Re: pslatex code contaminating the gnuplot core

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

On Sunday 06 March 2005 03:32 am, Harald Harders wrote:
> > Ethan Merritt wrote:
> > >
> > > In particular I object to the following contamination of core
> > > routines with terminal-specific code.  If we need a new terminal
> > > entry for this, then so be it.
> With "terminal entry", do you mean a
> new member in the TERMENTRY struct? It could be something like
>     void (*place_plot) __PROTO((void));
> that does nothing by default and writes the above line to the output
> file if defined:

Not exactly. If it is necessary to do this at all, let's try to
make it as general as possible.  Your epslatex driver wants to be
notified of the appropriate time to place the \includegraphics
command, but that is very terminal-specific and the core code 
should not be expected to make this decision.  Some other driver
might need to act at a different time, or perform some other
action instead.

How about a terminal entry point (*term->layer)((int) layernumber)
that the core code would call at each stage of the plot process,
once per layer?   Right now we only use 2 layers, or 3 if you consider 
this to be a new one, but I could imagine expanding this to a more
fine-grained description in the future.

Right now we have:
term_api.h:    int layer;                  /* 0 = back, 1 = front */

This could be replaced by a set of enum values so that future
expansion is possible:
    enum layer { LAYER_PLOT_BACKGROUND,
                 LAYER_AXES, LAYER_BACK_LABELS, LAYER_PLOT_LINES,
                 LAYER_FRONT_RECTANGLES, LAYER_FRONT_LABELS, ... }

We don't need all of these to begin with, but you see the idea.			 

The epslatex driver would ignore all (*term->layer)(layernumber) calls 
except for the one with layernumber = LAYER_PLOT_LINES

This approach could actually generalize some of the existing 
special-purpose driver entries.  For example
(*term->suspend)() could become (*term->layer)(LAYER_END_MULTIPLOT)
(*term->resume)() could become (*term->layer)(LAYER_BEGIN_MULTIPLOT)
and the processing associated with the flag 
#define TERM_INIT_ON_REPLOT   8  /* call term->init() on replot     */
could instead be triggered by (*term->layer)(LAYER_BEGIN_REPLOT)

I'm thinking out loud here, so I may be overlooking serious
drawbacks to this approach.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742