Jérôme Flesch a écrit 390 commentaires

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

Parce qu'on a des normes qui sont bien documentées, supportées par plein de libs/outils/langages et utilisées dans des milliers de logiciels ?

Oui, par exemple, on a le CSV. Il se trouve que c'est le format que j'utilise pour les fichiers contenant les labels des documents. Je n'utilise juste pas de parseur CSV (c'est bon vieux bête et méchant line.split(",") sur chaque ligne, avec une interdiction d'utiliser les virgules dans les noms de labels).

Ou bien parce que c'est directement inclus dans le fichier, ce qui est pratique lors de copie, transfert, etc.

Oui, parce-que copier ou transférer un dossier est clairement plus difficile qu'un seul fichier, c'est sûr …

Juste pour info, dans le future, je pense utiliser le format DjVu pour les scans. Ça permettra de justement stocker images et textes dans un même document. Par contre, vu comment le format est peu supporté par d'autres applications, ça réduira la portabilité de ces documents.
Les labels seront eux stockés dans un seul fichier (sqlite ?) pour des questions d'atomicité des opérations.

Quoiqu'il en soit, cette discussion relève pour moi clairement du troll technique (quitte à perdre du temps, on pourrait se faire un bon vieux Emacs VS Vim ?). Je ne compte pas la poursuivre plus loin.

Si le PDF contient déjà du texte sous une forme parsable, qu'apporte l'OCR ?

J'ai déjà eut le cas d'une facture de téléphone mobile où le texte visible était en fait une image. Un texte aléatoire avait été mis en dessous des images pour faire croire qu'il y avait effectivement du texte dans le PDF (ne me demandez pas pourquoi, j'en ai aucune idée, je n'ai fait que constater et halluciner). D'où le fait que Paperwork permet de repasser un coup d'OCR dessus.
On peut imaginer d'autre cas : certains personnes font leur scan au boulot. Certains scanner pro proposent de générer des PDFs avec texte issu de l'OCR inclu. Pour peu qu'ils ne soient pas satisfait du résultat de l'OCR du scanner, ils peuvent vouloir essayer Tesseract.

pourquoi ne pas les stocker dans les champs IPTC/XMP ?

Meh. Pourquoi IPTC/XMP ? Pourquoi pas des fichiers JSON ? Pourquoi pas des fichiers de config Python ? Pourquoi pas XYZ ?
Au final, je voulais stocker une liste de labels dans un fichier. Je n'ai pas cherché plus loin.

Pareil pour l'OCR, le résultat ne peut-il pas être sauvegardé dans le pdf lui-même ?

J'ai pris l'approche la plus safe (et la plus simple) que je pouvais : Paperwork ne touche jamais au PDF original. Donc la sortie de l'OCR (s'il y en a une), est stockée à coté du PDF.
De plus, si on réécrit le PDF pour y inclure la sortie de l'OCR, que faire du texte déjà existant dans le PDF s'il y en a ? On le bazarde ? Et si on se rend compte ensuite que le texte original était finalement meilleur que l'OCR ?

Pour la doc dans l'appli, je viens d'ajouter un ticket.

Sinon, niveau Debian, je me disais que, peut-être, ça aurait du sens de faire des paquets bidons paperwork-l10n-<XX> ? Parce-qu'en fait, il n'y pas juste l'OCR, mais aussi la correction orthographique (utilisée pour améliorer la détection de l'orientation des pages) --> paperwork-l10n-fr tirerait par exemple tesseract-ocr-fra + aspell-fr/ifrench/whatever ? (après, je réalise que ce n'est pas trivial, surtout qu'on ne sait pas quel correcteur orthographique l'utilisateur souhaite installer et utiliser)

Le résultat de l'OCR, les labels et autres sont stocké dans de simple fichiers textes, au coté des scans. Ceci dit, pour les labels, ça changera peut-être dans le futur.

Pour l'anecdote, personnellement, pour synchroniser mes documents entre mes différentes machines, j'utilise SparkleShare. J'utilise aussi eCryptfs pour en assurer la confidentialité.

Chose amusante, j'ai décidé de travailler sur Paperwork (enfin son prédécesseur) après dû faire la paperasse pour obtenir un visa pour un stage aux US :)

Tout est documenté sur le wiki. En gros, j'ai essayé de garder les choses le plus simple possible.