Extraire le texte d'un PDF, et ce que la mise en page lui fait

Un PDF n'a pas de lignes — seulement des glyphes à des coordonnées

C'est le fait dont tout le reste découle, et presque aucun guide ne l'énonce clairement. Une page PDF est une liste d'instructions de dessin. L'une d'elles dit : place ce glyphe à ce point, dans cette police, à cette taille. Il n'existe dans le fichier aucun objet signifiant « paragraphe », aucun signifiant « ligne », et aucun n'enregistre quel bloc de texte doit être lu en premier. Le format est défini par l'ISO 32000, et l'ordre de lecture ne fait tout simplement pas partie de ce que porte une description de page ordinaire.

L'extraction est donc une reconstruction, et c'est là que tous les outils diffèrent. Celui-ci prend la suite de glyphes renvoyée par pdf.js, chacun avec sa position, et regroupe en une ligne ceux dont les lignes de base tombent à moins d'une demi-hauteur de glyphe l'une de l'autre. Dans une ligne, il trie de gauche à droite et insère une espace partout où l'écart horizontal dépasse un cinquième de la hauteur du glyphe — car un PDF qui espace les mots en déplaçant le curseur n'émet aucun caractère d'espace. Cette reconstruction est bonne. C'est aussi pourquoi les échecs ci-dessous ont la forme qu'ils ont : ce sont tous des cas où la géométrie de la page et la logique du document se contredisent.

Deux colonnes : la panne que tu rencontreras en premier

Une page à deux colonnes a été composée avec quatre lignes par colonne, puis extraite. Le résultat commence par : « Revenue for the quarter rose by four Costs grew more slowly, at two per cent, ». La première moitié est la ligne d'ouverture de la colonne de gauche ; la seconde, celle de la colonne de droite. Elles partagent une ligne de base : pour la reconstruction, elles ne font qu'une seule ligne, et sont jointes par une espace.

Passer à « Recoller en paragraphes » aggrave les choses au lieu de les arranger. Les lignes entrelacées sont désormais collées en un bloc unique où chaque phrase est coupée en deux par un fragment de l'autre colonne. Pire, la recollecte des mots coupés cesse de fonctionner : la colonne de gauche terminait une ligne par « sub- », mais quand la logique de paragraphe examine le tampon, le tiret n'est plus le dernier caractère — le texte de la colonne de droite s'est intercalé. La sortie donne « by the sub- reclassification of contractors into the scription business ». Le mot « subscription » a été déchiré en deux et les moitiés sont séparées par onze mots.

Aucun réglage ne corrige cela, car le corriger suppose de détecter les colonnes, et la détection de colonnes est un problème réellement difficile que l'outil ne tente pas. Le contournement pratique consiste à extraire page par page et à découper le résultat à la main, ou à accepter qu'un article académique sur deux colonnes ou une loi imprimée demandera une édition après extraction plutôt qu'avant.

Les tableaux gardent leurs rangées et perdent leurs colonnes

Un tableau à quatre colonnes s'est extrait proprement au niveau des rangées : « Region Revenue Cost Margin », puis « North 1,240 980 21% ». Chaque rangée est sur sa propre ligne et dans le bon ordre. Ce qui a disparu, c'est la frontière de colonne — les cellules sont séparées par une simple espace, exactement comme des mots : rien dans la sortie ne distingue une fin de cellule d'une fin de mot. Colle cela dans un tableur, tu obtiens une seule colonne.

Le problème le plus aigu est la cellule vide. Un tableau avec une « Note » vide sur une rangée et un « Fournisseur » vide sur une autre a produit « Chair Nordia 89.00 » et « Desk back-order 240.00 » — quatre colonnes qui arrivent en trois valeurs, deux fois, sans rien pour dire quelle colonne a été sautée. Un lecteur reconstruisant ce tableau à l'œil mettrait « back-order » dans la colonne Fournisseur. Rien dans le texte ne dit le contraire. Et une cellule dont le contenu passe à la ligne devient sa propre rangée : la note « discontinued, replacement pending » est ressortie en « Lamp Vela discontinued, 15.00 » suivie d'une ligne ne contenant que « replacement pending ».

En mode paragraphe, le tableau cesse tout simplement d'être un tableau. L'ensemble est revenu en une seule phrase : « Region Revenue Cost Margin North 1,240 980 21% South 870 910 -5% East 2,310 1,760 24% ». Si ton document contient un tableau auquel tu tiens, utilise « Garder les lignes » — et attends-toi à reconstruire les colonnes toi-même.

Tirets, ligatures et l'en-tête présent sur chaque page

La césure est gérée, avec une réserve. En mode paragraphe, une ligne se terminant par un tiret voit ce tiret supprimé et la ligne suivante collée directement, si bien que « con- » et « cluded » donnent « concluded », « re- » et « vised » donnent « revised ». Les deux ont été vérifiés sur une page à une colonne. Mais la règle est inconditionnelle : elle se déclenche sur tout tiret en fin de ligne, y compris celui qui appartient au mot. Sur une page de test, « long- » en fin de ligne plus « term » a produit « longterm », et « e- » plus « mail » a produit « email ». Ce ne sont pas des fautes dans la source : c'est la réparation qui se déclenche à tort.

Les ligatures sont la bonne nouvelle, et il vaut la peine de comprendre pourquoi : elles cassent la recherche dans les outils qui les traitent mal. Le fi d'un typographe est souvent un caractère unique dans la police, et une police sous-ensemble le ramène vers Unicode grâce à une table portée par le PDF. Extrais naïvement et tu obtiens U+FB01, identique à l'écran et introuvable quand tu cherches « file ». Le moteur sous cet outil normalise par défaut : le même fichier de test renvoie « confirmed » et « fluently » en lettres ordinaires. En relançant le fichier identique avec la normalisation désactivée, on récupère les caractères de ligature — c'est ainsi qu'on sait que c'est bien la normalisation qui fait le travail.

Les en-têtes et pieds de page courants sont extraits, sur chaque page, et rien ne les retire. Un décret consolidé espagnol de 44 pages a livré exactement 44 copies de « LEGISLACIÓN CONSOLIDADA » et 44 lignes de numéro, déposées au milieu du texte suivi. Dans le fichier extrait, une phrase s'interrompt en pleine proposition au bas de la page 5, est suivie d'un pied de page, d'un séparateur et de deux lignes d'en-tête, et reprend page 6. Ce n'est pas un défaut de la reconstruction — l'en-tête est bel et bien sur la page — mais cela signifie que tout document long exige une passe de rechercher-remplacer pour retirer le mobilier avant que le texte soit utilisable.

Un PDF scanné ne contient aucun texte, et l'OCR est une autre opération

C'est la déception la plus fréquente, et elle mérite une réponse franche. Quand une page est scannée ou photographiée, le PDF obtenu contient une image et rien d'autre. Pas de glyphes, pas de police, pas de codes de caractères — juste des pixels qui, pour toi, ressemblent à des lettres. L'extraction n'a rien à trouver, et choisir une autre mise en page n'y change rien.

L'outil le dit, ce que tous ne font pas. Alimenté avec une page ne contenant qu'une image, il a renvoyé la chaîne vide et affiché une phrase expliquant que le fichier ne contient aucun texte sélectionnable et qu'il s'agit très probablement d'un scan sans couche de texte. Il ne rend pas silencieusement une zone de texte vide, et il ne rend pas une zone contenant seulement des séparateurs de page — la vacuité est testée sur le corps des pages, pas sur la chaîne assemblée. Transformer un scan en texte demande une reconnaissance optique de caractères, qui lit les pixels et devine les lettres. Cet outil ne le fait pas, et rien en lui ne le fait discrètement en arrière-plan.

Deux façons pour une page de revenir vide, et ce qu'on t'en dit

D'abord : une plage désignant des pages que le fichier n'a pas. Saisis 99 sur un document de deux pages et l'analyseur de plage écarte le numéro hors limites, si bien qu'il ne reste rien à extraire. Ce n'est pas la même chose qu'une page sans texte, et cela ne reçoit plus la même réponse : le message indique combien de pages le document compte réellement et te demande de corriger la plage ou de la vider. Mesuré sur un fichier de deux pages où l'on demande la page 99 — « Aucune des pages demandées n'existe dans ce document : il en compte 2. » Une plage qui déborde la fin au lieu de commencer après elle est simplement rognée : demander 1-3 sur ce même fichier extrait les deux pages sans un mot.

Ensuite : un document mêlant des pages saisies et un feuillet scanné — une page signée, un fax, un certificat photographié et inséré. Cette page ne porte aucune couche de texte, elle revient donc vide alors que le reste du document s'extrait parfaitement. C'est le cas qui passait en silence, parce que la vacuité était testée sur le document entier et que les pages saisies suffisaient à la satisfaire : la page scannée se réduisait à un séparateur sans rien dessous, et à rien du tout une fois les séparateurs désactivés. La vacuité est désormais mesurée page par page. Sur un fichier de test de quatre pages dont la deuxième était une image, l'extraction a rendu les trois autres pages et, au-dessus, une ligne ambre disant « 1 page(s) ne portent aucun texte sélectionnable et ressortent vides : 2 » ; avec les pages 2 et 4 en images, la même ligne a nommé « 2, 4 ». C'est un avertissement, pas un refus — le texte obtenu reste à toi. Ce qu'il t'indique, ce sont les pages qui relèvent d'une reconnaissance optique de caractères et non d'un second essai.

Questions fréquentes

Pourquoi mon PDF à deux colonnes ressort-il illisible ?

Parce que la ligne de gauche et celle de droite sont imprimées à la même hauteur, et que la reconstruction regroupe par hauteur. Elle n'a aucun moyen de savoir que la page est divisée en deux zones de lecture — un PDF ne l'enregistre pas. Elle lit donc de part en part, joint les deux fragments par une espace et descend. Les deux modes le font ; le mode paragraphe aggrave ensuite en collant les lignes entrelacées. S'il te faut un texte propre issu d'un document à deux colonnes, extrais page par page et sépare les colonnes à la main, ou trouve une version du document jamais mise en colonnes.

Peut-il lire un PDF scanné, et fait-il de l'OCR ?

Non, et non. Un PDF scanné contient une image de page et aucun objet texte : il n'y a rien à extraire ; l'outil ne renvoie rien et t'indique que le fichier est très probablement un scan sans couche de texte. La reconnaissance optique de caractères est une autre opération — elle regarde les pixels et devine quelles lettres ils représentent, d'où ses erreurs possibles et le besoin de connaître la langue lue. Cet outil ne le fait pas, ne le propose pas et ne l'essaie pas en douce. Un test rapide avant d'envoyer : ouvre le fichier dans un lecteur et tente de sélectionner une phrase. Si le surlignage ne suit pas les mots, aucun outil d'extraction n'aidera.

Il dit qu'il n'y a pas de texte, mais je peux en sélectionner dans mon lecteur. Pourquoi ?

Vérifie d'abord la plage de pages. Le champ accepte n'importe quoi et écarte silencieusement les numéros absents du document : demander la page 99 d'un fichier de dix pages ne laisse rien à extraire — et le message obtenu dit exactement cela, en indiquant combien de pages le document compte réellement, plutôt que de traiter ton fichier de scan. Vide le champ et relance. L'autre possibilité est que les pages sélectionnées soient justement les pages scannées : un document peut mêler des pages saisies et un feuillet scanné, et si tu n'as demandé que ce feuillet, il n'y a rien dessus. Demande plutôt le document entier. Toute page portant du texte est extraite, et les pages revenues vides sont nommées dans un avertissement au-dessus du résultat : tu vois ainsi lesquelles relèvent d'une reconnaissance optique de caractères.

Quel mode de mise en page choisir ?

Choisis « Garder les lignes » chaque fois que la disposition de la page porte du sens : tableaux, formulaires, factures, tout ce qui a des colonnes, et tout document que tu comptes vérifier ligne à ligne. Choisis « Recoller en paragraphes » uniquement pour du texte suivi sur une colonne que tu vas coller dans un document, où les lignes coupées sont une gêne plutôt qu'une information. Le mode paragraphe est celui qui répare les mots coupés : il produit une prose réellement meilleure — sur le bon type de page. Sur le mauvais, il détruit la structure de façon irréversible, et tu ne peux pas la récupérer depuis la sortie ; il faut relancer l'extraction.

Retire-t-il l'en-tête et le pied de page répétés à chaque page ?

Non. Chaque élément répété ressort une fois par page, et sur un document long cela fait beaucoup de bruit : un décret de 44 pages a produit 44 copies de sa ligne d'en-tête et 44 lignes de numéro, posées entre les phrases qu'elles interrompent. Les retirer de façon fiable supposerait de reconnaître qu'une ligne est du mobilier plutôt que du contenu, jugement que l'outil ne porte pas. Le remède pratique est un rechercher-remplacer dans un éditeur de texte après extraction : l'en-tête est une chaîne répétée à l'identique, une seule substitution les efface tous. Fais-le avant de compter les mots ou d'alimenter autre chose, sinon le mobilier répété sera compté comme du contenu.