想象一下以下 tikz/pgfplots 代码:
% compile as: lualatex --jobname=figname-f1 figname.tex
\documentclass[10pt]{book}
\usepackage{tikz}
\usepackage{pgfplots}
\pgfplotsset{compat=1.6}
\pgfrealjobname{figname}
\pdfminorversion=5
\pdfobjcompresslevel=6
\pdfcompresslevel=9
\begin{document}
\beginpgfgraphicnamed{figname-f1}%
\begin{tikzpicture}
\begin{axis}[width=14cm,height=6cm,scale only axis,axis lines=left,axis]
\addplot3 coordinates{
(8.27605704077856,0.505526531790625,1.15577754382534e-05)
(8.27605704077856,1.01105306358125,4.16291426502054e-06)
(8.27605704077856,1.51657959537188,3.77146738938349e-06)
.... % many more lines similar to the one above
};
这个 tex 文件大约 3Mb。编译它得到figname-f1.pdf
。现在用零替换所有非常小的第三部分,即:
\addplot3 coordinates{
(8.27605704077856,0.505526531790625,0)
(8.27605704077856,1.01105306358125,0)
(8.27605704077856,1.51657959537188,0)
.... % many more lines similar to the one above
};
这个新的 tex 文件大约有 2Mb。编译它。
在我正在处理的个人示例中,两个 .pdf 文件大小相同,约为 530kb。这是预期的吗?
答案1
值得注意的是 (La)TeX解释代码并生成输出。本例中的输出是生成的 PDF,其二进制形式由一堆形状(圆形、线条、矩形和一些嵌入内容,例如字体)组成。
(2,3)的解释可能会产生 PDF 二进制形式中(2.0000000,3.0000000)的广义表示,从而膨胀生成的 PDF 的大小以适应最多 7 位小数的精度*。但是,这也意味着指定超过 7 位小数的精度可能会被四舍五入/截断(或瘪)在保持对象/形状的数量和类型不变的情况下,即使输入的精度可能存在很大的差异,这种输出方面的标准化也会导致 PDF 大小相似。
无论您将对象/形状放置在代码(输入)中的位置 (2,3)、位置 (2.0,3.0)、位置 (2.0001,3.0001) 还是位置 (2.718281828459045,3.141592653589793),结果(输出)在 PDF 中仍然是二维的相同对象/形状。因此,预期输出大小相同。
*我不确定 PDF 二进制文件使用的准确性。这只是一个例子。