Journal Gérer sa paperasse quand on est une feignas^W^W un programmeur

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
59
1
avr.
2012

Tout le monde a déjà eut affaire à une administration, et tout le monde sait qu'ils n'hésitent pas à demander des documents vieux de plus de 3 mois. Sauf que, quand on a une aptitude innée à la désorganisation comme moi, retrouver ces documents peut vite prendre du temps. Je pourrais simplement ranger mes papiers, mais je suis un programmeur, donc il faut que je complique pour simplifier.

L'idée que j'ai eut alors fût de scanner mes documents et de passer un coup d'OCR dessus. Cela permet de les retrouver par mots clefs mais aussi de les sauvegarder rapidement (avec Rsync par exemple). N'ayant pas trouvé de programme satisfaisant, j'avais créé un prototype. Pour l'OCR, j'ai utilisé Tesseract. À ma grande surprise, ça marche plutôt bien :-)

L'année dernière, j'ai commencé à écrire un programme un peu plus propre: Paperwork. Au final, ça donne ça:

Screenshout

Maintenant, il reste une question : Est-ce que ce programme peut intéresser d'autres personnes que moi ?

Liens utiles:
- Le README (contient les instructions pour l'installation)
- Le bug tracker

  • # Docmgr

    Posté par  (site web personnel) . Évalué à 2.

    Je me suis installé un docmgr pour gérer ma paperasse, c'est un peu plus lourd mais ça me permet également d'organiser mes ebooks …

    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

  • # Très intéressant

    Posté par  . Évalué à 5.

    Je me tâte à faire un système similaire depuis longtemps, mais ça disparaît souvent au fond de ma todolist, comme par enchantement.

    C'est le genre de logiciel qui aurait tout son sens pour moi, et sûrement pour beaucoup d'autres gens.

    Si tu cherches des pistes d'amélioration, en voici quelques une en vrac :

    • Chiffrement des fichiers
    • Stockage dans une archive, ou un fichier simple pour faciliter la sauvegarde de ses papiers
    • Ajouts de plusieurs tags et/ou catégories aux documents scannés (un même doc pouvant appartenir à plusieurs catégories)

    Pour le troisième point, tu en parles dans le README, mais j'ai cru comprendre qu'on ne peut mettre qu'un label par fichier, d'où ma suggestion.

    Bravo en tout cas, j'aimerais bien que ton logiciel soit intégré dans le projet Gnome perso !

    • [^] # Re: Très intéressant

      Posté par  (site web personnel) . Évalué à 7.

      • Pour le chiffrement des fichiers, je me tate. Je me demande si ce n'est pas un peu hors-sujet et si un programme dédié ne ferait pas un meilleur travail (personnellement, là, j'utilise encfs). Il faut que j'y réfléchisse. Merci pour la suggestion en tout cas.

      • Pour le stockage dans une archive, il suffit de faire une archive du répertoire de travail, ce qui se fait en 2 clicks dans Nautilus.

      • Pour les tags, j'aurais effectivement dû clarifier: On peut mettre plusieurs tags sur un même document. Je vais mettre à jour le README dès que j'aurais un peu de temps

      • Pour Gnome, moi aussi j'aimerais bien, mais j'en suis sûrement encore loin :-)

      • [^] # Re: Très intéressant

        Posté par  (site web personnel, Mastodon) . Évalué à -1.

        Pour le chiffrement des fichiers, je pense que c'est pas du tout hors sujet. Car à priori, dans ton appli, on y stocke des papiers personnels, voir confidentiels (contrats…).

        Avoir un système de fichier encfs, c'est sympa mais :

        • il faut déjà configurer le truc, pas évident (moi par exemple, je ne sais pas du tout comment faut faire ce truc, et va falloir que je passe du temps à me documenter, à le configurer, à encrypter etc..)
        • ça oblige aussi à chiffrer plein d'autres fichiers (le home ?), ce qui n'est pas forcément utile
        • ça ne résout pas le problème des backups. Parce que cela signifie avoir là aussi des système de fichiers crypté sur tes disques de backups, etc..

        Alors que pour l'utilisateur, si ton soft sait crypter, on lui donne une passphrase et basta. Les fichiers peuvent se trouver n'importe où, même sur un disque où ils n'ont rien à y faire, ce n'est pas un souci.

        • [^] # Re: Très intéressant

          Posté par  (site web personnel) . Évalué à 1.

          Petit bémol quand même, avec des fichiers chiffres, qui sait si dans 5 ans tu te souviendras de ton mot de passe. On ajoute aussi ce risque sur les donnes lorsque l'on chiffre a mon avis. Je ne sais pas au final ce qui est le plus sur pour la pérenité des données.

          Ceci n'est pas une signature

          • [^] # Re: Très intéressant

            Posté par  . Évalué à 2.

            Ça c'est un choix que doit faire l'utilisateur. Si je décide de chiffrer mes données, et que j'oublie mon mot de passe, je ne m'en prendrais qu'à moi-même !

        • [^] # Re: Très intéressant

          Posté par  (site web personnel) . Évalué à 5.

          il faut déjà configurer le truc, pas évident (moi par exemple, je ne sais pas du tout comment faut faire ce truc, et va falloir que je passe du temps à me documenter, à le configurer, à encrypter etc..)

          Deux solutions ultra-simples que j'utilise.

          • Chiffrage de volume : Cryptkeeper qui est une surcouche graphique à encfs. Cela s'utilise très simplement via une applet GNOME.

          • Chiffrage de document. Pour ça j'utilise ccrypt via un user-script Nautilus. Je fais un bête clic droit sur le document je choisis de le chiffrer ou de le déchiffrer. Je pourrai te coller le script si ça t'intéresse.

          En résumé, nul besoin de se prendre la tête pour protéger ses données.

      • [^] # Re: Très intéressant

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Pour Gnome, moi aussi j'aimerais bien, mais j'en suis sûrement encore loin :-)

        Tu peux tenter de discuter sur le canal IRC des designers d'applis Gnome (#gnome-design sur irc.gnome.org) pu des les contacter via ce site avec un oiseau bleu auquel je ne comprends rien. Pour ce que j'en ai vu, ils sont plutôt sympas. Ton appli peut les intéresser dans le cadre du développement de gnome-documents, par exemple.

      • [^] # Re: Très intéressant

        Posté par  . Évalué à 2.

        Dans une logique de séparation des responsabilités, selon moi, ce n'est pas à l'applicatif de gérer le chiffrement (comme la compression).
        Si l'utilisateur veut de la confidentialité, il peut placer les fichiers de l'application sur un volume chiffré.

        D'ailleurs, un peu dans cette même logique, est ce qu'il serait possible de coupler cette application avec un moteur de recherche desktop ? Pour avoir une interface unifié de recherche.

        Clairement, pour moi, la problématique traitée est très intéressante.
        Pour rejoindre certain commentaire, j'ajouterai à la liste de demande:
        - tags, catégories
        - possibilité d'indiquer l'emplacement physique de l'original (banette N, carton X)
        voire:
        - possibilité d'indiquer la confidentialité du document
        possibilité d'indiquer la durée de conservation (à vie, 5 ans, 10 ans) pour proposer un ménage de printemps.

        Merci pour cette initiative en tout cas.

        Dernier point, une idée de la volumétrie de stockage (moi je dois bien avoir 2000 pages A4 de paperasse).

        • [^] # Re: Très intéressant

          Posté par  (site web personnel) . Évalué à 1.

          Pour la logique de séparation des responsabilités: +1 :-)

          Pour ce qui est de coupler l'application avec un moteur de recherche desktop: C'est sûrement possible. C'est même déjà plus ou moins le cas: Paperwork génère des .jpg+.txt. Le .txt sera donc déjà indexé par le moteur. D'après mes souvenirs d'expérimentations d'il y a quelques années, le plus gros problème est en fait de pouvoir ouvrir le jpg correspondant au .txt: les moteurs de recherche desktop, dans leurs listes de résultats, ont la fâcheuse habitude de juste permettre l'ouverture du .txt, et non pas du dossier parent de ce fichier. J'avais juste trouvé Google Desktop qui permettait de le faire …
          Après il y a une autre problématique: Les défauts d'OCR. Paperwork fournit (enfin tente) des suggestions de recherche basées sur les mots effectivement obtenus par l'OCR. Ça permet occasionnellement de rattraper certains glitchs de l'OCR (par exemple, j'ai un document qui a pour mot clef "Flescih" au lieu de "Flesch"). Je ne pense pas qu'un moteur de recherche desktop puisse fournir ces suggestions facilement.

          Pour les tags/catégories: C'est déjà implémenté (c'est appelé 'labels' dans l'application)

          Pour le reste, tel que je vois ça:

          • L'emplacement physique de l'original: les tags peuvent servir pour faire ça.
          • La confidentialité du document: idem, les tags peuvent servir pour faire ça.
          • La durée de conservation / une option pour faire le ménage: Je me sais pas dans quel mesure un ménage de printemps serait pertinent connaissant les capacités de stockage des disques durs actuels. Quand bien même quelqu'un tiendrait à le faire, c'est faisable avec les tags: Les documents sont identifiés (et triés) par leur date de scan. Il suffit donc de les tagger ensuite sur la période qu'on veut les garder. Lorsqu'on veut faire le ménage, on peut alors faire une recherche sur un des tags de durée, et supprimer les documents trop vieux. Par contre il faudrait que j'autorise la sélection de multiples documents simultanément.

          Concernant la volumétrie: J'ai actuellement 792 pages. Elles prennent 859Mo. Quand il démarre, Paperwork met environ 10 à 20 secondes à les indexer sur ma machine (problème qui disparaitra lorsque j'utiliserais Sqlite pour stocker l'index sur le disque).

          • [^] # Re: Très intéressant

            Posté par  . Évalué à 2.

            Par ménage de printemps, j'entendais un ménage dans les papiers, pas dans les données gérées par le logiciel. Histoire de garder une pile de papier raisonnable. Une fois pas an, on demanderai au logiciel quels sont les papiers périmés, et comme on a renseigné leurs emplacements, on peut jeter les documents physiques, quitte à garder les documents numérisés et les marquer comme uniquement virtuel.
            C'était l'idée.

        • [^] # Re: Très intéressant

          Posté par  . Évalué à 2.

          Dans une logique de séparation des responsabilités, selon moi, ce n'est pas à l'applicatif de gérer le chiffrement (comme la compression).
          Si l'utilisateur veut de la confidentialité, il peut placer les fichiers de l'application sur un volume chiffré.

          On peut aussi vouloir un système d'exploitation simple, mono-utilisateur comme Haiku, et gérer la sécurité dans chacune des applications qui le requièrent. Ça permet d'avoir différents niveaux de sécurisation selon le contexte, et une hétérogénéité de verrous qui participe à la sécurité globale du système.

    • [^] # Re: Très intéressant

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 01 avril 2012 à 21:50.

      Ca me permet de faire un peu de pub pour moi même, mais MALODOS que j'avais présenté ici même permet d'ajouter plusieurs tags et / ou plusieurs dossiers virtuels à chaque documents. La sécurisation (chiffrement et toussa) fait parti des projets à venir.

      Il permet également de créer une archive avec une sélection quelconque de documents.

      a++

      Ceci n'est pas une signature

  • # Mémoire de poisson

    Posté par  (site web personnel) . Évalué à 6.

    Je n'ai pas assez de paperasse pour être concerné, mais j'ai le souvenir d'avoir déjà vu un programme faire la même chose sur linusquefr. En tout cas, il y a de la demande !

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Peut-être ajouter la gestion de pdf ?

    Posté par  (site web personnel) . Évalué à 3.

    Bon, je viens de voir qu'il y a déjà un ticket d'ouvert.

    On y gagnerait pas mal pour l'indexation grâce à pdftotext. Pis surtout, mes factures sont toutes en pdf maintenant !

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: Peut-être ajouter la gestion de pdf ?

      Posté par  (site web personnel) . Évalué à 3.

      J'avais parlé de ce programme à un collègue, et c'est lui qui m'a poussé à faire le ticket. J'étais septique quant à l'utilité de la chose, mais visiblement il y a de la demande, donc je ne vais pas y couper … :)

      • [^] # Re: Peut-être ajouter la gestion de pdf ?

        Posté par  . Évalué à 3.

        Ca vaut le coup d'y inclure aussi les documents ODF ?

        (Pour répondre à ta question, oui ça m'intéresse aussi :-))

      • [^] # Re: Peut-être ajouter la gestion de pdf ?

        Posté par  . Évalué à 4.

        en fait le format pdf est trop utile pour pouvoir imprimer rapidement et sans se prendre la tête au format A4 (tous les visualiseurs d'image ne gérant par forcément très bien l'impression sur A4).

        Il existe par ailleurs le logiciel pdfsandwich qui permet de transformer un pdf contenant une image scannée, en pdf avec l'image + le résultat OCRisé, ça semble pratique mais pour le moment mes rapides tests ne sont pas concluant, il faut sans doute stocker l'image aux traits en 300dpi, par exemple en niveaux de gris et 200 dpi, ce n'est pas suffisant pour un bon résultat.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Peut-être ajouter la gestion de pdf ?

          Posté par  . Évalué à 2.

          je me réponds (confirme) à moi-même : ça fonctionne bien avec pdfsandwich, pour peu que l'on définisse bien en niveau de gris et en 300 dpi. Ensuite, pour un document français, indiquez :

          pdfsandwich -lang fra document.pdf

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: Peut-être ajouter la gestion de pdf ?

            Posté par  . Évalué à 3.

            grr, correction, je voulais dire en n&b 2 couleurs (au trait), pas en niveau de gris justement.

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # OCR avec cuneiform

    Posté par  . Évalué à 2.

    J'ai découvert il y a peu le logiciel cuneiform qui pour la première fois m'a permis d'utiliser l'OCR sous linux. Je te conseille donc de tester.

    • [^] # Re: OCR avec cuneiform

      Posté par  (site web personnel) . Évalué à 2.

      Merci du conseil. J'avais manqué Cuneiform quand j'avais fait mon tour des OCR libres. Il a l'air très efficace. Je me suis créé un ticket à ce sujet.

    • [^] # Re: OCR avec cuneiform

      Posté par  . Évalué à 2.

      Ces deux OCR (tesseract et cuneiform) gèrent les caractères latins avec diacritiques voire ceux des autres systèmes d'écriture ?

      • [^] # Re: OCR avec cuneiform

        Posté par  (site web personnel) . Évalué à 3.

        Tesseract oui. Enfin plus ou moins bien (il confond régulièrement "é" et "'e"). Pour Cuneiform je n'ai pas encore regardé.

        Toutefois, pour améliorer un peu la recherche et les suggestions, Paperwork retire les accents des mots clefs. Du coup, ça a relativement peu d'importance.

        (et oui, je sais, cette astuce ne marche probablement qu'avec le français et l'anglais, et il faudra sûrement que je m'en passe pour les autres langues. Mais bon, en attendant …)

  • # Moi

    Posté par  . Évalué à 2.

    Moi, ca m'intéresse.
    Sous quel(s) format(s) est/sont stocké(s) les fichiers ?
    Est-ce que l'on peut obtenir des PDF "searcheable", c'est à dire avec 2 couches : une contenant l'image scannée et l'autre (caché) le texte issu de l'ocr ?
    http://tfischernet.wordpress.com/2008/11/26/searchable-pdfs-with-linux/
    http://blog.konradvoelkel.de/2010/01/linux-ocr-and-pdf-problem-solved/

    • [^] # Re: Moi

      Posté par  (site web personnel) . Évalué à 3.

      Chaque document est un répertoire dans le répertoire de travail.
      Chaque page d'un document est stockée sous forme de 3 fichiers:

      • un .jpg
      • un .txt : le resultat de l'OCR
      • un .word (hOCR) : pour avoir la position de chaque mot dans la page

      J'aurais pu me contenter d'un .jpg + .word vu que le .word contient aussi les mots clefs du .txt. Cependant, actuellement, Paperwork indexe tout les documents quand il démarre, et les fichiers hOCR sont trop longs à parser. Donc pour maintenir un démarrage en un temps décent, je garde aussi les .txt. (J'ai déjà un ticket plus ou moins en rapport avec ça: https://github.com/jflesch/paperwork/issues/20 ).

      Pour ce qui est des PDF, actuellement, non. Mais je suppose que c'est une fonctionnalité qui pourrait être pratique. Merci pour la suggestion. Je me suis la suis noté dans un ticket: https://github.com/jflesch/paperwork/issues/44

  • # dependances

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 01 avril 2012 à 23:27.

    une dépendance que j'ai du installer et qui n'est pas décrite : pycountry
    Un simple pip install pycountry a suffit, mais c'est éventuellement à ajouter à la liste des dépendances

    EDIT: désolé j'avais mal lu ton README , on peux effacer un commentaire?

    Ceci n'est pas une signature

    • [^] # Re: dependances

      Posté par  . Évalué à 1.

      à ceci s'ajoute :
      Traceback (most recent call last):
      File "/usr/bin/paperwork", line 3, in
      from paperwork.paperwork import main
      File "/usr/lib/python3.2/site-packages/paperwork/paperwork.py", line 39
      print "Looking for locales in '%s' …" % (fr_locale_path)
      ^
      SyntaxError: invalid syntax

      => marche pas avec python3… (c'est le python par defaut sur mon pc je viens de le découvrir )

      et avec python2 ça donne :
      Traceback (most recent call last):
      File "/usr/bin/paperwork", line 3, in
      from paperwork.paperwork import main
      File "/usr/lib/python2.7/site-packages/paperwork/paperwork.py", line 16, in
      from controller.mainwindow import MainWindow
      File "/usr/lib/python2.7/site-packages/paperwork/controller/mainwindow.py", line 13, in
      from paperwork.controller.multiscan import MultiscanDialog
      File "/usr/lib/python2.7/site-packages/paperwork/controller/multiscan.py", line 8, in
      from paperwork.model.doc import ScannedDoc
      File "/usr/lib/python2.7/site-packages/paperwork/model/doc.py", line 12, in
      from paperwork.model.page import ScannedPage
      File "/usr/lib/python2.7/site-packages/paperwork/model/page.py", line 13, in
      import tesseract
      ImportError: No module named tesseract

      et je viens de passer 2h à tenter d'installer le module python pour tesseract mais comme je suis nul en python, ben j'ai pas réussi ^

      et il n'y à pas de paquet Archlinux pour python-tesseract. Je verrais demain si je fait un rapport de bug (car je ne sais pas si c'est un bug ou bien un problème de moiquiesnulenpython).

      bonne nuit!

      • [^] # Re: dependances

        Posté par  (site web personnel) . Évalué à 2.

        Pour la version de Python, il faut que je creuse. Je pensais avoir fait le nécessaire pour forcer l'utilisation de Python 2. Visiblement j'ai raté quelque-chose.

        Pour python-tesseract, il n'y a pas de paquet, dans aucune distribution. Les instructions pour l'installer sont dans le README de Paperwork dans la section "Dependencies".

      • [^] # Re: dependances

        Posté par  (site web personnel) . Évalué à 1.

        J'ai réussi à installer les dépendances sans problème pour que ca fonctionne sur achlinux

        Les paquets que j'ai installé avec pacman sont python-imaging python2-pycountry python-imaging tesseract pygtk.
        Pour python-tesseract, j'ai utilisé le dépôt git indiqué dans le readme.

        Je ne sais plus si j'ai fait l'installation avec python2 ou python3 ensuite, mais ça tourne parfaitement.

        • [^] # Re: dependances

          Posté par  . Évalué à 1.

          pareil, python 2 et 3, je force python2 dans /usr/bin/paperwork , si je ne le fait pas, ça fait un syntax error.

          j'ai les mêmes paquets dans archlinux.

          et maintenant, l'installation du module python se passe bien, mais quand je lance paperwork :
          Traceback (most recent call last):
          File "/usr/bin/paperwork", line 6, in
          main()
          File "/usr/lib/python2.7/site-packages/paperwork/paperwork.py", line 57, in main
          mainwin = MainWindow(config)
          File "/usr/lib/python2.7/site-packages/paperwork/controller/mainwindow.py", line 545, in __init          _
          self.updatescanner_settings()
          File "/usr/lib/python2.7/site-packages/paperwork/controller/mainwindow.py", line 609, in update_scanner_settings
          self.          device.selected_device = self._config.scanner_devid
          File "/usr/lib/python2.7/site-packages/paperwork/model/scanner.py", line 234, in __set_selected_device
          elif not tesseract.is_tesseract_available():
          AttributeError: 'module' object has no attribute 'is_tesseract_available'

          j'ai désinstallé et re-téléchargé paperwork, re-installé mais même sanction.

          séparément, tesseract et les scanners marchent bien. mais ce module python, veux rien savoir…

          le seul truc pas standard sur mon archlinux est une ancienne libusb-compat pour permettre à scanbuttond de détecter le scanner usb, ce serait la source du problème ?

          enfin bref, j'attendrais un paquet propre pour archlinux, car à la main, je ne peux dépatouiller le problème à cause de mon manque de compétences en python ^

          • [^] # Re: dependances

            Posté par  (site web personnel) . Évalué à 1.

            Curieusement, on dirait que tu as un module Python Tesseract installé, mais pas le bon.

            Dans le cas où tu aurais juste installé le mauvais module python-tesseract, voici ce que je te suggère de faire:

            • sudo rm -f $(find /usr/lib/python2.7/dist-packages /usr/local/lib/python2.7/dist-packages -name tesseract.py*)
            • Puis suivre à nouveau la méthode dans le README de Paperwork pour installer python-tesseract.

            Le rm -f est un peu violent, mais ça aura le mérite de résoudre ton problème.

            • [^] # Re: dependances

              Posté par  . Évalué à 2.

              Merci! \o/ c'est violement efficace! \o/ Et ça marche! \o/

              Et j'ai 7Kg paperasse à numériser /o\ ….

              Idée d'ammélioration :

              j'ai 2 scanners, je peux numériser 2 fichiers à la fois et remplir un dossier de fichiers au format tif (j'en parle ici : https://linuxfr.org/users/yao_kuramoto/journaux/telecommande-scan-to-pc-pour-imprimante-hplip )

              Il serait bien de pouvoir importer tout les fichiers de ce dossier d'un coup. (quitte à faire du tif2jpeg)

              Comme ça , pour ceux comme moi qui on un gros historique 7Kg, on peux faire une session de numérisation (par exemple dans les bons jours, 10 feuilles/jours) et une session d'import dans Paperwork.

              Ceci dit, merci pour ton travail et pour l'aide :-)

              • [^] # Re: dependances

                Posté par  (site web personnel) . Évalué à 1.

                Le problème, c'est que je doute qu'il y ait 2 personnes pour organiser le dossier à importer de la même façon. Donc ça va faire une option compliquée à utiliser, qu'il va donc falloir longuement documenter (et tout le monde sait que les utilisateurs ne lisent pas la doc :).

                Par contre, ton cas devrait pouvoir se scripter assez facilement. Tout ce qu'il faut, c'est que tu obtiennes un répertoire de travail contenant:

                • Un dossier par document, ayant de préférence pour nom une date au format "YYYYMMDD_HHmm_ss". Ce n'est pas strictement nécessaire : Paperwork doit fonctionner même si les noms des dossiers ont un autre format (il les affichera alors tel quel).
                • Dans chaque dossier, pour chaque page, il faut un .jpg et un .txt:
                  • "paper.[page].jpg": tu peux l'obtenir facilement avec "convert" (qui fait partie de "imagemagick" de mémoire)
                  • "paper.[page].txt": un coup de tesseract sur le jpg, et hop: tesseract paper.[page].jpg paper.[page] -l fra
                  • "paper.[page].words": Le fichier .words est optionnel. Je crois que les commandes suivantes devrait pouvoir le générer: tesseract paper.[page].jpg paper.[page] -l fra hocr

                • [^] # Re: dependances

                  Posté par  . Évalué à 2.

                  Merci \o/

                  ça donne ça :

                  #!/bin/sh

_PAPERS='/mondossier_de_papers'
_SCANS='/mondossier_de_Scans'

for _FILE in `ls ${_SCANS}` ; do

    #variabilisation des esprits
    _FILENAME="$_SCANS/$_FILE"
    _BASENAME=`echo ${_FILE} | xargs -I"{}" basename {} .tif`
    _JPGFILE="$_PAPERS/$_BASENAME/paper.$_BASENAME.jpg"
    _TESSRESULTFILE="$_PAPERS/$_BASENAME/paper.$_BASENAME"

        # creation du dossier de destination
    mkdir $_PAPERS/$_BASENAME

    #convertion de tiff en jpeg
    tifftopnm $_FILENAME | pnmtojpeg > $_JPGFILE

    # OCR
    tesseract $_JPGFILE $_TESSRESULTFILE -l fra
    tesseract $_JPGFILE $_TESSRESULTFILE -l fra hocr

        # peut etre deplacer les tiff deja scannes dans un autre dossier ?
        # a voir pour plus tard....
done

                  • [^] # Re: dependances

                    Posté par  (site web personnel) . Évalué à 1.

                    Zut, j'avais oublié de préciser: tesseract [img] [result] -l fra hocr génère un [result].html qu'il faut en fait renommer en [result].words pour que paperwork le prenne en compte. Désolé pour cette omission.

                    • [^] # Re: dependances

                      Posté par  . Évalué à 1.

                      voici :

                      #!/bin/sh

echo "environnement"
_PAPERS='/home/cedric/papers'
_SCANS='/home/cedric/Scans'

echo "boucle"
for _FILE in `ls ${_SCANS}` ; do

    # conversion du nom
    _FILENAME="$_SCANS/$_FILE"
    _BASENAME=`echo ${_FILE} | xargs -I"{}" basename {} .tif`
    _JPGFILE="$_PAPERS/$_BASENAME/paper.1.jpg"
    _TESSRESULTFILE="$_PAPERS/$_BASENAME/paper.1"

        # creation du dossier de destination
    mkdir $_PAPERS/$_BASENAME

    # convertion de tiff en jpeg
    tifftopnm $_FILENAME | pnmtojpeg > $_JPGFILE

    # OCR
    tesseract $_JPGFILE $_TESSRESULTFILE -l fra
    tesseract $_JPGFILE $_TESSRESULTFILE -l fra hocr
    mv $_TESSRESULTFILE.html $_TESSRESULTFILE.words

done

                      et là Paperwork vois bien les imports. bon, c'est un début mais il me sert bien :-)

                      Mon script /etc/scanbuttond/buttonpressed.sh est modifié comme suit :

                      […]

                      echo "button 1 has been pressed on $2"
    PLUSTEK=`scanimage -L | grep plustek | awk -Fplustek '{ print $2 }' | awk -F\' '{ print $1 }'` ; echo plustek$PLUSTEK
    scanimage -d plustek$PLUSTEK -x 215 -y 297 --mode Color --resolution 300 --format=tiff >~/Scans/`date +%Y%m%d_%H%M_%S.tif` &
    sleep 5
    scanimage -d hpaio:/net/Photosmart_C4380_series?ip=192.168.0.1 --mode Color --resolution 300 --format=tiff >~/Scans/`date +%Y%m%d_%H%M_%S.tif` &

                      […]

                      Ceci pour préparer le travail du script d'import. Il est possible de faire une sortie directe au format pnm ce qui facilite la convertion future en jpeg…

  • # Lecture recommandée

    Posté par  (site web personnel) . Évalué à 2.

    Pour aller (vraiment) plus loin, je conseille la lecture de Your life uploaded.

  • # Journal Gérer sa paperasse quand on est une feignas^W^W un programmeur

    Posté par  . Évalué à 5.

    chouette, moi qui avait commencer il y a 5 ans a tous faire en PDF, dommage mais l administration sont incapable d'insérer une clés USB dans un port USB, il leur faut du papiers. ou est passer la dé-matérialisation de document? dans la poubelle du bureau. ;)

    Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

  • # Le stockage

    Posté par  (site web personnel) . Évalué à 1.

    Intéressant comme projet.
    Un truc qui pourrait être pas mal : pouvoir stocker les fichiers sur un espace type Dropbox, HubiC…

    Mise en situation :
    Martin entre dans le bâtiment de la CAF, prends un ticket et patiente gentillement. C'est son tour.
    Martin : "Bonjour, je vous apporte les papiers pour mon dossier d'assistance à vivre… pardon d'aide social".
    Préposé CAF : "Bonjour, on va regarder si il est complet… Ah bah non il vous manque le justificatif d'impôt de l'année 2000 pour le formulaire rose 42"
    Martin : "Ah… Vous avez un e-mail ?"
    Préposé CAF : "un quoi ????"
    Martin : "un e - m a i l"
    Préposé CAF : "Ahhhhh un mel !"
    Martin : "Oui si vous voulez…"
    Préposé CAF : "Alors c'est, attendez je l'ai noté quelque part, 047298457895… Oh pardon c'est le FAX"

    Une fois le mel obtenue M. Martin en bon geek moderne sort son smartphone dernière génération, lance PaperWork for Android fait ça petite recherche et dans les 3mn le dossier est complet. Il peut continuer à vivre sous assistance.

    Toute ressemblance avec une personne ou service public est involontaire ;)

    Born to Kill EndUser !

    • [^] # Re: Le stockage

      Posté par  (site web personnel) . Évalué à 3.

      En fait l'idée m'avait déjà traversé l'esprit, mais c'est très très loin sur la roadmap ça :/

    • [^] # Re: Le stockage

      Posté par  . Évalué à 1.

      j'ai un serveur web perso avec davfs, avec un :

      mount -t davfs http://monserveur.mondomaine.perso/mondossier /monpointdemontage

      je peux y stocker mes docs et les rapatrier à la demande. C'est sur que c'est du cloudeartisanalàmoiquej'ai mais ça marche. Sauf qu'en pratique il se pose le problème du débit…

      Uploader quelques de docs depuis un adsl à 1Mbps (en upload, et oui même en ile de france ça existe) c'est lent..

      les rapatrier depuis une connection 3G/HDSPA à … 256Kbs c'est lent…. sans parler du quota de données qui au mieux est de 3Gb (chez libremobile).

      Pour le problème du fonctionnaire/contractuel incompétent, je n'ai pas de soluce technique (peut-être un upgrade de firmware de la personne en question mais je n'ose imaginer ou brancher le cable de connection Oo)

      • [^] # Re: Le stockage

        Posté par  (site web personnel) . Évalué à 1.

        Je le fais déjà depuis mon serveur mais faire la même chose depuis un smartphone c'est un poil plus compliqué.

        Born to Kill EndUser !

    • [^] # Re: Le stockage

      Posté par  . Évalué à 1.

      Préposé CAF : "Ah mais, mon bon monsieur, il me faut les originaux. Sans les originaux, je ne peux rien faire."

      • [^] # CAF

        Posté par  . Évalué à 1.

        Véridique?
        Si tu fais tout par courrier, quel originaux doit-on fournir?

    • [^] # Re: Le stockage

      Posté par  . Évalué à 2.

      Je trouve la possibilité, intéressante.
      Comme je l'écrivais plus haut, je ne pense pas que ce soit à l'application de proposer des fonctions avancées de stockage.
      Par contre, un stockage distant à la webdav implique de modifier peu de petits fichier plutôt qu'un gros fichier ce qui induit des contraintes sur l'application.
      Dropbox n'est pas au niveau bloc lui ? ça ne résoudrai peut être pas le problème d'un fichier de base de données, car beaucoup de blocs peuvent être modifiés pour peu de modification du point de vue de l'utilisateur.

  • # Mon programme à moi

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 02 avril 2012 à 11:19.

    Salut collègue,

    Quand je vivais seul (et que je n'avais pas une copine disposant d'un OCR naturel tout-à-fait performant pour classer les documents dans des chemises en papier), je laissais tous ces papiers s'accumuler dans une sorte de pile quelque part dans l'appart et j'attendais les rappels successifs des différents organismes. Lorsque le dernier rappel me menaçait de couper l'eau courante et (plus grave, car internet !) l'électricité, ça me motivait assez pour passer une heure à rechercher les documents afférents dans la pile (qu'il fallait d'abord localiser au milieu d'autres piles), tout cela contrevenant de façon assez pathétique avec le principe du programmeur paresseux.
    J'aurais bien voulu alors disposer d'un tel logiciel :)

  • # fedora

    Posté par  . Évalué à 1.

    Ça a l'air intéressant. Malheureusement, pas de python-tesseract sur les dépots de fedora. J'ai tente de récupérer le module via le dépôt git mais pas de libuilib sur fedora.

    Donc je repasserai. Peut être avec Fedora 17.

    • [^] # Re: fedora

      Posté par  (site web personnel) . Évalué à 2.

      Euh, libuilib ? Je pense que tu as essayé d'installer le mauvais python-tesseract :)

      C'est un peu fourbe: le python-tesseract que j'utilise est en fait le mien et est en pur Python.

      Pour la petite histoire, il est en basé sur le dépot de hoffstaetter/python-tesseract, qui a été repris par jbochi/python-tesseract qui me l'a ensuite refilé .. Sauf qu'il n'a pas supprimé son dépôt. Donc, faute d'avoir autant de watchers que le sien, il n'apparaît pas dans les recherches Github. Ceci dit, si j'implémente le support pour Cuneiform, il faudra que je le renomme, ce qui devrait régler ce problème.

  • # Très interressant

    Posté par  . Évalué à 2.

    Je suis un peu comme toi, j'aime scanner quelques documents afin de les retrouver en 2sec via une recherche indexée.

    Je testerai avec plaisir Paperwork dès que possible.
    Merci pour ton chouette boulot :)

    • [^] # Re: Très interressant

      Posté par  . Évalué à 1.

      Le top, ca serait qu'il reconnaisse automatiquement le type de document (facture EDF, CAF, …) pour en extraire les infos pertinentes (la date de reglement, le montant, …).

      Quelqu'un a une idée de comment s'y prendre ?

  • # Saine émulation

    Posté par  (site web personnel) . Évalué à 4.

    Ayant présenté Médoc il y a quelques temps, je suis ravi de voir d'autres approches pour résoudre le problème de la paperasse qui s'accumule. Ton logiciel m'a l'air beaucoup plus intégré, ce qui est un plus: Médoc reste particulièrement crampon à installer.

    De manière générale, je trouve l'OCR plutôt moins utile que les tags, parce que typiquement je cherche la "facture EDF d'il y a 2 ou 3 mois", plutôt que des mots spécifiques au document, mais c'est peut-être ma manière de chercher.

    J'ai aussi pas mal creusé du côté des formats, et je trouve le PDF assez nul, au final. Je suis tout à fait satisfait de mes bons vieux JPEG, qui au moins sont triviaux à lire. Puis-je te demander quel format tu utilises pour tes documents?

    • [^] # Re: Saine émulation

      Posté par  (site web personnel) . Évalué à 2.

      Pour la recherche, si tu taggues les documents systématiquement avec un label "type" et un label "mois+année", tu vas vite te retrouver avec plein de labels. Ce n'est pas vraiment un problème, mais je trouve ça un peu inutile : Le but de Paperwork est justement de pouvoir flemmarder : Tu mets la feuille dans le scanner, tu clicks scan, et ensuite tu peux l'empiler avec les autres :)
      Personnellement, je maintiens les labels au strict minimum. Et si je cherche "edf facture février 2012", j'ai immédiatement mon dernier échéancier EDF qui apparait, même si il n'y a aucun label dessus.

      Concernant le format, les pages sont gardées sous forme de 3 fichiers:

      • un JPG
      • un fichier .txt contenant les mots clefs
      • un fichier .word (hOCR simplifié) pour pouvoir replacer les mots sur les pages

      J'ai choisi le format JPG pour rester aussi proche que possible de la sortie du scanner (ceci dit, le JPG reste un compromis). De cette manière, au besoin, il est aussi possible de rééditer les documents après scan (rajouter des mots clefs dans le .txt, masquer des choses compromettantes dans les .jpg, etc).

  • # Flemmard

    Posté par  (site web personnel) . Évalué à 2.

    Je trouve que ce projet est une bonne idée.

    Mais mon problème c'est que j'ai la flemme de scanner ces documents, je préfère les classer à la main.

    Prochainement, je vous proposerai peut-être un commentaire constructif.

    • [^] # Re: Flemmard

      Posté par  . Évalué à 2.

      Moi, c'est la liste des dépendances à installer à la main qui me freine…

    • [^] # Re: Flemmard

      Posté par  . Évalué à 2.

      Moi c'est mon backlog de 10 ans qui me freine.

  • # Pareil

    Posté par  . Évalué à 2.

    Je suis très intéressé car j'aime avoir tout en numérique (plus facile a sauvegarder/transporter/a dupliquer).
    Mon système, c'était un scanner qui sauvegarde automatiquement un pdf dans un repertoire partagé sur mon PC via samba. Pas d'OCR par contre dessus.
    Ce qui serait pas mal, c'est qu'a partir de ce pdf, ton logiciel l'OCRise pour pouvoir le conserver dans les archives de PaperWork.

    En tout cas, super projet ;)

  • # Chargeur de documents et archivage physique

    Posté par  . Évalué à 3. Dernière modification le 03 avril 2012 à 21:00.

    Salut,

    Quelques petites questions :

    1. Est-ce que le logiciel gère les scanners avec chargeur de documents (pour scanner plusieurs pages / documents d'un coup) ?
    2. Comment procèdes-tu pour garder le lien entre doc scanné endroit où est le doc physique (pour les documents genre fiche de paie où il faut garder les originaux ?
    3. Peut-on choisir la date du document ? La date du jour va bien pour scanner un truc que tu viens de recevoir, mais si tu veux scanner tes archives c'est moins évident

    • [^] # Re: Chargeur de documents et archivage physique

      Posté par  (site web personnel) . Évalué à 1.

      1. Oui. Un dialogue a d'ailleurs été prévu pour pouvoir scanner plusieurs documents d'un coup (il faut que je le peaufine un peu par contre).
      2. Ça reste à la charge de l'utilisateur. Il peut s'aider du système de label si il le souhaite. Personnellement j'ai très rarement besoin des originaux, donc si je dois de nouveau fouiller dans les piles de papiers à ces moments là, ça n'est pas bien gênant.
      3. Il n'y a rien dans Paperwork même prévu à cette fin. Il est cependant possible de simplement renommer le répertoire du document à la main. Toutefois, tel que je vois ça, la date du scan sert surtout à identifier le document de manière unique. Les mots clefs dans le document sont généralement suffisants pour le retrouver. Personnellement j'ai plein de documents scannés en 2011 qui datent en fait de 2010, et ça ne m'a jamais gêné pour les retrouver.

      • [^] # Re: Chargeur de documents et archivage physique

        Posté par  . Évalué à 3.

        Toutefois, tel que je vois ça, la date du scan sert surtout à identifier le document de manière unique. Les mots clefs dans le document sont généralement suffisants pour le retrouver. Personnellement j'ai plein de documents scannés en 2011 qui datent en fait de 2010, et ça ne m'a jamais gêné pour les retrouver.

        En fait, ma problématique est de vérifier qu'il ne manque pas un document d'une série de documents périodiques (genre le bulletin de paie d'un mois). Classer les docs répondant aux critères qui vont bien par date me semblait une bonne idée pour faire ça

Suivre le flux des commentaires

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