Jérôme Flesch a écrit 379 commentaires

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.

Est-ce qu'il y a des systèmes qui analysent le contenu HTML des pages pour les filtrer ? Est-ce que ces systèmes sont déployés en entreprise ? de manière légitime ? Si oui, effectivement, c'est effectivement problèmatique pour ces entreprises.

Ayant travaillé pour un fabriquant d'UTM-IPS, je peux répondre facilement à ces questions : oui.

Les UTMs sont généralement capables de filtrer, directement dans les flux HTTP, HTML et Javascript. Ceci dit, pour le HTTPS, à ma connaissance, ils proposent maintenant tous aussi des fonctionnalités pour faire du man-in-the-middle. La seule contrainte est que les postes clients doivent faire confiance à l'autorité de certification de l'UTM. À partir de là, l'UTM génère des certificats à la volée pour se faire passer pour les serveurs légitimes.

Le premier qui s'annonce disponible pour le faire gagne.
Du coup, si personne d'autre ne se déclare volontaire avant septembre, le job est pour toi :)
N'oublie pas d'envoyer un mail sur la mailing-list le moment venu s'il-te-plaît.

Le packaging est une tâche facile à déléguer. Du coup, j'espère pouvoir le déléguer pour pouvoir me concentrer sur les améliorations de Paperwork.

Ceci dit, si je ne trouve personne pour le faire (ou si on me dit encore que finalement on a pas le temps), je vais devoir finir par le faire moi-même.

Cool :)
Dans ce cas, il faudrait juste que tu envoies un messages sur la mailing-list pour faire savoir que tu comptes t'en occuper.

Merci d'avance,

Zut. Freecode était pratique pour moi pour faire ma pub sans pour autant spammer ou payer plein de brouzoufs. Du coup, est-ce que quelqu'un connaît de bonnes alternatives à Freecode ?

PS : Oui, j'en profite aussi pour me refaire un peu de pub ;)

Des fois que ça en inspire d'autres, voici la solution pour laquelle j'ai opté:
De base, j'ai opté pour Keepassx. Pour ce qui est de travailler sur plusieurs postes, j'ai résolu le problème en utilisant SparkleShare. Il synchronise automatiquement ma base de mots de passe sur la plupart de mes postes. Vu que SparkleShare utilise Git comme backend, j'ai aussi pu me mettre une copie de ma base de mots de passe sur mon téléphone Android : Il y un client Git/Android appelé agit, et KeePassDroid pour lire et modifier la base de données de mot de passe. Le seul défaut est que je dois faire la synchro de la base sur mon téléphone à la main de temps en temps.

Vous connaissez des bonnes alternative à Owncloud?

Personnellement, tout ce qui m'intéressait dans Owncloud, en fait, c'était la synchronisation de dossiers. Au final, j'ai opté pour SparkleShare. C'est basé sur Git. Et surtout, contrairement à Owncloud, SparkleShare fait une chose et une seule, et il la fait bien.

Ils disent que ce n'est pas idéal pour une collection de photos. Ceci dit, moi je m'en sers aussi pour ça, et pour l'heure ça fonctionne bien.

Directory Tiles will instead suggest pre-packaged content for first-time users.

En fait il ne s'agit que de préremplir les tuiles affichées dans les nouveaux onglets avec des suggestions/pubs. Suggestions/pubs qui ne seront plus faites une fois que les 9 tuiles seront remplies, autrement dit, une fois que l'utilisateur aura visité 9 sites différents.
Quand on précise ça, ça me semble tout de suite nettement moins désagréable et intrusif.

Reste surtout à voir comment ça va évoluer ensuite …

Chose que je trouve amusante, j'étais embêté par le problème inverse quand j'avais fais une dépêche pour mon projet. À savoir, des discussions techniques et des rapports de bugs avaient lieu dans les commentaires Linuxfr au lieu du bugtracker. Ça m'embêtait parce-qu'il fallait que je les copie-colle dans des tickets GitHub pour ne pas les perdre de vue et éviter les duplications.
Au final, j'aurais préféré avoir juste les trolls sur Linuxfr et les discussions constructives sur Github :)

Ma remarque porte seulement sur la croyance asso à but non lucratif" = que des gentils pas financièrement interessés c'est sûr. Il y a la belle théorie d'un côté, il y a la réalité d'un autre côté.

Tu présupposes souvent que les choses ne marchent pas comme elles devraient ? Si tu programme, ça doit donner des résultats intéressants. "Hm, et si ce bit passe à 1 soudainement sans prévenir ? mon programme devrait gérer ça".

Je ne dis pas qu'il faut avoir une confiance absolue et aveugle dans les associations. Mais à moment donné, tu es forcément obligé de présupposer que tout marche comme prévu. Et dans ce cas, les associations à but non-lucratif sont, de par leurs status et objectifs affichés, nettement plus fiables que les entreprises privées. Faute de pouvoir analyser leurs moindres détails, ce sont les meilleurs choix.

Bien vu, ma faute là aussi. On m'avait dit ça dans une des associations où j'ai été bénévole, mais ça devait être spécifique à cette association. Désolé pour cette erreur.

Quoiqu'il en soit, vu les règles strictes liées à leurs rémunérations, ça ne change pas grand chose à mon propos.