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