5 ms·

One interesting thing I noticed is that the shortest conforming PDF 2.0 file clocks in at 254 bytes long (if you strip out the indentation): %PDF-2.0 1 0 o

One interesting thing I noticed is that the shortest conforming PDF 2.0 file clocks in at 254 bytes long (if you strip out the indentation): %PDF-2.0 1 0 obj<</Count 0/Kids[]/Type/Pages>>endobj 2 0 obj<</Pages 1 0 R/Type/Catalog>>endobj xref 0 3 0000000000 65535 f 0000000009 00000 n 0000000053 00000 n trailer<</ID[( )( )]/Root 2 0 R/Size 3>> startxref 96 %%EOF This is 41 bytes longer than the shortest conforming file in PDF 1.0 through PDF 1.7, which do not require the ID entry in the file trailer dictionary. (Apart from the ID entry and file header, the shortest file is otherwise identical.) The standard justifies its mandatory inclusion by saying that "some workflows" require PDF files to be "uniquely identified". I wonder what sort of workflows those might be.

popcorncowboy 4y ago
DRM fingerprinting
- LegionMammal978 4y ago
  At least the standard doesn't seem to support that: it suggests creating the ID by hashing the current time, file path, and file size. Besides, there are a billion other side channels that can be used to digitally watermark PDFs. Anyway, I've since found an explanation in the PDF 1.7 spec. PDF files can include "file specifications" (file paths or URLs) to refer to other files. An ID can be added to a file specification for an external PDF, which the PDF reader can validate against the ID contained in the located file's trailer dictionary, to ensure that the external PDF is the expected one. I guess "some workflows" must have gotten upset when trying to generate a link to a PDF file with no ID, so they finally required its presence in the spec.