Sortie de Tabula 1.0.1 - Extraction de données tabulaires dans des pdfs

Posté par (page perso) . Édité par Nils Ratusznik, Xavier Claude et palm123. Modéré par Ontologia. Licence CC by-sa
Tags :
42
15
sept.
2015
Base de données

Issu de l'univers du data-journalisme, Tabula est un logiciel permettant d'extraire facilement des données tabulaires issues de fichiers PDF. Il a été développé par des journalistes pour des journalistes. Mais son usage va au-delà de cette profession : étudiants, chercheurs, etc…

Si vous avez déjà essayé de copier-coller des tableaux contenus dans des documents PDF pour les retravailler dans Libre Office par exemple, au format CSV, vous savez à quel point c'est compliqué et chronophage.

Gratuit, Libre (Licence MIT), Tabula fonctionne sous Mac, Windows et Linux. Codé en Ruby, fonctionnant avec la JVM, Tabula est un web-service puissant, disposant de fonctionnalités de détection de tableaux de deux types :

  • soit par détection automatique des espaces entre les colonnes (mode stream) ;
  • soit par détection automatique des caractères de colonnes (mode lattice).

Tabula a été conçu dans un esprit de maîtrise de ses données. À aucun moment vos fichiers ne voyagent sur internet. Si l'utilisation de Tabula se fait via votre navigateur, il fonctionne bien en local.
Tabula peut également être installé sur un LAN.

Limitation : Les créateurs du logiciel précisent que Tabula est conçu pour les pdf texte. Il ne fonctionne pas sur les pdf images (scan).
Toutefois, par expérience personnelle, de bons résultats peuvent cependant être obtenus sur des scans OCRisés de bonne résolution (400DPI), et au format pdf non-compressés.

Le logiciel sort aujourd'hui dans sa version 1.0.1, corrigeant quelques bugs de la version 1.0

Les nouveautés de la version 1.0

  • Nouvelle interface utilisateur ;
  • corrections de bugs ;
  • ajout du mode de détection Lattice ;
  • amélioration de la détection des colonnes non-marquées ;
  • la version OS X embarque désormais sa propre version de la JVM.
  • # C'est trés bon !

    Posté par . Évalué à 7.

    Je l'ai découvert il y a 4 jours, au détour d'un PDF dont je devais extraire des tables.

    Après avoir tenté FreeOCR sur ce PDF etc…. Bref seul Tabula a fonctionné.

    Bel ouvrage ! ;)

  • # Usage et adoption

    Posté par (page perso) . Évalué à 10.

    Tout d'abord, merci au modérateur et aux relecteurs de ma première dépêche! ;)

    J'utilise Tabula tous les jours dans le domaine de la compliance/analyse de relevés bancaires.
    Lorsque Tabula échoue ou génère beaucoup de décalage de colonnes - ce qui arrive sur des pdf de 200 pages scannés et ocrisés - je couple Tabula avec OpenRefine pour redresser plus vite mes tableaux.

    Ce magic combo Tabula/Refine a vraiment boosté ma productivité au quotidien!

    L'équipe de développement fait un boulot assez remarquable.

    J'ajoute que tabula est en faite une interface web à un un moteur en ligne de commande : tabula-extractor, et qui peut être scripté. https://github.com/tabulapdf/tabula-extractor

    Bref, cet outil est merveilleux et je voulais vous faire partager mon enthousiasme à son sujet.

    • [^] # Re: Usage et adoption

      Posté par . Évalué à 4.

      J'ajoute que dans mon cas, les PDFs ont un watermark, certaines tables sont fragmentées sur plusieurs pages.

      Le moteur par défaut n'est pas passé. Le moteur secondaire a trés bien mis en page ces tableaux.

      Bref, que du bon.

      Effectivement il est un peu mou, mais ce n'est pas - dans mon cas - une contrainte :)

  • # Extraordinaire

    Posté par . Évalué à 10.

    Merci beaucoup pour ce programme. Il fonctionne vraiment pas mal.
    Je l'ai testé avec une liste de prix fournisseur, PDF 2,1MB, 77 pages, 760 lignes x 5 colonnes de tableaux.

    • Il est juste un peu lent (7min34 preview + 20sec export CSV), mais ce n'est pas là le plus important pour moi, c'est toujours beaucoup plus rapide que de le faire à la main.
    • Un peu consommateur de ressource. 700MB de RAM pour un pdf de 2,1MB (avec Ruby sur Java c'est normal)
    • L'interface utilisateur est très bien faite et facile. L'auto-détection de tableau a parfaitement fonctionné sur mon test. Il devait y avoir +-300 petits tableaux.
    • L'installation est "plug and play", je redoutais le pire avec Ruby. (expérience passée) Mais le fait qu'il soit packagé dans du Java aide sur ce point.
    • Il n'est pas compatible avec les processeurs multi-coeur (multiprocessing). Je n'en ai qu'un seul thread à 100% avec 4 cores.
    • Il doit y avoir des fuites mémoires, après plusieurs itérations la mémoire RAM augmente. Après 2 itérations et on en est à 780MB de RAM total.
  • # Extraction de données ?

    Posté par (page perso) . Évalué à 2.

    Je suis intéressé sur la manière dont est effectué la détection de tableau dans le pdf, et j'ai beau chercher dans le repo où est chargé le pdf, mais je suis un peu perdu. Je trouve un jar avec les dépendances dans le répertoire jar, mais je ne sais pas où trouver les sources de celui-ci…

    Est-ce que tu peux détailler (vite fait) comment tu extrait le tableau ? Pour ceux qui ne connaissent pas le pdf, le langage ne garantie pas que le texte est présent de manière séquentielle dans le fichier, c'est plutôt :

    • va aux coordonnées X1,Y1; affiche le texte "…"
    • va au coordonnées X2, Y2; affiche le texte "…"

    avec tous les problèmes que cela peut poser (l'espace peut ne pas être représentée etc)

    (Au passage, puisque ça fonctionne dans une jvm, est-ce que vous avez choisi d'utiliser pdfbox ?)

  • # le comble de l'application web

    Posté par . Évalué à 10.

    Alors déjà: c'est un super outil, je le découvre, et aux premiers tests ça marche nickel et ça va me rendre des services, trop cool :-)

    Mais quand même… techniquement… oser faire un exécutable autour d'un jar qui lance une appli web sur 127.0.0.1:8080 et un navigateur, plutôt qu'une bonne vieille appli desktop, c'est-y-pas malheureux… Pourtant au moment de concevoir la pompe à shadoks consistant à lancer le browser. Je déteste les webapps, je suis partisan, mais là c'est un peu le comble…

    C'est pas bien grave, l'important c'est la fonction, et elle est cool.

    • [^] # Re: le comble de l'application web

      Posté par (page perso) . Évalué à 5.

      Ah je ne partage pas ton point de vue, mais alors pas du tout. ;)

      Cette appli est utilisée par 200 personnes chez nous sans que j'aie à gérer un déploiement/mise à jour sur 200 postes. Elle tourne sur un serveur chez nous.

      Ma critique sur ce plan consiste plus à penser que tant qu'à faire une webapp, un petit module de gestion des droits utilisateurs pour créer des espaces privés seraient un plus.

      • [^] # Re: le comble de l'application web

        Posté par . Évalué à 1. Dernière modification le 16/09/15 à 18:49.

        Je n'ai pas compris ce qui te faisait penser qu'un déploiement server-side était exclusif d'une application desktop, mais j'ai quand même plussé ton point de vue.

        Et puis n'importe comment l'appli est super c'est l'essentiel.

    • [^] # Re: le comble de l'application web

      Posté par . Évalué à 7.

      Je ne vois pas vraiment le problème.
      Ce choix permet:

      • d'utiliser HTML/CSS/JS pour la partie graphique, dont la bibliothèque pfd.js
      • de bénéficier d'un runtime largement optimisé (le navigateur), potentiellement lourde.
      • si la GUI par en vrac, le moteur est toujours là, juste à relancer le navigateur.
      • de scripter facilement avec un simple curl (headless) => tu testes ta transformation dans le navigateur puis tu n'as plus qu'à rejouer les commandes dans un script, dans une chaine de production par ex.
      • de déployer l'application sur un ou plusieurs serveurs communs pour :
        • gérer les montées de versions
        • équilibrer la charge vers des machines puissantes (versus un poste utilisateur peut être faiblard)
        • cela n'empêche pas l'installation en local.

      OpenRefine a fait le même choix.

      Finalement, la partie rendu est minime dans cette application, autant ne pas se coupler trop fortement avec la partie graphique et garder un moteur séparé accessible par API.

      En bref ça te hérisse le poil et j'aurai un peu la même tendance (vacciné par le ggleries qui devienne ingérable dans un navigateur car trop compliquées) mais dans ce cas, je trouve que c'est un bon choix.

      • [^] # Re: le comble de l'application web

        Posté par . Évalué à -3. Dernière modification le 18/09/15 à 23:43.

        Je ne vois pas vraiment le problème.

        C'est vrai que lancer deux fenêtres dont une moche en mode terminal et l'autre qui est un onglet du navigateur, c'est à la fois beau, naturel et ergonomique, et ça fait pro. Et puis c'est pas comme si le premier lancement de l'appli c'était la première impression de l'utilisateur non plus. Je ne vois pas le problème t'as raison.

        • [^] # Re: le comble de l'application web

          Posté par (page perso) . Évalué à 8.

          Ça n'est pas une application « grand public » destiné à faire mouiller les copines. C'est un outil pour ceux qui bidouillent les données.
          La partie esthétique ne me semble pas importante (avis perso, rien de plus). De même que mes tournevis ne sont pas anodisés noir avec manche en imitation carbone.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.