Executive summary

This report ships as a linearized PDF — also called Fast Web View in desktop readers. A linearized file places a small linearization parameter dictionary as its very first object, followed by everything a viewer needs to paint page one, so a browser or reader can begin displaying content while the rest of the file is still arriving over the network. For a short brief like this one the difference is barely perceptible; for the multi-hundred-page manuals, statements, and archival bundles NextPDF renders in production, it is the difference between an instant first page and a multi-second blank-screen wait.

How Fast Web View streaming works

ISO 32000-2 Annex F defines the linearized file structure precisely so that any conforming reader can exploit it, without vendor-specific tricks:

• The /Linearized dictionary is the first object in the file and declares the byte offset of the last page's cross-reference section, so a reader can confirm the file is genuinely linearized in a single read.
• A primary hint stream immediately follows, encoding compact per-page and per-object byte offsets and lengths — the reader's map for jumping straight to any page without parsing the whole file.
• Page 1's objects, and only page 1's objects, are placed next, ahead of every later page, so the first page is fully paintable from the leading bytes alone.
• A first-page cross-reference table follows page 1's objects, letting a reader resolve page-1 references before the rest of the file's main cross-reference table exists.
• Remaining pages are then reorganized in reading order, each reachable via the hint stream's offsets, enabling true byte-range, page-by-page delivery over HTTP.

Time to first page by connection profile

Measured against a representative 220-page NextPDF statement bundle, serving over HTTP byte-range requests instead of waiting for the complete download:

Figures are illustrative reference measurements for a 220-page bundle; actual gains scale with document size and shrink toward zero on very short documents like this sample.

When to enable it

Turn linearization on for anything a person opens directly in a browser tab or a desktop reader over a network link — statements, contracts, manuals, and reports delivered by URL rather than as an email attachment already on disk. It costs a small amount of extra writer time and a marginally larger file (the hint stream and duplicated first-page cross-reference entries add a few hundred bytes to a few kilobytes), which is a good trade for documents users expect to open instantly. The engine keeps this configuration mutually exclusive with encryption and in-process signing. The release pipeline signs the completed linearized base as an ISO 32000-2 §12.8 incremental update: /L continues to identify the first revision while the signature chain extends the published file. Skip linearization for documents that are always fully downloaded before opening, such as files delivered over internal batch transfer or archived directly to disk.

Reader & delivery compatibility

Linearization is a hint, not a requirement — every reader can still open a linearized file the ordinary way, and only readers plus delivery paths that support HTTP byte-range requests actually see the fast first page:

Verifying a linearized file

Two independent signals confirm linearization took effect: a structural check that the file's first object is a valid /Linearized dictionary whose /L value matches the unsigned file length, or the first revision through its terminal %%EOF once the release signature is appended; and a visual check in any PDF reader that supports progressive rendering. NextPDF's release pipeline runs both checks, plus a third-party qpdf --check pass, before publication.