[cc-ing to the mailing list, to keep the thread consistent]
> Timoth=E9e Lecomte wrote:
>> I would like to discuss what is the expected behaviour of the
>> terminals when the user resizes the windows.
> I don't think there is any formalized expectation beyond "try to make a=
> much sense as possible".
Sure, I completely agree !
>> The X11 terminal is resizing the plot by scaling everything on it exce=
>> the font size and the linewidths. Thus, if the user makes the window
>> smaller, ticks labels may overlap, the plot box gets closer to the
>> window's edges and may overlap the labels, etc.
>> If another plot command is issued, the ratio is kept, so that the
>> of the box doesn't change for example.
> I'm not quite sure which "ratio" you're referring to there.
I mean the global aspect of the plot (box position, overlapping if any
because of the rescaling), as opposed to the situation described just
>> If 'set term x11; replot' is issued, the window size seems to be probe=
> Yes. There's a back channel from gnuplot_x11 to gnuplot (the same one
> usually used for mouse interaction) which is used to inform the core
> about the actual geometry of the plot. IIRC, it's supposed to used not
> only if you 'set term x11', but actually on each new plot.
At least for me with a CVS version picked up one month ago, the new windo=
size is taken into account when you do 'set term x11', but not for a
simple new plot.
>> The Windows terminal behaves similarly, except that term->xmax and
>> term->ymax seem to be stored at once on startup only, so that 'set ter=
>> win; replot' won't change the layout of the plot at all.
> Win.trm's internal coordinates have no relation to the GUI window's
> size. The transformation between these artificial coordinates and
> screen pixels is handled by the graphical output layer.
Ok, thanks for the details.
>> I can imagine two other possibilites for the plot behavior when the us=
>> changes the window's size :
>> 1) really scale everything - including the font size
> That would be manifestly wrong. Font size is specified by the user, an=
> it's absolute. It's not supposed to change just because you changed th=
> size of the plot.
At least, thinking of it as a value relative to the window size leads to
inconsistencies when gnuplot's core is informed of a new geometry for a
>> 2) don't scale anything and just display the plot centered in the
>> if it is smaller than the window, and if it is bigger add scrollbars o=
>> the edges of the window.
> Seems like you're missing the most obvious possibility:
> 3) Leave it to the core engine to re-layout the entire plot for the new
> window size, i.e. automatically trigger a "replot".
> The reason we're not doing that is that it's not always (easily)
> possible, because of 'multiplot' and because data may no longer be
That is the underlying problem (I experienced it, and I aknowledged it at
the end of my first message).
>> The second solution (don't scale anything) has the advantage to be
>> as it has basically no complex operation at all to be done when the
>> window's size changes.
> And it has the major disadvantage that if the user makes the window
> smaller than it originally was, part of the plot will now be invisible.
Yes, but as mentioned in my reply to Ethan's message, it's the way most
other applications work. I am not saying it is the optimal solution, but
it may be better that the current one.
For my wxt terminal, it would just imply (for example) a new button 'fit
to window' that the user would have to click on to inform gnuplot of the
> Ultimately, if the plot is a multiplot, *nothing* can really be done
> that would get us a sensible plot that doesn't explicitly violate at
> least some of the explicit or implicit requests issued by the user.
> Either the font size will be wrong, or the layout will no longer be
> adjusted to the font size, or the layout will be fundamentally differen=
> from what size, origin and margin were set to.
> For short, it's generally an impossible mission. "replot" is correct i=
> it can be done --- but sometimes it just isn't.
Agreed. So a long-run goal could be to rework this.