Paperwork 1.0

Posté par  (site web personnel) . Édité par Davy Defaud, Nils Ratusznik, ZeroHeure et palm123. Modéré par Ontologia. Licence CC By‑SA.
Étiquettes :
88
9
nov.
2016
Bureautique

Paperwork est un programme de gestion de documents papiers (et PDF) conçu par un flemmard pour les flemmards. 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.

Le nom de code de cette version est « it's about time ! ».

Écran principal de Paperwork

Les principaux changements sont :

  • exportation : les fichiers PDF générés contiennent maintenant le texte de l’OCR ;
  • exportation : une option pour simplifier les pages et documents exportés a été ajoutée, elle est basée sur les algorithmes de unpaper (simplification « douce ») et SWT (simplification « aggressive ») et permet d’avoir des fichiers en sortie plus petits ;
  • édition des pages : les couleurs des numérisations peuvent maintenant être ajustées automagiquement au besoin ;
  • séparation du code backend et du code frontend (paquets Python séparés et dépôts Git séparés) ;
  • passage à Python 3 ;
  • passage de Pyinsane 1 à Pyinsane 2 ;
  • ajout d’une fenêtre de diagnostic pour aider au débogage ;
  • portage vers Windows en cours.

Paperwork est diffusé sous licence GPL v3 ou plus.

Aller plus loin

  • # 1.0

    Posté par  . Évalué à 10.

    Bon, je n'ai plus d'excuse pour ne pas l'utiliser mais la pile est haute.

  • # Synology ?

    Posté par  . Évalué à 3.

    Ce type d'application m’intéresse fortement, mais je n'ai jamais réussi à l'installer sur mon NAS qui ne supporte pas docker (synology 214Play).

    Quelqu'un a-t-il réussi à installer paperwork sur son Syno ?

    • [^] # Re: Synology ?

      Posté par  (site web personnel) . Évalué à 6.

      Tu n'es pas obligé d'installer Docker non plus.

      Paperwork s'installe aussi directement, sans Docker, mais c'est plus long, c'est vrai.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # Bravo!

    Posté par  (site web personnel) . Évalué à 8.

    Pas mal comme concept! J'aime bien la baseline, scan & forget, c'est exactement ce qu'il faut pour que ce type d'outil devienne populaire.

  • # plantage...

    Posté par  . Évalué à 4.

    Bonjour,

    Ca m'intéresse beaucoup, mais je ne réussis pas à le démarrer. Je suis sous Debian, et j'ai suivi les instructions d'installation avec PIP. J'ai les messages suivants :

    WARNING paperwork.paperwork No suitable localization file found.
    WARNING paperwork_backend.util Unknown language [fr]. Switching back to english
    WARNING paperwork_backend.util Unknown language [eng]. Switching back to english
    …
    Fatal Python error: Cannot recover from stack overflow.

    Une idée pour m'aider ?

    Merci.

  • # Ambiguïté mais bonne surprise

    Posté par  . Évalué à 2.

    Je m'attendais à lire un article sur cette app http://paperwork.rocks/, aussi utile pour la recherche.

    Peut-être serait-il bon de vous différencier.

    Mais je découvre avec plaisir ton travail. Est-ce qu'il serait possible par ex. de scanner un bouquin (une centaine de pages), de bénéficier de l'OCR, et d'en avoir une centaine comme ça, sans perdre en qualité de recherche ?
    Par ex., je charge ma centaine de fichiers PDF, qui sont des livres scannés, il y a une reconnaissance du texte grâce à l'OCR, et ensuite je fais une recherche du mot "dendrite", et il me sort chaque livre qui en parle, avec les pages où le mot est mentionné, avec une rapidité de recherche convenable ?

    • [^] # Re: Ambiguïté mais bonne surprise

      Posté par  . Évalué à -1.

      Tu as googleBooks pour ça
      :þ

      =>[ ]

    • [^] # Les performances

      Posté par  . Évalué à 1.

      C'est vrai que c'est super alléchant ! mais il n'est pas inutile d'avoir une petite idée des performances/capacités/limitation !

      je suis preneur d'info/retour :)

    • [^] # Re: Ambiguïté mais bonne surprise

      Posté par  (site web personnel) . Évalué à 2.

      Non seulement la page, mais aussi une mise en évidence dans la page de chaque occurrence.

      Alors que Mayan ne va te donner que la page.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Ambiguïté mais bonne surprise

      Posté par  (site web personnel) . Évalué à 9. Dernière modification le 14 novembre 2016 à 17:19.

      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>

    • [^] # Re: Ambiguïté mais bonne surprise

      Posté par  (site web personnel) . Évalué à 4.

      une recherche du mot "dendrite", et il me sort chaque livre qui en parle

      Une commande du nom de pdfgrep pourrait sans doute vous aider ☺

      kentoc'h mervel eget bezan saotred

      • [^] # Re: Ambiguïté mais bonne surprise

        Posté par  . Évalué à 0.

        AFAIK, pdfgrep ne fonctionne que sur la partie texte des PDF, pas sur les images embarquées, qui sont typiquement produites par les logiciels de scan.

        • [^] # Re: Ambiguïté mais bonne surprise

          Posté par  . Évalué à 2.

          C'est pour ça qu'il y a un OCR dans paperwork, ça crée un calque invisible avec le texte correspondant à l'image (je ne connais pas les termes exacts). La recherche se fait évidemment dans le texte, on ne lance pas l'OCR à chaque fois qu'on cherche un mot.

          Cette signature est publiée sous licence WTFPL

  • # docker !

    Posté par  . Évalué à 2.

    Ravi de voir que tu sois passé au docker, c'est nickel !
    Ce type d'outil me parait hyper utile.

    Quelques commentaires :
    - on ne peut importer qu'un fichier a la fois ?
    - open directory plnate le docker: sh: 1: xdg-open: not found
    - quand tu fais une recherche par mot-cle, comment faire pour voir l'endroit du document qui contient ce mot-cle ?

    Merci pour ce soft.

    • [^] # Re: docker !

      Posté par  (site web personnel) . Évalué à 3.

      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.

    • [^] # Re: docker !

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 novembre 2016 à 17:38.

      J'ai failli oublier:

      • on ne peut importer qu'un fichier a la fois ?

      Une image (JPG, PNG, etc) à la fois oui. Sinon c'est compliqué de deviner où la placer.

      Par contre, pour les PDFs, c'est déjà possible. Il suffit d'indiquer à Paperwork un dossier contenant plusieurs PDFs. Il va le parcourir (récursivement si ma mémoire est bonne), et importer chaque PDF comme un document distinct.

      • open directory plnate le docker: sh: 1: xdg-open: not found

      Euh, xdg-open fait partie des normes freedesktop à ma connaissance. Il faudrait l'inclure dans l'image Docker en fait.
      Quoiqu'il en soit, ce sera résolu dans la version 1.0.3. Au lieu de xdg-open, cette version utilisera Gtk.show_uri() qui semble bien plus fiable.

      • quand tu fais une recherche par mot-cle, comment faire pour voir l'endroit du document qui contient ce mot-cle ?

      Tu cliques sur le document .. :-)
      Plus sérieusement:
      - quand les pages sont affichées en grille, celles qui contiennent un des mots clés sont entourées en vert.
      - quand elles sont affichées en liste (en grand), les mots clés eux-mêmes sont entourés en vert.

      Par contre, ça met quelques secondes à s'afficher.
      (et en terme de clarté d'affichage, j'ai encore du travail ..)

  • # layout de répertoire ?

    Posté par  (site web personnel) . Évalué à 5.

    Est-ce que tu comptes vraiment sur une stabilité de la forme de tes répertoires de données ?

    J'ai vraiment mal vécu la gestion "je mets des trucs partout" ou "j'ai un format rien qu'à moi" des gestionnaires de photo d'il y a 10 ans. Depuis c'est moi qui décide, et c'est toujours lisible et utilisable, 10 ans plus tard ou presque.

    J'imagine bien que ce genre de format est un peu spécial mais as-tu prévu que cela soit encore utilisable dans 10 ans, même si ton outil ne fonctionne plus ? (format txt et pas binaire, image "normal"…)

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

    • [^] # Re: layout de répertoire ?

      Posté par  (site web personnel) . Évalué à 6.

      Oui!

      je pourrait m'arrêter là, mais …

      En fait, il me semble que c'est bien documenté la manière dont les données sont organisées.
      Il y a un index, et les scans.
      On ne peut pas faire plus simple.

      Il y a seulement un formalisme à respecter pour le nom des fichiers et le contenu de l'index.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: layout de répertoire ?

        Posté par  (site web personnel) . Évalué à 9.

        Jusqu’à présent, c’est très stable. J’utilise Paperwork depuis la version 0.1, et j’y ai adjoint ma propre interface CLI et WEB de recherche, ainsi qu’un ajout automatique de document par dépôt dans un répertoire-sas (basé sur inotify, qui intègre directement le document dans l’arborescence). Aucun problème de compatibilité à signaler jusqu’à présent :-)
        Bravo jflesch !

        • [^] # Re: layout de répertoire ?

          Posté par  . Évalué à 2.

          Si tu en as le temps et l'envie, je serais ravi d'avoir le code de tes interfaces, et de ton ajout automatique

          • [^] # Re: layout de répertoire ?

            Posté par  (site web personnel) . Évalué à 3.

            Salut,

            • Pour les interfaces web et cli :

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

            Les limitations dont j’ai connaissance :
            — Les pages affichées sont celles qui possèdent une miniature (thumbnail). J’ai constaté depuis la refonte IHM (v0.3) que les miniatures des pages 2 et + ne sont pas toujours générées (ils ont l’air d’être faits à la demande). Ça ne m’a pas gêné jusqu’à présent car je connais mes documents et je peux consulter les autres pages en changeant l’URL :-p Mais c’est sûrement très simple à corriger.
            — Les mots-clef additionnels ne sont pas du tout exploités.

            • Pour le dépôt automatique, il n’y a pas de code. Tous mes documents sont sur mon serveur, sur lequel /partage est un partage NFS ; mes documents sont dans /partage/Papiers. J’ai créé un répertoire /partage/Papiers.import ainsi que l’incrontab suivant : /partage/Papiers.import IN_CLOSE_WRITE,IN_MOVED_TO bash /home/yves/.local/bin/paperwork.import.sh $@ $# Le contenu du script est le suivant :
            #!/bin/bash
PW_DATA=/partage/Papiers

[[ $2 =~ ^([0-9]{8}|x)(\+[^-+]+)*(-.*)?\.pdf$ ]] || exit

IFS=- read d c <<<"${2%.pdf}"
IFS=+ read d l <<<"$d"
[ "$d" == x ] \
&& read d hm s < <(date +'%Y%m%d %H%M %S') \
|| read   hm s < <(date        +'%H%M %S')

[ -e "$1/$2" ] || exit

p="$PW_DATA/${d}_${hm}_$s"
{ mkdir "$p" &>/dev/null || {
    for s in {01..99}; do
      mkdir "${p}_$s" &>/dev/null || continue
      p="${p}_$s"
      break
    done
  }
} \
&& mv "$1/$2" "$p/doc.pdf" \
&& {
  [ -n "$l" ] && {
    tr + '\n' <<<"$l" | while read str; do
      grep -hFim 1 -e "$str" "$PW_DATA"/*/labels | tail -n 1
    done >"$p/labels"
  }
  pdftoppm -jpeg -r 18 -q "$p/doc.pdf" "$p/tmpthb"
  for f in "$p/tmpthb"*; do
    mv "$f" "${f%/*}/paper.$(cut -d- -f2 < <(basename "$f" .jpg)).thumb.jpg"
  done
}

            Les fichiers que je dépose dans le répertoire sont forcément en PDF et se nomment AAAAMMJJ+label+label…-….pdf, ou x+label+label…-….pdf, avec AAAAMMJJ la date du document (juste « x » pour avoir la date du jour), les labels étant facultatifs (il suffit de donner une sous-chaîne du label, en ignorant la casse). Exemple : je crée « x+thierry+61-.pdf » et ça me crée /partage/Papiers/20161115_1654_12, contenant :
            — doc.pdf
            — paper.1.thumb.jpg
            — paper.2.thumb.jpg
            — paper.3.thumb.jpg
            — labels avec ce contenu :

            Thierry Immobilier,rgb(149,79,54)
            61@3 rois,rgb(255,255,0)

            Limitations :
            — Partant du principe que les PDF ainsi intégrés sont reçus par mail et sont des PDF « texte » et non des PDF « image », rien n’est fait pour créer un fichier de mots (words).
            — Je n’ai pas tenté d’importer ainsi des PDF en même temps que Paperwork fonctionne. Je pense que Paperwork n’apprécierait pas…

            Yves.

            • [^] # Re: layout de répertoire ?

              Posté par  (site web personnel) . Évalué à 3.

              Je n’ai pas tenté d’importer ainsi des PDF en même temps que Paperwork fonctionne. Je pense que Paperwork n’apprécierait pas…

              En fait, il ne le verra juste pas jusqu'à son prochain démarrage. Quand il redémarrera, il le verra au moment où il parcours le répertoire de travail pour trouver les changements.
              Je pense que le seul risque, c'est une collision de nom quand Paperwork tente d'ajouter un document. Mais vu qu'il y a les secondes dans les noms de fichiers, ça me semble très improbable.

    • [^] # Re: layout de répertoire ?

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 novembre 2016 à 17:30.

      L'organisation du répertoire de travail est documentée ici:
      https://github.com/jflesch/paperwork/wiki/Work-directory-organization

      L'organisation des fichiers est effectivement spécifique à Paperwork. Mais les formats des fichiers sont tous standards (JPEG, hOCR, CSV et PDF), et je pense pouvoir dire que cette organisation se prête bien au scripting shell.

      Ceci dit, pour bien plus tard, il y a quelques évolutions possibles envisagées pour les documents scannés :

      • Zipper les fichiers d'un même document ensemble. Je me dis que ça pourrais économiser un peu les inodes et les blocs disques partiellement utilisées. À voir si ça serait vraiment utile.
      • Utiliser le format DjVu. Là le problème, c'est qu'il y a djvulibre pour lire les fichiers DjVu, mais il n'y a aucune librarie C/C++/Python pour en créer (attention, je ne parle pas de wrapper autour des commandes de DjvuLibre ; ça il y en a plein, mais c'est saleeuuuu).
      • Stocker les labels dans une base sqlite. Parce-que le problème actuellement, c'est que les opérations sur les labels ne sont pas atomiques du tout. Si tu changes le nom d'un label mais qu'une coupure de courant zigouille Paperwork pendant l'opération vous allez avoir une moitié de labels modifiés et pas l'autre.

      • [^] # Re: layout de répertoire ?

        Posté par  (site web personnel) . Évalué à 3.

        Ne fais surtout pas ça ! :) Ton outil deviendrait indispensable pour lire les documents.

        Tu peux avoir une base sqllite comme mozilla pour gérer les plantages ou un cache, mais pas pour contenir les donnés.

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

        • [^] # Re: layout de répertoire ?

          Posté par  . Évalué à 1.

          Les documents peuvent rester sur le filesystem, et les métadonnées dans la base de données. Rien de choquant.
          Ou alors tout en base de données, comme Sharepoint, mais il faudra alors prévoir des possibilités d'export.

        • [^] # Re: layout de répertoire ?

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 17 novembre 2016 à 16:55.

          Ton outil deviendrait indispensable pour lire les documents.

          Il me semble que sqlite3 peut être utilisé avec des scripts shell sans problème. Je ne suis donc pas convaincu que ce soit un problème.

          Ce qui me gêne déjà un peu plus, c'est la synchro avec des outils comme SparkleShare ou OwnCloud .. Je présents qu'ils vont re-uploader toute la BDD sqlite à chaque modification. Sur ma connexion ADSL moisie à 200ko/s / 75ko/s max, ça va piquer :/

          • [^] # Re: layout de répertoire ?

            Posté par  (site web personnel) . Évalué à 2.

            Je confirme… Personnellement, je synchronise mon dossier paperwork avec syncthing, ça deviendrait un peu lourd avec une bdd…

            La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

  • # Installation sur Mageia

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 12 novembre 2016 à 13:36.

    for the record…
    j'ai dû installer qqs packages de dev:
    $ urpmi python-dev lib64python3-devel lib64tiff-devel liblcms2-devel
    $ sudo python3 -m pip install paperwork
    j'avais peut-être déjà des dépendances installées par ailleurs, je ne sais pas…

    sinon ça a l'air super, je vais me débarrasser d'un paquet de papiers ;)

  • # Debian

    Posté par  (site web personnel) . Évalué à 7.

    Comment ce fait il qu'un logiciel aussi génial ne soit pas packagé pour Debian ? Je suis outré, je m'insurge, je ne vais pas en dormir de la nuit, je suis au bord de la syncope :-D

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Debian

      Posté par  (site web personnel) . Évalué à 5.

      Du temps de Paperwork 0.2, plusieurs s'y sont essayés et ont abandonné. Au final, seul PyOCR a été packagé, mais la version dans Debian est maintenant complètement obsolète :(

      Le problème vient surtout des dépendances. Même si ça été simplifié depuis la 0.2, il faudrait quand même packager:

      Ce sont des modules Python tout ce qu'il y a de classique, donc je suppose qu'une fois le premier fait, les autres sont faciles à faire.

  • # Tuto / Procédure / Notice ?

    Posté par  . Évalué à 3.

    Bonjour existe t'il un tuto ou une procédure ou une notice utilisation de ce logiciel car honnêtement installé aucun soucis sous debian mais après je suis perdu complet :/

    • [^] # Re: Tuto / Procédure / Notice ?

      Posté par  (site web personnel) . Évalué à 6.

      Les contributeurs et moi-même avons essayé de faire un logiciel aussi intuitif que possible. Pour moi, l'interface est très claire et explicite (sinon je ne l'aurais pas fait comme ça ;). Du coup je ne suis pas trop sûr de ce qui devrait être documenté ("tout" diraient certains, mais je manque de temps, et maintenir une doc détaillée à jour est un poids en plus non négligeable).

      Je te propose de prendre le problème dans l'autre sens : Qu'est-ce qui ne te semble pas clair ? / Qu'est-ce que tu essayes de faire avec ?

  • # Flatpak

    Posté par  . Évalué à 2.

    Bonjour,

    merci pour le soft!
    Est-ce qu'un flatpak est prévu pour faciliter l'installation cross distrib ?

Suivre le flux des commentaires

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