Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2005-05-24 10:03:09
|
I prefer "darker green" color in my screen plots, thus I've put gnuplot*line2Color: green,0,6 !gnuplot*line2Color: green,0.6 into my .Xdefaults + run xrdb. The trouble is that gnuplot parses the information according to current locales, thus sometimes I have green curve, sometimes black curve, depending whether I have LC_ALL=C in the given running terminal/program and whether there is "0.6" or "0,6" in .Xdefaults. Cannot be .Xdefaults parsing locale-independent? --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-05-24 10:35:24
|
Petr Mikulik wrote: > whether I have LC_ALL=C in the given running terminal/program and whether > there is "0.6" or "0,6" in .Xdefaults. > > Cannot be .Xdefaults parsing locale-independent? That's not for us to decide, I think: we don't parse .Xdefaults ourselves, but rather have X11 API functions do that for us. Thus the problem, if any, is in X11. |
|
From: Petr M. <mi...@ph...> - 2005-05-24 14:04:55
|
> > Cannot be .Xdefaults parsing locale-independent?
> That's not for us to decide, I think: we don't parse .Xdefaults
> ourselves, but rather have X11 API functions do that for us. Thus the
> problem, if any, is in X11.
No, it is in gnuplot -- gplt_x11.c:
if (sscanf(v, "%30[^,],%lf", color, &intensity) == 2) {
if (intensity < 0 || intensity > 1) {
fprintf(stderr, "\ngnuplot: invalid color intensity in '%s'\n", color);
intensity = 1;
}
} else {
strcpy(color, v);
intensity = 1;
}
It is the above sscanf() which returns different values according to locale.
Funny -- gnuplot ignores locale, gnuplot_x11 takes care about them:
sscanf("3,1415", "%lg", &x);
gives different results in command.c and gplt_x11.c.
It seems that this in gplt_x11.c
setlocale(LC_ALL, "")==NULL
is responsible for the problems.
Could locales be ignored when reading .Xdefaults?
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-24 15:28:53
|
On Tuesday 24 May 2005 07:04 am, Petr Mikulik wrote:
> > > Cannot be .Xdefaults parsing locale-independent?
>
> No, it is in gnuplot -- gplt_x11.c:
>
> if (sscanf(v, "%30[^,],%lf", color, &intensity) == 2) {
Locale handling is done in sscanf (glibc).
> It is the above sscanf() which returns different values according to locale.
Exactly.
> It seems that this in gplt_x11.c
> setlocale(LC_ALL, "")==NULL
> is responsible for the problems.
setlocale( ,"") tells libc to use the locale which the user has
requested for this process. That is the correct thing to do.
> Could locales be ignored when reading .Xdefaults?
Why? It's the user's .Xdefaults file. He should construct
it to be consistent with his chosen locale.
But if you want gnuplot_x11 always to run in a specific locale,
you can make a wrapper script:
gnuplot_x11:
#!/bin/csh
setenv LC_TYPE C
real_gnuplot_x11 $@
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-24 15:44:39
|
On Tuesday 24 May 2005 08:28 am, Ethan Merritt wrote: > > But if you want gnuplot_x11 always to run in a specific locale, > you can make a wrapper script: > > gnuplot_x11: > #!/bin/csh > setenv LC_TYPE C > real_gnuplot_x11 $@ Correction: That example is correct for setting character encoding, which is what I'm usually fighting. But for your specific issue (commas or periods in numbers) it should be: setenv LC_NUMERIC C -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-05-25 07:27:41
|
> > But if you want gnuplot_x11 always to run in a specific locale, > > you can make a wrapper script: > > > > gnuplot_x11: > > #!/bin/csh > > setenv LC_TYPE C > > real_gnuplot_x11 $@ > > setenv LC_NUMERIC C That's an ugly solution. I don't see any reason why gnuplot should insist on having its resources in .Xdefaults written in a non-C locales. It's just gnuplot's choice. Also, docs says: gnuplot> help x11 color_resources ... For example, `blue, 0.5` means a half intensity blue. .. Thus, gnuplot should not expect "blue,0,5" on some other systems -- that's not portable. Consequently, I propose that gnuplot always reads .Xdefaults resources in C-locale. PS: I came to this issue because on my system there is by default LANG=cs_CZ.UTF-8 but I run Midnight Commander as LANG=en_US.UTF-8 mc_lastdir so that its menus are always in English. That's not funny if hotkeys change. Gnuplot behaves differently if I run it from plain Konsole or from mc, i.e. its .Xdefault resources are not portable. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-05-25 10:32:44
|
Petr Mikulik wrote: > I don't see any reason why gnuplot should insist on having its resources in > .Xdefaults written in a non-C locales. gnuplot isn't really insisting on anything here --- it just does what you seemed to ask of it. The locale environment settings are under *your* control, so you're responsible for making sure they make sense. Setting LC_NUMERIC or LC_COLLATE to anything other than "C" or "POSIX" generally doesn't make sense. So you could fix your situation for good by putting an export LC_NUMERIC=C into your ~/.profile or /etc/profile, or change your mc invokation macro to LC_MESSAGES=en_US.UTF-8 mc_lastdir > Consequently, I propose that gnuplot always reads .Xdefaults resources in > C-locale. That's a good idea in its own right. I'll move the setlocale() call in gplt_x11.c to a less disturbing position. |
|
From: Petr M. <mi...@ph...> - 2005-05-25 13:54:33
|
> into your ~/.profile or /etc/profile, or change your mc invokation macro to > LC_MESSAGES=en_US.UTF-8 mc_lastdir This changes menu entries ... but dates are in Czech, and the additional pain is with (g)awk which gets crazy with decimal "," instead of ".", so I will rather keep the LANG. > > Consequently, I propose that gnuplot always reads .Xdefaults resources in > > C-locale. > > That's a good idea in its own right. I'll move the setlocale() call in > gplt_x11.c to a less disturbing position. Thanks, it works. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-25 16:27:42
|
On Wednesday 25 May 2005 12:27 am, Petr Mikulik wrote: > Consequently, I propose that gnuplot always reads .Xdefaults resources in > C-locale. I fail to understand the problem. It's your .Xdefaults file - you can put anything you like in it. Why limit gnuplot by telling it to ingore the user's choice of environment? > PS: I came to this issue because on my system there is by default > LANG=cs_CZ.UTF-8 > but I run Midnight Commander as > LANG=en_US.UTF-8 mc_lastdir > so that its menus are always in English. That's not funny if hotkeys change. Aha. So I think the underlying issue is that you are using obsolete syntax for setting the locale. For a long time now the locale settings have been split into separate components, and the LANG variable is used only as a backward-compatibility fall-back. I think what you want is unsetenv LANG setenv LC_CTYPE cs_CZ.UTF-8,en_US.UTF-8 setenv LC_MESSAGES en_US.UTF-8 setenv LC_NUMERIC C Individual programs may be buggy, of course, but if they are correctly calling setlocale() then this should result in using CZ character encodings if available (with fall-back to en_US), menus and other system messages in English, and C-language formats for numbers. You can also set LC_TIME to choose a prefered time/date format. > Gnuplot behaves differently if I run it from plain Konsole or from mc, > i.e. its .Xdefault resources are not portable. It should be consistent if you set LC_NUMERIC. If you find out otherwise, then that definitely is a bug, and we should try to fix it. I am not an expert on setting locales. I had to figure this all out the hard way, after installing my current generation of machines to support ja_JP.UTF-8. I assure you it's at least as disconcerting to have your menus pop up in Japanese as it is to have them appear in Czech. But dual-language support works nicely once you have the various locale settings sorted out. I love the current versions of Mandrake (now Mandriva), where the KDE desktop can be installed with SCIM multi-language support. This is really great because you can change the effective locale for individual programs (while they are running!) with a hot keys or a menu command. (caveat: the programs have to be build with appropriate X-input support, but that is true for the ones in the Mandriva distro). -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-05-26 14:14:59
|
> > Consequently, I propose that gnuplot always reads .Xdefaults resources in > > C-locale. > > I fail to understand the problem. > It's your .Xdefaults file - you can put anything you like in it. > Why limit gnuplot by telling it to ingore the user's choice of > environment? I just wanted that gnuplot entries in .Xdefault are not subject to locale, but always with decimal point. Patch by Hans-Bernhard fixed this. > I think what you want is > setenv LC_CTYPE cs_CZ.UTF-8,en_US.UTF-8 Interesting to know that you can have two options. --- PM |
