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

Re: locales and .Xdefaults

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

> 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

[Fwd: Gnuplot: MAX_NUM_VAR in src/syscfg.h]

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

----- Forwarded message from Eeri Kask <ee...@in...> -----

Dear Mr. Gaylord,

may I ask to advance the #define'd compile-time parameter

     MAX_NUM_VAR

in src/syscfg.h from 5 to something like 20 or so?  :-)

I am doing some plotting of functions of analytical geometry in R^3 and 
as I am afraid Gnuplot does not support vector/matrix data/arithmetics I 
have to define functions to compute e.g. vector dot products and the 
like by myself:

     DotProduct (a1,b1,c1,a2,b2,c2) = a1*a2 + b1*b2 + c1*c2;

providing components of all vectors (resp. matrices) as function call 
parameters.  So it is a little unlucky if the abovementioned dot product 
function parsing fails at 'c2'.

This is a matter of discomfort simply, as I have to compile Gnuplot 
always separately instead of installing precompiled binaries provided by 
most Linux distributors.  :-)

Greetings,

     Eeri Kask

----- End forwarded message -----

Re: locales and .Xdefaults

[Hans-Bernhard B. <br...@ph...>]

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.

Re: locales and .Xdefaults

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

> > 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

Re: locales and .Xdefaults

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

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

Re: locales and .Xdefaults

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

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

Re: locales and .Xdefaults

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

> > 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

Re: locales and .Xdefaults

[Hans-Bernhard B. <br...@ph...>]

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.

locales and .Xdefaults

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

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

Re: [RFC] Boxed text labels

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

On Monday 23 May 2005 08:49 am, Ethan Merritt wrote:
> 
> > fill a box (even with "background"), draw a rectangle
> 
> Only if the corners of the rectangle are known in advance.
> In this case, they are not.  Consider how poorly the text on the
> "text" page is boxed, and always has been.
   ^^^^

Bleah. I meant "test", of course. 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [RFC] Boxed text labels

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

Petr Mikulik wrote >
> Can you specify the fill color and line width+color (or
> linestyle)?

>On Sunday 22 May 2005 10:38 pm, Ethan Merritt wrote:
>>     set style textbox {opaque|transparent}
>> The intent is that eventually other style options (text
>> margins, shape, color, linestyle, etc) could be added
>> here as well.

The current line width+color is used. As I noted above, my 
intent was that eventually we could add additional properties
to "set style textbox". 

>  I think there should be an option to increase the size of
> the box --
> "... boxed size {+20%,+30% | +3char,+3char | absolute size} ..."

Yes. That is what I meant by "text margin".  There's a
place-holder for it in the terminal code, but I was interested
in hearing opinions as to whether this should be a global
setting or something that is specified separately for each label.
The latter would require adding data fields to the text_label
structure.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [RFC] Boxed text labels

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> This capability is necessarily driver-dependent. 

Why?  The existing terminal API can do all the necessary things already,
AFAICS: measure text, fill a box (even with "background"), draw a 
rectangle, and output text.  I really don't see why this should 
necessitate a new API entry.  I dislike the amount of needless code 
duplication this is bound to duplicate.  Work that can be described and 
done without knowing what terminal you're on has no business being done 
inside a terminal driver.

Re: global pt

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

> > I don't think so.  That would have to be done by 'set style plot', in
> > the current setup, but such a command doesn't exist, nor do 'set style
> > data' or 'set style functions' extend to this.
>
> I wonder if we could provide an option to cycle through line *styles*
> rather than line *types* in successive plots.  This would allow you,
> for instance, to set all line styles to use pt 7, and then issue plot
> commands as usual.

Something like that could be useful; nowadays, we can use macros (cool!).

---
PM

[RFC] Boxed text labels

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

I have not had much feedback on patchset #1143563
"Place arbitrary rectangles in 2D". Perhaps it does not
do what people really want. So I have been working away
at an alternative approach that does only one thing, but
does it a whole lot better than the previous patchset.

Please take a look, and offer comments or suggestions.

Patchset #1206823 "Boxed text labels"

New option {boxed} for text labels draws a bounding box
around the corresponding text.  E.g.
    set label 1 "Some multi-line\n comment" boxed
    set label 2 "{/Symbol S}f_k^{2n}" boxed
    splot "foo" using 2:3:4:1 with labels boxed

I have included a demo script, showing use in 2D and in 3D
(png output uploaded to SourceForge with the patchset).
 
Box placement is perfect, subject to the limitations of
font and output device. It works independently of
enhanced text mode. The style of the bounding box is
controlled globally by a new command:
    set style textbox {opaque|transparent}
The intent is that eventually other style options (text
margins, shape, color, linestyle, etc) could be added
here as well.

This capability is necessarily driver-dependent. I have
implemented it for gd.trm post.trm and x11.trm   I
imagine that it would be staightforward to implement in
the TeX-based terminals, but I'll leave that to  some
TeX guru.

The implementation adds one new terminal routine
    *term->boxed_text(x, y, option)

Option 0: Initialize bounding box to contain only the
point (x,y). Subsequent calls to *term->put_text() will
update the bounding box incrementally

Option 1: Draw the bounding box outline

Option 2: Fill the box with background color

Option 3: Change text margins to x% and y% of default
margins (not implemented yet).

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

Re: [Gnuplot-info] logscale and autoscale improvement (was logscale and manual range setting?)

[James R. V. Z. <jr...@co...>]

Hans-Bernhard Broeker <br...@ph...> wrote:
>> How hard do you think it would be to start/end the axis
>> on a minitic rather than a major tic if too large a
>> fraction of the range is wasted?
> 
> Starting the axis on a minitic is IMHO not the right solution.
> Lifting the limitation that in log axes only at integer powers of
> the base can currently be major tics is what really needs tackling.
> While at it, other axis re-mappings than pow()/log() should be made
> possible.
> 
> Unfortunately, that'd end up in having to essentially re-write the
> entire autoticking stuff from scratch.  James Van Zandt made a
> proposal for that a long time ago, but it never made it into serious
> discussion, let alone the CVS code.

I worked out a pretty good algorithm for selecting major and minor tic
locations for axes transformed by any continuous and either strictly
increasing or strictly decreasing function, such that:
 - tic labels are "simple"
 - tic labels do not overlap
 - the distances between tics are roughly equal
 - the numeric value corresponding to any minitic is unambiguous
 - the distances between minitics are roughly equal, and small enough
   that the numeric value of any point can be estimated by eye.

You can find standalone demo code and a couple of example plots at
http://jrv.oddones.org.

I need help integrating this into gnuplot - e.g. 
 - choosing command syntax for declaring a transformed axis
 - command parsing
 - evaluating the transformation function for chosen points
 - displaying both major and minor tics at arbitrary locations
(I found the user could choose locations for major tics but not minor
tics)
 - maintaining the current log axis algorithm in parallel, and
allowing the user to choose either for now.  

It's been two years since I worked on this.

	  - Jim Van Zandt

Re: [Docs] [Screenshots]

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

On Wednesday 18 May 2005 12:56 am, Petr Mikulik wrote:
> 
> 
> > But do we really have any screenshots other than the output of the
> > plot demos?
> 
> Yes, see the table at
> 	http://gnuplot.sourceforge.net/screenshots/

Ah yes, I'd forgotten about those.

I've updated that table slightly.
In particular I made a local copy of Bruce Ravel's emacs screenshot,
since the original site has moved.  But I added links to Bruce's site
as well as to Octave.org and so on.

I will also try to come up with a nice screenshot from one of the
web-based apps that uses gnuplot as a back end.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [Docs] [Screenshots]

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

> > 	http://gnuplot.sourceforge.net/screenshots/
>
> Instructions at
>   http://sourceforge.net/docman/display_doc.php?docid=25493&group_id=1

I see, there can be just up to 6 images.


> But do we really have any screenshots other than the output of the
> plot demos?

Yes, see the table at
	http://gnuplot.sourceforge.net/screenshots/

---
PM

Re: [Docs] [Screenshots]

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

On Tuesday 17 May 2005 08:11 am, Petr Mikulik wrote:
> At
> 	http://sourceforge.net/projects/gnuplot
> 
> there are [Docs] and [Screenshots] items. They should link to
> 	http://gnuplot.sourceforge.net/documentation.html

I thought this section was for people to contribute documentation,
much as the patches section was for people to contribute patches.
Some random poking around on other SourceForge projects failed to
turn up any examples of a project with a non-empty "docs" tab.
Many projects have removed this tab altogether, but I don't know
how they did it.

> and
> 	http://gnuplot.sourceforge.net/screenshots/

Instructions at 
  http://sourceforge.net/docman/display_doc.php?docid=25493&group_id=1

But do we really have any screenshots other than the output of the
plot demos?


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

[Docs] [Screenshots]

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

At
	http://sourceforge.net/projects/gnuplot

there are [Docs] and [Screenshots] items. They should link to
	http://gnuplot.sourceforge.net/documentation.html
and
	http://gnuplot.sourceforge.net/screenshots/

Could somebody organize this?

---
PM

Re: Compile error on Mac OS X

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> But I don't quite follow the distinction you are making.
> This is indeed a declaration, not a definition, at least as
> I understand the terms.  It looks like there are similar
> declarations in the TERM_PROTO sections of gd.trm, ggi.trm,
> linux.trm, and mif.trm. Do you want these moved as well? 

Yes.  To quote term/README:

The bit in the PROTO section is basically what you would put into a .h
file if we had them - everything that is needed by the TABLE_ENTRY
should be defined in this part. In particular, don't forget all the 
maxes and character sizes and things for the table entry.

Definitions don't belong in headers, so they don't belong into the 
TERM_PROTO section either.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Compile error on Mac OS X

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

On Sunday 15 May 2005 02:07 pm, you wrote:
>
> TERM_PROTO is for *declarations*, not for definitions.

OK, sorry.

But I don't quite follow the distinction you are making.
This is indeed a declaration, not a definition, at least as
I understand the terms.  It looks like there are similar
declarations in the TERM_PROTO sections of gd.trm, ggi.trm,
linux.trm, and mif.trm. Do you want these moved as well? 

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

Re: Compile error on Mac OS X

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

On Sunday 15 May 2005 11:31 am, Per Persson wrote:
> I'm on 10.4 now and the following change to post.h seems to fix the
> build problems:
>
> --- term/post.h 2 Mar 2005 19:44:57 -0000       1.7
> +++ term/post.h 15 May 2005 18:20:22 -0000
> @@ -85,6 +85,6 @@
> #define EPSLATEX_HCHAR (11*PS_SC*6/10)
> /* additional LaTeX header information for epslatex terminal */
> -extern char *epslatex_header;
> +TERM_PUBLIC char *epslatex_header;
> #endif /* TERM_POST_H */

It should be defined consistently, so please change it to 
TERM_PUBLIC in pslatex.trm also:

===========================================================================
--- gnuplot/term/pslatex.trm    2005-05-09 22:51:37.000000000 -0700
+++ gnuplot-cvs/term/pslatex.trm        2005-05-15 12:10:49.937075896 -0700
@@ -99,6 +99,9 @@
 TERM_PUBLIC void EPSLATEX_put_text __PROTO((unsigned int x, unsigned int 
y, const char *str));
 TERM_PUBLIC void EPSLATEX_linetype __PROTO((int linetype));

+/* additional LaTeX header information for epslatex terminal */
+TERM_PUBLIC char *epslatex_header = NULL;
+
 #endif /* TERM_PROTO */


@@ -116,9 +119,6 @@

 static struct pstex_text_command *pstex_labels = NULL;

-/* additional LaTeX header information for epslatex terminal */
-static char *epslatex_header = NULL;
-
 /* Common functions for epslatex and ps(la)tex */


===========================================================================

> Am I right in assuming that using the 'extern' qualifier in post.h,
> which will be pulled into term.c with the rest of the terminal stuff,
> was never strictly correct and that gcc 4.0 now returns an error?

It was never correct, insofar as this variable was never needed outside
of the terminal drivers.  But I don't see how gcc could know that.
gcc is just complaining that the two declarations, static and extern, 
are inconsistent.

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

Re: Compile error on Mac OS X

[Per P. <per...@ma...>]

On May 11, 2005, at 21:18, Hans-Bernhard Broeker wrote:

> Brendan Burns wrote:
>
>> In file included from term.h:400,
>>                  from term.c:1205:
>> ../term/pslatex.trm:120: error: static declaration of   
>> 'epslatex_header' follows non-static declaration
>> ../term/post.h:88: error: previous declaration of  
>> 'epslatex_header'  was here
>>
>
> That's strange --- this is usually just a warning, not an error.   
> Did GCC change its behaviour on this?
>
>
>> Changing
>> "static char *epslatex_header..." -> "char *epslatex_header..."  
>> in  pslatex.trm fixed the compile error.
>>
>
> It's quite probably the wrong direction of change, though.  Making  
> the declaration in post.h 'static' makes more sense.  Actually, it  
> should probably be TERM_PUBLIC, which evaluates to static.

I'm on 10.4 now and the following change to post.h seems to fix the  
build problems:

Index: term/post.h
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/term/post.h,v
retrieving revision 1.7
diff -u -d -b -w -r1.7 post.h
--- term/post.h 2 Mar 2005 19:44:57 -0000       1.7
+++ term/post.h 15 May 2005 18:20:22 -0000
@@ -85,6 +85,6 @@
#define EPSLATEX_HCHAR (11*PS_SC*6/10)
/* additional LaTeX header information for epslatex terminal */
-extern char *epslatex_header;
+TERM_PUBLIC char *epslatex_header;
#endif /* TERM_POST_H */


Am I right in assuming that using the 'extern' qualifier in post.h,  
which will be pulled into term.c with the rest of the terminal stuff,  
was never strictly correct and that gcc 4.0 now returns an error?

Should I commit this change?

/Per

Re: global pt

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

On Friday 13 May 2005 03:57 am, Hans-Bernhard Broeker wrote:
> Johannes Zellner wrote:
> > 
> > is it possible to set a global point type, e.g. pt 7 for all plots
> > w/o specifying it on the plot command line?
> 
> I don't think so.  That would have to be done by 'set style plot', in 
> the current setup, but such a command doesn't exist, nor do 'set style 
> data' or 'set style functions' extend to this.

I wonder if we could provide an option to cycle through line *styles*
rather than line *types* in successive plots.  This would allow you,
for instance, to set all line styles to use pt 7, and then issue plot
commands as usual.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: global pt

[Hans-Bernhard B. <br...@ph...>]

Johannes Zellner wrote:
> Hello,
> 
> is it possible to set a global point type, e.g. pt 7 for all plots
> w/o specifying it on the plot command line?

I don't think so.  That would have to be done by 'set style plot', in 
the current setup, but such a command doesn't exist, nor do 'set style 
data' or 'set style functions' extend to this.