« Convertir un PDF en texte » est un problème difficile

 (marginalia.nu)
4 points par GN⁺ 2025-05-15 | 1 commentaires | Partager sur WhatsApp
  • L’extraction de texte à partir d’un fichier PDF est bien plus difficile qu’on ne l’imagine, car le PDF est fondamentalement un format de fichier basé sur le graphisme
  • Dans un PDF, il n’existe souvent que des informations de position des glyphes, avec très peu de signaux sémantiques, ce qui rend l’identification et la reconstruction du texte délicates
  • Les moteurs de recherche attendent une entrée propre au format HTML, mais les outils open source existants ont des limites pour extraire les informations structurelles comme les titres ou les paragraphes
  • Les approches de vision fondées sur le machine learning sont les plus précises, mais elles sont difficiles à appliquer à grande échelle à cause des contraintes de ressources et de performances
  • Parmi les principales pistes d’amélioration, on trouve l’introduction d’algorithmes d’identification des titres et des paragraphes fondés sur la taille de police et des statistiques, afin d’améliorer la précision de l’extraction

Les défis de l’extraction de texte depuis un PDF

  • Les moteurs de recherche modernes savent désormais indexer le format de fichier PDF
  • Extraire de l’information d’un PDF est un problème difficile, car le PDF a été conçu à l’origine comme un format graphique et non textuel
  • Au lieu de texte réel, on y trouve des glyphes placés à des coordonnées, d’où des problèmes de rotation, de chevauchement, d’ordre mélangé et d’absence d’information sémantique
  • Les informations textuelles telles qu’on les conçoit habituellement n’existent pas directement dans le fichier
  • Le fait qu’un lecteur PDF permette une recherche de texte avec ctrl+f est en réalité assez remarquable

Les exigences des moteurs de recherche et les limites des approches de base

  • Le format d’entrée préféré des moteurs de recherche est un HTML propre
  • Les modèles récents de vision par ordinateur fondés sur le machine learning offrent les meilleures performances, mais
    • traiter de gros volumes de fichiers PDF (des centaines de Go) sur un seul serveur sans GPU est inefficace
  • Heureusement, ce domaine n’est pas totalement terra incognita, et
    • la classe PDFTextStripper de PDFBox peut servir de point de départ
    • mais elle ne permet presque pas d’identifier la structure sémantique comme les titres — elle extrait seulement des chaînes de caractères

Algorithme d’identification des titres

Principe de base de l’identification des titres

  • En général, on peut exploiter le fait que les titres apparaissent souvent en semi-gras ou dans une graisse plus marquée, et de manière isolée
    • mais les titres non gras sont aussi fréquents, donc cette méthode seule a ses limites
  • Dans de nombreux cas, la taille de police sert de critère pour distinguer les titres
    • toutefois, la taille de police varie complètement d’un document à l’autre, et il est impossible d’utiliser un seuil global

Exploitation des statistiques sur la taille de police

  • Chaque page possède généralement une taille de police dominante (le corps du texte)
  • La page 1 (la couverture) a une distribution différente des tailles de police, en raison du contenu descriptif et des informations sur les auteurs
  • Comme la distribution des tailles de police diffère d’une page à l’autre, il est plus efficace d’utiliser des statistiques à l’échelle de la page plutôt que du document entier
  • En appliquant une majoration d’environ 20 % à la taille de police médiane de chaque page, on peut identifier les titres avec une assez bonne précision

Le problème de la fusion des titres sur plusieurs lignes

  • Pour des raisons de style, un titre peut être réparti sur plusieurs lignes
    • déterminer à quel moment fusionner un titre n’est pas simple : il peut y avoir des titres sur deux lignes ou plus, des noms d’auteurs ou d’autres textes mis en emphase
  • Règles de fusion :
    • fusionner les lignes consécutives qui ont la même taille de police et la même graisse fonctionne plutôt bien
    • mais il existe beaucoup d’exceptions — fusionner sans discernement peut produire des résultats absurdes

Amélioration de l’identification des paragraphes

  • PDFTextStripper identifie les paragraphes à partir de l’espacement entre les lignes et de l’indentation
    • comme il utilise une valeur fixe pour le seuil de séparation entre les lignes, il gère mal les documents qui ont des interlignes différents
    • en particulier, des interlignes de 1,5 à 2 fois sont fréquents dans les brouillons d’articles ou les prépublications
  • Si le seuil est trop grand, des erreurs apparaissent et les titres se retrouvent intégrés au corps du texte

Séparation statistique des paragraphes

  • Comme pour la taille de police, on peut appliquer un traitement statistique à l’interligne
    • en utilisant la médiane de la distance entre les lignes, on obtient une séparation robuste des paragraphes quel que soit l’interligne

Conclusion

  • Extraire du texte depuis un PDF ne peut, par nature, jamais être parfaitement fiable
    • parce que le format PDF lui-même n’a pas été conçu pour cet usage
  • Dans une implémentation réelle, le compromis est indispensable, et il est important d’adopter une stratégie visant un résultat « suffisamment bon »
  • Pour les moteurs de recherche, il est plus efficace de se concentrer sur l’extraction de signaux significatifs tels que les titres, les résumés et les principaux indices structurels

Exemples de textes de référence

  • Can Education be Standardized? Evidence from Kenya (2022) - Working Paper
    : Guthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. Ozier
  • The theory of ideas and Plato’s philosophy of mathematics (2019)
    : Dembiński, B.
  • The role of phronesis in Knowledge-Based Economy (2024)
    : Anna Ceglarska, Cymbranowicz Katarzyna

À lire aussi

1 commentaires

 
GN⁺ 2025-05-15
Avis Hacker News

  • Il m’est déjà arrivé de trouver quelque chose de nouveau et d’intéressant dans la vie, puis de voir remonter vaguement le souvenir que j’en avais été expert pendant des mois, voire des années, par le passé. Même des moments où j’ai fait des choses vraiment formidables semblent s’être complètement effacés de ma tête, au point de me donner l’impression de repartir de zéro. J’ai un souvenir flou d’avoir fait quelque chose d’impressionnant avec les PDF et l’OCR il y a 6 ou 7 ans. En cherchant sur Google, le nom « tesseract » me paraît familier

    • Vers 2006, j’étais agacé par l’impossibilité de copier le texte d’articles scientifiques en plusieurs colonnes sur l’iRex, une liseuse hackable des débuts. Le viewer PDF utilisait alors poppler, donc j’ai modifié poppler pour qu’il infère l’ordre de lecture dans les documents multicolonnes. Pour cela, je me suis inspiré de l’algorithme OCR de Thomas Breuel, l’auteur de tesseract. C’était une sorte de hack heuristique, et ça ne s’accordait pas très bien avec l’API d’accessibilité. Une fonction de sélection multicolonnes a bien été introduite, mais j’ai eu du mal à convaincre les mainteneurs. Quoi qu’il en soit, c’est ainsi que kpdf a obtenu une fonction de sélection multicolonne. Aujourd’hui, je pense qu’il est bien plus logique d’utiliser directement tesseract pour ce genre d’usage

    • On ne pourra jamais récupérer les dizaines d’années-homme que l’humanité a gaspillées à cause du format PDF. Je me demande quand cette folie prendra fin

    • Tesseract a été pendant un temps le meilleur OCR open source. Mais aujourd’hui, je trouve docTR supérieur en précision et en accélération GPU. docTR a une architecture en pipeline qui permet de combiner différents modèles de détection et de reconnaissance de texte. On peut aussi l’entraîner et l’ajuster dans PyTorch ou TensorFlow, ce qui permet d’obtenir des performances bien mieux adaptées à un domaine spécifique

    • C’est ça, la vie. À chaque fin de projet, on se dit : « Maintenant je suis devenu expert dans ce domaine. Mais je ne referai probablement jamais ça. » Parce que la fois suivante, on recommence depuis zéro sur un sujet totalement nouveau

    • Il n’y a pas longtemps, quelqu’un m’a posé une question sur le C++ et j’ai répondu : « Je n’ai jamais travaillé sérieusement avec. » Puis je me suis souvenu, avec retard, qu’il y a environ 20 ans, j’avais écrit le code client d’une messagerie instantanée privée en Borland C++, utilisée par plusieurs milliers de personnes. Ce genre de chose m’arrive souvent

    • Je ne peux pas savoir exactement ce qu’il y a dans ta tête, mais oui, ça ressemblait vraiment à tesseract. J’ai vécu quelque chose de similaire, dans mon cas il y a environ 12 ans

    • À l’époque où HQ cartonnait, j’avais fabriqué un solveur automatique de quiz HQ avec tesseract. Je prenais une capture d’écran de la question dans l’app, je l’envoyais à une petite API, puis je cherchais la phrase de la question sur Google et je classais les réponses selon le nombre d’occurrences trouvées pour chacune. Ce n’était ni très précis ni très sophistiqué, mais c’était amusant à construire

    • C’est un phénomène qui ne vaut guère mieux qu’une fourmi de feu qui, quand une feuille s’envole, va simplement en chercher une autre

    • Comme ça remonte à mes 20 ans, il y a 7 ou 8 ans, je m’en souviens encore très bien. Je me demande s’il y a peut-être une différence d’âge. Ou alors, je recommanderais aussi un bilan de santé

  • J’aimerais qu’il existe un outil, un peu comme les outils de développement du navigateur (« inspecter l’élément »), qui permette de « voir » au niveau source les content streams d’un PDF — le BT…ET qui entoure le texte, les divers opérateurs qui définissent les polices et les coordonnées, etc. — et de les comparer/analyser côte à côte avec le rendu. Ce n’est pas la même chose que le flux actuel où les modèles de vision traitent un PDF en le « regardant » pour lire le texte ; j’ai envie de comprendre en profondeur quelles informations sont réellement présentes à l’intérieur d’un PDF. Il existe bien quelques outils, mais ils s’arrêtent au niveau des objets et n’entrent pas dans les content streams. Je voudrais un environnement où l’on puisse comparer et analyser côte à côte, comme en HTML, le vrai code source du stream d’un PDF d’exemple et son rendu, pour voir comment chaque partie est représentée

    • Je pense qu’on peut obtenir une expérience presque similaire en utilisant PDF.js de Mozilla pour rendre le PDF dans le DOM. Par exemple, des opérateurs comme Tj ou TJ sont transformés en <span> ou en groupes de ceux-ci. C’est probablement dû à la nécessité de rester fidèle au document source

    • Je recommande d’essayer l’outil cpdf (que j’ai créé). Les options -output-json et -output-json-parse-content-streams de cpdf permettent de convertir un PDF en JSON pour faire toutes sortes d’expériences. On peut aussi faire l’inverse et revenir du JSON vers le PDF. En revanche, il n’offre pas d’interactivité en temps réel

    • Tu sembles chercher un outil gratuit ou open source, mais quand j’utilisais Acrobat Pro autrefois, il fournissait quelque chose de presque équivalent. Cela dit, c’était plus une navigation dans l’arbre de contenu qu’une inspection de page, et on s’arrêtait aux objets/streams sans descendre jusqu’aux commandes individuelles

    • « Nous construisons chez Tensorlake une combinaison de “voir le PDF comme le ferait un humain avec un modèle de vision” et de “savoir quelles données se trouvent réellement dans le PDF” (j’y travaille). L’idée n’est pas seulement de lire du texte, mais de vraiment comprendre aussi les tableaux, les images, les équations, l’écriture manuscrite, etc., afin d’extraire les données en Markdown/JSON pour des applications d’IA, de LLM, etc. » https://tensorlake.ai

    • Ce n’est pas exactement au niveau que tu souhaites, mais il existe un notebook qui fournit un inspecteur montrant en « live » les différentes opérations de dessin internes d’un PDF, ça peut valoir le détour : https://observablehq.com/@player1537/pdf-utilities

  • J’ai travaillé plusieurs années chez Apple sur ce problème. Le point essentiel, c’est d’accepter que « tout est géométrie », puis d’utiliser un algorithme qui différencie l’espacement entre les mots et celui entre les lettres par clustering. Cela fonctionne bien sur la plupart des PDF, mais en regardant de près, la diversité des cas est telle que certains restent décevants. Si je devais m’y remettre aujourd’hui, je supprimerais complètement l’OCR, je partirais d’une approche basée sur l’information géométrique, mais en y ajoutant du machine learning. Si l’on génère des PDF à partir d’un texte connu à l’avance pour les exploiter en apprentissage automatique, on peut même automatiser la construction des données d’entraînement. (Il existe une vidéo de présentation de Bertrand Serlet à la WWDC 2009)

  • Je ne pense pas qu’il s’agisse d’un seul problème « PDF to Text », mais en réalité de 3 catégories : (1) un OCR fiable (pour la recherche, l’alimentation d’une base vectorielle, etc.), (2) l’extraction de données structurées (ne récupérer que certaines valeurs), (3) l’automatisation du pipeline documentaire complet (par ex. l’automatisation des prêts immobiliers). Marginalia vise le point (1), et avec Gemini Flash et d’autres, l’OCR devient aujourd’hui peu coûteux et générique. En revanche, les points (2) et (3) sont bien plus difficiles, et l’automatisation complète exige encore énormément de travail humain : constitution de datasets, conception du pipeline, détection de l’incertitude et intervention manuelle, fine-tuning, etc. C’est là que se trouve l’avenir. (Je dirige une entreprise de traitement documentaire avec des LLM) https://extend.ai

    • Je pense qu’il faut aussi une catégorie (4) : un OCR fiable et une extraction sémantique sur des documents de formes variées, autrement dit une solution pour l’accessibilité. C’est difficile parce que, contrairement à un workflow classique, on ne peut pas prédire le type de document utilisateur ; il faut extraire aussi des éléments non textuels comme les tableaux, les en-têtes/pieds de page/annotations/équations ; il faut minimiser les erreurs, donc éviter d’utiliser l’OCR plus que nécessaire ; le texte embarqué peut ne pas correspondre au rendu réel (texte caché, assemblages atypiques, etc.) ; cela fonctionne surtout dans des applications locales, donc il est difficile de s’appuyer sur des serveurs ; et il faut aussi gérer les formulaires pour des documents destinés à l’impression. À ce jour, il n’existe pas de solution qui résolve complètement tous ces points

    • On dit avoir simplifié les pipelines OCR avec des VLM, mais attention : sur les documents réellement complexes, c’est extrêmement difficile. C’est excellent pour des labels d’image simples, et utilisable sur des documents très simples, mais dès qu’il y a des tableaux, des en-têtes, des résumés structurés, etc., les hallucinations deviennent très importantes. En pratique, c’est donc presque inutilisable

    • En convertissant vers Markdown, je rencontre toutes sortes de problèmes, notamment la détection des en-têtes. L’OCR moderne est excellent, mais préserver la structure globale du document est bien plus difficile. J’obtiens des résultats à peu près corrects en faisant passer le document plusieurs fois dans des LLM pour en extraire la structure, avec du contexte injecté page par page

  • Une meilleure solution serait de joindre au PDF le document source éditable. On peut le faire simplement avec LibreOffice. En général, cela ne prend pas beaucoup plus d’espace, et cela permet de connaître clairement la sémantique du texte. Les lecteurs PDF existants continuent de fonctionner sans problème

    • Quand le vrai problème est l’extraction de texte à partir de PDF existants, je me demande sincèrement en quoi des conseils sur la manière de fabriquer les PDF peuvent aider. Je me demande à quel moment ce genre de solution commencera réellement à produire un effet

    • C’est vrai, mais cela introduit le risque que le document source et le PDF rendu aient des contenus complètement différents

    • C’est une bonne remarque, mais elle n’est valable que si les intérêts de celui qui produit le PDF et de celui qui le consomme sont alignés. Dans le domaine de l’e-Discovery, il est courant que l’avocat adverse convertisse volontairement les pièces en PDF pour les rendre plus difficiles à exploiter. Résultat : les défenseurs publics disposant de peu de moyens passent davantage de temps à traiter les documents et subissent un désavantage concret. Pour éviter cela, je pense qu’il faudrait imposer par la loi le dépôt de certains types de données dans des formats standard lisibles par machine

    • Si l’on a accès au document source, l’attacher à l’intérieur du PDF est effectivement une très bonne idée. Mais dans la plupart des cas, on n’a pas ce niveau de contrôle

    • La plupart des vrais problèmes viennent des PDF legacy. Dans notre entreprise aussi, nous en avons des milliers accumulés, dont certains sont des scans catastrophiques. Quelques-uns ont un OCR Adobe intégré, mais la grande majorité n’en a pas du tout

  • Le PDF ci-dessous est en réalité un fichier .txt. On peut changer son extension en .pdf et l’ouvrir dans un lecteur PDF, ou le modifier directement dans un éditeur de texte pour contrôler ce qui s’affiche à l’écran, la police, la taille de police, l’interligne, le nombre de caractères par page, le nombre de lignes, la taille du papier, etc. (avec un exemple de texte PDF inclus directement)

    • Un PDF peut aussi embarquer des flux binaires. Le PDF n’est pas un format texte, c’est un format conçu pour la mise en page et le graphisme. Comme dans l’exemple, chaque ligne peut apparaître en une seule fois, mais en réalité cela peut aussi être représenté caractère par caractère, mot par mot, voire même dans le désordre

    • PDF signifie « Portable Document Format ». Il est encodé sous forme de fichier ASCII 7 bits, ce qui lui confère une grande portabilité sur une grande variété d’appareils et de systèmes d’exploitation. (Référence : lien vers la documentation officielle d’Adobe)

    • Cet exemple est le « Hello World » du PDF. Les PDF récents compressent généralement la plupart des objets (obj) avec deflate et regroupent ces objets dans des streams, ce qui les rend bien plus complexes. Du coup, il devient très difficile de les analyser simplement en cherchant du texte comme 6 0 Obj

  • Extraire du texte d’un PDF, surtout du texte structuré, n’est absolument pas simple. Les tableaux HTML sont généralement relativement faciles à extraire, mais dans un PDF, ils ne sont qu’un rendu visuel basé sur des coordonnées ; en réalité, le texte et les éléments graphiques sont dispersés. Pour ma part, j’utilise Poppler PDF utils pour convertir le PDF en HTML, puis je repère les en-têtes de tableau, j’identifie les colonnes à partir des coordonnées x de chaque valeur, et j’extrais les données ligne par ligne. C’est rudimentaire visuellement, mais plus fiable qu’un simple .txt aligné

    • J’étais frustré de ne pas pouvoir extraire des données d’un PDF comme on le fait d’une page web avec BeautifulSoup, alors j’ai créé moi-même une bibliothèque avec ce type d’interface. (exemple de forme page.find) Comme les cas particuliers varient d’un PDF à l’autre de façon infernale, je rassemble mon savoir-faire d’extraction et des exemples de PDF monstrueux dans cette bibliothèque : https://jsoma.github.io/natural-pdf/ , https://badpdfs.com/

    • J’aimerais, un jour, extraire des données tabulaires de PDF vers mon logiciel de traitement de données. Si quelqu’un connaît une bibliothèque gratuite ou très peu chère qui puisse s’intégrer à une application C++, je suis preneur

    • Il existe des documents, notamment d’organismes publics, où le texte affiché et le texte réellement extrait n’ont absolument rien à voir. Ce genre de cas arrive régulièrement

    • Le PDF est fondamentalement un format de type markup/XML. Un même PDF peut être produit d’innombrables façons. Exporté depuis un outil graphique, on obtient un PDF mêlant graphismes et texte ; exporté depuis un traitement de texte, on obtient plutôt un PDF centré sur le texte, etc. Le résultat est multidimensionnel. La façon dont l’application de production traite l’information a une grande influence sur la manière dont le PDF est généré. Parmi les utilitaires prêts à l’emploi, divers produits comme cisdem peuvent être utiles jusqu’à un certain point pour extraire des données structurées. Mais il faut un outil adapté à chaque tâche

  • L’un de mes exemples préférés est le PDF de cet article de recherche (lien joint). La première page cumule le texte classique en deux colonnes, un en-tête central, du texte inséré entre les deux colonnes, et même des éléments qui modifient la longueur des lignes et l’indentation. Les en-têtes de page changent aussi entre pages paires et impaires, et les règles des titres de section ne sont pas uniformes. Les paragraphes non plus ne sont pas toujours indentés, et l’espacement des lignes varie. C’est un concentré de problèmes différents

    • L’API CoreGraphics de macOS fournit le texte d’un PDF page par page, dans l’ordre encodé dans le dictionnaire. Dans 95 % des cas, cela fonctionnait assez bien, et PDFKit comme Preview n’ont pas posé de gros problèmes pendant des années. Même pour du texte en deux colonnes, le PDF suivait généralement l’ordre du buffer du traitement de texte d’origine, donc le flux du contenu restait correct. En revanche, pour les en-têtes, pieds de page, etc., chaque application interne les gère d’une manière totalement différente, donc c’est imprévisible

  • Quand j’ai moi-même écrit un petit parseur PDF, j’ai été stupéfait par la manière dont ce format fonctionne. Du coup, je me suis toujours demandé pourquoi il était autant utilisé pour des usages centrés sur le texte. Par exemple, pour une facture, l’idéal serait qu’un système numérique puisse extraire facilement les données, tout en présentant à l’humain une version correctement mise en forme. J’aimerais donc que le secteur fasse une migration progressive vers de meilleurs formats

    • XML+XSLT se rapprochait autrefois beaucoup de ce rôle, mais malheureusement les navigateurs ne le prennent plus en charge pour les fichiers XML locaux. Ils ne prennent plus en charge que le XML servi à distance par un serveur

  • Extraire des « informations utiles » à partir de PDF, c’est précisément le travail de Tensorlake (https://tensorlake.ai). Un PDF contient non seulement du texte, mais aussi des tableaux, des images, des équations, de l’écriture manuscrite, des textes barrés, etc. En tant que développeurs, nous devons donc être capables non seulement de « lire » le texte, mais aussi de le « comprendre ». (Je précise que j’y travaille)