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’indexation des PDF a été ajoutée au moteur de recherche, mais obtenir à partir d’un PDF un texte structuré exploitable pour la recherche est bien plus difficile que de traiter du HTML
  • Un PDF se rapproche davantage d’un format graphique basé sur des coordonnées que d’un document texte, si bien que les glyphes peuvent être placés en étant tournés, superposés ou dans le désordre
  • Le PDFTextStripper de PDFBox peut servir de point de départ, mais il ne restitue pas suffisamment la structure sémantique, comme les titres ou les paragraphes, ce qui limite l’évaluation de la pertinence en recherche
  • Pour distinguer les titres des paragraphes, des heuristiques comme les statistiques de taille de police par page et la médiane de l’interligne sont plus utiles qu’une référence calculée sur l’ensemble du document
  • Comme une extraction parfaite du texte d’un PDF est difficile, l’objectif réaliste pour un moteur de recherche est une solution suffisamment bonne pour obtenir de façon fiable la structure titre, résumé et corps du texte

Les problèmes révélés par l’ajout de l’indexation PDF

  • Le moteur de recherche est désormais capable d’indexer le format de fichier PDF, et le déploiement du changement s’étalera sur plusieurs mois
  • Du point de vue d’un moteur de recherche, un HTML propre est ce qu’il y a de plus simple à traiter, mais un PDF ne fournit pas directement le même niveau de texte structuré
  • Même si du texte semble visible à l’écran, reconstituer à partir du PDF des phrases et des paragraphes exploitables pour la recherche relève presque d’un problème distinct

Pourquoi les PDF sont difficiles pour l’extraction de texte

  • Un PDF n’est pas un format texte classique, mais se rapproche d’un format graphique
  • Sa représentation interne ressemble davantage au placement de glyphes à des coordonnées sur une « feuille » qu’à des phrases ou des paragraphes
  • Les glyphes peuvent se trouver dans les états suivants
    • tournés
    • superposés
    • affichés dans un ordre différent de l’ordre de lecture
    • accompagnés de très peu d’informations sémantiques
  • Le simple fait qu’une recherche ctrl+f fonctionne dans une visionneuse PDF ou un navigateur est déjà assez remarquable
  • Les modèles de machine learning basés sur la vision peuvent constituer aujourd’hui une bonne approche, mais ils ne conviennent pas à un traitement à l’échelle de centaines de Go de PDF sur un seul serveur sans GPU

On peut commencer avec PDFBox, mais cela ne suffit pas

  • Ce n’est pas un problème totalement inexploré, et la classe PDFTextStripper de PDFBox peut servir de point de départ
  • PDFTextStripper extrait le texte des PDF, mais, comme son nom l’indique, il se concentre surtout sur le fait de dépouiller le texte
  • Pour un moteur de recherche, des informations sémantiques comme le titre sont des signaux de pertinence importants, et les résultats d’extraction par défaut ne permettent pas de récupérer suffisamment bien cette structure

Heuristiques pour trouver les titres

  • La détection de titre la plus simple consiste à chercher des lignes en graisse semibold ou plus, séparées du reste du texte
  • Mais tous les titres ne sont pas affichés en gras, et de nombreux documents distinguent les titres par la taille de police
  • Une référence globale de taille de police varie d’un document à l’autre
    • un document peut utiliser du corps en 10pt et des titres en 16pt
    • un autre peut utiliser du corps en 14pt et des titres en 20pt
  • Des statistiques par page sont parfois plus adaptées qu’une mesure sur l’ensemble du document
    • la première page peut avoir des choix de police très différents du reste à cause du résumé et de la liste des auteurs
    • dans l’exemple, le titre du document utilise une police de taille 17, puis les titres suivants une police de taille 14
  • Chaque page possède en général une taille de police dominante correspondant au corps du texte
  • En appliquant un coefficient d’environ 20 % à la taille médiane de police par page, on peut identifier les titres de façon assez stable
  • Il reste des exceptions, mais la plupart des cas importants peuvent être couverts

Fusionner en un seul titre les titres sur plusieurs lignes

  • Les titres sont souvent répartis sur plusieurs lignes pour des raisons de style, et il faut parfois fusionner des lignes de titre consécutives en un seul élément
  • Déterminer quand les fusionner n’est pas simple
  • L’exemple présente en même temps les cas suivants
    • un titre sur deux lignes
    • un titre aligné à droite
    • un nom d’auteur en semibold juste après le titre
    • un titre non gras situé quelques lignes plus bas
  • L’indentation sert aussi de signal pour distinguer les paragraphes, ce qui rend les titres alignés à droite encore plus difficiles à traiter
  • Fusionner des lignes de titre consécutives ayant la même taille de police et la même graisse fonctionne généralement bien, mais peut aussi produire des résultats indésirables

Les pièges de l’interligne dans l’identification des paragraphes

  • PDFTextStripper effectue plutôt bien l’identification des paragraphes
  • Il décide où couper les paragraphes en examinant à la fois l’interligne et l’indentation
  • Il reste une marge d’amélioration, en particulier dans la logique liée à l’interligne
  • Le gros problème de PDFTextStripper est qu’il utilise un seuil fixe pour séparer les lignes
    • si l’écart entre deux lignes dépasse ce seuil, il considère qu’elles n’appartiennent pas au même paragraphe
    • cela ne reflète pas suffisamment le fait que l’interligne varie selon les documents
  • Dans les brouillons académiques et les preprints, un interligne de 1,5 à 2 est assez courant
  • Si l’on fixe une valeur seuil trop élevée, certains titres risquent d’être absorbés dans les paragraphes du corps de texte, ce qui gêne leur identification

Corriger avec des statistiques d’interligne

  • Comme pour le traitement de la taille de police, on peut appliquer des méthodes statistiques à la distance entre les lignes
  • Si l’on construit un histogramme des distances entre les lignes sur une page de texte, on observe souvent de gros outliers
  • La moyenne est facilement perturbée par les outliers, alors que la médiane peut correspondre exactement à l’interligne utilisé dans le corps du texte
  • En appliquant un certain coefficient à la médiane, on peut construire une heuristique de séparation des paragraphes qui tient sur une variété d’interlignes

L’objectif réaliste est la stabilité plutôt que la perfection

  • Il est difficile d’obtenir une extraction de texte parfaite à partir d’un PDF
  • Le format PDF lui-même n’a pas été conçu pour ce type de tâche, et choisir une solution « suffisamment bonne » implique plusieurs compromis
  • Un moteur de recherche s’intéresse en particulier aux informations suivantes
    • les signaux de pertinence comme les titres
    • l’identification du résumé
    • une structure à peu près cohérente pour le reste du texte
  • Avec ces objectifs, on peut parvenir à une solution capable de traiter la plupart des documents pertinents sans difficulté majeure

Exemples de textes utilisés

  • 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 sur Hacker News

  • Il arrive qu’on oublie complètement quelque chose dans lequel on s’était plongé pendant des mois, voire des années, au point d’atteindre un niveau d’expertise, puis que plus tard on se dise : « tiens, c’est nouveau et intéressant »
    On a fait pas mal de choses intéressantes, mais elles disparaissent de la mémoire, si bien qu’on a l’impression de recommencer sa vie à zéro jusqu’à ce qu’un élément déclencheur les fasse remonter
    J’ai un souvenir assez vague d’avoir fait un travail plutôt chouette avec PDF et OCR il y a 6 ou 7 ans, et en cherchant, il me semble que c’était Tesseract

    • Vers 2006, sur une liseuse ancienne appelée iRex, il était impossible de copier le texte d’articles scientifiques en plusieurs colonnes, alors j’ai creusé la cause ; comme le lecteur PDF utilisait Poppler en interne, j’ai modifié Poppler pour déduire l’ordre de lecture des documents multicolonnes, en m’appuyant sur un algorithme d’OCR présenté par Thomas Breuel, l’auteur de Tesseract
      C’était un hack assez proche d’une heuristique, et il me semble que l’ancienne API de Poppler de l’époque ne représentait pas les séquences de texte d’une manière adaptée aux API d’accessibilité
      La sélection multicolonne a fini par être intégrée dans une certaine mesure, mais il a ensuite été difficile de convaincre les mainteneurs d’accepter des propositions d’amélioration des performances, au motif que l’heuristique changeait un peu et que, dans certains cas, le résultat de la sélection différait
      Dès le départ, il n’y avait pas une seule « bonne réponse », donc exiger une correspondance exacte des résultats n’avait pas de sens ; c’est ainsi que la sélection multicolonne de kpdf a plus ou moins vu le jour
      Aujourd’hui, il est probablement plus raisonnable d’utiliser directement Tesseract pour ce type d’usage
    • Les décennies de temps humain collectivement brûlées à cause de ce format ne reviendront jamais
      Je ne sais pas quand cette folie prendra fin
    • Tesseract a longtemps été le meilleur OCR open source, mais je pense qu’aujourd’hui docTR est meilleur
      Sa précision par défaut est plus élevée, il prend en charge l’accélération GPU, et il implémente sous forme de pipeline composable plusieurs architectures de modèles de détection et de reconnaissance de texte
      On peut l’entraîner ou l’affiner avec PyTorch ou TensorFlow pour améliorer encore ses performances sur des domaines spécifiques
    • Un jour, quelqu’un m’a posé une question sur C++ et j’ai répondu que je n’avais « jamais vraiment travaillé sérieusement en C++ », avant de me rappeler qu’il y a une vingtaine d’années, j’avais écrit en Borland C++ le code d’un client de messagerie instantanée privé utilisé par des milliers de personnes
      Donc oui, ce genre de chose arrive vraiment
    • À chaque fois que je termine un projet, j’ai souvent le sentiment suivant : « maintenant, je suis devenu expert là-dedans. Mais je ne le referai probablement jamais »
      Le travail suivant relève d’un domaine complètement différent, et il faut repartir des bases

  • Ce serait bien que quelqu’un crée l’équivalent des outils de développement du navigateur pour les PDF
    Comme avec « Inspecter l’élément », on pourrait voir le flux de contenu du PDF comme source, et vérifier comment les opérateurs de texte BT … ET ou l’opérateur de placement de texte Tj spécifient et génèrent chaque pixel
    C’est l’inverse de la tendance actuelle, où les modèles visuels « regardent » et lisent les PDF comme des humains, mais ce serait bien mieux de pouvoir comprendre ce qui se trouve réellement dans un fichier PDF
    Il existe quelques outils pour inspecter le contenu des PDF (https://news.ycombinator.com/item?id=41379101), mais ils s’arrêtent au niveau des objets PDF, de sorte que tout le flux de contenu apparaît simplement comme un seul objet
    Par exemple, à la page 8 du PDF, soit la page 6 du document mentionné dans l’article https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2..., le texte est placé au moyen d’opérateurs comme BT, la configuration de police, Td et TJ
    Si l’on pouvait afficher cette « source » et le PDF rendu côte à côte, puis survoler une zone d’un côté pour mettre en évidence la zone correspondante de l’autre, on pourrait le déboguer comme une page HTML

    • En rendant un PDF dans le DOM avec PDF.js de Mozilla, on pourrait obtenir un résultat assez proche
      Par exemple, chaque Tj deviendrait probablement un élément DOM, tandis que TJ serait un groupe de plusieurs éléments
      Comme il faut refléter correctement le document original pour que cela fonctionne, la conversion a de bonnes chances d’être assez fidèle
    • C’est possible dans une certaine mesure avec cpdf
      On peut créer du JSON avec cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json, modifier ce JSON, puis le reconvertir en PDF avec cpdf -j out.json -o out.pdf
      En revanche, il n’y a pas de liaison bidirectionnelle en temps réel
    • Vous parliez sans doute d’open source ou de gratuit, mais Acrobat Pro, que j’ai utilisé il y a quelques années, proposait aussi une fonctionnalité presque similaire
      Cela dit, ce n’était pas une inspection de la page, mais plutôt une navigation dans l’arborescence de contenu, et les objets sur la page étaient bien mis en évidence
      On ne descendait pas jusqu’au niveau des commandes, seulement jusqu’au niveau des objets ou des flux
    • Ce notebook ne correspond pas exactement à ce que vous voulez, mais il offre une fonctionnalité permettant d’inspecter « en temps réel » plusieurs opérations de dessin dans un PDF
      https://observablehq.com/@player1537/pdf-utilities
    • Ce que construit Tensorlake est également assez proche de cette combinaison
      L’objectif n’est pas seulement de « regarder » le PDF comme un humain et d’en lire le texte, mais de comprendre son contenu, y compris les tableaux, images, textes, formules et écritures manuscrites
      Ils analysent donc le PDF et exécutent plusieurs modèles pour extraire des fragments Markdown ou du JSON, afin que les données réelles puissent être injectées dans des agents IA, des LLM et d’autres applications
      https://tensorlake.ai

  • « PDF vers texte » est une formulation beaucoup trop simplifiée
    Cette catégorie comprend 1) de l’OCR fiable pour l’indexation de recherche ou l’alimentation de bases vectorielles, 2) l’extraction de données structurées pour récupérer des valeurs précises, 3) des pipelines documentaires de bout en bout comme l’automatisation des demandes de prêt immobilier
    Ce que Marginalia doit résoudre, c’est le point 1, l’OCR, et cela se généralise rapidement grâce à des modèles comme Gemini Flash
    J’ai vu plusieurs entreprises remplacer leurs pipelines OCR existants par Flash et réduire fortement leurs coûts, ce qui est assez impressionnant
    Mais les points 2 et 3 sont bien plus difficiles, et il reste encore un grand écart entre une sortie OCR brute et un pipeline documentaire critique en production
    Les LLM et les modèles vision-langage ne sont pas magiques, et s’attendre à une automatisation à 100 % réserve des surprises
    La constitution et l’étiquetage de jeux de données, l’orchestration de pipelines classification -> segmentation -> extraction, la détection d’incertitude avec revue humaine, le fine-tuning, etc. restent nécessaires
    À long terme, on pourra se rapprocher d’une automatisation presque complète, mais cela demandera du temps et des efforts, et il semble clair que l’avenir va dans cette direction
    À ce sujet, j’ai lancé une entreprise de traitement de documents par LLM, https://extend.ai

    • Du point de vue de l’accessibilité, il faut aussi un point 4 : une OCR fiable et une extraction sémantique qui fonctionnent sur une grande variété de types de documents
      Les workflows métier ne traitent souvent que quelques documents bien définis, mais un lecteur PDF généraliste ne sait pas quels documents l’utilisateur va ouvrir
      Il doit reconnaître non seulement le texte, mais aussi les tableaux, en-têtes et pieds de page, notes de bas de page, titres, formules mathématiques, etc.
      Comme c’est destiné à être consommé par des humains, il faut minimiser les erreurs : il ne faut donc pas utiliser l’OCR quand ce n’est pas nécessaire, et il faut exploiter le texte natif inclus dans le PDF tout en extrayant la structure sémantique
      Au final, il faut deux voies : une pour les PDF uniquement constitués d’images, et une pour les PDF dont le flux de contenu permet d’obtenir des informations
      Or le flux de contenu peut contenir un texte différent de ce qui apparaît réellement à l’écran. Par exemple des informations masquées en caractères blancs, ou des implémentations de type LaTeX qui dessinent les accents par des commandes au lieu d’utiliser des accents Unicode
      En général, cela tourne comme application locale sur les appareils peu puissants des utilisateurs, et il y a de fortes chances qu’il n’y ait ni serveur ni modèle par abonnement, donc pas de modèles d’IA cloud utilisables
      Les utilisateurs de logiciels d’accessibilité peuvent avoir du mal à imprimer puis remplir au stylo ; il faut donc traiter non seulement des formulaires propres et conformes aux spécifications, mais aussi des formulaires destinés à l’impression
      C’est encore un problème ouvert dont on est très loin de la résolution ; toutes les solutions actuelles sont insuffisantes d’une manière ou d’une autre, et il n’existe pas de solution unique qui résolve correctement ces cinq points
    • Du point de vue de quelqu’un qui a dû créer ses propres outils parce que les modèles vision-langage étaient trop instables, les entreprises qui utilisent des VLM sur des images non traitées risquent de beaucoup souffrir
      Ils étiquettent très bien les images et conviennent à des documents simples : texte en une seule colonne, titre centré en une seule étape, une image ou un tableau par page
      La plupart des démos de MVP montrent ce genre d’exemples
      Mais sur des documents complexes mêlant tableaux et images, il semble qu’il faudra encore beaucoup plus de paramètres pour atteindre ne serait-ce qu’un « mauvais niveau » acceptable
      Pour l’instant, les hallucinations sont trop importantes : même un tableau simple avec un titre en haut, des données au centre et un résumé en bas est difficilement utilisable tel quel
    • Je continue à bricoler pour traiter les PDF en Markdown, et comme dans l’article original je me heurte à la détection des en-têtes et à plusieurs autres problèmes
      L’OCR d’aujourd’hui est excellent, mais préserver la structure globale d’un document est beaucoup plus délicat
      Obtenir un HTML cohérent sur de grands documents semble encore lointain ; en revanche, en faisant passer le document plusieurs fois dans un LLM pour en extraire la structure, puis en l’injectant comme contexte dans l’extraction page par page, on obtient des résultats Markdown plutôt corrects

  • Chez Apple, on a travaillé sur ce problème pendant plusieurs années avec pas mal de succès, et le secret principal consistait à tout considérer comme de la géométrie et à essayer de distinguer l’espacement entre les mots et l’espacement entre les lettres par analyse de clusters
    Cela fonctionne très bien sur beaucoup de PDF, mais les PDF sont tellement variés qu’il y a toujours des cas où le résultat est médiocre
    Si je devais le refaire aujourd’hui, je conserverais la géométrie et j’éviterais totalement l’OCR, mais j’utiliserais probablement le machine learning
    Le grand avantage du machine learning est qu’on peut automatiser entièrement l’étape d’apprentissage en s’appuyant sur les outils existants qui génèrent des PDF à partir de textes connus
    Bertrand Serlet présentant cette fonctionnalité à la WWDC 2009 : https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308

  • Une meilleure solution serait d’embarquer dans le PDF le document source modifiable
    C’est facile à faire avec LibreOffice, et comme cela se compresse bien, cela prend généralement très peu de place
    On obtient alors de bien meilleures informations sur le texte et la sémantique, tout en restant compatible avec les lecteurs PDF existants

    • C’est vrai, mais il faut que les intérêts du créateur et du consommateur du PDF soient alignés
      Dans le domaine de l’e-discovery, il est courant que la partie qui fournit les preuves les déverse volontairement en PDF pour rendre leur contenu difficile à exploiter par l’avocat adverse
      Si les deux parties ont beaucoup d’argent, ce n’est pas un obstacle, mais par exemple un avocat commis d’office n’a pas les moyens d’embaucher quelqu’un pour transformer les PDF dans un format lisible, ce qui allonge fortement le temps de traitement et accroît la charge psychologique pour l’accusé
      Il peut même arriver que les données ne puissent pas être correctement traitées
      La solution consiste à rendre ces pratiques illégales
      Par exemple, les données d’interception devraient être fournies dans un format standardisé lisible par machine, et il n’y a aucune raison éthique pour qu’une simple friction technique influence l’issue d’une procédure pénale
    • Il est étrange que la meilleure solution au problème des moteurs de recherche qui doivent extraire du texte de PDF existants soit un conseil sur la façon de créer des PDF
      Je me demande combien de temps il faudrait pour que cette solution produise des effets
    • C’est vrai, mais cela crée aussi une vulnérabilité : le document source peut différer arbitrairement du contenu rendu dans le PDF
    • J’ai l’impression que 90 % de l’espace du problème concerne les PDF hérités
      Dans notre entreprise aussi, nous avons des milliers de fichiers de ce type ; certains sont de très mauvaises numérisations, d’autres embarquent l’OCR d’Adobe, mais la plupart ne contiennent rien
    • C’est une bonne méthode si l’on a accès au document source qui a servi à créer le PDF
      Mais en général, on ne dispose pas de ce contrôle

  • Le PDF ci-dessous est en fait un fichier .txt
    Si on l’enregistre avec l’extension .pdf, il peut être ouvert dans un lecteur PDF, et modifié avec un éditeur de texte
    Par exemple, en éditant ce fichier texte, on peut changer le texte affiché à l’écran quand on ouvre le PDF, la police, la taille des caractères, l’interligne, le nombre maximal de caractères par ligne, le nombre de lignes par page, la largeur et la hauteur du papier, ainsi que l’orientation portrait ou paysage
    L’exemple est une structure PDF minimale commençant par %PDF-1.4, où Catalog, Pages, Font, Page, Contents, xref, trailer, etc. sont écrits directement sous forme de texte

    • Un PDF peut aussi contenir des flux binaires intégrés
      Le PDF n’a pas été conçu pour le texte, mais pour la mise en page et les graphiques
      L’exemple est bon, mais chaque ligne peut aussi être découpée en un appel par caractère, un appel par mot, et l’ordre peut être mélangé
    • « PDF » est l’abréviation de « Portable Document Format »
      Dans la section « 2.3.2 Portability » du document de référence PDF 1.0, un fichier PDF est décrit comme un fichier ASCII 7 bits, et il y est indiqué que même les documents contenant des images et des caractères spéciaux sont décrits en n’utilisant que le sous-ensemble imprimable de l’ASCII
      Le résultat, explique le document, est une très grande portabilité entre divers environnements matériels et systèmes d’exploitation
      https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
    • Cela ressemble au Hello World du PDF
      De nos jours, dans la plupart des PDF, tous les objets sont compressés avec deflate
      En plus, pour rendre le suivi encore plus difficile, beaucoup de PDF regroupent la plupart des objets dans des objets de type flux d’objets, puis les compressent à nouveau
      Donc même si l’on veut suivre la fin de 6 0 R, on ne peut pas chercher 6 0 Obj dans un éditeur de texte

  • Il y a un document que j’aime bien pour illustrer les difficultés décrites dans cet article : https://academic.oup.com/auk/article/126/4/717/5148354
    Dès la première page, on trouve le texte classique sur deux colonnes, un titre centré, et une zone de texte intercalée entre les deux colonnes qui change la longueur des lignes et les retraits
    Ensuite apparaissent des en-têtes qui changent selon les pages paires ou impaires, ainsi que des règles de titres de section très différentes
    Pire encore, il n’y a pas d’espacement supplémentaire entre les paragraphes et le retrait de première ligne n’est pas toujours présent, ce qui concentre toutes sortes de difficultés

    • L’API PDF CoreGraphics de MacOS fournissait par défaut le texte page par page dans l’ordre où il était encodé dans le dictionnaire
      Dans environ 95 % des cas, c’était plutôt correct, et cela a suffi pendant des années à PDFKit et Preview sur Mac
      Si l’on pense à l’application d’origine qui a créé le PDF, par exemple un traitement de texte, il est très probable qu’elle ait rendu le texte depuis son propre tampon de texte vers le contexte PDF dans un ordre assez raisonnable
      Ainsi, même dans un document à deux colonnes, le texte s’écoulait souvent correctement de la colonne de gauche vers celle de droite, et il était déjà dans le bon ordre à l’intérieur du PDF
      En revanche, pour les pieds de page ou les en-têtes, impossible de savoir dans quel ordre l’application génératrice du PDF les a déversés dans le contexte

  • Extraire du texte d’un PDF, même du texte structuré, n’a rien de facile
    Récupérer un tableau dans un document HTML est souvent simple, même quand le site utilise l’antipattern consistant à tout faire avec des div, et c’est encore plus facile s’il utilise des éléments sémantiques
    Les PDF, ce n’est pas ça
    Comme je ne suis pas spécialiste du format, je ne sais pas jusqu’où va la prise en charge de la structure sémantique, mais j’ai vu beaucoup de PDF où un tableau était constitué d’un assemblage lâche d’éléments graphiques et textuels qui ne ressemble à un tableau qu’une fois rendu
    En pratique, j’ai assez bien réussi à extraire des données de tableaux en convertissant le PDF en HTML avec les utilitaires PDF de Poppler, puis en recherchant les en-têtes de tableau attendus et en calculant les colonnes à partir de la coordonnée x de chaque valeur pour extraire les valeurs ligne par ligne
    C’est une méthode sale, mais elle a fonctionné de façon fiable pour l’usage dont j’avais besoin, et c’était bien mieux que du texte brut formaté avec des espacements irréguliers ou des retours à la ligne au milieu des lignes

    • Frustré de ne pas pouvoir extraire des données d’un PDF comme on le fait avec une page web et BeautifulSoup, j’ai créé une bibliothèque qui fait plus ou moins ce genre de choses
      Elle contient aussi diverses autres fonctionnalités, mais son objectif principal est de permettre une interaction plus humaine, du genre page.find('text:bold:contains("Summary").below().extract_text()
      Comme chaque PDF est un cauchemar sur mesure, j’essaie de rassembler des exemples difficiles à extraire pour en faire la base d’une bibliothèque de méthodes
      https://jsoma.github.io/natural-pdf/
      https://badpdfs.com/
    • Dans les documents officiels du gouvernement, les cas que je préfère sont ceux où le texte rendu et le texte obtenu par extraction classique sont complètement différents
    • J’aimerais qu’un jour mon logiciel de nettoyage de données puisse faire de l’extraction de données tabulaires depuis les PDF
      Si quelqu’un connaît une bibliothèque d’extraction de tableaux PDF intégrable dans une appli C++ et gratuite, ou coûtant moins de quelques centaines de dollars, j’aimerais qu’il me le dise
    • Le PDF est fondamentalement un format de balisage/XML, et son standard est public et peut être appris
      Il existe vraiment beaucoup de façons de produire le même PDF
      Certains outils ressemblent davantage à l’export d’une mise en page contenant du texte et des graphiques depuis un éditeur graphique, tandis que d’autres se rapprochent d’un traitement de texte qui exporte du texte et des graphiques en partant d’abord des mots
      La manière dont l’application génératrice considère l’information influence souvent aussi sa façon de produire le PDF
      Si l’on cherche un utilitaire prêt à l’emploi, des outils comme cisdem ont déjà résolu le problème jusqu’à extraire assez correctement des données structurées pour un utilisateur local
      Il existe beaucoup d’outils de ce type, et beaucoup promettent la prise en charge des données structurées, mais il faut qu’ils correspondent bien à la tâche que l’on veut accomplir

  • Le PDF est un format d’affichage
    Il est optimisé pour l’œil humain et les imprimantes, et ses fonctionnalités n’ont cessé de s’étendre
    Comme moyen de transmission de données entre machines, il est médiocre, mais il est très bon pour être lu par des humains ou pour enregistrer une page A4
    Si l’on part du principe que, puisque le .pdf stocke du texte, c’est ce texte que l’on veut récupérer, cela revient à dire qu’il suffit d’avoir de meilleurs yeux
    Sinon, il faut gérer quelque chose de très complexe
    Le premier problème est déjà de savoir si ce texte est du vrai texte ou une image
    L’œil humain peut le lire dans tous les cas, quitte à remettre ses lunettes, mais un parseur peut s’effondrer avec des erreurs de segmentation
    Le PDF étant destiné à la lecture humaine, pour lire un PDF il faut imiter un humain

  • J’avais autrefois bricolé un parseur PDF jouet, et j’ai été assez déconcerté en découvrant comment le format fonctionnait
    Quand on y pense, il est d’autant plus étrange que le PDF soit si souvent utilisé pour des usages riches en texte
    Je pense notamment aux factures
    Les systèmes numériques devraient pouvoir extraire facilement les données d’un fichier, tout en les présentant dans un format agréable à lire pour les humains
    Le secteur tech gagnerait beaucoup à passer à un meilleur format

    • XML+XSLT était presque cette solution, mais malheureusement les navigateurs ne le prennent désormais plus en charge pour les fichiers XML locaux, seulement pour les XML servis par un serveur distant