gnuplot-beta

Again: canvas size

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

In the last days, I have thought about the canvas size discussion we had
in this mailing list.

At the moment, there are two different possibilities to change
the canvas size (partly depending on the terminal):

- Use 'set size xcan,ycan' before using 'set terminal'.
  This leads to screen coordinates 0,0 in the lower left corner and
  xcan,ycan in the upper right corner.

- Use 'set terminal <term> size xterm,yterm'.
  This leads to screen coordinates 0,0 in the lower left corner and
  1,1 in the upper right corner.

In my opinion, both possibilities are necessary.

Of course, it is a good thing to specify the canvas size in
terminal-dependent, absolute values, using 'set terminal <term> size'. And
in many cases, it is good to reach a canvas that has the screen
coordinates 0,0 and 1,1 for the lower left and upper right corner,
respectively.

But there are also cases, where a screen coordinate unequal to 1,1 for the
upper right corner is useful:
Say, you want to have many plots in one document with identical size. If
one of these plots is a multiplot, it is useful to have a canvas with
maximal screen coordinates 1,2.

I propose following structure:

- The canvas size is defined exclusively by the 'set terminal' commands,
  e.g., 'set terminal png size 640,480' or 'set term post size 6in,4in'.
- Inside the bounds of the canvas, the screen coordinate system can be set
  by another command, e.g.,
  'set screen-coordinate min <xmin>,<ymin> max <xmax>,<ymax>'
  where defaults are xmin=0, ymin=0, xmax=1, ymax=1.
  This command does not change the canvas size, e.g., Bounding Box (in
  contrast to the current 'set size' command before 'set terminal').

In the case mentioned above, you could use for a single plot:

set screen-coordinate max 1,1
set terminal postscript size 5in,3in

And for a multiplot, you can use

set screen-coordinate max 1,2
set terminal postscript size 5in,6in

This would lead to identical absolute screen coordinate lengths in both
cases.

What do you think of this structure?

Best regards
Harald

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

Re: Again: canvas size

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

On Monday 10 October 2005 02:37 pm, Harald Harders wrote:
> At the moment, there are two different possibilities to change
> the canvas size (partly depending on the terminal):
> 
> - Use 'set size xcan,ycan' before using 'set terminal'.
>   This leads to screen coordinates 0,0 in the lower left corner and
>   xcan,ycan in the upper right corner.

That does seem to be true currently.
I really dislike this as being totally counter-intuitive.   
See for example, today's bug report #1324011


> - Use 'set terminal <term> size xterm,yterm'.
>   This leads to screen coordinates 0,0 in the lower left corner and
>   1,1 in the upper right corner.

This is not true currently.
What it does is to define range screen 0 -> screen 1 as spanning
xterm pixels.  That may or may not be the same as the upper right
corner of the screen, as you pointed out yourself just above.
 
> Say, you want to have many plots in one document with identical size. If
> one of these plots is a multiplot, it is useful to have a canvas with
> maximal screen coordinates 1,2.

I am totally lost here.  Can you post a web page that contains an 
example of such a document?  Won't you get exactly what you describe
without specifying "set size" at all?  Each plot, multi- or single-
will be of identical size.

 
> I propose following structure:
> 
> - The canvas size is defined exclusively by the 'set terminal' commands,
>   e.g., 'set terminal png size 640,480' or 'set term post size 6in,4in'.

I agree with this part.

> And for a multiplot, you can use
> 
> set screen-coordinate max 1,2
> set terminal postscript size 5in,6in
> 
> This would lead to identical absolute screen coordinate lengths in both
> cases.

I do not understand this at all. 
What is "screen coordinate length"?
Consider the two following command sequences:

A)
set term png size 200,200
set output 'A.png'
set screen-coord max 1,1
set multiplot layout 2,1
plot <foo>
plot <baz>

B)
set term png size 200,200
set output 'B.png'
set screen-coord max 1,2
set multiplot layout 2,1
plot <foo>
plot <baz>

Both png images are 200x200 pixels, right?
Will B.png contain both plots, or will it only contain one of them?
If it contains both, in what way does it differ from A.png?
 
> What do you think of this structure?

So far I don't understand it :-)


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

Re: Again: canvas size

[Robert H. <en...@no...>]

On Tue, 11 Oct 2005, Ethan Merritt wrote:

> > Say, you want to have many plots in one document with identical size. If
> > one of these plots is a multiplot, it is useful to have a canvas with
> > maximal screen coordinates 1,2.
> 
> I am totally lost here.  Can you post a web page that contains an 
> example of such a document?  Won't you get exactly what you describe
> without specifying "set size" at all?  Each plot, multi- or single-
> will be of identical size.

I assume the meaning is: A document contains a number of plots most of
which is plotted at a "default size". For some reason the author happens
to want to include a multiplot at such a size that each sub plot is the
same size as all the rest.

To be honest, the more I think about it, the less sure I am that multiplot
is/was a good idea. Surely just as gnuplot isn't a data-processing
application, it also isn't a page layout program either. Are there any
uses for multiplot that couldn't be just as easily acheived by montaging
the plots together in an Image Editor, DTP, LaTeX, or whatever?

Rob



This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Again: canvas size

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

On Tuesday 11 October 2005 04:34 pm, Robert Hart wrote:
> 
> To be honest, the more I think about it, the less sure I am that multiplot
> is/was a good idea. Surely just as gnuplot isn't a data-processing
> application, it also isn't a page layout program either. Are there any
> uses for multiplot that couldn't be just as easily acheived by montaging
> the plots together in an Image Editor, DTP, LaTeX, or whatever?

Yes, but they are not exactly the ones that multiplot was originally 
designed to produce.

So far as I can see, the thing it is most useful for is to produce
stacked plots. See, for example, the "finance" demo provided by
John Bollinger	
    http://gnuplot.sourceforge.net/demo_4.1/finance.html

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

Re: Again: canvas size

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

On Tue, Oct 11, 2005 at 05:19:54PM -0700, Ethan Merritt wrote:
>     http://gnuplot.sourceforge.net/demo_4.1/finance.html

    By the way, the fonts are tiny and unreadable in my browser (Firefox)
for the demo webpages. I am the only one this happens to ?

--
    Ga=EBl

Re: Again: canvas size

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

On Tuesday 11 October 2005 11:16 pm, Ga=EBl Varoquaux wrote:
>     By the way, the fonts are tiny and unreadable in my browser (Firefox)
> for the demo webpages. I am the only one this happens to ?

The web pages as a whole should appear in normal fonts.

The embedded text of the demo scripts is written with style spec
 LISTING, PRE=20
        {
        margin-left: 2%   ;
        line-height: 1.00 ;
        font-size: 0.5em ;
        }

This should result in half-size monospaced text. The intent is=20
that the script is less likely to overlap with the plot itself.

The size it appears in your browser will depend on what you have
set as a default size for the monospace font, and the minimum
fontsize overall. =20

=46or me it comes out small but very legible in firefox.
But I see that it is hitting the minimum fontsize limit (9)
rather than the default/2 (12/2=3D6), so I will increase that spec
on the web site to fontsize to 75% of default instead.
See if that is better for you.


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

Re: Again: canvas size

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

On Wed, Oct 12, 2005 at 02:35:33PM -0700, Ethan Merritt wrote:
> On Tuesday 11 October 2005 11:16 pm, Ga=EBl Varoquaux wrote:
> >     By the way, the fonts are tiny and unreadable in my browser (Fire=
fox)
> > for the demo webpages. I am the only one this happens to ?

> For me it comes out small but very legible in firefox.
> But I see that it is hitting the minimum fontsize limit (9)
> rather than the default/2 (12/2=3D6), so I will increase that spec
> on the web site to fontsize to 75% of default instead.
> See if that is better for you.

    Currently (thursday 13th, 8am paris time) the code in the 4.1 demos
are unreadable, but the 4.0 demos are very nice. That's the case with
firefox, both on a Ubuntu box, and on a win2k box (both have 1024x768=20
screens), but not with IE 5.5.

--
    Ga=EBl

Re: Again: canvas size

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

Robert Hart wrote:
> I assume the meaning is: A document contains a number of plots most of
> which is plotted at a "default size". For some reason the author happens
> to want to include a multiplot at such a size that each sub plot is the
> same size as all the rest.

Using multiplot is certainly not the best possible way of achieving that 
goal.

> To be honest, the more I think about it, the less sure I am that multiplot
> is/was a good idea. 

It was a good idea alright --- it's just not a panacea.  But then, what 
ever is?  It works well enough for its main purpose (multiple plots with 
locked axes, inset plots, ...), and it's much easier to implement inside 
gnuplot than outside.

Re: Again: canvas size

[Robert H. <en...@no...>]

On Wed, 2005-10-12 at 13:52 +0200, Hans-Bernhard Broeker wrote:
> Robert Hart wrote:
> > I assume the meaning is: A document contains a number of plots most of
> > which is plotted at a "default size". For some reason the author happens
> > to want to include a multiplot at such a size that each sub plot is the
> > same size as all the rest.
> 
> Using multiplot is certainly not the best possible way of achieving that 
> goal.
> 
> > To be honest, the more I think about it, the less sure I am that multiplot
> > is/was a good idea. 
> 
> It was a good idea alright --- it's just not a panacea.  But then, what 
> ever is?  It works well enough for its main purpose (multiple plots with 
> locked axes, inset plots, ...), and it's much easier to implement inside 
> gnuplot than outside.

Sorry I didn't intend to sound critical. I'm aware that there are
certain things that are *best* achieved by using multiplot such as the
inset plot, or two abutting plots (as in the finance demo), but the
impression I go when reading the documentation was that the primary (and
simplest) use is to just group together a series of plots on a page.

It also seems like a bit of a kludge to use because it doesn't work well
with the generally interactive nature of gnuplot. 

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Again: canvas size

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

On Tue, 11 Oct 2005, Ethan Merritt wrote:

> On Monday 10 October 2005 02:37 pm, Harald Harders wrote:
> > At the moment, there are two different possibilities to change
> > the canvas size (partly depending on the terminal):
> >
> > - Use 'set size xcan,ycan' before using 'set terminal'.
> >   This leads to screen coordinates 0,0 in the lower left corner and
> >   xcan,ycan in the upper right corner.
>
> That does seem to be true currently.
> I really dislike this as being totally counter-intuitive.
> See for example, today's bug report #1324011
>
> > - Use 'set terminal <term> size xterm,yterm'.
> >   This leads to screen coordinates 0,0 in the lower left corner and
> >   1,1 in the upper right corner.
>
> This is not true currently.

I ment the default case without prior 'set size'.

> > Say, you want to have many plots in one document with identical size. If
> > one of these plots is a multiplot, it is useful to have a canvas with
> > maximal screen coordinates 1,2.
>
> I am totally lost here.  Can you post a web page that contains an
> example of such a document?  Won't you get exactly what you describe
> without specifying "set size" at all?  Each plot, multi- or single-
> will be of identical size.

You could compare the screen coordinate ranges with the ranges in a plot.
Would you understand if I say:

set xscreenrange [0:1]
set yscreenrange [0:2]

This would mean, the lower left corner of the canvas has the screen
coordinates 0,0 and the upper right has 1,2.

Have a look at http://www.harald-harders.de/gnuplot/canvas/

> > I propose following structure:
> >
> > - The canvas size is defined exclusively by the 'set terminal' commands,
> >   e.g., 'set terminal png size 640,480' or 'set term post size 6in,4in'.
>
> I agree with this part.
>
> > And for a multiplot, you can use
> >
> > set screen-coordinate max 1,2
> > set terminal postscript size 5in,6in
> >
> > This would lead to identical absolute screen coordinate lengths in both
> > cases.
>
> I do not understand this at all.
> What is "screen coordinate length"?

I do not know the correct English term. If you draw an arrow from screen
0,0 to screen 1,1 in a plot with

set screen-coordinate max 1,1
set terminal postscript size 4in,3in

and the same arrow (0,0 to 1,1) in a plot with

set screen-coordinate max 1,2
set terminal postscript size 4in,6in

this would lead to two identical arrows while in

set screen-coordinate max 1,1
set terminal postscript size 4in,6in

the arrow would point to a position at double height of the first two
cases.


> Consider the two following command sequences:
>
> A)
> set term png size 200,200
> set output 'A.png'
> set screen-coord max 1,1
> set multiplot layout 2,1
> plot <foo>
> plot <baz>
>
> B)
> set term png size 200,200
> set output 'B.png'
> set screen-coord max 1,2
> set multiplot layout 2,1
> plot <foo>
> plot <baz>
>
> Both png images are 200x200 pixels, right?
> Will B.png contain both plots, or will it only contain one of them?
> If it contains both, in what way does it differ from A.png?

I am not talking about the automatically scaled plots but of plots that
have a defined size given by the user. See the www page for that.
Of course, automatically placed and scaled plots shall not be influenced
by the 'set screen-coord' command.

Best regards
Harald

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

Re: Again: canvas size

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

On Wednesday 12 October 2005 06:34 am, Harald Harders wrote:
> set xscreenrange [0:1]
> set yscreenrange [0:2]
> 
> Have a look at http://www.harald-harders.de/gnuplot/canvas/

I remain unconvinced.

The only reason that your plots need to have these odd screen
ranges is that they specify per-plot arrows in terms of
screen coordinates rather than graph coordinates.

If you don't want the arrow to scale with the screen size,
then why are you specifying them in screen coordinates?

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

Re: Again: canvas size

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

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 06:34 am, Harald Harders wrote:
> > set xscreenrange [0:1]
> > set yscreenrange [0:2]
> >
> > Have a look at http://www.harald-harders.de/gnuplot/canvas/
>
> I remain unconvinced.
>
> The only reason that your plots need to have these odd screen
> ranges is that they specify per-plot arrows in terms of
> screen coordinates rather than graph coordinates.
>
> If you don't want the arrow to scale with the screen size,
> then why are you specifying them in screen coordinates?

Because I also do not want them to scale with the graph size. I do want to
have arrows that have the same length in absolute coordinates, say mm or
inches. I use larger canvas sizes mainly for multiplots where two plots
are above each other, often with different heights. And all these plots,
single plots and multiplots have the same arrow lengths. Of course I could
use 'character' as absolute measure which does not scale with the canvas
size, but there is no fixed relation between x and y length.

Until now, the screen coordinates are the only measure (except character,
see above) that can remain constant independent on the graph, canvas or
whatever size. If the screen coordinate system is changed to be hardcoded
to range 0:1 the only absolute coordinate system gets lost.

And I also do not see why there shall not be a coordinate system that
allows two plots to have identical sizes independently on the canvas size.

Where is the advantage of generating two plots with the same size by
giving different measures:

set terminal png size 640,480
set multiplot
set size 1,1
...

and

set terminal png size 640,600
set multiplot
set size 1,480./600

I do not understand this.

I do not understand your reluctance against a coordinate system with an
absolute manner. In particular because I also agree that the default
should be that the screen coordinate system scale with the canvas.
Maybe, we have a different view of the canvas size. For you it appears to
be a scaling factor for the plots (but for that, I really can rescale my
output in standard size). For me, the canvas size is the size of an area
where I can put everything. If you use A3 paper instead of A4 paper, you
still have the possibility of plotting a square of 10 x 10 mm. You do not
have to say: "I plot a square of 10/sqrt(2) * 10/sqrt(2) A3-mm".

I of course would also agree with a new coordinate system that may really
use absolute coordinates as millimeters. But this seems not to be possible
because many terminals do not have this measure.

So, why not a coordinate system that's unit is constant, x mm for
Postscript, y Pixel for screen or pixel terminals independent on canvas
size?  And because pixel are not defined in postscript and inches,
millimeter, and pt are not defined for screen terminals (while they were
defined for pixel-based terminals if the resolution could be given), a
pragmatic default scaling has to be defined. And why not using range 0 to
1 for the default canvas size?

Maybe, a measure millimeter should be introduced that used a resolution
for pixel-based terminals and either the resolution of the window manager
or a fall-back of 75 or 72 dpi for screen terminals.

I am strict against to dispose a coordinate system that stays constant
when resizing the canvas.

I assume that you still are not convinced but I nevertheless hope so.

Best regards
Harald

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

Re: Again: canvas size

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

On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> 
> Until now, the screen coordinates are the only measure (except character,
> see above) that can remain constant independent on the graph, canvas or
> whatever size. If the screen coordinate system is changed to be hardcoded
> to range 0:1 the only absolute coordinate system gets lost.

Then let let us fix that problem directly, instead of mis-using the
screen size simply to allow specification of arrows in absolute coordinates.

Introduce a new coordinate system "absolute", or maybe even the specific
units  "in", "cm", "pt", "pixel".

That would work far better than misusing the screen coords, because the
screen coords are not guaranteed to have an aspect ratio of 1.  Indeed
usually they do not, which I have noticed is a problem for generating
arrowheads that look the same independent of the direction the arrow is
pointing.


> Where is the advantage of generating two plots with the same size by
> giving different measures:
> 
> set terminal png size 640,480
> set multiplot
> set size 1,1
> ...
> 
> and
> 
> set terminal png size 640,600
> set multiplot
> set size 1,480./600
> 
> I do not understand this.

If those two command sequences produce the same result, it is a bug.
But they don't.

The first one produces a 640x480 image that is entirely filled
by the plot.

The second one produces a 640x600 image that contains a plot
in the lower 480 pixels, but is blank above that.  Presumably that
blank area will be occupied by the next plot in the multiplot
sequence.  Is that not the entire purpose of multiplot?


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

Re: Again: canvas size

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

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> >
> > Until now, the screen coordinates are the only measure (except character,
> > see above) that can remain constant independent on the graph, canvas or
> > whatever size. If the screen coordinate system is changed to be hardcoded
> > to range 0:1 the only absolute coordinate system gets lost.
>
> Then let let us fix that problem directly, instead of mis-using the
> screen size simply to allow specification of arrows in absolute coordinates.
>
> Introduce a new coordinate system "absolute", or maybe even the specific
> units  "in", "cm", "pt", "pixel".

I totally agree with this approach. The specific units have too problems:
How shall pixel defined in vector terminals, and how shall in, ch, pt be
defined in terminals without a absolute canvas size? For png and jpeg, a
resolution in dpi could be given and thus in, ch, and pt also used. But
what about x11 and windows? Do they have access to the system-wide
resolution settings?

> > Where is the advantage of generating two plots with the same size by
> > giving different measures:
> >
> > set terminal png size 640,480
> > set multiplot
> > set size 1,1
> > ...
> >
> > and
> >
> > set terminal png size 640,600
> > set multiplot
> > set size 1,480./600
> >
> > I do not understand this.
>
> If those two command sequences produce the same result, it is a bug.
> But they don't.
>
> The first one produces a 640x480 image that is entirely filled
> by the plot.
>
> The second one produces a 640x600 image that contains a plot
> in the lower 480 pixels, but is blank above that.

Which is the same plot on different canvas (what is the plural of
canvas?). Our do you tell twice the same drawing to be different only
because they are placed in different frames?

> Presumably that
> blank area will be occupied by the next plot in the multiplot
> sequence.  Is that not the entire purpose of multiplot?

Yes, the multiplot command is ment for this. I often use one big plot in
the upper part (which is meant to have the same size as my normal, single
plots) and a smaller plot under it. Here, the automatic placement of
gnuplot cannot work. But let's stop discussing about this because the
abolute measurements are okay for both of us. What do the others say to
that suggestion?

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

Re: Again: canvas size

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

On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> 
> I of course would also agree with a new coordinate system that may really
> use absolute coordinates as millimeters. But this seems not to be possible
> because many terminals do not have this measure.

But also many terminals (essentially ALL of them :-) do not consistently
support sizes greater than 1.

Here is a quick survey of terminals I can easily test.

Arguably, the only terminal to get it right is mif.trm.

If I am being generous, I can point out that I patched the abort/failure
in cgm.trm last week.

If I am being even more generous, then I can accept that fig.trm also does
something reasonable although it's not what I expected it to do.

All other terminals that I tested have problems of varying severity.

Test sequence of commands
---------------------------

gnuplot> set size 2,2
gnuplot> set term <TERMINAL>
gnuplot> set output <foo.TERMINAL>
gnuplot> plot sin(x)

Results
---------

post.trm	full plot is drawn - bounding box goes negative
gd.trm		full plot is drawn - size is twice that requested
fig.trm		full plot is drawn - size is twice that expected

mif.trm		full plot is drawn but bounding box describes only
		lower left corner. Arguably this is the only terminal
		to get it right!

dumb.trm	segfault after next command

pdf.trm		lower left quarter of plot is drawn

x11.trm		lower left quarter of plot is drawn

epslatex	left 2/3 of plot is drawn  (bizarre!)

cgm.trm		gnuplot: ../term/cgm.trm:1282: CGM_write_int: 
		Assertion `value <= 32767' failed.
		Abort

emf.trm		gnuplot: ../term/emf.trm:860: EMF_move: 
		Assertion `x < term->xmax && y < term->ymax' failed.
		Abort


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

Re: Again: canvas size

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

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> >
> > I of course would also agree with a new coordinate system that may really
> > use absolute coordinates as millimeters. But this seems not to be possible
> > because many terminals do not have this measure.
>
> But also many terminals (essentially ALL of them :-) do not consistently
> support sizes greater than 1.

Let me extend your list.

> gnuplot> set size 2,2
> gnuplot> set term <TERMINAL>
> gnuplot> set output <foo.TERMINAL>
> gnuplot> plot sin(x)
>
> Results
> ---------
>
> post.trm	full plot is drawn - bounding box goes negative

post.trm (eps mode)   works correctly

> gd.trm		full plot is drawn - size is twice that requested

Here, the labels are missing outside 1,1 (without my patch). The double
size is unexpected by consistent with other terminals as postscript. But I
also see this as a bug.

> fig.trm		full plot is drawn - size is twice that expected
>
> mif.trm		full plot is drawn but bounding box describes only
> 		lower left corner. Arguably this is the only terminal
> 		to get it right!
>
> dumb.trm	segfault after next command
>
> pdf.trm		lower left quarter of plot is drawn
>
> x11.trm		lower left quarter of plot is drawn
>
> epslatex	left 2/3 of plot is drawn  (bizarre!)

Here, the whole plot is there, but all text outside 1,1 is ignored. Using
my small patch (available on the www page), the epslatex plot gets
correct.

> cgm.trm		gnuplot: ../term/cgm.trm:1282: CGM_write_int:
> 		Assertion `value <= 32767' failed.
> 		Abort
>
> emf.trm		gnuplot: ../term/emf.trm:860: EMF_move:
> 		Assertion `x < term->xmax && y < term->ymax' failed.
> 		Abort


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

Re: Again: canvas size

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

Ethan Merritt wrote:
> Arguably, the only terminal to get it right is mif.trm.

No.

> post.trm	full plot is drawn - bounding box goes negative

> gd.trm		full plot is drawn - size is twice that requested

And what size was that?

> fig.trm		full plot is drawn - size is twice that expected

Expected by whom, why?

> mif.trm		full plot is drawn but bounding box describes only
> 		lower left corner. Arguably this is the only terminal
> 		to get it right!

No, it's not.  The size was set to twice the normal one, *before* 'set 
terminal' and 'set output'.  Thus, it should have changed not just the 
plot size, but also the page size, i.e. the bounding box.  mif.trm is 
ignoring the one input it currently has about the intended actual size 
of the plotted output.

Re: Again: canvas size

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

On Wednesday 12 October 2005 04:45 pm, Harald Harders wrote:

> > Introduce a new coordinate system "absolute", or maybe even the specific
> > units  "in", "cm", "pt", "pixel".
> 
> I totally agree with this approach. The specific units have too problems:
> How shall pixel defined in vector terminals

I assume that you would not specify a measurement in pixels if you are
using a vector terminal.

> and how shall in, ch, pt be 
> defined in terminals without a absolute canvas size? 

Which terminals do you have in mind here - the pixel terminals?

> For png and jpeg, a 
> resolution in dpi could be given and thus in, ch, and pt also used.

I think we would have to introduce a "dpi" parameter into the various terminal
options.  There would have to be a default value, which would usually turn out
to be wrong, but what else can we do?

	set term png size 900,300  {dpi 300}
would be the same as
	set term png size 3in, 1in dpi 300

Both would generate a 3 inch by 1 inch image when printed to
a 300 dpi printer.  The first form would only require the dpi
value if you in fact wanted to use absolute coordinates in inches or cm.
The second form absolutely requires the dpi value in order to calculate
the necessary size in pixels.

> what about x11 and windows? Do they have access to the system-wide
> resolution settings?

X11 has access to the display resolution.
It is not system-wide because it can be different for each display device.


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

Re: Again: canvas size

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

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 04:45 pm, Harald Harders wrote:
>
> > > Introduce a new coordinate system "absolute", or maybe even the specific
> > > units  "in", "cm", "pt", "pixel".
> >
> > I totally agree with this approach. The specific units have too problems:
> > How shall pixel defined in vector terminals
>
> I assume that you would not specify a measurement in pixels if you are
> using a vector terminal.

I won't. But many other people will. And it might happen that you have
used a pixel terminal and switch to a vector terminal afterwards. Thus,
every unit should work everywhere.

> > and how shall in, ch, pt be
> > defined in terminals without a absolute canvas size?
>
> Which terminals do you have in mind here - the pixel terminals?

I thought of screen terminals (which in fact are also pixel terminals).
Pixel terminals are not a problem because of the resolution. I think we
can give every terminal that does not know a resolution a default of
72dpi. Also vector-based terminals could use a (pseudo) resolution to
convert pixels to real measures.

> > For png and jpeg, a
> > resolution in dpi could be given and thus in, ch, and pt also used.
>
> I think we would have to introduce a "dpi" parameter into the various terminal
> options.  There would have to be a default value, which would usually turn out
> to be wrong, but what else can we do?
>
> 	set term png size 900,300  {dpi 300}
> would be the same as
> 	set term png size 3in, 1in dpi 300

That's a good idea. Then, all terminals could get the ability of absolute
measures. The second line would change to

        set term png size inch 3,1 dpi 300

if inch is one of the new measures. Then, sizes could be given using
get_position() which allows all measures except 'screen', 'first',
'second', and 'graph'. Even 'character' could be valid (even if strange).
For pixel-based terminals, the unit could default to 'pixel', for
postscript to 'pt'.

I think adding 'inch', 'millimeter', 'point', and 'pixel' to the list of
coordinate systems would be a big step in the right direction. This would
enable users to produce plots in exact the size they want to get them.

Best regards
Harald

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

Re: Again: canvas size

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

On Thursday 13 October 2005 01:58 am, Hans-Bernhard Broeker wrote:
> 
> > gd.trm		full plot is drawn - size is twice that requested
> 
> And what size was that?

 set term png size <xpixels>,<ypixels>

 If I request that image size explicitly, then absolutely that is what
 I am expecting to get.  The size of the plot within that image may be
 varied using "set size", as it is for multiplots, but the image size
 should be invariant.
 
> > mif.trm		full plot is drawn but bounding box describes only
> > 		lower left corner. Arguably this is the only terminal
> > 		to get it right!
> 
> No, it's not.  The size was set to twice the normal one, *before* 'set 
> terminal' and 'set output'. Thus, it should have changed not just the   
> plot size, but also the page size, i.e. the bounding box.

Here is the root of the problem.
I claim that "set size" should *not* change the page size, or bounding
box size.  The mif behavior is exactly what it should be, assuming that
it is legal to specify a size greater than 1 in the first place.

> mif.trm is  
> ignoring the one input it currently has about the intended actual size 
> of the plotted output.

No, it is not.  It is producing a scalable image that is now twice
as large as the bounding box.  As Harald point out, that is also the
result from "set term post eps".  So that raises the total number
of correct and consistent output devices to 2, if you count eps as
a separate output device from postscript.

I realize that different people have different expectations.
But equally, different gnuplot terminals have different behaviors.
My expectations are met by mif and eps; yours are apparently met
by some other terminal type (which one?).

Whoever is "right", the current state is a total mess as far as
cross-device compatibility.

I strongly advocate that "set size" be limited to sizes equal
or less than 1.0,  but only after some to-be-determined list
of terminals drivers are modified to accept a "size" option as
part of the terminal spec.

Forget backward compatibility. There can be none, because the current
behaviour is not even compatibility with itself.


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

Re: Again: canvas size

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

On Thursday 13 October 2005 09:05 am, Ethan Merritt wrote:
> I strongly advocate that "set size" be limited to sizes equal
> or less than 1.0

Let me phrase that in a different way:

I strongly advocate that "set size" have the same behaviour
regardless of whether it is called before or after "set term".
It should affect the scaling of the next plot to be drawn,
but it should never affect the size of the canvas[*].


* Canvas:  The image size in pixels for pixel devices,
  the BoundingBox for postscript or TeX devices,  the paper
  size for pen plotters.


As before, I note that backwards compatibility is out of
question because there is no consistent behaviour to be
compatible with.


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

Re: Again: canvas size

[Aapo L. <aap...@gm...>]

On Thu, 2005-10-13 at 09:18 -0700, Ethan Merritt wrote:
> Let me phrase that in a different way:
> 
> I strongly advocate that "set size" have the same behaviour
> regardless of whether it is called before or after "set term".
> It should affect the scaling of the next plot to be drawn,
> but it should never affect the size of the canvas[*].

Does that mean there should be a new command "set canvas" or a dedicated
"canvas" option that all terminals should implement?

						Aapo

-- 
Aapo Lankinen <aap...@gm...>

Re: Again: canvas size

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

Ethan Merritt wrote:

>  If I request that image size explicitly, then absolutely that is what
>  I am expecting to get.  The size of the plot within that image may be
>  varied using "set size", as it is for multiplots, but the image size
>  should be invariant.

Herein lies the problem.  I think some recent changes in this area were 
committed wihthout sufficient insight.

'set size' before 'set term' was a working method in gnuplot-4.0, for a
non-negligeable number of drivers, to change the overall size of the 
plot.  Scripts using that are now broken.

> I claim that "set size" should *not* change the page size, or bounding
> box size.  

I tend to see compatibility with previously working, publically 
recommended (in the newsgroup) practice more important than a 'should' 
based on aesthetic arguments.

 > The mif behavior is exactly what it should be, assuming that
> it is legal to specify a size greater than 1 in the first place.

It always was, and was sometimes necessary.   I don't think that 
deliberately breaking all scripts that used it is an acceptable 
short-term plan.


> No, it is not.  It is producing a scalable image that is now twice
> as large as the bounding box.  

And that means its lieing through its teeth about that bounding box.

 > As Harald point out, that is also the
> result from "set term post eps".  

Release 4.0 still got that right.

> I strongly advocate that "set size" be limited to sizes equal
> or less than 1.0,  but only after some to-be-determined list
> of terminals drivers are modified to accept a "size" option as
> part of the terminal spec.

Having the same option in very many, maybe all terminals, feels wrong. 
It also breaks one of our basic design principles of old: scripts must 
work reasonably, and should work as equally as possible, on all drivers. 
    If essentially terminals are to have this option, IMHO that's 
grounds for introducing a new core command that talks to a new terminal 
API function to implement that functionality.

> Forget backward compatibility. There can be none, because the current
> behaviour is not even compatibility with itself.

Backward compatibility cannot be judged from the current CVS version. 
Only the release version(s) can serve as a reference, and compability 
with 4.0 has *already* been broken, for reasons I personally don't think 
justify doing so.

Re: Again: canvas size

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

On Thursday 13 October 2005 09:36 am, Hans-Bernhard Broeker wrote:
> 
> Backward compatibility cannot be judged from the current CVS version. 
> Only the release version(s) can serve as a reference, 

Fine. I have re-run my test sequence using version 4.0
  set size 2,2
  set term <foo>
  set output '2.foo'
  plot sin(x)

Here are the results:

	mif	Bounding box remains unchanged, plot scale is doubled

	dumb	segfault
	emf	Abort
	cgm	Abort
	png	image is twice the size requested in "set term"
	pbm	image size is twice default
		(4.0 had no "set term pbm size ..." option)

	fig	"set term fig inches size 3 3"
		resulting plot extends from -2 to 4 inches on y
		and from 1 to 7 inches on x

	post	%%BoundingBox: -454 50 554 1490
		(size 1,1 gives %%BoundingBox: 50 50 554 770)
	eps	%%BoundingBox: 50 50 770 554
		(size 1,1 gives %%BoundingBox: 50 50 410 302)

	epslatex	result depends on the TeX options in the
			surrounding document


> and compability  
> with 4.0 has *already* been broken, for reasons I personally don't think 
> justify doing so.

So I find no change between 4.0 and 4.1,
except that I recently added a "set term pbm size xx,yy" option.

size > 1 was already seriously broken, and it remains so.

 

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

Re: Again: canvas size

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

On Thursday 13 October 2005 09:56 am, Ethan Merritt wrote:
 And here are the results for 3.7
> 
> 	mif	Bounding box remains unchanged, plot scale is doubled
		3.7 same
> 	dumb	segfault
		3.7 no segfault I don't know what changed
> 	emf	Abort
		3.7 no emf driver 
> 	cgm	Abort
		3.7 same
> 	png	image is twice the size requested in "set term"
> 	pbm	image size is twice default
> 		(4.0 had no "set term pbm size ..." option)
		3.7 uses old png driver, png and pbm behave the same

> 	fig	"set term fig inches size 3 3"
> 		resulting plot extends from -2 to 4 inches on y
> 		and from 1 to 7 inches on x
		3.7 Xfig displays no plot if size is set to 2,2
		but shows the expected plot is size is set to 1,1
		I have no idea why, but version 4.0 was clearly an
		improvement

> 	post	%%BoundingBox: -454 50 554 1490
> 		(size 1,1 gives %%BoundingBox: 50 50 554 770)
		3.7 same

> 	eps	%%BoundingBox: 50 50 770 554
> 		(size 1,1 gives %%BoundingBox: 50 50 410 302)
		3.7 same

> 	epslatex	result depends on the TeX options in the
> 			surrounding document
		3.7 no epslatex driver
 
> size greater than 1 was already seriously broken, and it remains so.
  3.7 same :-)


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