Jérôme Flesch a écrit 390 commentaires

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).

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.

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.

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

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.

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).

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".

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 …)

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

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.

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.

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

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 … :)

• 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 :-)

Vous l'avez rêvé, je l'ai commencé :
http://jflesch.kwain.net/node/495

Par contre comme je suis une grosse feignasse qui fait semblant d'être over-booké, je l'ai pas encore fini.