تخطيط PDF خطيًا

ماذا تفعل هذه الأداة

A linearised PDF is the same document with its objects in a different order. Everything the first page needs is moved to the front of the file, so a reader can draw page one while the remaining megabytes are still arriving. Nothing about the pages, the text or the images changes - open the result next to the original and you will not be able to tell them apart on screen.

Do it to any PDF you publish on a website, link to in an email, or hand to a viewer embedded in an app. It matters most for large files on slow connections, where a document that opens in two seconds and one that appears to hang for thirty are the same file in two different orders.

كيف تعمل

1. Drop the PDF onto this page. Files up to 300 MB are accepted.
2. Leave Also repack the file on. It recompresses the streams first, which usually takes another 10 to 25 per cent off the size.
3. Press Linearize.
4. The download starts on its own, with a -web suffix so you can tell the two versions apart.
5. Upload the result as it is. No setting is needed to produce the effect, though your server must support byte-range requests for readers to use it.

The mechanism is ordering, not compression. In an ordinary PDF the objects sit wherever the producer wrote them and the index that finds them is at the end, so a reader over HTTP either waits for the whole file or asks for pieces of it in several round trips. Linearising puts a small hint table, the first page and every object that page depends on right at the front, followed by the rest in page order.

Repacking and linearising pull against each other, which is why the order of the passes matters. Object streams make a file smaller by packing many objects into one compressed block, and linearisation needs the first page's objects reachable on their own. The repack runs first and the linearisation last, so qpdf resolves the conflict rather than producing a file that claims to be linearised and is not.

The effect only exists if the server cooperates. Fast Web View depends on HTTP byte-range requests: the reader asks for the first part of the file, draws page one, then asks for more. A server that does not honour ranges sends the whole file regardless, and the linearised document behaves like the ordinary one. Most static hosting and every CDN supports ranges; some application frameworks streaming a file through their own handler do not.

If the repack fails on an unusual file, you still get the linearisation you asked for. Recompression is treated as a bonus rather than a requirement.

The job happens in your browser through qpdf compiled to WebAssembly, so the file you are preparing to publish - often still a draft - reaches no server before you put it on one.