Re: pngcairo: suggestion for additional option

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

On Mon, 26 Nov 2007, Ethan Merritt wrote:

> On Saturday 24 November 2007 11:29, Allin Cottrell wrote:
> > I'm attaching a set of 3 small patches that, I hope, 
> > jointly do the job in a reasonably elegant way.
> > 
> > 1) term_api.h is modified to add another term->foo function, 
> > namely term_scale, which (if applicable) retrieves a 
> > terminal-specific scale factor such as the oversampling_scale
> > in pngcairo.
> > 
> > 2) cairo.trm (pngcairo variant) is modified to provide that 
> > function, which simply returns the oversampling scale.
> 
> Thinking out loud...
> 
> 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.

> Would we ever need separate scales for X and Y?

FWIW, I find it difficult to imagine that.

> What about auxilliary information like the mouse coordinate 
> format?

I guess that could be added where relevant: add_udv_by_name() is a 
nice flexible mechanism!

> What if someone wanted mouse feedback from the colorbar? We 
> don't do that now, but as long as we're looking into expanded 
> capabilities, why not?

Ditto.  I have no need for these things but they could be added.

> I have not yet had a chance to look at your patchset.
> Too busy reviewing character encoding fix-ups :-)

Fair enough!

> > 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_.  But 
now suppose I do:

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?  It'll still 
give the pngcairo bounding box while the user might reasonably 
expect it to give the jpeg box (or yield undefined values, perhaps 
-- but why bother to undef these values when they can be retrieved 
with ease).

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC