Re: pslatex code contaminating the gnuplot core

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> Yes, but no other terminal driver that I know of interprets this as 
> meaning that the back labels are underneath *everything* else.

Well, it's not really the terminal drivers that are doing that job
at all.  So far, "layers" are implemented only by the core.  The
terminal drivers don't know what the core is doing.  It's this lack of
knowledge that is causing the problem at hand in epslatex.  It could be
hacked around inside the driver, e.g. by outputting the \includegraphics
line the moment the core issues the first non-text command to the
terminal, but I think I'd prefer a term->set_layer() over such an approach.

What the core does is it goes through all the labels twice, once rather
early in the process, for the "back" labels, once after everything else,
for the "front" labels.  That's why there are two calls to
place_labels() in do_plot(), and place_labels() takes a "layer" argument.

> I think you can argue that if intermixing the order of labels and 
> other plot elements is important, then epslatex is the wrong terminal
>  driver to use in the first place.

That would essentially mean the {e}pslatex type of driver is a lost
cause.  Given the very high opinion about its usefulness everybody seems
to share, esp. after its recent overhaul, I find it hard to accept such
a point of view.

Epslatex with a separate PostScript file, unless changed somewhat
radically, to support more than one graphical output file to be
intermixed with the texts, will be inherently limited in its support of
a more generalized layering of gnuplot's output, but I don't agree that
we shouldn't even try to support such ordering because of that.