Pourquoi le texte copié depuis un PDF ressort en charabia

Un PDF dessine des glyphes, pas des caractères

Le flux de contenu d’une page ne contient pas votre texte. Il contient des nombres.

Chaque nombre est un code. La ressource de police attachée à la page fait correspondre ce code à un contour — une forme à dessiner. C’est la seule table qu’un PDF est tenu d’avoir, parce que c’est la seule nécessaire pour poser des marques sur une page, et c’est pourquoi le document a l’air parfait.

La copie a besoin de la table qui va dans l’autre sens : ce code signifie le caractère U+0041, un A majuscule. ISO 32000-1 prévoit exactement cela, sous la forme d’une CMap ToUnicode attachée à la police. Elle est facultative. Un producteur qui ne se souciait que de l’impression correcte du document n’avait aucune raison d’en écrire une, et rien dans le fichier ne se plaint de son absence.

Le sous-ensemble aggrave la défaillance. Quand un producteur n’intègre que les glyphes qu’un document utilise réellement, il est libre de les numéroter comme il veut — couramment 1, 2, 3 dans l’ordre où les caractères ont été rencontrés la première fois. Sans table ToUnicode, ces nombres ne signifient absolument rien ; avec une table, ils signifient ce qu’elle dit. Pourquoi un PDF s’affiche différemment sur un autre ordinateur traite du sous-ensemble et des autres surprises qu’il provoque.

La conséquence à bien assimiler : c’est une propriété du fichier, pas de votre ordinateur. Changer de lecteur, de système d’exploitation, de réglages de police ou de destination de collage n’aidera pas, parce que tous consultent la même table manquante. C’est aussi pourquoi la recherche à l’intérieur du document ne trouve rien — le lecteur compare ce que vous avez saisi avec cette même table cassée.

Lequel de ces cas est le vôtre

Le symptôme identifie la cause assez fiablement, et la cause décide si quelque chose peut être fait.

La première ligne est celle à écarter avant tout le reste, parce qu’elle est courante et qu’elle n’est pas le sujet de cet article. Si rien ne se surligne quand vous glissez le curseur sur la page, vous avez un scan, et il n’y a aucun texte à défigurer.

Ce PDF est-il scanné ou est-ce du texte ? explique comment distinguer les deux en quelques secondes.

Les espaces et l’ordre sont un autre problème

Ces deux-là produisent un désastre d’apparence lisible plutôt que du non-sens, et ils ont une cause différente de celle de la table manquante.

Il n’y a peut-être aucun espace dans le fichier

Rien n’oblige un PDF à contenir des caractères d’espace. Une ligne de texte est typiquement dessinée comme une série de chaînes séparées par des décalages numériques, et c’est le décalage qui fait l’écart entre deux mots. Savoir si cet écart est un espace est un jugement que l’extracteur porte d’après la largeur : trop généreux et les mots se collent, trop empressé et les mots se coupent en deux. C’est une heuristique, et c’est pourquoi deux outils divergent sur le même fichier sans qu’aucun ait tort.

L’ordre est l’ordre dans lequel cela a été dessiné

Le flux de contenu est dans l’ordre où l’application productrice a émis les marques. Un moteur de mise en page qui parcourt des cadres de texte peut alterner entre deux colonnes ; un modèle peut placer le pied de page avant le corps ; un tableau peut être dessiné cellule par cellule en descendant les colonnes plutôt qu’en parcourant les lignes. Rien, dans un PDF ordinaire, n’enregistre que ces marques formaient une colonne, une note de bas de page ou un tableau — les colonnes existent dans votre lecture de la page, pas dans le fichier.

Les extracteurs compensent en triant les marques par position, ce qui traite bien les pages simples à deux colonnes et mal les mises en page compliquées. Un PDF balisé est l’exception : il porte un arbre de structure énonçant le véritable ordre de lecture, et un extracteur qui en tient compte obtient la bonne réponse sans deviner. C’est l’un des vrais bénéfices pratiques du balisage, bien au-delà de l’exigence d’accessibilité pour laquelle il existe généralement — voir ce qui rend un PDF accessible.

Ce qui aide réellement, dans l’ordre

1. Essayez un autre extracteur avant toute chose. PDF en texte fonctionne dans votre navigateur avec PDF.js et respecte les tables ToUnicode là où elles existent. S’il renvoie un texte correct, le fichier n’a jamais été le problème et c’est le comportement de copie de votre lecteur qui l’était — une découverte de deux minutes qui vaut d’être faite avant une découverte de deux heures.
2. Si la table est cassée, aucun outil travaillant sur la couche de texte n’aidera. Tous les extracteurs lisent la même table. Convertir en Word, en tableur ou en texte brut la consulte pareillement : tous produisent donc le même non-sens dans des emballages différents. C’est le moment d’arrêter d’essayer des outils.
3. Ignorez la couche de texte et lisez la page comme une image. C’est l’OCR : rendre la page, reconnaître les formes, écrire une nouvelle couche de texte. C’est la seule issue fiable à une table cassée, et elle a deux coûts — la reconnaissance commet ses propres erreurs, et l’outil fonctionne sur un serveur, donc le document est téléversé. Pour un fichier confidentiel, c’est une décision plutôt qu’un clic.
4. S’il s’agit des espaces ou de l’ordre, extrayez puis nettoyez. Une passe de rechercher-remplacer sur le texte extrait corrige généralement les ligatures et les mots collés plus vite que n’importe quel outil. Pour un document sur lequel vous devez continuer à travailler, PDF en Word vous donne quelque chose de modifiable à réparer — côté serveur également, et ce qu’il peut et ne peut pas récupérer vaut d’être lu d’abord.
5. Si c’est vous qui produisez le fichier, corrigez à la source. Exportez plutôt que d’imprimer en PDF, intégrez les polices, et balisez le document. Un fichier exporté depuis un traitement de texte actuel se copie presque toujours correctement, et ceux qui ne le font pas sont généralement ceux qui sont passés par un pilote d’impression en chemin.

Et la solution sans gloire : pour une page ou deux, la ressaisie est souvent plus rapide que tout ce qui précède. Cela vaut la peine d’être dit à voix haute, parce que les gens passent une heure sur un travail de cinq minutes par le sentiment que l’ordinateur devrait bien pouvoir le faire.

Ce qu’aucun outil ne peut faire

• Il ne peut pas reconstruire une table qui n’a jamais été écrite. L’information n’est pas cachée ni chiffrée, elle est absente. Tout ce qui prétend réparer une table ToUnicode cassée déduit les caractères de la forme des glyphes, ce qui est de la reconnaissance optique de caractères sous une autre étiquette.
• L’OCR vous donne une nouvelle meilleure supposition, pas l’original. Ses erreurs se concentrent exactement sur ce que vous pouvez le moins vous permettre de rater — les chiffres, les numéros de référence, les noms de famille, tout ce que vous ne pouvez pas vérifier en lisant pour le sens. Relisez tout ce sur quoi vous allez agir.
• Une extraction correcte n’est toujours pas le document. Les tableaux reviennent sous forme de lignes, les notes de bas de page reviennent au milieu, les légendes reviennent détachées de leurs figures. Obtenir chaque caractère correctement ne dit rien de la structure, et aucune exactitude au niveau du caractère ne le dira jamais.
• Les écritures de droite à gauche et les écritures complexes ont une seconde défaillance par-dessus celle-ci. Certains producteurs écrivent l’arabe ou l’hébreu dans l’ordre visuel, en utilisant des formes de présentation plutôt que les lettres sous-jacentes. Une table de caractères correcte donne alors un texte techniquement juste qui se lit à l’envers, et le remettre dans l’ordre logique est un travail en soi.

La bonne habitude est de tester avant de s’engager : prenez une page, extrayez-la, et lisez ce qui en sort. Deux minutes au départ décident si ce document est un travail de copier-coller ou un travail de ressaisie, et c’est la seule décision qui compte vraiment ici.