En fait, de mon point de vue, la question était un peu différente:
Dans un premier temps, j'ai fait ce début de jeu pour le fun. C'est quelque-chose qui me démangeait depuis longtemps et je l'ai fait pour moi.
Dans un deuxième temps, il s'agissait de savoir si cette idée de jeu pouvait intéresser des gens et si ça valait le coup pour moi que j'y investisse plus de temps. L'idée était de continuer à m'y investir proportionnellement à l'intérêt que ça peut avoir.
Il ne s'agissait donc pas vraiment d'obtenir des fonds pour. Atteindre les 4000 euros avait en soit peu d'intérêt. Ce que je voulais savoir, c'est si cette idée avait de la valeur au point que des gens seraient prêts à donner de l'argent pour.
Faire de la publicité pour cette campagne aurait donc été contre-productif. Ça aurait juste biaisé le résultat.
Et donc là la résultat fût net: Personne n'est prêt à mettre 5€ pour un jeu comme ça (les 10€, c'est ma petite amie :). Donc juste pas de raison de que je passe plus de temps dessus. Fondamentalement, même si le ton de mon journal peut avoir donné l'impression du contraire, je ne suis pas aigri ni frustré par ce résultat (bon OK, le 0 absolu … un petit peu quand même … ;).
à moins biensûr que du travail n'ait été repris en dehors de git.
Nop, tout a été fait dans Git directement :-)
j'ai juste constaté que mon ordi soufflait pas mal
Je n'ai pas creusé beaucoup ce point, mais je crois que c'est un soucis lié à Pygame, au pilotes graphiques et au type même du jeu: Le jeu est assez agressif en terme de 2D (le circuit bouge relativement par rapport à la voiture --> rafraîchissement complet de l'écran à chaque frame). Or l'accéleration 2D sous Linux, en fonction du pilote de la carte graphique, semble être entre inexistante et pas-terrible. Faute d'accéleration GPU, je suppose que c'est le CPU qui fait toute.
Pour l'anecdote, j'avais de meilleures perfs sur mon portable avec une carte Intel (~50 à 100 FPS) que sur mon fixe avec une carte Radeon (~20 à 25 FPS).
pour ma part je verrais bien ce style de jeu dans un bundle avec plein d'autres
Il faudrait que quelqu'un prenne le temps de le finir par contre …
Je serais plus que content d'utiliser le format DjVu pour les scans au lieu de ma bouillabaisse à base de JPEG+hOCR.
Le problème, c'est qu'à l'heure actuelle, à ma connaissance, il n'y aucune libraire C ou Python libre pour générer des fichiers DjVu.
La dernière fois que j'ai regardé, DjvuLibre ne proposait qu'une librairie pour la lecture de fichiers DjVu, et des outils en ligne de commande pour leur génération. Je dois déjà faire des fork()+exec() pour Tesseract, et ça m'embête déjà bien. Je refuse de faire des fork()+exec() pour générer les fichiers DjVu.
Ayant moi-même une Brother MFC (pour tester Paperwork principalement), pour ma part, j'aurais plutôt tendance à les déconseiller. Même si ça semble être du très bon matériel, logiciellement ça pêche :
En fonction de la distribution, l'installateur et les pilotes Brother marchent plus ou moins bien: Pas de problème avec Ubuntu Gnome 16.10, mais je n'ai pas réussi à les faire marcher sur Debian sid.
Sauf erreur de ma part, les drivers Brother sont entièrement propriétaires. Pour l'instant ils fonctionnent, mais le jour où Brother en aura marre de les maintenir, ça va devenir de plus en plus compliqué de les utiliser avec une distribution à jour. Jusqu'au moment où ce ne sera plus possible, et la seule option sera de racheter une imprimante …
Pour info, le nom du paquet manquant ici, dans Debian/Ubuntu, c'est gir1.2-poppler-0.18.
Gnome a introduit les GIR (GObject Introspection Repositories) pour pouvoir générer automatiquement les bindings pour chaque langage à la volée, rendant les paquets comme python-poppler obsolètes.
Personnellement, j'ai une préférence pour les scanners/imprimantes HP. Matériellement ils sont moyens. Les drivers sont acceptables mais sans plus. Mais HP fournit des pilotes Linux open-source, donc tu branches en USB et ça marche.
Il y a juste parfois un apt install hplip à faire. Au pire, si le matériel est trop récent, il faut faire une installation manuelle pas-hyper-compliquée des pilotes HP.
À ma connaissance ils font systématiquement des pilotes Linux open-source, mais je ne suis pas 100% certain.
Actuellement, ce n'est donc malheureusement pas possible tel quel. Dans ton cas, je pense que le plus simple serait de scripter la fusion des pages recto avec les pages verso en utilisant des outils en ligne de commande. Bon ok, pour l'aspect intuitif et user-friendly, on repassera …
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 ?
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 :/
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.
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:
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 ..)
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.
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.
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>
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).
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é :-)
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 ?
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 ?
À 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: tout le monde s'en tamponne le coquillard
Posté par Jérôme Flesch (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 10.
En fait, de mon point de vue, la question était un peu différente:
Dans un premier temps, j'ai fait ce début de jeu pour le fun. C'est quelque-chose qui me démangeait depuis longtemps et je l'ai fait pour moi.
Dans un deuxième temps, il s'agissait de savoir si cette idée de jeu pouvait intéresser des gens et si ça valait le coup pour moi que j'y investisse plus de temps. L'idée était de continuer à m'y investir proportionnellement à l'intérêt que ça peut avoir.
Il ne s'agissait donc pas vraiment d'obtenir des fonds pour. Atteindre les 4000 euros avait en soit peu d'intérêt. Ce que je voulais savoir, c'est si cette idée avait de la valeur au point que des gens seraient prêts à donner de l'argent pour.
Faire de la publicité pour cette campagne aurait donc été contre-productif. Ça aurait juste biaisé le résultat.
Et donc là la résultat fût net: Personne n'est prêt à mettre 5€ pour un jeu comme ça (les 10€, c'est ma petite amie :). Donc juste pas de raison de que je passe plus de temps dessus. Fondamentalement, même si le ton de mon journal peut avoir donné l'impression du contraire, je ne suis pas aigri ni frustré par ce résultat (bon OK, le 0 absolu … un petit peu quand même … ;).
[^] # Re: Syntax error
Posté par Jérôme Flesch (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 3.
Je l'ai fait avec Python 3.5. Ceci dit, je pensais que cette syntaxe existait déjà avec Python 3.4.
[^] # Re: Il est fort bien pour un jeu développé en quinze jours
Posté par Jérôme Flesch (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 4.
Nop, tout a été fait dans Git directement :-)
Je n'ai pas creusé beaucoup ce point, mais je crois que c'est un soucis lié à Pygame, au pilotes graphiques et au type même du jeu: Le jeu est assez agressif en terme de 2D (le circuit bouge relativement par rapport à la voiture --> rafraîchissement complet de l'écran à chaque frame). Or l'accéleration 2D sous Linux, en fonction du pilote de la carte graphique, semble être entre inexistante et pas-terrible. Faute d'accéleration GPU, je suppose que c'est le CPU qui fait toute.
Pour l'anecdote, j'avais de meilleures perfs sur mon portable avec une carte Intel (~50 à 100 FPS) que sur mon fixe avec une carte Radeon (~20 à 25 FPS).
Il faudrait que quelqu'un prenne le temps de le finir par contre …
[^] # Re: Slicks'n'slide / Generally
Posté par Jérôme Flesch (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 4.
Ma source d'inspiration principale était Super Car II. Pour le coup, tu viens de m'apprendre que ce type de jeu avait un nom à lui :-)
[^] # Re: tout le monde s'en tamponne le coquillard
Posté par Jérôme Flesch (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 3.
5€ ne me semblait pas déraisonnable. Question de point de vue je suppose.
[^] # Re: DjVu
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.1. Évalué à 5.
Je serais plus que content d'utiliser le format DjVu pour les scans au lieu de ma bouillabaisse à base de JPEG+hOCR.
Le problème, c'est qu'à l'heure actuelle, à ma connaissance, il n'y aucune libraire C ou Python libre pour générer des fichiers DjVu.
La dernière fois que j'ai regardé, DjvuLibre ne proposait qu'une librairie pour la lecture de fichiers DjVu, et des outils en ligne de commande pour leur génération. Je dois déjà faire des fork()+exec() pour Tesseract, et ça m'embête déjà bien. Je refuse de faire des fork()+exec() pour générer les fichiers DjVu.
[^] # Re: scanner
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.1. Évalué à 4. Dernière modification le 06 février 2017 à 14:56.
Ayant moi-même une Brother MFC (pour tester Paperwork principalement), pour ma part, j'aurais plutôt tendance à les déconseiller. Même si ça semble être du très bon matériel, logiciellement ça pêche :
[^] # Re: Mageia
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.1. Évalué à 3. Dernière modification le 04 février 2017 à 14:47.
Pour info, le nom du paquet manquant ici, dans Debian/Ubuntu, c'est
gir1.2-poppler-0.18.Gnome a introduit les GIR (GObject Introspection Repositories) pour pouvoir générer automatiquement les bindings pour chaque langage à la volée, rendant les paquets comme
python-popplerobsolètes.Si un utilisateur de Mageia aurait le temps de compléter paperwork-shell avec les listes de paquets Mageia, ça serait cool :
https://github.com/jflesch/paperwork-backend/blob/unstable/src/paperwork/backend/shell_cmd.py#L22
https://github.com/jflesch/paperwork-backend/blob/unstable/src/paperwork/backend/deps.py
https://github.com/jflesch/paperwork/blob/unstable/src/paperwork/deps.py
[^] # Re: scanner
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.1. Évalué à 4. Dernière modification le 01 février 2017 à 19:28.
Personnellement, j'ai une préférence pour les scanners/imprimantes HP. Matériellement ils sont moyens. Les drivers sont acceptables mais sans plus. Mais HP fournit des pilotes Linux open-source, donc tu branches en USB et ça marche.
Il y a juste parfois un
apt install hplipà faire. Au pire, si le matériel est trop récent, il faut faire une installation manuelle pas-hyper-compliquée des pilotes HP.À ma connaissance ils font systématiquement des pilotes Linux open-source, mais je ne suis pas 100% certain.
[^] # Re: fusionner documents
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.1. Évalué à 6. Dernière modification le 01 février 2017 à 11:49.
Paperwork considère que 1 PDF = 1 document. Et paperwork a pour principe de ne jamais modifier les PDFs qu'on lui donne.
Sinon, il est possible d'importer des images (1 image = 1 page). Mais dans ce cas, Paperwork ne permet d'importer qu'une seule image à la fois pour le moment.
Actuellement, ce n'est donc malheureusement pas possible tel quel. Dans ton cas, je pense que le plus simple serait de scripter la fusion des pages recto avec les pages verso en utilisant des outils en ligne de commande. Bon ok, pour l'aspect intuitif et user-friendly, on repassera …
[^] # Re: Tuto / Procédure / Notice ?
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. É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 ?
[^] # Re: layout de répertoire ?
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. Évalué à 2. Dernière modification le 17 novembre 2016 à 16:55.
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 Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. Évalué à 3.
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: Debian
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. É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.
[^] # Re: docker !
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. Évalué à 4. Dernière modification le 14 novembre 2016 à 17:38.
J'ai failli oublier:
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.
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.
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 ..)
[^] # Re: layout de répertoire ?
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. É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 :
[^] # Re: docker !
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. É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: Ambiguïté mais bonne surprise
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. É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: plantage...
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 1.0. Évalué à 7.
Désolé, c'est un bug que j'avais introduit dans la 1.0.0. C'est corrigé en 1.0.1.
https://github.com/jflesch/paperwork/issues/510
[^] # Re: J'ai arrêté d'utiliser paperwork
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 0.3. Évalué à 1.
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: Best teaser ever
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 0.3. Évalué à 4. Dernière modification le 18 février 2016 à 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é :-)
[^] # Re: J'ai arrêté d'utiliser paperwork
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 0.3. Évalué à 2.
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.
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: Paperless
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 0.3. Évalué à 3.
Je vois quelques problèmes pour les rendre compatibles :
[^] # Re: Ah si seulement...
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 0.3. Évalué à 1.
À tout hasard, il y a quelques solutions workarounds possibles:
Pas très pratique, je sais :/
[^] # Re: J'ai arrêté d'utiliser paperwork
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork 0.3. Évalué à 1. Dernière modification le 17 février 2016 à 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.