Re: pngcairo: suggestion for additional option

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

On Fri, 23 Nov 2007, Ethan A Merritt wrote:

> On Friday 23 November 2007 16:56, pl...@pi... wrote:
> > On Sat, 24 Nov 2007 01:24:09 +0100, Allin Cottrell <cot...@wf...>  
> > wrote:
> > >
> > > gp_cairo.h: #define GP_CAIRO_SCALE 20
> > >
> > 
> > So you should probalby be using the named const not a number.
> 
> No core routine should be peering into the code of individual 
> terminal drivers, nor making terminal-specific decisions.

Granted.  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.

3) eval.c is modified as per my previous suggestion, as amended by 
you.  That is, update_gpval_variables(), for context = 1, is 
augmented to call the new function update_plot_bounds(), which 
defines the 4 variables TERM_XMIN, TERM_XMAX, TERM_YMIN and 
TERM_YMAX.  The initial values to fill out these variables come 
via the map_position() function.  We then test to see if the 
current term offers a term_scale function, and if so we use this 
to modify the values before recording them.

This way every terminal writes entries for TERM_XMIN et al, with 
the option for the maintainer of the terminal to add a scale 
factor function if that makes sense (e.g. to convert to pixels).

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.

Also, the basic bounds calculation can easily be done in the core, 
hence avoiding needless duplication of code at the terminal level.

Allin Cottrell