什么是可能的最小有效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 joy. 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约定，因此通过使用十六进制编辑器，我用\ r替换了\ r \ n并完全删除了最后一个换行符，这使我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 \r\n with \r 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(HA！看看我在那儿做什么吗?)，如果您同意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屋！