Tu es sur Linuxfr, un site dédié à un OS au parts de marché sur le desktop minoritaires voir anecdotiques. Pourtant je suppose que tu postes ton commentaire depuis un poste GNU/Linux ? Du coup, je suppose aussi que puisque tu le fais, tu ne regrettes pas ton choix, bien au contraire ? Je suppose aussi que puisque ce choix te plaît, tu le recommandes aux autres dans la mesure du possible ? Pourtant le monde semble aller dans d'autres directions, celles de Windows, Android et iOS.
Au final, ton propos me semble bien étrange.
Je conclurais juste ma remarque en disant que "des milliards de mouches ne peuvent avoir tord, mangeons de la merde !".
Hm, et il se passe quoi si ton cloud se fait démonter par des pirates et que, comme c'est déjà arrivé trop souvent par le passé, le chiffrage de des données se révèle insuffisant voir inexistant ?
Pour ma part, je stocke ça sur mes machines perso. Ça ne veut pas dire que je suis à l'abri d'un piratage, mais ça veut dire que je sais à peu prêt comment la sécurité de mes mots de passe est assurée. Aussi, à mon avis, il y a quand même moins de chances que mes machines perso se fassent démonter par une attaque ciblée qu'un service de cloud (nettement plus rentable pour un pirate).
À mon avis, le 1er xkcd linké tape parfaitement juste, mais le 2ième oublie une chose : il faut réussir à taper "correcthorsebatterystaple" dans un champ texte qui masque la saisie. Je suis à peu prêt sûr que la plupart gens ont déjà du mal à saisir leur mot de passe de 8 caractères sans typo, alors 26 … Peut-être faudrait-il généraliser la saisie de mot de passe avec le dernier caractère visible, comme elle est faite sur les smartphones ?
Sinon, pour répondre à ta question, moi j'utilise pwgen et pwsafe. Ça me permet d'avoir un master password qui protège ma base de données de mots de passe, et un mot de passe unique par site web. Comme ça, en cas de fuite/piratage/whatever, je n'ai jamais plus qu'un mot de passe à changer.
Il me reste toutefois le problème du login sur mes machines. J'ai le même couple login/mot de passe sur toutes mes machines perso. Pour résoudre ce problème, j'avais un ami qui avait joué avec les one-time passwords (il utilisait son téléphone portable pour les générer). Mais personnellement je n'ai pas eut le temps d'essayer.
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)
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).
Tu te représentes la quantité de travail? Alors qu'avec un poil de volonté du développeur on pourrait avoir un paquet par distrib à faire
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.
Portabilité ? : Le logiciel est en Python, donc il pourrait potentiellement viser Windows et/ou Mac OS
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é.
Gestion du projet : La gestion des dépendances (Quelles libs on utilise? Quelles libs on peut virer? Quelles versions?), c'est le développeur qui doit les faire, j'espère qu'au moins la dessus on est d'accord. Seulement si le développeur ne tient compte que du code et pas du packaging, le logiciel peut vite devenir une horreur à packager. Par exemple si le dev choisi d'intégrer une lib originale que personne n'utilise à chaque release.
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)
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.
Si tu veux des testeurs, il faut qu'ils puissent installer en dehors des repos officiels
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.
tu remarques que ce sont les premiers rapports de "bugs" de ton logiciel
Euh non. Les 1ers rapports de bug sur Paperwork sont bien plus vieux et n'ont rien à voir.
Certaines des dépendances sont abandonnées en upstream
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.
« Je n'embarque pas les dépendances, car je ne veux pas ré-inventé la roue ».
Ta formulation est mauvaise,
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.
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.
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)
Actuellement il est déjà possible d'importer des images et des PDFs dans Paperwork.
Par contre l'import d'un dossier d'images complet est plus compliqué, vu que chaque personne aura sa propre façon d'organiser le-dit dossier à importer. J'ai quelques idées sur comment importer ce qui sera vraisemblablement les organisations les plus courantes, mais ce n'est pas prévu pour la 0.1.
En attendant, pour ceux qui savent scripter, c'est un problème qui peut se résoudre à grand coup de scripts shell. J'ai inclus les informations nécessaire dans la doc de hacking pour ceux que ça intéresse. En fait il suffit d'arranger et nommer les fichiers dans le répertoire de travail de la même façon que Paperwork.
Je ne les sélectionne pas :)
En fait je passe le texte tel-quel à Whoosh. C'est lui qui se charge de l'indexation, de la recherche et des suggestions.
Pour Scribo, je ne connaissais pas. Je vais voir pour l'intégrer à PyOCR. Pour ce qui est de l'interaction, actuellement, c'est fait de façon relativement crade: Paperwork (via PyOCR) exécute tout simplement Tesseract comme commande shell. Je suppose que Scribo peut aussi être lancé depuis le shell, donc je ne devrais pas avoir de soucis pour l'intégrer.
En fait, Tesseract fournit aussi une librairie C++, mais du coup ce n'est pas simple à binder sur du Python (du moins sans rajouter une autre dépendance), et je n'ai trouvé aucune documentation expliquant comment l'utiliser. Donc j'ai juste laissé tombé (pour le moment)
Ah non désolé. Ça fait un moment que je n'ai plus de ArchLinux installée. Si je trouve la motivation et le temps, je vais essayer d'en installer une ce week-end dans une VM. Ça me permettra de compléter le README. (pas de garantie ceci dit)
Hm. J'ai pushé un fix temporaire sur Paperwork, mais il faudra que j'examine ça plus en détails dès que j'ai du temps. Il semblerait que j'ai cassé l'import d'image. Je ne vois juste pas comment j'ai pu rater ça, et il faudra que je vois comment faire un fix propre.
Tesseract et Cuneiform ont besoin de fichiers de data pour chaque langue avec lesquelles tu souhaite travailler.
Là l'exception indique qu'aucun fichier de data n'a été trouvé.
Si tu utilises Ubuntu ou Debian: sudo apt-get install tesseract-ocr-fra .
Je viens de voir que doc dans le README était tronquée sur ce point (une erreur de ma part dans le markdown). C'est corrigé.
Pour les pertes de dossiers, c'est plus que bizarre. J'ai du mal à voir ce qui pourrait causer ça dans Paperwork.
Quant à l'import, quand il continue à tourner indéfiniment, généralement, c'est qu'il y a eut une exception Python non-catchée. Es-tu sûr que tu n'as aucune exception dans le terminal ? (éventuellement un peu plus haut que les 2 messages que tu as cité)
Vu que ça me semble être une réponse potentiellement pertinente à ta question, j'en profite pour me faire un peu de pub.
Je travaille depuis un moment sur un programme appelé Paperwork. C'est un client lourd (Python/Gtk), et pour des questions de performances, je recommande d'avoir les documents en local. Ceci dit, rien n’empêche d'avoir les documents en local et de les rsync périodiquement sur ton NAS (mieux vaut avoir trop de copies de ses documents que pas assez).
[^] # Re: Traduction de la traduction
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Qui a vraiment besoin d'héberger soi-même ses données ?. Évalué à 2.
Ah ben voilà qui explique. Merci pour cet éclaircissement.
[^] # Re: Traduction de la traduction
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Qui a vraiment besoin d'héberger soi-même ses données ?. Évalué à 6.
Cette fin de phrase me fait tiquer.
Tu es sur Linuxfr, un site dédié à un OS au parts de marché sur le desktop minoritaires voir anecdotiques. Pourtant je suppose que tu postes ton commentaire depuis un poste GNU/Linux ? Du coup, je suppose aussi que puisque tu le fais, tu ne regrettes pas ton choix, bien au contraire ? Je suppose aussi que puisque ce choix te plaît, tu le recommandes aux autres dans la mesure du possible ? Pourtant le monde semble aller dans d'autres directions, celles de Windows, Android et iOS.
Au final, ton propos me semble bien étrange.
Je conclurais juste ma remarque en disant que "des milliards de mouches ne peuvent avoir tord, mangeons de la merde !".
[^] # Re: KeePassX
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Sécurité des mots de passe. Évalué à 2. Dernière modification le 10 mai 2013 à 15:43.
Hm, et il se passe quoi si ton cloud se fait démonter par des pirates et que, comme c'est déjà arrivé trop souvent par le passé, le chiffrage de des données se révèle insuffisant voir inexistant ?
Pour ma part, je stocke ça sur mes machines perso. Ça ne veut pas dire que je suis à l'abri d'un piratage, mais ça veut dire que je sais à peu prêt comment la sécurité de mes mots de passe est assurée. Aussi, à mon avis, il y a quand même moins de chances que mes machines perso se fassent démonter par une attaque ciblée qu'un service de cloud (nettement plus rentable pour un pirate).
# Pas entièrement d'accord avec xkcd
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Sécurité des mots de passe. Évalué à 6.
À mon avis, le 1er xkcd linké tape parfaitement juste, mais le 2ième oublie une chose : il faut réussir à taper "correcthorsebatterystaple" dans un champ texte qui masque la saisie. Je suis à peu prêt sûr que la plupart gens ont déjà du mal à saisir leur mot de passe de 8 caractères sans typo, alors 26 … Peut-être faudrait-il généraliser la saisie de mot de passe avec le dernier caractère visible, comme elle est faite sur les smartphones ?
Sinon, pour répondre à ta question, moi j'utilise pwgen et pwsafe. Ça me permet d'avoir un master password qui protège ma base de données de mots de passe, et un mot de passe unique par site web. Comme ça, en cas de fuite/piratage/whatever, je n'ai jamais plus qu'un mot de passe à changer.
Il me reste toutefois le problème du login sur mes machines. J'ai le même couple login/mot de passe sur toutes mes machines perso. Pour résoudre ce problème, j'avais un ami qui avait joué avec les one-time passwords (il utilisait son téléphone portable pour les générer). Mais personnellement je n'ai pas eut le temps d'essayer.
[^] # Re: PKGBUILD pour Arch Linux dispo dans AUR
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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: purge
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 2.
Pour la catégorie de document, un label devrait faire l'affaire, non ?
[^] # Re: Import de photos
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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 Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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 Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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 Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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: Forces et Faiblesses
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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: petits retours rapides
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. É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)
[^] # Re: Et sans scan connecté ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Tout à fait :)
[^] # Re: Et sans scan connecté ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Actuellement il est déjà possible d'importer des images et des PDFs dans Paperwork.
Par contre l'import d'un dossier d'images complet est plus compliqué, vu que chaque personne aura sa propre façon d'organiser le-dit dossier à importer. J'ai quelques idées sur comment importer ce qui sera vraisemblablement les organisations les plus courantes, mais ce n'est pas prévu pour la 0.1.
En attendant, pour ceux qui savent scripter, c'est un problème qui peut se résoudre à grand coup de scripts shell. J'ai inclus les informations nécessaire dans la doc de hacking pour ceux que ça intéresse. En fait il suffit d'arranger et nommer les fichiers dans le répertoire de travail de la même façon que Paperwork.
[^] # Re: Comment ca marche ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Je ne les sélectionne pas :)
En fait je passe le texte tel-quel à Whoosh. C'est lui qui se charge de l'indexation, de la recherche et des suggestions.
Pour Scribo, je ne connaissais pas. Je vais voir pour l'intégrer à PyOCR. Pour ce qui est de l'interaction, actuellement, c'est fait de façon relativement crade: Paperwork (via PyOCR) exécute tout simplement Tesseract comme commande shell. Je suppose que Scribo peut aussi être lancé depuis le shell, donc je ne devrais pas avoir de soucis pour l'intégrer.
En fait, Tesseract fournit aussi une librairie C++, mais du coup ce n'est pas simple à binder sur du Python (du moins sans rajouter une autre dépendance), et je n'ai trouvé aucune documentation expliquant comment l'utiliser. Donc j'ai juste laissé tombé (pour le moment)
[^] # Re: A tester
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 1.
En l’occurrence l'adresse en question est obsolète. Mais tu as raison, mieux vaut être trop prudent que pas assez. C'est rectifié.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Oui, un passage à Python 3 est prévu. Ce sera fait dès que toutes les dépendances de Paperwork seront disponibles pour Python 3.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 1.
Ah non désolé. Ça fait un moment que je n'ai plus de ArchLinux installée. Si je trouve la motivation et le temps, je vais essayer d'en installer une ce week-end dans une VM. Ça me permettra de compléter le README. (pas de garantie ceci dit)
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Désolé, je crois que j'ai mal lu la stacktrace et l'exception la 1ère fois. En fait, il s'agirait plutôt du cas où il n'a pas trouvé d'OCR du tout.
Pour info, pour savoir si Tesseract est disponible, Pyocr cherche simplement la commande "tesseract" dans le PATH.
À tout hasard, quelle distribution Linux utilises-tu ?
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Hm. J'ai pushé un fix temporaire sur Paperwork, mais il faudra que j'examine ça plus en détails dès que j'ai du temps. Il semblerait que j'ai cassé l'import d'image. Je ne vois juste pas comment j'ai pu rater ça, et il faudra que je vois comment faire un fix propre.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 1.
Tesseract et Cuneiform ont besoin de fichiers de data pour chaque langue avec lesquelles tu souhaite travailler.
Là l'exception indique qu'aucun fichier de data n'a été trouvé.
Si tu utilises Ubuntu ou Debian: sudo apt-get install tesseract-ocr-fra .
Je viens de voir que doc dans le README était tronquée sur ce point (une erreur de ma part dans le markdown). C'est corrigé.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Il me faudrait aussi la stacktrace qui devait être juste en-dessous de l'exception s'il-te-plait.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 1.
Pour les pertes de dossiers, c'est plus que bizarre. J'ai du mal à voir ce qui pourrait causer ça dans Paperwork.
Quant à l'import, quand il continue à tourner indéfiniment, généralement, c'est qu'il y a eut une exception Python non-catchée. Es-tu sûr que tu n'as aucune exception dans le terminal ? (éventuellement un peu plus haut que les 2 messages que tu as cité)
# Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 10. Dernière modification le 19 avril 2013 à 19:03.
Vu que ça me semble être une réponse potentiellement pertinente à ta question, j'en profite pour me faire un peu de pub.
Je travaille depuis un moment sur un programme appelé Paperwork. C'est un client lourd (Python/Gtk), et pour des questions de performances, je recommande d'avoir les documents en local. Ceci dit, rien n’empêche d'avoir les documents en local et de les rsync périodiquement sur ton NAS (mieux vaut avoir trop de copies de ses documents que pas assez).