[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuplot-info-beta
Subject:    Re: Set pagesize     [was Re: Clipping of arrows buggy]
From:       Hans-Bernhard Broeker <broeker () physik ! rwth-aachen ! de>
Date:       2005-01-24 13:46:05
Message-ID: 41F4FC1D.7010006 () physik ! rwth-aachen ! de
[Download RAW message or body]

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)?





-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
gnuplot-beta mailing list
gnuplot-beta@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
[prev in list] [next in list] [prev in thread] [next in thread]