NewsLinuxFr > GNOME Scan 0.6 : vulgariser la numérisation

Alors que GNOME print et maintenant GtkPrint? offre une solution efficace pour l'impression, simple tant pour le développeur que pour l'utilisateur, GNOME manque toujours cruellement d'une solution de numérisation en phase avec ses impératifs d'ergonomies, de simplicité, d'accessibilité et de modularité.

Contrairement à l'impression, la numérisation reste un domaine utilisé par les professionnels et les passionnés. On s'épargnera la description de la situation sous les SE propriétaires. Sous GNU/Linux, la décisions a été prise il y a de nombreuses année de décharger le noyau du support des scanner, il sera gérer en espace utilisateur. Le projet SANE est l'API et l'implémentation de référence pour le support des scanner sous GNU/Linux et plus. SANE est indépendant de l'interface. De nombreuses interfaces sont apparue : un exemple en GTK+ fourni avec SANE, un fork de ce dernier baptisé XSane et développé par Oliver Rauch, OpenOffice dispose d'une interface rudimentaire au dessus de SANE, Kooka pour KDE 3, Ekazo en py/gtk, etc. GNOME est le grand absent de cette liste, et les distributions orientés GNOME se sont rabbatues sur XSane. Ce logiciel reproduits certaines erreurs de conception de certains logiciels fournis avec les scanners : une logiciel tiers qui veut s'intégrer partout et centraliser tout les accès au scanner.

Mark Finlay avait commencé le projet GNOME Scan en 2004, mais il mourut avant de pouvoir donner vie aux maquettes d'un logiciel de numérisation. Ross Burton at Alan Horkan s'étais juré d'accomplir ce projet en sa mémoire. Finalement en mars 2006, après des périgrinnation autour de la numérisation, je lance la discussion sur la conception d'une bibliothèque proposant la numérisation clef en main pour les développeurs et une interface facile pour les utilisateurs. Martin Schön m'aida beaucoup dans les discussion sur l'architecture du projet. Le projet démarre, prend forme dans le cadre du Google Summer of Code 2006 sous la houlette de Vincent Untz (aussi connu sour le nom de « Dieu »). Un long cycle de développement abouti à Noël 2006 à Gnome Scan 0.4. La 0.4 reste une preuve de principe : la numérisation dans un bibliothèque, ça a du sens. Les premiers problèmes se pose : le logiciel n'est pas assez flexible face à la diversité des scanner, de l'utilisation de la numérisation et de la disparité des pilotes de scanner SANE.

Le printemps 2007 est l'occasion de repenser GNOME Scan pour qu'il soit plus modulaire et plus flexible. Après quelques semaines de brouillionage et de diagramme, je me lance dans la réécriture du projet. Une fois de plus, Google apporte son soutien financier et Vincent Untz son soutien psychologique. Août 2007, une ébauche de greffon AbiWord? intègre la numérisation et la ROC directement dans AbiWord?. Ryan Paul gratifie cette nouvelle d'un article sur Ars Technica. Moment de gloire. AbiScan reste cependant une preuve de principe s'appuyant sur des technologies très fraiches : OCRopus, GEGL et GNOME Scan. Après le GSoC, la décision est prise de suivre le cycle de GNOME et de calquer la numérotation de version sur celle de GNOME. La branche 0.5 est donc une branche instable qui aboutira sur la 0.6, stable (en terme d'utilisation, pas d'API).

La phrase maîtresse de GNOME Scan est : « Rendre la numérisation aussi simple que l'impression tant pour les utilisateurs que pour les développeurs. »

Comme prévue, en parralèle avec GNOME 2.22, GNOME Scan 0.6 sort, traduit en 15 langues dont 6 à 100%. Cette version apporte un jeu de fonctionnalité très pertinents :

• Une interface de numérisation simple, réciproque de l'impression
• Un traitement des images adapté aux grosses résolutions grâce à GEGL, conçu pour Gimp
• Une API extensible pour l'adapter aux spécificité de l'application
• Un utilitaire de numérisation pour enregistrer dans une image
• Un greffon Gimp pour numériser dans un nouvelle image ou dans un nouveau calque.
• Une infrastructure prête pour le future : branchement à chaud, traitement d'image, multiple API d'accès au scanner, etc.
• Par défaut, rotation et amélioration automatique des couleurs sont proposé.
• Une interface optimisée pour la numérisation de masse, rapide et efficace avec la prise en charge des chargeur de document, la réduction de l'interaction avec le logiciel s'il l'utilisateur doit manipuler lui-même les pages à numériser, etc.
• L'enregistrement automatique des options de numérisation par application.

Le futur est prometteur, plein de choses sont à améliorer, à tout les niveaux. La 0.8 prévue pour GNOME 2.24 en septembre prochain devrait recevoir beaucoup de consolidation de l'API, amélioration du support des scanner (options évoluée, disparité des scanners, branchement à chaud, boutons matériels, et optimisation de l'interface (possibilité de revenir en arrière, moins de popup, etc.)



Un travail collaboratif

GNOME Scan est vraiment au cœur de la pile de numérisation du bureau. En amont, il y 'a SANE, HAL, OCRopus et GEGL ; en aval il y a Gimp, AbiWord?, Evolution, OpenOffice, F-Spot et tant d'autres application qui gagnerait à intégrer la numérisation. En théorie, tout application qui imprime devrait numériser. GNOME Scan fut le premier projet à s'appuyer sur GEGL, ce qui lui donnat un valeur non négligeable. Aujourd'hui, GIMP tire aussi partie de GEGL. Cela prouve que l'intuition des développeur de GIMP de créer un GStreamer de l'image étais juste. KDE traine toujours des tableaux interminable d'octets pour faire transiter les images.

Le cas SANE

SANE a de nombreux mérite, mais pose également quelques soucis. Le standard de SANE est très minimal et n'évolue quasiment pas. De sorte que l'idée d'une version 1.2 avant la 2.0 a eut du mal à faire son chemin. L'évolution de SANE depuis 10 ans a été d'implémenter de nouveau pilote et de corriger les bugs. Or il y a clairement des manques dans SANE voir des erreurs conceptuelle qu'il faut résoudre, tant du point de vue de développeur de pilote que du développeur d'interface.

En tant qu'interface, GNOME Scan est en butes à quelques problèmes :

• Les pilotes sont très très très disparates. Certains se contente d'exposer les registres de la puce, d'autres propose des options de haut-niveau mais incomplètes. Le nommages de options est anarchique
• le concept d'option est utilisé pour représenté les capteurs, les options et les groupe d'option, dans la même structures, au final, c'est l'interface qui doit faire le trie
• SANE ne parle quasiment pas des évènements matériel (boutons, capteur, etc.). La seule chose qu'une interface peut connaître, c'est qu'une option est définie par le matériel plutôt que par le logiciel. Aucune sémantique n'est donnée, de sorte que l'interface ne peut pas savoir à quelle action correspond l'évènement : "numériser", "annuler", "éjecter", "automatique", "papier inséré", "couvercle ouvert" ? Il y a tant de possibilités !

Au final, les pilotes n'expose pas toutes les capacité du matériel, plus ou moins selon la volonté du développeur, et de manière incohérente. C'est très pénible lorsque l'on veut maîtriser un minimum l'interface pour offrir à l'utilisateur un logiciel intelligent et non un simple configurateur de pilote.

HAL

Actuellement je développe le support des scanner dans HAL grâce au travail effectué dans SANE pour publier un fdi depuis la 1.0.19. C'est encore dans un git local et j'ai l'intention de publier ça rapidement sur HAL et être héberger sur freedesktop.org. Ça se présente sous la forme d'un greffon à hald, qui est exécuté sur chaque scanner branché et reconnus, il détermine le nom de scanner SANE, observe les capteurs et publie un signal au besoin. Il implémente l'interface org.freedesktop.Hal.Device.Scanner qui permet simplement à l'interface de prendre possession du scanner pour l'utiliser. C'est assez pénible de se dire qu'il faut dupliquer le code de gestion des évènement si on veut en tirer partie dans l'interface elle-même.

Reconnaissance optique de caractères

GNOME n'a rien pour la ROC. J'ai timidement lancé le projet libaccroc dont le but est de produire une API GObject simpliste qui permet de faire abstraction du moteur de ROC (OCRopus, tesseract, gocr, ocrad, claraocr, hocr, etc.) et de choisir globalement le moteur de son choix. GNOME Scan proposera une sous-classe de puit de la chaîne de traitement intégrant directement la ROC. Il y a du boulot également au niveau de l'intégration d'unpaper ou de greycstoration qui permettent d'apprêter une image pour la ROC.

Une fois ce travail effectué, on pourra revenir à la charge sur AbiScan et avoir un truc stable et fonctionnel. On peut même se permettre de parler d'une fonctionalité ultime. OpenOffice.org-gnome pourra en tirer partie également.

KDE

Kooka a longtemps été une très bonne alternative à XSane pour KDE, il a notamment été bibliothèquisé pour tenter de répondre au besoin des autres applications (DigiKam?). KDE 4 propose libkscan qui reprend le concept de Kooka. À la différence de GNOME Scan, l'API de libkscan est très très simpliste. Un widget KScanDialog avec deux signaux "scan-terminé" et "roc-terminée" et deux appels de fonction pour récupérer l'image dans un tableau d'octets ou le texte reconnu. Je suis un peu déçu car KDE semble absent dans les discussion en amont pour SANE et HAL. Vos retours sont les bienvenues (captures d'écrans, commentaires, liens, etc.). J'espère qu'avec HAL-scanner, la collaboration fera jour.

Interface

J'ai à cœur de faire de GNOME Scan l'interface la plus optimisée, pour la numérisation la plus efficace et la plus accessible. Je tiens par exemple à permettre de se passer de l'aperçu avant et après numérisation, notamment en ce qui concerne les ROC. L'utilisateur doit pouvoir se contenter de sélectionner format de papier, orientation, résolution, couleur et peut-être rotation ainsique les options de sortie (nom de fichier, de calque, d'album photo, etc.) et lancer directement la numérisation. Pas besoin d'assistant à 12 étapes. La numérisation de masse doit être extrêmement rapide : Appuyer sur Entrée déclenche la numérisation suivante. Il faut également pouvoir revenir en arrière aisément pour changer juste une option et continuer (ex: on numérise d'abord les photos paysage puis les photos portrait, sans relancer toute la machinerie).

Il y a beaucoup de boulot à ce niveau, et les retours, rêves, idées concrètes, patchs sont les bienvenus.

API

Il faut également que la numérisation soit très accessible pour le développeur. Cela passe d'abord par une API flexible et simple. Écrire des greffons pour différentes applications aide à concevoir quelques choses d'efficace. L'optimisation de l'API (éviter d'exposer trop de fonction qui porterai le développeur dans la confusion), la documentation, le développement de passerelles, l'écriture de tutoriels sont impératifs pour la démocratisation de la numérisation dans GNOME.

Contribuer

Depuis 2 ans, je travaille quasiment seul sur ce projet. Les traducteurs aident, Ross Burton m'a envoyé quelques patches et est désormais contributeurs de GNOME Scan. Philip Sadleder et quelques autres utilisateurs des premières heures m'ont bien aidé à corriger des anomalier ou retrouver de la motivation, Vincent Untz m'a toujours volontiers distribués des coups de fouets pour relancer le projet. Mais j'ai toujours cette crainte de concevoir un projet finalement clos, réduit à ma propre vision de la numérisation.

Aussi, n'hésitez pas à contribuer en envoyants vos idées sur le bugzilla. Telle fonctionnalité, telle comportement, telle traitement d'image, telle option, etc. Que chacun donne son avis, ça me permettra d'avoir une vision globale et d'offrir une solution vraiment adapté à l'utilisateur.

---