Comparaison pixel par pixel avec PDFLang

Un fournisseur envoie le fichier corrigé. Le travail est déjà au planning, la presse est réservée, et quelqu’un doit répondre à une question avant qu’elle tourne : est-ce bien le document qui a été validé, avec la correction dedans — ou est-ce autre chose ?

On répond à cette question à l’œil plus souvent qu’on ne voudrait l’admettre. Deux fenêtres côte à côte, ou deux épreuves sur une table lumineuse, et une personne qui fait défiler. C’est le moment le plus lent de la journée et le moins fiable.

Ce que coûte le mauvais fichier

À la seconde où un mauvais fichier part sur presse, tout ce qui suit est perdu. Le papier est consommé. L’encre est consommée. Les plaques ont été gravées pour ce fichier-là. Le temps de presse a été réservé et brûlé, celui des personnes qui la font tourner aussi. Si c’est allé jusqu’à la coupe, au pliage ou à la reliure, c’est perdu également. Si c’est parti, il y a le transport — deux fois, puisqu’il faut le faire revenir.

Puis tout le travail recommence, à plein tarif, alors que le budget a déjà été dépensé une fois.

Et le planning est la partie qui ne revient pas. Un catalogue qui rate la saison, une promotion qui arrive après la date imprimée dessus, un magazine qui sort avec une semaine de retard : réimprimer répare l’objet, pas le moment pour lequel il existait.

Une partie n’est même pas une question d’argent. Une notice de médicament avec la mauvaise mention, une annonce légale avec le mauvais chiffre, un document financier portant le chiffre du trimestre précédent — ce ne sont pas des erreurs chères, ce sont celles qui finissent en rappel ou devant un régulateur.

En face, la vérification coûte quelques secondes.

Pourquoi l’œil est le mauvais instrument

L’attention humaine est excellente pour repérer une grande différence et très mauvaise pour en repérer une petite et constante. Mettez deux pages presque identiques devant quelqu’un : il trouvera le paragraphe réécrit. Il ne trouvera pas le logo qui a bougé de deux millimètres.

Et cela empire avec le volume. Personne ne regarde la page 180 comme il a regardé la page 3. La concentration qui attrape les choses se dépense au début, et le dernier tiers d’un document long reçoit un coup d’œil, pas une vérification.

De plus, le résultat ne se reproduit pas. Deux personnes comparant la même paire de fichiers signaleront des choses différentes. La même personne un autre après-midi en signalera encore d’autres. Et quand cela compte plus tard — quand on demande qui a validé et sur quelle base — il n’y a rien à montrer.

Ce qu’une machine entend par « identique »

pdfl pixelcompare rend les deux fichiers et compare ce à quoi ils ressemblent, page par page :

pdfl pixelcompare valide.pdf retirage.pdf

Il signale un constat par page modifiée, avec la part de la page concernée et le nombre d’endroits distincts où cela se produit :

page 7: 0.51% of the pixels differ, in 29 area(s)

C’est une autre question que celle à laquelle répond pdfl compare. Cette commande-là regarde le texte et la structure. Celle-ci regarde l’apparence, et les deux divergent plus souvent qu’on ne l’imagine.

Un logo déplacé de deux millimètres. Un filet maigre qui a disparu. Un ton direct remplacé par sa composition en CMJN. Dans les trois cas le texte est identique, donc une comparaison de texte dit que les fichiers correspondent. Ils ne correspondent pas sur le papier, et c’est là que ça compte.

Une page présente dans un fichier et absente de l’autre fait l’objet d’un constat à part, puisqu’il n’y a rien à quoi la comparer.

Le pixel ou deux qui ne sont pas un changement

Un fichier réexporté depuis la même source retombe souvent à un ou deux pixels près. Si cela était traité comme une différence, chaque lettre de la page serait « différente » et la seule chose qui a réellement changé serait enfouie dans le bruit.

La comparaison cherche donc un décalage unique sur toute la page, et le signale quand elle en trouve un :

page 3: 2.10% of the pixels differ, in 44 area(s) (aligned by 2, -1 px)

Quand c’est la position elle-même que vous vérifiez — un élément qui doit se trouver à un endroit précis — --no-align désactive cela.

Un endroit pour regarder vraiment

Un pourcentage vous dit qu’une page a changé. Il ne vous dit pas si le changement est acceptable. Pour cela, quelqu’un doit voir :

pdfl pixelcompare valide.pdf retirage.pdf --viewer diff/

Cela écrit un dossier avec les pages, les différences et un index.html. Pas de serveur, pas d’internet, rien à installer. Ouvrez le fichier, ou zippez le dossier et envoyez-le à qui doit signer le retirage.

Il affiche trois volets côte à côte, toujours sur la même page : l’original, le nouveau fichier, et les deux ensemble avec les différences peintes par-dessus.

Une même paire de barres, une verticale et une horizontale, traverse les trois au même endroit. Elles suivent le pointeur — il n’y a rien à saisir ni rien à viser. Dans le volet des différences, les barres découpent : le nouveau fichier apparaît à droite de la verticale et sous l’horizontale, l’original partout ailleurs. Dans les deux autres volets, ces mêmes barres sont des règles, qui marquent la même colonne et la même ligne de la page — ce que la découpe dévoile se retrouve donc sur l’un ou l’autre original sans mesurer à l’œil.

Les différences sont peintes par-dessus la page, et la couleur dit de quel type :

Couleur	Signification
Rouge	Encre disparue du nouveau fichier
Vert	Encre nouvelle dans celui-ci
Bleu	Même densité, couleur différente

La molette zoome les trois volets ensemble, jusqu’à 8×, autour du point sous le pointeur — ce que vous regardiez reste donc où il était. En maintenant l’un ou l’autre bouton de la souris, on fait glisser la page, là encore dans les trois à la fois : c’est ainsi qu’on atteint un coin une fois agrandi. Reset view remet le zoom, le déplacement et les barres au départ.

Et la partie qui fait gagner le plus de temps : il s’ouvre sur les pages qui diffèrent. Sur un document de deux cents pages dont trois ont bougé, ces trois sont la raison pour laquelle vous l’avez ouvert, et All rétablit le reste. Les flèches suivent le filtre : elles enjambent ce qui est masqué au lieu de s’y arrêter.

En faire un verrou, pas un avis

Le code de sortie porte le verdict, ce qui permet de placer ceci devant la presse plutôt qu’à côté : 0 si aucune page n’a changé plus que ce que vous avez autorisé, 2 si l’une l’a fait, 10 si un fichier n’a pas pu être lu.

pdfl pixelcompare valide.pdf retirage.pdf --max-diff 0.1 --viewer diff/ || {
  echo "le retirage ne correspond pas — voir diff/index.html"
  exit 1
}

--max-diff est la tolérance : quelle part d’une page peut changer avant de compter. --dpi décide de la finesse du regard — plus haut voit davantage et prend plus de temps. --threshold et --blur absorbent le petit bruit que produit le rendu.

La vérification tourne en quelques secondes, donne la même réponse à chaque fois, et laisse derrière elle un rapport et une visionneuse comme trace de ce qui a été comparé.

Où regarder ensuite

Le chapitre du CLI documente chaque option de pixelcompare, ainsi que compare pour la question du texte et de la structure. Les recettes placent les deux dans des flux complets — un imprimeur confrontant le fichier de presse à l’épreuve validée, un éditeur confrontant un retirage à l’édition déjà en rayon.