应用程序为什么要向后读取PDF文件？

Question

我试图围绕PDF文件结构。有一个标题，一个带有对象的主体，一个交叉引用表和一个预告片。在Adobe的官方PDF reference中，关于文件预告片的第3.4.4节，我们可以读到：

  

PDF文件的预告片使读取文件的应用程序能够快速找到交叉引用表和某些特殊对象。应用程序应从其末尾读取PDF文件。

这对我来说效率很低。在加载整个文件之前，我无法以这种方式向用户显示任何内容（甚至不是第一页）。好吧，确切地说，我可以 - 如果我的文件线性化。但这是可选的，并且在写入和读取此类文件时都会带来额外的开销。

而不是整个线性化的东西，只需将引用放在主体前面（后面是第1页，第2页，第3页上的对象......）就更容易了。但Adobe的人可能有理由在之后将其放入。我只是没有看到他们。所以......

为什么交叉引用表在正文后放置？

Answer 1

当硬盘驱动器写文件很慢时，PDF就被发明了......真的是s-l-o-w。通过将外部参照放在最后，您可以通过简单地将新对象和更新的外部参照附加到文件末尾而不是重写整个文件来快速更改文件。

Answer 2

驱动器不仅速度慢（引起@ joelgeraci答案中的争论），而且典型计算机中的RAM也少得多。因此，在创建pdf时，必须尽早将数据写入文件，比任何人更早知道文件有多大，或者因此交叉引用会变得多。因此，最后编写交叉引用是一个自然的结果。

Answer 3

我同意已经提到的两个原因，但不是因为“当天”的硬件限制，而是规模。可以很容易地认为带有几页文本的发票可以更好地完成，但是一本书或一张包含1,000张照片的PDF呢？

最后使用预告片，您可以在处理文件时将图像/文本/字体写入文件，然后将其从内存中丢弃，同时只存储用于编写预告片的每个对象的文件偏移量。

如果预告片必须先到，那么你必须阅读（或者甚至在嵌入字体的情况下生成）所有这些对象只是为了获得它们的大小以便你可以写出预告片，然后写下所有的对象到文件。因此，您可以阅读，调整大小，丢弃，然后再次阅读，或尝试将所有内容保存在ram中，直到您可以将它们写入文件。

当我们在共享硬件上的VM上的docker容器中运行时，写入速度和ram仍然是我们所面临的问题。