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