Paperwork est un outil pour faciliter la gestion de la paperasse de tous les jours. Il a été conçu pour les flemmards désorganisés comme moi, dans une optique de « scan & forget » : vous devriez pouvoir juste scanner un document, l'enterrer dans une pile de papiers quelconque, et quand même le retrouver le jour où vous en avez besoin. Après tout, trier est un travail de machine.
À chaque scan, Paperwork se charge de passer un coup d'OCR sur le document et de l'indexer. Comme l'OCR est imparfaite, il est aussi possible de mettre des labels sur le document. Aujourd'hui, la dernière fonctionnalité voulue pour Paperwork 0.1 a été implémentée. Maintenant, avant de faire une première release, il reste à tester tout ça. C'est là que votre aide sera précieuse : il faut des testeurs.
NdM : merci à Jérôme Flesch pour son journal.
Pour devenir testeur, il faut les choses suivantes :
- Une distribution GNU/Linux
- Un scanner compatible Sane
- Savoir remplir un rapport de bug (en anglais de préférence)
- Du temps à tuer
Attention, la branche Git à tester est la branche "testing" (branche par défaut). La branche "unstable" est celle où va commencer le développement de la 0.2.
Pour mettre l'eau à la bouche de ceux qui ne l'auraient pas déjà testé, voici une jolie capture d'écran pas-complètement-à-jour :
Merci beaucoup à ceux qui l'ont déjà testé, et merci d'avance à ceux qui vont le faire,
Aller plus loin
- Journal à l'origine de la dépêche (340 clics)
- Paperwork (1236 clics)
# petits retours rapides
Posté par fravashyo . Évalué à 4.
C'est un beau projet.
Je l'ai testé rapidement, à partir de PDF scannés, et bien que les pdf soit de taille assez réduite, l'OCR était potable.
Quelques commentaires en vrac :
les 13 dépendances, dont la plupart en en python, font un peu peur : on se dit par exemple que si l'une d'elle n'est plus supportée dans le futur, il sera difficile de péréniser la base de données que l'on se constitue grâce à cet outil.
je n'ai pas vu le nom d'origine des fichiers pdf importés, dans la liste des documents (juste l'image de la page) : or j'essaye justement d'avoir le nom le plus parlant possible pour m'y retrouver (par exemple avec locate si je fais une recherche sur le nom "edf" + "2013-01" je sais que ça va me retourner la ou les factures edf de janvier 2013)
Ça utilise gtk3, sur mon bureau xfce le rendu du toolkit est plutôt moche mais tu n'y peux rien (dans le style de ça https://bbs.archlinux.org/viewtopic.php?id=118078)
je n'ai pas testé le scan, uniquement l'import de PDF (je n'ai pas de scanner fonctionnel pour le moment) : j'ai essayé de faire un export ensuite de mon résultat avec OCR, ça m'a proposé une boîte de dialogue avec le nom du fichier à exporter, mais ensuite il n'y a rien sous ce nom dans le dossier que j'ai choisi.
En fait, peut-être que j'utilise ton logiciel pour autre chose que ce dont il est conçu : j'aime l'idée de pouvoir avec un PDF mixe avec à la fois l'image et le texte OCRisé, et j'ai commencé par regarder de ce côté, mais peut-être que je devrais plutôt voir du côté de pdfsandwich
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: petits retours rapides
Posté par Jérôme Flesch (site web personnel) . Évalué à 5.
Pour les 13 dépendances, c'est juste une question pour moi de ne pas réinventer la roue. Quant à la pérennisation de la base de données, pour l'heure, la question ne se pose pas : l'organisation du répertoire de travail est très simple et fait usage de bêtes fichiers JPG et hOCR (text/html) (cf la doc de hacking). C'est ce répertoire qui fait référence, et l'index est automatiquement mis à jour en conséquence au démarrage de Paperwork.
Pour les noms: L'objectif est "scan&forget", pas "scan&name&forget" :). Déjà devoir labeliser les documents est une étape de trop à mon goût (mais j'ai quelques idées pour arranger ça). Je ne souhaite pas encourager les utilisateurs à nommer systématiquement leurs documents. D'après mon expérience, les miniatures suffisent à reconnaitre un document bien plus vite qu'un nom.
Il est toutefois possible, au besoin, d'ajouter des mots clefs sur le document, mais pas de le nommer. Si tu y tiens vraiment, tu peux renommer le dossier contenant le document différemment de la nomenclature normalement adoptée. Dans ce cas, Paperwork utilisera le nom du dossier tel quel sans essayer de le parser. Ça va faire des misères pour ordonner ensuite les documents mais bon.
Pour les exports PDF, le texte n'est pas encore inclus dans le PDF généré. À noter aussi que lorsqu'on exporte en PDF un document qui était un PDF à l'origine, Paperwork se contente de faire une copie. (c'est vrai que je n'ai pas vraiment pensé au cas du PDF qui a l'origine ne contient pas de texte mais que une image)
# Forces et Faiblesses
Posté par Glandos . Évalué à 6.
Je suis Paperwork depuis très longtemps (en fait, depuis le premier journal là dessus), car j'aime beaucoup l'idée.
Dans l'ensemble, l'effort n'est pas vain, mais j'aurais deux critiques :
- l'IHM est un peu bizarre, il faudrait peut-être dessiner quelque chose sur un papier avant de la refaire, mais ce point mériterait qu'on s'y attarde;
- l'installation via des dépendances multiples de modules Python sur GitHub force l'utilisation de virtualenv, pas très pratique actuellement.
Ce ne sont pas des critiques très constructives, dans le sens où elles n'apportent pas de solutions. C'est un ressenti.
Je continue de suivre les évolutions cependant, mais je tiens à préciser que mon utilisation sera beaucoup plus de l'import direct en PDF, car je peux scanner « en masse » au boulot et revenir avec ces fichiers chez moi.
[^] # Re: Forces et Faiblesses
Posté par Jérôme Flesch (site web personnel) . Évalué à 4. Dernière modification le 06 mai 2013 à 10:34.
Je suis toujours ouvert à la discussion. J'invite ceux qui ont des idées à venir en discuter sur la mailing-list (en anglais, please). Pour l'IHM, l'idéal serait d'en discuter mock-ups à l'appui. Glade, bien qu'un peu buggué, peut être assez pratique pour ça.
Pour les dépendances Python, disons juste que je préfère en avoir beaucoup plutôt que de réinventer la roue. Après, à terme, ça sera aux gestionnaires de paquets de résoudre ce problème.
[^] # Re: Forces et Faiblesses
Posté par Juke (site web personnel) . Évalué à 3.
Ha c'est toi !
# Dépendances rédhibitoire
Posté par vlamy (site web personnel) . Évalué à 7. Dernière modification le 06 mai 2013 à 11:37.
Salut, comme je l'avais mentionné dans un précédent journal, j'ai essayé d'installer paperwork sur une distribution Linux non basée sur Debian (Archlinux en l'occurrence) et j'ai décidé d'abandonner à cause du problème des dépendances. Étant un gars plutôt acharné et têtu, je pense que si j'en suis arrivé là, d'autres arriveront à la même conclusion, alors je développe ma critique dans l'intérêt de ce projet, que je trouve très intéressant malgré le fait que j'ai abandonné son adoption. Voici les éléments par ordre d'importance qui m'ont fait abandonner le projet "paperwork" :
Mais je n'abandonne pas là car je vois que le projet est vivant et toujours très intéressant.
Étant également développeur de métier, je me permet de critiquer l'argument suivant :
Ta formulation est mauvaise, car tu peux très bien embarquer des releases des dépendances, qui à priori sont libres et compatibles avec la licence de ton logiciel. Donc si tu veux fournir un logiciel qui s'installe simplement (en exécutant un seul script) tu peux le faire ! C'est un peu de boulot, mais tu ne ré-inventeras rien du tout.
Mais bien que mal justifié pour moi, ton choix se défend quand même, car les dépendances sont inévitable (OCR, SANE…etc) et là c'est tout le problème du développement en générale qui se pose : « Dois-je garder des dépendances 100% à jours, ou travailler avec des releases vieillissantes? ». Je n'ai pas la réponse à cette question, car c'est une histoire de compromis. Mais ce qui est sûr, c'est que ton logiciel est difficile à installer, et que ça va incroyablement freiner son adoption. Ce qui, d'après ce que j'en ai vu, est très dommage.
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
La seule que je connaisse qui semble abandonnée est PIL (corrigez-moi si je me trompe). J'ai l'intention de la remplacer par Pillow.
Si tu en as vu d'autres, ça m’intéresse.
En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.
Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.
Je comprends qu'actuellement toutes ces dépendances sont problématiques. Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.
[^] # Re: Dépendances rédhibitoire
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 06 mai 2013 à 12:11.
Pour être dans les repos, il faut que ton logiciel soit relativement connu.
Pour être relativement connu, il faut que les gens puissent installer ton logiciel.
Donc se reposer uniquement sur les packageurs ne va pas faire démarrer la pompe… Bienvenue dans la vraie vie des packages Linux où aucune distro n'est pareille, et où il faut que tu commences, toi, à proposer quelque chose d'installable avant que ce soit dans les repos officiels, car les testeurs que tu demandes, en ils bloquent à l'installation vu qu'il n'y a rien dans les repos!
Non, ça ne se résoudra pas tout seul. Si tu veux des testeurs, il faut qu'ils puissent installer en dehors des repos officiels, c'est le premier test que des testeurs font (dans l’ordre des choses pour paraphraser quelqu'un ;-) )
Dans la vraie vie, en pratique, tant que tu ne seras pas super-méga-connu, si. Bienvenue dans le développement Linux de ceux qui ne s'appellent pas Valve (par exemple).
La packaging fait partie intégrante du développement (tu remarques que ce sont les premiers rapports de "bugs" de ton logiciel… Car ça en fait partie de ton ressort tant que personne d'autre ne se propose de le prendre en charge, ce qui semble être la cas actuellement)
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
Le fait est qu'un certain nombre de personnes ont déjà réussi à l'installer. Essentiellement des utilisateurs de Debian, Ubuntu et Fedora je présume. ArchLinux est plus problématique vu que la version par défaut de Python sur cette distribution est Python 3. C'est là encore un problème qui se résoudra de lui-même quand je ferais le passage à Python 3.
Le mieux que je puisse faire est de documenter la liste des dépendances, et pour les distributions les plus courantes, indiquer comment les installer. Je n'ai définitivement pas l'intention de me prendre la tête à faire un meta-package volumineux qui ne fonctionnera que sur une distribution sur deux. Je n'ai pas non plus l'intention de faire moi-même des paquets pour chaque distribution/architecture.
Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.
Euh non. Les 1ers rapports de bug sur Paperwork sont bien plus vieux et n'ont rien à voir.
[^] # Re: Dépendances rédhibitoire
Posté par vlamy (site web personnel) . Évalué à 2.
Entre un logiciel facilement portable et un logiciel dédié Debian, les mainteneurs Debian auront vite fait leur choix je pense. Bon, faudrait-il encore qu'il existe un concurrent sérieux à Paperwork (en fait, j'en sais rien). Mais tout ça pour montrer que la portabilité de ton logiciel va aussi dans l'intérêt de la communauté Debian.
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . Évalué à 5.
Je n'ai jamais dit que je comptais en faire un logiciel dédié Debian. J'ai juste dit que Debian est la distribution que j'utilise et sur laquelle je le développe, et que c'est donc la seule dans laquelle ça m'importe vraiment de voir Paperwork packagé. Si d'autres le packagent aussi, tant mieux, sinon tant pis.
Pour info, je teste aussi de temps en temps Paperwork sur Fedora et Ubuntu.
[^] # Re: Dépendances rédhibitoire
Posté par freem . Évalué à 3.
Je comprend que tu n'aies pas envie de maintenir des paquets pour toutes les distros, mais:
Pour le "comment faire":
Déjà, tu as pas besoin de t'embêter avec l'architecture cible, vu que tu sembles utiliser python, donc le nom de ton architecture sera "all".
Ensuite, il y a pleins de solutions, dont certaines qui demandent d'apprendre des procédures (les solutions propres ça, celles que je n'utilise pas ;) ) et d'installer des paquets… perso, j'ai eu la flemme, alors j'ai ouvert une archive (7z ou tar, choisi ton arme), j'ai regardé dedans, j'ai vu que c'était simple alors j'ai semi-automatisé la procédure. C'est crade dans le principe, mais dans la pratique ça marche proprement (et c'est ça qui m'intéresse au final).
J'ai eu besoin à un moment d'utiliser une dépendance à une lib (pluma-framework) qui n'était pas packagée (ni même testée sous autre chose que windows, pour être précis, et en plus hébergé sur un svn… d'où le "fork" qui me sers de laboratoire pour fixer les bugs que je remonte ensuite upstream avec les patchs) pour laquelle j'ai créé un patch.
J'ai du coup fait quelques scripts à la va-vite, si tu es intéressé, tu peux les récupérer et les adapter, ils sont ici.
Tu noteras que j'ai créé un répertoire par architecture ciblée, puis pour chaque architecture un nouveau pour chaque paquet final. Ce répertoire de paquet final contiens 2 choses: un "squelette" de l'arborescence qui sera affectée par le paquet, et un dossier "DEBIAN" qui lui contiens juste un fichier "control". Il te suffit de modifier ce fameux fichier, et de lancer les scripts (que tu auras naturellement lus et adaptés avant, vue leur tronche, c'est vraiment pas compliqué… tu noteras que j'ai bien dis qu'ils sont faits à la va-vite hein… faudrait que je les améliore, mais je ferai ça à mon prochain projet je pense, ou alors j'apprendrai à faire des trucs propres) et tu récupéreras en sortie tes paquets "deb".
Note: je n'ai utilisé que le fichier "control" qui ne contiens donc pas de signature. Une façon plus propre de faire les choses aurait été de créer un fichier ("sum" il me semble) qui contiens les hash des fichiers contenus dans ton paquet, et tu aurais ainsi même pu permettre de certifier que les fichiers n'ont pas été modifiés lors du transfert…
[^] # Re: Dépendances rédhibitoire
Posté par flan (site web personnel) . Évalué à 2.
Pour info, construire un paquet en Python est assez simple, quand on a un fichier setup.py déjà existant.
Il faut utiliser (python-distribute) et la commande supplémentaire bdist_stdeb.
Après, python setup.py permet de construire en ligne de commande des paquets .deb, .rpm, .tar.gz (binaire ou source), .exe, …
[^] # Re: Dépendances rédhibitoire
Posté par maboiteaspam . Évalué à 3.
Je ne renie pas, car j'en sais foutre rien, mais alors qu'est ce que cela me surprend….
Si tant est qu'on ai parlé d'une lib machin du sous système y nécessaire au démarrage, je n'aurais pas sourcillé d'un poil.
Mais là non , son logiciel est situé à la toute fin de la chaîne des dépendances, il est construit autour des gestionnaires de paquets, et pourtant il doit faire l'inverse pour être éventuellement intégrable.
On peut même imaginer que sans le gestionnaire de paquets pour rapidement lui fournir un environnement de développement lui permettant de ce concentrer sur sa valeur ajoutée,
le logiciel n'aurait jamais vu le jour.
Bref, j'aurais bien aimé en comprendre la raison avant de me laisser aller à quelques conclusions hâtives.
[^] # Re: Dépendances rédhibitoire
Posté par vlamy (site web personnel) . Évalué à 2.
« Autour d'apt-get » serait plus juste.
Ça n'empêche pas qu'on va vouloir le tester avant de l'injecter dans les dépôts officiels.
[^] # Re: Dépendances rédhibitoire
Posté par freem . Évalué à 2.
Autour de dpkg le serait encore plus :)
[^] # Re: Dépendances rédhibitoire
Posté par maboiteaspam . Évalué à 1.
oui, je sais pas trop comment ca fonctionne, je prend pour comparaison des gestionnaire de dependances genre npm ou composer.
Tout y est fait pour t'amener à publier ta production.
A lire zenitram, faire un projet pour desktop linux semble hautement plus compliqué… en tout cas rédhibitoire en ce qui me concerne.
[^] # Re: Dépendances rédhibitoire
Posté par vlamy (site web personnel) . Évalué à 3. Dernière modification le 06 mai 2013 à 13:15.
Mea culpa ! Effectivement la question n'était pas posée comme ça, mais finalement l'utilisateur s'en fout un peu qu'il y est beaucoup de dépendances, si le logiciel est facile à installer, est à jours, et fonctionne correctement.
Je rejoins Zenitram sur le fait que si tu attends que ça tombe du ciel, tu vas freiner l'adoption de ton logiciel.
Pour moi, ça veut dire que tu n'as pas envie de faire le packaging (ça je crois qu'on l'a bien compris) et que tu t'en fout d'avoir beaucoup d'utilisateurs tant que tu peux faire marcher le projet. J'ai peur que ce genre de politique ne soit pas très vendeur.
Finalement, pour moi le problème majeur est ailleurs : prenons les choses du point de vue d'un packageur potentiel (j'avoue que je me suis posé la question, mais je suis moyennement motivé):
Encore une fois, je salue ton travail car il y a du mérite ! Mais je pense que mes critiques sont fondées, en tout cas c'est la réflexion que je me suis faite. Bref le problème du packaging est difficile dans ton cas, en plus c'est du Python et c'est pas le moment adéquate pour vendre du Python. Mais je suis sûr qu'en y mettant les formes et en fournissant un peu de travail, tu peux arriver à un résultat très prometteur.
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . Évalué à 2. Dernière modification le 06 mai 2013 à 13:56.
Je ne connais pas les politiques exactes de chaque distribution, mais je suis presque sûr que pour une distribution comme Debian, c'est une violation de leur politique. À ma connaissance, c'est toujours un package par librairie ou programme. Il me semble clair que pour eux, il est hors de question de faire un paquet contenant un programme et 10 librairies. Sinon l'intérêt des dépendances se perd, et on en arrive à ce que font les installateurs Windows ou PC-BSD.
Au final, que je package ou pas Paperwork avec ses dépendances n'aidera en rien les packageurs des distributions.
Nop. Mon poil dans la main est trop gros pour supporter des OS propriétaires. Si quelqu'un veut le faire, qu'il se fasse plaisir, mais je ne le ferais pas. Par contre, je veux bien faire du support pour cette personne si elle en a besoin et je ne suis pas contre l'inclusion de patchs ayant pour but la portabilité.
Sur ce point on est d'accord. C'est pour ça que j'essaye de maintenir une liste des dépendances aussi complète que possible. C'est aussi pour ça que j'essaye d'éviter les dépendances ésotériques et que je favorise autant que possible les librairies déjà disponibles dans Debian. (je n'aime pas plus qu'un autre avoir 25 librairies installées en dehors de mon gestionnaire de paquets)
[^] # Re: Dépendances rédhibitoire
Posté par vlamy (site web personnel) . Évalué à 1.
Au final on est d'accord sur la technique, je suis d'accord sur le fait que la plupart des dépendances doivent être packagées à part. Pour les OS proprio je suis d'accord aussi.
Je voulais juste montrer que c'était dur de faire un paquet de ce logiciel. Et honnêtement, je pense que si tu te fends de faire un paquet Debian pour ta V1 et que tu repasses demander des testeurs, tu auras beaucoup plus de succès. Y compris auprès des non debianistes :)
[^] # Re: Dépendances rédhibitoire
Posté par freem . Évalué à 3.
Pas tant que ça, dès lors que l'on connaît les dépendances du dit logiciel. Ou alors, tu ne parles des fichiers deb… (cf plus haut ou j'explique comment j'ai fait un truc à la va-vite…)
On oublie généralement dans les intérêts que ça permets aussi de simplifier la vie du dev: déjà, plus de plaintes "ouin y'a pas de paquet pour debian" (y'a toujours les mêmes pour fedora et arch, forcément…) mais surtout ça simplifie la galère avec les versions.
Pour le fait d'avoir plus facilement des testeurs, je suis assez d'accord par contre.
[^] # Re: Dépendances rédhibitoire
Posté par vlamy (site web personnel) . Évalué à 1. Dernière modification le 06 mai 2013 à 16:37.
J'entends de faire un paquet par dépendances :)
Mais cela dit, je suis d'accord sur le fait qu'il vaut mieux avoir un paquet qui embarque toutes les dépendances que pas de paquet du tout. Dans ce cas, je ferais juste attention à utiliser un environnement spécifique pour le logiciel en question, afin que les libs embarquées ne polluent pas l'environnement de l'utilisateur (Par chance, Python se prête très bien à ce genre de gymnastique). Je pense au cas où on installe une lib embarquée avec un logiciel arbitraire, puis qu'on installe cette même lib par la suite via le gestionnaire de paquet. Ça m'est déjà arrivé en Java et c'est assez subtile à trouver comme bug !
Finalement on a trouvé une solution assez propre pour Paperwork :) Y a plus qu'à !
[^] # Re: Dépendances rédhibitoire
Posté par freem . Évalué à 1.
Pour le 1er point, je maintiens. C'est juste un peu chiant la première fois parce qu'il faut paramétrer chaque paquet que l'on souhaite générer, mais après, il suffit de faire 2-3 scripts et ça se fait tout seul… après tout, dans un paquet debian, a part la version et parfois des dépendances à ajouter/supprimer, rien ne change.
La version peut s'automatiser à coups de sed/awk je pense, et les dépendances, de toutes façon quand on mets à jour on les vérifies… ou alors on s'expose à des emmerdes a n'en plus finir.
Pour le 2nd, je n'ai pas d'avis. Personnellement, je pense que dès l'instant ou l'on fait 1 paquet pour un logiciel, il n'y a pas grand chose qui empêche de faire des paquets pour les autres: le principe est le même, il n'y a que les fichier DEBIAN/control à modifier, ce n'est pas la mer à boire tout de même.
En revanche, je me suis fais la réflexion il y quelques minutes que, depuis le multi-arch, mes scripts ont une forte chance de tout péter si l'utilisateur installe d'abord i386 puis amd64, ou vice versa, sans supprimer l'ancienne (en gros: s'il fait n'imp, mais un utilisateur, c'est comme un ordinateur, si on part du principe qu'il va deviner ce qu'il faut faire, on s'expose aux emmerdes et aux crashs)… va falloir que j'ajoute une dépendance de conflit, ou que je fasse que la lib que j'ai empaquetée soit compatible multi-arch… je pense que je vais plutôt ajouter la dépendance de conflit, ça sera plus simple :D (faut que je me remette à autorealm un de ces 4 d'ailleurs)
[^] # Re: Dépendances rédhibitoire
Posté par jpic (site web personnel) . Évalué à 3.
Pour les dépendances, comptez sur pip: http://pythonhosted.org/distribute/setuptools.html?highlight=install_requires#declaring-dependencies
Issue #151: https://github.com/jflesch/paperwork/issues/151
[^] # Re: Dépendances rédhibitoire
Posté par vlamy (site web personnel) . Évalué à 1.
Je ne connais pas assez bien Python, mais il me semblait bien que ce genre d'outil existait. Il parait assez clair que c'est la solution propre.
[^] # Re: Dépendances rédhibitoire
Posté par freem . Évalué à 1.
Non…
… et oui, car je n'ai constaté que cet état de faits pour de très petits logiciels, pas pour des libs.
[^] # Re: Dépendances rédhibitoire
Posté par ALSimon . Évalué à 2.
C'est normal que tu ais constaté cela que pour des collections de logiciels et non pas pour des librairies : c'est la politique de Debian.
Il est autorisé de faire un paquet pour une collection de petits outils sous la même licence et dans le même domaine (tous les -utils en général).
Cependant, sous Debian, il est contraire à la politique d'embarquer les librairies de dépendance dans le paquet, et ce même si le développeur les a joint à son code source. Ce type de paquet sera systématiquement rejeté.
En effet, avoir plusieurs outils liés dans un paquet ne pose pas de problème (soit tu installes tout, soit rien, c'est le seul problème), mais si j'embarque les librairies dans mon logiciel, cela veut dire que je vais me retrouver avec potentiellement plusieurs versions des librairies sur mon poste… d'où des éventuels conflits, perte d'espace, problématique de mise à jour, …
La plupart des autres distributions ont une politique très semblable, généralement juste peut être un peu plus laxiste que Debian ;).
[^] # Re: Dépendances rédhibitoire
Posté par freem . Évalué à 1.
Je le sais, et très honnêtement, je trouve cette politique tout sauf stupide.
En fait, je répondait bien à la partie que j'ai citée, mais j'aurai dû étendre la citation pour qu'elle englobe ceci: "À ma connaissance, c'est toujours un package par librairie ou programme. "
# Import de photos
Posté par oao . Évalué à 4.
Je n'ai pas de scanner, mais un téléphone qui comme la grande majorité des smartphones actuels fait des photos en grande résolution. Est-il possible d'importer les photos dans Paperwork et de les recadrer automatiquement, en reconnaissant la feuille de papier ?
[^] # Re: Import de photos
Posté par Jérôme Flesch (site web personnel) . Évalué à 4.
Il est possible d'importer des images. Il n'y a toutefois pas de recadrage automatique. Paperwork permet juste une édition minimaliste des pages/images : rognage et rotation de 90/180/270 degrés.
Maintenant, je ne suis pas sûr qu'utiliser son téléphone pour scanner des documents soit une bonne idée. J'ai déjà entendu et lu plusieurs personnes se plaindre du temps que ça prend pour scanner les piles de papiers qu'ils avaient accumulées jusque là avec un scanner. Je ne peux qu'imaginer le temps que ça prendrait avec un téléphone (temps de transfert sur l'ordinateur et import dans Paperwork, photos partiellement floues à refaire, etc).
[^] # Re: Import de photos
Posté par oao . Évalué à 2.
Si j'avais un scanner, je l'utiliserai effectivement. Le problème est que c'est petit chez moi, que mon téléphone me suffit pour scanner mes fiches de paye, que je ne suis pas tout le temps chez moi et que si je peux économiser quelques dizaines d'euros, ce n'est pas plus mal. D'où l'utilisation du téléphone. Je ne pense pas être le seul à faire ça.
Je peux essayer de te faire un script pour redresser l'image automatiquement. Si tu veux bien l'intégrer dans Paperwork, je le code et je test le logiciel après.
[^] # Re: Import de photos
Posté par steph1978 . Évalué à 2.
il existe des montage sur le net pour utiliser un apn comme scanner. ça permet démettre l'appareil à la bonne distance et d'avoir le bon cadrage. j'imagine qu'il faut faire les réglages en fonction de sa configuration mais après ça doit gagner un temps fou.
# Héhé
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Salut Jérôme, je voulais te dire que j'aime beaucoup ton site web
Mais tu pourrais au moins mettre un lien vers Paperwork, quand même :)
Je te donne le code source en bonus ^v^
"<a href="https://github.com/jflesch/paperwork#readme">Paperwork</a> is a tool to make papers searchable."
# Dépendances pour Fedora ?
Posté par Skanx (site web personnel) . Évalué à 1.
Si quelqu'un a déjà compilé la liste des paquets Fedora à installer pour combler les dépendances de Paperwork, je suis preneur !
Sinon, je tenterai de m'y coller.
# Au sujet d'Archlinux
Posté par aplc (site web personnel, Mastodon) . Évalué à 1.
Le sujet a été abordé précédemment mais voilà : je suis bien intéressé par ce projet, je suis sous Arch mais je suis pas très fort. Si quelqu'un a les compétences/bonne volonté pour écrire un "howto install", je lui en serai infiniment reconnaissant !
Mon 1er commentaire sur linuxfr … ça fait drôle.
[^] # Re: Au sujet d'Archlinux
Posté par jpic (site web personnel) . Évalué à 2.
Voila l'idée.
# purge
Posté par coïn . Évalué à 2.
suggestion:
Le truc qui pourrait être intéressant, c'est de pouvoir mettre une date de péremption sur un document ou une catégorie de document.
Pour un mec qui vient de passer 4h dimanche à classer des papiers, je suis très attentif à l'évolution de ce projet :)
[^] # Re: purge
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
Pour la catégorie de document, un label devrait faire l'affaire, non ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# OCR
Posté par wysman . Évalué à 0.
Quel logiciel d'OCR est utilisée ?
[^] # Re: OCR
Posté par sifu . Évalué à 3.
L'information est disponible dans la page GitHub du projet fournie dans la dépêche (https://github.com/jflesch/paperwork#readme).
[^] # Re: OCR
Posté par wysman . Évalué à 0.
Merci
# rpm pour Mageia 2
Posté par Dimitri . Évalué à 2.
J'ai preparè des paquets pour Mageia 2.
Le paperwork et les dependences
Touts sont disponibles ici:
http://www.mageia-gr.org/rpm/2/noarch/
Par contre j'ai passè beaucoup de temps pour faire les rpm de toutes les dependences et je n' ai pas eu le temp encore de faire des tests. J'ai essayè de passer le ocr sur un document scannè et c' a marchè correctement
C'est une application laquelle je voudrais vraiment pour organiser mes papiers car je scan tout, mais difficile à retrouver apres …
Je voudrais poser une question:
Quand on passe un document scannè déjà dans paperwork et on fait un Redo OCR, ca veut dire que le contenu du document est désormais recherchable depuis d'autres applications ? example le recoll (utilise xapian)?
En fait, je n ai pas compris comment les documents sont exploitables à la suite.
Si il faut avoir tout les documents importès dans la liste à gauche du paperwork ca serait bien si on peut inserer plusiers documents à la fois et non un par un
Actuelement, j'ai mes documents organisès dans des dossiers dans le dossier Dropbox.
# PKGBUILD pour Arch Linux dispo dans AUR
Posté par -mat . Évalué à 3.
J'ai mis le PKGBUILD de paperwork-git pour Arch linux sous AUR (https://aur.archlinux.org/packages/paperwork-git/) avec les 2 ou 3 paquets qui manquaient.
Une chose qui me manque est de pouvoir importer tout une arborescence de PDF, car un par un c'est long !
[^] # Re: PKGBUILD pour Arch Linux dispo dans AUR
Posté par Jérôme Flesch (site web personnel) . Évalué à 1.
Essaye d'importer un dossier qui contient tout tes PDFs. Ça devrait déjà marcher. (importer un dossier de PDF est une problématique nettement plus simple qu'un dossier d'images)
[^] # Re: PKGBUILD pour Arch Linux dispo dans AUR
Posté par woprandi . Évalué à 2.
2 paquets sont à corriger : python2-pyocr-git python2-pyinsane-git
Et tu as oublié python2-pyenchant
[^] # Re: PKGBUILD pour Arch Linux dispo dans AUR
Posté par -mat . Évalué à 0.
Merci !
python2-pyenchant ajouté en dépendance…
Peux-tu m'indiquer ce qui ne va pas dans python2-pyocr-git et python2-pyinsane-git ?
[^] # Re: PKGBUILD pour Arch Linux dispo dans AUR
Posté par -mat . Évalué à 0.
Ok, c'est corrigé
# Installé sur Arch
Posté par woprandi . Évalué à 1.
Salut,
J'ai installé paperwork sur Arch via le paquet AUR : j'ai du corriger le PKGBUILD, je t'invite à le mettre à jour si tu t'en occupes, 2 paquets sont faux et il manque pyenchant.
Je vais essayé de tester ça
# Premier commentaire
Posté par Mindiell (site web personnel) . Évalué à 0.
J'ai découvert Paperwork via Linux Essentiel. Bravo, ça a l'air très intéressant !
Je teste dès ce week-end (si j'ai du temps)…
[^] # Re: Premier commentaire
Posté par Mindiell (site web personnel) . Évalué à 0.
Arf !
J'ai tenté l'installation ce soir, mais ça n'a rien donné…
Le apt-get ne trouve pas les paquets. Etant sur une 10.04, je me rends compte qu'il va falloir changer quelque chose et pas qu'un peu !
C'est dommage, je me faisais une joie de me débarrasser de mes papiers. Mais l'idée est intéressante, très intéressante…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.