gnuplot-beta

pslatex code contaminating the gnuplot core

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

By the way, in trying to build gnuplot without the postscript
terminal driver I discovered that the recent commingling of
postscript/pslatex/epslatex has made this impossible.

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. But having the core code writing
this garbage is just really really ugly.

--- gnuplot/src/graphics.c      2005-02-24 12:14:16.000000000 -0800
+++ gnuplot-cvs/src/graphics.c  2005-03-01 12:49:19.368297032 -0800
@@ -1482,11 +1482,6 @@
     /* PLACE ARROWS */
     place_arrows( 0 );
 
-    /* Print \includegraphics here when using back option for text */
-    if (term->name=="epslatex" && gpoutfile)
-       fprintf(gpoutfile, "    \\put(0,0){\\includegraphics{%s}}%%\n",
-               pslatex_auxname);
-
     /* WORK OUT KEY SETTINGS AND DO KEY TITLE / BOX */
     if (lkey) {                        /* may have been cancelled if something went wrong */
        /* just use keybox.xl etc worked out in boundary() */

--- gnuplot/src/graph3d.c       2005-02-13 15:55:37.000000000 -0800
+++ gnuplot-cvs/src/graph3d.c   2005-03-01 12:49:02.316889240 -0800
@@ -739,11 +739,6 @@
     /* PLACE ARROWS */
     place_arrows3d(0);
 
-    /* Print \includegraphics here when using back option for text */
-    if (term->name=="epslatex" && gpoutfile)
-       fprintf(gpoutfile, "    \\put(0,0){\\includegraphics{%s}}%%\n",
-               pslatex_auxname);
-
 #ifndef LITE
     if (hidden3d && draw_surface && !quick) {
        init_hidden_line_removal();


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: pslatex code contaminating the gnuplot core

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> By the way, in trying to build gnuplot without the postscript
> terminal driver I discovered that the recent commingling of
> postscript/pslatex/epslatex has made this impossible.
> 
> 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. But having the core code writing
> this garbage is just really really ugly.

Oo, yes.  Don't start this sort of thing.  There must be a good solution to this inside the terminal 
driver, e.g., static variables for remembering when to put this string in the LaTeX file.  Harald?

> -    /* Print \includegraphics here when using back option for text */
> -    if (term->name=="epslatex" && gpoutfile)
> -       fprintf(gpoutfile, "    \\put(0,0){\\includegraphics{%s}}%%\n",
> -               pslatex_auxname);

Dan

Re: pslatex code contaminating the gnuplot core

[Harald H. <h.h...@tu...>]

On Tue, 1 Mar 2005, Daniel J Sebald wrote:

> Ethan Merritt wrote:
> > By the way, in trying to build gnuplot without the postscript
> > terminal driver I discovered that the recent commingling of
> > postscript/pslatex/epslatex has made this impossible.
> >
> > 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. But having the core code writing
> > this garbage is just really really ugly.
>
> Oo, yes.  Don't start this sort of thing.  There must be a good solution to this inside the terminal
> driver, e.g., static variables for remembering when to put this string in the LaTeX file.  Harald?
>
> > -    /* Print \includegraphics here when using back option for text */
> > -    if (term->name=="epslatex" && gpoutfile)
> > -       fprintf(gpoutfile, "    \\put(0,0){\\includegraphics{%s}}%%\n",
> > -               pslatex_auxname);

This was the only possibility to enable the user to use the keywords
'front' and 'back' for 'labels'. 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:

graphics.c, graph3d.c, and term.c:

    if (term->place_plot)
        (*term->place_plot)();

post.trm:

TERM_PUBLIC void
PS_place_plot()
{
    if (term->name=="epslatex" && gpoutfile)
        fprintf(gpoutfile, "    \\put(0,0){\\includegraphics{%s}}%%\n",
                pslatex_auxname);
}

Shall I write a patch and upload it to sourceforge?

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

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

Re: pslatex code contaminating the gnuplot core

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

Ethan Merritt wrote:

> 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?
[...]
> enum layer { LAYER_PLOT_BACKGROUND, LAYER_AXES, LAYER_BACK_LABELS,
> LAYER_PLOT_LINES, LAYER_FRONT_RECTANGLES, LAYER_FRONT_LABELS, ... }

This idea certainly has a nicer ring to it than the current situation.

What I'm a little bit worried about is, as always, the conceptual
clarity of our terminal layer API.  So far, the terminal API is,
essentially, just a rather generic vector drawing API --- all the way to
the old "gnuplot library" which exported this API for generic usage.

A new API entry like the above would, effectively, specialize the
interface to gnuplot as the client, and kill all remaining hopes of one
day splitting up the program into well-separated layers of functionality.

I don't thus think that *naming* the layers would be a good idea at all.
Let them have numbers, and export those to the user interface in some
way the users can (hopefully) understand.

Re: pslatex code contaminating the gnuplot core

[Harald H. <h.h...@tu...>]

On Thu, 10 Mar 2005, Hans-Bernhard Broeker wrote:

> Ethan Merritt wrote:
>
> > 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?
> [...]
> > enum layer { LAYER_PLOT_BACKGROUND, LAYER_AXES, LAYER_BACK_LABELS,
> > LAYER_PLOT_LINES, LAYER_FRONT_RECTANGLES, LAYER_FRONT_LABELS, ... }
>
> This idea certainly has a nicer ring to it than the current situation.
[...]
> I don't thus think that *naming* the layers would be a good idea at all.
> Let them have numbers, and export those to the user interface in some
> way the users can (hopefully) understand.

Would you prefer something like this? Or how do you think it should be
implemented?

int layer;
#define LAYER_PLOT_BACKGROUND -3
#define LAYER_AXES -2
#define LAYER_BACK_LABELS -1
#define LAYER_PLOT_LINES 0
#define LAYER_FRONT_RECTANGLES 1
#define LAYER_FRONT_LABELS 2


-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: pslatex code contaminating the gnuplot core

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

Harald Harders wrote:
> On Thu, 10 Mar 2005, Hans-Bernhard Broeker wrote:

>>I don't thus think that *naming* the layers would be a good idea at all.
>>Let them have numbers, and export those to the user interface in some
>>way the users can (hopefully) understand.

> Would you prefer something like this? Or how do you think it should be
> implemented?

A heap of #define'd numbers offer exactly no improvement over an enum 
--- they'ld actually be worse.

The issue is not how they're defined, the issue is which parts of the 
programs know about, and use them.  The terminal API shouldn't have to 
know about the meanings of individual layers' designators.

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.

Re: pslatex code contaminating the gnuplot core

[Robert H. <en...@no...>]

On Mon, 2005-03-14 at 16:27 +0100, Hans-Bernhard Broeker wrote:
> 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

Is that really such a bad idea? It seems to fit with the semantics
currently used by the core and the other terminals. 

The multi-layer approach either requires that the core output the
various layers in order (in which case nothing has really changed), or
that most terminals buffer up all the graphics for each layer and
composite them all together at the end (which is a lot of extra hassle
for no real gain). I suppose it would make sense for things like .fig
which actually have real layers.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: pslatex code contaminating the gnuplot core

[Harald H. <h.h...@tu...>]

On Mon, 14 Mar 2005, Hans-Bernhard Broeker wrote:

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

Yes, I have tried to find another solution, but I did not know a better
workaround than this one.

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

I have also thought of splitting the graphic part of the output. But this
would mean to have three output files which would be a bad thing. I am
aware that the 'back' option in the epslatex terminal is different than in
other terminals. Of course, it would be nice if the 'back' option would
behave as in the other terminals. But it is still better if it works at
least similarly and allows the user to place labels behind portions of the
graph than to ignore the 'back' option at all.

Thus, we really should find a good solution for this implementation
problem without removing the feature 'back' in epslatex.

Regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: pslatex code contaminating the gnuplot core

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

On Tuesday 01 March 2005 02:33 pm, 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. 

It has belatedly occurred to me that this approach has another
problem as well - it breaks in multiplot mode.  Each sub-plot
within the multiplot sequence triggers a repeat call to write
out the {\includegraphics{foo}} statement, and by the time these
are later executed by LaTeX the included file "foo.eps" contains
only the final composite set of all sub-plots.  So instead of
layering, you end up with redundant redrawing of the same final
composite plot on top of itself.

To do this properly, I think you would need to save each subplot
to a separate file and emit a corresponding \includegraphics
statement somewhere in term->suspend() or possibly in term->resume().

Which makes me wonder if the original ugliness can be resolved
without addition of any new terminal API calls, by suitable use of
the existing term->suspend() and term->resume() mechanism.
The PostScript driver proper does not use suspend/resume, but 
maybe the merged epslatex/pslatex code should do so.


> having the core code writing this garbage is just really really ugly.
>
> --- gnuplot/src/graphics.c      2005-02-24 12:14:16.000000000 -0800
> +++ gnuplot-cvs/src/graphics.c  2005-03-01 12:49:19.368297032 -0800
> @@ -1482,11 +1482,6 @@
>      /* PLACE ARROWS */
>      place_arrows( 0 );
>
> -    /* Print \includegraphics here when using back option for text */
> -    if (term->name=="epslatex" && gpoutfile)
> -       fprintf(gpoutfile, "    \\put(0,0){\\includegraphics{%s}}%%\n",
> -               pslatex_auxname);
> -
>      /* WORK OUT KEY SETTINGS AND DO KEY TITLE / BOX */
>      if (lkey) {                        /* may have been cancelled if
> something went wrong */ /* just use keybox.xl etc worked out in
> boundary() */
>
-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Re: pslatex code contaminating the gnuplot core

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

Ethan Merritt wrote:

> only the final composite set of all sub-plots.  So instead of
> layering, you end up with redundant redrawing of the same final
> composite plot on top of itself.

> To do this properly, I think you would need to save each subplot
> to a separate file and emit a corresponding \includegraphics
> statement somewhere in term->suspend() or possibly in term->resume().

I'm quite sure that that can't work either --- at the time of a
term->suspend() or term->resume() call, one of the multiple plots is
either completely finished, or hasn't actually been started yet. I.e. an
\includegraphics issued at either of these points would always either
end up with the graphical elements displayed in front of all texts, or
behind all texts, neither of which is any better than the original state
of things.

I suspect multiplot vs. \includegraphics is a lost cause.   It's one of 
the situations where the old pslatex terminal's mode of operation with 
only one output file (postscript \specials directly interspersed with 
the LaTeX output) is a better idea --- even if it's seriously oldfashioned.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: pslatex code contaminating the gnuplot core

[Harald H. <h.h...@tu...>]

On Tue, 29 Mar 2005, Hans-Bernhard Broeker wrote:

> Ethan Merritt wrote:
>
> > only the final composite set of all sub-plots.  So instead of
> > layering, you end up with redundant redrawing of the same final
> > composite plot on top of itself.

Mmh, why I have not noticed that?

> > To do this properly, I think you would need to save each subplot
> > to a separate file and emit a corresponding \includegraphics
> > statement somewhere in term->suspend() or possibly in term->resume().

Another possibility could be to store everything temporarily and write
the 'back' labels of all sub-plots first, then the plots itself and
afterwards the 'front' labels. But I believe that this is a too strong
modification of gnuplots algorithm.

> I'm quite sure that that can't work either --- at the time of a
> term->suspend() or term->resume() call, one of the multiple plots is
> either completely finished, or hasn't actually been started yet. I.e. an
> \includegraphics issued at either of these points would always either
> end up with the graphical elements displayed in front of all texts, or
> behind all texts, neither of which is any better than the original state
> of things.
>
> I suspect multiplot vs. \includegraphics is a lost cause.   It's one of
> the situations where the old pslatex terminal's mode of operation with
> only one output file (postscript \specials directly interspersed with
> the LaTeX output) is a better idea --- even if it's seriously oldfashioned.

The main disadvantage is that it does not work with pdflatex and VTeX, for
example. But I must admit that I also don't know a satisfactory solution
for the problem using \includegraphics, at the moment.

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de