Out of simple curiosity, having seen the smallest GIF, what is the smallest possible valid PDF file?
The smallest possible valid PDF
optimizationpdfpdf-generation
Related Topic
- Javascript – Generating PDF files with JavaScript
- Sqlite – Improve INSERT-per-second performance of SQLite
- Linux – Merge / convert multiple PDF files into one PDF
- Convert PDF to PNG using ImageMagick
- Html – the purpose of the “role” attribute in HTML
- C++ – Why does C++ code for testing the Collatz conjecture run faster than hand-written assembly
Best Answer
This is an interesting problem. Taking it by the book, you can start off with this:
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.
However, Acrobat X doesn't even bother with the cross reference table anymore, so we can take that out:
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:
Turns out you don't need all those pesky /Type elements in your dictionaries:
Now we're at 138 bytes.
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:
70 bytes.
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
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.
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.