gnuplot-beta

GPVAL_TERM_XSIZE behavior?

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

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?

Allin Cottrell

Re: GPVAL_TERM_XSIZE behavior?

[Ethan A M. <me...@uw...>]

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.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



	Ethan

Re: GPVAL_TERM_XSIZE behavior?

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

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

Re: GPVAL_TERM_XSIZE behavior?

[Ethan A M. <me...@uw...>]

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.

	Ethan

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