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

Re: Comment for pgnuplot

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

Tatsuro MATSUOKA wrote:

> If "void PostString(HWND hwnd, char *pc)"
> 
> in pgnuplot.c is modified by
> 
> "void PostString(HWND hwnd, unsigned char *pc)"
> 
> , it looks like work well.

While that may appear to work well, I doubt it's the right way of going
at it.  The data passed to this function are actually type char *, not
unsigned char *, and casting a pointer from one type to another is
always a dangerous thing to do, even more so if it's supposed to happen
this silently, by argument conversion.  The correct method would rather
appear to be a cast of the character being sent to 'unsigned char', as
it's passed to the Windows API function PostMessage.

> The buffer size is rather small. (80) I think it should be larger
> (eg.512).
> 
> "#define BUFFER_SIZE 512"

What do you think would be gained by that?  Please note that the size of
this buffer may very well be a critical parameter that determines how
well pgnuplot works in a somewhat busy Windows environment.

Comment for pgnuplot

[Tatsuro M. <mat...@nu...>]

Dear sir,

 From wgnuplot 4.0 later, we can treat Japanese shift-Jis code character.
Unfortunately I found that pgnuplot.exe could not treat Japanese character.


If
"void PostString(HWND hwnd, char *pc)"

in pgnuplot.c is modified by 

"void PostString(HWND hwnd, unsigned char *pc)"

, it looks like work well. 

This may be because Shift-Jis code uses code number larger than 80(HEX).

I have another opinion.

The buffer size is rather small. (80) 
I think it should be larger (eg.512).

"#define BUFFER_SIZE 512"

Please be patient for my influent English.

***************************************************************
Dr. Tatsuro MATSUOKA

Department of Molecular Design and Engineering
Graduate School of Engineering
Nagoya University
Furo-cho, Chikusa-ku, Nagoya, 464-8603, Japan
E-mail mat...@nu...
Tel.   +81(Japan)-52-789-3274
FAX    +81(Japan)-52-789-3273
****************************************************************

Re: Contour plots

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

On Tuesday 25 January 2005 05:04 am, Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> 
> > Also, I just want to confirm that gnuplot contours can't do the 
> > following type of labelling?
        X
> > 
> > ------ 20 ------
> > 
> > ------------ 30 --------
> 
                     Y
> Right, it can't.  The main problem being that it's an absolute beast of
> a problem to figure out *where* to put such labels

I agree that it is difficult.

On the other hand, the mousing code is now versatile enough
that you could write a script to add the labels interactively.
I can imagine a semi-automated mode in which you click twice,
once at point X above and once and point Y above, and the script
proceeds to add a label on each intervening contour.

The demo below was written for a different purpose, but it
illustrates some of the same ideas:

# Contour-slice demo
# Ethan A Merritt <merritt@u.washington.edu>
#
set samples 40, 40
set isosamples 41, 41
set contour base
set cntrparam levels auto 10
set title "Interactive contour slicing demo"

f(x,y) = sin(x) * cos(y)
f(x,y) = sin(13*besj0(x))  * cos(y/ (0.1 + (abs(x-2.))) )

# Plot function with contours
set view map
unset surface
splot [x=-0:4] [y=0:2] f(x,y)

pause mouse "Click on some point\n"
x0 = MOUSE_X
y0 = MOUSE_Y
pause mouse "Click on another point\n"
x1 = MOUSE_X
y1 = MOUSE_Y

# Show selected path
set arrow 1 from x0,y0 to x1,y1
replot
pause -1 "Hit return to plot contours along this slice"
unset arrow 1

# Define parametric function running along this line
g(z) = f( x0 + z*(x1-x0), y0 + z*(y1-y0) )

# Plot the value of f(x) along the selected path
set xlabel "Fractional distance along selected path"
set samples 500
unset key
set label 1 sprintf("(%.3f,%.3f)",x0,y0) at 0,g(0) tc lt 3
set label 2 sprintf("(%.3f,%.3f)",x1,y1) at 1,g(1) right tc lt 3
plot [x=0:1] g(x)

pause -1



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

Re: Contour plots (was "What should be set term, set output, set term, set term behavior?")

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

Daniel J Sebald wrote:

> Also, I just want to confirm that gnuplot contours can't do the 
> following type of labelling?
> 
> ------ 20 ------
> 
> ------------ 30 --------

Right, it can't.  The main problem being that it's an absolute beast of
a problem to figure out *where* to put such labels, and not make a
complete fool out oneself half the time.  Re-writing TeX's layout
algorithm from scratch might be a piece-of-cake, in comparison.

Comment for pgnuplot

[Tatsuro M. <mat...@nu...>]

Dear sir,

 From wgnuplot 4.0, we can treat Japanese shift-Jis code character.
Unfortunately I found that pgnuplot.exe could not treat Japanese character.


If
"void PostString(HWND hwnd, char *pc)"

in pgnuplot.c is modified by 

"void PostString(HWND hwnd, unsigned char *pc)"

, it looks like work well. 

This may be because Shift-Jis code uses code number larger than 80(HEX).

I have another opinion.

The buffer size is rather small. (80) 
I think it should be larger (eg.512).

"#define BUFFER_SIZE 512"

Please be patient for my influent English.

***************************************************************
Dr. Tatsuro MATSUOKA

Department of Molecular Design and Engineering
Graduate School of Engineering
Nagoya University
Furo-cho, Chikusa-ku, Nagoya, 464-8603, Japan
E-mail mat...@nu...
Tel.   +81(Japan)-52-789-3274
FAX    +81(Japan)-52-789-3273
****************************************************************

Re: Povray terminal output

[V. <gae...@en...>]

> The surface in povray is OK, but what about axes and their labels, and =
also
> the colorbox?

  Yes, I am aware, but I know (because I have seen other people do it)
that such thing are reasonnably easily done in povray.

 I am currently overwellmed with other work that is due at the end of the
week. I am planning to work more actively on the use of scientific
plotting with povray afterward. I would greatly enjoy collaborating with
the gnuplot team to get a gnuplot terminal working.

> For exporting only the surface into povray you could use just the "set =
term
> table" and an appropriate filter.

   Yes, this is true, and then include it in Povray with a heightfield.
But my goal would be to make povray usable for scientific plotting by
somebody who doesn't know anything about Povray, but only through
standard Gnuplot interface, with a given terminal, and maybe a few
options. For somebody who allready knows Povray it is quite easy to use
it to display plots, eventhough it take a bit of time to put axes and
alike to scale.

       Ga=EBl

Re: Povray terminal output

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

>   I am a bit in a hurry, right now, so here is an splot with pm3D, the
> povray version and the gnuplot version.
>
> www.eleves.ens.fr/home/varoquau/2Dlattice.png
> www.eleves.ens.fr/home/varoquau/2Dlattice.pov
> www.eleves.ens.fr/home/varoquau/gnuplot-2Dlattice.png

The surface in povray is OK, but what about axes and their labels, and also
the colorbox?

For exporting only the surface into povray you could use just the "set term
table" and an appropriate filter.

---
PM

Contour plots (was "What should be set term, set output, set term, set term behavior?")

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

Daniel J Sebald wrote:

> This has come to my attention because in Octave I'd wondered if there 
> was a way to leave a PostScript file or PDF file open, switch over to 
> X11 to do some plots, switch back to the PS or PDF terminal and place 
> another plot in the file.  (Octave does stem plots as two successive 
> plots.)


For those interested, the plot scripts of Octave have just been updated 
to plot all data at once as opposed to a series of "replots":

http://www.octave.org/cgi-bin/viewcvs.cgi/octave/scripts/plot/

This makes for nicer behavior in all plot terminals... and obviates the 
need for any alternate behavior of switching terminals when the output 
file is left open.

...

Also, I just want to confirm that gnuplot contours can't do the 
following type of labelling?

     ------ 20 ------

      ------------ 30 --------


If they can, let me know.  Otherwise, maybe a project for summer.

Dan

Re: Set pagesize [was Re: Clipping of arrows buggy]

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

Harald Harders wrote:
> On Fri, 21 Jan 2005, Hans-Bernhard Broeker wrote:

>>That's indeed seriously bad.  The patch should follow what the existing
>>code does, i.e. use the values of 'set pagesize' instead of 'set size'
>>in exactly those places I already described, where currently a 'set size
>>before set terminal' makes a difference.

> I maybe partly agree. But if you want to have two different sizes, one for
> the page and one for the plot, you have to have two coordinate pairs for
> both sizes. 

Yes, and we already have them, at least in principle: the terminal page
size, and the 'set size' / 'set origin' status.

Currently, you have to be in multiplot mode to actually have separate 
control over the two, but other than that.  That's the real limitation
that needs to be undone.  The rest is, effectively, just user interface 
polishing.

> I think I should have put the page sizes into the TERMENTRY
> struct, too. 

Not just "too", that's exactly the one and only place where they belong.
The variables term->xmax and term->ymax *are* the page size.

If we implement this by a new global 'set pagesize' command, then
the change to terminal drivers is trivial: find all
occurences of 'xsize' and 'ysize' in term->graphic() implementations,
and replace them by 'pagesize.x' and 'pagesize.y'.  Optionally, for 
extra credit, find some more drivers that could benefit from such a
feature.

> Of course there are terminals which schould not allow to change the
> pagesize, e.g., a DOS screen. 

And that's why at least the core part of this modification *must* be
done inside the terminal driver source.  Doing such work in the 
terminal-independent part of gnuplot is strictly a non-option.

> Maybe, an additional TERMENTRY member 'TBOOLEAN resizable' could be
> introduced that takes the information if this terminal may be resized or
> not. 

That's another option, indeed.  But I still consider it safer to have
the individual terminal drivers handles this on their own, rather than
a central routine checking a flag and then fiddling around with 
term->xmax post factum --- by the time the core functions get there, it 
may be too late.  Think of stuff like picture headers being written by 
term->graphics() that contain the absolute image size.

>>>gnuplot does not control the size of the X window,

>>And it shouldn't.  I.e., x11.trm should ignore 'set pagesize'.

> I don't understand why not. 

Because having two such radically separate user interfaces as the script
console and an X11 resize operation try to fight over control of a 
single option is seriously bad design.  If it was a clever idea to let 
programs dictate their own window sizes (and placements?), why does X11
need a window manager?

 > It should get a default window size by the X
> resources, of course. But why the user shall not be able to produce two
> x11 terminal windows with different size in one session? 

He can --- but he has to do it the X11-preferred way: using the mouse, 
or teaching his/her window manager how to do it.

> I think there are pros and cons. On the one hand, you are then able to
> specify the sizes exactly, for example in pixels for pixel-based terminals
> or in mm, pt, or inches for postscript. On the other hand, a unique
> approach for all capable terminals has an advantage when switching from
> one terminal to another.

That may very be a disadvantage instead.  Just consider this: what are 
the odds that a pagesize override designed for one terminal still makes 
sense on some other?  The page size is, almost by definition, terminal 
dependent, and as such, should probably be controlled on a per-terminal 
basis.

I therefore vote for making this an option to those 'set terminal' that 
can use it, but don't have one yet, rather than a new global setting.

Maybe we can revive Lars' old "set termoptions" plan (i.e. a set of 
options applied globally to all terminal drivers)?

Re: set "margins"?

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

> Would "set margins" as a shorthand for modifying all margins be a
> worthwhile syntax?  The more obvious uses would be
>
> set margins
> set margins 0

I would prefer
	set margins [left|right|top|bottom] ...

instead of the 4 set lmargin, set bmargin ...  but of course these have to
be kept due to compatibility reasons.

---
Petr

set "margins"?

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

Would "set margins" as a shorthand for modifying all margins be a 
worthwhile syntax?  The more obvious uses would be

set margins
set margins 0

The first instance is often covered by just doing a general "reset".  
But the second instance might be more useful.

Dan

What should be set term, set output, set term, set term behavior?

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

I don't know if anyone put any thought into the proper behavior of 
changing the terminal while some output file is still open, but current 
behavior seems undefined or of no use.  Maybe closing the output after a 
terminal command is the thing to do, but I don't thing gnuplot behaves 
that way.

This has come to my attention because in Octave I'd wondered if there 
was a way to leave a PostScript file or PDF file open, switch over to 
X11 to do some plots, switch back to the PS or PDF terminal and place 
another plot in the file.  (Octave does stem plots as two successive 
plots.)  In other words, in Octave this would be similar to the "print 
-dpdf" command but not closing the file in between plots.

Anyway, back on to behavior.  Try

set term post color solid
set output 'junk.ps'
plot sin(x)
set term x11
plot cos(x)
set term post color solid
replot
set output

OK, what's strange about this is that gnuplot still prints PostScript 
code to the file 'junk.ps' after switching to and back from "set term 
x11".  The content of the file from the first "plot sin(x)" is erased, 
then the result of "replot" is sent to the file.  But then there is the 
additional non-consistency of the PostScript file not being in color as 
indicated by the set term.

As I said before, this is probably undefined.  But I'd think a more 
"defined" or logical behavior would

1) The "set term" causes the output file to be closed as though a "set 
output" had been issued just before "set term"; or
2) The file is not actually closed and it is possible to continue to 
write to the file using a different terminal.  If the user mixes 
incompatible file types, that's his or her problem to clear up.

Alternative 2 would allow plotting in the x11 terminal in an 
intermediate fashion.

Dan

Re: Set pagesize [was Re: Clipping of arrows buggy]

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

On Saturday 22 January 2005 12:32 am, Harald Harders wrote:
> There is, for example, another option that has started from one terminal
> and is now available for many terminals: enhanced text. In my opionion,
> something like 'set text enhanced' would be better than chosing it for
> every terminal in a different way.

Not only do I agree with this, I added it quite a while ago at Petr's 
urging. There is such an option already:
	set termoption enhanced

See, for instance, the enhancedtext.dem demo file

> You may say that not every terminal 
> supports enhanced text. But there are enough other things that are not
> supported by all terminals and still not in the terminal command, for
> example, filled arrow heads.

Sure. But one has to make sure that the failure mode is harmless.
I'd like to add "set termoption linewidth <foo>", for instance,
but with the current code this causes an error if the active terminal
does not support a set linewidth option.

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

Re: Set pagesize [was Re: Clipping of arrows buggy]

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

On Fri, 21 Jan 2005, Ethan Merritt wrote:

> On Friday 21 January 2005 11:33 am, Harald Harders wrote:
> >
> > > > gnuplot does not control the size of the X window,
> > >
> > > And it shouldn't.  I.e., x11.trm should ignore 'set pagesize'.
> >
> > I don't understand why not. It should get a default window size by the X
> > resources, of course. But why the user shall not be able to produce two
> > x11 terminal windows with different size in one session? You cannot change
> > the X resources between two plots of one gnuplot session. But why not
> > provide to produce different window sizes?
>
> That's not the point.  Sure, you could start out with any window
> size you like. But after you have opened the window, the size can be
> changed externally by the user. So the gnuplot core code cannot
> assume that it knows the current size of the window.
>
> It would be possible to have gnuplot_x11 update the values
> of term->xmax and term->ymax via the mousing pipe. You'll find
> a commented out bit of code that does so.
> But doing this breaks various assumptions in the gnuplot core.
> I know it does, because I tried it; that's why the code
> is there but commented out.  To fix all these you would have to
> make explicit use of term->xmax and term->ymax in many places that
> do not  currently check them at all. This might be worth doing,
> but it goes in exactly the opposite direction of your current patch.

Thus, I understand it in this way: It was a good thing if gnuplot could
handle different window sizes but it is too hard to provide that
functionality starting from gnuplot's source code.

> > Some terminals already have an own mechanism to change the size. The
> > question now is how to handle a pagesize that differs from the default
> > value in conjunction with an explicit size given in the 'set terminal'
> > command. Shall the pagesize be overwritten by the terminal size or shall
> > both values be multiplicated?
>
> I am not clear on exactly what problem you are trying to fix
> with this work. Would it suffice for your purposes if there
> were a 'set term post ...' option that explicitly set the
> BoundingBox?

Yes, for me it is enough if the Postscript terminal (and with it hopefully
also the epslatex terminal when the epslatex patch will be applied to cvs
somedays) has the capability to take an option to change the page size -
because I am only using this terminal.  But I think it was a better
approach to provide a unique command that changes the size of the page for
all capable terminals.

There is, for example, another option that has started from one terminal
and is now available for many terminals: enhanced text. In my opionion,
something like 'set text enhanced' would be better than chosing it for
every terminal in a different way. You may say that not every terminal
supports enhanced text. But there are enough other things that are not
supported by all terminals and still not in the terminal command, for
example, filled arrow heads.

If we cannot reach a consensus on a global 'set pagesize' command that
changes the page size (it really may be realised in a different way than I
have done it) I will provide a patch that gives the BoundingBox for the
postscript terminal because this is all I need personally. Nevertheless I
think, for gnuplot in general, a global 'set pagesize' command should be
available.

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

Re: Set pagesize [was Re: Clipping of arrows buggy]

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

On Friday 21 January 2005 11:33 am, Harald Harders wrote:
> 
> > > gnuplot does not control the size of the X window,
> >
> > And it shouldn't.  I.e., x11.trm should ignore 'set pagesize'.
> 
> I don't understand why not. It should get a default window size by the X
> resources, of course. But why the user shall not be able to produce two
> x11 terminal windows with different size in one session? You cannot change
> the X resources between two plots of one gnuplot session. But why not
> provide to produce different window sizes?

That's not the point.  Sure, you could start out with any window
size you like. But after you have opened the window, the size can be
changed externally by the user. So the gnuplot core code cannot
assume that it knows the current size of the window.

It would be possible to have gnuplot_x11 update the values
of term->xmax and term->ymax via the mousing pipe. You'll find
a commented out bit of code that does so.
But doing this breaks various assumptions in the gnuplot core.
I know it does, because I tried it; that's why the code
is there but commented out.  To fix all these you would have to
make explicit use of term->xmax and term->ymax in many places that
do not  currently check them at all. This might be worth doing,
but it goes in exactly the opposite direction of your current patch.

> Some terminals already have an own mechanism to change the size. The
> question now is how to handle a pagesize that differs from the default
> value in conjunction with an explicit size given in the 'set terminal'
> command. Shall the pagesize be overwritten by the terminal size or shall
> both values be multiplicated?

I am not clear on exactly what problem you are trying to fix
with this work. Would it suffice for your purposes if there
were a 'set term post ...' option that explicitly set the
BoundingBox?


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

Re: Set pagesize [was Re: Clipping of arrows buggy]

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

On Fri, 21 Jan 2005, Hans-Bernhard Broeker wrote:

> Ethan Merritt wrote:
> > On Wednesday 19 January 2005 08:38 am, Harald Harders wrote:
> >
> >>After Dan's mail, I have had the same idea. I think it is a good idea that
> >>screen should be in the range 0<=screen<=1. But it should also be possible
> >>to change the size of the page as well. This could then also apply to
> >>other terminals as x11. I volunteer to add at least the basis of a
> >>'set pagesize' command. I also will add support to some terminals that I
> >>understand. I then will need some help to support all terminals.
> >
> >
> > I don't understand how this is intended to work.
> > You have changed all the places that currently refer to
> > term->xmax or term->ymax so that they refer to some
> > global variable instead.
>
> That's indeed seriously bad.  The patch should follow what the existing
> code does, i.e. use the values of 'set pagesize' instead of 'set size'
> in exactly those places I already described, where currently a 'set size
> before set terminal' makes a difference.

I maybe partly agree. But if you want to have two different sizes, one for
the page and one for the plot, you have to have two coordinate pairs for
both sizes. I think I should have put the page sizes into the TERMENTRY
struct, too. I haven't done that because then all initialisations needed
to be changed, too. If you have an idea how to avoid additional, global
variables without producing confusing code, please tell it to me.

Of course there are terminals which schould not allow to change the
pagesize, e.g., a DOS screen. Unfortunately, I was not aware of these and
maybe have made terminals resizable which shouldn't be that. I think all
terminals which are reasonable to resize should be resized by 'set
pagesize'. The terminals that may not have different sizes should produce
a warning if the pagesize is different from 1,1.

Maybe, an additional TERMENTRY member 'TBOOLEAN resizable' could be
introduced that takes the information if this terminal may be resized or
not. Or, a value
    #define TERM_RESIZEABLE 64
or
    #define TERM_NOTRESIZEABLE 64
could be added to the flags parameter. Then, a function could be used to
set term->xmax, term->ymax, xpagemax, and ypagemax (or whatever they are
called) according to the resize switch.

I think it is important to be able to set the size of the page and of the
plot independently, even without multiplot. If you, for example, want to
put some extra labels to the plot that are rather large it may be the
easiest way to increase the pagesize and/or to decrease the plot size.
This could of course also be done using the margins. But I think using the
sizes is easier.

> > gnuplot does not control the size of the X window,
>
> And it shouldn't.  I.e., x11.trm should ignore 'set pagesize'.

I don't understand why not. It should get a default window size by the X
resources, of course. But why the user shall not be able to produce two
x11 terminal windows with different size in one session? You cannot change
the X resources between two plots of one gnuplot session. But why not
provide to produce different window sizes?

> > I see that your patch touches many terminal types.
> > If you have to change them anyhow, would it not make
> > more sense just to add explicit size specs for the
> > terminal types that already support it?
>
> That would be a different, possibly better approach to that.

I think there are pros and cons. On the one hand, you are then able to
specify the sizes exactly, for example in pixels for pixel-based terminals
or in mm, pt, or inches for postscript. On the other hand, a unique
approach for all capable terminals has an advantage when switching from
one terminal to another.

Some terminals already have an own mechanism to change the size. The
question now is how to handle a pagesize that differs from the default
value in conjunction with an explicit size given in the 'set terminal'
command. Shall the pagesize be overwritten by the terminal size or shall
both values be multiplicated?

Harald

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

Re: gd.trm and multiple plots with png

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

Hans-Bernhard Broeker wrote:

> Jim Kleckner wrote:
>
>> I have also wanted to create GIF animations.  How hard is it to
>> crack them back apart into individual images?
>
>
> I don't know.  But it shouldn't be excessively hard --- even Java's 
> AWT can do it ;-)
>
>> Note that the
>> current behavior for GIF and PNG is to lose all plots subsequent
>> to the first one.
>
>
> In the existing framework, that's one of only two possibly sane ways 
> of doing it (the other: keep only the last page).
>
> > Would it make sense to define an option to
>
>> write these subsequent plots to sequentially numbered files?
>
>
> It might, if someone manages to pull it off and find an understandable
> user interface.  I would imagine something like
>
>     set output 'filename' numbered
>
> (maybe with some options to control how the numbers are put into the 
> name).
>
> The main benefit of this approach would be that it would work for 
> other file-based terminal drivers, too.


With that approach, perhaps "multi" should be a keyword because it is 
similar in concept to multiplot, agree?  Just yesterday I could have 
used something like this to generate PNG files from a series of graphs 
in Octave.  It beats doing a "mv output.png output1.png" after every 
plot.  On the other hand, I just used the PDF file format because there 
everything is "packaged" automatically and there is a viewer to go along 
with it.  The problem with PDF, however, is it's usual benefit.  If one 
has a plot with many, many sample points, the series of plots gets 
rather big.

I'd still like the terminal to create a single file for animation if 
possible.  That just seems so much nicer.  Guess I see the application 
for both.

Dan

Re: Set pagesize [was Re: Clipping of arrows buggy]

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

Ethan Merritt wrote:
> On Wednesday 19 January 2005 08:38 am, Harald Harders wrote:
> 
>>After Dan's mail, I have had the same idea. I think it is a good idea that
>>screen should be in the range 0<=screen<=1. But it should also be possible
>>to change the size of the page as well. This could then also apply to
>>other terminals as x11. I volunteer to add at least the basis of a
>>'set pagesize' command. I also will add support to some terminals that I
>>understand. I then will need some help to support all terminals.
> 
> 
> I don't understand how this is intended to work.
> You have changed all the places that currently refer to
> term->xmax or term->ymax so that they refer to some
> global variable instead.

That's indeed seriously bad.  The patch should follow what the existing
code does, i.e. use the values of 'set pagesize' instead of 'set size' 
in exactly those places I already described, where currently a 'set size 
before set terminal' makes a difference.

> You can't just assume that you managed to set it to something
> else.  What about output to a printer?  You can't change the
> page size other than maybe feeding it an extra long piece of
> paper.

It's not that meaningless, actually.  Workgroup printers often have 
automatic page-size detection per print job, meaning they'll 
automatically pull in paper from their A3 tray if that's what the print 
job says it needs.  If gnuplot can pack this kind of information into 
the printable file at all, then 'set pagesize' would be exactly the 
method to do that.

> gnuplot does not control the size of the X window, 

And it shouldn't.  I.e., x11.trm should ignore 'set pagesize'.

> I see that your patch touches many terminal types.
> If you have to change them anyhow, would it not make
> more sense just to add explicit size specs for the 
> terminal types that already support it?

That would be a different, possibly better approach to that.
IIRC, Lars once wanted to collect common terminal options like this into 
a central handling routine, but that plan never got to fruition.

Re: gd.trm and multiple plots with png

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

Jim Kleckner wrote:

> I have also wanted to create GIF animations.  How hard is it to
> crack them back apart into individual images?

I don't know.  But it shouldn't be excessively hard --- even Java's AWT 
can do it ;-)

> Note that the
> current behavior for GIF and PNG is to lose all plots subsequent
> to the first one.

In the existing framework, that's one of only two possibly sane ways of 
doing it (the other: keep only the last page).

 > Would it make sense to define an option to
> write these subsequent plots to sequentially numbered files?

It might, if someone manages to pull it off and find an understandable
user interface.  I would imagine something like

	set output 'filename' numbered

(maybe with some options to control how the numbers are put into the name).

The main benefit of this approach would be that it would work for other 
file-based terminal drivers, too.

Re: [ gnuplot-Patches-1105717 ] Add '=' special file to reread '-' inline data

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

Ethan Merritt wrote:
>Sampo Kellom=E4ki (sampo2)

>>BTW, I would much prefer to reply by email and you would get
>>quicker replies. However, the message I got from you by mail did
>>not have usable reply address. This is bad netiquette in my
>>opinion.

Netiquette deals originally with USENET, not Web-based messaging forum=20
like this one.

And given the level of severity the spamming problem has reached, I'm=20
afraid offring a free-for-all plain email address must be considered a=20
dangerous thing to offer these days.

> If you want to join us in Email discussions, please post
> and subscrive to the mailing list

I fully second Ethan on that.  Note that if you don't subscribe, all=20
submissionss to gnuplot-beta will be put on hold until an admin (i.e.:=20
myself) OKs them.

>>I'd say that=20
>>a proper redesign using temporary file for pipes might be
>>the best thing to do.

What exactly do you mean by that?  Do you propose gnuplot should
backup all data it receives from a redirected stdin to a disk file?
I really don't think that's a good idea.  Caching it in memory, maybe,=20
but not to disk.

[...]
> the copy already stored in gnuplot's internal data structures.

Unfortunately, not quite.  Not if "fast" datafile reading (which doesn't =

keep all columns of a single line, must less the entire datafile) is in u=
se.

>>If you can confirm that '=3D' is the official way to do it, I
>>can move on with my life

> There can be no promise that this will become "the official way"
> when we don't even have a fully-working example at the moment.

I think it would make more sense to change the meaning of

	plot '-', ''

from being equivalent to

	plot '-', '-'

(if that's what users wanted, they only have to put in the missing '-')=20
to being equivalent to the

	plot '-', '=3D'

proposed here.  I really don't think we need another special filename=20
for this.

Re: Another small bug reported by Dietmar Warning

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

Ethan Merritt wrote:

> does this mean you are successfully running the current CVS on OpenVMS?

No.  He's not even using OpenVMS, according to his mail.  He found this 
problem in src/gnuplot.opt because the MS VC makefile 
(config/makefile.nt) also uses gnuplot.opt.

Re: Another small bug reported by Dietmar Warning

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

On Thursday 20 January 2005 12:47 pm, Harald Harders wrote:
> +++ ./gnuplot.opt       2005-01-20 21:37:26.000000000 +0100
> @@ -2,6 +2,7 @@
>  axis.obj
>  binary.obj
>  bitmap.obj
> +breaders.obj
>  color.obj

Got it. Thanks.
Dietmar - 
does this mean you are successfully running the current CVS on OpenVMS?

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

Another small bug reported by Dietmar Warning

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

Dietmar has send me another small bug. Here comes the patch:

--- src/gnuplot/cvs/gnuplot/src/gnuplot.opt     2001-07-28
18:43:12.000000000 +0200
+++ ./gnuplot.opt       2005-01-20 21:37:26.000000000 +0100
@@ -2,6 +2,7 @@
 axis.obj
 binary.obj
 bitmap.obj
+breaders.obj
 color.obj
 command.obj


Greetings
Harald

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

Re: [ gnuplot-Patches-1105717 ] Add '=' special file to reread '-' inline data

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

>=20
> >Comment By: Sampo Kellom=E4ki (sampo2)
> Date: 2005-01-20 19:12
>=20
> Message:
> Logged In: YES=20
> user_id=3D1200825
>=20
> BTW, I would much prefer to reply by email and you would get
> quicker replies. However, the message I got from you by mail did
> not have usable reply address. This is bad netiquette in my
> opinion.

You'll have to take that up with SourceForge.
The messages you are reading are auto-generated by the SourceForge
site itself whenever a comment or file is uploaded to
the website.  I agree that it is annoying, and they should=20
auto-generate some real return address.  But they don't.

If you want to join us in Email discussions, please post
and subscrive to the mailing list
	<gnu...@li...>


> I'd say that=20
> a proper redesign using temporary file for pipes might be
> the best thing to do.

That was the topic of discussion on the mailing list recently.
A temporary file is probably the most general answer.
But if you just want to replot the *same* data without
having to read it in again, it should be possible to use
the copy already stored in gnuplot's internal data structures.
So in that sense there are two separate possibilities:

Could re-use existing data with no actual re-reading:
  plot "-" with lines, "=3D" with points
  replot

Never stored the data in the first place, so clearly
would need to re-read:
  plot "-" using 1:2, "=3D" using 3:4


> However, I offer the '=3D' construct as design level
> suggestion on how to do it.

OK.  But still, do you propose that "=3D" is only valid
within a single plot command, or would you also be able
to use it in successive plot commands?=20


> If you can confirm that '=3D' is the official way to do it, I
> can move on with my life

There can be no promise that this will become "the official way"
when we don't even have a fully-working example at the moment.
If there is general agreement that this is a good target syntax,
then it is likely that something of the sort will eventually
make it into the official source.  But the exact details clearly
won't be settled until it has been successfully tried out in
patches to the development tree.

> Until then I'll use my patch even if it has its limitations.

Sure.  Although if you are working on additions to gnuplot I think
it would make sense to base your work on the development tree source
rather than on 4.0.


>=20
> Comment By: Hans-Bernhard Broeker (broeker)
                                     ^^^^^^^

By the way, you can reconstruct real Email addresses by knowing
that the information above refers the username on SourceForge.
So to reply to Hans-Bernhard you could have used
	br...@us...





> Date: 2005-01-20 11:44
>=20
> Message:
> Logged In: YES=20
> user_id=3D27517
>=20
> Error returns from ftell() definitely have to be checked
> here.  In particular, you have to be prepared to int_error()
> out of this if '-' is not a seekable file, i.e. if gnuplot
> is reading from a (redirected or console) stdin instead of a
> script.
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-01-20 05:48
>=20
> Message:
> Logged In: YES=20
> user_id=3D235620
>=20
> Very interesting.
> And either a remarkable coincidence or pretty quick
> programming, since we were just the other day grousing about
> the lack of such a feature.
>=20
> I've attached the equivalent patch against current CVS.
>=20
> Don't you have to test for ftell() returning EBADF or EINVAL?
> Is it  across multiple plots? E.g.:
>    plot '-' with lines
>    ... do some stuff...
>    plot '=3D' with lines
>=20
> I tried that, and it put gnuplot into a very strange state.
> Every keystroke or mouse click caused a replot but I could
> not exit the program.  But I may have used too strange of a
> test case.
>=20
>=20
> ----------------------------------------------------------------------
>=20
> You can respond by visiting:=20
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D302055&aid=3D110571=
7&group_id=3D2055
>=20

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

Re: PDF/PostScript output bottom margin

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

Daniel J Sebald wrote:

> Oh my goodness!  What did I do?  (And what short memory.:-)  I'll have 
> a look at what the issue is.


Well, it seems to have behaved this way before the application of the 
float margins patch.  I must be imagining things.  A larger font size in 
the most recent PDFlib might be the reason pm3d.dem looking different.

Dan