Jérôme Flesch a écrit 346 commentaires

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.

Ces équipements ne pouvant être utilisé comme scanner (non supporté, pas autorisé ou simplement trop loin du PC), est-il prévu de pouvoir utiliser une boite de courriel (IMAP ou POP3) comme source des scans ?

Non.

(ou un répertoire).

Il est déjà possible d'importer un répertoire de PDFs. Je ne l'ai pas fait avec les images pour l'instant parce-que ça présente moultes complications.

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

Non.

Ce cas d'utilisation vous semble-il en accord avec les objectifs de Paperwork ?

Non.

L'objectif est "scanner & oublier". Pas "rentrer ses réglages email dans Paperwork & aller scanner au boulot & lancer Paperwork chez soi".

Le public visé est les particuliers, pas les artisans.

De plus, ça soulève plein de complications, aussi bien pratique qu'en terme de design d'UI. Je suppose qu'on ne parle pas d'une adresse email dédiée ? --> Il faut notamment pouvoir faire le tri entre les mails venant du scanner et les autres.

Au final, pour un particulier, on parle de maximum 3 à 4 documents à scanner par jour. Pour ces cas, il est donc juste plus simple qu'il se débrouille avec son scanner comme il l'entend, et qu'il utilise la fonction d'import pour les ajouter dans Paperwork. Ça évitera de polluer la GUI avec des options que 99% des gens n'utilisent pas.

Sur une note plus personnelle, je n'aurais aucune utilité pour une telle fonctionnalité. Je n'ai donc aucune incitation à la coder. Pire que ça, je n'aurais aucune incitation à la tester régulièrement et la maintenir fonctionnelle.

Woops, c'est corrigé. Merci :)

Il n'y avait rien d'agressif dans ma question initiale, tu as choisi de le prendre comme tel et de faire une réponse dans ce ton.

Je sais qu'il n'y avait rien d'agressif. C'est juste que comme dit, c'est des questions récurrentes et c'est fatiguant pour moi. Désolé que ma réponse agacée soit tombée sur toi en particulier alors que ça n'avait rien de personnel.

connaître les motivations d'une autre approche m’intéresse

Je pense que c'est ça le problème de départ. Il y a beaucoup de choix que j'ai fait juste parce-que "il me fallait quelque-chose". Je me fichais de savoir quoi du moment que ça répondait à mon cahier des charges (minimaliste). Du coup, j'ai pris le premier truc qui m'est passé sous la main.
Je pense qu'il ne faut pas toujours chercher de justification. Il n'y en a parfois juste pas.

La réalité, c'est que pour un problème donné, il y a bien souvent 250 solutions possibles, et dans le tas, il y en 25 qui sont tout à fait satisfaisantes. À partir de là, pour faire le tri, c'est juste plus simple de coder un truc vite fait, et de voir ensuite où ça pose problème.

Là, les fichiers de labels se sont révélés problématiques parce-que je ne peux pas modifier tout les labels sur tout les documents de façon atomique. Mais à coté de ça, il y a plein de choix que j'ai fait à l'arrache qui passent très bien ("Pourquoi GTK plutôt que QT ?", "Pourquoi un client lourd plutôt que léger ?" (et Dieu sait que cette question revient …), etc).

En tout cas merci pour la faq et le fait de faire passer tes interlocuteurs (ou juste moi) pour des trous du cul.

Là encore, rien de personnel. J'aimerais juste resté motivé pour travailler sur Paperwork. Il faut donc que je trouve une solution pour me débarrasser de ces questions récurrentes avant que je pête sérieusement un câble.

Avec un peu d'autodérision ça passe peut être mieux. Par exemple tu peut faire une allusion au BDFL.

Idée intéressante. J'ai réédité le wiki. Peux-tu me dire ce que tu en penses s'il-te-plaît ?

Eclipse pose peu de question et je ne vois pas le liens entre poser des questions et être lourd.

Chaque option est une question. Chaque option peut être reformulée sous la forme "Voulez-vous faire X ?". Autant dire que Eclipse (et de façon générale, tout les softs pour spécialistes) noient les utilisateurs sous les questions.

Après, il y a des solutions intelligentes pour contourner ce problème. Par exemple, les extensions Firefox sont une excellente idée.

Ça peut être une zone de notification, une boite qui apparaît dans la fenêtre déjà ouverte (c'est utilisé dans eclipse entre autre), etc

Ça évite la création d'une nouvelle fenêtre. À part ça, aucune réelle différence avec un popup. Dans tout les cas, la question ne peut pas être ignorée. Or ici, la question n'est pas nécessaire.

En fait ce n'est pas spécifiquement cette question qui m'embête, c'est toutes les remarques et questions du même genre.

Quoiqu'il en soit, c'est une bonne remarque que tu fais. Je viens d'ajouter ça au wiki:
https://github.com/jflesch/paperwork/wiki/Faq#why-did-you-do-x-instead-of-y-

Ça m'embête un peu d'avoir ce ton passif-agressif dans la FAQ, mais ces questions sont vraiment récurrentes (le bugtracker en est plein).

En design d'interface graphique, se décharger sur l'utilisateur est généralement une mauvaise idée. C'est comme ça qu'on finit avec des bloatware comme Eclipse. Sans compter que ici, ça prendrait vraisemblablement la forme d'un popup, et je hais les popups.

Dans le cas dont on parle ici, il n'y a aucune raison de demander à l'utilisateur quoique ce soit. Il a demandé que l'OCR soit passé sur le document, donc c'est le texte issue de l'OCR qui doit être utilisé. Mais:

• Réécrire le PDF implique risquer de l'endommager.
• L'opération doit rester réversible. À terme, il y aura même une option "Annuler".

Après, si l'utilisateur a besoin d'un PDF contenant le texte de l'OCR, c'est la fonction d'export qui s'en chargera.

Cette solution ne répond pas à l'énoncé du problème. La question était "qu'est-ce qu'on fait du texte initialement présent dans le PDF s'il y en a ?" (parce-que si, ça peut arriver).