Jérôme Flesch a écrit 345 commentaires

<mode troll="on">
.. ou que les investissements dans les R&D des constructeurs de voitures sont nettement plus importants que que les constructeurs de moto.
On notera toutefois que c'est entrain d'évoluer: J'ai acheter une 125 l'année dernière qui répond aux dernières normes écologique (eco 3), et je m'en tire à 3,5l / 100km alors que je suis un peu sec sur la poignée des gaz. J'ai un collègue qui a une Prius et qui consomme nettement plus que moi (5~6l / 100km).

Niveau danger pour autrui: Lors de mon passage du code pour le permis moto l'année dernière, au centre d'examen, je suis tombé sur les statistiques 2010 en terme de tués par type de véhicule dans le département du Nord. Les 2 roues n'ont tués ni piéton et ni d'autre usagé de la route. Les automobilistes ne peuvent pas en dire autant.
</mode>

À vrai dire, je suis dans la même situation que toi. Je n'ai plus vraiment envi d'encourager les gens à utiliser Ubuntu:

• Je trouve l'interface d'Unity discutable (c'est probablement personnel, donc je ne vais pas détailler, sinon ça va partir en troll)
• Pour des raisons politiques: Unity divise au lieu d'unir. De plus, du coup, ils tirent dans les pattes du projet Gnome alors qu'ils se sont pourtant longtemps appuyés dessus avec succès.
• Pour des questions de liberté: Si l'utilisateur lambda s'habitue à Unity, le migrer ensuite sur une autre distribution risque de s'avérer pénible. Ça me donne un sentiment de rendre les gens prisonniers d'un unique fournisseur, et ça me rappelle certaines migrations douloureuses Windows->Linux que j'ai justement faites par le passé.
• Pour des questions de confort: Ubuntu devient de plus en plus commerciale (Ubuntu One, etc). Du coup, Ubuntu va vite en arriver à chercher à rendre ses produits de plus en plus visibles (si ce n'est pas déjà le cas), ce qui ne peut que nuir à la qualité de l'interface.

Avant qu'Ubuntu dérive, c'était simple. Je pouvais suggérer une seule et même distribution à tout le monde. Là je suis embêté. Du coup, ce que je fais actuellement:

• Pour les geeks confirmés (genre collègues de travail), je pousse Debian (stable, testing ou Sid, selon la personne)
• Pour les utilisateurs lambda qui me laissent administrer leur machine à distance (mes parents en gros): Ubuntu, mais avec une interface Gnome 3. Quand Gnome 3 sera dans Debian stable, je vais probablement les passer à Debian.
• Pour les autres utilisateurs lambda, une Ubuntu LTS de base. Là, honnêtement, je prie très fort pour que Ubuntu reste raisonnable dans ses dérives marketing.
• Reste les geeks-en-devenir: Là actuellement, je n'ai plus aucune distribution à leur suggérer. Ça se joue entre Ubuntu et Debian.

Hm, si ton but est de faire de la pub pour Linux, je ne suis pas sûr que ce soit un bon argument de vente. Au contraire même.

• Trop de choix tue le choix
• Avec toutes ces interfaces (Gnome, KDE, Unity, etc), Linux n'a pas d'identité visuelle : C'est plus dûr de vendre un produit si le client n'arrive pas à se le représenter. Si en plus on commence à présenter des versions customisées …

Testé sur mes parents, mes soeurs et mes nièces et neuveux: Les utilisateurs lambda veulent juste des logiciels qui fonctionnent et qu'ils peuvent montrer à leur copains MacOSX-iens sans pâlir (--> visuellement plaisant). Ils se fichent de savoir quelle interface ils utilisent, ni même quelle distribution Linux. C'est tout juste si savoir qu'ils utilisent Linux les intéressent (ça permet de se la jouer en peu en soirée ceci dit :). Quand les gens voient toutes ces customisations, souvent, ils ne disent pas "ouah cool". Ils se disent "oula, avec autant de choix, ça va être compliqué".

Ici, au mieux, ils se diront:

1. C'est joli
2. C'est familié (MacOSX-like) donc simple à utiliser
3. Donc je veux ça sur mon ordi

Et là ils vont vite déchanter en se rendant compte que:

1. Ce n'est pas simple à avoir
2. Ce n'est pas aussi familié que ce qu'ils s'étaient imaginé
3. Que la version customisée est sûrement moins bien finie que la version originale, et donc plus pénible à utiliser

"Et là, c'est le drame."

Au final, si tu veux que ça "percute" les gens, il vaudrait mieux avoir une seule UI par défaut sur toutes les distribs. Une qui transpire la simplicité d'utilisation tout en étant élégante et non une qui nage dans les possibilités de personnalisation. Après, une fois Linux installé et l'utilisateur conquit, rien ne l'empêche de personnaliser son système petit à petit.

<troll inside>
Plus largement, ces dernières années, je trouve que Linux a entamé un sérieux décollage sur le desktop. Personnellement je suis convaincu que c'est grâce à Ubuntu (pas Kubuntu&co hein, juste Ubuntu):

• Ubuntu a toujours choisi par défaut une interface simple. Que ce soit Gnome 2 ou Unity.
• Les geeks que je connais se sont mis d'accord pour vendre principalement cette distrib aux lambda users : C'est clairement la plus simple à utiliser. Les utilisateurs lambda n'ont donc plus à faire ce choix compliqué.
• Ubuntu a une identité visuelle clairement définie qui change peu souvent. Avant c'était Gnome 2, maintenant Unity. Quand tu parles à quelqu'un de Ubuntu, s'il l'a déjà vue, il aura une idée claire de ce dont tu parles.

PS: Je ne cherche pas à faire de la pub pour Ubuntu. En fait, je n'aime pas du tout Unity. Mais à moment donné il faut essayer d'être objectif.

</troll inside>

Donc, si je comprends bien ce post, pour que Linux soit prêt pour le desktop, il faut que l'interface repompe autant que possible celle de MacOSX ?

Nul part il n'a dit qu'elles ne sont bonnes que à ça.

Pour la logique de séparation des responsabilités: +1 :-)

Pour ce qui est de coupler l'application avec un moteur de recherche desktop: C'est sûrement possible. C'est même déjà plus ou moins le cas: Paperwork génère des .jpg+.txt. Le .txt sera donc déjà indexé par le moteur. D'après mes souvenirs d'expérimentations d'il y a quelques années, le plus gros problème est en fait de pouvoir ouvrir le jpg correspondant au .txt: les moteurs de recherche desktop, dans leurs listes de résultats, ont la fâcheuse habitude de juste permettre l'ouverture du .txt, et non pas du dossier parent de ce fichier. J'avais juste trouvé Google Desktop qui permettait de le faire …
Après il y a une autre problématique: Les défauts d'OCR. Paperwork fournit (enfin tente) des suggestions de recherche basées sur les mots effectivement obtenus par l'OCR. Ça permet occasionnellement de rattraper certains glitchs de l'OCR (par exemple, j'ai un document qui a pour mot clef "Flescih" au lieu de "Flesch"). Je ne pense pas qu'un moteur de recherche desktop puisse fournir ces suggestions facilement.

Pour les tags/catégories: C'est déjà implémenté (c'est appelé 'labels' dans l'application)

Pour le reste, tel que je vois ça:

• L'emplacement physique de l'original: les tags peuvent servir pour faire ça.
• La confidentialité du document: idem, les tags peuvent servir pour faire ça.
• La durée de conservation / une option pour faire le ménage: Je me sais pas dans quel mesure un ménage de printemps serait pertinent connaissant les capacités de stockage des disques durs actuels. Quand bien même quelqu'un tiendrait à le faire, c'est faisable avec les tags: Les documents sont identifiés (et triés) par leur date de scan. Il suffit donc de les tagger ensuite sur la période qu'on veut les garder. Lorsqu'on veut faire le ménage, on peut alors faire une recherche sur un des tags de durée, et supprimer les documents trop vieux. Par contre il faudrait que j'autorise la sélection de multiples documents simultanément.

Concernant la volumétrie: J'ai actuellement 792 pages. Elles prennent 859Mo. Quand il démarre, Paperwork met environ 10 à 20 secondes à les indexer sur ma machine (problème qui disparaitra lorsque j'utiliserais Sqlite pour stocker l'index sur le disque).

Zut, j'avais oublié de préciser: tesseract [img] [result] -l fra hocr génère un [result].html qu'il faut en fait renommer en [result].words pour que paperwork le prenne en compte. Désolé pour cette omission.

1. Oui. Un dialogue a d'ailleurs été prévu pour pouvoir scanner plusieurs documents d'un coup (il faut que je le peaufine un peu par contre).
2. Ça reste à la charge de l'utilisateur. Il peut s'aider du système de label si il le souhaite. Personnellement j'ai très rarement besoin des originaux, donc si je dois de nouveau fouiller dans les piles de papiers à ces moments là, ça n'est pas bien gênant.
3. Il n'y a rien dans Paperwork même prévu à cette fin. Il est cependant possible de simplement renommer le répertoire du document à la main. Toutefois, tel que je vois ça, la date du scan sert surtout à identifier le document de manière unique. Les mots clefs dans le document sont généralement suffisants pour le retrouver. Personnellement j'ai plein de documents scannés en 2011 qui datent en fait de 2010, et ça ne m'a jamais gêné pour les retrouver.

Le problème, c'est que je doute qu'il y ait 2 personnes pour organiser le dossier à importer de la même façon. Donc ça va faire une option compliquée à utiliser, qu'il va donc falloir longuement documenter (et tout le monde sait que les utilisateurs ne lisent pas la doc :).

Par contre, ton cas devrait pouvoir se scripter assez facilement. Tout ce qu'il faut, c'est que tu obtiennes un répertoire de travail contenant:

• Un dossier par document, ayant de préférence pour nom une date au format "YYYYMMDD_HHmm_ss". Ce n'est pas strictement nécessaire : Paperwork doit fonctionner même si les noms des dossiers ont un autre format (il les affichera alors tel quel).
• Dans chaque dossier, pour chaque page, il faut un .jpg et un .txt:
  • "paper.[page].jpg": tu peux l'obtenir facilement avec "convert" (qui fait partie de "imagemagick" de mémoire)
  • "paper.[page].txt": un coup de tesseract sur le jpg, et hop: tesseract paper.[page].jpg paper.[page] -l fra
  • "paper.[page].words": Le fichier .words est optionnel. Je crois que les commandes suivantes devrait pouvoir le générer: tesseract paper.[page].jpg paper.[page] -l fra hocr

Curieusement, on dirait que tu as un module Python Tesseract installé, mais pas le bon.

Dans le cas où tu aurais juste installé le mauvais module python-tesseract, voici ce que je te suggère de faire:

• sudo rm -f $(find /usr/lib/python2.7/dist-packages /usr/local/lib/python2.7/dist-packages -name tesseract.py*)
• Puis suivre à nouveau la méthode dans le README de Paperwork pour installer python-tesseract.

Le rm -f est un peu violent, mais ça aura le mérite de résoudre ton problème.

Pour la recherche, si tu taggues les documents systématiquement avec un label "type" et un label "mois+année", tu vas vite te retrouver avec plein de labels. Ce n'est pas vraiment un problème, mais je trouve ça un peu inutile : Le but de Paperwork est justement de pouvoir flemmarder : Tu mets la feuille dans le scanner, tu clicks scan, et ensuite tu peux l'empiler avec les autres :)
Personnellement, je maintiens les labels au strict minimum. Et si je cherche "edf facture février 2012", j'ai immédiatement mon dernier échéancier EDF qui apparait, même si il n'y a aucun label dessus.

Concernant le format, les pages sont gardées sous forme de 3 fichiers:

• un JPG
• un fichier .txt contenant les mots clefs
• un fichier .word (hOCR simplifié) pour pouvoir replacer les mots sur les pages

J'ai choisi le format JPG pour rester aussi proche que possible de la sortie du scanner (ceci dit, le JPG reste un compromis). De cette manière, au besoin, il est aussi possible de rééditer les documents après scan (rajouter des mots clefs dans le .txt, masquer des choses compromettantes dans les .jpg, etc).

Pour la version de Python, il faut que je creuse. Je pensais avoir fait le nécessaire pour forcer l'utilisation de Python 2. Visiblement j'ai raté quelque-chose.

Pour python-tesseract, il n'y a pas de paquet, dans aucune distribution. Les instructions pour l'installer sont dans le README de Paperwork dans la section "Dependencies".

Tesseract oui. Enfin plus ou moins bien (il confond régulièrement "é" et "'e"). Pour Cuneiform je n'ai pas encore regardé.

Toutefois, pour améliorer un peu la recherche et les suggestions, Paperwork retire les accents des mots clefs. Du coup, ça a relativement peu d'importance.

(et oui, je sais, cette astuce ne marche probablement qu'avec le français et l'anglais, et il faudra sûrement que je m'en passe pour les autres langues. Mais bon, en attendant …)

En fait l'idée m'avait déjà traversé l'esprit, mais c'est très très loin sur la roadmap ça :/

Euh, libuilib ? Je pense que tu as essayé d'installer le mauvais python-tesseract :)

C'est un peu fourbe: le python-tesseract que j'utilise est en fait le mien et est en pur Python.

Pour la petite histoire, il est en basé sur le dépot de hoffstaetter/python-tesseract, qui a été repris par jbochi/python-tesseract qui me l'a ensuite refilé .. Sauf qu'il n'a pas supprimé son dépôt. Donc, faute d'avoir autant de watchers que le sien, il n'apparaît pas dans les recherches Github. Ceci dit, si j'implémente le support pour Cuneiform, il faudra que je le renomme, ce qui devrait régler ce problème.

Merci du conseil. J'avais manqué Cuneiform quand j'avais fait mon tour des OCR libres. Il a l'air très efficace. Je me suis créé un ticket à ce sujet.

Chaque document est un répertoire dans le répertoire de travail.
Chaque page d'un document est stockée sous forme de 3 fichiers:

• un .jpg
• un .txt : le resultat de l'OCR
• un .word (hOCR) : pour avoir la position de chaque mot dans la page

J'aurais pu me contenter d'un .jpg + .word vu que le .word contient aussi les mots clefs du .txt. Cependant, actuellement, Paperwork indexe tout les documents quand il démarre, et les fichiers hOCR sont trop longs à parser. Donc pour maintenir un démarrage en un temps décent, je garde aussi les .txt. (J'ai déjà un ticket plus ou moins en rapport avec ça: https://github.com/jflesch/paperwork/issues/20 ).

Pour ce qui est des PDF, actuellement, non. Mais je suppose que c'est une fonctionnalité qui pourrait être pratique. Merci pour la suggestion. Je me suis la suis noté dans un ticket: https://github.com/jflesch/paperwork/issues/44

J'avais parlé de ce programme à un collègue, et c'est lui qui m'a poussé à faire le ticket. J'étais septique quant à l'utilité de la chose, mais visiblement il y a de la demande, donc je ne vais pas y couper … :)

• Pour le chiffrement des fichiers, je me tate. Je me demande si ce n'est pas un peu hors-sujet et si un programme dédié ne ferait pas un meilleur travail (personnellement, là, j'utilise encfs). Il faut que j'y réfléchisse. Merci pour la suggestion en tout cas.

• Pour le stockage dans une archive, il suffit de faire une archive du répertoire de travail, ce qui se fait en 2 clicks dans Nautilus.

• Pour les tags, j'aurais effectivement dû clarifier: On peut mettre plusieurs tags sur un même document. Je vais mettre à jour le README dès que j'aurais un peu de temps

• Pour Gnome, moi aussi j'aimerais bien, mais j'en suis sûrement encore loin :-)

Vous l'avez rêvé, je l'ai commencé :
http://jflesch.kwain.net/node/495

Par contre comme je suis une grosse feignasse qui fait semblant d'être over-booké, je l'ai pas encore fini.