☰

tikzpictures 通过 dvips 和 ps2pdf 处理时会产生巨大的 pdf 文件

tag-icon • tag-icon tikz-pgf ps2pdf dvips
tikzpictures 通过 dvips 和 ps2pdf 处理时会产生巨大的 pdf 文件

我写了一篇包含几张 TikZ 图片的论文，并将其提交给 Springer 期刊。当我收到他们根据我的源文件生成的 pdf 文件时，我感到非常震惊，因为它超过了 8 MiB - 而我自己的 pdf 只有 170 KiB。

首先，我将 pdf 剪切为单页，发现尺寸来自 TikZ 图片。

然后我意识到该期刊很可能使用 tex -> dvi -> ps -> pdf 工作流程，而我使用的是 pdflatex。因此，我以另一种方式编译了这篇论文，结果如下：dvi 文件为 655 KiB，ps（通过 dvips）为 625 KiB，但 pdf（通过 ps2pdf 或 ghostview）为 7.8 MiB。（细微的差异是由于期刊添加了标题页。）

有没有办法使用基于 dvips 的路线生成更合理大小的 pdf 文件？

我尝试\newcommand{\pgfsysdriver}{pgfsys-dvips.def}在包含 tikz 之前添加，但没有任何反应。

我还尝试使用“外部”包创建 poscript 图形来生成图形的 eps 版本，但结果是相同的：对于其中一个图形，保存为 pdf 时为 12 KiB，保存为 ps 时为 183 KiB - 使用 epstopdf 可得到 183 KiB eps，然后得到 3.1 MiB(!) pdf。（如果我在 ghostview 中将 12 KiB pdf 转换为 eps，我会得到 1.5 MiB eps，然后使用 epstopdf 可得到 361 KiB pdf - 稍微好一点，但仍然很大。）

编辑：一个工作示例：

\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 生成 19 KiB pdf，而 latex + dvips + ps2pdf 生成 209 KiB dvi -> 197 KiB ps -> 2954 KiB pdf。

谢谢

答案1

图片中的阴影元素确实是问题所在。此外，我的第一个假设是将pgf对象存储在 PDF Form XObjects 中并重复使用它们。事实并非如此。PDF 直接支持可以通过函数对象自定义的不同阴影类型。因此，pgf通过定义函数来设置阴影操作，当放置阴影元素时，阴影操作仅会占用一些字节。

PostScript 也具有此功能，但它需要语言级别 3。pgf不支持此功能，并且编写的代码没有该功能。这意味着，它必须使用更原始的绘图运算符手动编程着色，并且必须对每个着色元素一次又一次地重复此操作，因为 Form XObjects 也不可用。

为重复的对象定义一个过程可以节省空间。但这会占用打印机内存，并且对于不重复的对象效率低下。

如果您愿意冒险通过 PostScript 级别 3，那么请使用pgf支持 PDF 着色功能的驱动程序将图片生成为 PDF，例如 pdfTeX。

然后你需要一个能够生成 PostScript 3 级的转换器和支持此语言级别的阴影功能。

  • pdftops3.00（来自xpdf）知道选项-level3，但后者的要求失败并生成一个非常大的 PostScript 文件。

  • AR7/Linux、AR8/Linux：acroread -toPostScript -level 3 -pairs test.pdf test.ps生成 PostScript 文件，其中阴影元素丢失。

  • gs -sDEVICE=epswrite -dLanguageLevel=3 -dBATCH -dNOPAUSE -sOutputFile=test.eps test.pdf 由于同样的原因，9.05 版本也失败了。

如果您找到转换器，下一步就是检查图片是否打印在整张纸上，以及图片是否在边界框内。还需要测试重新转换。GhosScript 的某些版本是否支持该转换器？期刊使用哪种转换器？等等。

测试并找到支持 PostScript 阴影功能的程序会很有趣。但我认为这对于期刊和类似工作的工作流程来说有点冒险，因为您无法控制程序和使用的版本。

相关内容