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

Re: Requesting a webpage update

[M S. <ms...@my...>]

On Tuesday 23 November 2004 03:46, Petr Mikulik wrote:

> >  As some of you are probably aware, I have created a fortran95 interface
> > to Gnuplot. Please add the following URL :
> >
> >  http://gnuplotfortran.sourceforge.net/
> >
> >  to the Gnuplot webpage at :
> >
> >  http://gnuplot.sourceforge.net/links.html
> >
> >  under Programming Interfaces.
>
> Done.
>

Thanks !!

Re: Requesting a webpage update

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

>  As some of you are probably aware, I have created a fortran95 interface to
> Gnuplot. Please add the following URL :
>
>  http://gnuplotfortran.sourceforge.net/
>
>  to the Gnuplot webpage at :
>
>  http://gnuplot.sourceforge.net/links.html
>
>  under Programming Interfaces.

Done.

---
PM

Requesting a webpage update

[M S. <ms...@my...>]

Hi

 As some of you are probably aware, I have created a fortran95 interface to 
Gnuplot. Please add the following URL :

 http://gnuplotfortran.sourceforge.net/

 to the Gnuplot webpage at :

 http://gnuplot.sourceforge.net/links.html

 under Programming Interfaces.

Thanks,

MS

Re: no mirroring to www.gnuplot.info

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

Mirroring of gnuplot.sf.net to www.gnuplot.info does not work -- cf. pages
from October/November to those of May.

Who is maintaining www.gnuplot.info?
Could he restart the mirroring?

---
PM

Feature Request: Logarithmic t in parametric plots

[Christopher K. <cj...@ca...>]

Hi,

Apologies if there is already an easy way to achieve the following.

What I'm looking for is the ability to specify that the values of t for 
which x,y should be evaluated should increase logarithmically.  Even more 
useful would be the ability to do this over a range spanning from negative 
to postive aswell, e.g. -100, -10, -1, -0.1, -0.01, 0.01, 0.1, 1, 10, 100. 
Another refinement would be the ability to loop through infinity, rather 
than zero, i.e. -0.01, -0.1, -1, -10, -100, 100, 10, 1, 0.1, 0.01.

This would be particularly useful for plotting Nyquist plots, where one 
needs to plot a complex function of w, for -inf < w < inf.  If a linear 
range is used, then an awful lot of samples need to be taken to get a smooth 
curve in the regions of low w.

I'm, not sure how best this could be implemented, but one solution might be 
to add three options:

(un)set logparametric:      Instructs gnuplot to take samples of t at 
logarithmic intervals (identical to setting x axis to logarithmic in 
behaviour).

(un)set logparametricnegative      Instructs gnuplot to mirror the samples 
of t to include negative values aswell.

(un)set logparametricthroughinf      Tells gnuplot to order the samples of t 
such that they start and finish at +-0, looping through inf as opposed to 
starting and finishing at +-inf and looping through 0.


Any thoughts on whether this might be achievable?

Many thanks,

Chris Key

Re: FC3 and odds and ends

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

On Tue, 16 Nov 2004, Daniel J Sebald wrote:

> Here's an observation or two.  I notice at the command line that the 
> help notice says
> 
> [sebald@localhost ~]$ gnuplot --help
> Usage: gnuplot [OPTION]... [FILE]
> for X11 options see 'help X11->command-line-options'
> 
> However, if one types "help X11" inside gnuplot, the subtopics do not 
> get listed.  However, typing "help x11" does cause subtopics to be listed.

Looks like incomplete help entries in the X11 alternative name for the x11 
driver.  I suggest changing the --help text to lower-case x11.

> Also, the background of an X11 image doesn't come out as white unless I 
> explicitly launch gnuplot as
> 
> [~]$ gnuplot -background white

That would usually be the result of the X resources database containing a
generic *background entry that sets the background to something else than
white.  SuSE linux does that, too, IIRC.  You'll have to query xrdb to get
all the fine details.

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

FC3 and odds and ends

[Daniel J S. <dan...@ie...>]

Just finished upgrading my system to Fedora Core 3.  Some observations...

Basically, gnuplot works very well.  (gnuplot 4.0 is on FC3)  CVS 
gnuplot compiles without problems.  FC3 deserves little fanfare, but I 
would say that the performance of X11 from RH7 to FC3 deserves a "wow!"  
The images have a great antialiasing effect and the speed is amazingly 
improved.  Even the polygon approximations seems to resize fairly fast.  
Very slick.


Here's an observation or two.  I notice at the command line that the 
help notice says

[sebald@localhost ~]$ gnuplot --help
Usage: gnuplot [OPTION]... [FILE]
for X11 options see 'help X11->command-line-options'

However, if one types "help X11" inside gnuplot, the subtopics do not 
get listed.  However, typing "help x11" does cause subtopics to be listed.

Also, the background of an X11 image doesn't come out as white unless I 
explicitly launch gnuplot as

[~]$ gnuplot -background white

otherwise it seems to be the default "grey" them color, which is 
slightly lighter than the "-background grey" option.  I'll investigate 
when I have time.

Dan

no mirroring to www.gnuplot.info

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

It looks to me that mirroring of gnuplot.sf.net to www.gnuplot.info does not
work (cf. pages from October/November to those of May). Could somebody
restart this service?

---
PM

Re: key patch update

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

On Tuesday 09 November 2004 06:06 pm, Daniel J Sebald wrote:
> One thing that threw me in the plot--that made me not conclude the key 
> samples should be associated with each cluster of bars--is the fact that 
> it is one key.  Wouldn't you prefer multiple boxed keys?  Say as in the 
> mock up:
> 
> http://acer-access.com/~ds...@ac.../gnuplot/sample_2_keys.png

Absolutely! That would be great.  I had been fumbling my way towards
recoding the key layout so that it was generic, and then allowing multiple
keys.  My intent was to modify the 'set key' command to:
    set key {<n>} ...
And allow each plot to specify which key it's title was placed in:
    plot 'foo' with lines key 1, 'bar' with lines key 2, 'blech' key 1

> My guess is that programming multiple keys wouldn't be too bad. 
>  However, the syntax would be something tricky.  Perhaps:
> 
> set key <...>
> set key 1 <...>
> set key 2 <...>
> unset key 2 <...>
> 
> These are the sorts of commands for declaring multiple keys.  (The "set 
> key" without a number is the same as "set key 1".)
> 
> But the big question is how does one make a connection between what is 
> on the plot and how it ends up in the key?  Maybe:
> 
> plot 'this.file" u 1:2 key 1, 'this.file' u 1:3 k 1, 'that.file' u 1:2 
> key 2, 'that.file' u 1:3 k 2

You and I are on the same wavelength on this one.
I wasn't progressing very fast on the project, however.
Mostly I had just been trying to collect all the variables having to
do with the key layout into a single structure, so that later on I
could have multiple such structures to support multiple keys.
That was a while ago.  I got sidetracked by the string variables
code.



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

Re: key patch update

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> plot 'this.file" u 1:2 key 1, 'this.file' u 1:3 k 1, 'that.file' u 1:2 
> key 2, 'that.file' u 1:3 k 2
>
> Good?  Bad?


And I'd say that to get the keys in three different locations under the 
bar clusters would require manual placement of all keys.  Otherwise, if 
all were specified as "under" then they'd land on top of one another.

Dan

Re: key patch update

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Tuesday 09 November 2004 03:57 pm, Daniel J Sebald wrote:
>  
>
>>Something else I've noticed about the way the key is laid out...  If you 
>>look at the last example of the histograms, you'll see that the sample 
>>length (i.e., samplen) is constant for all columns.  In some ways that 
>>looks nice, but in some ways it also uses a lot of space.  That is, the 
>>"United Kingdom" entry determines the width of _every_ column.  I wonder 
>>how it would look if the default, non-samplen-specified layout would 
>>allow those columns to vary, so that the Denmark/Norway column etc were 
>>moved over.
>>    
>>
>
>We must not lose track of the most important point, however, which is
>that the caption is supposed to match the figure.  In the ideal case
>for histograms like this one, I would want each column of the key to
>start exactly under the corresponding set of histograms.  At the very
>least I would like a guarantee that if the histograms come in sets of,
>say, 3+2+3 then the key columns also contain 3, 2, and 3 entries
>correspondingly.
>

Oh!  Now I see why the X11 example, which is a 2 x 5 key, has the 
strange space at locations (2,2) and (2,4).  I wasn't aware it was 
supposed to work that way.

>>The modified key at first seems rather difficult, but perhaps not. 
>> Rather than algrebra, an exhaustive attempt at layout could be done. 
>> Of course, I don't think we want a complete exhaustive search in that 
>>we could rearrange the order of the key entries.  (Although I bet 
>>something creative could be done whereby one first orders the key 
>>samples by width... but .)  Rather, one would begin by attempting to put 
>>all samples on a row (column).  If they don't fit, then one starts there.
>>    
>>
>
>If you can figure out a smarter automatic method, great.
>But I'd settle for the much simpler alternative of some flag that
>forces a column break.   In the case of histograms, I'd like the
>"newhistogram" command to force such a column break.  In the general
>case there would have to be some user-accessible flag or option.
>Maybe
>	set key columns=(3,3,2)
>which means generate a new column after the 3rd, 6th, and 8th entries.
>This would need some further thought.  Does one count or not count
>plots with 'notitle'?
>

Well, this is interesting.  I'd say I'm not completely sold on the idea 
of having the key behave uniquely different for the plot style of 
grouped histograms.  So, some way of controlling the key seems in order; 
something general.

One thing that threw me in the plot--that made me not conclude the key 
samples should be associated with each cluster of bars--is the fact that 
it is one key.  Wouldn't you prefer multiple boxed keys?  Say as in the 
mock up:

http://acer-access.com/~ds...@ac.../gnuplot/sample_2_keys.png

Would it be easier to program something allowing multiple keys rather 
than the grouping or clustering of columns within a single key?  With 
that, one could plot things in groups, whether it be histograms, lines, 
etc.

My guess is that programming multiple keys wouldn't be too bad. 
 However, the syntax would be something tricky.  Perhaps:

set key <...>
set key 1 <...>
set key 2 <...>
unset key 2 <...>

These are the sorts of commands for declaring multiple keys.  (The "set 
key" without a number is the same as "set key 1".)

But the big question is how does one make a connection between what is 
on the plot and how it ends up in the key?  Maybe:

plot 'this.file" u 1:2 key 1, 'this.file' u 1:3 k 1, 'that.file' u 1:2 
key 2, 'that.file' u 1:3 k 2

Good?  Bad?

Dan

Re: key patch update

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

On Tuesday 09 November 2004 03:57 pm, Daniel J Sebald wrote:
> 
> Something else I've noticed about the way the key is laid out...  If you 
> look at the last example of the histograms, you'll see that the sample 
> length (i.e., samplen) is constant for all columns.  In some ways that 
> looks nice, but in some ways it also uses a lot of space.  That is, the 
> "United Kingdom" entry determines the width of _every_ column.  I wonder 
> how it would look if the default, non-samplen-specified layout would 
> allow those columns to vary, so that the Denmark/Norway column etc were 
> moved over.

We must not lose track of the most important point, however, which is
that the caption is supposed to match the figure.  In the ideal case
for histograms like this one, I would want each column of the key to
start exactly under the corresponding set of histograms.  At the very
least I would like a guarantee that if the histograms come in sets of,
say, 3+2+3 then the key columns also contain 3, 2, and 3 entries
correspondingly.

> The modified key at first seems rather difficult, but perhaps not. 
>  Rather than algrebra, an exhaustive attempt at layout could be done. 
>  Of course, I don't think we want a complete exhaustive search in that 
> we could rearrange the order of the key entries.  (Although I bet 
> something creative could be done whereby one first orders the key 
> samples by width... but .)  Rather, one would begin by attempting to put 
> all samples on a row (column).  If they don't fit, then one starts there.

If you can figure out a smarter automatic method, great.
But I'd settle for the much simpler alternative of some flag that
forces a column break.   In the case of histograms, I'd like the
"newhistogram" command to force such a column break.  In the general
case there would have to be some user-accessible flag or option.
Maybe
	set key columns=(3,3,2)
which means generate a new column after the 3rd, 6th, and 8th entries.
This would need some further thought.  Does one count or not count
plots with 'notitle'?


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

Re: key patch update

[Daniel J S. <dan...@ie...>]

Ethan,

(I'm including the list to see what others think.)

Something else I've noticed about the way the key is laid out...  If you 
look at the last example of the histograms, you'll see that the sample 
length (i.e., samplen) is constant for all columns.  In some ways that 
looks nice, but in some ways it also uses a lot of space.  That is, the 
"United Kingdom" entry determines the width of _every_ column.  I wonder 
how it would look if the default, non-samplen-specified layout would 
allow those columns to vary, so that the Denmark/Norway column etc were 
moved over.

I've put your original sample_2.png and a mock-up using GIMP 
(sample_2_mod.png) at:

http://acer-access.com/~ds...@ac.../gnuplot/sample_2.png
http://acer-access.com/~ds...@ac.../gnuplot/sample_2_mod.png

Right now, I think the gnuplot code computes the maximum width of a 
sample entry, treats that as though it were a user supplied sample 
width, then does some algrebra to compute what the number of rows and 
columns of the key should be.

The modified key at first seems rather difficult, but perhaps not. 
 Rather than algrebra, an exhaustive attempt at layout could be done. 
 Of course, I don't think we want a complete exhaustive search in that 
we could rearrange the order of the key entries.  (Although I bet 
something creative could be done whereby one first orders the key 
samples by width... but .)  Rather, one would begin by attempting to put 
all samples on a row (column).  If they don't fit, then one starts there.

Say only the first four fit.  Then try a key with four columns, and if 
after going through expanding the columns with wider samples when 
appropriate the overall width still fits within the plot width, then 
done.  Otherwise, reduce the key to three columns and try again.  If it 
fails, reduce, etc.  It isn't the most efficient, but I think that even 
with, say 20 or 30 entries, it would be efficient.  It's a probabilistic 
sort of thing, but if the sample widths are very wide then the routine 
would start from a small column number and finish quickly.  If the 
sample widths are very narrow, then the algorithm should find a fit in a 
short amount of time.  The worst case senario would be if the traces 
were labeled "a", "b", "c", ...., "very long for some strange reason 
that can't be explained".

Dan

Re: key patch update

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

On Monday 08 November 2004 11:06 pm, Daniel J Sebald wrote:
> >Why not add it to cvs earlier if more people agree?

I like it.
There is one issue I am unhappy about, but it was not
introduced by this patchset.  

The centering algorithm for "set key under" is very
fragile, and sometimes comes out horribly wrong.  See,
for instance, the last plots in histograms.dem.
On X11 with font "verdana,11" the key is more or less OK,
although not perfectly centered.
But with 'set term png font "verdana" 11'  (same font)
the centering is very wrong.

Any chance that while this code is still fresh in your
mind, you could have another look at the centering
algorithm?  Feel free to rip out any of my previous
tweaks, since clearly they are not working reliably.

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

Re: key patch update

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:

>>I updated the key patch and demo.  The demo is in PDF format at
>>
>>http://acer-access.com/~ds...@ac.../gnuplot/key.pdf
>>
>>The layout of the plot could use small changes here or there, but this
>>should be a good first step toward cleanup.
>>    
>>
>
>I like it, it provides a consistent syntax.
>
>  
>
>>I'll let it sit for a few months to see what people think.
>>    
>>
>
>Why not add it to cvs earlier if more people agree?
>

 From what I recall, originally one issue Hans raised was that I used 
JUSTIFY/VERT_JUSTIFY with the hope of changing that to something 
consistent like H_JUSTIFY/V_JUSTIFY.  But he suggested not doing that 
because the so large number of occurrences of JUSTIFY.  I changed it to 
what he suggested, a GPKEY_HORIZONTAL, GPKEY_VERTICAL, etc.

That is where it was before this small update I made.  I remember really 
cleaning up the key layout nicely, at least in 2D plots.  So I think 
moving it into CVS would be alright, and perhaps a good idea at this time.

I probably didn't do as nice a job in 3D because I'm anticipating a 
discussion at some point at how to make key, color bar, nice 3D borders 
(Hans' favorite), and general layout that is consistent between 2D and 
3D plots (i.e., code reuse).  Part of that debate would be whether to 
hold that off until after a 4.1 version, because there have already been 
so many changes since 4.0.  I'll leave that up to the rest because it 
sounded like a lot of work to create and publish a version.  (What I 
mean is unifying 2D/3D layout might be upsetting the apple cart a bit to 
much if other items have priority.)

Dan

Re: Bug for X11?: How to make Gnuplot not to grab X selection

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

On Fri, 29 Oct 2004 pa...@mi... wrote:

> I found out that the gnuplot has a feature (bug?) that on a normal
> operation under plot or replot <SOMETIMES> grabs the X11 selection
> buffer.

IIRC, it's actually always grabbing it, not just sometimes.

To turn this off, you need a recompile of at least gnuplot_x11,
with -DNOEXPORT=1 passed to the compiler.

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

Re: (no subject)

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

On Fri, 29 Oct 2004 em...@ru... wrote:

> My thought (without having delved deeply into the source code, I must
> admit) is to give the user one more type of scale much like logscale
> which they can select.  

You're thinking too narrowly there.

What we need here is a broader approach at not just this particular
re-mapping idea, but the entire general concept of "translated axes".  So
far, gnuplot supports two such translations: identity and logarithm.  
Extending this to general mapping functions has been discussed in the past
(I think under a heading like "generalized log axes"), but AFAIK no
implementation has ever been attempted.

In principle, what is needed is a pair of functions, which are inverses of
each other, so gnuplot can map from data coordinates to 'plotted
coordinates' for placing things, and also from plotted coordinates back to
data coordinates for jobs like auto-ticking and mouse feedback.  The
mappings have to be monotonous, or all hell would break loose, and for
this feature to be more than an isolated special-purpose tool, the
mappings have to be specifiable as user-defined functions, e.g.

	set scale x1  sin(x1), asin(x1)

There's a ton of questions to be answered before this can be implemented,
mostly revolving about how to code an automatic range fix-up and automatic
tick placement algorithm that work somewhat robustly in such a generalized
situation.  As a first step towards that, we need a re-design of the
auto-ticking algorithm that makes them behave reasonably in the face of
short-range log axes.

For the time being, you'll just have to re-map coordinates on the go and
place xtics with 'faked' numbers, as demonstrated by earlier replies.

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

Re: gp2tex

[Sebastian H. <seb...@gm...>]

On Monday 08 November 2004 10:49, Petr Mikulik wrote:
> > On your webpage there is a link to the attached script. The link s broken
> > but the author mailed me the script. Maybe you can host it on
> > gnuplot.info
>
> Fine, I have put the "gp2tex.pl" there.
>
> Actually, it does convert columns of a data file into LaTeX tables (not
> necessarily data file that only gnuplot can read). I think that a more
> appropriate name is "dat2latex.pl". What do you think about this rename?
Go ahead. Sounds okay to me.
>
> ---
> PM

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://sebastian-hi...@we...
My OS: Suse Linux. Geek by Nature, Linux by Choice

Re: gp2tex

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

> On your webpage there is a link to the attached script. The link s broken but
> the author mailed me the script. Maybe you can host it on gnuplot.info

Fine, I have put the "gp2tex.pl" there.

Actually, it does convert columns of a data file into LaTeX tables (not
necessarily data file that only gnuplot can read). I think that a more
appropriate name is "dat2latex.pl". What do you think about this rename?

---
PM

Re: key patch update

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

> I updated the key patch and demo.  The demo is in PDF format at
>
> http://acer-access.com/~ds...@ac.../gnuplot/key.pdf
>
> The layout of the plot could use small changes here or there, but this
> should be a good first step toward cleanup.

I like it, it provides a consistent syntax.

> I'll let it sit for a few months to see what people think.

Why not add it to cvs earlier if more people agree?

---
PM

key patch update

[Daniel J S. <dan...@ie...>]

I updated the key patch and demo.  The demo is in PDF format at

http://acer-access.com/~ds...@ac.../gnuplot/key.pdf

The layout of the plot could use small changes here or there, but this 
should be a good first step toward cleanup.  I'll let it sit for a few 
months to see what people think.

Dan

Re: multiplot doc spelling errors

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:

>>Also, I notice in this documentation that
>>?nomultiplot
>>is a means to access this text.  Perhaps all the cases of
>>?no<keyword>
>>that appear in gnuplot.doc can be moved under the same heading
>>?nomultiplot
>>?noarrow
>>etc.
>>    
>>
>
>Enclosed is a patch that moves all this "?no" into the section of "What's
>new in 4.0" => "3 Other changes and additions". Do you like it?
>

Conceptually I like it.  But looking at the code a bit, I see that 
"no<>" is handled not as an individual command (or more accurately, a 
whole bunch of individual commands), but rather is handled in a special way:

    } else if (input_line[token[c_token].start_index] == 'n' &&
           input_line[token[c_token].start_index+1] == 'o') {
    if (interactive)
        int_warn(c_token, "deprecated syntax, use \"unset\"");
    token[c_token].start_index += 2;
    token[c_token].length -= 2;
    c_token--;
    unset_command();

[By the way, the "deprecated syntax" warning gets printed even if the 
associated keyword is not a valid one.  Everyone's OK with that? 
 Putting the warning after the call to "unset_command()" might fix that 
because unset_command() should break out if there is an error.]

This means that even as new keywords get added to gnuplot, say "foo", 
something like "nofoo" will work for "unset foo".  But, that means it is 
difficult for someone to anticipate having to add "nofoo" to the list of 
items in the "gnuplot.doc" file.  In other words, the list

-
+?noarrow
+?noautoscale
+?noborder
+?noclip
+?nocontour
+?nodgrid3d
+?nogrid
+?nohidden3d
+?nohistorysize
+?nokey
+?nolabel
+?nologscale
+?nomouse
+?nomultiplot
+?nomx2tics
+?nomxtics
+?nomy2tics
+?nomytics
+?nomztics
+?nooffsets
+?noparametric
+?nopolar
+?nosurface
+?notimestamp
+?nox2dtics
+?nox2mtics
+?nox2tics
+?nox2zeroaxis
+?noxdtics
+?noxmtics
+?noxtics
+?noxzeroaxis
+?noy2dtics
+?noy2mtics
+?noy2tics
+?noy2zeroaxis
+?noydtics
+?noymtics
+?noytics
+?noyzeroaxis
+?nozdtics
+?nocbdtics
+?nozmtics
+?noztics
+?nocbmtics
+?nocbtics


is always going to be an insufficient list to cover all the uses of 
"no<>".  As an alternative, if you prefer, I've attached a patch with a 
small mod to "help.c" to map any "no<>" to "no deprecated", and then in 
gnuplot.doc I put a "no deprecated to unset" in place of all the 
keywords listed above.  (Change the heading "no deprecated to unset" if 
you like.)

[Of course, with my BTW comment above, the patch I've supplied will 
print out the "no deprecated to unset" help for "help nojunkeroo" and 
such.  A bit hypocritical I guess, but I think that is tolerable.  I 
could easily modify it so that "no" is stripped off the keyword, then a 
FindHelp() is done to see if the keyword exists.  If so, then replace 
the keyword by "no deprecated" and continue through the rest of the 
function.  However, always printing out the deprecation help might be 
preferred.]

... While on the topic about lists becoming outdated.  There is this 
list, which I think is always apt to be overlooked:

    static char GPFAR unsetmess[] =
    "valid unset options:  [] = choose one, {} means optional\n\n\
\t'angles', 'arrow', 'autoscale', 'bar', 'border', 'boxwidth', 'clabel',\n\
\t'clip', 'cntrparam', 'colorbox', 'contour', 'dgrid3d', 'decimalsign',\n\

etc.  I think at some point, a short bit of code to pull these from the 
the list of keywords and automatically format to 80 letters wide would 
be nice.

And, not straying too far off the subject still, there is the case 
statement:

     switch(found_token) {
    case S_ANGLES:
    unset_angles();
    break;
    case S_ARROW:
    unset_arrow();
    break;

which probably could be done with lookup in a table of functions... but 
perhaps that is just a cosmetic thing because case statements often end 
up as table lookup once compiled.

Dan

I've also included a short patch to weed out "unset_multiplot" from the 
unset.c file.  If it is not conditional (i.e., "#if 0") and can be 
reproduced easily if needed at a later date, I'd say just weed it out to 
avoid cruft.

gp2tex

[Sebastian H. <seb...@gm...>]

On your webpage there is a link to the attached script. The link s broken but 
the author mailed me the script. Maybe you can host it on gnuplot.info
-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://sebastian-hi...@we...
My OS: Suse Linux. Geek by Nature, Linux by Choice

Re: multiplot doc spelling errors

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

> Also, I notice in this documentation that
> ?nomultiplot
> is a means to access this text.  Perhaps all the cases of
> ?no<keyword>
> that appear in gnuplot.doc can be moved under the same heading
> ?nomultiplot
> ?noarrow
> etc.

Enclosed is a patch that moves all this "?no" into the section of "What's
new in 4.0" => "3 Other changes and additions". Do you like it?

---
PM

splot with vectors vs. grid data

[<te...@me...>]

Hello,

Since latest stable release, I am using gnuplot routinly to visualize 2D
and 3D simulation data (also).

Now I am using the latest experimental version because the ability to plot
vectors on pm3d map. It works fine, although I have a suggestion to
make it more convenient.

currently if grid data is used (grid rows are separted with empty lines)
the following error message appears:

"Cannot plot multiple contours in style vectors"

So currently I am using different output file for vector and scalar
quantities.

Also "splot every 2:2" option cannot be used to each grid direction for
vector plot (obviously because it is not a grid data). It is an important
feature, because vector plot usually so dense that few things can be seen
if some rows and columns are not eliminated.


Thank you very much for your work on the best open source ploting tool,
and I hope my suggestions will be usefull in further developing the code.

Best Regards,
George Tegze