From: Ethan M. <merritt@u.washington.edu> - 2007-11-26 18:11:11
|
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? Would we ever need separate scales for X and Y? What about auxilliary information like the mouse coordinate format? This is a sore point in the current X11 implementation. You can continue to mouse an old plot even after gnuplot itself has exited, but the format used for mouse coordinates falls back to a generic one rather than the user-specified one. 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? > 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. I have not yet had a chance to look at your patchset. Too busy reviewing character encoding fix-ups :-) > 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. > Also, the basic bounds calculation can easily be done in the core, > hence avoiding needless duplication of code at the terminal level. Yes, but... Some terminals will want their own routines anyhow. In particular, x11 has its own format and output path for this information. There is another possible mechanism for this case, one parallel to that used for term->arrow(). Any driver that wants to handle arrows privately can register a specific routine; all others can register the generic routine do_arrow() instead. In fact change_term() is smart enough to register the generic routine do_arrow() for terminals that don't provide an entry point at all. This avoids having to patch every single driver. -- Ethan A Merritt |