#1822 lua / tikz / pgf terminal not generating latex-compilable DVI and PostScript

[Dan Sebald]

The lua/tikz terminal generates proper code for the "pdflatex" processor. That is, a correct PDF file results that can be viewed in acroread or xpdf. Example

set term tikz standalone
set output 'test.tex'
test
set output

However, the LaTeX code cannot properly be compiled with "latex" to create a DVI file that can be converted to PostScript. I.e.,

latex test
dvips test -o test.ps
gv test.ps

The result is a lot of PostScript stack errors when interpretted. Similarly, this variant of pdflatex

pdflatex -output-format dvi test.tex
dvips test -o test.ps
gv test.ps

behaves the same as "latex" processing. Doing a diff between the two PS files shows they are exactly the same except for the first line or two which is the name of the source document.

Somehow the pdflatex command is doing something that latex is not. Given one of the PostScript errors:

Error: /undefined in pgfo

I think I see what the problem is. In the PostScript file is the use of the command pgfo, but it isn't defined anywhere. So it may be the case that pdflatex defines what pgfo is, but normal latex processing doesn't. And my guess is that pgfo is defined (maybe conditionally?) by the pgf TeX package.

In the special directory /usr/local/share/texmf/tex/latex/gnuplot is a set of style files that get included with the tikz LaTeX output when processed with latex or pdflatex. In particular, gnuplot-lua-tikz-common.tex has a lot of pgf-related instructions. Do you think we need to include some type of default definition for pgfo within that file?

I'm attaching a PostScript file created via the "latex" process. One may search the file in an editor for "pgfo".

[Ethan Merritt]

I defer to those with more TeX knowledge, but my understanding is that pdflatex, pdftex, xetex, and probably other variants support tikz+pgf directly, whereas plain latex and pslatex require help from some additional packages or preprocessing.

[Dan Sebald]

That's probably true. My best guess is that it is this file of PostScript commands:

/usr/share/texmf/tex/generic/pgf/systemlayer/pgfsys-dvips.def

that needs to be included somehow. This seems to be the only location of a pgfo definition.

[Dan Sebald]

For reference, Section 10 of the Tikz/PGF manual discusses how to configure the system for the DVI portion of the processing. It seems to suggest that dvips is a viable alternative, but I can't seem to get it to work by including any of the packages meantioned or redefining \pgfsysdriver.

http://www.texample.net/media/pgf/builds/pgfmanualCVS2012-11-04.pdf

[Dan Sebald]

I've made some progress. If I make just this change from

\usepackage[active,tightpage]{preview}

to

\usepackage[tightpage]{preview}

in the TikZ tex file, latex will work correctly. (Of course, this is effectively turning off the preview package.) However, the -E option of

latex sinewave-tikz.tex
dvips sinewave-tikz.dvi -o sinewave-tikz.ps -E

does not properly crop the figure. Instead, it appears as the attached screenshot, which to me looks like about the size of the backdrop of the legend/keybox.

[Dan Sebald]

The documentation for the preview package is here:

http://mirrors.acm.jhu.edu/ctan/macros/latex/contrib/preview/preview.pdf

It is meant to achieve what the -E option of dvips does, but done better.

[Dan Sebald]

I can't seem to make the preview package work so well. In the documentation for preview package is a comment about the option "dvips" which is meant to undo things that other packages may have added for proper operation with dvips. I'm not sure exactly what is happening, but I suspect that preview package is removing parts of what was added by the pgfsys-dvips.eps file.

In any case, that preview code is a result of using "standalone" option with the lua tikz terminal. A post at this website:

http://tex.stackexchange.com/a/57528

suggested using the "standalone" class rather than the preview package. So I made this change:

sebald@ ~/octave/gnuplot-multiple_eps_latex $ diff -pur test-orig.tex test.tex 
--- test-orig.tex   2016-06-29 00:10:53.223987415 -0500
+++ test.tex    2016-06-29 00:11:33.003987804 -0500
@@ -1,4 +1,4 @@
-\documentclass[10pt]{article}
+\documentclass[10pt]{standalone}
 \usepackage[T1]{fontenc}
 \usepackage{textcomp}

@@ -7,9 +7,6 @@

 \usepackage{gnuplot-lua-tikz}
 \pagestyle{empty}
-\usepackage[active,tightpage]{preview}
-\PreviewEnvironment{tikzpicture}
-\setlength\PreviewBorder{\gpbboxborder}
 \begin{document}

 \begin{tikzpicture}[gnuplot]

And that works pretty well for both "pdflatex" and "latex". The crop isn't exactly right in both cases. In the case of pdflatex (test.pdf) the black border is cropped off of the right side. In the case of latex + dvips (test.ps) there is extra white pixels outside three of the borders.

Does the above change work for those interested? If so, any interest in changing the lua tikz standalone mode to use "standalone" class and remove \def\gpbboxborder{0mm} from file /usr/local/share/texmf/tex/latex/gnuplot/gnuplot-lua-tikz-common.tex? (Or is gpbboxborder important for other cases?)