Une passe de compression PDF sans perte réécrit la structure interne du fichier plutôt que de réencoder les images qu'il contient. Nous avons mesuré ce que cela économise réellement sur huit PDF de test. Trois d'entre eux sont ressortis plus gros dans au moins un mode, et la pire régression a été de 20,8 pour cent.
L'économie dépend de la façon dont l'entrée était relâchée. Les flux texte non compressés ont diminué de 84 à 90 pour cent, tandis qu'un fichier dont les flux étaient déjà compressés en Flate a diminué de 31,6 pour cent en mode standard et a grossi de 3,0 pour cent en mode maximum. Une seconde passe n'a rien changé sur aucun échantillon, et deux fichiers au même contenu mais de structure différente ont produit une sortie identique octet pour octet. Rien de tout cela ne signifie que le moteur est défectueux ; cela signifie qu'une affirmation sur la taille a besoin d'une mesure derrière elle. La méthode complète, le tableau et les limites du test figurent ci-dessous.
Chaque outil PDF a un bouton Compresser, et presque tous rapportent un succès. Ce mot recouvre au moins deux opérations très différentes, et l'une d'elles peut vous rendre un fichier plus gros. Nous voulions des chiffres plutôt qu'une promesse, alors nous avons construit huit PDF aux structures internes délibérément différentes et fait passer chacun dans qpdf 11.7.0 en utilisant les mêmes arguments que ceux passés par notre propre outil.
Compresser un PDF
La même passe qpdf décrite ici, compilée en WebAssembly et exécutée dans l'onglet. Choisissez le niveau, puis lisez vous-même les tailles avant et après.
Ce que fait réellement un bouton "compresser un PDF"
La première chose à savoir est qu'il ne s'agit généralement pas d'une recompression d'images. C'est une réécriture structurelle. Un PDF conserve ses pages comme une collection d'objets et de flux, et la passe les décompresse, supprime les doublons, compresse les flux qui étaient stockés bruts et écrit un nouveau fichier.
qpdf, le moteur à l'intérieur de notre outil, le fait avec cet appel en mode standard :
--object-streams=generate --compress-streams=y --recompress-flate --compression-level=6
et celui-ci en mode maximum, qui ajoute un niveau supérieur et une linéarisation pour un affichage web rapide :
--object-streams=generate --compress-streams=y --recompress-flate --compression-level=9 --linearize
Remarquez ce qui ne figure dans aucun des deux appels : quoi que ce soit qui touche les images intégrées. Une passe structurelle ne décode pas un JPEG déjà présent dans un PDF, donc elle ne peut pas réduire de façon significative un document numérisé ou riche en photos. Ce qu'elle peut faire, c'est supprimer l'inefficacité accumulée pendant la construction du fichier. C'est pourquoi l'économie dépend de l'entrée plutôt que de l'acharnement de l'outil.
Comment la mesure a été effectuée
Huit échantillons ont été générés pour isoler chacun une propriété structurelle : un fichier minimal d'une page, un fichier de trois pages, le même document de vingt pages avec des flux compressés et non compressés, un fichier de cent pages comportant de nombreux objets, un fichier d'une page complété par un commentaire inutile, un fichier avec un JPEG intégré, et un fichier avec un petit paquet XMP non compressé. Chaque fichier a ensuite été traité avec les arguments ci-dessus, deux fois dans le cas du mode standard, et le nombre d'octets et l'empreinte SHA-256 ont été enregistrés à chaque fois.
- Générez les échantillons par script, pas à la main. Cela rend chacun reproductible et évite que le test dépende des documents qui se trouvaient sous la main.
- Utilisez les vrais arguments de l'outil. Le moteur est appelé avec exactement les drapeaux que passe l'outil du navigateur, donc les chiffres décrivent le produit plutôt qu'une expérience d'apparence similaire.
- Enregistrez les octets et les empreintes, pas seulement un pourcentage. Une empreinte répond à une seconde question que la taille ne peut pas trancher : si deux entrées construites différemment aboutissent au même fichier.
- Exécutez tout une seconde fois. Répéter l'opération teste si elle converge, ce qui compte si une interface vous invite à appuyer une nouvelle fois sur le bouton.
Les chiffres
Le mode standard est le niveau 6 sans linéarisation. Le maximum est le niveau 9 avec linéarisation. Les pourcentages négatifs correspondent à des fichiers plus petits.
| Échantillon | Entrée (B) | Standard (B) | Modifier | Maximum (B) | Modifier |
|---|---|---|---|---|---|
| 01 minimal, 1 page | 3,392 | 872 | -74.3% | 1,637 | -51.7% |
| 02 minimal, 3 pages | 9,520 | 1,475 | -84.5% | 2,513 | -73.6% |
| 03 texte non compressé, 20 pages | 62,145 | 6,590 | -89.4% | 9,916 | -84.0% |
| 04 texte compressé, 20 pages | 9,629 | 6,590 | -31.6% | 9,916 | +3.0% |
| 05 nombreux objets, 100 pages | 311,281 | 30,964 | -90.1% | 45,110 | -85.5% |
| 06 structure relâchée, 1 page | 7,489 | 872 | -88.4% | 1,637 | -78.1% |
| 07 image JPEG intégrée | 67,974 | 68,124 | +0.2% | 68,863 | +1.3% |
| 08 XMP non compressé | 4,151 | 4,235 | +2.0% | 5,013 | +20.8% |
Quatre choses que disent les chiffres
Le gain vient du fait que l'entrée est relâchée, pas de l'intelligence de l'outil
Les fichiers dont les flux texte étaient stockés non compressés ont diminué de 84 à 90 pour cent. Un fichier dont les flux étaient déjà compressés en Flate a diminué de 31,6 pour cent en mode standard puis a grossi de 3,0 pour cent en mode maximum, car le niveau 9 plus la linéarisation ajoutaient une structure dont le fichier n'avait pas besoin. Plus d'effort n'équivaut pas à un fichier plus petit, et la limite est la structure de l'entrée, pas l'effort qui y est appliqué.
Trois des huit échantillons ont grossi
Le pire cas a été une augmentation de 20,8 pour cent sur un fichier portant un petit paquet XMP non compressé, poussé dans le mode maximum. L'échantillon avec un JPEG intégré a grossi dans les deux modes, car il n'y avait rien de structurel à gagner et la réécriture coûte elle-même des octets. C'est la part qu'un message de succès masque : un compresseur qui rapporte toujours un succès ne mesure rien, et sur ces entrées la sortie honnête est un fichier légèrement plus gros.
L'opération est idempotente sur sa propre sortie
Chaque échantillon a été exécuté une seconde fois par le chemin standard, et chaque changement à la seconde passe a été de 0,0 pour cent. Une fois qu'un fichier a été réécrit, le réécrire de nouveau ne trouve rien. Si un outil semble trouver sans cesse de nouvelles économies à chaque fois que vous appuyez sur le bouton, c'est une raison d'examiner ce qu'il fait réellement plutôt qu'un signe de rigueur.
La réécriture normalise, elle ne se contente pas d'élaguer
Les échantillons 01 et 06 sont le même document d'une page, sauf que 06 porte quatre kilooctets de commentaire inutile. Après la réécriture, ils produisent la même empreinte SHA-256. Les échantillons 03 et 04 sont le même document de vingt pages avec des flux compressés et non compressés, et ils convergent de la même manière. Le moteur reconstruit le fichier sous une forme canonique plutôt que de raboter ce qu'il trouve par hasard, ce qui explique aussi pourquoi une seconde passe n'a plus rien à faire.
Comment savoir si un compresseur a mesuré quoi que ce soit
Deux vérifications prennent environ une minute chacune et fonctionnent avec n'importe quel outil.
- Demandez le chiffre. Un message qui dit Compressé sans indiquer le nombre d'octets avant et après ne vous a rien appris. Les cas à surveiller sont les petits fichiers et les fichiers déjà bien faits, où la réponse honnête est souvent qu'ils ont grossi.
- Essayez un fichier déjà serré. Un export depuis une suite bureautique moderne est généralement déjà compressé. Si un outil prétend encore en tirer une économie importante, soit il réencode vos images, ce qui est une décision de qualité plutôt qu'une opération sans perte, soit il devine.
Les deux vérifications pointent vers la même idée. Un optimiseur structurel n'a pas de taille cible à viser, c'est pourquoi notre propre outil n'a aucun champ pour cela et pourquoi la description honnête de ce qu'il peut faire dépend du document qui lui est présenté.
Où ce test a des limites
Les chiffres ci-dessus sont réels et ils sont étroits. Être clair sur les lacunes est précisément l'intérêt de les publier.
- Les échantillons sont générés, pas collectés. Ils isolent délibérément des propriétés structurelles, donc ils ne constituent pas un échantillon aléatoire des PDF que les gens possèdent réellement.
- Huit, c'est un petit ensemble. Lisez les pourcentages comme la preuve qu'une plage existe, pas comme une moyenne pour tous les PDF.
- Les images sont représentées par un seul échantillon. Un seul JPEG intégré représente toute une catégorie de documents. L'imbrication plus profonde d'images, de polices et de champs de formulaire n'a pas été testée.
- Le moteur ne réencode jamais les images ici. C'est une propriété de la passe structurelle de qpdf, et non quelque chose que ce jeu de données prouve pour d'autres compresseurs.
- Les versions comptent. Ces résultats appartiennent à qpdf 11.7.0. Si une version ultérieure modifie son optimisation, les chiffres changent avec elle et la méthode doit être exécutée de nouveau.
Questions fréquentes
Si vous voulez une vue plus large de ce qu'un outil dans le navigateur peut ou ne peut pas faire avec un document, le guide sur compresser un PDF sans le téléverser couvre le moteur et le chemin du fichier, et la question des tailles cibles explique pourquoi un optimiseur sans perte n'a pas de champ pour cela.