gnuplot-beta — Developers and beta testers of new gnuplot code

Re: pngcairo: suggestion for additional option

[Ethan A M. <merritt@u.washington.edu>]

On Monday 26 November 2007 17:48, Allin Cottrell wrote:
> On the other hand, having the scale variable 
> default to zero would not be good at all -- it should really 
> default to 1

Just put a fix-up line in change_term() along with the others at
term.c lines 1524-1536

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: pngcairo: suggestion for additional option

[Allin C. <cot...@wf...>]

On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote:

> Allin Cottrell wrote:
> 
> > Hans has put me right: I had thought of TERM_TABLE entries as constants but
> > I was wrong.  However, it seems to me easier to add a function pointer at
> > the end of the table: that way no *.trm code needs to be touched unless the
> > term wants to offer a scale factor.
> 
> Same difference.  Adding a variable at the end of the struct has 
> the same net effect, and the benefit of being less risky.  An 
> unsupported variable automatically defaults to zero, but an 
> unsupported function defaults to an invalid function pointer, 
> which is generally unsafe to use.

I thought things were set up so that an unsupported function 
defaults to a null pointer (and my proposed code tests for that).  
Is that incorrect?  On the other hand, having the scale variable 
default to zero would not be good at all -- it should really 
default to 1, though I suppose one could work around a broken 
default of 0.

Allin Cottrell

Re: pngcairo: suggestion for additional option

[Ethan M. <merritt@u.washington.edu>]

On Monday 26 November 2007 10:11, Ethan Merritt wrote:
> Thinking out loud...
> 
> Is there an advantage to having this be a function call, rather than
> simply exporting the scale itself in TERM_TABLE?  
> 
> Would we ever need separate scales for X and Y?
> 
> What about auxilliary information like the mouse coordinate format?
> This is a sore point in the current X11 implementation. You can 
> continue to mouse an old plot even after gnuplot itself has exited,
> but the format used for mouse coordinates falls back to a generic
> one rather than the user-specified one.
> 
> What if someone wanted mouse feedback from the colorbar?
> We don't do that now, but as long as we're looking into expanded
> capabilities, why not?

Another thought, from my long-term wishlist...

Whatever mechanism we end up with, it would be nice to have it
available for the individual subplots within a multiplot.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

[<HBB...@t-...>]

Allin Cottrell wrote:

> Hans has put me right: I had thought of TERM_TABLE entries as 
> constants but I was wrong.  However, it seems to me easier to add 
> a function pointer at the end of the table: that way no *.trm code 
> needs to be touched unless the term wants to offer a scale factor.

Same difference.  Adding a variable at the end of the struct has the 
same net effect, and the benefit of being less risky.  An unsupported 
variable automatically defaults to zero, but an unsupported function 
defaults to an invalid function pointer, which is generally unsafe to use.

Re: colorbox front

[Ethan M. <merritt@u.washington.edu>]

On Monday 26 November 2007 14:17, Petr Mikulik wrote:
> There was a proposal to draw the palette colorbox always in front.
> Here, the colorbar inside the plot is obscured by the surface:
> 
> set colorbox origin 0.11,0.2 user
> set pm3d map; splot x
> 
> I don't think it makes too much sense to keyword "front|back" (there is 
> neither for "set key"). Any objections/ideas of drawing the colorbar after 
> the plot?

No objections, although I think if you are going to the trouble of
re-thinking the call site, you might as well provide a {front|back} option.

Just make sure that the "front" colorbox is still behind any
"front" labels.


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

[Allin C. <cot...@wf...>]

On Mon, 26 Nov 2007, Ethan Merritt wrote:

> On Monday 26 November 2007 11:44, you wrote:
> > On Mon, 26 Nov 2007, Ethan Merritt wrote:
> > > 
> > > Is there an advantage to having this be a function call, rather 
> > > than simply exporting the scale itself in TERM_TABLE?
> > 
> > As I understand it, yes.  For pngcairo, there's at present a 
> > hard-wired oversampling scale of 20, *if* oversampling is used.  
> > I believe it's always used at present, but in principle this could 
> > be user-configurable or otherwise depend on things at run time.

Hans has put me right: I had thought of TERM_TABLE entries as 
constants but I was wrong.  However, it seems to me easier to add 
a function pointer at the end of the table: that way no *.trm code 
needs to be touched unless the term wants to offer a scale factor.

Allin Cottrell

Re: colorbox front

[<HBB...@t-...>]

Petr Mikulik wrote:
> There was a proposal to draw the palette colorbox always in front.
> Here, the colorbar inside the plot is obscured by the surface:
> 
> set colorbox origin 0.11,0.2 user
> set pm3d map; splot x

That looks like quite a clear case of "Well, don't do that, then!" to 
me.  Nobody forced the user to put the box into such a silly position. 
So if they requested it there, we have to assume that's exactly what 
they wanted.

> I don't think it makes too much sense to keyword "front|back" (there is 
> neither for "set key").

I don't see what the key has to do with this.  Yes, the colorbox should 
have layering control.

> Any objections/ideas of drawing the colorbar after 
> the plot?

Objection.  Drawing it always on top of everything else would be worse 
than the current state of affairs.  People might have reasons to obscure 
parts of it --- i.e. they might hold their actual data more important 
than the legibility of the colourbar.

Re: Consistent escape mechanism for Unicode characters?

[<HBB...@t-...>]

Ethan Merritt wrote:
> For example
> 	set label "Planks's constant = ℏ"

> Would it be reasonable to make this same form acceptable to the
> wxt, post, x11 and other terminals?

I doubt it.  The SGML group of formats is quite alone in using '&' as an 
escape character.  Exporting this usage to other formats is bound to 
create tons of problem --- for starters, we already use it in enhanced 
text to signify "phantom" whitespace.

I tend to think Java's \u210f would make more sense, particularly 
because it would be a better fit into our overall C-based escape 
character scheme.

colorbox front

[Petr M. <mi...@ph...>]

There was a proposal to draw the palette colorbox always in front.
Here, the colorbar inside the plot is obscured by the surface:

set colorbox origin 0.11,0.2 user
set pm3d map; splot x

I don't think it makes too much sense to keyword "front|back" (there is 
neither for "set key"). Any objections/ideas of drawing the colorbar after 
the plot?

---
PM

Re: pngcairo: suggestion for additional option

[Ethan M. <merritt@u.washington.edu>]

On Monday 26 November 2007 11:44, you wrote:
> On Mon, 26 Nov 2007, Ethan Merritt wrote:
> > 
> > Is there an advantage to having this be a function call, rather 
> > than simply exporting the scale itself in TERM_TABLE?
> 
> As I understand it, yes.  For pngcairo, there's at present a 
> hard-wired oversampling scale of 20, *if* oversampling is used.  
> I believe it's always used at present, but in principle this could 
> be user-configurable or otherwise depend on things at run time.

I think the tool button on the wxt terminal allows you to toggle the
oversampling.  But isn't that exactly the same as term->xmax and
term->ymax changing dynamically when you resize the plot window?

> > > You suggested this sort of thing might be done on a 
> > > per-terminal basis via the term->text function.  I thought 
> > > about that, but it would seem to create a potential problem.  
> > > Suppose I plot using (say) pngcairo and the TERM_* values are 
> > > set.  Then I plot again using some other terminal, and these 
> > > values are not touched.  Now I'm going to get stale state 
> > > information from the TERM_* variables.
> > 
> > But that will _always_ be the case, no matter where you put the 
> > code. The TERM_* variables, and for that matter the GPVAL_* 
> > variables, are only valid immediately after a plot command.  As 
> > soon as you change anything with a "set ..." command, the values 
> > become stale.
> 
> I'm not quite with you on that.  Suppose I do
> 
> set term pngcairo
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> # set something or other
> set term dumb
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> 
> Both instances of "print" (on gnuplot with my patch) produce
> 
> bbox: 79 620 37 460
> 
> This does not strike me as a case of stale information, since I'm 
> getting the correct bounding box _for the last plot created_. 

I'm not saying that every "set" command inevitably invalidates
every variable.  But many "set" commands invalidate one or more
variables.  In particular, any command that affects the axis
ranges or scaling will invalidate the use of TERM_* for back-calculating
plot coordinates.  It would be tricky for gnuplot itself to know
whether it is still safe to present a value for a particular variable,
so the burden is on the user to capture a consistent snapshot of values.
And I think the only guaranteed safe time to do that is immediately 
after a plot command. 

> set term pngcairo
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX   
> set term jpeg
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> 
> If setting TERM_XMIN et al is optional and depends on the specific 
> terminal, and if the jpeg terminal doesn't elect to do it, the 
> second bbox print will be out of phase, won't it?

That is certainly an argument for requiring that the TERM_* variables
be updated for all terminal types.  The best mechanism for doing this
is under discussion.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

[Allin C. <cot...@wf...>]

On Mon, 26 Nov 2007, Ethan Merritt wrote:

> On Saturday 24 November 2007 11:29, Allin Cottrell wrote:
> > I'm attaching a set of 3 small patches that, I hope, 
> > jointly do the job in a reasonably elegant way.
> > 
> > 1) term_api.h is modified to add another term->foo function, 
> > namely term_scale, which (if applicable) retrieves a 
> > terminal-specific scale factor such as the oversampling_scale
> > in pngcairo.
> > 
> > 2) cairo.trm (pngcairo variant) is modified to provide that 
> > function, which simply returns the oversampling scale.
> 
> Thinking out loud...
> 
> Is there an advantage to having this be a function call, rather 
> than simply exporting the scale itself in TERM_TABLE?

As I understand it, yes.  For pngcairo, there's at present a 
hard-wired oversampling scale of 20, *if* oversampling is used.  
I believe it's always used at present, but in principle this could 
be user-configurable or otherwise depend on things at run time.

> Would we ever need separate scales for X and Y?

FWIW, I find it difficult to imagine that.

> What about auxilliary information like the mouse coordinate 
> format?

I guess that could be added where relevant: add_udv_by_name() is a 
nice flexible mechanism!

> What if someone wanted mouse feedback from the colorbar? We 
> don't do that now, but as long as we're looking into expanded 
> capabilities, why not?

Ditto.  I have no need for these things but they could be added.

> I have not yet had a chance to look at your patchset.
> Too busy reviewing character encoding fix-ups :-)

Fair enough!

> > You suggested this sort of thing might be done on a 
> > per-terminal basis via the term->text function.  I thought 
> > about that, but it would seem to create a potential problem.  
> > Suppose I plot using (say) pngcairo and the TERM_* values are 
> > set.  Then I plot again using some other terminal, and these 
> > values are not touched.  Now I'm going to get stale state 
> > information from the TERM_* variables.
> 
> But that will _always_ be the case, no matter where you put the 
> code. The TERM_* variables, and for that matter the GPVAL_* 
> variables, are only valid immediately after a plot command.  As 
> soon as you change anything with a "set ..." command, the values 
> become stale.

I'm not quite with you on that.  Suppose I do

set term pngcairo
set output '/dev/null'
plot x
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
# set something or other
set term dumb
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX

Both instances of "print" (on gnuplot with my patch) produce

bbox: 79 620 37 460

This does not strike me as a case of stale information, since I'm 
getting the correct bounding box _for the last plot created_.  But 
now suppose I do:

set term pngcairo
set output '/dev/null'
plot x
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX   
set term jpeg
set output '/dev/null'
plot x
print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX

If setting TERM_XMIN et al is optional and depends on the specific 
terminal, and if the jpeg terminal doesn't elect to do it, the 
second bbox print will be out of phase, won't it?  It'll still 
give the pngcairo bounding box while the user might reasonably 
expect it to give the jpeg box (or yield undefined values, perhaps 
-- but why bother to undef these values when they can be retrieved 
with ease).

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Consistent escape mechanism for Unicode characters?

[Ethan M. <merritt@u.washington.edu>]

With the addition of UTF-8 support to the postscript terminal,
we are reaching the point where users might logically want to
specify individual Unicode characters in a terminal-independent
way.  If your environment is natively UTF-8 this shouldn't be a problem.
But some people may not have that option.

In particular I am thinking of the FAQ entries for
Planck's constant and the solar mass symbol.

For example
	set label "Planks's constant = ℏ"

Currently the SVG and PNG drivers simply pass through the escaped
sequence to the underlying libraries, which correctly look for the
corresponding Unicode character in the current font.

Would it be reasonable to make this same form acceptable to the
wxt, post, x11 and other terminals?

-- 
Ethan A Merritt

Re: utf-8.ps not installed

[Lars H. <lhe...@us...>]

> I don't think the dust has settled yet from adding UTF-8 support.
> I doubt many people have used these yet.
> Would it be easier if they were renamed to unicode.* ?
> 
> unicode_big.map		-> unicode.big_map
> unicode_maps.README	-> unicode.README
> unicode_small.map	-> unicode.small_map
> <doesn't exist yet>	-> unicode.math_map

 I haven't really followed UTF-8 support and do not know the significance
 of these files :) I'll just check in what I have now, and we can make
 more changes if and when necessary.

Re: utf-8.ps not installed

[Ethan M. <merritt@u.washington.edu>]

On Monday 26 November 2007 09:31, Lars Hecking wrote:
> Ethan Merritt writes:
> > 
> > Could some autotools guru please change the Makefile template so
> > that the entire contents of the .../term/PostScript directory are
> > installed?  
>  
>  Not a good idea - if, for any reason, random rubbish ends up in the directory,
>  it will get installed.
> 
>  But I can change this so that all .ps and .txt files get installed.

That sounds reasonable.

>  Any others? What about the .map files?

I don't think the dust has settled yet from adding UTF-8 support.
I doubt many people have used these yet.
Would it be easier if they were renamed to unicode.* ?

unicode_big.map		-> unicode.big_map
unicode_maps.README	-> unicode.README
unicode_small.map	-> unicode.small_map
<doesn't exist yet>	-> unicode.math_map


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

[Ethan M. <merritt@u.washington.edu>]

On Saturday 24 November 2007 11:29, Allin Cottrell wrote:
> I'm attaching a set of 3 small patches that, I hope, 
> jointly do the job in a reasonably elegant way.
> 
> 1) term_api.h is modified to add another term->foo function, 
> namely term_scale, which (if applicable) retrieves a 
> terminal-specific scale factor such as the oversampling_scale
> in pngcairo.
> 
> 2) cairo.trm (pngcairo variant) is modified to provide that 
> function, which simply returns the oversampling scale.

Thinking out loud...

Is there an advantage to having this be a function call, rather than
simply exporting the scale itself in TERM_TABLE?  

Would we ever need separate scales for X and Y?

What about auxilliary information like the mouse coordinate format?
This is a sore point in the current X11 implementation. You can 
continue to mouse an old plot even after gnuplot itself has exited,
but the format used for mouse coordinates falls back to a generic
one rather than the user-specified one.

What if someone wanted mouse feedback from the colorbar?
We don't do that now, but as long as we're looking into expanded
capabilities, why not?


> 3) eval.c is modified as per my previous suggestion, as amended by 
> you.  That is, update_gpval_variables(), for context = 1, is 
> augmented to call the new function update_plot_bounds(), which 
> defines the 4 variables TERM_XMIN, TERM_XMAX, TERM_YMIN and 
> TERM_YMAX.  The initial values to fill out these variables come 
> via the map_position() function.  We then test to see if the 
> current term offers a term_scale function, and if so we use this 
> to modify the values before recording them.

I have not yet had a chance to look at your patchset.
Too busy reviewing character encoding fix-ups :-)

> You suggested this sort of thing might be done on a per-terminal 
> basis via the term->text function.  I thought about that, but it 
> would seem to create a potential problem.  Suppose I plot using 
> (say) pngcairo and the TERM_* values are set.  Then I plot again 
> using some other terminal, and these values are not touched.  Now 
> I'm going to get stale state information from the TERM_*  variables.

But that will _always_ be the case, no matter where you put the code.
The TERM_* variables, and for that matter the GPVAL_* variables,
are only valid immediately after a plot command.  As soon as you 
change anything with a "set ..." command, the values become stale.

> Also, the basic bounds calculation can easily be done in the core, 
> hence avoiding needless duplication of code at the terminal level.

Yes, but...
Some terminals will want their own routines anyhow. In particular,
x11 has its own format and output path for this information.  

There is another possible mechanism for this case, one parallel to
that used for term->arrow(). Any driver that wants to handle arrows
privately can register a specific routine;  all others can register
the generic routine do_arrow() instead.  In fact change_term() is 
smart enough to register the generic routine do_arrow() for 
terminals that don't provide an entry point at all.  This avoids
having to patch every single driver.


-- 
Ethan A Merritt

Re: utf-8.ps not installed

[Lars H. <lhe...@us...>]

Ethan Merritt writes:
> On Monday 26 November 2007 08:58, Allin Cottrell wrote:
> > Small issue: term/Makefile.am.in needs to have utf-8.ps added to 
> > the list of headers to be installed, in the postscript_DATA 
> > section.  Otherwise it doesn't get installed and term post fails 
> > for encoding utf8.
> 
> It seems error-prone to require modification of all the build scripts 
> every time a file is added to this directory.
> 
> Could some autotools guru please change the Makefile template so
> that the entire contents of the .../term/PostScript directory are
> installed?  
 
 Not a good idea - if, for any reason, random rubbish ends up in the directory,
 it will get installed.

 But I can change this so that all .ps and .txt files get installed.
 Any others? What about the .map files?

RFC: define new variables TERM_XMIN etc.

[Allin C. <cot...@wf...>]

I think my original posting on this got lost in a flood of other 
things, so I'm trying again.

The idea: make available, via the print command, the "bounding 
box" of the actual plot area following a plot command.  This is 
primarily intended for retrieving the pixel bounds for bitmapped 
graphics so as to be able to construct an "image map" (e.g. for a 
gnuplot-generated PNG file), but it may have other uses.

Method: define 4 new internal variables, TERM_XMIN, TERM_XMAX, 
TERM_YMIN and TERM_YMAX.  These get updated in eval.c after a plot 
(along with GRAPH_X_MIN and friends).  A function is added to the 
term structure which enables -- but does not require -- a given 
terminal to supply a scale factor for these bounds.  This is 
designed for pngcairo, which works in units of pixel/20, but might 
have application for some other terminals.

Comment: This would be *very* useful for me, and others have 
expressed an interest in this sort of thing before.  In the 
implementation I have tried to take into account suggestions 
from Hans and Ethan, and to respect the gnuplot architecture.

Patch: The required small diffs to cairo.trm, eval.c and 
term_api.h (as per current CVS) are attached in a tarball.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: utf-8.ps not installed

[Ethan M. <merritt@u.washington.edu>]

On Monday 26 November 2007 08:58, Allin Cottrell wrote:
> Small issue: term/Makefile.am.in needs to have utf-8.ps added to 
> the list of headers to be installed, in the postscript_DATA 
> section.  Otherwise it doesn't get installed and term post fails 
> for encoding utf8.

It seems error-prone to require modification of all the build scripts 
every time a file is added to this directory.

Could some autotools guru please change the Makefile template so
that the entire contents of the .../term/PostScript directory are
installed?  

-- 
Ethan A Merritt

utf-8.ps not installed

[Allin C. <cot...@wf...>]

Small issue: term/Makefile.am.in needs to have utf-8.ps added to 
the list of headers to be installed, in the postscript_DATA 
section.  Otherwise it doesn't get installed and term post fails 
for encoding utf8.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: status of alternatives to linetype/pointtype?

[Ralf J. <jue...@cs...>]

On Mon, 12 Nov 2007, Ethan A Merritt wrote:

>>> If you mean user definition of point types, please ask a more
>>> specific question.
>>
>> The same holds for point types, as far as I understand (applies
>> to plotting styles 'points' or 'linespoints'). It would be nice
>> if the interpretation of point types were terminal independent.
>
> Points:
> The first 8-10 point types are supposed to be the same up to the
> limitations imposed by individual output hardware.
> I've just checked on post/pdf/cairo/png/emf/latex/x11/wxt/win
> They all look pretty much equivalent to me.
>
> Do you have an example of an inconsistency?

I mostly use emf and postscript eps and at least for these two
the point types look completetly different (gnuplot 4.2).


> Dashes:
> I am not aware of any standard definition of dash patterns that
> would be terminal-independent in the sense that RGB color is.
> I am dubious that we can do any better than we already are.

I don't understand. Are you saying it is difficult to realize
the same line appearance on different terminals?
Or you are you saying you don't know a scheme of specifying
dash patterns?

I did not mean to ask for allowing users to define their own
dash patterns (although that would solve the problem as well),
but for consistency of appearance across terminals.

Thanks,
Ralf

Re: cairo and character encoding issues

[Allin C. <cot...@wf...>]

On Sat, 24 Nov 2007, Ethan A Merritt wrote:

> On Saturday 24 November 2007 11:05, Timothée Lecomte wrote:
> > Allin Cottrell a écrit :
> > >> I am thinking that regardless of any possible bugs in the cairo 
> > >> processing, we should be consistent and always call 
> > >> setlocale(LC_CTYPE,"").
> > > That makes sense to me: maybe in init_locale?
> > I agree with that. Why not LC_ALL by the way ?
> 
> OK. I have added setlocale(LC_CTYPE,"") to init_locale().
> I also added Allin's pre-validation of strings to see if they conform
> to UTF-8. The test doesn't really prove the string is UTF-8, but I
> can't think of any non-contrived cases where this would be a problem.

Thank you for doing that.

> Neither of these patches are strictly speaking necessary. The 
> same result could be accomplished by putting "set encoding 
> locale" in ~/.gnuplot.

Not quite the same.  One of the attractions of a target that 
accepts UTF-8 is that files intended for that target and encoded 
in UTF-8 can be shared across platforms, regardless of the local 
encoding.  

For instance if I'm on an ISO-88959-1 platform and I download a 
UTF-8-encoded gnuplot source file to generate a plot using one of 
the cairo-based terminals, it should now work fine.  Before, it 
would fail with a confusing error message (probably a different 
confusing error message depending on whether or not I had "set 
encoding locale" in my ~/.gnuplot).

Allin Cottrell

Re: cairo and character encoding issues

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 24 November 2007 11:05, Timoth=E9e Lecomte wrote:
> Allin Cottrell a =E9crit :
> >> I am thinking that regardless of any possible bugs in the cairo=20
> >> processing, we should be consistent and always call=20
> >> setlocale(LC_CTYPE,"").
> > That makes sense to me: maybe in init_locale?
> I agree with that. Why not LC_ALL by the way ?

OK. I have added setlocale(LC_CTYPE,"") to init_locale().
I also added Allin's pre-validation of strings to see if they conform
to UTF-8. The test doesn't really prove the string is UTF-8, but I
can't think of any non-contrived cases where this would be a problem.

Neither of these patches are strictly speaking necessary. The same=20
result could be accomplished by putting "set encoding locale" in
~/.gnuplot.  But having a more consistent initial state for the program
will I hope reduce the number of confusing bug reports.

This should also resolve bug=20
#1834525 'utf8 encoding not working in pdfcairo under C locale'


=2D-=20
Ethan A Merritt

Re: cairo and character encoding issues

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 24 November 2007 11:05, you wrote:
> >> I am thinking that regardless of any possible bugs in the cairo 
> >> processing, we should be consistent and always call 
> >> setlocale(LC_CTYPE,"").
> >
> > That makes sense to me: maybe in init_locale?
> >   
> I agree with that. Why not LC_ALL by the way ?

Because it sets LC_NUMERIC, which breaks all sorts of things
in locales where the decimal separator is a comma.

In 4.2 we tried to work around this by explicitly setting
LC_NUMERIC to "C" when necessary, but the list of necessary places
was long yet incomplete.  This led to more than one bug report.
(e.g. #1740017 #1707916 #1692541 #1692550).

In CVS I have inverted that.  The program runs with LC_NUMERIC set
to "C" for all purposes, except that it applies the locale when creating
a text string for display as part of the plot.

-- 
Ethan A Merritt

Re: cairo and character encoding issues

[<tim...@lp...>]

Allin Cottrell a écrit :
> On Sat, 24 Nov 2007, Ethan A Merritt wrote:
>
>   
>>> 2) How did LC_CTYPE _get_ to be equal to en_US.UTF-8 at this point 
>>> in execution, when the only command that has been issued is "show 
>>> locale"? 
>>>       
>> Puzzling indeed.  With the help of many trace statements, I find that
>> the locale is loaded during the first call to readline_ipc() in rlgets(),
>> which is itself called from gp_get_string()...
>>     
>
> Nice detective work!
>
>   
Please note that gtk+ (used by wxGTK, used by wxt) is another offender 
here which calls setlocale(LC_ALL,"") or something like that. For 
example, on my system where wxt is built:

> tipote@tipote-laptop:~$ echo "show locale; plot x; show locale" | gnuplot
>
>         LC_CTYPE is C
>         LC_TIME is C
>
>
>         LC_CTYPE is fr_FR.UTF-8
>         LC_TIME is fr_FR.UTF-8

When wxt is initialized, gtk+ loads the locale settings. I have already 
had to work around it for LC_NUMERIC in wxt, as you can see from the 
following lines of code taken from lines 1445-1449 in 
src/wxterminal/wxt_gui.cpp:

> #ifdef HAVE_LOCALE_H
>         /* when wxGTK is initialised, GTK+ also sets the locale of the 
> program itself;
>          * we must revert it */
>         setlocale(LC_NUMERIC, "C");
> #endif /*have_locale_h*/


At least, we know understand what happens on Mojca's box too:
>
> Here I have:
>
>   
>> > locale
>>     
> LANG=
> LC_COLLATE="sl_SI.UTF-8"
> LC_CTYPE="sl_SI.UTF-8"
> LC_MESSAGES="sl_SI.UTF-8"
> LC_MONETARY="sl_SI.UTF-8"
> LC_NUMERIC="sl_SI.UTF-8"
> LC_TIME="sl_SI.UTF-8"
> LC_ALL="sl_SI.UTF-8"
> Terminal type set to 'aqua'
> gnuplot> show locale
>
>         LC_CTYPE is C
>         LC_TIME is C
>         LC_NUMERIC is C
>
> gnuplot>
>
> Mojca

Mojca runs MacOS, so she surely doesn't have wxt, aqua is indeed the 
terminal initialized on startup, and she most likely doesn't have 
readline. That's why her LC_* are not set from her locale settings.


>>> 3) Anyway, by the time you plot a graph using cairo the LC_CTYPE 
>>> setting has reverted to "C".  I've verified that by sticking a 
>>> print before the g_get_charset() invocation:
>>>       
>> I can't reproduce that. Once the locale gets set, it sticks.  
>> As you would expect.
>>     
>
> Yup, I was wrong.  The active factor was interactive vs 
> non-interactive, not anything that happened in between "show 
> locale" and gp_cairo calling g_get_charset.
>   
Ah, I was puzzled too by that one.

>   
>> I am thinking that regardless of any possible bugs in the cairo 
>> processing, we should be consistent and always call 
>> setlocale(LC_CTYPE,"").
>>     
>
> That makes sense to me: maybe in init_locale?
>   
I agree with that. Why not LC_ALL by the way ?

Timothée

Re: cairo and character encoding issues

[Allin C. <cot...@wf...>]

On Sat, 24 Nov 2007, Ethan A Merritt wrote:

> > 2) How did LC_CTYPE _get_ to be equal to en_US.UTF-8 at this point 
> > in execution, when the only command that has been issued is "show 
> > locale"? 
> 
> Puzzling indeed.  With the help of many trace statements, I find that
> the locale is loaded during the first call to readline_ipc() in rlgets(),
> which is itself called from gp_get_string()...

Nice detective work!

> > 3) Anyway, by the time you plot a graph using cairo the LC_CTYPE 
> > setting has reverted to "C".  I've verified that by sticking a 
> > print before the g_get_charset() invocation:
> 
> I can't reproduce that. Once the locale gets set, it sticks.  
> As you would expect.

Yup, I was wrong.  The active factor was interactive vs 
non-interactive, not anything that happened in between "show 
locale" and gp_cairo calling g_get_charset.

> I am thinking that regardless of any possible bugs in the cairo 
> processing, we should be consistent and always call 
> setlocale(LC_CTYPE,"").

That makes sense to me: maybe in init_locale?

Allin Cottrell