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

[Ben A. <bpa...@ma...>]

On Friday, February 13, 2009, at 01:13PM, "Ethan Merritt" <merritt@u.washington.edu> wrote:
>On Friday 13 February 2009 08:27:08 Ethan A Merritt wrote:
>
>> The canvas size is held by GPVAL_TERM_XMIN, GPVAL_TERM_XMAX, etc...
>> The plot boundaries are held by GPVAL_X_MIN, ....
>
>Sorry, I got that wrong. There are indeed serious issues lurking here.
>
>The properties are reported as follows:
>
>Plot boundaries in "terminal coordinates"
>   GPVAL_TERM_XMIN, GPVAL_TERM_XMAX, ...
>Plot boundaries in axis coordinates (i.e. xrange[], yrange[])
>   GPVAL_XMIN, GPVAL_XMAX, GPVAL_LOG, GPVAL_REVERSE, ...
>Exact canvas size
>   Not as easily obtained as I remembered. 
>
>The canvas driver writes the exact size to the output, for example,
>as does svg and various pixel drivers.
>But it is not exported as a pair of GPVAL_* values.
>
>The existing system does work for mousing, because the information is
>sufficient to decode coordinates within the plot boundaries.
>But I agree that there is room for improvement here, and I'm not sure 
>how to make it fully generic.
>
>1) What should we report as the canvas size for vector terminals? 

For Octave's purposes, the canvas would be normalized to unit width and length.