En fait il y a une légère différence d'objectif entre libsane et libinsane:
- Libsane cherche à apporter un support pour un maximum de périphériques d'acquisition d'images, sans trop se soucier de quel type de périphériques il s'agit exactement ou de comment les applications vont interagir avec.
- Libinsane cherche à supporter les mange-papiers (et que les mange-papiers) le mieux possible, en fournissant un protocole précis pour interagir avec eux.
De ce que j'en ai vu, la libsane passe les appels des applications quasi-directement aux backends (pilotes). On pourrait rajouter une surcouche directement dans la libsane pour essayer de normaliser tout ça, mais on risquerait de perdre en flexibilité: Parce-qu'elle impose très peu aux pilotes, pratiquement tout ce qui génère une image peu être intégré dans la libsane. Il y a même un backend v4l (video4linux ; support des caméras ; désactivé par défaut dans Sane).
Deux exemples:
- La plupart des backends Sane propose une option source. Mais la libsane ne normalise pas du tout les valeurs possibles pour ce champs. Cette option acceptera généralement les valeurs Flatbed et Automatic Document Feeder. Mais il y a par exemple les scanners Canon CanoScan N1240U/LiDE30 qui ont pour sources possibles Normal, Transparency et Negative. Seule la première valeur est pertinente dans le cas de Libinsane. Les autres marcheront peut-être sur un malentendu mais ne sont pas officiellement supportées.
- La plupart des backends Sane propose les options tl-x, tl-y, br-x, br-y pour définir la zone à scanner. Le backend v4l) ne les proposent pas. La libinsane devrait fonctionner même si ils sont absents, mais c'est plus un coup de bol qu'autre chose.
[^] # Re: libsane et libinsane
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Base de données de scanners : besoin de contributeurs (yep, encore). Évalué à 3.
En fait il y a une légère différence d'objectif entre libsane et libinsane:
- Libsane cherche à apporter un support pour un maximum de périphériques d'acquisition d'images, sans trop se soucier de quel type de périphériques il s'agit exactement ou de comment les applications vont interagir avec.
- Libinsane cherche à supporter les mange-papiers (et que les mange-papiers) le mieux possible, en fournissant un protocole précis pour interagir avec eux.
De ce que j'en ai vu, la libsane passe les appels des applications quasi-directement aux backends (pilotes). On pourrait rajouter une surcouche directement dans la libsane pour essayer de normaliser tout ça, mais on risquerait de perdre en flexibilité: Parce-qu'elle impose très peu aux pilotes, pratiquement tout ce qui génère une image peu être intégré dans la libsane. Il y a même un backend v4l (video4linux ; support des caméras ; désactivé par défaut dans Sane).
Deux exemples:
- La plupart des backends Sane propose une option
source. Mais la libsane ne normalise pas du tout les valeurs possibles pour ce champs. Cette option acceptera généralement les valeursFlatbedetAutomatic Document Feeder. Mais il y a par exemple les scanners Canon CanoScan N1240U/LiDE30 qui ont pour sources possiblesNormal,TransparencyetNegative. Seule la première valeur est pertinente dans le cas de Libinsane. Les autres marcheront peut-être sur un malentendu mais ne sont pas officiellement supportées.- La plupart des backends Sane propose les options
tl-x,tl-y,br-x,br-ypour définir la zone à scanner. Le backend v4l) ne les proposent pas. La libinsane devrait fonctionner même si ils sont absents, mais c'est plus un coup de bol qu'autre chose.