Re: pngcairo: suggestion for additional option

[Ethan M. <merritt@u.washington.edu>]

On Monday 26 November 2007 11:44, you wrote:
> On Mon, 26 Nov 2007, Ethan Merritt wrote:
> > 
> > Is there an advantage to having this be a function call, rather 
> > than simply exporting the scale itself in TERM_TABLE?
> 
> As I understand it, yes.  For pngcairo, there's at present a 
> hard-wired oversampling scale of 20, *if* oversampling is used.  
> I believe it's always used at present, but in principle this could 
> be user-configurable or otherwise depend on things at run time.

I think the tool button on the wxt terminal allows you to toggle the
oversampling.  But isn't that exactly the same as term->xmax and
term->ymax changing dynamically when you resize the plot window?

> > > You suggested this sort of thing might be done on a 
> > > per-terminal basis via the term->text function.  I thought 
> > > about that, but it would seem to create a potential problem.  
> > > Suppose I plot using (say) pngcairo and the TERM_* values are 
> > > set.  Then I plot again using some other terminal, and these 
> > > values are not touched.  Now I'm going to get stale state 
> > > information from the TERM_* variables.
> > 
> > But that will _always_ be the case, no matter where you put the 
> > code. The TERM_* variables, and for that matter the GPVAL_* 
> > variables, are only valid immediately after a plot command.  As 
> > soon as you change anything with a "set ..." command, the values 
> > become stale.
> 
> I'm not quite with you on that.  Suppose I do
> 
> set term pngcairo
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> # set something or other
> set term dumb
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> 
> Both instances of "print" (on gnuplot with my patch) produce
> 
> bbox: 79 620 37 460
> 
> This does not strike me as a case of stale information, since I'm 
> getting the correct bounding box _for the last plot created_. 

I'm not saying that every "set" command inevitably invalidates
every variable.  But many "set" commands invalidate one or more
variables.  In particular, any command that affects the axis
ranges or scaling will invalidate the use of TERM_* for back-calculating
plot coordinates.  It would be tricky for gnuplot itself to know
whether it is still safe to present a value for a particular variable,
so the burden is on the user to capture a consistent snapshot of values.
And I think the only guaranteed safe time to do that is immediately 
after a plot command. 

> set term pngcairo
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX   
> set term jpeg
> set output '/dev/null'
> plot x
> print "bbox: ", TERM_XMIN, TERM_XMAX, TERM_YMIN, TERM_YMAX
> 
> If setting TERM_XMIN et al is optional and depends on the specific 
> terminal, and if the jpeg terminal doesn't elect to do it, the 
> second bbox print will be out of phase, won't it?

That is certainly an argument for requiring that the TERM_* variables
be updated for all terminal types.  The best mechanism for doing this
is under discussion.

-- 
Ethan A Merritt