Jérôme Flesch a écrit 390 commentaires

Je serais plus que content d'utiliser le format DjVu pour les scans au lieu de ma bouillabaisse à base de JPEG+hOCR.
Le problème, c'est qu'à l'heure actuelle, à ma connaissance, il n'y aucune libraire C ou Python libre pour générer des fichiers DjVu.

La dernière fois que j'ai regardé, DjvuLibre ne proposait qu'une librairie pour la lecture de fichiers DjVu, et des outils en ligne de commande pour leur génération. Je dois déjà faire des fork()+exec() pour Tesseract, et ça m'embête déjà bien. Je refuse de faire des fork()+exec() pour générer les fichiers DjVu.

Ayant moi-même une Brother MFC (pour tester Paperwork principalement), pour ma part, j'aurais plutôt tendance à les déconseiller. Même si ça semble être du très bon matériel, logiciellement ça pêche :

• En fonction de la distribution, l'installateur et les pilotes Brother marchent plus ou moins bien: Pas de problème avec Ubuntu Gnome 16.10, mais je n'ai pas réussi à les faire marcher sur Debian sid.
• Sauf erreur de ma part, les drivers Brother sont entièrement propriétaires. Pour l'instant ils fonctionnent, mais le jour où Brother en aura marre de les maintenir, ça va devenir de plus en plus compliqué de les utiliser avec une distribution à jour. Jusqu'au moment où ce ne sera plus possible, et la seule option sera de racheter une imprimante …

Pour info, le nom du paquet manquant ici, dans Debian/Ubuntu, c'est gir1.2-poppler-0.18.
Gnome a introduit les GIR (GObject Introspection Repositories) pour pouvoir générer automatiquement les bindings pour chaque langage à la volée, rendant les paquets comme python-poppler obsolètes.

Si un utilisateur de Mageia aurait le temps de compléter paperwork-shell avec les listes de paquets Mageia, ça serait cool :
https://github.com/jflesch/paperwork-backend/blob/unstable/src/paperwork/backend/shell_cmd.py#L22
https://github.com/jflesch/paperwork-backend/blob/unstable/src/paperwork/backend/deps.py
https://github.com/jflesch/paperwork/blob/unstable/src/paperwork/deps.py

Personnellement, j'ai une préférence pour les scanners/imprimantes HP. Matériellement ils sont moyens. Les drivers sont acceptables mais sans plus. Mais HP fournit des pilotes Linux open-source, donc tu branches en USB et ça marche.
Il y a juste parfois un apt install hplip à faire. Au pire, si le matériel est trop récent, il faut faire une installation manuelle pas-hyper-compliquée des pilotes HP.

À ma connaissance ils font systématiquement des pilotes Linux open-source, mais je ne suis pas 100% certain.

Paperwork considère que 1 PDF = 1 document. Et paperwork a pour principe de ne jamais modifier les PDFs qu'on lui donne.

Sinon, il est possible d'importer des images (1 image = 1 page). Mais dans ce cas, Paperwork ne permet d'importer qu'une seule image à la fois pour le moment.

Actuellement, ce n'est donc malheureusement pas possible tel quel. Dans ton cas, je pense que le plus simple serait de scripter la fusion des pages recto avec les pages verso en utilisant des outils en ligne de commande. Bon ok, pour l'aspect intuitif et user-friendly, on repassera …

Les contributeurs et moi-même avons essayé de faire un logiciel aussi intuitif que possible. Pour moi, l'interface est très claire et explicite (sinon je ne l'aurais pas fait comme ça ;). Du coup je ne suis pas trop sûr de ce qui devrait être documenté ("tout" diraient certains, mais je manque de temps, et maintenir une doc détaillée à jour est un poids en plus non négligeable).

Je te propose de prendre le problème dans l'autre sens : Qu'est-ce qui ne te semble pas clair ? / Qu'est-ce que tu essayes de faire avec ?

Ton outil deviendrait indispensable pour lire les documents.

Il me semble que sqlite3 peut être utilisé avec des scripts shell sans problème. Je ne suis donc pas convaincu que ce soit un problème.

Ce qui me gêne déjà un peu plus, c'est la synchro avec des outils comme SparkleShare ou OwnCloud .. Je présents qu'ils vont re-uploader toute la BDD sqlite à chaque modification. Sur ma connexion ADSL moisie à 200ko/s / 75ko/s max, ça va piquer :/

Je n’ai pas tenté d’importer ainsi des PDF en même temps que Paperwork fonctionne. Je pense que Paperwork n’apprécierait pas…

En fait, il ne le verra juste pas jusqu'à son prochain démarrage. Quand il redémarrera, il le verra au moment où il parcours le répertoire de travail pour trouver les changements.
Je pense que le seul risque, c'est une collision de nom quand Paperwork tente d'ajouter un document. Mais vu qu'il y a les secondes dans les noms de fichiers, ça me semble très improbable.

Du temps de Paperwork 0.2, plusieurs s'y sont essayés et ont abandonné. Au final, seul PyOCR a été packagé, mais la version dans Debian est maintenant complètement obsolète :(

Le problème vient surtout des dépendances. Même si ça été simplifié depuis la 0.2, il faudrait quand même packager:

• Paperwork-backend
• Pyinsane 2
• Pyocr à jour
• libpillowfight

Ce sont des modules Python tout ce qu'il y a de classique, donc je suppose qu'une fois le premier fait, les autres sont faciles à faire.

J'ai failli oublier:

• on ne peut importer qu'un fichier a la fois ?

Une image (JPG, PNG, etc) à la fois oui. Sinon c'est compliqué de deviner où la placer.

Par contre, pour les PDFs, c'est déjà possible. Il suffit d'indiquer à Paperwork un dossier contenant plusieurs PDFs. Il va le parcourir (récursivement si ma mémoire est bonne), et importer chaque PDF comme un document distinct.

• open directory plnate le docker: sh: 1: xdg-open: not found

Euh, xdg-open fait partie des normes freedesktop à ma connaissance. Il faudrait l'inclure dans l'image Docker en fait.
Quoiqu'il en soit, ce sera résolu dans la version 1.0.3. Au lieu de xdg-open, cette version utilisera Gtk.show_uri() qui semble bien plus fiable.

• quand tu fais une recherche par mot-cle, comment faire pour voir l'endroit du document qui contient ce mot-cle ?

Tu cliques sur le document .. :-)
Plus sérieusement:
- quand les pages sont affichées en grille, celles qui contiennent un des mots clés sont entourées en vert.
- quand elles sont affichées en liste (en grand), les mots clés eux-mêmes sont entourés en vert.

Par contre, ça met quelques secondes à s'afficher.
(et en terme de clarté d'affichage, j'ai encore du travail ..)

L'organisation du répertoire de travail est documentée ici:
https://github.com/jflesch/paperwork/wiki/Work-directory-organization

L'organisation des fichiers est effectivement spécifique à Paperwork. Mais les formats des fichiers sont tous standards (JPEG, hOCR, CSV et PDF), et je pense pouvoir dire que cette organisation se prête bien au scripting shell.

Ceci dit, pour bien plus tard, il y a quelques évolutions possibles envisagées pour les documents scannés :

• Zipper les fichiers d'un même document ensemble. Je me dis que ça pourrais économiser un peu les inodes et les blocs disques partiellement utilisées. À voir si ça serait vraiment utile.
• Utiliser le format DjVu. Là le problème, c'est qu'il y a djvulibre pour lire les fichiers DjVu, mais il n'y a aucune librarie C/C++/Python pour en créer (attention, je ne parle pas de wrapper autour des commandes de DjvuLibre ; ça il y en a plein, mais c'est saleeuuuu).
• Stocker les labels dans une base sqlite. Parce-que le problème actuellement, c'est que les opérations sur les labels ne sont pas atomiques du tout. Si tu changes le nom d'un label mais qu'une coupure de courant zigouille Paperwork pendant l'opération vous allez avoir une moitié de labels modifiés et pas l'autre.

Au risque de te décevoir, c'est une contribution de Thomas Clavier.
N'utilisant pas Docker, je ne peux pas la maintenir ni répondre aux questions sur la mailing-list … :/

Je présume que ça marche encore pour le moment, et donc je la laisse.

Dans la théorie oui, tu peux le faire.
Dans la pratique, je teste très rarement Paperwork avec des documents > 60 pages. Il faudra donc voir comment il se comporte avec des livres entiers.

Pour http://paperwork.rocks/ , c'est un sujet assez contrariant pour moi. J'ai sorti Paperwork 0.1 le 8/8/2013. Leur dépôt Git indique que leur premier commit date du 3/7/2014. Autrement dit, ils n'ont même pas pris la peine de faire une recherche sur Github pour voir si le nom était déjà utilisé par d'autres (peine que, moi, j'avais pris).

<humour>
À partir de là, mon objectif est de faire un logiciel qui sera bien plus populaire que le leur pour les pousser dans l'oblivion. Oui je sais, je suis un gars rempli d'amour pour son prochain et très réaliste ;-)
</humour>

Désolé, c'est un bug que j'avais introduit dans la 1.0.0. C'est corrigé en 1.0.1.
https://github.com/jflesch/paperwork/issues/510

Le but concret, c'est de trouver rapidement les fichiers sans avoir besoin de lancer paperwork (accès distant notamment).

Ok, je comprends mieux l'idée. (et aussi pourquoi je n'en voyais pas l'intérêt : je synchro tout mes papiers avec Sparkleshare, même au boulot --> je peux lancer Paperwork partout où j'en ai besoin).

De toute façon, même si je voulais le faire, ce n'est pas gérable. Il y a juste trop de distributions GNU/Linux à gérer pour une seule personne. Si je m'y essayais, le seul résultat serait des paquets bâclés pour seulement la moitié des distributions existantes. Même pour Debian (qui est la distribution que j'utilise), le paquet serait sûrement aussi baclé vu que, en tant développeur Paperwork, je n'utiliserais pas la version packagée.

Il m'a toujours semblé que ce n'est pas au développeur d'une application de se faire le packaging dans les distributions. Pour moi, c'est aux développeurs (/utilisateurs?) des-dites distributions. En gros, chacun son rôle, et les logiciels seront de meilleure qualité :-)

Disons que le label est un truc comme « fiche de paie » dans les deux, il faudrait que je mettre un label "Octobre" et "Novembre" pour savoir quel fichier correspond à quel mois ?

Je ne suis pas sûr de comprendre la question.

1) Quel rapport entre un label "fiche de paie" et des labels de date ?
2) Les documents sont nommés par leur date de scan (modifiable si nécessaire). Personnellement je m'arrange pour que les dates de scan collent toujours à peu prêt aux dates de réception (ce qui est déjà le cas de base 99% du temps). Donc l'information du mois est déjà inclue dans le document.
3) Les documents sont indépendants les uns des autres. Si vous souhaitez avoir un label "fiche de paie" sur ces deux documents, le label sera mis dans 20150223_1320_32/labels et dans 20150223_1323_23/labels.

Ce dont je rêve (je sais, je pourrai payer mon patch) c'est de pouvoir formatter les dossiers et nom de fichiers en sorti

Quelque-chose comme #423 ?
Personnellement, je ne vois pas trop l'utilité de la chose. Au final, quel est l'objectif concret de cette manœuvre ?

Je vois quelques problèmes pour les rendre compatibles :

• Paperless attend de l'utilisateur qu'il nomme les documents. Paperwork, non. Parce-que ça me semble inutile et contre-productif.
• Paperless chiffre les documents. Paperwork, non. Parce-que ce n'est pas son boulot.

À tout hasard, il y a quelques solutions workarounds possibles:

• Chroot
• Container LXC
• Container/image Docker (perso, je suis pas fan, mais bon)

Pas très pratique, je sais :/

Hm, autant je peux comprendre cette crainte pour un utilisateur lambda, autant j'aurais tendance à penser qu'elle n'est pas justifiée pour les lecteurs de Linuxfr. Corrigez-moi si je me trompe, mais je serais enclin à supposer que la plupart des gens ici savent faire des scripts shells ?

À partir de là, oui, Paperwork organise les documents d'une façon qui lui est propre.
Mais non, Paperwork n'utilise pas de format propriétaire. Les formats utilisés actuellement sont JPEG (scans), hOCR (sortie de l'OCR), CSV (labels), et PDF (imports). Certains ont déjà scriptés des opérations d'export de leurs documents sans problème.

À terme, Paperwork utilisera probablement le format DjVu. Il me semble être le format le plus approprié pour ce qu'il fait. Il y aura alors une mécanique de migration automatique qui sera mise en place. Je pense que ça répondra à cette inquiétude aussi pour les utilisateurs lambda.

un gros paquet de documents .djvu, .pdf, .jpeg scannés

• paquet de PDF: yep
• paquet de JPEG: pas encore
• paquet de DjVu: pas encore

"tous les docs de ce dossier auront ce tag"

Nop.
Paperwork apprends des documents déjà labelisés. Il essaye ensuite de déterminer automagiquement quels labels appliquer sur les nouveaux documents (scannés ou importés). Statistiquement, ça marche bien. Mais il faut quand même garder un œil dessus.

C’est backup-friendly

Yep, tout est stocké dans le répertoire de travail, sauf l'index whoosh et le cache des filtres bayesiens (pour les labels). Mais à chaque démarrage, Paperwork remet à jour son index automatiquement à partir du contenu du répertoire de travail.

Du coup, ça marche aussi très bien avec des outils de synchro comme SparkleShare ou OwnCloud.

Pour l'heure, pour les exports en PDF, Paperwork utilise Cairo. Ça limite le contenu du PDF à une image.
C'est malheureusement un ticket que j'ai en attente depuis longtemps.

Pour l'import:

• Résultat d'OCR : Habituellement, dans un PDF généré par OCR, la page scannée est mise sous forme d'image dans le PDF, et le texte reconnu est mis en dessous. Paperwork prend déjà en compte le texte contenu dans les PDFs.
• Méta-données : Pareil, c'est un vieux ticket. Par contre, je doute que ce soit une bonne idée d'utiliser ces tags pour les labels des documents Paperwork. Un PDF mal-taggué pourrait mettre facilement le bordel dans les labels Paperwork.

Pour la migration vers un autre outil, le format de données utilisé par Paperwork est très simpliste. Du coup, il se prête bien à la manipulation par script shell. Voir par exemple un des commentaires sur le ticket concernant l'export.

Par contre, le format utilisé par Paperwork va sûrement évoluer dans la future. Probablement vers quelque-chose comme DjVu.

C'est un module Python tout à fait classique :

• C'est simple à utiliser
• Ça fonctionne bien

J'ai juste dû faire un petit peu de tunning à l'arrache. Jusque là, le résultat me semble tout à fait satisfaisant.

Je n'ai pas de licence Windows chez moi. Et plus embêtant, je n'aurais pas l'usage d'un tel portage. Or coder quelque-chose que je n'utilise pas ensuite est un moyen sûr de faire un programme de mauvaise qualité. Je n'ai donc pas l'intention de le faire.

Par contre, si quelqu'un souhaite le faire, je n'ai aucun problème avec ça. Toutes les modifications allant dans ce sens pourront être intégrées dans Paperwork/PyOCR/Pyinsane sans problème. La seule condition est de ne pas les casser sous GNU/Linux.

Si vous avez suivi les instructions données pour Debian, simplebayes devrait être installé automatiquement par la commande pip. À ma connaissance, il n'y a pas de paquet Debian actuellement pour simplebayes.

Avec Linux Mint 17, vous allez avoir un autre problème : https://github.com/jflesch/paperwork/issues/440 .
La version de Gtk dans Linux Mint 17 est encore plus ancienne que celle de Debian stable (no comment). J'ai rajouté un workaround rapide, mais ce ne sera releasé que avec Paperwork 0.3.1.

Quant à l'exception remontée par Paperwork, il faudra être plus précis. Si vous avez toujours cette exception après avoir installé toutes les dépendances (y compris celles remontées par paperwork-chkdeps), je vous invite à ouvrir un ticket indiquant la sortie complète de Paperwork (au moins les 10 lignes avant l'erreur indiquée).