Pourquoi le texte copié depuis un PDF se colle-t-il en charabia ?

Il manque au fichier une CMap ToUnicode — la table qui dit quel caractère Unicode représente chaque glyphe. La page s'affiche parfaitement parce que l'affichage n'a besoin que des formes des glyphes, mais rien dans le fichier ne déclare ce que ces formes signifient, si bien que copier renvoie les codes bruts.

L'extraction de texte peut-elle être parfaite ?

Pour les caractères, oui — un fichier doté de CMap correctes s'extrait exactement. Pour la mise en page, non. La structure de ligne, de paragraphe, de colonne et de tableau est entièrement déduite des coordonnées, et déduire sur une mise en page ambiguë se trompe parfois. Une page au texte correct dans le mauvais ordre, c'est l'échec normal.

Extraire du texte, est-ce la même chose que l'OCR ?

Non, et se tromper d'outil fait perdre du temps. L'extraction lit des instructions que le fichier contient déjà ; elle est exacte et instantanée. L'OCR regarde des pixels et reconnaît des formes, ce qui est plus lent et approximatif. Essayez d'abord l'extraction ; s'il ne sort rien, la page est une image et l'OCR est la seule option.

Pourquoi certains PDF me laissent sélectionner du texte et d'autres non ?

Du texte sélectionnable veut dire qu'une couche de texte existe. Si vous obtenez à la place un rectangle sur toute la page, la page est une image. Un scan, une photographie ou un export qui a converti les caractères en tracés vectoriels se comportent tous ainsi.

comment fonctionne l'extraction de texte d'un pdf

Comment fonctionne l'extraction de texte d'un PDF

Il n'y a pas de mots dans un PDF. Il y a des glyphes numérotés à des coordonnées. Tout ce qu'un extracteur vous rend est une reconstruction raisonnée, et c'est pourquoi elle est parfois troublante de justesse et parfois incompréhensible.

Étape un : trouver les instructions de dessin

L'extracteur décompresse le flux de contenu de chaque page et le parcourt à la recherche des opérateurs de texte. Le texte vit entre `BT` et `ET` — begin text, end text — et dans ce bloc une poignée d'opérateurs fait tout le travail. `Tf` choisit une police et un corps. `Tm` et `Td` fixent la position. `Tj` et `TJ` dessinent une chaîne.

La matière première est donc une liste de ce genre : en (72, 720), dans la police F1 à 12 pt, dessine ces octets. Répétez quelques milliers de fois. C'est réellement tout ce que le fichier contient.

Étape deux : transformer des codes de glyphes en caractères — la partie difficile

Les octets à l'intérieur d'un `Tj` ne sont pas de l'Unicode. Ce sont des indices dans la table interne de glyphes d'une police. L'octet 0x44 signifie « dessine le glyphe 68 de cette police », et le glyphe 68 n'est la lettre D que si la police le dit.

Il y a deux façons de le savoir. Les polices simples portent un encodage — souvent un encodage standard comme WinAnsi, parfois un tableau Differences sur mesure qui remappe des cases individuelles. Les polices composites, c'est-à-dire la plupart des polices embarquées modernes, ont besoin d'une CMap `ToUnicode` : une table explicite dans le fichier associant chaque code de glyphe à un caractère Unicode.

Quand cette CMap est présente et correcte, l'extraction est exacte. Quand elle manque, l'extracteur devine — en général en se rabattant sur les noms de glyphes de la police et, à défaut, sur les codes bruts. C'est l'origine du texte extrait qui ressort en flot de consonnes accentuées ou en caractères chinois issus d'un document manifestement français. Rien n'est cassé ; le fichier n'a simplement jamais dit ce que ses glyphes signifiaient.

Les polices en sous-ensemble aggravent la chose. Pour gagner de la place, un rédacteur n'embarque que les glyphes utilisés et les renumérote, si bien que la correspondance est entièrement arbitraire et dépend entièrement de la CMap que le rédacteur a pris ou non la peine d'inclure.

CMap ToUnicode présente: Extraction exacte. Le fichier déclare ce que chaque glyphe signifie.
Encodage standard, pas de CMap: En général correct pour du texte latin simple. Les accents et les symboles commencent à déraper.
Police en sous-ensemble, pas de CMap: Mojibake. La numérotation des glyphes est arbitraire et rien dans le fichier ne la décode.
Texte converti en tracés: Pas de texte du tout — les lettres sont des formes vectorielles. Seul l'OCR peut le lire, exactement comme pour un scan.

Étape trois : inventer les espaces

Cela surprend. Un PDF n'est pas tenu de stocker des espaces. Deux mots sont fréquemment dessinés comme deux chaînes distinctes avec un saut de position entre elles, ou comme un seul tableau `TJ` avec un nombre négatif au milieu — `[(Bon) -20 (jour)] TJ` — où le nombre est un ajustement de crénage en millièmes de cadratin.

L'extracteur mesure donc. Il connaît par la police la chasse de chaque glyphe, il sait donc où un caractère *aurait dû* se terminer. Si le caractère suivant commence sensiblement plus à droite, il insère une espace. Si l'écart est faible, il n'en insère pas.

Le seuil est une heuristique, et c'est pourquoi le texte extrait arrive parfois sous la forme `c e c i e s t e s p a c é` ou, dans l'autre sens, sous la forme `motscollés`. Le texte justifié est le coupable habituel : étirer une ligne pour atteindre la marge élargit les vraies espaces jusqu'à ce que le crénage intérieur au mot commence à leur ressembler.

Étape quatre : reconstruire lignes, colonnes et ordre de lecture

L'extracteur a maintenant des caractères avec des coordonnées et aucune notion de ligne. Il regroupe par position verticale — les glyphes partageant une ligne de base, à une tolérance près, forment une ligne — puis trie chaque ligne de gauche à droite, puis trie les lignes de haut en bas.

Cela marche pour une seule colonne. Cela échoue lourdement sur deux, parce que l'ordre du flux de contenu est l'ordre de dessin, et que l'ordre par coordonnée en descendant la page traverse tout droit la gouttière. Ligne un de la colonne un, puis ligne un de la colonne deux, puis ligne deux de la colonne un. Le résultat, ce sont des mots lisibles dans un ordre illisible.

Les meilleurs extracteurs font d'abord une analyse de mise en page : ils trouvent les gouttières de blanc, découpent la page en blocs-colonnes et extraient chaque bloc en entier avant de passer au suivant. Les tableaux reçoivent le même traitement une dimension plus haut — les cellules sont regroupées en lignes et en colonnes par alignement, parce que rien dans le fichier ne dit « tableau ». Une bordure tracée, ce sont quatre traits dessinés sur la page, et cela ne signifie rien pour l'extracteur.

C'est aussi là que se fait la reconstruction des paragraphes, et là qu'il faut défaire la césure. Un mot coupé en fin de ligne, ce sont deux suites de glyphes et un trait d'union ; les rejoindre demande une règle sur le moment où un trait d'union final est une coupure de ligne et le moment où il fait partie d'un mot composé.

Les modes d'échec, et ce que chacun signifie

Parce que vous pouvez désormais remonter du symptôme à la cause :

Il ne sort rien du tout: Il n'y a pas de couche de texte. La page est une image, ou le texte a été converti en tracés. Passez l'OCR.
Caractères illisibles: Une CMap ToUnicode absente ou fausse. Les glyphes se sont bien dessinés ; rien ne les décode.
Texte dans le mauvais ordre: Mise en page multicolonne, ou un ordre de dessin qui ne coïncide pas avec l'ordre de lecture.
Espaces manquantes ou en trop: L'heuristique de l'écart. Fréquent dans le texte justifié et dans les titres très interlettrés.
« ﬁ » et « ﬂ » dans la sortie: Des ligatures. Deux lettres dessinées comme un seul glyphe, et la CMap l'a associé au caractère de ligature unique plutôt qu'à la paire.

Pourquoi c'est le même problème que PDF vers Word

Convertir vers Word, c'est l'extraction de texte plus une couche d'inférence supplémentaire. Ayant reconstruit caractères, espaces, lignes et colonnes, le convertisseur doit deviner la sémantique : cette suite est en 18 points et en gras et se tient seule au-dessus d'un paragraphe, c'est donc probablement un titre ; ces lignes commencent toutes au même retrait avec un glyphe de puce, c'est donc probablement une liste.

Chacune de ces décisions est une supposition tirée d'indices visuels, parce que le fichier consigne l'apparence et rien d'autre. C'est pourquoi la qualité de conversion varie tant selon la source. Un PDF exporté depuis Word, qui porte peut-être encore un balisage, se convertit bien. Un PDF produit par un moteur de composition ne porte aucune structure, et le convertisseur le lit exactement comme vous le liriez sur une feuille imprimée.