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