tikzpictures give huge pdf files when processed via dvips and ps2pdf

Question

I have written a paper that includes a couple of TikZ pictures and submitted it to a (Springer) journal. I was quite shocked when I got the pdf file they produced from my source file, since it was over 8 MiB - while my own pdf is only 170 KiB.

First, I cut the pdf to single pages and found that the size comes from the TikZ pictures.

Then I realized that the journal most likely uses tex -> dvi -> ps -> pdf workflow, while I am using pdflatex. I therefore compiled the paper the other way and there it was: dvi file was 655 KiB, ps (via dvips) was 625 KiB, but pdf (via ps2pdf, or via ghostview) was 7.8 MiB. (The small difference is due to the journal adding a title page.)

Is there some way to produce a more reasonably-sized pdf file using the dvips-based route?

I tried adding \newcommand{\pgfsysdriver}{pgfsys-dvips.def} just before including tikz, but it did not do anything.

I also tried producing eps version of the figures, using the 'external' package to create poscript figures, but it is the same: for one of the figures, it is 12 KiB saved as pdf and 183 KiB as ps - which gives 183 KiB eps and then 3.1 MiB(!) pdf using epstopdf. (If I convert the 12 KiB pdf to eps in ghostview, I get 1.5 MiB eps, which then gives 361 KiB pdf using epstopdf - bit better, but still huge.)

edit: a working example:

\documentclass{article}
\usepackage{tikz}
\tikzstyle{strat}=[text=white, circle, ball color=red, inner sep=3pt]
\tikzstyle{oper}=[text=white, rectangle, ball color=blue, inner sep=1.75pt, level distance=\lvlDist] 
\newlength\lvlDist\setlength\lvlDist{12pt} % distance between levels

\begin{document}
\begin{figure}[tbp]
    \centering
    \begin{tikzpicture}[level distance=\lvlDist, grow=down, every node/.style={oper}]
        \path[
                level 1/.style={sibling distance=40mm},
                level 6/.style={sibling distance=20mm},
                level 7/.style={sibling distance=10mm},
                level 12/.style={sibling distance=5mm},
                level 13/.style={sibling distance=2mm}
            ]
            node[strat](root){} child foreach \oPI in {1,...,2} {
                node{} child { node{} child { node{} child {node{} child {
                node{} child foreach \perI in {1,...,2} {
                    node[strat]{} child foreach \oPII in {1,...,2} {
                    node{} child { node{} child { node{} child { node{} child {
                    node{} child foreach \perII in {1,...,2} {
                        node[strat]{} child foreach \oPIII in {1,...,2} {
                        node{} child { node{} child { node{} child { node{} child {
                            node{}
                        }}}}}
                    }}}}}}
                }}}}}
            }
        ;
    \end{tikzpicture}
\end{figure} 
\end{document}

Pdflatex produces a 19 KiB pdf, while latex + dvips + ps2pdf give 209 KiB dvi -> 197 KiB ps -> 2954 KiB pdf.

Thanks

Answer 1

The shaded elements in the picture are indeed the problem. Also my first assumption was that pgf stores the objects in PDF Form XObjects and reuses them. That is not the case. PDF supports different shading types directly that can be customized by function objects. Therefore pgf sets up the shading operation by defining functions and when the shaded elements are placed, the shading operation costs some bytes only.

Also PostScript has this feature, but it requires language level 3. pgf does not support this and writes the code without that features. That means, it has to program the shading manually with more primitive drawing operators and has to repeat it for every shaded element again and again, because Form XObjects are not available either.

Space could be saved by defining a procedure for the repeated objects. But it will cost printer memory and is inefficient for not repeated objects.

If you want to take the risk in going via PostScript level 3, then generate the picture as PDF using a driver, for which pgf supports the PDF shading features, e.g. pdfTeX.

Then you need a converter that is able to generate PostScript level 3 and supports the shading feature of this language level.

• pdftops 3.00 (from xpdf) knows option -level3, but fails in the latter requirement and generates a very huge PostScript file.

• AR7/Linux, AR8/Linux: acroread -toPostScript -level 3 -pairs test.pdf test.ps generates a PostScript file, where the shaded elements are lost.

• gs -sDEVICE=epswrite -dLanguageLevel=3 -dBATCH -dNOPAUSE -sOutputFile=test.eps test.pdf also fails in version 9.05 for the same reason.

If you find a converter, the next step would be the check of the bounding box for the case the picture is printed on the full paper. Also the reconversion needs to be tested. It is supported in some versions of GhosScript? Which converter is used by the journal? And so on.

It would be interesting to test and find programs that support PostScript's shading feature. But I would consider it a bit risky for the workflow with journals and similar, where you do not have the control over the programs and the used versions.