我正试图围绕 PDF 文件结构展开思考。有一个标题、一个带有对象的正文、一个交叉引用表和一个预告片。在来自 Adobe 的官方PDF reference，关于文件预告的第 3.4.4 节中，我们可以看到：
PDF 文件的预告片使读取文件的应用程序能够快速找到交叉引用表和某些特殊对象。应用程序应从末尾读取 PDF 文件。
这在我看来效率很低。在加载整个文件之前，我无法以这种方式向用户显示任何内容（甚至不是第一页）。好吧，准确地说，我可以 - 如果我的文件是线性化。但这是可选的，并且在写入和读取此类文件时意味着一些额外的开销。
而不是整个线性化的事情，将引用放在 前面 正文会更容易（后面是第 1 页、第 2 页、第 3 页上的对象...）。但 Adobe 中的人可能有理由将其放在 之后。我只是没有看到他们。所以...
为什么将交叉引用表放在正文之后？
【问题讨论】：
标签： pdf file-format
我同意已经提到的两个原因，但不是因为“过去”的硬件限制，而是因为规模。很容易认为包含几页文本的发票可以做得更好，但是一本书或包含 1000 张照片的 PDF 呢？
使用末尾的预告片，您可以在处理图像/文本/字体时将它们写入文件，然后从内存中丢弃它们，同时只需存储每个对象的文件偏移量以用于写入预告片。
如果预告片必须先出现，那么您将必须读取（甚至在嵌入字体的情况下生成）所有这些对象以获得它们的大小，以便您可以写出预告片，然后写入所有对象到文件。因此，您要么读取、调整大小、丢弃，然后再次读取，要么尝试将所有内容保存在 ram 中，直到您可以将它们写入文件。
当我们在共享硬件上的虚拟机上的 docker 容器中运行时，写入速度和内存仍然是我们今天要解决的问题。..
【讨论】：
PDF 是在硬盘驱动器写入文件速度很慢时发明的......真的很s-l-o-w。通过将外部参照放在末尾，您可以通过简单地将新对象和更新的外部参照附加到文件末尾而不是重写整个文件来快速更改文件。
【讨论】：
不仅驱动器速度慢（引起@joelgeraci 的回答中的论点），典型计算机中可用的 RAM 也少得多。因此，在创建 pdf 时，必须尽早将数据写入文件，远远早于人们知道文件有多大，或者因此交叉引用会变成多大。因此，在最后编写交叉引用是一个自然的结果。
【讨论】：