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

*** QUESTION: HOW MANY FUNCTIONS THAT CAN BE PLOTTED AT ONCE?

[Pier L. L. <la...@el...>]

dear gnuplot people,=20

sorry to bother with probably a naive question.

I have a problem with gnuplot. I have a program that=20
generates=20
many functions that must be plotted all together in the=20
same plot.=20

An example of the typical script I generate is in attach.

If you plot it, some holes in the plot will appear as if=20
some sections of the domain are not covered.

This for instance happens between 0 and 100.

Then, if you change the script and plot only the section=20
between 0 and 100 the holes disappear.

Basically some functions in the script I put in attach are=20
not plotted.

Is there a limit to the number of functions that gnuplot=20
can plot at once?

What can I do? :)

Thank you!

It is for a paper that I have to submit soon! :))

Pier Luca

Re: Open patches that are useful to me

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

Harald Harders wrote:

>>> #713166 margins changed from int to float
>>>     
>>
> set terminal postscript eps 'Times-Roman' 22
> set output 'margins-1.eps'
> set bmargin 1
> plot sin(x)
> set output
> set output 'margins-2.eps'
> set bmargin 2
> plot sin(x)
> set output
>
> You either crop the xtics or you have white space below them.
>  
>

I think that was pretty much the reason for the patch.  When importing a 
figure, it's easier to add white space than to remove it.  Removing it, 
in LaTeX at least, is slightly trial and error, but also I think it will 
end up causing warning messages because the figure might be slightly too 
big even, though it may be white space hanging over the edge of a margin.

> This is one of my major problems I have using Gnuplot. My current
> workaround is to use multiplot:
>
> ...
> set multiplot
> set size ...
> set origin ...
> set lmargin 0
> set bmargin 0
> set tmargin 0
> set rmargin 0
> plot ...
> unset multiplot
>
> By variing the inner size and origin, I adjust the margins. But this is a
> bad hack.
>  
>

I recall a bit of discussion about this alternative.  I too am not real 
happy with the solution because, again, there is too much trial and 
error.  It always feels like a major undertaking to layout the plots.  
It's nice to be able to fall back on precise positioning, but it's also 
nice to be able to slightly tweak something that is almost what one 
wants.  Even "set bmargin #" is trial and error, but not too bad.  I'd 
be open to a nicer, more obvious syntax.  Maybe bmargin could be the 
amount of white space and then the xlabel would start right where the 
whitespace ends.  Could make for tricky programming across terminals, 
however.

Dan

Re: Open patches that are useful for me

[Harald H. <h.h...@tu...>]

On Sun, 9 Jan 2005, Ethan Merritt wrote:

> On Sunday 09 January 2005 07:38 am, Harald Harders wrote:
> > #616199 Ignore title string after notitle
>
> This patch no longer works since the addition of string variables.

Shit. I have tried this patch (first, only for 2d plots):

--- orig/src/plot2d.c   2004-12-05 16:12:35.000000000 +0100
+++ notitle/src/plot2d.c        2005-01-09 20:54:40.000000000 +0100
@@ -1480,6 +1480,8 @@
                    if (xtitle != NULL)
                        xtitle[0] = '\0';
                    c_token++;
+                   if (try_to_get_string())
+                       int_warn(c_token, "title string ignored");
                    set_title = TRUE;
                    continue;
                }

But this only works when a string is given that can be ignored or if
notitle is the last token:

gnuplot> plot sin(x) notitle 'sine' w l
gnuplot> plot sin(x) notitle 'sine'
gnuplot> plot sin(x) notitle

It does not work if notitle is followed by other things than a string:

gnuplot> plot sin(x) notitle w l
         undefined variable: w

This error message is produced inside execute_at() by the command call
(*ft[operator].func) (&(at_ptr->actions[instruction_index].arg));

Does anybody have an idea how I can reach that the token after notitle is
evaluated if it results to a string and ignored otherwise?



> > #713166 margins changed from int to float
>
> I have no strong objection, but I have not found a case where
> the ability to adjust margins by fractional character widths
> is really needed.  Can you provide a test case?

No problem. Say, you want to produce a postscript file without whitespace
around the plot (This is useful when including these in LaTeX, for
example). Have a look at the lower edge:

set terminal postscript eps 'Times-Roman' 22
set output 'margins-1.eps'
set bmargin 1
plot sin(x)
set output
set output 'margins-2.eps'
set bmargin 2
plot sin(x)
set output

You either crop the xtics or you have white space below them.

This is one of my major problems I have using Gnuplot. My current
workaround is to use multiplot:

...
set multiplot
set size ...
set origin ...
set lmargin 0
set bmargin 0
set tmargin 0
set rmargin 0
plot ...
unset multiplot

By variing the inner size and origin, I adjust the margins. But this is a
bad hack.



> > #835235 minitics updates
>
> No opinion.

Have a look at this example:

set logscale y
set ticscale 2
#
set xrange [1.1:2]
plot 2**x
print 'vertical range not optimal'
pause -1 "Press any key"
#
set yrange [2:5]
replot
print 'range good but ytics are gone'
pause -1 "Press any key"
#
set ytics (2, 3, 4, 5)
replot
print 'range good, major tics visible, but no minor tics'
pause -1 "Press any key"
#
set mytics
replot
print 'still no minor tics'
pause -1 "Press any key"
#
set mytics (2.25, 2.5, 2.75, 3.25, 3.5, 3.75, 4.25, 4.5)
print 'explicit minor tics work with patched gnuplot'
replot
pause -1 "Press any key"


Greetings
Harald


-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Username patch

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

Harald Harders wrote:

> I ment both, since I do not have Acrobat at all.


You can download 5.10 from Adobe's site.


>So, you see in "General Info" in Acroread:
>
>File: <filename>
>Title: <filename>
>Subject: gnuplot plot
>Author: Daniel J Sebald
>Keywords:
>Binding: Left Edge
>Creator: gnuplot 4.1 patchlevel 0
>Producer: PDFlib Lite 6.0.1  resp.  Ghostscript 7.07
>Created: <date>
>...
>PDF Version: 1.4  resp.  1.3
>  
>

Yes.

>>For some reason "ggv" and "xpdf" do not show file information.  Why?  I
>>don't know.
>>    
>>
> Someone can cross that bridge some other day.
>
>
>Thus, you have a pdf file with information, shown by Acroread? But if
>viewed in xpdf, they are not shown? Strange.
>

You're OK.  I mean xpdf provides no means of displaying file info, not 
that I can see.

Dan

Re: Username patch

[Harald H. <h.h...@tu...>]

On Sun, 9 Jan 2005, Daniel J Sebald wrote:

> Harald Harders wrote:
> >I have updated the username patch now to work with the current cvs
> >version. Since I don't have Windows available, does somebody compile
> >gnuplot with Windows and can test the patch there? Gnuplot should either
> >use the Windows login name or one of the environment variables USER or
> >USERNAME to set the Author for the pdf and postscript terminal.
> >
> >When using the postscript terminal, information should be written into the
> >postscript file that is interpreted by ghostscript and Acrobat. With
> >ghostscript, it works. Can please somebody test if Acrobat also takes
> >these information for the pdf file information?
>
> Do you mean in Windows?

I ment both, since I do not have Acrobat at all.

> For Acrobat on linux I'm seeing file
> information in Acrobat for PDF directly and ps2pdf.  (In one case I see
> the Creator is PDFlib Lite 6.0.1 (Linux); in the other case GNU
> Ghostscript 7.07.)

So, you see in "General Info" in Acroread:

File: <filename>
Title: <filename>
Subject: gnuplot plot
Author: Daniel J Sebald
Keywords:
Binding: Left Edge
Creator: gnuplot 4.1 patchlevel 0
Producer: PDFlib Lite 6.0.1  resp.  Ghostscript 7.07
Created: <date>
...
PDF Version: 1.4  resp.  1.3

> The former PDF looks better because the border white
> space is smaller and more even.  The issue with the latter is
> Ghostscript (probably some margins need to be set in a defaults file).

You are using a really old ghostscript version. The current is 8.50. Many
improvements concerning pdf production have been made in the meantime.

> The PostScript file created by Gnuplot does hav e a little bit of
> unbalanced white space borders when viewed in letter layout (bounding
> box layout looks fine).

Are you describing, where the plot is inside the BoundingBox? That should
be another problem that does not have to do with this patch.

> Someone can cross that bridge some other day.
> For some reason "ggv" and "xpdf" do not show file information.  Why?  I
> don't know.

Thus, you have a pdf file with information, shown by Acroread? But if
viewed in xpdf, they are not shown? Strange.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Username patch

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

Harald Harders wrote:

>I have updated the username patch now to work with the current cvs
>version. Since I don't have Windows available, does somebody compile
>gnuplot with Windows and can test the patch there? Gnuplot should either
>use the Windows login name or one of the environment variables USER or
>USERNAME to set the Author for the pdf and postscript terminal.
>
>When using the postscript terminal, information should be written into the
>postscript file that is interpreted by ghostscript and Acrobat. With
>ghostscript, it works. Can please somebody test if Acrobat also takes
>these information for the pdf file information?
>

Do you mean in Windows?  For Acrobat on linux I'm seeing file 
information in Acrobat for PDF directly and ps2pdf.  (In one case I see 
the Creator is PDFlib Lite 6.0.1 (Linux); in the other case GNU 
Ghostscript 7.07.)  The former PDF looks better because the border white 
space is smaller and more even.  The issue with the latter is 
Ghostscript (probably some margins need to be set in a defaults file).  
The PostScript file created by Gnuplot does hav e a little bit of 
unbalanced white space borders when viewed in letter layout (bounding 
box layout looks fine).  Someone can cross that bridge some other day.  
For some reason "ggv" and "xpdf" do not show file information.  Why?  I 
don't know.

Dan

Re: Open patches that are useful for me

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

On Sunday 09 January 2005 07:38 am, Harald Harders wrote:
> #616199 Ignore title string after notitle

This patch no longer works since the addition of string variables.

> #713166 margins changed from int to float

I have no strong objection, but I have not found a case where
the ability to adjust margins by fractional character widths
is really needed.  Can you provide a test case?

> #835235 minitics updates

No opinion.

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

Re: Open patches that are useful for me

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

Harald Harders wrote:

>Today, I have had a look to the open patches at sourceforge.net. Some of
>them are very useful to me and I ask myself why they are not committed to
>cvs, yet. Am I the only person who finds them useful? I would like to
>start a discussion about these patches. Why are they not in cvs. Do they
>have to be improved before, or do you think they are useless, do they
>cause problems?
>  
>

I think there are many more patches there that are ready than just the 
few you mentioned.  :)  We've probably entered a stage where we are 
unafraid to break things.

>#616199 Ignore title string after notitle
>
>plot \
>  sin(x) title 'sin({/Symbol-Oblique a})', \
>  cos(x) notitle 'cos({/Symbol-Oblique a})', \
>  tan(x) title 'tan({/Symbol-Oblique a})'
>  
>

This one I'll think over.  Guess I'm fine with it because I can 
understand its use.  However, it's a bit of a conceptual shift and 
people will wonder, Why can't I do the same with "nolabel 2"?  Etc.

Dan

Username patch (was: Acroread Error (not) Message)

[Harald H. <h.h...@tu...>]

I have updated the username patch now to work with the current cvs
version. Since I don't have Windows available, does somebody compile
gnuplot with Windows and can test the patch there? Gnuplot should either
use the Windows login name or one of the environment variables USER or
USERNAME to set the Author for the pdf and postscript terminal.

When using the postscript terminal, information should be written into the
postscript file that is interpreted by ghostscript and Acrobat. With
ghostscript, it works. Can please somebody test if Acrobat also takes
these information for the pdf file information?

Another thing are information in other terminals. For example, the jpeg
file format can take information, e.g., as exif strings (as digital
cameras do it). Unfortunately, the gd library does not support these. I
have spoken to the maintainer of this library. He would be glad if
somebody of the gnuplot people programmes a patch for his package. I have
had a look to it and don't know how it could be done. If somebody
volunteers to do it ...

Do other file formats also support comments?

Thanks,
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Open patches that are useful for me

[Harald H. <h.h...@tu...>]

Today, I have had a look to the open patches at sourceforge.net. Some of
them are very useful to me and I ask myself why they are not committed to
cvs, yet. Am I the only person who finds them useful? I would like to
start a discussion about these patches. Why are they not in cvs. Do they
have to be improved before, or do you think they are useless, do they
cause problems?



#616199 Ignore title string after notitle
This patch enables to give a string after 'notitle' in the plot command.
This is useful if you have multiple curves in a plot with different titles
and if you want to remove one of the titles (maybe temporarily). Example:

plot \
  sin(x) title 'sin({/Symbol-Oblique a})', \
  cos(x) title 'cos({/Symbol-Oblique a})', \
  tan(x) title 'tan({/Symbol-Oblique a})'

If you want to omit only the second title, you have to change title to
notitle and remove the string. If you later want to add it again, you have
to have a backup copy of this string somewhere or to type it in again.
With this patch, you simply can change the plot command as follows:

plot \
  sin(x) title 'sin({/Symbol-Oblique a})', \
  cos(x) notitle 'cos({/Symbol-Oblique a})', \
  tan(x) title 'tan({/Symbol-Oblique a})'



#713166 margins changed from int to float
By default, the steps in which you can change the margins are too big in
my opinion. This patch avoids this limitation. It is a very simple patch
that does not cause any compatibility problems.



#835235 minitics updates
This patch enables to use explicit minitics, e.g.,
    set mxtics (1.1,1.2,1.3,1.4)
and to use automatic minitics even when the major tics were explicitly
defined, e.g.,
    set xtics (1, 2, 3, 4)
    set mxtics
Especially the explicit minitics are very useful for logarithmic plots
that have data range over only few decades. I am using this patch since it
was submitted without any problems. If you don't use this new function,
the patch does not change anything.


That's it.
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: {column,row}major of multiplot

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

> > In ChangeLog of CVS version:
> >
> >   2005-01-04  Ethan Merritt  <merritt@u.washington.edu>
> >   ...
> >      * docs/gnuplot.doc: Correct the documentation to say
> >      'set multiplot layout <rows>,<cols>' (rows/cols were reversed in the
> >      previous version, and mis-described in the example).
> >
> > I think it is true. Moreover, I wonder the behavior of options
> > {column,row}major are reversed. gnuplot.doc says:
> >
> >   This grid is filled rows first or columns first depending on
> >   whether `rowmajor` or `columnmajor` ...
> >
> > However, in columnmajor (default), first two graphs are placed in
> > the first "row" from left to right. Is it correct behavior ?
>
> I think you are right, and the current behavior is incorrect.
> I will interchange the behavior of the two options unless
> someone here proposes a different solution.

The original meaning of "{columns|rows}major" comes from the original
author. It ment "fill first all columns|rows". The documentation was
correct, when I was adding keywords "upwards" and "downwards". I did not
like the names "*major" very much, but there was no better proposal.

I agree to change the syntax from "layout <cols>,<rows>" to "layout
<rows,cols>", and to replace those confusing "*major" by "rows$first" and
"columns$first".

---
PM

time range

[Jacques B. <jac...@on...>]

Suppose you want to plot a 2D data-file the 1st column of which contain
times. For example:

gnuplot time.dem

time.dem:
     set timefmt '%s'
     set xdata time
     set format x "%y-%m-%d\n%H:%M:%S"
     set xrange ["1105190580":"1105190880"] # ok
     #tmin="1105190580"; tmax="1105190880"; set xrange [tmin:tmax]
     plot 'time.dat' using 1:2
     pause -1

time.dat:
     1105190640 2
     1105190700 1
     1105190760 3
     1105190820 0

You can set a time range with "set xrange" using explicit quoted
strings, but you can't do it with variables containing strings (ex:
tmin, tmax).

Would it be easy to implement this?

empty data-files

[Jacques B. <jac...@on...>]

When you try to plot an empty data-file with "plot", the output terminal 
is not updated, and you get this message:

"no valid data points found in specified file".

Why not.

But if you try to plot 2 data-files, one empty the other not, you get 
the same answer, and that is not OK. There _is_ something to plot. That 
situation may arise if the data-files and the gnuplot script are 
generated automatically.

So I think that in plot2d.c:

int_error(c_token, "no valid data points found in specified file");

should be replaced with:

int_warn(c_token, "no valid data points found in specified file");

Re: Acroread Error (not) Message

[Harald H. <h.h...@tu...>]

On Fri, 7 Jan 2005, Daniel J Sebald wrote:

> Harald Harders wrote:
>
> >On Fri, 7 Jan 2005, Ethan Merritt wrote:
> >
> >Please have a look at this patch. I really think it is useful. I am using
> >it since I have uploaded it to sf.net and I never had any problems.
> >
> These all look like nice improvements.  The error message is gone.
> Details, including user's name show up in the file.  Why not move the
> patch into CVS while on the topic?  One thing I wonder is if we could
> include some way to provide an alternate user name or notice.  For
> example, say I don't want my account user name in the file, but rather a
> company name, work group name, or maybe copyright notice.  Does this
> seem like something worthwhile?  Maybe something like another
> environment variable GNUPLOT_USERNAME.  Or were we trying to move away
> from too many environment variables for gnuplot?

With unix, this patch already uses the environment variables USER or
USERNAME. You can force a username by setting one of these, e.g., using a
bash:

USER='I myself' gnuplot

I have changed it locally that also Windows looks at these environment
variables.

I have also thought if I would be worth to introduce something like
    set fileinfo username 'Harald' title 'Main plot' subject 'test'
Here, also things as keywords could be set. These information could also
be used by other terminals that produce output files which support
information (e.g., jpeg). The fileinfo command could default to the values
used at the moment.

> PS:  Looking through the code I see a couple things.  First "gnuplot
> diagram" is ok, but its technically not a diagram I guess.  (But you
> probably thought "gnuplot plot" just doesn't read well.)

I have changed it to "gnuplot plot". If somebody has a better idea, please
send it to the mailing list.

> Second, the
> following lines of malloc/free are generally OK.  But the one case where
> username2 is zero and username isn't might be a problem.  (But the only
> case that would happen is if the system runs out of memory right after
> allocating username.)

I will change it.

Greetings
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Acroread Error (not) Message

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

On Friday 07 January 2005 09:24 pm, Daniel J Sebald wrote:
> Second, the
> following lines of malloc/free are generally OK.  But the one case where
> username2 is zero and username isn't might be a problem.

free(NULL)  is perfectly legal.  The test
  if (foo) free(foo);
is common, but not necessary.

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

Re: Acroread Error (not) Message

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

Harald Harders wrote:

>On Fri, 7 Jan 2005, Ethan Merritt wrote:
>
>  
>
>>On Friday 07 January 2005 12:41 pm, Daniel J Sebald wrote:
>>    
>>
>>>In any case, the contents of the file seem viewable.  Perhaps something
>>>wrong with the PDF library?  (Ethan?)  I think I just compiled the most
>>>recent version of PDFlib-Lite.  (PDFlib-6.0.1p1-Linux.tar.gz)  Either
>>>
>>>1) PDF library does something acroread doesn't like.
>>>      
>>>
>>The first line of the output from PDFlib is now
>>  %PDF-1.5
>>It used to be
>>  %PDF-1.2
>>
>>Whether PDFlib actually *uses* any of the features introduced since
>>1.2, that I don't know.
>>    
>>
>
>I am rather sure that it does not use any features newer than PDF-1.4. My
>Patch #1023783, Write username to pdf and ps plots and fix both terminals,
>solves this problem. It uses the current PDFlib syntax if available and
>sets PDF to compatibility level 1.4. And it solves some more problems. For
>example, original gnuplot states in every plot that the author of this
>plot was Hans-Bernhard Broeker, in the official version.  This of course
>is not the correct way to handle it. The patch tries to find out the name
>of the current user and uses this one. Some effort is done to work with
>Unix and Windows. The Windows part has to be tested since I do not have
>Windows.
>
>In addition, this patch adds information to postscript files that enable
>ghostscript (and hopefully Acrobat) to set the username and title of the
>plot correctly when converting the postscript file to pdf.
>
>Please have a look at this patch. I really think it is useful. I am using
>it since I have uploaded it to sf.net and I never had any problems.
>
>Harald
>  
>

These all look like nice improvements.  The error message is gone.  
Details, including user's name show up in the file.  Why not move the 
patch into CVS while on the topic?  One thing I wonder is if we could 
include some way to provide an alternate user name or notice.  For 
example, say I don't want my account user name in the file, but rather a 
company name, work group name, or maybe copyright notice.  Does this 
seem like something worthwhile?  Maybe something like another 
environment variable GNUPLOT_USERNAME.  Or were we trying to move away 
from too many environment variables for gnuplot?

Dan


PS:  Looking through the code I see a couple things.  First "gnuplot 
diagram" is ok, but its technically not a diagram I guess.  (But you 
probably thought "gnuplot plot" just doesn't read well.)  Second, the 
following lines of malloc/free are generally OK.  But the one case where 
username2 is zero and username isn't might be a problem.  (But the only 
case that would happen is if the system runs out of memory right after 
allocating username.)

+    char *username=getusername();
+    char *username2=pspdf_escape_string(username,"()\\");
<snip>
+    if (username2) {
+        free(username);
+        free(username2);
+    }

Re: Acroread Error (not) Message

[Harald H. <h.h...@tu...>]

On Fri, 7 Jan 2005, Ethan Merritt wrote:

> On Friday 07 January 2005 12:41 pm, Daniel J Sebald wrote:
> >
> > In any case, the contents of the file seem viewable.  Perhaps something
> > wrong with the PDF library?  (Ethan?)  I think I just compiled the most
> > recent version of PDFlib-Lite.  (PDFlib-6.0.1p1-Linux.tar.gz)  Either
> >
> > 1) PDF library does something acroread doesn't like.
>
> The first line of the output from PDFlib is now
>   %PDF-1.5
> It used to be
>   %PDF-1.2
>
> Whether PDFlib actually *uses* any of the features introduced since
> 1.2, that I don't know.

I am rather sure that it does not use any features newer than PDF-1.4. My
Patch #1023783, Write username to pdf and ps plots and fix both terminals,
solves this problem. It uses the current PDFlib syntax if available and
sets PDF to compatibility level 1.4. And it solves some more problems. For
example, original gnuplot states in every plot that the author of this
plot was Hans-Bernhard Broeker, in the official version.  This of course
is not the correct way to handle it. The patch tries to find out the name
of the current user and uses this one. Some effort is done to work with
Unix and Windows. The Windows part has to be tested since I do not have
Windows.

In addition, this patch adds information to postscript files that enable
ghostscript (and hopefully Acrobat) to set the username and title of the
plot correctly when converting the postscript file to pdf.

Please have a look at this patch. I really think it is useful. I am using
it since I have uploaded it to sf.net and I never had any problems.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: "Bind all <key> <command>" patch on SourceForge

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

On Friday 07 January 2005 02:12 pm, Jacques Bouchard wrote:
> There is still a problem: you can't zoom with the mouse any longer (and
> that's one of the reasons why I wish to reactivate my x11 terminals).

Are you sure?
Zoom works for me, although there is the confusion that whatever
range you zoom into then becomes the default for the next replot
command, whichever plot window it may belong to.

If you tell me the precise sequence of operations that leads
to non-functional zoom, I will try to reproduce it.


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

Re: "Bind all <key> <command>" patch on SourceForge

[Jacques B. <jac...@no...>]

Ethan Merritt wrote:
> Both of these are fixable.  So I have uploaded a new version
> of the patchset ...
> With this revised version I think you can do everything you
> wanted ...
> As before, please let me know if more, or different, functionality
> is ideally needed for your full application.

There is still a problem: you can't zoom with the mouse any longer (and
that's one of the reasons why I wish to reactivate my x11 terminals).

Thanks again for your help.

Re: "Bind all <key> <command>" patch on SourceForge

[Jacques B. <jac...@no...>]

Ethan Merritt <merritt <at> u.washington.edu> writes:
> With this revised version I think you can do everything you
> wanted. Here are my test files:
> ...
> As before, please let me know if more, or different, functionality
> is ideally needed for your full application.

There is just one problem: you can't zoom with the mouse any longer (and that is
one of the reasons why I wanted to reactivate my x11 plots).

Thanks again for your help.

Re: {column,row}major of multiplot

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

Ethan Merritt wrote:

>Longer answer
>-------------
>
>Some programming languages (e.g. C) and some application
>communities (e.g. image processing) choose instead to refer to
>arrays as A[column,row].  That is, the words "row" and "column"
>now correspond to the 2nd and the 1st index respectively.
>In this case "column major" still means "1st index varies fastest"
>but the 1st index is unfortunately called "column" rather than
>"row".  I have no idea why this terribly confusing choice of terms
>was introduced.
>  
>
>

I too wonder how that ever came about.  Whenever I program C arrays, I 
always test to make sure I'm indexing in the right fashion rather than 
go from memory.

>So gnuplot's current use of the word "columnmajor" may be
>technically correct with regard to internal storage of C arrays.
>But the user doesn't care about internal arrays, only about
>the appearance of the output page. We should change it to match
>the output page.
>

Exactly.

I'm sure this will effect Octave and perhaps others.  But I'd prefer 
this be fixed in Gnuplot.

Dan

Re: Acroread Error (not) Message

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

On Friday 07 January 2005 12:41 pm, Daniel J Sebald wrote:
> 
> In any case, the contents of the file seem viewable.  Perhaps something 
> wrong with the PDF library?  (Ethan?)  I think I just compiled the most 
> recent version of PDFlib-Lite.  (PDFlib-6.0.1p1-Linux.tar.gz)  Either
> 
> 1) PDF library does something acroread doesn't like.

The first line of the output from PDFlib is now 
  %PDF-1.5
It used to be
  %PDF-1.2

Whether PDFlib actually *uses* any of the features introduced since
1.2, that I don't know.

> 3) Acroread added an error message from 5.6 to 5.10 and complains where 
> it used to not know the difference... and Acroread 7.0 can actually 
> handle what is in PDF library, it's just that there's only a beta 
> version of Acroread 7.0 just yet.

The world has moved on, and Acroread for linux mostly hasn't.
Version 5.8 now spits out this warning message for a majority
of PDF files that I have to deal with each day from many sources.
Nevertheless, even files that truly do contains elements not fully
supported by 5.8 (e.g. fillable forms) still display and edit properly.

So it's annoying, but harmless.


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

Acroread Error (not) Message

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

I'm seeing the following error message when viewing Gnuplot generated 
PDF files:

This file may contain newer information than this viewer can support. It 
may not open or display correctly. Adobe recommends that you upgrade to 
the latest version of our Acrobat products. Please visit our product 
site at http://www.adobe.com/acrobat

The version is AcroRead 5.10.  I can't say when this started happening.  
I just recently upgraded my system, along with the version of acroread.  
However, I found this out through a collegue who may be running a 
slightly older version of AcroRead, say 5.6.

In any case, the contents of the file seem viewable.  Perhaps something 
wrong with the PDF library?  (Ethan?)  I think I just compiled the most 
recent version of PDFlib-Lite.  (PDFlib-6.0.1p1-Linux.tar.gz)  Either

1) PDF library does something acroread doesn't like.
2) PDF library isn't being called correctly to build a header
3) Acroread added an error message from 5.6 to 5.10 and complains where 
it used to not know the difference... and Acroread 7.0 can actually 
handle what is in PDF library, it's just that there's only a beta 
version of Acroread 7.0 just yet.

Dan

Re: {column,row}major of multiplot

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

On Wednesday 05 January 2005 08:29 pm, Shigeharu TAKENO wrote:
> shige 01/06 2005
> ----------------
> 
> In ChangeLog of CVS version: 
> 
>   2005-01-04  Ethan Merritt  <merritt@u.washington.edu>
>   ...
>      * docs/gnuplot.doc: Correct the documentation to say
>      'set multiplot layout <rows>,<cols>' (rows/cols were reversed in the
>      previous version, and mis-described in the example).
> 
> I think it is true. Moreover, I wonder the behavior of options 
> {column,row}major are reversed. gnuplot.doc says:
> 
>   This grid is filled rows first or columns first depending on
>   whether `rowmajor` or `columnmajor` ...
> 
> However, in columnmajor (default), first two graphs are placed in
> the first "row" from left to right. Is it correct behavior ?

I think you are right, and the current behavior is incorrect.
I will interchange the behavior of the two options unless
someone here proposes a different solution.


Short answer
------------

Standard mathematical terminology for arrays is A[row,column],
so that "row" is the first index.

The standard definition of "column major" is
"elements that differ only in their first index are contiguous".
In other words, "the first index varies fastest".
So indeed "column major" means that successive entries should
fill one column before continuing in the next column.

Longer answer
-------------

Some programming languages (e.g. C) and some application
communities (e.g. image processing) choose instead to refer to
arrays as A[column,row].  That is, the words "row" and "column"
now correspond to the 2nd and the 1st index respectively.
In this case "column major" still means "1st index varies fastest"
but the 1st index is unfortunately called "column" rather than
"row".  I have no idea why this terribly confusing choice of terms
was introduced.

So gnuplot's current use of the word "columnmajor" may be
technically correct with regard to internal storage of C arrays.
But the user doesn't care about internal arrays, only about
the appearance of the output page. We should change it to match
the output page.


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

Re: cvs(today): splot "with image" y-size; missing data color

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

> #]> 2) is there any way to set the "missing data" color for "with image" (and
> #]> perhaps "with pm3d") ?
> (...)
> #]
> #]For pm3d, either miss them in the data file, or set a z-range, or use
> #]different z-range and cb-range;
> #]	set zrange [10:1e8]
> #]will invalidate all data out of the above range.
>
> Do I understand this correctly that in pm3d map mode the zrange controls
> whether points are "drawn", i.e. whether for example in a postscript image
> the background is visible or not?

Yes, invalid quadrangles are not drawn.


> #]That cannot be done for "with image" for principal reasons -- that's to draw
> #]a matrix, so all pts must be valid. Thus, you have to make a palette with
> #]one color white and use the corresponding value for coloring your special
> #]pixels.
>
> Sure... what I was asking is: is there any way to set this special color
> value?

No; I overcome it by the above method. It may be really useful to add such a
"masking" color, chooseable like the current "textcolor". You could try to
make a proposal for syntax with comments on functionality.

---
PM