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

Re: expanding allowed usage of word() command

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

On Sunday 09 November 2008, m sutton wrote:
> 
> > ----- Original Message -----
> > From: "Ethan A Merritt" <merritt@u.washington.edu>
> > To: gnu...@li...
> > Cc: "m sutton" <mw...@us...>, "Hans-Bernhard Bröker" <HBB...@t-...>
> > Subject: Re: expanding allowed usage of word() command
> > Date: Sat, 8 Nov 2008 09:30:53 -0700
> > 
> > 
> > On Saturday 08 November 2008, m sutton wrote:
> > > Hi all,
> > >
> > > I was trying to plot a single data file with multiple indexes.  I 
> > > want to plot some indexes with lines and some with points.  I 
> > > tried the following in a 4.3 CVS snapshot:
> > >
> > > list="points lines points"
> > > plot for [j=1:3] 'data' with word(list,j)
> > >
> > > I thought the word() command would be expanded much like it does 
> > > for title.  However it just results in an expecting error.
> > >
> > > Should the word() command be expanded in the above situation?  If 
> > > so, would that be difficult to implement?
> > 
> > There is still a fundamental difference between a keyword and
> > a string value.  Your failed command did get expanded, but the
> > expanded form is equivalent to
> >    plot 'data' with "points", '' with "lines", ...
> > 
> > which isn't a legal command.
> 
> 
> I put a few print statements in the code to see what was happening.  I added a print statement to f_words to see when the function was being called.  And to lookup_table to see what the current token was.  I change the commands to the following to force a call to f_words.  An the result shows that f_words is not called during the plot command call.
> 
> list="foo bar"
> print "word 1 = ". word(list,1)
> plot for [j=1:2] x with word(list,j)
> 
> 
> The results was the following
> 
> gnuplot> list="foo bar"
> gnuplot> print "word 1 = ". word(list,1)
> enter f_words
> word 1 = foo
> gnuplot> plot for [j=1:2] x with word(list,j)
> token = word
>                                      ^
>          expecting 'lines', 'points', 'linespoints', 'dots', 'impulses',
>         'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
>         'histeps', 'filledcurves', 'boxes', 'boxerrorbars', 'boxxyerrorbars',
>         'vectors', 'financebars', 'candlesticks', 'errorlines', 'xerrorlines',
>         'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
>          'image', 'rgbimage'
> 
> 
> I guess the real question is should the word() command be allowed to specify the with type?

You are asking for substitution of keywords, which is a somewhat different
process than the evaluation of string-valued functions.  There actually is
an existing  mechanism for macro-substitution, although it hasn't been 
re-examined in the context of iteration clauses.

I think the command you are aiming for is
    set macros
    plot for [style in "lines impulses"]  foo with @style title style

That almost works. Note that the clause
       with @style title style
expands the same user variable 'style' using two different mechanisms.
'title style' uses it as a string constant.
The macro @style is exanded to generate a string of lexical
tokens, which means that a keyword is an acceptable value.

The command as shown currently fails because the process of macro exansion
overwrites the original command line rather than preserving it.
That works fine for a one-shot use, but breaks when the command line is 
re-scanned for iterative execution. That may be fixable.

Bottom line:

1) It may be possible to do as you say, and add a special case to the 
parser so that if it fails to find a keyword after "with" it falls
back to attempting evaluation of a string-valued function that returns
a keyword.  This strikes me as very hack-ish and ugly, but perhaps we
can come up with a less hackish or more general form.

2) Alternatively, the macro expansion code can be updated to work
inside an iteration loop. 

I view the macro-expansion mechanism in gnuplot as being kind of a
failed experiment.  It was an early attempt to work around the lack of
string variables.  Now that gnuplot supports both string variables and
string-valued functions, there is not much need for the macro mechanism.
But this may be a case where it really would make sense to use it.


-- 
Ethan A Merritt

Re: expanding allowed usage of word() command

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: gnu...@li...
> Cc: "m sutton" <mw...@us...>, "Hans-Bernhard Bröker" <HBB...@t-...>
> Subject: Re: expanding allowed usage of word() command
> Date: Sat, 8 Nov 2008 09:30:53 -0700
> 
> 
> On Saturday 08 November 2008, m sutton wrote:
> > Hi all,
> >
> > I was trying to plot a single data file with multiple indexes.  I 
> > want to plot some indexes with lines and some with points.  I 
> > tried the following in a 4.3 CVS snapshot:
> >
> > list="points lines points"
> > plot for [j=1:3] 'data' with word(list,j)
> >
> > I thought the word() command would be expanded much like it does 
> > for title.  However it just results in an expecting error.
> >
> > Should the word() command be expanded in the above situation?  If 
> > so, would that be difficult to implement?
> 
> There is still a fundamental difference between a keyword and
> a string value.  Your failed command did get expanded, but the
> expanded form is equivalent to
>    plot 'data' with "points", '' with "lines", ...
> 
> which isn't a legal command.


I put a few print statements in the code to see what was happening.  I added a print statement to f_words to see when the function was being called.  And to lookup_table to see what the current token was.  I change the commands to the following to force a call to f_words.  An the result shows that f_words is not called during the plot command call.

list="foo bar"
print "word 1 = ". word(list,1)
plot for [j=1:2] x with word(list,j)


The results was the following

gnuplot> list="foo bar"
gnuplot> print "word 1 = ". word(list,1)
enter f_words
word 1 = foo
gnuplot> plot for [j=1:2] x with word(list,j)
token = word
                                     ^
         expecting 'lines', 'points', 'linespoints', 'dots', 'impulses',
        'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
        'histeps', 'filledcurves', 'boxes', 'boxerrorbars', 'boxxyerrorbars',
        'vectors', 'financebars', 'candlesticks', 'errorlines', 'xerrorlines',
        'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
         'image', 'rgbimage'



I guess the real question is should the word() command be allowed to specify the with type?

Mike Sutton



-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

Re: expanding allowed usage of word() command

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

On Saturday 08 November 2008, m sutton wrote:
> Hi all,
> 
> I was trying to plot a single data file with multiple indexes.  I 
> want to plot some indexes with lines and some with points.  I tried 
> the following in a 4.3 CVS snapshot:
> 
> list="points lines points"
> plot for [j=1:3] 'data' with word(list,j)
> 
> I thought the word() command would be expanded much like it does for 
> title.  However it just results in an expecting error.
> 
> Should the word() command be expanded in the above situation?  If so, 
> would that be difficult to implement?

There is still a fundamental difference between a keyword and 
a string value.  Your failed command did get expanded, but the
expanded form is equivalent to
  plot 'data' with "points", '' with "lines", ...

which isn't a legal command.

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

expanding allowed usage of word() command

[m s. <mw...@us...>]

Hi all,

I was trying to plot a single data file with multiple indexes.  I 
want to plot some indexes with lines and some with points.  I tried 
the following in a 4.3 CVS snapshot:

list="points lines points"
plot for [j=1:3] 'data' with word(list,j)

I thought the word() command would be expanded much like it does for 
title.  However it just results in an expecting error.

Should the word() command be expanded in the above situation?  If so, 
would that be difficult to implement?

Regards,

Mike Sutton


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.(ChangeLog Date 2008-11-07)

[Tatsuro M. <tma...@ya...>]

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.
(latest ChangeLog date: 2008-11-07)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Difference in greek tic marks for x11 and aqua?

[Dmitri A. S. <das...@gm...>]

On Thu, Nov 6, 2008 at 1:30 PM, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Monday 03 November 2008 10:46:32 Ethan Merritt wrote:
>> On Monday 03 November 2008 08:54:57 Dmitri A. Sergatskov wrote:
>>
>> But as I know understand it, your observation is that the command
>>    set xlabel "{/Symbol q}, radians" font <face,size>
>> does not change the initial font used by enhanced text processing.
>>
>> In other words, it should act equivalently to
>>     set xlabel "{/Helvetica=20 {/Symbol q}, radians}"
>> but it doesn't.
>>
>> Yes, the x11 terminal seems to behave differently that other terminals
>> in this regard, which is a bug.
>
> I have found two issues to be involved.
> One was purely a bug in the x11 terminal driver.
> That is now fixed in the cvs source for both 4.2 and 4.3

FWIW -- that seems to be working for me without any special workaround
mentioned below.

gnuplot> show encoding

	nominal character encoding is default
	however LC_CTYPE in current locale is en_US.UTF-8

xorg-x11-server-Xorg-1.5.0-2

>
> The other issue seems to be in the X-server itself.
> I have not pinned this down precisely, but my older machines behave
> different from the newer ones and I am wondering if it is a difference
> between xfree86 and x.org servers.  In any event, searches for some fonts
> (but not all) are now sensitive to the presence or absence of a specific
> requested encoding.  That is, a request for a generic font (encoding *-*)
> fails, but a request for the same font with encoding iso8859-1 succeeds.
> If you still see a problem with your plots, try setting
>    set encoding iso_8859_1
> before issuing the plot command (or other encoding as needed).
>
> It may be possible to fix this by changing the font request procedure
> in gnuplot_x11, but first I need to better understand the failure.
>
> --
> Ethan A Merritt
>

Thanks!

Dmitri.
--

Re: Difference in greek tic marks for x11 and aqua?

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

On Monday 03 November 2008 10:46:32 Ethan Merritt wrote:
> On Monday 03 November 2008 08:54:57 Dmitri A. Sergatskov wrote:
> 
> But as I know understand it, your observation is that the command
>    set xlabel "{/Symbol q}, radians" font <face,size>
> does not change the initial font used by enhanced text processing.
> 
> In other words, it should act equivalently to 
>     set xlabel "{/Helvetica=20 {/Symbol q}, radians}"
> but it doesn't.
> 
> Yes, the x11 terminal seems to behave differently that other terminals
> in this regard, which is a bug.

I have found two issues to be involved.
One was purely a bug in the x11 terminal driver.
That is now fixed in the cvs source for both 4.2 and 4.3

The other issue seems to be in the X-server itself.
I have not pinned this down precisely, but my older machines behave
different from the newer ones and I am wondering if it is a difference
between xfree86 and x.org servers.  In any event, searches for some fonts
(but not all) are now sensitive to the presence or absence of a specific
requested encoding.  That is, a request for a generic font (encoding *-*)
fails, but a request for the same font with encoding iso8859-1 succeeds.
If you still see a problem with your plots, try setting
    set encoding iso_8859_1
before issuing the plot command (or other encoding as needed).

It may be possible to fix this by changing the font request procedure
in gnuplot_x11, but first I need to better understand the failure.

-- 
Ethan A Merritt

Re: Difference in greek tic marks for x11 and aqua?

[Ben A. <bpa...@ma...>]

On Nov 3, 2008, at 4:07 PM, Ethan Merritt wrote:

> On Monday 03 November 2008 09:11:25 Dmitri A. Sergatskov wrote:
>> On Mon, Nov 3, 2008 at 10:54 AM, Dmitri A. Sergatskov
>> <das...@gm...> wrote:
>>
>>> set term x11 enh
>>> set xlabel "{/Symbol q}, radians" font "Helvetica, 20"
>>
>> If I use
>> set xlabel "radians" font "Helvetica, 20"
>>
>> insted -- everything works as expected...
>
> Yes, because that does not invoke the enhanced text mode.
>
> As I understand it at this moment, the problem is the font
> requested by the 'set ...' command is only applied to normal text,
> not to enhanced text.
>
> If a text string does not use any of the enhanced text markup
> characters, then it is handled by the normal text processing code.

A bit more information. When I try

	set xlabel "{/Symbol=20 q}, radians"  font "Times,20";

The "radians" is not 20pt.

Ben

Re: Difference in greek tic marks for x11 and aqua?

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

On Monday 03 November 2008 09:11:25 Dmitri A. Sergatskov wrote:
> On Mon, Nov 3, 2008 at 10:54 AM, Dmitri A. Sergatskov
> <das...@gm...> wrote:
> 
> >  set term x11 enh
> >  set xlabel "{/Symbol q}, radians" font "Helvetica, 20"
> 
> If I use
> set xlabel "radians" font "Helvetica, 20"
> 
> insted -- everything works as expected...

Yes, because that does not invoke the enhanced text mode.

As I understand it at this moment, the problem is the font 
requested by the 'set ...' command is only applied to normal text,
not to enhanced text.  

If a text string does not use any of the enhanced text markup
characters, then it is handled by the normal text processing code.


-- 
Ethan A Merritt

Re: Difference in greek tic marks for x11 and aqua?

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

On Monday 03 November 2008, Dmitri A. Sergatskov wrote:
> On Sat, Nov 1, 2008 at 7:20 PM, Ben Abbott <bpa...@ma...> wrote:
> > On Mac OSX, I noticed that the "aqua" and "x11" terminals give different
> > results when I add greek symbols to the axis tic marks *and* change the axes
> > fontsize.
> >
> > I've attached an "aqua" plot and the script I'm using to create the plots
> > for various terminals. I can't include the x11 bit map, as when I do a snap
> > shot, I get a blank bitmap. So I've included the plotstream for x11 instead.
> > Just type "gnuplot -persist plot-x11.gp" to have the plot rendered.
> >
> > In any event, for x11 the strings with greek letters always show up in the
> > default fontsize (10?).
> >
> > Can someone verify that the fontsize problem exists on Linux? ... and can
> > another Mac OSX user verify it exists for them as well?

I am not aware of any such problem in gnuplot, but without seeing the 
input commands I cannot comment on whether something may be incorrectly
specified to the program.  If you want to pursue this, please upload the
scripts to the Bug tracker on SourceForge:
   https://sourceforge.net/tracker/?atid=102055&group_id=2055

In general, gnuplot leaves font handling to the operating system.
So font problems probably indicate system configuration problems.

> 
> I suggest posting this to <gnu...@li...>.
> 
> The only way i can change fonts in x11 is by:
> 
> set term x11 enhanced "Helvetica, 20"
> 
> or similar. More over -- i suspect there is no true "Helvetica" fonts
> for x11, so it does some kind of substitution.

# xlsfonts | grep -i helv | wc
    320     320   19172

On my machine x11 offers 320 variants of helvetica, some from Adobe
and others from URW.

> Setting  fonts in [x,y]labels etc does not make any effect.

I can guarantee that this works correctly inside gnuplot.
Of course, if your system doesn't really have those fonts installed.....

> I am not sure if it is a bug in octave or just a feature of x11 terminal.

I suspect it is neither, but instead an issue with the local system
font configuration.

-- 
Ethan A Merritt

Re: Difference in greek tic marks for x11 and aqua?

[Dmitri A. S. <das...@gm...>]

On Mon, Nov 3, 2008 at 10:54 AM, Dmitri A. Sergatskov
<das...@gm...> wrote:

>  set term x11 enh
>  set xlabel "{/Symbol q}, radians" font "Helvetica, 20"

If I use
set xlabel "radians" font "Helvetica, 20"

insted -- everything works as expected...

Dmitri.
--

Re: Difference in greek tic marks for x11 and aqua?

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

On Monday 03 November 2008 08:54:57 Dmitri A. Sergatskov wrote:
> On Mon, Nov 3, 2008 at 10:11 AM, Ethan A Merritt
> <merritt@u.washington.edu> wrote:
> 
> > I can guarantee that this works correctly inside gnuplot.
> > Of course, if your system doesn't really have those fonts installed.....
> >
> >> I am not sure if it is a bug in octave or just a feature of x11 terminal.
> >
> > I suspect it is neither, but instead an issue with the local system
> > font configuration.
> >
> 
> Ataached are two snapshots. First is the result of
> 
>  set term x11 enh
>  set xlabel "{/Symbol q}, radians" font "Helvetica, 20"
>  plot sin(x)

Aha.
What a difference it makes to see what you are actually trying to do :-)
I mis-understood the original description.  Sorry.

I thought you were trying to get a different size font for the
symbol as compared to the rest of the text, as in:
   set xlabel "{/Symbol=20 q}, radians" 

This works fine in both gnuplot 4.2 and cvs.

But as I know understand it, your observation is that the command
   set xlabel "{/Symbol q}, radians" font <face,size>
does not change the initial font used by enhanced text processing.

In other words, it should act equivalently to 
    set xlabel "{/Helvetica=20 {/Symbol q}, radians}"
but it doesn't.

Yes, the x11 terminal seems to behave differently that other terminals
in this regard, which is a bug.

The command variant above demonstrates a work-around 
to use for 4.2 and current cvs.

	thanks for the report

-- 
Ethan A Merritt

Re: Difference in greek tic marks for x11 and aqua?

[Dmitri A. S. <das...@gm...>]

On Mon, Nov 3, 2008 at 10:11 AM, Ethan A Merritt
<merritt@u.washington.edu> wrote:

> I can guarantee that this works correctly inside gnuplot.
> Of course, if your system doesn't really have those fonts installed.....
>
>> I am not sure if it is a bug in octave or just a feature of x11 terminal.
>
> I suspect it is neither, but instead an issue with the local system
> font configuration.
>

Ataached are two snapshots. First is the result of

 set term x11 enh
 set xlabel "{/Symbol q}, radians" font "Helvetica, 20"
 plot sin(x)

The second one is the result of

 set term x11 enh font "Helvetica, 20"
 set xlabel "{/Symbol q}, radians"
 plot sin(x)

This is with few days old cvs snapshot of gnuplot on fedora 9

[...]$ xlsfonts | grep -i helv | wc
     96      96    6010


> --
> Ethan A Merritt
>

Sincerely,

Dmitri.
--

Re: Difference in greek tic marks for x11 and aqua?

[Dmitri A. S. <das...@gm...>]

On Sat, Nov 1, 2008 at 7:20 PM, Ben Abbott <bpa...@ma...> wrote:
> On Mac OSX, I noticed that the "aqua" and "x11" terminals give different
> results when I add greek symbols to the axis tic marks *and* change the axes
> fontsize.
>
> I've attached an "aqua" plot and the script I'm using to create the plots
> for various terminals. I can't include the x11 bit map, as when I do a snap
> shot, I get a blank bitmap. So I've included the plotstream for x11 instead.
> Just type "gnuplot -persist plot-x11.gp" to have the plot rendered.
>
> In any event, for x11 the strings with greek letters always show up in the
> default fontsize (10?).
>
> Can someone verify that the fontsize problem exists on Linux? ... and can
> another Mac OSX user verify it exists for them as well?
>

I suggest posting this to <gnu...@li...>.

The only way i can change fonts in x11 is by:

set term x11 enhanced "Helvetica, 20"

or similar. More over -- i suspect there is no true "Helvetica" fonts
for x11, so it does some kind of substitution.
Setting  fonts in [x,y]labels etc does not make any effect.

I am not sure if it is a bug in octave or just a feature of x11 terminal.

> Ben
>

Regards,

Dmitri.

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated. (ChangeLog Date 2008-11-01)

[Tatsuro M. <tma...@ya...>]

Hello

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.
(latest ChangeLog date: 2008-11-01)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Terminal: when does pm3d start and end?

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

On Thursday 30 October 2008, Christoph Bersch wrote:
> is there any possibility for a terminal driver to know within the 
> _filled_polygon() function when the first and last polygon of a surface 
> are drawn?

CVS code:

The routine term->layer(TERM_LAYER_BEFORE_PLOT) is called at the
start of each clause within the 'plot' or 'splot' command. So a
terminal driver could, if needed, set an internal flag when it 
receives this call and then term->filled_polygon() could test and
clear it after the first call.  

There is a corresponding call to term->layer(TERM_LAYER_AFTER_PLOT)
 at the end.  This is, of course, *after* the last polygon but if
it's a question of having the terminal do some cleanup at the end
then this should be sufficient.

-- 
Ethan A Merritt

Terminal: when does pm3d start and end?

[Christoph B. <us...@be...>]

Hi,

is there any possibility for a terminal driver to know within the 
_filled_polygon() function when the first and last polygon of a surface 
are drawn?

Thanks,
Christoph

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated

[Tatsuro M. <tma...@ya...>]

Hello

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.
(latest ChangeLog date: 2008-10-27)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards

Tatsuro

--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: iterate evaluate

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

On Sunday 26 October 2008, Ethan A Merritt wrote:

> Anyhow, getting back to the original question,
>  set for [i=1:N] cntrparam levels discrete <foo>
> should act analogously to the first form of the iterated 'set xtics' above.
> It should all by itself do the initial clear and subsequent implicit "add".

Applied to cvs.  It was a one-line change.

   if (!iteration) {
      ... clear and initialize list of contour levels ...
   }


-- 
Ethan A Merritt

Re: iterate evaluate

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

On Sunday 26 October 2008, Juergen Wieferink wrote:
> In my opinion it's more natural to put the
> 'for' right before the 'set' command:
> 
> for [i=1:10] set xtics add ("label" POSITION)

That is a logical syntax, but I would wager that users will immediately
assume that 
  for [i=1:N] ....
can be placed in front of any command (not just "set").
In fact maybe it _should_ apply to any command, but as of now it doesn't.

Furthermore, there is a logical difference between the two forms, as easily
seen for "plot", because
  for [i=1:N] plot ...
would create N separate plots, whereas
  plot [i=1:N] ...
creates 1 plot with N lines on it.

I now remember that "set for [i=1:N] xtics <foo>" makes this same distinction.
Because the iteration is _inside_ the set command, it is not required to explicitly
say "add".  So the two commands below (2nd is only hypothetical) are equivalent:

  set for [i=1:N] xtics (label(i), i)
  set xtics (); for [i=1:N] set xtics add (label(i), i)

The second (hypothetical) form requires both that you manually clear the list
initially and that subsequent list entries contain an explicit "add" keyword.
The first form (currently implemented) does both for you automatically.

Anyhow, getting back to the original question,
 set for [i=1:N] cntrparam levels discrete <foo>
should act analogously to the first form of the iterated 'set xtics' above.
It should all by itself do the initial clear and subsequent implicit "add".


-- 
Ethan A Merritt

Re: iterate evaluate

[Juergen W. <wie...@fr...>]

> How about a patch to allow
>    set cntrparam levels discrete add <foo>
> similar to the existing option
>    set xtics add ("label" POSITION)

This would make sense.

Something different: In my opinion it's more natural to put the
'for' right before the 'set' command:

for [i=1:10] set xtics add ("label" POSITION)

The iteration feature would still have to be recursivly callable,
though.  This could be done by an iteration context (or ID) which is
returned by check_iteration() and possibly cleaned along with

	load_file_error();	/* if we were in load_file(), cleanup */
	reset_eval_depth();     /* reset evaluate command recursion counter 
*/

in plot.c.

Maybe I just file a feature request and we will see if anyone is
interested.


Juergen

Re: gnuplot version history question

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

On Sat, 25 Oct 2008, Ethan A Merritt wrote:

> RGB colorspecs of the form rgb "#ff0000" were added to CVS in 
> December 2004. The keyword "lc" was added in March 2005.
> 
> The first official release supporting RGB colors was 4.2,
> 4.2-rc1  - Oct 2006
> 4.2.0    - Mar 2007

Thank you, Ethan, that's very helpful.  

Allin Cottrell

Re: gnuplot version history question

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

On Saturday 25 October 2008, Allin Cottrell wrote:
> Can anyone tell me, what was the earliest gnuplot version that 
> would accept a command of the form
> 
> set style line 1 lt 6 lc rgb "#ff0000"
> 
> ?  Thanks very much.

RGB colorspecs of the form   rgb "#ff0000" were added to CVS in December 2004.
The keyword "lc" was added in March 2005.

The first official release supporting RGB colors was 4.2,
4.2-rc1  - Oct 2006
4.2.0    - Mar 2007


-- 
Ethan A Merritt

gnuplot version history question

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

Can anyone tell me, what was the earliest gnuplot version that 
would accept a command of the form

set style line 1 lt 6 lc rgb "#ff0000"

?  Thanks very much.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: special behavior of postscript terminal? (again)

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

On Thu, 23 Oct 2008, Ethan Merritt wrote:

> We made a concerted effort for 4.2 to bring the sequence of 
> point types into conformity across terminals.  So far as I 
> recall, no one argued for doing the same to dash patterns. I 
> have no objections to someone offering a series of patches that 
> re-orders the sequence of dash patterns to achieve some level of 
> cross-terminal agreement.

Since I haven't yet looked into the code in detail on this point 
I'm somewhat in the dark.  But what I had (vaguely) in mind was 
some sort of analogue to the way in which one can now force colors 
on "line styles" in a consistent, more or less 
terminal-independent, manner.  Could one force a consistently 
enumerated set of dash-patterns using "set style line dt"?

If so, that would avoid disrupting time-honored per-terminal 
default patterns.  You could stay with the defaults if you like, 
or if you're interested in cross-terminal compatibility you could 
define a set of line styles including dash-types.  (?)

Allin Cottrell