Re: bug in terminals affected by 'set size'

[Juergen W. <wie...@fr...>]

Aapo Lankinen wrote:
> Anyway, because there are different paper sizes possible in postscript
> and because eps figures are of different size by their nature, there
> really should be such a size option as you suggested.  But I think its
> name should not be "size", because the "size" is already a reserved
> keyword for "set" and it would cause confusion.  How would e.g.
>
> set term post eps canvas 8cm, 5cm
> set term post canvas a0

Well, there is a "size" option for the bitmap drivers, as noted
upthread.  So I think "size" is the right way to go.  It might be a
good idea to rename these option to the more meaningful "canvas".
I'm not sure.

> sound?  Is this kind of behaviour possible to implement for just one
> terminal driver without touching others?  This way there would be no
> need to change the "set size" behaviour at all, and by choosing default
> a4 size canvas for postscript, there would be perfect backward
> compatibility.

I'm pretty sure this is possible.  The terminal drivers are almost
completely independent from each other, even in parsing their
terminal options.

But the "set size" behaviour would have to change, I think.
Something like

set size 1/sqrt(2), sqrt(2)
set term post eps

to change to portrait EPS wouldn't work no more.  Well, one could
use the "set size" setting at the time of the "set term" command as
default canvas size (relative to the hardwired default) if no other
size is given.  ... Did I mention that I don't like the command line
syntax of gnuplot very much?

Juergen