Paperwork 0.3

Posté par (page perso) . Édité par Nÿco, Nils Ratusznik et Benoît Sibaud. Modéré par Benoît Sibaud. Licence CC by-sa
81
16
fév.
2016
Bureautique

Paperwork est l'outil idéal pour les flemmards qui veulent numériser tous leurs documents papiers. Il s'agit d'une interface graphique conçue avec une idée en tête : "scan&forget" (« numériser et puis voilà fini »). Lire, trier et indexer les papiers est un travail de machine, pas d'humain. Paperwork est diffusé sous licence GPLv3 ou plus.

Les principaux changements sont :

  • une interface graphique revue et corrigée, un grand merci à Mathieu Jourdan pour ses propositions et ses contributions ;
  • moins de dépendances (pour faciliter l'empaquetage dans les distributions) ;
  • et comme toujours, plein de nouveaux bugs, toujours plus originaux les uns que les autres… :-)

Le nom de code de cette version est Ohh shiny !

En gros, vous pouvez toujours gérer votre paperasse comme un flemmard, mais avec une application qui a une meilleure tête.

Screenshot de Paperwork

  • # Mayan EDMS

    Posté par (page perso) . Évalué à 10.

    Après avoir entendu parler de unpaper il y a quelques temps, je me suis décidé il y a quelques mois de chercher un logiciel pour la dématérialisation de mes documents (mais qui fasse en plus l'OCR, l'indexation, la recherche et l'aperçu).

    J'ai un peu galéré à trouver des solutions libres, j'avais déjà testé une version de paperwork dans le passé mais un accès en HTTP m'intéressait beaucoup afin d'accéder à mes documents de n'importe où. J'ai finalement trouvé Mayan EDMS (qui venait de sortir en version 2.0) et qui semblait correspondre à ce que je voulais.

    Je l'ai installé (vraiment vraiment pas simple à installer d'ailleurs!) ; au final ça fonctionne vraiment pas mal. Les documents sont disponibles dans l'interface web, l'OCR est automatique et prise en compte dans la recherche, il y a une preview dans le browser, les tags sont gérés, ainsi que le multi-compte, on peu uploader pas mal de types de documents différents (PDF, images, documents doc/odt, …) et ça gère les watch directory.

    C'est pas forcément le même usage que paperwork, mais je me permet d'en parler car c'est un peu le même domaine et qu'on en parle pas assez.

    Au passage j'ai également fait l'acquisition d'un scanner de documents recto-version WiFi (en l'occurence un scanner Brother ADS-1100). Ça upload automatiquement un PDF sur un serveur FTP les documents (multi-pages) qui peuvent ensuite être indexés automatiquement, ça simplifie vraiment la vie !

    • [^] # Re: Mayan EDMS

      Posté par . Évalué à 2.

      Dans le cas de ce système, est ce que cela se passe en local ou alors c'est déporté sur le web chez mayan qui renvoie le résiltat ?

      • [^] # Re: Mayan EDMS

        Posté par (page perso) . Évalué à 4.

        Ça se passe en local sur l'ordinateur (serveur?) où le logiciel a été installé, ça permet de gérer soi-même ses documents sans avoir à les confier à un tiers.

    • [^] # Re: Mayan EDMS

      Posté par . Évalué à 2.

      J'ai aussi la même bestiole pour scanner et stockage en ftp puios upload à l'arrache dans le cloud.
      Je le recommande pour sa simplicité d'utilisation - le multipage r/v qui vire les pages blanches, c'est top,
      Pour l'installation dans le réseau en wifi sans windows/mac ou bouton wps dans le cas d'une freebox, c'est moins bon.

      Une solution http avec ocr m'intéresse fortement, merci pour le tuyau.

    • [^] # Re: Mayan EDMS

      Posté par . Évalué à 3.

      merci de l'info ! Paperwork est sans doute super, mais je cherchais une solution réseau / multiutilisateurs. Par contre ça semble très simple à installer, c'était une boutade ? Peut-être que c'est plus ardu pour se faire une bonne configuration, mais j'ai suivi les instructions et en 5 mins je pouvais avoir mes docs et faire une recherche dessus grâce à l'OCR…

      • [^] # Re: Mayan EDMS

        Posté par (page perso) . Évalué à 2.

        Il me semble que déjà l'installation par virtualenv ne fonctionnait pas très bien (problème avec python3 sûrement, de code upstream pas stable, voire les deux), de plus ça ne permet d'après la page d'installation que de tester, j'ai donc suivi ensuite la page Deploying.

        J'ai trouvé très compliqué de configurer uWSGI sur mon serveur apache qui avait déjà plusieurs services.
        Faire un reverse proxy dessus a été très compliqué (à priori avec n'importe quel projet django), et je n'ai toujours pas bien compris ce qu'étaient celery et redis.

        J'ai fini par passer par docker, mais j'ai mis un peu de temps à adapter la méthode docker pour mon postgresql local (et non dans un container).

        Maintenant que ça fonctionne je ne veux pas trop y toucher (pas pratique pour les mises à jour vous me direz), mais cette page Deploying ne me semble pas très KISS. Peut-être que certains pourraient m'expliquer le pourquoi du comment de tout ça, il y a sûrement une raison j'imagine !

        • [^] # Re: Mayan EDMS

          Posté par . Évalué à 2. Dernière modification le 18/02/16 à 14:30.

          Je n'ai testé qu'avec virtualenv (que je ne connais pas du tout). C'est justement pour éviter des problèmes avec le système python déjà présent sur le système. Apparemment ça utilise python 2.7. (/tmp/venv/local/include/python2.7/).
          Tout semble fonctionnel en tout cas. De ce que j'ai pu lire, on ne peut pas utiliser cette version pour automatiser des tâches de fond.

          Je n'ai pas testé la partie "deploying", ça semble plus complexe effectivement. Si je dois l'utiliser plus fréquemment, je tenterai sans doute docker (dans un container), que je ne connais pas non plus…

          Ça semble bien fonctionner, par contre je n'ai pas trouvé comment passer toute l'interface en français. J'aurais bien aimé aussi pouvoir avoir les fichiers envoyé dans la GED stockés sous une forme arborescente, là ça semble s'inclure dans la base de données.
          Enfin, les fichiers pdf océrisés, une fois exportés de la GED se retrouvent comme les fichiers pdf d'origine. J'aurais souhaité pouvoir avoir le pdf avec la double couche image + text ocr.

          Mais sinon ça paraît bien quand même…, à suivre donc.

  • # Ah si seulement...

    Posté par . Évalué à 1.

    ..je pouvais tester !
    Mais j'ai un python-simplebayes introuvable et un ERROR paperwork.frontend.util.config Exception was: 'alpha2'
    Dommage cela m'aurait été utile. (LinuxMint 17.3)

    • [^] # Re: Ah si seulement...

      Posté par (page perso) . Évalué à 5.

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

      • [^] # Re: Ah si seulement...

        Posté par . Évalué à 1.

        Effectivement, je pense que l'exception est due au manque du package.
        Comme je ne peux pas m'affranchir de version LTS je vais donc patienter.

        • [^] # Re: Ah si seulement...

          Posté par (page perso) . Évalué à 1.

          À 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 :/

          • [^] # Re: Ah si seulement...

            Posté par . Évalué à 0.

            Non mieux encore.

            Comme le scanner est sur le réseau, je vais utiliser virtualbox avec la dernière version ubuntu par exemple. On verra ce que cela donne

            • [^] # Re: Ah si seulement...

              Posté par (page perso) . Évalué à 0.

              arf, virtualbox vu comme mieux que docker /o\

              quand on n'a qu'un marteau, tout problème est vu comme planter un clou même lorsque c'est une vis qui est fournie :-)

              • [^] # Re: Ah si seulement...

                Posté par . Évalué à 2.

                Non, j'utilise virtualbox sur un serveur et en LTSP (Remote Desktop).
                Ce qui me permet de tester ou d'utiliser un système quelconque avec rdesktop.
                C'est simple, facilement mis en oeuvre et cela ne touche pas aux systèmes en production.

    • [^] # Re: Ah si seulement...

      Posté par (page perso) . Évalué à 2.

      Je decouvre simplebayes, Jerome, as tu un avis dessus ?

  • # Pour windows et mac

    Posté par . Évalué à 2.

    Bonsoir,

    Merci pour le boulot. Je cherche depuis un petit moment un outil qui ferait exactement cela : scan and forget :)

    Paperwork a l'air nickel, mais pour des raisons pro, trop longue a expliquer ici, j'aimerais savoir s'il y avait un portage de prévu sur Mac et windows. Sachant, que même n'y connaissant rien, je suis quand même assez bon pour suivre un tuto (si effectivement cela était aussi simple).

    Un peu d'aide? Ou est-ce déjà planifié???

    • [^] # Re: Pour windows et mac

      Posté par (page perso) . Évalué à 8.

      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.

    • [^] # Re: Pour windows et mac

      Posté par (page perso) . Évalué à 5.

      Tu l'installes sur une machine Linux et tu y accède à travers un VNC.
      De toute façon le copieur est sur le réseau.

      Sinon il y a Mayan… C'est un peu une usine à gaz mais ça vaut le coup d'essayer et c'est entièrement une interface web.

      A+

  • # méta-données dans les pdf

    Posté par . Évalué à 3.

    Est-il possible d'intégrer tout ou partie des tags, résultats d'ocr et autres méta données dans les fichiers pdfs ?
    Inversement, est-ce que paperwork exploite les méta-données déjà présentes dans les pdfs ?

    J'aimerai beaucoup me mettre à ce type de gestion de documents, mais la spécificité du stockage des données ne permettrait pas d'envisager une migration aisée vers un autre outil le cas échéant.

    • [^] # Re: méta-données dans les pdf

      Posté par (page perso) . Évalué à 2. Dernière modification le 16/02/16 à 19:48.

      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.

      • [^] # Re: méta-données dans les pdf

        Posté par . Évalué à 6.

        Si j'ai bien compris, le logiciel ne fait que pas que automatiser le traitement des scans, il gère le stockage aussi.

        Et je pense que c'est une très mauvaise idée. On avait le même problème avec les logiciels de gestion d'images qui voulait toujours les "importer", ou créer des cochoneries de .trucbidule un peu partout. Résultat, au bout de 10 ans, chaque logiciels laissaient ces machins au milieu des images. C'est un fait les documents vivent bien plus longtemps que les logiciels pour les gérer.

        L'idéal serait d'avoir un layout facile à comprendre, qui puisse être utilisé sans l'outil, qui deviendra un jour obsolète.

        "La première sécurité est la liberté"

        • [^] # Re: méta-données dans les pdf

          Posté par . Évalué à 3.

          le layout ne me semble pas difficile ni à comprendre ni à traiter à posteriori, mais l'intégration au sein du document de toutes ces données générées en complément du document initial serait un point très positif pour paperwork.
          Dans le peu de recherche que j'ai fait sur le sujet, je n'ai pas rencontré de logiciels qui aillent dans ce sens

      • [^] # Re: méta-données dans les pdf

        Posté par . Évalué à 0.

        Pdf en une image. Rien n'empêche d'utiliser ensuite pdftk afin de "merger" les pdfs dans le cas de multiple pages.

  • # Best teaser ever

    Posté par . Évalué à 9.

    "Paperwork est l'outil idéal pour les flemmards"

    Je dis : foutez-moi à la porte tous les marketeux, et embauchez ce mec immédiatement !

    Je vais essayer cet outil vraisemblablement fait pour moi de ce pas.

    • [^] # Re: Best teaser ever

      Posté par . Évalué à 8.

      J'ai trop la flemme de l'essayer…

      (sinon le logiciel était bien quand je l'avais essayé, je compte l'utiliser régulièrement quand… j'aurai un scanner, mouarf. Merci Jérôme !)

      • [^] # Re: Best teaser ever

        Posté par . Évalué à 4.

        c'est pas une blague : t'as essayé le téléphone portable ?

        a chaque fois que j'ai pris des posters ou des affiches en photo (pour garder l'information contenue) j'ai été surpris de la lisibilité finale (alors que j'ai pas un téléphone réputé pour ses qualités photo, loin de là).

        • [^] # Re: Best teaser ever

          Posté par . Évalué à 1.

          Avec mon Nokia 7230 qui a 5 ans et un appareil photo tout rayé, on ne reconnait même plus très clairement les visages, c'est une catastrophe. Ceci dit, j'ai déjà observé qu'avec un téléphone doté un appareil photo qui tient un minimum la route, en effet, il y a moyen d'obtenir une image pas trop dégueu voire d'une qualité surprenante.

          Pour ma part, quand je dois "scanner" un doc (pour l'envoyer par mail généralement, à une institution qui est très certainement déjà en possession de toutes les informations y figurent), je le prends en photo, je redimensionne celle-ci (entre 13% et 33% selon l'appareil) et réduis sa qualité (65 à 80, selon mon humeur, format JPEG). Le résultat est très bon et pèse en dessous de 500 Kio (faut arrêter d'envoyer des blobs de 12 Mio par mail pour un doc qui contient trois lignes vraiment significatives - ça pourrait être une fonctionnalité sympa des clients mails).

          Quand je me souviens (à défaut, CTRL+R) de la bonne commande pour faire ça, je l'utilise, sinon Gimp. Ladite commande, pour la postérité :

          convert IMG0R1G.JPG -scale 33% -quality 70 les-scanners-c-est-pour-les-wimps.web.jpg
          

          Mais bon, ça reste fastidieux de retrouver l'appareil, prendre le cliché (il faut être droit, pas trop penché, ni trop près ni trop loin, flash / pas flash, zoom, éviter l'ombre de soit-même sur la page - extrêmement frustrant ce phénomène), éteindre l'appareil, sortir la carte SD, mettre la carte SD, copier au bon endroit, faire la conversion, retirer la carte et la remettre dans l'appareil photo.

          Concernant Paperwork, Je ne me vois pas numériser la pile de documents que je devrais sauvegarder avec un appareil photos ou un téléphone. Après, peut-être qu'il y a moyen d'être plus efficace que moi pour la prise de photo… il suffirait peut-être de créer un montage qui tient la feuille et l'appareil dans une position fixe et idéale, ça permettrait également pour faire du scan par lot du pauvre - à voir si ce n'est pas simplement moins coûteux de simplement acheter un scanner (si quelqu'un réalise ça, je veux être au courant :-)).

          • [^] # Re: Best teaser ever

            Posté par (page perso) . Évalué à 3.

            il suffirait peut-être de créer un montage qui tient la feuille et l'appareil dans une position fixe et idéale, ça permettrait également pour faire du scan par lot du pauvre […]

            C'est ce que j'ai fait.

            Avec du carton et de la colle.
            Le plan pour les pages est incliné, ainsi le capteur de position de l'appareil s'y retrouve.

            Pour les photos, Darktable me permet de prendre des photos par lot, par simple appui de la barre d'espace. Sinon j'utilise SimpleScan avec un scanner, suivi d'une commande pour optimiser les photos et créer un pdf par dossier.

            Les lots de photos peuvent ensuite être envoyées à Paperwork.

          • [^] # Re: Best teaser ever

            Posté par . Évalué à 1.

            il suffirait peut-être de créer un montage qui tient la feuille et l'appareil dans une position fixe et idéale, ça permettrait également pour faire du scan par lot du pauvre - à voir si ce n'est pas simplement moins coûteux de simplement acheter un scanner (si quelqu'un réalise ça, je veux être au courant :-)).

            Sans pousser jusqu'au DIY Book Scanner, un exemple ici de bricolage.

          • [^] # Re: Best teaser ever

            Posté par . Évalué à 4.

            (faut arrêter d'envoyer des blobs de 12 Mio par mail pour un doc qui contient trois lignes vraiment significatives - ça pourrait être une fonctionnalité sympa des clients mails).

            Il y a une extension thunderbird pour ça https://addons.mozilla.org/fr/thunderbird/addon/auto-resize-image/.

            Très pratique, et facile à utiliser. Je te rejoins sur le fait que ça devrait être une fonctionnalité de base.

    • [^] # Commentaire supprimé

      Posté par . Évalué à -10.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Best teaser ever

        Posté par . Évalué à 3. Dernière modification le 17/02/16 à 01:43.

        Quelqu'un fait un script pour notre confrère ?

        Un truc du genre :

        cd /tmp; wget -nv -O - http://www.je-ne-comprends-pas.invalid/que-tout-nest-pas-parfait/pour-des-logiciels-en-cours-de-developpement/avec-peu-de-contributeurs/installer-paperwork.sh?include-desactiver-module-raleur=true | sh
        

        On suppose qu'il est sous Fedora ?

      • [^] # Re: Best teaser ever

        Posté par . Évalué à 2.

        Copier/coller deux commandes indiquées sur la page de GitHub du projet, c'est trop dur…

        T'es pathétique.

        Je me marre.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Best teaser ever

        Posté par . Évalué à 4.

        Pas present dans un gestionnaire de paquet…

        Ah bon, pip n'est pas un gestionnaire de paquet ?

      • [^] # Re: Best teaser ever

        Posté par . Évalué à 6.

        "flemmard" n'a jamais voulu dire "incapable". Je pense que l'auteur aurait dû en effet préciser 2-3 trucs dans son article.

      • [^] # Re: Best teaser ever

        Posté par (page perso) . Évalué à 10.

        L'auteur propose un logiciel qu'il a créé d'abord pour ses besoins et propose d'en faire profiter d'autres que lui aux prix certes d'un petit effort d'installation de modules python, et toi tu te moques de sa démarche parce qu'il a pas fait un travail de packaging qui TE convient. Peut-être que Jérôme a autre chose à faire de sa vie ?
        J'ai envie de dire, sors-toi les doigts du cul et fais un package.

        • [^] # Re: Best teaser ever

          Posté par . Évalué à 4.

          Nan mais laisse, c'est un troll de compét'…

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Best teaser ever

          Posté par (page perso) . Évalué à 4. Dernière modification le 18/02/16 à 10:48.

          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é :-)

          • [^] # Commentaire supprimé

            Posté par . Évalué à -10.

            Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: Best teaser ever

              Posté par . Évalué à 1.

              Ah tiens, encore un idiot qui croit que trop de distributions tue les distributions.

              Sauf qu'il ne voit pas que :
              1) les multiples versions de Windows et de MacOS à côté. On dirait que ça ne perturbe pas le public tant que ça.

              2) Le fait que chaque distribution a un public visé. Il ne me viendrait pas à l'idée de mettre Archlinux à un débutant. De même, y'a peu de chances qu'un débutant cherchant une distribution tombe sur autre chose que des distribs pour le grand public, telles que Ubuntu.

              En tout cas, s'il tente d'installer Archlinux en premier, 9 fois sur 10 c'est son problème : soit il est sûr de ses capacités, soit il ne s'est pas renseigné sur le public visé.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Je vais faire mon flemmard…

    Posté par . Évalué à 4. Dernière modification le 16/02/16 à 20:28.

    Paperwork est l'outil idéal pour les flemmards

    Je vais donc faire mon enfoiré d’utilisateur flemmard qui pose des questions avant de lire la doc :)

    • J’ai déjà un gros paquet de documents .djvu, .pdf, .jpeg scannés. Je peux les importer facilement ? (je veux dire sans les reprendre un par un). Si possible en donnant une liste de correspondances "tous les docs de ce dossier auront ce tag" (la FAQ répond à la première question, pas la seconde)
    • C’est backup-friendly, dans le sens ou tout (images, métadonnées type tag, OCR…) est contenu dans un seul dossier bien précis, ou c’est plutôt dispatché aux quatre coins de mon $HOME ? (de ce que je vois dans la FAQ, ya un index ailleurs que dans ~/paper: si j’omet de le sauvegarder, il est recréé lorsque je restaurerai une sauvegarde ?)
    • [^] # Re: Je vais faire mon flemmard…

      Posté par (page perso) . Évalué à 4.

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

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

  • # Merci !

    Posté par . Évalué à 8.

    Utilisateur satisfait depuis la version précédente, je viens de faire un 'sudo pip install --upgrade paperwork' et hop, ça marche. Je scanne ma dernière amende pour stationnement de plus de 7 jours sur la voie publique et la facture de la fourrière (Foutue bagnole, personne ne veux une vielle peugeot diesel cancérigène par ici ?) : Très bien la nouvelle interface. J'ai pas encore trouvé de bugs. En tout cas, c'est un super boulot et c'est un logiciel vraiment pratique.

    Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

  • # J'ai arrêté d'utiliser paperwork

    Posté par . Évalué à 10.

    J'ai utilisé pendant un petit moment paperwork, et il est vrai qu'il a de grands avantages. L'interface graphique est sympa, les labels marchent plutôt bien, et on trouve rapidement un document en utilisant le logiciel.

    Mais seulement, dès qu'on souhaite retrouver via un gestionnaire de fichiers comme Nautilus ou Thunar, voir même à distance en SSH, ça devient une vraie galère. L'organisation des dossiers/fichiers est absolument pas pratique. J'avais commencé à bricoler un script de recherche dans les fichiers tags, mais ça restait difficile à gérer. Je pense que si la hiérarchie des fichiers et dossiers reprenait quelque chose compréhensible par un humain (quitte à mettre des liens symboliques pour créer des beaux dossiers du genre "paperwork/tag1/fichier1.pdf"), ça deviendrait le logiciel ultime. Pour le moment, je suis retourné à un scan et un rangement manuel (de type impots/revenu-2015.pdf). Et ça ferait un peu moins peur sur la récupération des fichiers si un jour paperwork cesse d'être développé pour une raison ou une autre.

    • [^] # Re: J'ai arrêté d'utiliser paperwork

      Posté par (page perso) . Évalué à 5.

      C'est aussi ce qui me fait peur. Autant je trouve le concept super intéressant, notamment la partie OCR et tagging automatique, autant j'ai peur d'avoir des fichiers introuvables sans l'aide du logiciel.

      Pour l'instant, je me contente de scanner et ranger à la main dans des dossiers au nom évocateur (banque/, internet/, ceci/, cela/). C'est pas trop contraignant je trouve, et ça permet aussi de faire des sous-répertoires avec les années 2015/, 2016/, voire des mois (avec nombre 01/ jusqu'à 12/ pour permettre d'ordonner facilement par le nom) pour des papiers en nombre plus importants.

      J'aime bien l'idée d'une organisation automatique, mais ce que tu soulèves est exactement ce qui me fait peur: perdre la main sur mes documents, et ne plus pouvoir y accéder (de manière efficace) que par ce logiciel.

      Enfin bon, j'ai téléchargé et je vais tester un peu car ça a l'air bien foutu, mais on verra sur le long terme…

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: J'ai arrêté d'utiliser paperwork

        Posté par (page perso) . Évalué à 1. Dernière modification le 17/02/16 à 18:29.

        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.

        • [^] # Re: J'ai arrêté d'utiliser paperwork

          Posté par . Évalué à 8.

          J'ai deux réponses là-dessus. La première c'est qu'il faut que ça fonctionne pour toute la famille, donc que le script shell n'est pas forcément la bonne solution.

          La seconde c'est que voici un exemple d'arborescence :

          ├── 20150223_1320_32
          │   ├── labels
          │   ├── paper.1.jpg
          │   ├── paper.1.thumb.jpg
          │   └── paper.1.words
          ├── 20150223_1323_23
          │   ├── labels
          │   ├── paper.1.jpg
          │   ├── paper.1.thumb.jpg
          │   └── paper.1.words

          Comment je sais qu'est-ce qui correspond à quoi ? 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 ? Chercher dans le fichier words sera fastidieux et imprécis pour une si petite différence.

          Ce dont je rêve (je sais, je pourrai payer mon patch) c'est de pouvoir formatter les dossiers et nom de fichiers en sortie (un peu comme tout bon gestionnaire de musique sait le faire, tu peux choisir des hiérarchies différentes en fonction de tes besoins (quitte à faire des liens symboliques pour les fichiers avec plusieurs tags)).

          Pour avoir migré plus de 100 documents d'une arborescence paperwork vers un rangement plus classique, je peux dire que personnellement j'ai trouvé ça chiant :-) Ce qui n'enlève rien aux très nombreuses qualité du logiciel, qui répond à un vrai besoin.

          • [^] # Re: J'ai arrêté d'utiliser paperwork

            Posté par (page perso) . Évalué à 2.

            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 ?

            • [^] # Re: J'ai arrêté d'utiliser paperwork

              Posté par . Évalué à 4.

              1) Quel rapport entre un label "fiche de paie" et des labels de date ?

              La question c'est comment je trouve mon fichier :-) Ton point deux y répond, on a une différence d'utilisation. De mon côté, je scan le tas de documents de temps en temps. J'ai donc des dizaines de fichiers avec la même date (que je ne change pas, je suis fainéant. Et je ne savais pas qu'on pouvait la changer).

              Quelque-chose comme #423 ?

              Oui. Le but concret, c'est de trouver rapidement les fichiers sans avoir besoin de lancer paperwork (accès distant notamment). Et sans avoir besoin d'aller lire les fichiers labels un par un.

              • [^] # Re: J'ai arrêté d'utiliser paperwork

                Posté par (page perso) . Évalué à 1.

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

                • [^] # Re: J'ai arrêté d'utiliser paperwork

                  Posté par . Évalué à 3.

                  L'intérêt, c'est de coller un peu plus à l'esprit « Unix » qui est que le système de fichier est une API « simpliste » mais quand même commune à pas mal d'outils : utiliser des noms de fichiers significatifs et organisés hiérarchiquement est « la base ». Après, si tu n'as pas de catégorie ou de tag « principal » pour un document, ça va être un peu plus complexe à adapter, mais je trouve également que ça serait un grand plus si ton logiciel savait le faire.

                  Dire que « je peux lancer Paperwork partout » c'est ne pas comprendre l'approche Unix ou le FS est un accès partagé à « des données », sur lequel on applique un certain nombre de traitements avec des logiciels différents. Je sais que ça n'est pas à la mode aujourd'hui, où un service = une application, mais quand même, on est sur linuxfr :-)

      • [^] # Re: J'ai arrêté d'utiliser paperwork

        Posté par (page perso) . Évalué à 2.

        Pour retrouver les documents depuis n'importe où, j'ai fait un petit outil. Même mon épouse, peu adepte de la technologie, arrive à l'utiliser :-)

        http://yalis.fr/cms/index.php/post/2016/01/21/Command-line-and-Web-Interface-for-Paperwork

  • # Super application

    Posté par . Évalué à 4.

    Bonjour

    Je remets mes remerciements au(x) développeur(s).

    Super application qui m'est bien utile.

    Merci

    • [^] # Re: Super application

      Posté par (page perso) . Évalué à 3.

      Idem !

      Je me sers de la version 2.4 depuis des mois, légèrement car heureusement pas trop de paperasse à gérer, et j'en suis très satisfait. J'utilise régulièrement les fonctionnalités d'édition cut/resize et export.

      Version 3 installée sans difficulté sur Arch Linux, à l'exception d'une dépendance manquante: python2-simplebayes. Je l'ai installée séparément depuis AUR et c'était réglé.

  • # Paperless

    Posté par . Évalué à 4.

    Il y a paperless qui fait exactement la même chose, en python aussi, et qui est "trending" en ce moment sur github. Est-ce qu'il y a eu une influence quelconque de l'un sur l'autre? Est-ce qu'il serait envisageable de rendre les deux compatibles ? (synchroniser paperwork avec un serveur paperless)…

    • [^] # Re: Paperless

      Posté par (page perso) . Évalué à 3.

      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.
    • [^] # Re: Paperless

      Posté par (page perso) . Évalué à 2.

      Tu as un lien? Si je cherche "paperless linux" dans un moteur de recherche, j'ai trouvé des articles sur paperwork, mais pas paperless!
      Et sur github, je trouve plus de 100 repos! Aucun moyen de savoir lequel est le repo upstream (c'est un des trucs pour lequel je comprends pas l'engouement pour github d'ailleurs!).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Paperless

        Posté par . Évalué à 3. Dernière modification le 18/02/16 à 14:18.

        Aucun moyen de savoir lequel est le repo upstream (c'est un des trucs pour lequel je comprends pas l'engouement pour github d'ailleurs!).

        Tu n’as pas quasiment pas d’upstream et de forks, si tu excepte le premier résultat qui s’est fait pas mal forker (et tu ne vois aucun des forks dans la première page de résultats). C’est une trentaine de projets différents qui ont pris le même nom.

        Pour trouver l’upstream sous github c’est simple : prend https://github.com/pitkley/paperless par exemple, tu as "forked from" sous le nom qui est un lien vers l’upstream, en l’occurrence https://github.com/danielquinn/paperless.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.