最小的有效 PDF 是多少? [英] What is the smallest possible valid PDF?

问题描述

出于单纯的好奇，看过最小的 GIF, 最小的有效 PDF 文件是多少?

Out of simple curiosity, having seen the smallest GIF, what is the smallest possible valid PDF file?

推荐答案

这是一个有趣的问题.按照这本书，你可以从这个开始:

This is an interesting problem. Taking it by the book, you can start off with this:

%PDF-1.0
1 0 obj<</Type/Catalog/Pages 2 0 R>>endobj 2 0 obj<</Type/Pages/Kids[3 0 R]/Count 1>>endobj 3 0 obj<</Type/Page/MediaBox[0 0 3 3]>>endobj
xref
0 4
0000000000 65535 f
0000000010 00000 n
0000000053 00000 n
0000000102 00000 n
trailer<</Size 4/Root 1 0 R>>
startxref
149
%EOF

这是 291 字节的 PDF 乐趣.Acrobat 打开它，但它有些抱怨.其中有一页，它是 3/72" 正方形，这是规范允许的最小值.

which is 291 bytes of PDF joy. Acrobat opens it, but it complains somewhat. There is one page in it and it is 3/72" square, the minimum allowed by the spec.

但是，Acrobat X 甚至不再理会交叉引用表，因此我们可以将其删除:

However, Acrobat X doesn't even bother with the cross reference table anymore, so we can take that out:

%PDF-1.0
1 0 obj<</Type/Catalog/Pages 2 0 R>>endobj 2 0 obj<</Type/Pages/Kids[3 0 R]/Count 1>>endobj 3 0 obj<</Type/Page/MediaBox[0 0 3 3]>>endobj
trailer<</Size 4/Root 1 0 R>>

Acrobat 抱怨，但打开了它.现在我们有 178 个字节.事实证明，您不需要预告片中的/Size .现在我们在 172:

Acrobat complains, but opens it. Now we're at 178 bytes. Turns out that you don't need that /Size in the trailer. Now we're at 172:

%PDF-1.0
1 0 obj<</Type/Catalog/Pages 2 0 R>>endobj 2 0 obj<</Type/Pages/Kids[3 0 R]/Count 1>>endobj 3 0 obj<</Type/Page/MediaBox[0 0 3 3]>>endobj
trailer<</Root 1 0 R>>

事实证明，您的字典中不需要所有那些讨厌的/Type 元素:

Turns out you don't need all those pesky /Type elements in your dictionaries:

%PDF-1.0
1 0 obj<</Pages 2 0 R>>endobj 2 0 obj<</Kids[3 0 R]/Count 1>>endobj 3 0 obj<</MediaBox[0 0 3 3]>>endobj
trailer<</Root 1 0 R>>

现在我们有 138 个字节.

Now we're at 138 bytes.

事实证明，当规范说应该是间接引用"和/Count 是必需的，并且标题必须"是 %PDF-1.0 时，他们提出了松散的建议.这是我能做到的最小的并且可以在 Acrobat X 中打开它:

It also turns out that when the spec says "shall be an indirect reference" and /Count is required, and the header "must" be %PDF-1.0, they're making loose suggestions. This is the smallest I could make it and have it openable in Acrobat X:

%PDF-1.
trailer<</Root<</Pages<</Kids[<</MediaBox[0 0 3 3]>>]>>>>>>

70 字节.

现在，我的编辑器使用 Windows 换行符规则，但 Acrobat 接受 Windows、Mac 或 Unix 约定，因此通过使用十六进制编辑器，我将 替换为 并完全删除了最后一个换行符，这让我67 字节

Now, my editor uses Windows newline discipline, but Acrobat accepts Windows, Mac, or Unix conventions, so by using a hex editor, I replaced the with and removed the last newline altogether, which leaves me with 67 bytes

25 50 44 46 2D 31 2E 0D 74 72 61 69 6C 65 72 3C 
3C 2F 52 6F 6F 74 3C 3C 2F 50 61 67 65 73 3C 3C 
2F 4B 69 64 73 5B 3C 3C 2F 4D 65 64 69 61 42 6F 
78 5B 30 20 30 20 33 20 33 5D 3E 3E 5D 3E 3E 3E 
3E 3E 3E 

我尝试去掉最后一个字典 (>>)，但 Acrobat 没有.Google Chrome (FoxIt) 内置的 PDF 阅读无法打开.

I tried taking off the last end dictionary (>>), but Acrobat wouldn't have that. The PDF reading built-in to Google Chrome (FoxIt) won't open it.

作为 PostScript(哈！看看我在那里做了什么?)，如果你同意 Acrobat修复"文件，它会增加到 3550 字节，其中大部分是可选的元数据，但它留下了一些明确的规范违规行为.

As a PostScript (HA! See what I did there?), if you consent to Acrobat "repairing" the file, it bumps up to 3550 bytes, most of it optional metadata, but it leaves behind a number of clear spec violations.

这篇关于最小的有效 PDF 是多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！