A big document whose first page shows straight away
You send a customer a four-hundred-page catalogue. They click the link, and nothing happens for eight seconds. They are not waiting for page four hundred — they only wanted to look at page one. A document can be written so that page one appears almost at once and the rest keeps arriving behind it. Same pages, same lettering, near enough the same weight.
What happens when somebody clicks a link to a PDF
A PDF file is written back to front. Everything the document is made of comes first, and the index saying where each piece sits comes last, right at the end of the file.
That is fine on a disk: the reading program jumps to the end, reads the index, and goes straight to the pieces it needs. It is not fine down a wire. To read an index that sits at the end, you have to receive the end. To receive the end, you have to receive everything before it. So the person waits for four hundred pages to look at one.
Written the other way round, the file opens with page one, everything page one needs, and a small index saying where every other page begins. The reading program draws page one and fetches the rest while the person is busy reading. Jump to page fifty and it asks for page fifty alone rather than for the whole book.
Nothing else changes. The same document, the same pages, and somebody who opens it from their own machine sees no difference at all.
The word, for whoever is looking for it
This is called linearising a PDF, and a file written that way is a linearised PDF — or linearized, spelled the American way, which is how you will most often meet it in a list of requirements. Some reading software calls the same thing Fast Web View, and shows it as a yes or a no in the document's properties.
If that is the line you have to tick, this is the tick: our engine writes linearised PDF, and it is one switch.
Detail — 42 882 bytes instead of 519 049
One document, two hundred pages of a numbered table, written twice: once the ordinary way, once first page first. Nothing else differs between the two files.
- 519 049 bytes — must arrive before page one can be drawn, on the file written the ordinary way — which is the whole of it.
- 42 882 bytes — on the file written first page first.
- 476 167 bytes — no longer waited for.
That is 8% of the file.
The figures are read off the two files themselves, not typed in. The sheet they are printed on is a document you can download, and that sheet is itself written first page first.
When it makes no difference
Worth knowing before you switch it on, because it is the part nobody tells you. The gain is felt only when the document is read as it arrives, and two things have to be true for that.
- The server that hands the file over has to be able to send a slice of it on request. Most do, out of the box. A server that only ever sends whole files hands over the whole file, and the reading program waits for it like before.
- The reading software has to make use of it. The ones built into Chrome, Firefox and Edge do. So does Adobe Acrobat Reader. Some others read the file the ordinary way — and lose nothing at all doing so, because the document is the same document.
And it does nothing at all in the cases where nobody is waiting: a file attached to an email, a file copied to a shared folder, a file downloaded whole and opened afterwards. In all of those the document has already landed before anybody looks at it.
So: if your documents are opened from a link, this is worth switching on and it costs you nothing. If they are sent as attachments, it changes nothing and it still costs you nothing.
Technically
Linearisation in the sense of ISO 32000, clause 7.5.8: a first-page cross-reference section and the linearisation parameter dictionary at the head of the file, page one and its resources immediately after, then the remaining objects, then the main cross-reference section. The hint tables — the shared-object hint stream and the page-offset hint stream — let a reader work out the byte range of any page and ask for it in a single ranged request.
The figure above is the /E entry of the parameter dictionary, which states the offset of the end of the first page: everything before it is what a reader must hold before drawing. A file written the ordinary way states nothing of the kind, so the answer for it is its own length. That is why the two numbers are comparable — one measurement, applied to two spellings of one document.
What to check at your end: the server must answer Accept-Ranges: bytes and honour Range requests with a 206, on the exact route that serves the documents — a front-end server placed in front, a compression layer applied on the fly, or a delivery network set to transform the body will each quietly turn ranged requests back into whole-file transfers. Content-encoded responses are the usual culprit: a PDF served under Content-Encoding: gzip cannot be range-requested meaningfully, and a PDF is already compressed inside, so serving it uncompressed is the right call anyway.
It composes with everything else: object streams, tagging, PDF/A and PDF/UA conformance, encryption, signing. It is written last, over the finished document, so it never changes what the pages say.
Where to look next
The document that was measured, and its program What a linearised PDF is, in the glossary Changing the library that writes your documents The engine inside your own program