From: Hans-Bernhard B. <br...@ph...> - 2005-01-24 13:43:57
|
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)? |