gnuplot-beta

Compile warnings in new post/pslatex terminal code

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

Current CVS gives the following errors when compiled:
../term/pslatex.trm:260: warning: unused variable `tmp'
../term/pslatex.trm:150: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
../term/pslatex.trm:257: warning: enumeration value `PSTERM_EPSLATEX' not handled in switch
../term/pslatex.trm:257: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
../term/post.trm:2202: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
../term/post.trm:2309: warning: 'xmin_t' might be used uninitialized in this function
../term/post.trm:2309: warning: 'ymin_t' might be used uninitialized in this function
../term/post.trm:2309: warning: 'xmax_t' might be used uninitialized in this function
../term/post.trm:2309: warning: 'ymax_t' might be used uninitialized in this function

so far relatively trivial, though they ought to be fixed.
but then I get:

../term/post.trm:1463: warning: implicit declaration of function `conv_text'
../term/post.trm:1463: warning: format argument is not a pointer (arg 3)

This is bad.  Individual drivers should not be calling
back into the gnuplot core routines (conv_text is in show.c).
Is this conversion really necessary?  
Why do we care if a user manages to type in non-printing characters
in an epslatex header string?  "If it hurts, don't do it".



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

Re: Compile warnings in new post/pslatex terminal code

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

On Saturday 12 February 2005 10:08 pm, Ethan Merritt wrote:
> Individual drivers should not be calling
> back into the gnuplot core routines (conv_text is in show.c).

An audit of other drivers finds the following suspicious #includes:

#include "getcolor.h"	(invoked by aquaterm pdf post svg x11)
- Maybe this is OK; can anyone see a way around it?

x11.trm:#include "graphics.h"
- This is conditional on the WITH_IMAGE code, but it doesn't
  actually seem to be needed for anything.
  Daniel - can we get rid of this altogether?

vgagl.trm:#include "pm3d.h"
vgagl.trm:#include "mousecmn.h"
- No idea what these are about

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

Re: Compile warnings in new post/pslatex terminal code

[Petr M. <mi...@ph...>]

> An audit of other drivers finds the following suspicious #includes:
>
> #include "getcolor.h"	(invoked by aquaterm pdf post svg x11)
> - Maybe this is OK; can anyone see a way around it?
>
> x11.trm:#include "graphics.h"
> - This is conditional on the WITH_IMAGE code, but it doesn't
>   actually seem to be needed for anything.
>   Daniel - can we get rid of this altogether?
>
> vgagl.trm:#include "pm3d.h"
> vgagl.trm:#include "mousecmn.h"
> - No idea what these are about

I've cleaned it.

---
PM

Re: Compile warnings in new post/pslatex terminal code

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

On Sat, 12 Feb 2005, Ethan Merritt wrote:

> Current CVS gives the following errors when compiled:
> ../term/pslatex.trm:260: warning: unused variable `tmp'
> ../term/pslatex.trm:150: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
> ../term/pslatex.trm:257: warning: enumeration value `PSTERM_EPSLATEX' not handled in switch
> ../term/pslatex.trm:257: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
> ../term/post.trm:2202: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
> ../term/post.trm:2309: warning: 'xmin_t' might be used uninitialized in this function
> ../term/post.trm:2309: warning: 'ymin_t' might be used uninitialized in this function
> ../term/post.trm:2309: warning: 'xmax_t' might be used uninitialized in this function
> ../term/post.trm:2309: warning: 'ymax_t' might be used uninitialized in this function

I have fixed them. The patch is at the end of this mail.

> but then I get:
>
> ../term/post.trm:1463: warning: implicit declaration of function `conv_text'
> ../term/post.trm:1463: warning: format argument is not a pointer (arg 3)
>
> This is bad.  Individual drivers should not be calling
> back into the gnuplot core routines (conv_text is in show.c).
> Is this conversion really necessary?
> Why do we care if a user manages to type in non-printing characters
> in an epslatex header string?  "If it hurts, don't do it".

I have added this because LaTeX header strings can get relatively long.
Thus, it can be useful to split them into multiple lines which needs the
non-printing character \n. I would be really unhappy if this will not work
anymore.

In my opinion, setshow.h is not the best position to define conv_text().
Wouldn't the definition of conv_text() fit better into parse.[ch] or
util.[ch]?

Regards
Harald


And here is the patch (which does not solve the critical warning which
needs discussion first):

diff -uNr orig/term/post.trm epslatex/term/post.trm
--- orig/term/post.trm	2005-02-09 12:43:12.000000000 +0100
+++ epslatex/term/post.trm	2005-02-13 14:48:09.000000000 +0100
@@ -2199,6 +2199,7 @@
     case PSTERM_PSTEX:
 	PSTEX_common_init();
 	break;
+    default:; /* do nothing, just avoid a compiler warning */
     }

     if (ps_params->psformat == PSTERM_EPS)
@@ -2306,7 +2307,7 @@
 TERM_PUBLIC void
 PS_init()
 {
-    unsigned int xmin_t, ymin_t, xmax_t, ymax_t;
+    unsigned int xmin_t = 0, ymin_t = 0, xmax_t = 0, ymax_t = 0;

     switch (ps_params->psformat) {
     case PSTERM_EPS:
@@ -2336,6 +2337,8 @@
 	xmin_t = term->ymax * (1-ysize-yoffset) / PS_SC;
 	xmax_t = term->ymax * (1-yoffset) / PS_SC;
 	break;
+    default:
+	int_error(NO_CARET, "invalid postscript format used");
     }

     /* for enhanced postscript, copy ps_params->font to ps_enh_font
@@ -2677,7 +2680,7 @@
 PS_set_font(const char *font)
 {
     char name[32];
-    int  i;
+    unsigned int  i;
     float size;
     size_t sep;

diff -uNr orig/term/pslatex.trm epslatex/term/pslatex.trm
--- orig/term/pslatex.trm	2005-02-09 12:43:12.000000000 +0100
+++ epslatex/term/pslatex.trm	2005-02-13 14:45:33.000000000 +0100
@@ -147,6 +147,7 @@
 \\endgroup\n\
 \\endinput\n", gpoutfile);
 	break;
+    default:; /* do nothing, just avoid a compiler warning */
     }

     if (pslatex_auxname) {
@@ -254,10 +255,10 @@
 	fprintf(gpoutfile, "\\GNUPLOTpicture(%d,%d)\n",
 		(int) (xsize * term->xmax), (int) (ysize * term->ymax));
 	break;
+    default:; /* do nothing, just avoid a compiler warning */
     }

     if (gppsfile != gpoutfile) {
-	FILE *tmp;
 	/* these are taken from the post.trm file computation
 	 * of the bounding box, but without the X_OFF and Y_OFF */
 	int urx = (int) (xsize * term->xmax / (2*PS_SC) + 0.5);



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

Re: Compile warnings in new post/pslatex terminal code

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

On Sun, 13 Feb 2005, Hans-Bernhard Broeker wrote:

> Harald Harders wrote:
>
> > I have added this because LaTeX header strings can get relatively long.
> > Thus, it can be useful to split them into multiple lines which needs the
> > non-printing character \n.
>
> Split them into multiple lines *where*?  In the gnuplot command 'set
> title'?  In the resulting TeX output?

The format in the 'set terminal epslatex header' command line does not
have anything to do with the contents of the epslatex_header variable.
What I mean is the format in the LaTeX output.

Have a look at this example:

set terminal epslatex standalone color \
  header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" \
  'default' 12
set title "Hello\nNewline"
show title
show terminal
set output 'header.tex'
test
set output

This leads to a LaTeX file header.tex containig these lines:

[...]
\usepackage[T1]{fontenc}
\usepackage{mathpmnt}
\begin{document}
[...]

As expected, the two \usepackage commands have their own lines.

Using conv_text() in PS_options() (as it is in cvs at the moment), the
output of this script is as follows:

        title is "Hello\nNewline", offset at ((character units) 0, 0, 0)

   terminal type is epslatex    leveldefault color colortext \
   dashed dashlength 1.0 linewidth 1.0 butt \
   palfuncparam 2000,0.003 \
   header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" "default" 12

If using 'save', a gnuplot file is produced with a valid 'set terminal'
command. This is the correct behaviour.

When I remove the call of conv_text() in PS_options(), I get following
output:

        title is "Hello\nNewline", offset at ((character units) 0, 0, 0)

   terminal type is epslatex    leveldefault color colortext \
   dashed dashlength 1.0 linewidth 1.0 butt \
   palfuncparam 2000,0.003 \
   header "\usepackage[T1]{fontenc}
\usepackage{mathpmnt}" "default" 12

And this incorrect header option is also written to an output file when
using 'save'. Thus, producing an invalid Gnuplot file.

> I'm pretty sure you should never need what conv_text does, in your driver.

Are you still sure? How am I supposed to add a linebreak into the header
string without conv_text?

> > In my opinion, setshow.h is not the best position to define conv_text().
>
> It's not defined there, anyway, just declared.

That is clear, of course. What I meant is that its syntax is made
available to other files in setshow.h.

> More the point, conv_text() is simplemented in show.c,
> and that's quite exactly the right place for it to be --- because it
> deals with presenting non-printable characters in human-readable format.
> All currently existing calls to that routine are in show.c and save.c.

The point is that conv_text() is used by routines that take strings from
options of commands of the command line, for example, 'set title'.  What
conv_text() does is to take input strings that may be written between
single quotes '...' or between double quotes "..." and map them to a
unique format that corresponds to that in double quotes "...".  And this
is used by the show and save commands to write all strings in double
quotes.

The only difference between 'show title' and 'show terminal' is that the
output string of 'show title' is produced in 'show.c' while the terminals
produce the output string in the *.trm files. Why shall the terminals not
be allowed to handle strings as the other 'set' commands are?

> > Wouldn't the definition of conv_text() fit better into parse.[ch] or
> > util.[ch]?
>
> Not for the existing code.  And even if it was moved to util.c, that
> wouldn't change anything --- because the real problem is not where
> conv_text is defined, but that terminal drivers have no business calling
> it.

I do not understand why. It may be a problem that the production of the
'show terminal' output is done in the *.trm files. In my opinion, also the
terminals should be able to take arbitrary string arguments in single and
double quotes. Thus, they should have access to conv_text().  I don't have
an opinion where conv_text() really should be declared.

> The terminal layer is supposed to be about the bottom-most layer of
> the entire program, meaning that it's not allowed to call back to the
> core engine, ever.  The mouse code has already wreaked considerable
> havoc on that principle, which was one main reason why I opposed it for
> quite a while.  That's no excuse to make a bad situation even worse, though.

I think so, too. But I do not agree to restrict the functionality of a
terminal only because of this. If it is necessary to have a functionality
it has to be enabled.

Of course, the header string does not need all characters of conv_text().
Thus, I could programme a minor function that does only deal with \n. But
this was worse in my opinion.

Regards
Harald

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

Re: Compile warnings in new post/pslatex terminal code

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

Harald Harders wrote:

> The format in the 'set terminal epslatex header' command line does not
> have anything to do with the contents of the epslatex_header variable.

The format may not, but the contents will.  So, looking at this from a 
little closer (after having updated my CVS working copy), I see the 
following: you need conv_text() to un-do the effect of having used 
quote_str() to fill epslatex_header, which interpreted backslash 
sequences into actual newlines for you (by calling parse_esc()).

But meanwhile, the text you're trying to put into term_options (with the 
quotes still in their original format) is still available in its 
original form, right where quote_str() found it, so you could just copy 
the string argument directly from gp_input_line[] to term_options[].

I.e. you don't really need conv_text() --- you only need strcpy(), but 
from a different source than the already munged epslatex_header.

And while we're at it: I have serious usability reservations about the 
'header' option.  It's barely usable for your example prefixing two 
simple \usepackage lines --- this really should be a header taken from a 
file, instead.  At least it should be allowed to keep it in a separate 
file.  Or to use this option multiple times, to generate multiple header 
lines.

> The point is that conv_text() is used by routines that take strings from
> options of commands of the command line, for example, 'set title'.  What
> conv_text() does is to take input strings that may be written between
> single quotes '...' or between double quotes "..." and map them to a
> unique format that corresponds to that in double quotes "...".  

Actually, it does only the second half of that job: turning 
non-printable back into printable syntax.  The other (first) half is
done by argument input functions (in set.c, unset.c, ...), which 
indirectly all use util.c:parse_esc() to parse backslash-escape 
sequences into actual newlines, tabs and whatnot.

Re: Compile warnings in new post/pslatex terminal code

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

On Sun, 13 Feb 2005, Hans-Bernhard Broeker wrote:

> Harald Harders wrote:
>
> > The format in the 'set terminal epslatex header' command line does not
> > have anything to do with the contents of the epslatex_header variable.
>
> The format may not, but the contents will.  So, looking at this from a
> little closer (after having updated my CVS working copy), I see the
> following: you need conv_text() to un-do the effect of having used
> quote_str() to fill epslatex_header, which interpreted backslash
> sequences into actual newlines for you (by calling parse_esc()).
>
> But meanwhile, the text you're trying to put into term_options (with the
> quotes still in their original format) is still available in its
> original form, right where quote_str() found it, so you could just copy
> the string argument directly from gp_input_line[] to term_options[].

Then I ask myself why isn't that done in that way for all options that
contain strings. Thas has been a question to me for a long time: If I type
in
    set title '\hello'
why is it saved as
    set title "\\hello"
? I would prefer to preserve the quotation marks and the original format
in all cases. Then, the parsing of the strings would be moved to the
position where they are used. I am aware that this is a big change but I
think it will improve consistency.

> And while we're at it: I have serious usability reservations about the
> 'header' option.  It's barely usable for your example prefixing two
> simple \usepackage lines --- this really should be a header taken from a
> file, instead.

I don't agree. It is useful to be able to make some local header additions
in a gnuplot script. If you have multiple gnuplot files that all need
different headers an external header file would be impractical. Of course,
for more complex headers, an external file is useful (which already is
possible, see below).

> At least it should be allowed to keep it in a separate file.

It is already: If gnuplot.cfg is in the LaTeX path it is loaded. This may
be in the current working directory or somewhere in $TEXMF.

> Or to use this option multiple times, to generate multiple header
> lines.

This could be an option. But I think the current approach is easier to
handle. Otherwise, we would need additional commands to remove all header
information etc. as it is done with Postscript fontfile.

I have uploaded a patch that uses the original syntax including the
quotation marks for the 'show terminal' and 'save' commands:
#1121971, "Avoid usage of conv_text() in post.trm".
As the name indicates, this avoids to use conv_text() in post.trm.

I really think it was a good idea to handle all kinds of strings in a
similar way.

Regards
Harald

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

Re: Compile warnings in new post/pslatex terminal code

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

On Sunday 13 February 2005 10:54 am, Harald Harders wrote:
> 
> Have a look at this example:
> 
> set terminal epslatex standalone color \
>   header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" \
>   'default' 12

Yuck. Guaranteed to scare away novice users, like me.

Do you really expect people to type that gibberish in the 'set term'
command?  Surely this belongs in an auxilliary file, or should
be constructed by the driver itself from more user-friendly
commands on the order of 
	set termoption packages (mathpmnt, times, ...)


And what is that font encoding business?  Is it fighting against
the "set encoding" command?

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

Re: Compile warnings in new post/pslatex terminal code

[Petr M. <mi...@ph...>]

> > set terminal epslatex standalone color \
> >   header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" \
> >   'default' 12
>
> Yuck. Guaranteed to scare away novice users, like me.

LaTeX users are power users, and the above syntax does exactly what it is
supposed to do -- add raw LaTeX commands to the document. Thus it should be
like that.

> commands on the order of
> 	set termoption packages (mathpmnt, times, ...)

That's confusing.

---
PM

Re: Compile warnings in new post/pslatex terminal code

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

On Mon, 14 Feb 2005, Petr Mikulik wrote:

> > > set terminal epslatex standalone color \
> > >   header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" \
> > >   'default' 12
> >
> > Yuck. Guaranteed to scare away novice users, like me.
>
> LaTeX users are power users, and the above syntax does exactly what it is
> supposed to do -- add raw LaTeX commands to the document. Thus it should be
> like that.
>
> > commands on the order of
> > 	set termoption packages (mathpmnt, times, ...)
>
> That's confusing.

I am glad that I am not the only one who thinks like that.

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

Re: Compile warnings in new post/pslatex terminal code

[<dan...@ie...>]

> On Mon, 14 Feb 2005, Petr Mikulik wrote:
>
>> > > set terminal epslatex standalone color \
>> > >   header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" \
>> > >   'default' 12
>> >
>> > Yuck. Guaranteed to scare away novice users, like me.
>>
>> LaTeX users are power users, and the above syntax does exactly what it
>> is
>> supposed to do -- add raw LaTeX commands to the document. Thus it shou=
ld
>> be
>> like that.
>>
>> > commands on the order of
>> > 	set termoption packages (mathpmnt, times, ...)
>>
>> That's confusing.
>
> I am glad that I am not the only one who thinks like that.

I think so too, but I also think that Ethan's recent point is a valid one=
.
 The nature of the beast (LaTeX) is to deal with packages, etc. somewhere=
.
 But my intuition is to do that in a separate file.

Often I generate figures in Xfig and plots in Gnuplot that have added
blocks of text.  These can get wordy with commands like
\begin{minipage}{1.5in}, and so on.  But rather than type the whole thing
into Xfig (ever try typing in Xfig's edit window?  ay, ay, ay) or Gnuplot
I will instead put something like \txta and \txtb, then define those
inside the LaTeX file.

Certainly nobody is forced to use the standalone option.  But consider th=
e
difference.  Either I

1) Create an auxiliary LaTeX file that I copy from an existing file that
I've created in the past.  The information in this file indicates the
packages to use, etc.  I change a few things like the name of the include=
d
file.

2) Create a Gnuplot input file from some existing one I've created in the
past which has the standalone string already in it, because I certainly a=
m
not going to type in that information anew every time.

3) Run some thirdparty program, e.g., say someone had the wherewithall to
write an Octave script for printing such standalone LaTeX figures.  That
program could use the standalone option.

My estimate is that 1 and 2 are pretty much the same mechinations.=20
However, 3 might put me in the pro-standalone camp.  If I wrote a program
with a pipe to gnuplot, I certainly would like to send all information
through that pipe rather than create some temporary file.

Dan

Re: Compile warnings in new post/pslatex terminal code

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

On Sun, 13 Feb 2005, Ethan Merritt wrote:

> > Have a look at this example:
> >
> > set terminal epslatex standalone color \
> >   header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" \
> >   'default' 12
>
> Yuck. Guaranteed to scare away novice users, like me.

It scares away non-LaTeX users as you appear to be. But LaTeX users will
understand the syntax. What is difficult using this syntax? You
do understand
    set title "first line\nsecond line"
What is that different with the header "..." line?

> Do you really expect people to type that gibberish in the 'set term'
> command?  Surely this belongs in an auxilliary file,

There is also the possibility of using 'gnuplot.cfg' which automatically
is loaded when available. When working with the epslatex terminal I have
noticed that this is impractical in some cases. For example if you want
different headers in different files.

Thus:
- gnuplot.cfg is useful for common settings for different plot of the same
  project.
- The header option is useful for local settings that shall only appear
  for the current plot.

I think using another auxilliary file for local settings in impractical.
You always have to handle two files then. Or you have to use a really
strange syntax like:

set print 'localplot.cfg'
print '\usepackage[T1]{fontenc}'
print '\usepackage{mathpmnt}'
unset print
set terminal epslatex headerfile 'localplot.cfg'

I don't like this syntax.

> or should
> be constructed by the driver itself from more user-friendly
> commands on the order of
> 	set termoption packages (mathpmnt, times, ...)

That scares away any LaTeX user. How do you want to add optional
parameters of the \usepackage commands? Or how do you want other useful
LaTeX commands like '\newcommand\fracab{\frac{a}{b}}'? It is not possible.
This kind of syntax would constrain LaTeX users.

> And what is that font encoding business?  Is it fighting against
> the "set encoding" command?

Original TeX only knew about 7bit fonts with at least 128 characters.
\usepackage[T1]{fontenc} switches to 8bit encoded fonts with 256
characters (for example, real umlauts). It does not have to do anything
about the inputencoding. In LaTeX the input encoding is handled by
\usepackage[latin1]{inputenc}, for example. The input encoding command is
already handled by Gnuplot when using the standalone option. In 'input'
mode (which produces a LaTeX file that is meant to be \input-ed into
another LaTeX file), a comment line is written that tells the user which
input encoding has been used for the gnuplot file.

Your question has raised an idea: It is also possible for plots that are
embedded using \input to change the encoding locally, by using
\inputencoding{...}. I have uploaded a patch that uses this possibility:
#1121972 "Improve input encoding in epslatex terminal".
In addition, this patch adds the missing koi8-u encoding.

Regards
Harald

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

Re: Compile warnings in new post/pslatex terminal code

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

On Sunday 13 February 2005 01:17 pm, Harald Harders wrote:
> > >  
> Then I ask myself why isn't that done in that way for all options that
> contain strings. Thas has been a question to me for a long time: If I type
> in
>     set title '\hello'
> why is it saved as
>     set title "\\hello"
> ? I would prefer to preserve the quotation marks and the original format
> in all cases. 

I agree. I pointed this out as being a problem while I was struggling
with handling string variables.  I ended up being able to work around
it, but I also think that the single-quoted-ness or double-quoted-ness
of a string should be maintained across a save/load operation.
Currently it is not, so you cannot guarantee to reproduce the current
state.

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

Re: Compile warnings in new post/pslatex terminal code

[<dan...@ie...>]

> On Sunday 13 February 2005 01:17 pm, Harald Harders wrote:
>> > >
>> Then I ask myself why isn't that done in that way for all options that
>> contain strings. Thas has been a question to me for a long time: If I
>> type
>> in
>>     set title '\hello'
>> why is it saved as
>>     set title "\\hello"
>> ? I would prefer to preserve the quotation marks and the original form=
at
>> in all cases.
>
> I agree. I pointed this out as being a problem while I was struggling
> with handling string variables.  I ended up being able to work around
> it, but I also think that the single-quoted-ness or double-quoted-ness
> of a string should be maintained across a save/load operation.
> Currently it is not, so you cannot guarantee to reproduce the current
> state.

Keep in mind that if one is to type in a newline character "\n", double
quotes are a must, for otherwise stuff like "\newenvironment" or somethin=
g
similar would fail.  It would have to be "\\newenvironment".

Dan

Re: Compile warnings in new post/pslatex terminal code

[<dan...@ie...>]

> On Sun, 13 Feb 2005, Ethan Merritt wrote:
>
>> > Have a look at this example:
>> >
>> > set terminal epslatex standalone color \
>> >   header "\\usepackage[T1]{fontenc}\n\\usepackage{mathpmnt}" \
>> >   'default' 12
>>
>> Yuck. Guaranteed to scare away novice users, like me.
>
> It scares away non-LaTeX users as you appear to be. But LaTeX users wil=
l
> understand the syntax. What is difficult using this syntax? You
> do understand
>     set title "first line\nsecond line"
> What is that different with the header "..." line?
>
>> Do you really expect people to type that gibberish in the 'set term'
>> command?  Surely this belongs in an auxilliary file,
>
> There is also the possibility of using 'gnuplot.cfg' which automaticall=
y
> is loaded when available. When working with the epslatex terminal I hav=
e
> noticed that this is impractical in some cases. For example if you want
> different headers in different files.
>
> Thus:
> - gnuplot.cfg is useful for common settings for different plot of the s=
ame
>   project.
> - The header option is useful for local settings that shall only appear
>   for the current plot.
>
> I think using another auxilliary file for local settings in impractical=
.
> You always have to handle two files then. Or you have to use a really
> strange syntax like:
>
> set print 'localplot.cfg'
> print '\usepackage[T1]{fontenc}'
> print '\usepackage{mathpmnt}'
> unset print
> set terminal epslatex headerfile 'localplot.cfg'
>
> I don't like this syntax.


I use LaTeX almost exclusively for documents, but I've come in at the
middle of this conversation.  I'm very used to including the epslatex
output in a LaTeX file.  Or I create a simple little file with all the
necessary header information, then compile that and convert the figure to
EPS using the -E option of dvips.

So I guess your standalone option is supposed to allow someone to create =
a
file to circumvent the process I described above.  I can see that as bein=
g
useful for some 3rd party program that wants to generate a no-brainer
latex file for a user.  (But wouldn't a more generic format be in order,
where one could simply append gnuplot output to an open file?)  But I
can't ever see myself using such a thing, unless you could convince me of
some time savings.

In the first case I simply copy a short "auxiliary" file I've already
written for some other figure and change the name within.  A bit kludgy,
but not bad.  And if I want to change something in the header, no problem=
,
no need to rerun gnuplot.  (Of course, that is the case for the proposed
syntax, but the presumption is that the new syntax is the way to make
changes.  In the proposed case I must always keep track of the header fil=
e
when I'm creating a figure through gnuplot or Octave.  Hmmm...  I just
don't know.  For automated third party programs?  Perhaps.

Dan

Re: Compile warnings in new post/pslatex terminal code

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

> I use LaTeX almost exclusively for documents, but I've come in at the
> middle of this conversation.  I'm very used to including the epslatex
> output in a LaTeX file.

If using LaTeX for the whole document, using \input to include the plot
generated by gnuplot is the best solution, of course. I have never done
this before since the epslatex terminal was not capable of the important
features of the postscript terminal. This problem is solved now, as you
may have noticed.

> Or I create a simple little file with all the
> necessary header information, then compile that and convert the figure to
> EPS using the -E option of dvips.

This can be done now using 'set terminal epslatex standalone'. You don't
have to handle an additional header file then, because gnuplot produces
everything you need. You even can omit the -E switch of dvips since the
generated header file preserves the correct BoundaryBox, when using
latex->dvips and when using epstopdf->pdflatex. There ist one difference:
The new syntax produces the BoundingBox that is given by the 'set size'
command while dvips -E cuts off all white space. If you, for example,
produce white space around your plot, using 'set size', it is kept in your
final postscript file.

> So I guess your standalone option is supposed to allow someone to create a
> file to circumvent the process I described above.  I can see that as being
> useful for some 3rd party program that wants to generate a no-brainer
> latex file for a user.

It's not only useful for 3rd party programmes. Since it has been
available, I often use it because I find it is easier to add the keyword
'standalone' to the 'set terminal' line than to edit an additional LaTeX
file. Another advantage is that you don't have to take care that the font
sizes match in the gnuplot and the LaTeX file since the fontsize given in
the 'set terminal' line is also used by the surrounding LaTeX code. And,
the input encoding given in Gnuplot is also used by LaTeX, automatically.
Dan, just try the 'standalone' option. Maybe you can give me feedback what
can be improved.

> (But wouldn't a more generic format be in order,
> where one could simply append gnuplot output to an open file?)

What do you mean by that? Could you please explain it in more detail?

> But I can't ever see myself using such a thing, unless you could
> convince me of some time savings.

As mentioned above. Just try it. For example, if you want a standalone
plot with Times in 12pt size, use:

set terminal epslatex standalone header '\usepackage{mathptmx}' '' 12

As you see here, the 'header' option gives access to additional commands
in the header of the LaTeX file. If you have more complex additions that
shall apply to more than one gnuplot file, you may use the file
'gnuplot.cfg'. If using this, you also don't have to rerun gnuplot.

What I often do is to add some code at the end of my gnuplot file:

set terminal epslatex standalone rounded color linewidth 2 \
  header '\usepackage{mathpmtx}' '' 12
set output 'myplot.tex'
...
set output
!epstopdf myplot-inc.eps
!pdflatex myplot

This produces a plot in pdf format by simply starting
    gnuplot myplot.gpl

Dan, if you have additinal questions or suggestions, just mail me.

BTW: I have received two additional mails by you that cannot be displayed
by my pine.

Regards
Harald

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

Re: Compile warnings in new post/pslatex terminal code

[<dan...@ie...>]

>> Or I create a simple little file with all the
>> necessary header information, then compile that and convert the figure
>> to
>> EPS using the -E option of dvips.
>
> This can be done now using 'set terminal epslatex standalone'. You don'=
t
> have to handle an additional header file then, because gnuplot produces
> everything you need. You even can omit the -E switch of dvips since the
> generated header file preserves the correct BoundaryBox, when using
> latex->dvips and when using epstopdf->pdflatex. There ist one differenc=
e:
> The new syntax produces the BoundingBox that is given by the 'set size'
> command while dvips -E cuts off all white space. If you, for example,
> produce white space around your plot, using 'set size', it is kept in y=
our
> final postscript file.

Funny because a month or so ago I had a conversation with Ethan and Hans
about cropping *all* of the white space surrounding plots.  (It's always
easier to add than to take away.)

>
>> (But wouldn't a more generic format be in order,
>> where one could simply append gnuplot output to an open file?)
>
> What do you mean by that? Could you please explain it in more detail?

Well, it would be the case where the higher level application opens the
file, puts information there and then requests gnuplot to append to the
file.  In fact, it could be generic, like

set output 'foo.ps' append

(I'm not proposing the above, just making a point.)

>
>> But I can't ever see myself using such a thing, unless you could
>> convince me of some time savings.
>
> As mentioned above. Just try it. For example, if you want a standalone
> plot with Times in 12pt size, use:

I can imagine using such a feature.  But the typing of the LaTeX code for
the header is the issue:

> set terminal epslatex standalone header '\usepackage{mathptmx}' '' 12

What Ethan mentioned; just too cumbersome... unless one uses the syntax a
lot.  I wonder why one needs this.  OK, the gnuplot.cfg could cover the
special users.  But since gnuplot is generating the code, why can't the
terminal driver figure out all the packages that are needed?  Maybe an
option like

set terminal epslatex standalone font "times"

would result in

\usepackage{times}

in the code.  Didn't Ethan propose making the "font" that keeps showing u=
p
in terminal options an actual command?


>
> What I often do is to add some code at the end of my gnuplot file:
>
> set terminal epslatex standalone rounded color linewidth 2 \
>   header '\usepackage{mathpmtx}' '' 12
> set output 'myplot.tex'
> ...
> set output
> !epstopdf myplot-inc.eps
> !pdflatex myplot
>
> This produces a plot in pdf format by simply starting
>     gnuplot myplot.gpl

That's nice.


> BTW: I have received two additional mails by you that cannot be display=
ed
> by my pine.

Can you tell me a date for one of those emails?  Thanks,

Dan

Re: Compile warnings in new post/pslatex terminal code

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

On Mon, 14 Feb 2005 dan...@ie... wrote:

> > This can be done now using 'set terminal epslatex standalone'. You don't
> > have to handle an additional header file then, because gnuplot produces
> > everything you need. You even can omit the -E switch of dvips since the
> > generated header file preserves the correct BoundaryBox, when using
> > latex->dvips and when using epstopdf->pdflatex. There ist one difference:
> > The new syntax produces the BoundingBox that is given by the 'set size'
> > command while dvips -E cuts off all white space. If you, for example,
> > produce white space around your plot, using 'set size', it is kept in your
> > final postscript file.
>
> Funny because a month or so ago I had a conversation with Ethan and Hans
> about cropping *all* of the white space surrounding plots.  (It's always
> easier to add than to take away.)

I did not want to say that it is an advantage that the white space is
preserved. It is just a difference. I also think it could be a good thing
to _optionally_ remove all white space around a plot.

> >> But I can't ever see myself using such a thing, unless you could
> >> convince me of some time savings.
> >
> > As mentioned above. Just try it. For example, if you want a standalone
> > plot with Times in 12pt size, use:
>
> I can imagine using such a feature.  But the typing of the LaTeX code for
> the header is the issue:
>
> > set terminal epslatex standalone header '\usepackage{mathptmx}' '' 12
>
> What Ethan mentioned; just too cumbersome... unless one uses the syntax a
> lot.

I don't think so. A LaTeX user knows which packages and commands he needs
to reach a special output. He is used to use \usepackage commands.

> I wonder why one needs this.  OK, the gnuplot.cfg could cover the
> special users.  But since gnuplot is generating the code, why can't the
> terminal driver figure out all the packages that are needed?  Maybe an
> option like
>
> set terminal epslatex standalone font "times"
>
> would result in
>
> \usepackage{times}

Then, a LaTeX user would have to learn that in using LaTeX, he has to use
\usepackage{mathptmx} to get Times-Roman as font while in epslatex, he has
to use 'font "times"'. (BTW: \usepackage{times} is obsolete.) Using the
header command, the LaTeX user can use the same syntax for the gnuplot
header and the normal LaTeX header.

And how do you want gnuplot to cover all possible font wishes?

times --> \usepackage{mathptmx}
minion --> \usepackage[T1]{fontenc}\usepackage{mathpmnt}
cmbright --> \usepackage{cmbright}
latinmodern --> \usepackage{lmodern}
... (thousands of more possibilities that don't follow simple rules)

Using the present 'header' syntax, everything is possible that LaTeX can
do. You can even define abbreviations. If you, for example, are making a
plot for fracture mechanics, you will have to use something like
$K_{\mathrm{Ic}}$. To shorten your code, you can do this:

set terminal epslatex header '\def\Kc{{\ensuremath K_{\mathrm{Ic}}}}'
set xlabel '\Kc'

Everybody who knows LaTeX immediately understands what these lines do.

The current code already supports to switch to fonts without the header
option. But this is a little bit low level:
  set terminal epslatex 'phv,bx,it' 12
switches to Helvetica bold italics. The abbreviations are the LaTeX
internal names for the fonts.

Regards
Harald

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

Re: Compile warnings in new post/pslatex terminal code

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

On Monday 14 February 2005 03:29 pm, Harald Harders wrote:
> 
> set terminal epslatex header '\def\Kc{{\ensuremath K_{\mathrm{Ic}}}}'
> set xlabel '\Kc'
> 
> Everybody who knows LaTeX immediately understands what these lines do.

I doubt it.  Certainly not everyone who *uses* LaTeX knows what those
lines do.

As it stands there is essentially no way I would be able to figure
out how to use the epslatex terminal, even if it would be somewhat
nicer than plain 'set term post eps'.   I use LaTeX via a front end
(LyX) that hides all this gobbledy-gook from me, and I have no
interest in having to learn it just to include gnuplot figures.

I think it would be *far* more appropriate to provide a working set
of header files to be auto-included.  Any power users out there would
be free to edit them, and the rest of us poor novices could ignore them.



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

Re: Compile warnings in new post/pslatex terminal code

[Petr M. <mi...@ph...>]

> > set terminal epslatex header '\def\Kc{{\ensuremath K_{\mathrm{Ic}}}}'
> > set xlabel '\Kc'
> >
> > Everybody who knows LaTeX immediately understands what these lines do.
>
> I doubt it.  Certainly not everyone who *uses* LaTeX knows what those
> lines do.

Thus, there are two folks, one group wants to be able to include raw latex
commands into header, the other link to a file to be \input. The patch
should satisfy both.

---
PM

Re: Compile warnings in new post/pslatex terminal code

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

On Tue, 15 Feb 2005, Petr Mikulik wrote:

> > > set terminal epslatex header '\def\Kc{{\ensuremath K_{\mathrm{Ic}}}}'
> > > set xlabel '\Kc'
> > >
> > > Everybody who knows LaTeX immediately understands what these lines do.
> >
> > I doubt it.  Certainly not everyone who *uses* LaTeX knows what those
> > lines do.
>
> Thus, there are two folks, one group wants to be able to include raw latex
> commands into header, the other link to a file to be \input. The patch
> should satisfy both.

I have uploaded a patch #1123355 "Support a header file in epslatex
terminal" to sourceforge that provides the option 'header file' to the
epslatex terminal. It makes the output file to input the given file using
the LaTeX command \input. The user can either use 'header file' or
'header'. Loading gnuplot.cfg works in all cases.

Regards
Harald

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

Re: Compile warnings in new post/pslatex terminal code

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

Harald Harders wrote:

>     set title '\hello'
> why is it saved as
>     set title "\\hello"
> ? 

Because by the time 'save' operates, it no longer knows if you 
originally use '' or "" quotes.  And because there are some things in a 
string that could only have gotten in there using "" syntax, most 
importantly literal linebreaks.  So, at that point, always using "" 
syntax and escaping all non-printable characters on their out from 
internal storage to the file is the only available option.

>>And while we're at it: I have serious usability reservations about the
>>'header' option.  It's barely usable for your example prefixing two
>>simple \usepackage lines --- this really should be a header taken from a
>>file, instead.
> 
> 
> I don't agree. It is useful to be able to make some local header additions
> in a gnuplot script. 

I'm not debating that.  I'm debating the user interface to getting that 
effect.  Two shortish LaTeX command lines may still reasonably fit into 
a single gnuplot command line, but there comes a point at which it 
becomes highly repetitive and stressful command line editing.  That's 
why I requested taking these header snippets from a separate file as an 
additional option, not as a replacement of the existing one.

Come to think of it, maybe I'm simply against the entire "standalong" 
thingy --- it's not doing anything that a typical LaTeX user can't 
easily do with a quickly typed framework document instead.

>>At least it should be allowed to keep it in a separate file.
> 
> 
> It is already: If gnuplot.cfg is in the LaTeX path it is loaded. This may
> be in the current working directory or somewhere in $TEXMF.

A default configuration file is not exactly what I had in mind, either. 
   I was talking about giving file name instead of the literal string, 
so the string can be pulled from that file, instead of having to become 
part of the already quite crowded "set terminal epslatex" line.

Re: Compile warnings in new post/pslatex terminal code

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

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

> Harald Harders wrote:
>
> >     set title '\hello'
> > why is it saved as
> >     set title "\\hello"
> > ?
>
> Because by the time 'save' operates, it no longer knows if you
> originally use '' or "" quotes.

And that is a shortcoming of the current gnuplot sourcecode. Why does
gnuplot analyse the string when it is input and then forgets which
quotation marks have been used? In my opinion, Gnuplot should just store
the original string including the quotation marks in memory and postpone
to analyse the string to the time when it uses the string. Then, 'save'
and 'show' could output the original string with the originally used
quotation marks. And this would not change any functionality.

> And because there are some things in a
> string that could only have gotten in there using "" syntax, most
> importantly literal linebreaks.  So, at that point, always using ""
> syntax and escaping all non-printable characters on their out from
> internal storage to the file is the only available option.

If you want to analyse the string immediately when inputting it and want
to use either "" or '' in all outputs, you of course have to use "". But
there is no need to do so.
    set title '\nhello'
should be saved as
    set title '\nhello'
and
    set title "\\nhello"
should be saved as
    set title "\\nhello"

> >>And while we're at it: I have serious usability reservations about the
> >>'header' option.  It's barely usable for your example prefixing two
> >>simple \usepackage lines --- this really should be a header taken from a
> >>file, instead.
> >
> >
> > I don't agree. It is useful to be able to make some local header additions
> > in a gnuplot script.
>
> I'm not debating that.  I'm debating the user interface to getting that
> effect.  Two shortish LaTeX command lines may still reasonably fit into
> a single gnuplot command line, but there comes a point at which it
> becomes highly repetitive and stressful command line editing.  That's
> why I requested taking these header snippets from a separate file as an
> additional option, not as a replacement of the existing one.

I could of course add an option 'header file "<filename>"' that inputs
filename. Then, the question is if <filename> should be written as
  \input{filename}
to the output file or if gnuplot should read in <filename> and write the
contents to the output file.

Another possibility that already exists is to use
  set terminal epslatex header '\input{filename}'

> Come to think of it, maybe I'm simply against the entire "standalong"
> thingy --- it's not doing anything that a typical LaTeX user can't
> easily do with a quickly typed framework document instead.

Have you had a look at the header that is produced by gnuplot when using
'standalone'? It's not that easy to write it. It automatically selects the
same fontsize for the output as the plot uses for calculating space of
text. It sets the correct page size for dvips, VTeX, and pdflatex (which
really is hard to do by hand for pdflatex). I don't understand why you
dislike to type in one word ('standalone') instead of multiple lines of
code.


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

Re: Compile warnings in new post/pslatex terminal code

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

On Monday 14 February 2005 09:28 am, Harald Harders wrote:
> 
> Have you had a look at the header that is produced by gnuplot when using
> 'standalone'? It's not that easy to write it. It automatically selects the
> same fontsize for the output as the plot uses for calculating space of
> text. It sets the correct page size for dvips, VTeX, and pdflatex (which
> really is hard to do by hand for pdflatex). 

Isn't that just a really convoluted way to "set term pdf" ?
Why go through latex at all if you really want a pdf plot?



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

Re: Compile warnings in new post/pslatex terminal code

[<dan...@ie...>]

> On Monday 14 February 2005 09:28 am, Harald Harders wrote:
>>
>> Have you had a look at the header that is produced by gnuplot when usi=
ng
>> 'standalone'? It's not that easy to write it. It automatically selects
>> the
>> same fontsize for the output as the plot uses for calculating space of
>> text. It sets the correct page size for dvips, VTeX, and pdflatex (whi=
ch
>> really is hard to do by hand for pdflatex).
>
> Isn't that just a really convoluted way to "set term pdf" ?
> Why go through latex at all if you really want a pdf plot?

Because one can use the LaTeX fonts (i.e., match the fonts in your
document) and--most importantly--use the latex typesetting to get useful
mathematical symbols in the figures.

Dan