|
From: Harald H. <h.h...@tu...> - 2005-01-21 19:32:03
|
On Fri, 21 Jan 2005, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Wednesday 19 January 2005 08:38 am, Harald Harders wrote:
> >
> >>After Dan's mail, I have had the same idea. I think it is a good idea that
> >>screen should be in the range 0<=screen<=1. But it should also be possible
> >>to change the size of the page as well. This could then also apply to
> >>other terminals as x11. I volunteer to add at least the basis of a
> >>'set pagesize' command. I also will add support to some terminals that I
> >>understand. I then will need some help to support all terminals.
> >
> >
> > I don't understand how this is intended to work.
> > You have changed all the places that currently refer to
> > term->xmax or term->ymax so that they refer to some
> > global variable instead.
>
> 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. I think I should have put the page sizes into the TERMENTRY
struct, too. I haven't done that because then all initialisations needed
to be changed, too. If you have an idea how to avoid additional, global
variables without producing confusing code, please tell it to me.
Of course there are terminals which schould not allow to change the
pagesize, e.g., a DOS screen. Unfortunately, I was not aware of these and
maybe have made terminals resizable which shouldn't be that. I think all
terminals which are reasonable to resize should be resized by 'set
pagesize'. The terminals that may not have different sizes should produce
a warning if the pagesize is different from 1,1.
Maybe, an additional TERMENTRY member 'TBOOLEAN resizable' could be
introduced that takes the information if this terminal may be resized or
not. Or, a value
#define TERM_RESIZEABLE 64
or
#define TERM_NOTRESIZEABLE 64
could be added to the flags parameter. Then, a function could be used to
set term->xmax, term->ymax, xpagemax, and ypagemax (or whatever they are
called) according to the resize switch.
I think it is important to be able to set the size of the page and of the
plot independently, even without multiplot. If you, for example, want to
put some extra labels to the plot that are rather large it may be the
easiest way to increase the pagesize and/or to decrease the plot size.
This could of course also be done using the margins. But I think using the
sizes is easier.
> > 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. 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? You cannot change
the X resources between two plots of one gnuplot session. But why not
provide to produce different window sizes?
> > I see that your patch touches many terminal types.
> > If you have to change them anyhow, would it not make
> > more sense just to add explicit size specs for the
> > terminal types that already support it?
>
> That would be a different, possibly better approach to that.
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.
Some terminals already have an own mechanism to change the size. The
question now is how to handle a pagesize that differs from the default
value in conjunction with an explicit size given in the 'set terminal'
command. Shall the pagesize be overwritten by the terminal size or shall
both values be multiplicated?
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|