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