Re: GPVAL_TERM_XSIZE behavior?

[Allin C. <cot...@wf...>]

On Fri, 5 Jun 2020, Ethan A Merritt wrote:

> On Friday, 5 June 2020 13:25:18 PDT Allin Cottrell wrote:
>> On Fri, 5 Jun 2020, Ethan A Merritt wrote:
>>
>>> On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
>>>> I'm seeing something that puzzles me. I create a plot using this
>>>> term line:
>>>>
>>>> set term pngcairo size 762,600
>>>>
>>>> Now I'm interested in retrieving the size of the PNG (which the
>>>> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I
>>>> get
>>>>
>>>> GPVAL_TERM_XSIZE = 15240
>>>> GPVAL_TERM_YSIZE = 12000
>>>> GPVAL_TERM_SCALE = 20
>>>>
>>>> and on division by 20 I get the size back OK. But using 5.2.8 I get
>>>>
>>>> GPVAL_TERM_XSIZE = 15220
>>>> GPVAL_TERM_YSIZE = 11980
>>>> GPVAL_TERM_SCALE = 20
>>>>
>>>> giving 761 x 599 on division by 20.
>>>>
>>>> Is this inadvertant or is there a reason for the difference?
>>>
>>> 600 pixels on y numbered from 0 to 599.
>>> 762 pixels on x numbered from 0 to 761.
>>>
>>> The internal variables are
>>>  term->xmax
>>>  term->ymax
>>>
>>> It is perhaps unfortunate that the exported versions are named
>>> "size" rather than "max".  This change fixed a long history of bug
>>> reports of asymmetry in the left/right top/bottom borders of
>>> pixel-based output plots.
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>> commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
>>> Author: Ethan A Merritt <merritt@u.washington.edu>
>>> Date:   Fri Jun 8 10:42:22 2018 -0700
>>>
>>>    Reconcile cairo terminal pixel coordinates and floating point coordinates.
>>>
>>>    The floating point coordinate space used internally by the terminal
>>>    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
>>>    Simply casting to (int) produces a bottom-of-screen y coordinate that
>>>    is one too large and hence is not drawn.  Similarly the right-of-screen
>>>    maximum x coordinate. Now we report one pixel smaller dimensions back
>>>    to the core code via term->xmax and term->ymax while retaining the full
>>>    canvas size internally to retain the oversampling boost in precision.
>>>    This affects all the cairo terminal variants including wxt.
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>
>> Thanks, Ethan. Not crucial, but do you know what was the first
>> release to incorporate this change? (I tried to figure this out
>> myself but failed.)
>>
>> Allin
>
> First appeared in 5.2.8, although it had been active in the 
> development version for 18 months at that point.

Thanks again! Good to know for sure.

Allin Cottrell