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

Re: PDF/PostScript output bottom margin

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

Ethan Merritt wrote:

>On Wednesday 19 January 2005 08:11 pm, Daniel J Sebald wrote:
>  
>
>>So there seems to be a bug with the bottom margin.  Anyone work on that
>>lately?
>>    
>>
>
>Just your patch changing it to a float.
>
>2005-01-10  Daniel Sebald  <dan...@ie...>
>        * src/gadgets.c src/gadgets.h src/set.c (set_margin) src/show.c
>        (show_margin) src/unset.c (unset_margin): Specify and store plot
>        margins as float rather than int.
>  
>

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

Dan

Re: PDF/PostScript output bottom margin

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

On Wednesday 19 January 2005 08:11 pm, Daniel J Sebald wrote:
> So there seems to be a bug with the bottom margin.  Anyone work on that
> lately?

Just your patch changing it to a float.

2005-01-10  Daniel Sebald  <dan...@ie...>
        * src/gadgets.c src/gadgets.h src/set.c (set_margin) src/show.c
        (show_margin) src/unset.c (unset_margin): Specify and store plot
        margins as float rather than int.

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

PDF/PostScript output bottom margin

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

In my new system, the bottom margin of PDF terminal output and 
PostScript output is off.  I can see in the demos that there is 
basically zero whitespace where there used to be white space on the 
bottom balanced with the white space on the other sides.  The space is 
so small that xlabels and colorboxes extend past the bottom of the 
visual portion of the screen.

Run 'pm3d.dem' in "pdf", "post color solid" and "x11".  "x11" looks OK.  
For PDF, page 21 and 39 are good examples.  (But also, the first plots 
of 'all.pdf' show there is zero margin.)  Oddly, it is only page 39 that 
is off screen in PostScript.  (May be a font thing.)

Oh wait, I just tried the x11 terminal for the 'all.dem'.  It too seems 
a bit close to the edge, but the white space for the coordinates 
balances things out.  However, I typed "set bmargin 1" and got something 
where the key, bottom margin and axis land on top of one another.  It 
continued for about four plots until a "reset" probably fixed matters.

So there seems to be a bug with the bottom margin.  Anyone work on that 
lately?

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Set pagesize [was Re: Clipping of arrows buggy]

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

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.   But what about terminals that
maintain their own values for xmax and ymax (e.g. X11)?

I think you *have* to use the value provided by the terminal.
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.

> This patch has only been tested with postscript and png
> terminal. 

How do you see this option interacting with explicit
size specifications like
   set term png size 800,400

Does your new pagesize apply multiplicatively to these?
Does it override them?

> I know that it does not change the window 
> size in x11 which it should do. But I really don't know
> how gnuplot and gnuplot_x11 talk to each other. gnuplot
> should send a message to gnuplot_x11 to resize the
> window after using 'set pagesize'.

gnuplot does not control the size of the X window, so
there is a serious problem there.  Are you proposing that
we change the code so that a user can not resize the X window
by click-and-drag with the mouse?  If the user changes the
size using the mouse, then what?  Does this feed back to
the main code of gnuplot and change the values of 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?
I.e.   png, svg, fig  and probably others
alread accept a size specification as an option to
"set term".  Why not just add this to other terminals
as desired, assuming they support it at all.



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

Re: gd.trm and multiple plots with png

[Jim K. <je...@kl...>]

Hans-Bernhard Broeker wrote:
> Harald Harders wrote:
> 
>> On Tue, 18 Jan 2005, Ethan Merritt wrote:
> 
>>> The first problem I see is that you have to initialize
>>> the GIF file differently if you want to insert multiple
>>> images, so you have to know in advance that you are
>>> going to do so.   In other words, it won't work to
>>> have term->graphics() simply check whether the file is
>>> already open.  It would have to be a new option
>>>     set term gif {animated}
> 
> Just as clarification: would it fail to work if we always claimed to be 
> going to build an animated GIF, but just make it a single-frame 
> degenerate case of an "animation" in case the user closes output after 
> only one plot?
> 
>>> The gif term for multi-image is "animated", although
>>> this may not be the best keyword to use in gnuplot.
>>> "multiplot" would be better, but it already is being
>>> used for something else.
> 
>> What about "multipage"?
> 
> Full ACK.  Esp. since it exactly matches our existing "help glossary" 
> definition of what a 'page' is.

I have also wanted to create GIF animations.  How hard is it to
crack them back apart into individual images?  Note that the
current behavior for GIF and PNG is to lose all plots subsequent
to the first one.  Would it make sense to define an option to
write these subsequent plots to sequentially numbered files?
Then you choose "multipage" when the GIF should contain
an animation and perhaps "mutifile" when the GIFs should be
written into individual files.  Fail if they already exist?

Re: gd.trm and multiple plots with png

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

On Wednesday 19 January 2005 05:21 am, Hans-Bernhard Broeker wrote:
> > On Tue, 18 Jan 2005, Ethan Merritt wrote:
> 
> >>The first problem I see is that you have to initialize
> >>the GIF file differently if you want to insert multiple
> >>images, so you have to know in advance that you are
> >>going to do so.   In other words, it won't work to
> >>have term->graphics() simply check whether the file is
> >>already open.  It would have to be a new option
> >>	set term gif {animated}
> 
> Just as clarification: would it fail to work if we always claimed to be 
> going to build an animated GIF, but just make it a single-frame 
> degenerate case of an "animation" in case the user closes output after 
> only one plot?

libgd would be fine with that, so far as I know.
But I would worry that not all viewers can handle files
that claim to be animated gifs.  Maybe they can.

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

Re: Clipping of arrows buggy

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

Hans-Bernhard Broeker wrote:

>
>> You have a different understanding of "screen" than I do.
>> "set size" does not change the screen. 
>
>
> Careful there.  This depends on command ordering.
>
> In particular, a 'set size' command issued *before* the terminal is 
> opened, *will* change the screen size, on at least some terminal 
> drivers.  Postscript in EPS mode is one of them, but several others are
> also effected by it --- generally all drivers producing output that 
> supports the notion of a physical output size (something in inches), 
> but don't have a 'size'-like terminal option.  To find all ~18 of 
> them, look for mentions of global variable 'xsize' in any 
> term->graphics() implementation.
>
> Getting this subtle detail confused may well be the core of the 
> problem in Harald's scripts.


I wouldn't have imagined such behavior.  Another reason I've had the 
ambition to write a tutorial summary of graph layout in gnuplot.  (No 
time 'though.)

Dan

Re: Povray terminal output

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

On Wed, Jan 19, 2005 at 06:18:48PM +0100, Harald Harders wrote:
> > Could you draw an expected gnuplot output, e.g. for the "test" page o=
r "plot
> > 1/x", or "splot x*y", by hand, and present it?

  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

> I think it doesn't make sense to export 2d plots to povray.

   I think it does, to be able to mix them with 3D plots.

    Ga=EBl

Re: Povray terminal output

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

I have forgotten one thing.

> Could you draw an expected gnuplot output, e.g. for the "test" page or "plot
> 1/x", or "splot x*y", by hand, and present it?

I think it doesn't make sense to export 2d plots to povray.

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

Re: Povray terminal output

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

On Wed, 19 Jan 2005, Petr Mikulik wrote:

> Some question:
>   - How can povray draw vectors? (I know VRML does not have them.)

I think as combination of a cylinder and a cone.

> Could you draw an expected gnuplot output, e.g. for the "test" page or "plot
> 1/x", or "splot x*y", by hand, and present it?

I have an old picture that uses some axes. It shows how coordinate axes
could be realized:
http://www.harald-harders.de/gnuplot/hindernisabstand1.png (280KB)
http://www.harald-harders.de/gnuplot/hindernisabstand1a.jpg (68KB)

I also have an example for a graph surface. It is available from
http://www.harald-harders.de/gnuplot/funktion3.png (136KB)
http://www.harald-harders.de/gnuplot/funktion3.pov (3716KB)
http://www.harald-harders.de/gnuplot/funktion3.ini (4KB)

May be, this is a little bit more than gnuplot will be able to do (using
glass and mirrors). But it was the least work to use this old picture. :-)

Harald

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

Re: Clipping of arrows buggy

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

On Wed, 19 Jan 2005, Hans-Bernhard Broeker wrote:

> Ethan Merritt wrote:
> > On Tuesday 18 January 2005 11:09 am, Harald Harders wrote:
>
> >>The difference only appears in the 3d plots (both with and without
> >>multiplot). All arrows and labels that start outside the boundaries
> >>0 <= screen coordinate <= 1 are missing. Since the screen may be larger
> >>using 'set size 1.4,1.4', for example, this is not okay for x>1 and y>1.
>
> > You have a different understanding of "screen" than I do.
> > "set size" does not change the screen.
>
> Careful there.  This depends on command ordering.
>
> In particular, a 'set size' command issued *before* the terminal is
> opened, *will* change the screen size, on at least some terminal
> drivers.  Postscript in EPS mode is one of them, but several others are
> also effected by it --- generally all drivers producing output that
> supports the notion of a physical output size (something in inches), but
> don't have a 'size'-like terminal option.  To find all ~18 of them, look
> for mentions of global variable 'xsize' in any term->graphics()
> implementation.
>
> Getting this subtle detail confused may well be the core of the problem
> in Harald's scripts.
>
> > Here's a radically different proposal:
> >
> > The command "set size x, y" should be limited to values
> > of x and y between 0 and 1.
>
> No, for the above-mentioned reason.  To be able to allow this
> modification, we need to add a command 'set pagesize' that takes the
> role of what is now 'set size before set terminal'.

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.

Harald

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

Re: Povray terminal output

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

>    I had a small look into povray and I must say it is quite convenient
> for scientific plotting. I am amazed at the possibilities. Writing a
> terminal driver may actual be more a work of building povray syntax
> blocks that would correspond with gnuplot's rendering engine than writing
> a conventional terminal driver.
>
>    Actually, while writing that I realised that this was probably the step
> where to start to do a povray output in gnuplot (it technically would not
> be a terminal driver, as far as I understand how Gnuplot terminal drivers
> work) : it would have to do most of its work before gnuplot's rendering
> engine.

Some question:
  - How can povray draw vectors? (I know VRML does not have them.)
  - And line thickness is what -- a diameter of a tube, or is it a
    "billboard"-like thickness.
  - And what about point symbols -- should they be billboard-like characters
    or true 3D objects?

Could you draw an expected gnuplot output, e.g. for the "test" page or "plot
1/x", or "splot x*y", by hand, and present it?

---
PM

Re: gd.trm and multiple plots with png

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

> >So we could use this mechanism if we really wanted to.
> >The first problem I see is that you have to initialize
> >the GIF file differently if you want to insert multiple
> >images, so you have to know in advance that you are
> >going to do so.   In other words, it won't work to
> >have term->graphics() simply check whether the file is
> >already open.  It would have to be a new option
> >	set term gif {animated}
> >
> >The gif term for multi-image is "animated", although
> >this may not be the best keyword to use in gnuplot.
> >"multiplot" would be better, but it already is being
> >used for something else.
> >
> >Does anyone think this would be worth the effort?

I've recently built "animation" into the "zimg" program, which normally uses
gd for its output. Before writing the generated image into .gif/.png file,
it is dumping the bitmap into ppm or pgm (ascii) file, which can be
transformed to a movie via animate or convert.

BTW:
	set term gif {animated {delay msec}}

--
PM

Re: Clipping of arrows buggy

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

Ethan Merritt wrote:
> On Tuesday 18 January 2005 11:09 am, Harald Harders wrote:

>>The difference only appears in the 3d plots (both with and without
>>multiplot). All arrows and labels that start outside the boundaries
>>0 <= screen coordinate <= 1 are missing. Since the screen may be larger
>>using 'set size 1.4,1.4', for example, this is not okay for x>1 and y>1.

> You have a different understanding of "screen" than I do.
> "set size" does not change the screen. 

Careful there.  This depends on command ordering.

In particular, a 'set size' command issued *before* the terminal is 
opened, *will* change the screen size, on at least some terminal 
drivers.  Postscript in EPS mode is one of them, but several others are
also effected by it --- generally all drivers producing output that 
supports the notion of a physical output size (something in inches), but 
don't have a 'size'-like terminal option.  To find all ~18 of them, look 
for mentions of global variable 'xsize' in any term->graphics() 
implementation.

Getting this subtle detail confused may well be the core of the problem 
in Harald's scripts.

> Here's a radically different proposal:
> 
> The command "set size x, y" should be limited to values
> of x and y between 0 and 1.

No, for the above-mentioned reason.  To be able to allow this 
modification, we need to add a command 'set pagesize' that takes the 
role of what is now 'set size before set terminal'.

Re: gd.trm and multiple plots with png

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

Harald Harders wrote:
> On Tue, 18 Jan 2005, Ethan Merritt wrote:

>>The first problem I see is that you have to initialize
>>the GIF file differently if you want to insert multiple
>>images, so you have to know in advance that you are
>>going to do so.   In other words, it won't work to
>>have term->graphics() simply check whether the file is
>>already open.  It would have to be a new option
>>	set term gif {animated}

Just as clarification: would it fail to work if we always claimed to be 
going to build an animated GIF, but just make it a single-frame 
degenerate case of an "animation" in case the user closes output after 
only one plot?

>>The gif term for multi-image is "animated", although
>>this may not be the best keyword to use in gnuplot.
>>"multiplot" would be better, but it already is being
>>used for something else.

> What about "multipage"?

Full ACK.  Esp. since it exactly matches our existing "help glossary" 
definition of what a 'page' is.

Re: Clipping of arrows buggy

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

Ethan Merritt wrote:

>On Tuesday 18 January 2005 11:09 am, Harald Harders wrote:
>  
>
>>On Mon, 17 Jan 2005, Ethan Merritt wrote:
>>
>>    
>>
>>>I see no difference in the output before applying your patch
>>>and after applying your patch.  What, exactly, is the change
>>>supposed to be?
>>>      
>>>
>>The difference only appears in the 3d plots (both with and without
>>multiplot). All arrows and labels that start outside the boundaries
>>0 <= screen coordinate <= 1 are missing. Since the screen may be larger
>>using 'set size 1.4,1.4', for example, this is not okay for x>1 and y>1.
>>    
>>
>
>You have a different understanding of "screen" than I do.
>"set size" does not change the screen. 
>
>The documentation says:
> `screen` specifies the screen area (the entire area---not just
>  the portion selected by `set size`), with 0,0 at bottom left
>  and 1,1 at top right
>
>In other words, if it is outside the area
>[0 < screen x < 1][ 0 < screen y < 1]
>it should never be visible.
>  
>

That is my understanding.  The plot examples that Harald I took as 
illustrative plots.  I mean, I wouldn't expect gnuplot to output 
something where the screen occupies less than (or greater than) the 
plotted portion.  For PostScript there is the issue of being able to 
view outside the bounding box and such.  But that is unique to the 
terminal and outside viewer.

>And yes, it is true that labels whose origin is outside the
>visible area will not be drawn.  That is intentional.
>
>So I think the only case being mis-handled by the current code
>is if an arrow starts from off-screen in one direction, crosses
>part of the screen, and terminates at another off-screen location.
>
>Is that the case you are concerned about? 
>  
>

I'd say this is worth the fix.  It's easy to compute where lines 
intersect borders and such if need be... well, a bit tedious but 
straightforward.

>Here's a radically different proposal:
>
>The command "set size x, y" should be limited to values
>of x and y between 0 and 1.  It basically doesn't make sense
>to set a size that is bigger than your screen.  I know some
>people will dislike this because they have existing scripts
>that sort of work, but I think it is a case of relying on
>behavior that is undocumented and not guaranteed.
>  
>

How does the zooming on interactive mouse splot work?  (I.e., the middle 
button of the mouse, moving left and right.  That doesn't require 
scaling greater than one, does it?  I notice that when the zooming in 
that fashion, any labels seem to appear all of a sudden as though they 
are following the "off screen, do not plot whole string" rule.

Aren't there some who will want to use this size greater than one to get 
a larger splot anyway?  Because of splot's larger margins?  I wouldn't 
totally rule out some legitimate use for a larger than 1.0 size.  Not 
immediately anyway.

Dan

Re: Clipping of arrows buggy

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

On Tuesday 18 January 2005 11:09 am, Harald Harders wrote:
> 
> On Mon, 17 Jan 2005, Ethan Merritt wrote:
> 
> >
> > I see no difference in the output before applying your patch
> > and after applying your patch.  What, exactly, is the change
> > supposed to be?
> 
> The difference only appears in the 3d plots (both with and without
> multiplot). All arrows and labels that start outside the boundaries
> 0 <= screen coordinate <= 1 are missing. Since the screen may be larger
> using 'set size 1.4,1.4', for example, this is not okay for x>1 and y>1.

You have a different understanding of "screen" than I do.
"set size" does not change the screen. 

The documentation says:
 `screen` specifies the screen area (the entire area---not just
  the portion selected by `set size`), with 0,0 at bottom left
  and 1,1 at top right

In other words, if it is outside the area
[0 < screen x < 1][ 0 < screen y < 1]
it should never be visible.
And yes, it is true that labels whose origin is outside the
visible area will not be drawn.  That is intentional.

So I think the only case being mis-handled by the current code
is if an arrow starts from off-screen in one direction, crosses
part of the screen, and terminates at another off-screen location.

Is that the case you are concerned about? 

Here's a radically different proposal:

The command "set size x, y" should be limited to values
of x and y between 0 and 1.  It basically doesn't make sense
to set a size that is bigger than your screen.  I know some
people will dislike this because they have existing scripts
that sort of work, but I think it is a case of relying on
behavior that is undocumented and not guaranteed.


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

Re: Clipping of arrows buggy

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

On Tue, 18 Jan 2005, Daniel J Sebald wrote:

> Harald Harders wrote:
>
> >I hope you all see what is the problem I have found. For me it is really
> >important to be able to change the size of the gnuplot eps output files.
> >At the moment, the only way is to use 'set size'.
>
> I'm following now.  Thanks...  One detail:  I see in the example plots
> with the left diagonal arrow that the arrow head appears to come out in
> some strange direction no parallal with the arrow line.  Did you issue
> the command that way?  Or is there another bug here?

I have not seen that. Strange. Seems to be another bug.

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

Re: gd.trm and multiple plots with png

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

Ethan Merritt wrote:

>update:
>
>multi-image GIFs are supported and working in libgd as of
>version 2.0.32  (Nov 2004).
>
>So we could use this mechanism if we really wanted to.
>The first problem I see is that you have to initialize
>the GIF file differently if you want to insert multiple
>images, so you have to know in advance that you are 
>going to do so.   In other words, it won't work to 
>have term->graphics() simply check whether the file is
>already open.  It would have to be a new option 
>	set term gif {animated}
>
>The gif term for multi-image is "animated", although
>this may not be the best keyword to use in gnuplot.
>"multiplot" would be better, but it already is being
>used for something else.
>
>Does anyone think this would be worth the effort?
>  
>
I'm sitting here think about the ability to create a movie of plots, say
to watch the activity in some multidimensional data evolve. PDF files
work fairly well at this if one just keeps hitting return fairly fast.
But creating some output format that could be stepped through with a
viewer or movie player might be a long-term neat capability. Is that
what you have in mind with "animate"?

Dan

Re: Clipping of arrows buggy

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

Harald Harders wrote:

>I hope you all see what is the problem I have found. For me it is really
>important to be able to change the size of the gnuplot eps output files.
>At the moment, the only way is to use 'set size'.
>  
>

I'm following now.  Thanks...  One detail:  I see in the example plots 
with the left diagonal arrow that the arrow head appears to come out in 
some strange direction no parallal with the arrow line.  Did you issue 
the command that way?  Or is there another bug here?

Dan

Re: gd.trm and multiple plots with png

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

On Tue, 18 Jan 2005, Ethan Merritt wrote:

> multi-image GIFs are supported and working in libgd as of
> version 2.0.32  (Nov 2004).
>
> So we could use this mechanism if we really wanted to.
> The first problem I see is that you have to initialize
> the GIF file differently if you want to insert multiple
> images, so you have to know in advance that you are
> going to do so.   In other words, it won't work to
> have term->graphics() simply check whether the file is
> already open.  It would have to be a new option
> 	set term gif {animated}
>
> The gif term for multi-image is "animated", although
> this may not be the best keyword to use in gnuplot.
> "multiplot" would be better, but it already is being
> used for something else.

What about "multipage"?

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

Re: gd.trm and multiple plots with png

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

update:

multi-image GIFs are supported and working in libgd as of
version 2.0.32  (Nov 2004).

So we could use this mechanism if we really wanted to.
The first problem I see is that you have to initialize
the GIF file differently if you want to insert multiple
images, so you have to know in advance that you are 
going to do so.   In other words, it won't work to 
have term->graphics() simply check whether the file is
already open.  It would have to be a new option 
	set term gif {animated}

The gif term for multi-image is "animated", although
this may not be the best keyword to use in gnuplot.
"multiplot" would be better, but it already is being
used for something else.

Does anyone think this would be worth the effort?
 




On Saturday 15 January 2005 01:12 pm, Ethan Merritt wrote:
> On Thursday 13 January 2005 05:02 pm, Hans-Bernhard Broeker wrote:
> >
> > It may not even be strictly necessary --- at least not for GIF files
> > generated by gd.trm.  GIF files can, at least in principle, hold
> > multiple pages.  But I suspect the GD library doesn't support this
> > (admittedly rarely used) feature, so gd.trm can't do anything about
> > that.
> 
> Tom Boutell says it is scheduled for an upcoming version of libgd.
> And, as I mentioned already, png could be supported this way also.
> But I don't know of any specific plans to add multi-image png
> support to libgd.


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

Re: Clipping of arrows buggy

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

Hello everybody,

I send one answer to all your comments. Please have a look to
www.harald-harders.de/gnuplot/gnuplotbug.tar.gz
It contains two gnuplot files that produce eps or png output respectively.
And it contains the two subdirectories containing the output produced
using the cvs version and the patched version.



On Mon, 17 Jan 2005, Ethan Merritt wrote:

> > In large splots with screen size above 1, arrows that are totally outside
> > the screen coordinates 1,1 are not plotted, see example:
>
> I see no difference in the output before applying your patch
> and after applying your patch.  What, exactly, is the change
> supposed to be?

The difference only appears in the 3d plots (both with and without
multiplot). All arrows and labels that start outside the boundaries
0 <= screen coordinate <= 1 are missing. Since the screen may be larger
using 'set size 1.4,1.4', for example, this is not okay for x>1 and y>1.




On Tue, 18 Jan 2005, Hans-Bernhard Broeker wrote:

> > In large splots with screen size above 1, arrows that are totally outside
> > the screen coordinates 1,1 are not plotted, see example:
>
> It might help if you explained in more detail what *exactly* is wrong
> about the multi-page output generated by this script.  This is probably
> related to this old bug report at SF.net:

The bug is not in the multi-page output and not in the multiplot output
but appears with 3d plots when the screen is larger than 1.0,1,0. All
arrows and labels with screen coordinates >1 that are inside the
visible area are cut off.

> I don't think 'set size' being larger than one is supposed to have
> anything to do with this --- 'screen' coordinates are meant to be
> relative to the actual screen size, not the default.

This might be wanted but it is not the case. See the example. The arrows
with screen coordinate 1 are always at the same position, independent of
the size given by 'set size'.



On Mon, 17 Jan 2005, Daniel J Sebald wrote:

> I'm not understanding this one either, Harald.  I've run your example,
> and the arrows that are visible make sense.  They are specified relative
> to the screen and come out looking the same in all plots.  However, the
> plots are extended past the visible part of the plot.  I think I
> understand that the arrow you've plotted
>
> set arrow from screen 1.1,0 rto screen 0,.5 as 1
>
> doesn't appear.  However, that shouldn't appear because no portion of it
> lies within the visible part of the image.

Of course they are in the visible part of the image. By using
    set size 1.4,1.4
I enlarge the visible part of the image. But still a rectangle between the
coordinates screen 0,0 and screen 1,1 has the original size and is not the
boundary of the visible screen anymore. Then, arrows and labels with
screen coordinates larger than 1 have to be plotted.

>  On the other hand, it still
> doesn't appear even if a *portion* of the arrow should appear on the
> screen.  So that may be your point, no?  For example, changing the above to
> set arrow from screen 1.1,0 rto screen -.5,.5 as 1
> should give a portion of an arrow.  That should be made to work fairly
> easy.  Afterall, the enlarged splots and plots show only a portion of
> the axis on the screen.  The arrows shouldn't be done any differently.

Again, the visible part of the plot is enlarged by using
    set size 1.4,1.4
at least for both eps and png terminals. For x11 terminal, the behaviour
is as described by Dan. I think, it is a bug of the x11 terminal.
Otherwise gnuplot would not have a possibility to change the size of eps
output.

> Can the conditional test be removed altogether?  The clipping should be
> done at a lower level I would think.

I agree. It should appear to every output.



I hope you all see what is the problem I have found. For me it is really
important to be able to change the size of the gnuplot eps output files.
At the moment, the only way is to use 'set size'.

There is another problem: If you remove the 'set size' command in line 48,
the 4th plot does not have the global size 1.4,1.4 as the other plots but
gets the global size 0.8,0.8. I think a size given inside
set multiplot ... unset multiplot
may not change the global size of the screen. Thus, in term_end_multi, the
xsize and ysize at 'set multiplot' should be restored.

Harald

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

Re: Povray terminal output

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

> >That issue of 2D vs. 3D is actually a major part of the problem.=20
> >gnuplot's terminal driver layer is entirely 2D by design.  The only=20
> >case where 3D data actually survives into an splot's output is 'set=20
> >term table

>  But again, I'd=20
> wait until 2D/3D are made more similar before attempting anything like =
that.

   To sum up what I have understood the terminal driver does not
currently take care of the 3D rendering, it is just a 2D output filter.
Well, as you will probably at some point restructure Gnuplot way of
handling 2D/3D by probably creating a suited abstraction layer (every
2D/3D program inventuily runs into that problem), I think you could think
have a close look into a povray output.

   I had a small look into povray and I must say it is quite convenient
for scientific plotting. I am amazed at the possibilities. Writing a
terminal driver may actual be more a work of building povray syntax
blocks that would correspond with gnuplot's rendering engine than writing
a conventional terminal driver.

   Actually, while writing that I realised that this was probably the ste=
p
where to start to do a povray output in gnuplot (it technically would not
be a terminal driver, as far as I understand how Gnuplot terminal drivers
work) : it would have to do most of its work before gnuplot's rendering
engine.

    Well I know nothing of Gnuplot's internals, so I think I am going to
stop my speculations now.

        Ga=EBl

Re: Bug or pipe issue?

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

> I just noticed that not all functions on the mouse work after doing a
> plot from inline data.  Is this a pipe issue?  Try
>
> plot '-' u 0:1
> 1
> 2
> 3
> 4
> e
>
> After, zooming can't be done.  Although, the center mouse button still
> works.

All commands which require 'replot' are disabled for piped data.

--
PM