Comment les PDF stockent texte et images (sous le capot)

Chaque fichier PDF a la même disposition en quatre parties :

1. En-tête — une ligne, p. ex. %PDF-1.7, déclarant la version.
2. Corps — une séquence d'objets indirects numérotés. C'est là que tout vit : pages, polices, images, métadonnées.
3. Table de références croisées (xref) — décalages d'octets de chaque objet, pour qu'un lecteur puisse les trouver sans scanner tout le fichier.
4. Trailer — pointe vers l'objet racine (le catalogue du document), l'emplacement du xref et des infos de chiffrement optionnelles. Le lecteur lit le trailer en premier, puis saute à la racine.

La conception trailer-d'abord est pourquoi un PDF peut être lu en temps constant sans charger tout le fichier — important pour les documents volumineux et les lecteurs en flux.

Chaque objet dans le corps est numéroté et ressemble à ceci :

3 0 obj
<< /Type /Page /MediaBox [0 0 612 792] /Contents 4 0 R /Resources << /Font << /F1 5 0 R >> >> >>
endobj

Le 3 0 obj dit « ceci est l'objet 3, génération 0 ». Le corps dans << ... >>est un dictionnaire — une liste de paires clé/valeur. Les valeurs peuvent être des nombres, des chaînes, des noms (préfixés par /), des tableaux, d'autres dictionnaires ou des références comme 4 0 R(« va regarder l'objet 4 »). C'est ainsi qu'une page pointe vers son flux de contenu et ses polices sans les intégrer.

Le numéro de génération est généralement 0. Il s'incrémente quand une mise à jour incrémentale supprime et réécrit un objet — une fonctionnalité qui permet d'éditer des PDF en ajoutant des modifications à la fin du fichier sans tout réécrire. La plupart des writers modernes réécrivent tout le fichier, donc les générations restent à 0.

Le contenu d'une page vit dans un flux de contenu — un objet dont la valeur est un flux d'octets (souvent compressé par Flate) contenant des opérateurs de dessin PDF. Le texte est dessiné avec des opérateurs comme BT (begin text),Tf (set font et size), Td (move position), Tj (show text) et ET(end text). Un simple « Hello » ressemble à peu près à :

BT
/F1 24 Tf
100 700 Td
(Hello) Tj
ET

La chaîne (Hello) utilise l'encodage de la police. Pour du texte latin simple, c'est souvent WinAnsiEncoding ou l'encodage intégré de la police. Pour du texte Unicode, la chaîne est une chaîne d'octets encodée en 16 bits et la police a un mappage/ToUnicode qui permet aux lecteurs de récupérer les code points réels pour le copier-coller et la recherche. Si un PDF a un copier-coller corrompu mais un texte visible, le mappage /ToUnicode est manquant ou erroné — un bug d'exportation courant.

Le texte n'est pas stocké comme HTML ou paragraphes. Il n'y a pas d'objet sémantique « paragraphe ». Les lignes, les sauts de ligne et le positionnement sont tous des commandes de dessin explicites. C'est pourquoi reflow un PDF à une largeur de page différente est difficile : le lecteur devrait faire l'ingénierie inverse de la mise en page à partir des commandes de dessin.

Un objet police en PDF a deux parties : undictionnaire de police qui nomme la police et pointe vers ses données, et le programme de policelui-même (Type 1, TrueType ou OpenType) intégré comme flux. La spécification PDF exige que les polices soient intégrées pour que le document rende identiquement partout — mais ne l'applique pas, c'est pourquoi certains PDF substituent des polices sur des machines qui ne les ont pas.

Le subsetting intègre uniquement les glyphes réellement utilisés dans le document. Une police de 250 Ko utilisée pour un seul titre devient un subset de 8 Ko. La plupart des exportateurs modernes font du subsetting par défaut. Les exportateurs anciens ou certains chemins « Print to PDF » intègrent parfois la police complète, ce qui est une cause courante de fichiers gonflés. Voir notre guide de taille de fichier pour le détail complet.

Les images sont stockées comme XObjects(objets externes) — des flux de données de pixels raw ou compressées avec un dictionnaire décrivant largeur, hauteur, espace de couleur, bits par composant et filtre. Le flux de contenu de la page dessine ensuite l'image avec l'opérateur Do.

PDF supporte plusieurs filtres d'image (compression) :

• DCTDecode — JPEG. Avec pertes, bon pour les photos. La source la plus courante de taille dans les PDFs riches en images.
• FlateDecode — zlib/deflate. Sans pertes, bon pour les dessins au trait et les images avec peu de couleurs.
• JPXDecode — JPEG2000. Meilleure compression que JPEG à haute qualité, mais plus lent et moins universellement supporté.
• JBIG2Decode — pour le texte numérisé bitonal (1-bit). Peut réduire drastiquement les pages numérisées.
• CCITTFaxDecode — compression de fax classique pour les images bitonales.

Un PDF riche en images est surtout une séquence de flux d'images compressées. Ré-encoder ces flux avec une qualité JPEG plus agressive est le levier unique le plus important de taille pour les documents numérisés.

La table xref liste le décalage d'octets de chaque objet indirect. Un lecteur ouvre le fichier, lit le trailer (qui est à un décalage connu depuis la fin du fichier), trouve le xref et l'utilise pour sauter directement à n'importe quel objet sans analyser tout le fichier. C'est ce qui rend PDF à accès direct.

PDF 1.5 a ajouté les flux de références croisées, qui compressent la table xref elle-même. Combiné avec les flux d'objets (de nombreux petits objets empaquetés dans un flux compressé), c'est la compression structurelle qui rend les PDFs modernes plus petits que leurs équivalents 1.4. Voir notreexplainer de compression pour ce que cela fait en pratique.

Le trailer pointe aussi vers/Root (le catalogue du document, qui liste l'arbre des pages), le dictionnaire /Info(Title, Author, CreationDate — les métadonnées) et optionnellement le dictionnaire /Encrypt si le fichier est chiffré.

Tout objet dont la valeur est une donnée binaire (un flux de contenu, une image, une police intégrée) est unflux : un dictionnaire suivi destream, des octets raw etendstream. L'entrée /Filter du dictionnaire indique au lecteur comment décoder les octets — FlateDecode pour zlib, DCTDecodepour JPEG, etc. Plusieurs filtres peuvent être chaînés, p. ex. une image qui est décodée puis sous-échantillonnée.

C'est pourquoi « compresser un PDF » n'est pas une opération. Chaque flux est compressé indépendamment avec son propre filtre. Un outil de compression qui ré-enregistre avec des flux d'objets réduit le overhead structurel ; ré-encoder les images avec une qualité JPEG plus agressive réduit les flux d'images. Ce sont des leviers indépendants.

Quand un outil comme IXPDF fusionne, divise ou fait pivoter un PDF, il analyse le xref, parcourt l'arbre des pages, copie ou réarrange les objets de page et réécrit le xref et le trailer. Les flux de contenu (texte et images) sont copiés octet par octet — pas de ré-encodage, pas de perte de qualité. C'est pourquoi les opérations structurelles sont rapides et sans perte : elles rearrangent les références d'objets, elles ne re-renderent pas la page.

La compression est l'exception : elle re-sérialise la structure avec des flux d'objets. Même alors, les flux d'images et de polices sont copiés tels quels sauf si l'utilisateur demande explicitement de les ré-encoder.

Tout cela se passe dans votre navigateur via un Web Worker — le fichier est analysé, modifié et re-sérialisé localement. Votre PDF ne quitte jamais votre appareil.