Using Version 5.2 patchlevel 4 last modified 2018-06-01
When an invalid font is specified for the PNG terminal, then subsequent variables/constants truncate the floating point portion.
Reproduction is easy:
set terminal png enhanced size 3504, 2754 font " Helvetica,32"
xRangeMin = 55.85
xRangeMax = 56.15
print( xRangeMin )
print( xRangeMax )
And it prints 55 and 56
I cannot reproduce this.
More information might help.
1) Do you see the same truncation from "show variable" or only from "print"?
2) In what way is that an invalid font? I ask because I get no error or truncation from the commands you show, but then again I see no error with the font either. Can you show the error message that leads you to think that the font is involved?
3) Is it possible that you are working within a LOCALE environment that uses comma rather than period for the decimal point? That really shouldn't cause this either, but it is the only remotely plausible mechanism I can think of for losing the fraction part of a floating point value.
To test (3), please issue the command "show locale" from the gnuplot command line after the "xRangeMax=56.15" command.
Last edit: Ethan Merritt 2018-09-04
Sorry for the delay - I had to regain access to my account.
I think the system locale is set to use commas, but gnuplot ignores this setting (thank god). It definitely throws errors if I use commas in constants. I can't reproduce it right now but I have seen show variable display a var as 55.85,0 before.
After opening a fresh instance, I can run the following:
And get this output:
55.85
56.15
User and default variables:
pi = 3.14159265358979
GNUTERM = "wxt"
NaN = NaN
ARGC = 0
ARG0 = ""
ARGV = <0 element array>
xRangeMin = 55.85
xRangeMax = 56.15
After running
I get:
fontconfig: Didn't find expected font family. Perhaps URW Type 1 fonts need installing? when opening font Helvetica, trying default
If I add a space between the quote and the font name I do not get the font error.
Rerunning the initial commands leads to:
55.0
56.0
User and default variables:
pi = 3,14159265358979.0
GNUTERM = "wxt"
NaN = NaN
ARGC = 0
ARG0 = ""
ARGV = <0 element array>
xRangeMin = 55.0
xRangeMax = 56.0
NOTE: The pi constant is now printed with a comma, not a decimal point. This leads me to believe that the set terminal command is switching the current thread's locale setting.
Last edit: Henrik A 2018-09-06
It is evident from the printed value of pi that the program has ended up in a state where a "comma for decimal separator" locale is active internally. That should never happen. I also notice that the current terminal self-reports as "wxt" after the error even though from what you describe it should have changed to "png". So other internal structures are also corrupt.
The fontconfig error message is presumably due to a system configuration problem, but I do not at this point understand how a system-level error can leave gnuplot's internal state corrupted. The strange thing is that apparently gnuplot itself never saw an error condition. If it had, the internal error-handling routine int_error() would have reset the locale to C regardless of what state it had been in previously.
My current best guess is that this error occurs because the threading model of the wxt libraries is garbage. Whatever the system-level error may be, it only affects gnuplot because the error is trapped by a thread of the wxt processing (not the main gnuplot thread) which then performs various non-thread-safe operations that affect the locale. In other words, the error scenario only happens if the current gnuplot terminal is "wxt" and the gnuplot executable was built to use the multi-threaded wxt libraries.
You can test this by first changing the current gnuplot terminal to something else entirely (e.g. "dumb" or "qt" or "x11") so that wxt is not involved. The strongest test would be to set this in the environmental variable GNUTERM so that the wxt terminal is never active to begin with. I would predict that running your test commands from that state will generate the same system-level error message but will not affect gnuplot's internal state because no wxt threads are running. I would be curious to know whether this results in the current gnuplot terminal successfully changing to "png" or not. Could you test that?
If my guess is correct, the permanent fix or work-around may be to never allow gnuplot to use the multi-threaded wxt libraries. They have been implicated in other problems as well, so this was already under consideration.
Your short term work-around is probably easier: install the URW fonts as suggested by the fontconfig error message.
I have thought of another possible work-around. Try explicitly setting the numeric locale in gnuplot to something with a decimal point. E.g.
This may cause gnuplot to actively set the locale rather than assuming that it is already correctly set.
5.0 patchlevel 4 does not exhibit this behavior.
I set GNUTERM=dumb and then launched gnuplot, error still occurs:
Note: I left out setting the variables after switching the terminal.
Trying to set variables with a comma seperator results in an error, both before and after entering the error state.
I cannot set the locale explicitly - I get 'Could not find the requested locale'. I can run 'set decimal locale', output is: 'decimal_sign in locale is ', however it still requires periods as a separater instead of commas, but now the output is correct again.
At this point I am suspecting a problem with the fontconfig library. See for example these bug reports:
https://bugs.gentoo.org/650332
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895470
https://bugs.freedesktop.org/show_bug.cgi?id=105492
Can you check what version of libfontconfig you have installed?
Is it possible that the older (working) gnuplot 5.0.4 is linked to an older version of libfontconfig and the newer (broken) gnuplot 5.2.4 is linked to a newer version of libfontconfig?
I'm using the official windows x64 build / download. So no libfontconfig. Or rather - you need to check what was used on the build system to create the release.
Last edit: Henrik A 2018-09-07
I can see that the windows x64 download contains
libfontconfig-1.dll
I do not know how to query for the exact version, but simply searching for ascii strings in that dll finds
../../fontconfig-2.13.0/src/fccache.c
../../fontconfig-2.13.0/src/fcmatch.c
../../fontconfig-2.13.0/src/fcweight.c
2.13.0 is the version for which the bug reports above were filed, so I think that this confirms that the problem is with libfontconfig. I know nothing about what is or is not possible on Windows. Maybe you can just swap out the buggy dll for a working one?
I will summarize this issue for the development mailing list so that one of the developers using Windows will see it.
I made window binary packages for 5.2.4.
For me it works on 5.2.4 64bit (64 bit on windows 10 Home 1803 )
Therefore I cannot reproduce what you met so that I cannot help you.
On Saturday, 08 September 2018 01:06:49 Tatsuro MATSUOKA wrote:
My understanding is that the error happens only if
1) The default locale of the system uses a comma as the decimal separator
and
2) You request a font of a type (in this case Adobe Type 1) that is not
installed on the system.
I cannot reproduce it here either, but both (1) and (2) are not
true for my system.
Related
Bugs:
#2069I made a reply without seeing the Ethan's post to the gnuplot-beta list.
https://sourceforge.net/p/gnuplot/mailman/message/36410457/
I will re-package 5.2.4 with new fontconfig librarary (2.13.1).
I updated build dependencies using the MSYS2 package manager. Now version of fontconfig is 2.13.1. I re-build windows binaries and re-packaged.
New windows binary packages are now available from SourceForge site.
https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.4/
To
Henrik A
Please test using new packgages.
Last edit: Tatsuro MATSUOKA 2018-09-08
I can confirm the issue is fixed.
Thanks !