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.