Fast Web View : comment un PDF s'ouvre avant la fin de son téléchargement

SpecSpec: ISO 32000-2, Annex FISO 32000-2 Annex F

En bref

Un PDF linéarisé est réorganisé de sorte que la première page et un petit index de navigation se trouvent tout au début du fichier. Un lecteur peut donc dessiner la page un pendant que le reste du document arrive encore, et sauter directement à la page 147 sans lire d’abord les pages 2 à 146.

C’est la fonctionnalité que la plupart des lecteurs connaissent sous son nom familier : Fast Web View.

Pourquoi c’est important

Imagine un rapport de 200 pages sur un téléphone avec une seule barre de signal. Sans linéarisation, le lecteur a souvent besoin de la toute fin du fichier avant de pouvoir dessiner quoi que ce soit, car l’index maître qui indique où se trouve chaque objet se situe traditionnellement à l’arrière. Tu regardes donc un spinner tourner pendant que deux cents pages se téléchargent, juste pour lire la première.

Avec la linéarisation, le fichier est agencé de sorte que la réponse à « qu’y a-t-il sur la page un » soit la première chose à sortir du câble. Le lecteur peint la page un en une seconde, et ne récupère le reste qu’au fil de ton défilement ou de tes sauts. Sur une connexion rapide, tu ne le remarqueras peut-être jamais. Sur une connexion lente ou facturée à l’usage, c’est la différence entre un document utilisable et un onglet abandonné.

La version courte

• Un fichier linéarisé est chargé par l’avant : la page un et une table d’indices sont placées en premier, avant le reste du corps.
• La table d’indices est une carte de plages. Elle indique au lecteur quelles plages d’octets appartiennent à chaque page et aux objets partagés, afin que le lecteur puisse demander au serveur juste ces tranches — puis la table de références croisées résout chaque numéro d’objet vers son offset exact.
• Cela repose sur les requêtes par plage d’octets — le lecteur récupère des tranches du fichier à la demande, pas le fichier entier.
• Les octets ont un contenu identique à un PDF normal. La linéarisation change l’ordre et l’index, pas les pages elles-mêmes.
• C’est une étape explicite et commutable dans NextPDF — produite par une vraie reconstruction en trois passes, pas un drapeau qui espère que tout ira bien.

L’approche de NextPDF

Tu ne peux pas charger une page par l’avant tant que tu ne sais pas exactement quelle est la taille de chaque chose, car la table d’indices enregistre des offsets d’octets et un offset n’est correct qu’une fois la longueur de chaque objet définitive. Cette circularité — les offsets dépendent des tailles, les tailles dépendent de la mise en page — explique pourquoi un linéariseur s’exécute en passes plutôt qu’en un seul balayage.

NextPDF la résout avec une reconstruction déterministe en trois passes. La première passe mesure, la deuxième décide du placement, la troisième écrit les vrais octets avec les offsets désormais connus intégrés.

1. MEASURESerialise every object once to learn its exact byte length. Offsets are circular — they depend on sizes — so sizes are pinned first.
2. PLACEDecide the order: first page and its dependencies up front, then the rest. Reserve space for the linearization parameter dictionary and the hint table.
3. FILLWrite the final bytes. Each reserved field is filled with values computed after MEASURE and PLACE — the first-page length, the hint-table location, the main cross-reference offset — derived from the measured sizes and the chosen placement.

La reconstruction de linéarisation en trois passes. MEASURE dimensionne chaque objet pour que les longueurs soient définitives ; PLACE décide de l'ordre chargé par l'avant et réserve la région de la table d'indices ; FILL écrit les vrais octets avec les offsets désormais connus, de sorte que la première page et la table d'indices atterrissent à l'avant et que les données de références croisées se résolvent dès la première récupération.

La sortie porte un dictionnaire de paramètres de linéarisation comme premier objet et une ou plusieurs tables d’indices qui indexent les pages, exactement comme la norme le prescrit (SpecSpec: ISO 32000-2, Annex FISO 32000-2 Annex F). Ces tables d’indices fonctionnent aux côtés d’une table de références croisées traditionnelle — elles enregistrent les plages d’octets et les emplacements qu’un lecteur doit récupérer, tandis que la table de références croisées est l’index qui associe chaque numéro d’objet à son offset d’octet exact. Le linéariseur de NextPDF émet la forme de table classique et évince tout flux de références croisées au passage, de sorte qu’une fois une tranche arrivée, le lecteur résout un objet par son offset directement depuis cette table (SpecSpec: ISO 32000-2, §7.5.4ISO 32000-2 §7.5.4).

Un modèle mental utile : un PDF normal est un livre dont la table des matières est collée à la quatrième de couverture. Un PDF linéarisé déplace cette table des matières vers l’avant et ajoute un index page par page, pour que tu puisses ouvrir directement n’importe quelle page. Les chapitres sont inchangés. Seule la navigation a bougé.

Exemple pratique

La linéarisation est une étape explicite et commutable. Tu la demandes ; le moteur effectue la reconstruction et émet un fichier Fast-Web-View.

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Contracts\OutputDestination;

$document = Document::createStandalone();
$document->setTitle('Annual Report');

for ($page = 1; $page <= 200; $page++) {
    $document->addPage();
    $document->setFont('helvetica', '', 12);
    $document->cell(0, 12, "Page {$page}", newLine: true);
}

// Linearization is requested explicitly — an operability choice, not a default.
// enableLinearization() takes no arguments; it is the on-switch. The engine
// runs the MEASURE -> PLACE -> FILL rebuild and emits a Fast-Web-View file
// with the first page and hint table at the front.
$document->enableLinearization();

$bytes = $document->output(dest: OutputDestination::String);

Le contenu de la page est exactement ce que tu as rédigé. La différence réside dans l’ordre de fichier des octets que tu reçois, et dans la table d’indices qui se trouve désormais près du sommet.

Tu vérifies le résultat comme le ferait un inconnu — avec un outil de contrôle externe :

$ qpdf --check-linearization report.pdf
report.pdf: no linearization errors

qpdf --check-linearization ne se contente pas de chercher un drapeau. Il re-dérive les offsets que le fichier prétend avoir et confirme qu’ils sont vrais : que les objets de la première page sont bien là où le dictionnaire de linéarisation le dit, que la table d’indices pointe vers les bons octets, et que la structure est conforme à l’Annexe F. Un fichier qui ment sur sa propre disposition échoue à cette vérification, même s’il a l’air linéarisé au premier coup d’œil.

Idée fausse courante

L’hypothèse fréquente est que la linéarisation compresse le fichier ou rend le téléchargement globalement plus rapide. Elle ne fait ni l’un ni l’autre. Un fichier linéarisé est souvent un peu plus gros, car il porte les tables d’indices supplémentaires. Le temps de transfert total de l’ensemble du document est essentiellement inchangé.

Ce qui change, c’est le moment où apparaît le premier pixel utile. La linéarisation optimise le temps jusqu’à la première page, pas le nombre total d’octets. C’est une fonctionnalité de latence, pas une fonctionnalité de compression. Diffuser la page un tôt et télécharger le fichier vite sont des objectifs différents, et la linéarisation sert le premier.

Une seconde idée fausse est que n’importe quel serveur web diffusera un fichier linéarisé. Le lecteur doit récupérer des plages d’octets, ce qui signifie que le serveur doit honorer les requêtes de plage HTTP. La plupart le font, mais un serveur qui renvoie toujours le fichier entier transforme Fast Web View en une lente attente du fichier complet — le fichier est prêt à être diffusé, mais le transport ne l’est pas.

Human-factors note:Human-factors note

Linearization is an explicit, switchable step, and that is deliberate. It costs an extra serialisation pass to produce, and it helps most for large documents served over slow links and opened in a browser. For a small invoice generated and emailed as an attachment, it adds work for no benefit. Making it a switch rather than an always-on default lets you spend that cost exactly where a reader feels it — the big public report on a phone — and skip it where they never would.

Limites et frontières

NextPDF dispose d’un support core complet pour produire des fichiers linéarisés : un linéariseur de production en trois passes qui émet le dictionnaire de paramètres et les tables d’indices et passe un contrôle Annexe F externe.

Fast Web View (linearization) output — edition availability

Edition	Availability
Core	○ Full support. NextPDF produces linearized (Fast Web View) output through a production three-pass MEASURE → PLACE → FILL rebuild, conforming to ISO 32000-2 Annex F.
Pro	○Not in this edition
Enterprise	○Not in this edition

Deux frontières méritent d’être nommées. Premièrement, la linéarisation est une propriété d’une révision. Au moment où tu ajoutes une mise à jour incrémentale — une signature, un remplissage de formulaire, une modification — les octets ajoutés vont à la fin et le fichier n’est plus strictement linéarisé tant qu’il n’est pas reconstruit. C’est un compromis normal, pas un défaut ; vois les mises à jour incrémentales pour comprendre pourquoi l’ajout est le bon comportement pour les documents signés.

Deuxièmement, le moteur contrôle le fichier. Il ne contrôle pas le réseau. Fast Web View ne tient sa promesse que lorsque la connexion de service honore les requêtes par plage d’octets ; les octets peuvent être parfaitement linéarisés et arriver quand même en un seul bloc lent si le serveur insiste pour envoyer le fichier entier.

Documents liés

• L’anatomie d’un fichier PDF — l’en-tête, le corps, la table de références croisées et le trailer que la linéarisation réagence. Lis-le d’abord pour voir ce qui est réordonné.
• Mémoire et streaming — le streaming côté écriture, un axe différent : comment NextPDF garde une mémoire plate en produisant des octets, par opposition à la façon dont un lecteur les diffuse en entrée.
• Les mises à jour incrémentales et pourquoi elles comptent — pourquoi une modification ultérieure s’ajoute à la fin, et ce que cela signifie pour la disposition chargée par l’avant d’un fichier linéarisé.
• Flux et filtres — ce qui vit à l’intérieur des objets de corps vers lesquels pointe la table d’indices, et comment ils sont compressés.

Glossaire

• Linéarisation — la reconstruction qui charge par l’avant la première page et un index de navigation pour qu’un lecteur puisse rendre et naviguer avant l’arrivée du fichier entier. Le nom donné au résultat par la norme.
• Fast Web View — le nom orienté grand public d’un PDF linéarisé ; les deux termes décrivent le même fichier.
• Table d’indices — la structure à l’intérieur d’un fichier linéarisé qui enregistre les plages et emplacements d’octets de chaque page et des objets partagés, pour qu’un lecteur sache quelles tranches demander ; la table de références croisées est ce qui associe ensuite un numéro d’objet à son offset d’octet exact.
• Dictionnaire de paramètres de linéarisation — le premier objet d’un fichier linéarisé ; il déclare les offsets clés (longueur de la première page, emplacement de la table d’indices, position de la table de références croisées principale) qui rendent la récupération à la demande possible.
• Requête par plage d’octets — une requête HTTP portant sur une tranche d’un fichier plutôt que sur l’ensemble ; le mécanisme de transport dont dépend Fast Web View.
• Temps jusqu’à la première page — la durée avant qu’un lecteur ne voie la page un. La latence que la linéarisation optimise, distincte du temps de téléchargement total.