Jérôme Flesch a écrit 379 commentaires

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

http://cgi.clamav.net/sendvirus.cgi

Edit: 0wn3d. J'ai été trop lent.

Bon, ok, je suis un boulet.

J'ai lu le post trop vite. Je n'avais pas compris que la licence d'origine est propriétaire. Bon ben en tout cas, bel exemple de pourquoi les logiciels libres rocks, et pourquoi les logiciels propriétaires s*cent des b*tes d'ours en enfer.

Pour moi, c'est comme si ce logiciel venait de devenir propriétaire. En général, ça se solde par un fork libre.

Pour les PDFs :

• Si un PDF contient du texte, à l'import, c'est ce texte qui est utilisé
• Si aucun texte n'est trouvé dedans, à l'import, Paperwork passe l'OCR dessus
• Il est possible de forcer Paperwork à passer l'OCR dessus (cf options avancées). Ça s'est révélé utile pour moi : J'avais le PDF d'une facture qui était en fait une image, avec, sous l'image, un texte bidon mais placé au même endroit que le texte de l'image. Je suppose qu'il s'agissait d'empêcher les copier-coller.

Sinon, quitte à faire un script bash, autant juste placer les images comme Paperwork les attends. Si elles sont bien placées, il les prendra en compte tout seul au prochain lancement.

Pour l'installation, je sais :/ . Scikit complique tout. J'espère toujours qu'un jour quelqu'un aura le temps de faire des paquets Debian et les fera inclure dans la distribution officielle (j'en suis à mon 3ième candidat pour être mainteneur …). Ça simplifiera considérablement le problème.

Déjà, merci pour ce retour constructif :)

Concernant les importations de plusieurs fichiers, s'il s'agit de fichiers PDF, c'est déjà possible. Il suffit de demander à importer le dossier qui les contient tous.

Pour les fichiers images, c'est malheureusement plus compliqué. Il est impossible de deviner ce qui est une page et ce qui est un document. Il faut donc que Paperwork pose la question à l'utilisateur .. sauf que, en ce moment, je manque cruellement de temps pour travailler dessus :/

Je pense qu'il y a une solution intermédiaire un peu plus réaliste. On pourrait simplement obliger toute société qui créé un format propriétaire à fournir gratuitement à la Justice les outils nécessaires pour les exploiter (et ce, bien avant même qu'une affaire éclate).

Je crois savoir que tu peux configurer les filtres à spam de sorte qu'ils ne rejettent que les spams les plus flagrants. De cette manière, tu ne serais déjà plus blacklisté je pense, et tes utilisateurs recevraient quand même l'essentiel des faux-positifs non ?

L'import de fichiers est-il scriptable ? (en ligne de commande, via une API ou un module Python)

Non. Ceci dit, la structure du répertoire de travail et des documents est actuellement très simple, ce qui rend la création de script assez facile.

Je suis un particulier. (…)

Particulier dans un cas qui ne concerne que 0.01% des gens --> Utilisation de l'import de fichiers.

Pour la reconnaissance automatique de la date, je crains que ce ne soit impossible tellement il y a de manières d'écrire une date, tellement il y a d'emplacements où l'écrire… et il n'est pas rare que plusieurs dates figurent dans un document.

Hm, à voir. Au moins pour les PDFs, il est peut-être possible de trouver une date pertinente et présente dans la plupart d'entre eux. Il faudrait peut-être juste s'assurer que la date en question n'est pas délirante (je viens de regarder une de mes factures, et j'ai Modified: 1970-01-01 00:59:59 … :)

Je me suis rajouté un ticket

Une fois les documents numérisés, quand les tags sont appliqués est-il possible de déclencher un script externe ?

Je viens de rajouter un ticket à ce sujet dans le bugtracker. À voir.