Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW, HH} {position XX, YY}")

[Ethan M. <merritt@u.washington.edu>]

On Thursday 12 February 2009 10:37:25 Ben Abbott wrote:
> On Thursday, February 12, 2009, at 11:46AM, "Ethan A Merritt" <merritt@u.washington.edu> wrote:
> >On Thursday 12 February 2009, Ben Abbott wrote:
> >
> >> To properly interpret the "size" information I'll get from x11 using  
> >> the GPVAL_TERM_WINDOWID, I'll need the value for GPVAL_TERM_VCHAR.  
> >> Temporarily I can assume it is 13 pixels. However, as I'll be using  
> >> the window size obtained from x11 to determine if the mouse was used  
> >> to change its size, and subsequently update the figures' size property  
> >> on the octave end, I'd like to make sure I get his correct.
> >
> >Use it for what?  
> 
> The window size reported by x11 includes the portion reporting the mouse coordinates, 
> which is not part of the gnuplot canvas. 
> So I'd like to have TERM_VCHAR so that I can subtract this from the window's height.  

Would you prefer a mousing mode that wrote the mouse coordinates without
extending the size on y?   That would be a trivial change, and could be 
toggled by the same hot-key that currently toggles the mouse coords on and off.

 
> >TERM_VCHAR is telling you about the font size, not the window size.
> >And in the case of the x11 terminal, it is only a rough approximation.
> >
> >The current code happens to use vchar and hchar also to estimate
> >the aspect ratio of the window, but this works very poorly.  Because
> >of this, the aspect ratio code is still broken in x11 and I think
> >will not be fixable unless/until we totally revise how the x11 terminal
> >coordinates are handled.  This will need a careful overhaul of the 
> >terminalcode, but I don't see any intrinsic difficulties to overcome.
> >The idea is that the x11 terminal coordinate space should be defined
> >in terms of the actual dimensions of the display window; resizing the
> >window would change term->xmax and term->ymax but leave the x and y
> >scales unchanged.  Currently the opposite is true;  xmax and ymax
> >are held constant, while the x and y scale are changed so that the current
> >window area is spanned by a coordinate space running from [0:4095] on
> >both x and y.  I don't know whether such a revision is relevant to your
> >current project or not.  
> 
> I'm not sure either. Would it interfere with the positioning of plots when using "set l/b/r/tmargin <margin>"?

I don't think it would be visible to the user or to user scripts, except
that it would result in improved behaviour of the "set size ratio ..." and
"set view equal xy..." commands.


> I'm using "set ?margin" to explicity set the position of the axes when 
> in multiplot mode, so that the axes align themselve across columns and/or rows.
> However, I noticed horizontal spacing of the axes/plots on my computuer is 
> slightly different than what Matlab produces (the figure windows are exaclty the same size).   
> 
> Ben
> 


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742