Pourquoi une visionneuse doit-elle regarder la fin d'un PDF normal ?

Parce que le format PDF place la table de références croisées (xref), qui indique où se trouve chaque objet dans le fichier, à la fin de celui-ci. Ce choix de conception permet les mises à jour incrémentales : les nouvelles modifications sont ajoutées à la fin et une nouvelle xref est écrite, sans altérer l'ancienne. Le prix à payer est l'obligation de commencer la lecture par la fin.

Que contient exactement une table d'indices (hint table) ?

Il en existe deux principales. La table d'indices de décalage de page indique dans quelle plage d'octets du fichier se trouvent les objets de chaque page. La table d'indices des objets partagés indique où se trouvent les ressources utilisées en commun par plusieurs pages (polices, images répétées). Lorsqu'elle saute à une page, la visionneuse consulte ces deux tables et ne demande que les plages d'octets nécessaires.

Un fichier linéarisé s'ouvre-t-il aussi dans les visionneuses ordinaires ?

Oui, parfaitement. La linéarisation fait partie de la norme et un fichier linéarisé est en même temps un PDF normal valide ; une table xref figure toujours à la fin du fichier. Une visionneuse qui ne comprend pas la linéarisation lit le fichier par la méthode classique et ne rencontre aucun problème. Le bénéfice disparaît, mais la compatibilité reste intacte.

Pourquoi une mise à jour incrémentale casse-t-elle la linéarisation ?

Parce que la promesse fondamentale de la linéarisation est que tout ce qui est nécessaire pour dessiner la première page se trouve au début du fichier. Une mise à jour incrémentale ajoute les modifications à la fin et écrit une nouvelle xref ; la visionneuse doit désormais regarder la fin pour connaître l'état courant. Le fichier reste valide, mais la garantie d'affichage web rapide devient caduque.

Qu'est-ce qu'un PDF linéarisé ? Les coulisses techniques de l'affichage web rapide

De deux PDF de même taille, l'un s'ouvre instantanément dans le navigateur, l'autre affiche une page blanche jusqu'à ce qu'il soit entièrement téléchargé. La différence ne tient pas au contenu du fichier — mais à l'ordre des objets à l'intérieur. Dans cet article, nous expliquons le mécanisme de lecture du PDF, comment la linéarisation le renverse et à quoi servent les tables d'indices.

Pourquoi un PDF se lit par la fin

À la fin d'un fichier PDF se trouvent ces trois éléments :

startxref
1247893
%%EOF

La ligne startxref indique à quel octet du fichier commence la table de références croisées. La première chose que fait une visionneuse en ouvrant un PDF est de lire les quelques centaines d'octets finaux pour trouver ce nombre.

Elle se rend ensuite à cet octet et lit la table xref. Cette table liste le numéro de chaque objet du fichier et l'octet auquel il commence. La table est suivie d'un dictionnaire trailer, qui indique le numéro de l'objet catalogue.

La visionneuse peut désormais trouver le catalogue. Du catalogue, elle passe à l'arbre des pages, de l'arbre des pages à l'objet de la première page, puis au flux de contenu et aux ressources utilisées. Ces ressources peuvent se trouver n'importe où dans le fichier — la police de la première page au milieu, son image tout à la fin.

Cette conception a une raison : la mise à jour incrémentale. Lorsqu'un PDF est modifié, plutôt que de réécrire tout le fichier, les modifications sont ajoutées à la fin et une nouvelle table xref est écrite. La nouvelle table pointe vers l'ancienne en disant « pour ce qui n'a pas changé, regarde là-bas ». Le fichier grossit mais l'opération est rapide, et l'ancienne version reste présente dans le fichier. C'est aussi sur ce mécanisme que reposent les signatures numériques.

Le prix à payer : vous devez voir la fin du fichier avant de pouvoir en lire la moindre partie.

Pourquoi cela pose problème sur le réseau

Sur un disque local, sauter à la fin d'un fichier est pratiquement gratuit. Sur le réseau, la situation est différente.

Lorsqu'un navigateur demande un PDF à un serveur, celui-ci commence à envoyer le fichier depuis le début. Or l'information dont la visionneuse a besoin se trouve tout à la fin. Autrement dit, pour dessiner la première page, il faut en pratique que le fichier entier soit arrivé.

Un catalogue de 50 Mo met environ 40 secondes à se télécharger sur une connexion à 10 Mbit/s. Pendant ces 40 secondes, l'utilisateur regarde une page blanche. La plupart des utilisateurs n'attendent pas.

La linéarisation inverse l'ordre

La structure d'un PDF linéarisé est la suivante :

| Emplacement | Contenu | |---|---| | Début du fichier | Dictionnaire de paramètres de linéarisation (/Linearized) | | Juste après | Table xref et trailer de la première page | | Ensuite | Tous les objets de la première page (contenu, police, image) | | Ensuite | Les tables d'indices (hint tables) | | Ensuite | Les objets des autres pages, dans l'ordre des pages | | Fin du fichier | Table xref principale (pour la compatibilité) |

Le dictionnaire de paramètres, tout au début du fichier, indique : ce fichier est linéarisé, sa longueur totale est de tant, les objets de la première page vont jusqu'à tel octet, les tables d'indices commencent ici.

Grâce à cela, dès qu'elle a reçu les premières centaines de kilo-octets du fichier, la visionneuse dispose de tout ce qu'il faut pour dessiner la première page. L'utilisateur commence à lire pendant que le téléchargement se poursuit.

Les tables d'indices : la structure qui rend le saut de page possible

Le second bénéfice de la linéarisation, peut-être le plus précieux, est de pouvoir sauter directement à la page voulue.

C'est ce que permettent les tables d'indices. Il y en a deux :

La table d'indices de décalage de page (Page Offset Hint Table) : pour chaque page, elle indique à partir de quel octet du fichier commencent ses objets et sur combien d'octets ils s'étendent. Lorsque l'utilisateur saute à la page 147, la visionneuse consulte cette table, y lit que « la page 147 se situe entre les octets 8 234 100 et 8 291 000 » et ne demande que cette plage au serveur.

La table d'indices des objets partagés (Shared Object Hint Table) : elle liste les ressources utilisées en commun par plusieurs pages — polices intégrées employées dans tout le document, logo répété sur chaque page. Si la page 147 a besoin de certaines d'entre elles, la visionneuse y trouve également leur plage d'octets.

Résultat : dans un fichier de 500 pages et 80 Mo, il suffit de télécharger quelques centaines de kilo-octets pour afficher la page 147.

Byte-range : la condition côté serveur

Le mécanisme ci-dessus repose sur la capacité du navigateur à dire au serveur « donne-moi les octets 8 234 100 à 8 291 000 de ce fichier ». En HTTP, cela se fait via l'en-tête Range, et le serveur doit répondre par un 206 Partial Content.

Presque tous les serveurs web modernes le prennent en charge pour les fichiers statiques, et c'est généralement activé par défaut. Mais cela ne fonctionne pas dans les cas suivants :

Si le fichier est généré dynamiquement (un serveur applicatif qui produit le PDF à la volée), les requêtes byte-range ne sont généralement pas prises en charge.
Si la réponse est compressée avec gzip, les plages d'octets perdent tout sens. Les PDF étant déjà compressés en interne, appliquer gzip côté serveur est à la fois inutile et générateur de ce problème.
Certaines configurations de CDN ou de proxy peuvent ne pas laisser passer les requêtes de plage.

Si l'une de ces conditions s'applique, le navigateur devra télécharger le fichier entier même s'il a été linéarisé, et le bénéfice disparaît.

Ce que la linéarisation ne change pas

Il faut clarifier ce point, car une confusion est répandue :

La taille du fichier. La linéarisation ne supprime aucun contenu et ne réencode aucune image. Comme des tables d'indices sont ajoutées, le fichier grossit typiquement de 1 à 2 %. Si vous voulez le réduire, il faut une compression.

La qualité des images. Aucun pixel ne change.

Le texte, les polices, la mise en page. Rien de tout cela n'est affecté.

La vitesse d'ouverture en local. Si le fichier est déjà sur le disque, l'ordre des objets n'a aucune importance ; un fichier linéarisé ne s'ouvre pas plus vite en local.

Les moments où la linéarisation se perd

Un fichier linéarisé peut perdre cette propriété lorsqu'on le manipule :

Toute opération effectuant une mise à jour incrémentale la détruit. Ajouter une annotation, remplir un champ de formulaire, apposer une signature numérique — la plupart de ces opérations ajoutent les modifications à la fin du fichier. Le fichier reste valide, mais la visionneuse doit désormais regarder la fin pour connaître l'état courant ; la promesse de la linéarisation devient caduque.

Les opérations qui réécrivent intégralement le fichier la détruisent également : compression, ajout ou suppression de pages, fusion, découpage. Elles produisent le fichier depuis zéro et l'ordre linéarisé particulier n'est pas conservé.

Conséquence pratique : la linéarisation doit être la dernière étape du flux de travail. Compressez, modifiez, signez, faites ce que vous avez à faire — puis linéarisez en tout dernier et publiez.

Comment le vérifier

La façon la plus simple de savoir si un fichier est linéarisé est de regarder ses premiers octets. Dans un PDF linéarisé, le premier objet ressemble à ceci :

1 0 obj
<< /Linearized 1 /L 1247893 /O 6 /E 45231 /N 120 /T 1247100 >>
endobj

La clé /Linearized 1 en est la preuve directe. /N donne le nombre total de pages, /L la longueur du fichier, /O le numéro de l'objet de la première page.

Pour tester en conditions réelles, mettez le fichier en ligne et ouvrez-le en simulant une connexion lente dans les outils de développement du navigateur. Sur un fichier linéarisé, la première page apparaît avant la fin du téléchargement.

En résumé

Pour rendre possibles les mises à jour incrémentales, le PDF place sa table de références croisées à la fin du fichier ; sur le réseau, cela revient à attendre le fichier entier. La linéarisation inverse cet ordre : tout ce qui concerne la première page passe en tête, suivi de tables d'indices qui indiquent où se trouve chaque page. La première page s'affiche ainsi immédiatement et il devient possible de sauter directement à la page voulue — à condition que le serveur prenne en charge les requêtes byte-range. L'opération ne réduit pas la taille du fichier, ne change pas la qualité et n'accélère pas l'ouverture en local. Elle n'a de sens que pour les gros fichiers publiés sur le web et, comme toute autre manipulation du fichier la détruit, elle doit être appliquée en toute dernière étape.