gnuplot-beta

Clipping of arrows buggy

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

In large splots with screen size above 1, arrows that are totally outside
the screen coordinates 1,1 are not plotted, see example:

set size 1.8,1.8
set terminal postscript color linewidth 4
set output 'gnuplotbug.ps'
set style arrow 1 nohead lt 1 front
set xrange [0:1]
set yrange [0:1]
set zrange [0:1]
set arrow from screen 1,0 rto screen 0,1 as 1
set arrow from screen 0,1 rto screen 1,0 as 1
set arrow from screen 0,0 rto screen 0,1 as 1
set arrow from screen 0,0 rto screen 1,0 as 1
set arrow from screen 1.1,0 rto screen 0,.5 as 1
set arrow from screen 0.9,0 rto screen 0,.5 as 1
set label '1' at screen 0.9,0.9
set label '2' at screen 1.0,1.0
set label '3' at screen 1.1,1.1
set label '4' at screen 0.1,0.1
set label '5' at screen 0.0,0.0
set label '6' at screen -0.1,-0.1
splot 1/0 notitle
plot 1/0 notitle
set multiplot
set size 0.8,0.8
set origin 0.1,0.1
splot 1/0 notitle
unset multiplot
set multiplot
set size 0.8,0.8
set origin 0.1,0.1
plot 1/0 notitle
unset multiplot
set output

I have written a patch that seems to work both with and without multiplot.
There is still one strange thing: Have a look at the arrows at the upper
corners. In 2d plots they are there, in 3d plots they are cut off. What is
the right behaviour?

Harald






Here is the patch:

diff -uNr orig/src/gadgets.c arrow/src/gadgets.c
--- orig/src/gadgets.c	2005-01-11 17:39:34.000000000 +0100
+++ arrow/src/gadgets.c	2005-01-17 22:41:05.000000000 +0100
@@ -62,6 +62,8 @@
 float xsize = 1.0;		/* scale factor for size */
 float ysize = 1.0;		/* scale factor for size */
 float zsize = 1.0;		/* scale factor for size */
+float global_xsize = 1.0;	/* scale factor for size */
+float global_ysize = 1.0;	/* scale factor for size */
 float xoffset = 0.0;		/* x origin */
 float yoffset = 0.0;		/* y origin */
 float aspect_ratio = 0.0;	/* don't attempt to force it */
diff -uNr orig/src/gadgets.h arrow/src/gadgets.h
--- orig/src/gadgets.h	2005-01-11 17:39:34.000000000 +0100
+++ arrow/src/gadgets.h	2005-01-17 22:37:56.000000000 +0100
@@ -249,6 +249,8 @@
 extern float xsize;		/* x scale factor for size */
 extern float ysize;		/* y scale factor for size */
 extern float zsize;		/* z scale factor for size */
+extern float global_xsize;	/* x scale factor for size */
+extern float global_ysize;	/* y scale factor for size */
 extern float xoffset;		/* x origin setting */
 extern float yoffset;		/* y origin setting */
 extern float aspect_ratio;	/* 1.0 for square */
diff -uNr orig/src/graph3d.c arrow/src/graph3d.c
--- orig/src/graph3d.c	2005-01-05 21:48:48.000000000 +0100
+++ arrow/src/graph3d.c	2005-01-17 22:47:42.000000000 +0100
@@ -453,8 +453,15 @@

     /* EAM  FIXME - Is this a sufficiently general test for out-of-bounds? */
     /*              Should we test the other end of the arrow also?        */
-    if (*sx < 0 || *sx > term->xmax || *sy < 0 || *sy > term->ymax)
+    if ((*sx < 0) ||
+	(multiplot && (*sx > term->xmax * global_xsize)) ||
+	(!multiplot && (*sx > term->xmax * xsize)) ||
+	(*sy < 0) ||
+	(multiplot && (*sy > term->ymax * global_ysize)) ||
+	(!multiplot && (*sy > term->ymax * ysize))) {
+	FPRINTF((stderr,"get_arrow3d: skipping out-of-bounds arrow\n"));
 	return FALSE;
+    }

     if (arrow->relative) {
 	map3d_position_r(&(arrow->end), ex, ey, "arrow");
@@ -484,7 +491,12 @@
 	map3d_position(&this_label->place, &x, &y, "label");

 	/* EAM FIXME - Is this a sufficient test for out-of-bounds? */
-	if (x < 0 || x > term->xmax || y < 0 || y > term->ymax) {
+	if ((x < 0) ||
+	    (multiplot && (x > term->xmax * global_xsize)) ||
+	    (!multiplot && (x > term->xmax * xsize)) ||
+	    (y < 0) ||
+	    (multiplot && (y > term->ymax * global_ysize)) ||
+	    (!multiplot && (y > term->ymax * ysize))) {
 	    FPRINTF((stderr,"place_labels3d: skipping out-of-bounds label\n"));
 	    continue;
 	}
diff -uNr orig/src/set.c arrow/src/set.c
--- orig/src/set.c	2005-01-12 20:38:52.000000000 +0100
+++ arrow/src/set.c	2005-01-17 22:39:43.000000000 +0100
@@ -3070,6 +3070,10 @@
 	    }
 	}
     }
+    if (!multiplot) {
+	global_xsize = xsize;
+	global_ysize = ysize;
+    }
 }


diff -uNr orig/src/term.c arrow/src/term.c
--- orig/src/term.c	2005-01-12 20:38:52.000000000 +0100
+++ arrow/src/term.c	2005-01-17 22:39:18.000000000 +0100
@@ -606,7 +606,10 @@

     multiplot = TRUE;
     mp_layout.auto_layout = FALSE;
-
+
+    global_xsize = xsize;
+    global_ysize = ysize;
+
     /* check for optional multiplot layout */
     if (!END_OF_COMMAND && almost_equals(c_token,"lay$out")) {
 	struct value a;


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

Re: Clipping of arrows buggy

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

On Monday 17 January 2005 01:50 pm, Harald Harders wrote:
> 
> In large splots with screen size above 1, arrows that are totally outside
> the screen coordinates 1,1 are not plotted, see example:

Harald:

I see no difference in the output before applying your patch
and after applying your patch.  What, exactly, is the change
supposed to be?


-- 
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...>]

Ethan Merritt wrote:

>On Monday 17 January 2005 01:50 pm, Harald Harders wrote:
>  
>
>>In large splots with screen size above 1, arrows that are totally outside
>>the screen coordinates 1,1 are not plotted, see example:
>>    
>>
>
>Harald:
>
>I see no difference in the output before applying your patch
>and after applying your patch.  What, exactly, is the change
>supposed to be?
>  
>

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.  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.  
Can the conditional test be removed altogether?  The clipping should be 
done at a lower level I would think.

Dan

PS:  One other thing I notice about splot is that the tics appear right 
up against the x and y axes.  The z tics look nice.

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: 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

[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

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

Harald Harders 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:

[ 839739 ] 'set arrow' to far away points causes garbage

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.

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: 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: 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: 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

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: 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: 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: 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: 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: 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, 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 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