Pourquoi certains PDF ne s’allègent pas

La réponse courte

Tout outil de compression a la même limite : il ne peut retirer que la redondance encore présente. Quand un PDF refuse de s’alléger, ce n’est presque jamais que l’outil a échoué. C’est que le fichier n’a plus de marge, ou que son poids réside dans une partie du document que la compression d’images n’atteint pas.

Quatre causes sont fréquentes, et elles appellent des réponses différentes. Le fichier est déjà proche de son plancher. Son poids vient des polices intégrées. Son poids vient des illustrations vectorielles. Ou bien ses images sont dans des formats impossibles à décoder et à ré-encoder dans un navigateur. Commencez par déterminer laquelle vous concerne — /pdf-page-count indique le nombre de pages, les formats de page et la présence d’une couche de texte, ce qui suffit généralement à trancher.

Le fichier est déjà construit efficacement

C’est le cas le plus fréquent et le moins satisfaisant. Un PDF exporté une seule fois depuis une application moderne est généralement déjà proche de la plus petite taille possible, parce que la compression générique a déjà été appliquée.

Les flux de contenu des pages — les instructions décrivant où va le texte, quelles polices utiliser, comment tracer les traits — sont stockés avec le filtre Flate, l’algorithme DEFLATE de la RFC 1951, le même que dans le ZIP et le PNG. L’exportateur l’a appliqué au moment d’écrire le fichier. Repasser DEFLATE sur des données déjà DEFLATE ne récupère rien ; une sortie compressée ressemble à du bruit pour un compresseur, et c’est précisément pour cela qu’elle est compressée.

Un document texte de 40 pages sans images n’a donc pas de marge notable. L’optimisation structurelle — regrouper les objets dans des flux d’objets, supprimer les objets orphelins laissés par des modifications antérieures, retirer les métadonnées — rapporte quelques pour cent, et parfois à peine cela. Ce n’est pas la limite d’un outil particulier ; c’est ce qu’est le fichier.

Une exception mérite d’être connue. Un PDF ouvert, modifié et réenregistré de nombreuses fois par plusieurs applications peut transporter beaucoup de résidus non référencés issus de ses versions antérieures, et le réécrire proprement rapporte alors bien davantage. Si un fichier paraît invraisemblablement lourd au regard de son contenu et qu’il a un long historique d’édition, c’est l’explication la plus probable.

Les polices intégrées

Un PDF est censé avoir le même aspect partout. Cette promesse est tenue en plaçant les polices à l’intérieur du fichier, pour que le document ne dépende pas de ce qui est installé sur la machine du lecteur. C’est l’une des raisons d’être du format, et cela coûte des octets.

Combien, cela dépend de la police. Un sous-ensemble — seulement les glyphes réellement utilisés par le document — d’une police de labeur latine pèse typiquement quelques dizaines de kilooctets et ne mérite pas qu’on s’en inquiète. Une police complète, non réduite en sous-ensemble, pèse davantage. Une police CJC, couvrant le chinois, le japonais ou le coréen, peut à elle seule atteindre plusieurs mégaoctets, car elle contient plusieurs milliers de glyphes. Intégrez-en deux graisses et vous obtenez un PDF de plusieurs mégaoctets pour une page de texte.

Un sous-ensemblage médiocre est une inefficacité réelle et corrigible, mais la correction consiste à réexporter depuis le document source en activant le sous-ensemblage — une affaire pour l’application qui a produit le PDF, pas pour un compresseur.

Ce qu’il ne faut pas faire, c’est retirer les polices. Un PDF dont les polices ont été supprimées s’affiche avec des substituts sur toute machine dépourvue des originales : les métriques se décalent, les coupures de ligne se déplacent, la mise en page dérive, et des caractères peuvent manquer totalement. Le document cesse silencieusement d’être le document. iBuildPDF ne retire pas les polices intégrées, dans aucun mode, exactement pour cette raison.

Les illustrations vectorielles denses

Une carte, un export de CAO, un plan d’étage, un graphique comportant des dizaines de milliers de points tracés : cela ressemble à des images, et n’en est pas. Ce sont des dessins vectoriels : le flux de contenu de la page contient une opération de dessin distincte pour chaque trait, courbe, aplat et chemin de détourage de l’illustration. Une carte détaillée peut représenter des centaines de milliers d’opérations. C’est cela, le fichier.

Il n’y a aucun levier de qualité d’image à actionner, puisqu’il n’y a pas d’image. Rien à sous-échantillonner, rien à ré-encoder, aucun réglage de qualité JPEG applicable. Passez une compression d’images sur un tel fichier et elle signalera à juste titre n’avoir rien trouvé sur quoi travailler, et le résultat aura la même taille que l’entrée. Ce n’est pas un échec ; c’est le résultat honnête. Le flux de contenu est, comme toujours, déjà compressé en Flate : le levier générique a donc lui aussi déjà été actionné.

Les vraies options consistent à simplifier l’illustration dans l’application qui l’a produite — moins de chemins, moins de détails cachés, calques inutiles supprimés — ou à renoncer aux vecteurs et à rastériser, ce qui est traité plus bas. La consolation, c’est que les fichiers vectoriels sont indépendants de la résolution : une carte de 500 Ko s’imprime parfaitement à n’importe quelle taille, ce que ne fait pas une photographie de carte de 500 Ko.

Les formats d’image qui ne peuvent pas être recompressés

Il arrive que le fichier soit bel et bien fait d’images et qu’elles restent pourtant intouchables, parce que le navigateur ne sait pas les décoder. Recompresser suppose de décoder d’abord les pixels d’origine, or un outil qui s’exécute dans le navigateur ne dispose que des décodeurs fournis avec celui-ci.

• JPEG 2000 (JPXDecode). Un successeur du JPEG fondé sur les ondelettes, utilisé dans certaines chaînes d’archivage, médicales ou de numérisation professionnelle. Les navigateurs ne le prennent pas en charge de façon fiable — il n’existe pas de décodeur JPX natif sur lequel compter, donc aucun moyen sûr d’accéder aux pixels.
• JBIG2. Un format pour les images scannées bitonales (noir et blanc pur). Il reconnaît les formes répétées — la même lettre apparaissant mille fois sur une page — et ne stocke chaque forme qu’une fois. Il est extrêmement efficace sur du texte scanné, et un JPEG ne saurait faire mieux.
• Fax CCITT Groupe 3 et Groupe 4. Les encodages bitonaux classiques du fax, toujours produits par les scanners de documents et les imprimantes multifonctions. Chaque pixel tient sur un bit : le résultat est donc typiquement déjà plus léger que n’importe quel JPEG que nous pourrions produire à partir de la même page ; convertir un scan bitonal net en JPEG le rendrait à la fois plus lourd et moins bon, avec un halo gris autour de chaque lettre.

D’autres éléments sont ignorés délibérément : les masques au pochoir et tout ce qui sert de /SMask ou de /Mask, les images de moins de 100×100 pixels environ, les échantillons bruts autres que 8 bits par composante, les espaces colorimétriques impossibles à convertir de façon fiable comme Separation, DeviceN et Lab, ainsi que les JPEG CMJN sur un navigateur qui échoue à un test de décodage au démarrage.

Quand iBuildPDF ignore une image, il comptabilise et signale ce contournement plutôt que de ne rien faire en silence. Si votre fichier a à peine changé et que le résultat indique que la plupart de ses images ont été ignorées, voilà l’explication.

Ce qui aide réellement

Adaptez le remède à la cause.

• Fichier déjà construit efficacement. Acceptez-le, ou changez ce que vous envoyez — divisez le document, ou envoyez un lien plutôt qu’une pièce jointe. Aucun réglage n’y changera rien.
• Fichier réenregistré de nombreuses fois. Une réécriture propre supprime les objets orphelins accumulés ; réexporter depuis l’application source produit le même effet.
• Polices. Réexportez en activant le sous-ensemblage. Ne supprimez pas les polices.
• Vecteurs. Simplifiez le dessin à la source, ou rastérisez.
• Formats d’image ignorés. Du JBIG2 ou du CCITT signifie que le fichier est probablement déjà proche de son plancher ; laissez-le tel quel. Pour le JPEG 2000, réexporter depuis le logiciel de numérisation avec une sortie JPEG ordinaire donne généralement un fichier que l’on peut ensuite compresser normalement.

Pour un fichier très vectoriel, la rastérisation est le seul levier restant. Le mode Maximum de /compress-pdf rend chaque page et la remplace par un JPEG d’elle-même : la taille du résultat ne dépend alors que des dimensions des pages et de la qualité, et non de la complexité de l’illustration. Cela fonctionne. C’est aussi le seul mode destructeur, et la page le signale avant que vous ne le lanciez : le résultat n’a aucun texte sélectionnable, aucune recherche, aucun copier-coller, aucun lien ni champ de formulaire fonctionnel, rien pour un lecteur d’écran, et des illustrations vectorielles qui deviennent floues au zoom ou à l’impression en plus grand format. Comme iBuildPDF ne fait aucun OCR, rien ici ne pourra ensuite rétablir une couche de texte. Conservez l’original.

Pour le détail de ce que change chaque mode, voyez comment fonctionne la compression PDF.