Une nouvelle version, la 1.0.21 vient de sortir. Parmi les nouveautés :
- Trois nouveaux backends (kodak, kvs1025 pour Panasonic et p5 pour Primax PagePartner) ;
- 224 nouveaux modèles gérés ;
- Prise en charge de HAL et udev mis à jour ;
- Uniformisation des noms;
- Compilation facilitée sur des architectures peu courantes;
- Mise à jour de la documentation;
- Correction de bugs et multiples améliorations de détail.
La liste des 1777 matériels référencés est particulièrement importante car elle montre que de trop nombreux matériels ne peuvent pas fonctionner hors de la configuration Windows avec laquelle ils ont été vendus. C'est un déni d'interopérabilité.
Il est donc important de consulter cette liste avant l'acquisition d'un scanner. Toutefois, certains modèles non gérés par les backends de SANE fonctionnent fort bien sous Linux avec des pilotes fournis par le constructeur. C'est le cas des imprimantes multifonction de HP où le pilote est installé en même temps que l'imprimante. C'est pourquoi la compatibilité doit être recherchée sur openprinting.org. Le cas d'Epson est un peu différent car les pilotes Epkowa sont réalisés par Avasys, une filiale d'Epson.
Sane peut être utilisé avec de nombreux frontends. On peut citer scanimage, scangui ou Xsane qui est l'interface graphique la plus utilisée. Il ne faut pas oublier le très commode xsane-gimp qui permet de scanner et importer un document depuis Gimp avec Fichier -> Créer -> Xsane: Device dialog...
NdM : Merci à ille qui avait proposé un article sur sane 1.0.21. Note : Comme indiqué en anglais sur la page d'accueil de sane, il manque deux fichiers dans l'archive tar.gz de sane-backends v1.0.21.
Il faut donc télécharger en plus sane-backends-1.0.21-i18n.patch et l'appliquer aux sources :
cd sane-backends-1.0.21
patch -p1 < sane-backends-1.0.21-i18n.patch
Ensuite configure et make comme d'habitude.
Dans une configuration Mandriva 2010, on trouve :
# rpm -qa "*sane*"
sane-backends-1.0.20-8.1mdv2010.0
xsane-0.996-3mdv2010.0
xsane-gimp-0.996-3mdv2010.0
lib64sane-hpaio1-3.9.12-1mdv2010.0
lib64sane1-1.0.20-8.1mdv2010.0
lib64ksane0-4.3.5-0.4mdv2010.0
sane-frontends-1.0.14-7mdv2010.0
sane-backends-iscan-1.0.20-8.1mdv2010.0
Heureusement, les dépendances gérées par urpmi font que ça s'installe tout seul.
Aller plus loin
- SANE (79 clics)
- Scanners gérés (113 clics)
- Prise en charge d'Epson (59 clics)
- Prise en charge multifonctions HP (31 clics)
- Interfaces utilisateur (Frontends) de SANE (45 clics)
# Scan en réseau
Posté par dest . Évalué à 2.
J'ai testé de scanner avec SANE par le réseau et sous Linux mais je n'y suis pas parvenu. L'imprimante est reliée à un petit boîtier en USB et ce boîtier dispose d'un port RJ45 et d'une antenne Wifi.
Sur MacOS, il faut se connecter à ce boîtier par son IP et hop, on numérise. Je n'ai pas réussi sous Linux par le réseau tandis qu'en USB, cela fonctionne.
S'il y a des personnes qui ont réussi à scanner par le réseau et aurait un tutoriel sous le coude, je suis preneur.
[^] # Re: Scan en réseau
Posté par bubar🦥 (Mastodon) . Évalué à 4.
Question peut être bête : es tu sûr d'avoir choisi le bon driver ?
Je demande ça car sur le site de avasys c'est un peu le bronx, on dirait un site de pilotes pour windows, et n'ayant plus l'habitude il m'est arrivé plus d'une fois de me gourrer (surtout si l'epson fait partie d'une classe et n'a pas directement son modèle répertorié).
La sx400 fait partie de la classe, de la famille "NX400/SX400/SX405/TX400/TX409".
Pour le scan en réseau ça fonctionne sans problème chez moi (un autre modèle) avec leur "Image Scan for Linux" (qui est par aileurs très simple et confortable d'emploi). Pour ton modèle, y aussi un "questionnaire", choisir : "network print/scan direct to printer/scan" je sais pas si ça change qq chose... ?)
Doit être sympa ce modèle...
[^] # Re: Scan en réseau
Posté par dest . Évalué à 2.
Je t'avoue que ce n'est plus très frais dans ma tête parce que ça fait quelques mois que je m'en suis occupé.
Autrement oui, j'ai été sur leur site et même installé leur deb mais ça ne fonctionne pas.
En désespoir de cause, j'ai même contacté le support technique qui n'a rien fait d'autre que de me rediriger vers la page d'Avasys.
Autant l'impression en réseau, c'est simple et ça fonctionne rapidement mais alors le scan en réseau, c'est une autre paire de manches.
Si vous êtes plusieurs à plébisciter (c'est peut-être un peu fort) le site d'Avasys, alors j'ai peut-être loupé une étape.
Et t'as raison Tankey, c'est clairement un site qui a un look & feel de driver Windows.
[^] # Re: Scan en réseau
Posté par Anonyme . Évalué à 3.
Peut-être essayé aussi de comparer avec les requêtes effectuées depuis Mac OS X ?
Ça ne résoudra pas le problème en tant que tel, mais ça permettra de savoir si le boulot essaye de faire son job au moins.
[^] # Re: Scan en réseau
Posté par Anonyme . Évalué à 1.
'... ça permettra de savoir si le pilote essaye de faire son job ...'
[^] # Re: Scan en réseau
Posté par superna (site web personnel) . Évalué à 1.
Je cherche ce genre de matériel, quel est le modèle ?
Il manque seulement un support réseau plus complet à Sane !
# Un protocole commun
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
– Salut scanner, tu as quoi comme réglages disponibles ?
– Alors, on peut choisir ma définition, parmi 100, 200 et 300 dpi, on peut aussi choisir le temps d'exposition, et puis aussi…
– Super, alors envoie-moi l'image entre (0, 0) et (42, 12) en 100 dpi à telle exposition…
– Voilà !
– Merci, maintenant, l'image entre (1, 2) et (41, 10) en 300 dpi…
– Voilà !
Ce n'est pas comme s'il y avait besoin de d'avantage de spécificités…
[^] # Re: Un protocole commun
Posté par Kerro . Évalué à 9.
Ils disent exactement pareil pour les imprimantes, alors qu'un vieux pilote pourri en PCL ou PS fonctionne parfaitement (oui bon, pas avec le recto-verso, la sélection des bacs, etc. Mais l'impression tout court c'est tout de même 95% du besoin).
Et puis franchement, j'imagine que je suis fabriquant de scanners. Je file la doc, je file les source de mon premier pilote... et désormais je n'ai plus _jamais_ à coder un pilote. Je fais mon job de fabricant, je fais des économies, ça me fait de la pub. Et je me demande bien comment mes concurrents sont assez stupides pour ne pas avoir fait la même chose.
[^] # Re: Un protocole commun
Posté par detail_pratique . Évalué à 3.
Et c'est aussi comme les cycles des dentifrices ou shampooings.
Mais c'est vrai que dans l'ensemble, ça pue de la gueule et ça a le cheveu terne. Donc autant les mettre dehors.
( Comment ? Quoi ? Comprends pas ! Provocation ? Rhoo ! Mais ça ne veut rien dire ! )
( La provocation, je veux dire )
( Pas la gestion d'une troupe de développeurs deux en un )
Et toi, tu scannes ou tu trimes ? ^.^
[^] # Re: Un protocole commun
Posté par dinomasque . Évalué à 3.
En entreprise (l'essentiel de l'usage des imprimantes), un driver "bien configuré" permet de faire du recto-verso et de sauver des arbres (les expérimentations montrent que les impressions en recto seul sont alors très rares, l'économie de papier approche les 50%).
Un driver qui gère les bacs permet d'imprimer par défaut sur du papier recyclé et de conserver le beau papier blanc pour les impressions "importantes".
Moralité : un driver qui fait plus sur du PCL/PS est nécessaire pour être éco-durable-compliant.
BeOS le faisait il y a 20 ans !
[^] # Re: Un protocole commun
Posté par Kerro . Évalué à 3.
Sur notre parc d'environ 60 imprimantes et multifonctions avec recto-verso, nous avons moins de 5% d'impression sur deux faces. C'est même plutôt du genre 0% sur 50 d'entre elles :-)
Les imprimantes sont configurées en double. Une en recto, une en recto-verso. Pour des raisons "pratiques" les impressions sont par défaut en recto. Presque personne ne souhaite le recto-verso par défaut. Je n'ai pas compris pourquoi (de même que tout le monde est en majuscules dans les logiciels de compta et de gestion, gros mystère).
[^] # Re: Un protocole commun
Posté par Earered . Évalué à 3.
- Quand un tableau est coupé on peut le lire quand même d'un coup d'œil en posant les feuilles cote à cote.
- Le verso sert de brouillon quand il n'y a pas de cahiers fournit en nombre suffisant.
Pour la compta, je ne sais pas, une hypothèse : des gens de la compta travaillent peut être avec des portables ou des claviers sans pavé numérique (d'où le caps-lock enclenché pour avoir les chiffres toujours dispo peut être) ?
[^] # Re: Un protocole commun
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Un protocole commun
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Inutilisable en entreprise, où des travaux d'impressions sont lancés à la chaîne par plusieurs personnes, de toute façon.
[^] # Re: Un protocole commun
Posté par Frédéric Perrin (site web personnel) . Évalué à 6.
Et où deux fois sur trois l'impression traîne dans le bac jusqu'à ce que quelqu'un vienne faire le ménage.
[^] # Re: Un protocole commun
Posté par gpe . Évalué à 3.
ça ne marche pas comme modèle. Quand tu fabriques un matos tu es obligé de fournir un pilote et de le maintenir. Tu ne peux pas te permettre de dépendre de quelqu'un d'autre et d'attendre son bon vouloir pour que ton produit soit fonctionnel.
Je le vois bien déjà dans le monde pro en s'adressant à des boîtes qui font du dev. On a essayé de juste fournir le matos avec les API les docs pour permettre à nos clients de développer selon leurs spécificités sur notre matos. Résultat:
« - ah vous ne fournissez pas de pilote ?
- euh non mais vous avez des exemples.»
Ils essaient et peu de temps après ils appellent le support parce que ça ne fonctionne pas. Tu te tapes donc beaucoup de support pour réussir à faire fonctionner leur code. Bref au final on écrit des pilotes complets que l'on maintient et c'est bien plus simple comme cela.
Donc penser que l'on peut fabriquer du matos sans jamais avoir à coder des pilotes me semble une utopie. Mais cela n'empêche pas de fournir les moyens pour ceux qui veulent coder leur propre version bien sur.
[^] # Re: Un protocole commun
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Un protocole commun
Posté par Victor . Évalué à 6.
[^] # Re: Un protocole commun
Posté par Kerro . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un protocole commun
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Il y a bien TWAIN voir http://www.twain.org/ : Selon http://www.sane-project.org/intro.html ce protocole a le défaut de ne pas séparer l'interface avec le matériel de l'interface avec l'utilisateur. Grave défaut, à vrai dire que de ne pas séparer backend et frontend car le fondement de l'interopérabilité consiste à spécifier les interfaces.
[^] # Re: Un protocole commun
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
[^] # Re: Un protocole commun
Posté par gpe . Évalué à 4.
[^] # Re: Un protocole commun
Posté par monde_de_merde . Évalué à 2.
[^] # Re: Un protocole commun
Posté par lolop (site web personnel) . Évalué à 3.
Pour le vulgus scanner commun, la tendance est à l'abaissement des coûts, et l'électromécanique vendue doit être minimale, avec des capacités en calcul et stockages très réduites... tout est alors dans le driver sur la machine cliente, et le matériel a une interface de très bas niveau.
Pour le (très) haut de gamme, ça doit être un morceau d'intelligence de photocopieur numérique extrait pour n'en retenir que le scanner, et dans ce cas en effet l'interface fournie est plus balèze.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# HAL?
Posté par Albert_ . Évalué à 6.
Il me semble que HAL est sur le point de disparaitre. J'espere que la mise a jour en question est une preparation a sa mort annonce.
[^] # Re: HAL?
Posté par ZeroHeure . Évalué à 7.
Ça n'a aucun sens ce que tu dis. En milieu professionnel on a besoin de technologies supportées longtemps. La rétro-compatibilité est nécessaire.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: HAL?
Posté par Albert_ . Évalué à 4.
En meme temps par rapport a ta remarque sur l'embarque je croyais que justement c'etait une des raisons de la mort annonce de HAL.
[^] # Re: HAL?
Posté par ZeroHeure . Évalué à 3.
Pour l'embarqué, je parlais de ce qui est déjà en place, et qui ne peut (ou alors difficilement) être totalement mit à jour par les dévs. Mais à bien y réfléchir, c'était assez stupide de ma part.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: HAL?
Posté par Albert_ . Évalué à 2.
pas grave je ne suis pas (trop) succeptible.
Un remarque je ne suis pas sur que l'embarque et un sane c'est tres compatible maintenant c'est vrai que l'on peut imaginer un des mini ordi sous android avec sane installe (je ne sais pas du tout si cela pourrait fonctionner c'est une hypothese) mais me servir de mon telephone pour brancher mon scanner je trouve que c'est un peu pousse. Mais je suis un vieux c... et pour moi un telephone cela doit avant tout me permettre de ... telephoner pas de faire le cafe!!!!
# Un meilleur support que sous widows
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 8.
Au final, ces politiques imbéciles des constructeurs finissent par favoriser le libre. Au troisième changement de scanner — à qualité constante puisque les progrès dans le domaine sont loin d'être notables ces dix dernières années — pour cause de problèmes de pilotes, la plus part des gens finissent par écouter la petite voix qui leur susurre de changer de voie. Pourquoi ne pas essayer un système d'exploitation qui évite toute cette pollution, ces dépenses, ces efforts inutiles et qui en plus ne coûte rien ? Après tout ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Un meilleur support que sous widows
Posté par Psychofox (Mastodon) . Évalué à 4.
Pourtant il rend toujours le même service depuis des années sur mes machines puisqu'elles sont équipées d'un OS propre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
# Minolta scan dual II
Posté par luc schimpf (site web personnel) . Évalué à 2.
Je m'acharne depuis 10 ans, à faire fonctionner un scan dual II avec sane.
Depuis quelques années il est annoncé comme fonctionnel mais je n'ai jamais réussi à obtenir une image.
Si quelqu'un y est arrivé, je suis preneur de toute info.
[^] # Re: Minolta scan dual II
Posté par Pierre Tramo (site web personnel) . Évalué à 5.
[^] # Re: Minolta scan dual II
Posté par luc schimpf (site web personnel) . Évalué à 3.
[^] # Re: Minolta scan dual II
Posté par patate . Évalué à 4.
De mémoire, il fallait allumer le scanner porte fermée, lancer une commande sane qui l'initialise, ouvrir la porte et insérer le porte négatifs, et entrer la commande sane qui va bien pour numériser.
Désolé, je n'ai rien de plus précis et il est possible que je me trompe... De toute façon, j'ai abandonné sane après trois essais tellement c'était mal fichu et les interfaces mauvaises. Ça a peut-être changé depuis, mais VueScan est infiniment meilleur à tous points de vue pour scanner des négatifs, à l'époque (il y a 1 an) en tout cas.
[^] # Re: Minolta scan dual II
Posté par luc schimpf (site web personnel) . Évalué à 2.
C'est bien mon avis aussi, et j'ai beaucoup de mal à comprendre une telle différence de qualité et d'ergonomie.
Je refuse de croire que les dèvs de sane soient moins compétents que Hamrick mais ça y ressemble quand même fortement...
[^] # Re: Minolta scan dual II
Posté par goom . Évalué à 2.
On a le même truc avec turboprint qui propose des drivers pour imprimantes pour Linux.
[^] # Re: Minolta scan dual II
Posté par gpe . Évalué à 1.
[^] # Re: Minolta scan dual II
Posté par patate . Évalué à 2.
# Pas besoin de drivers
Posté par Petit_Scarabee . Évalué à 3.
[^] # Re: Pas besoin de drivers
Posté par Xavier Poinsard . Évalué à 2.
[^] # Re: Pas besoin de drivers
Posté par goom . Évalué à 3.
On est loin du simple scanner à plat du particulier
[^] # Re: Pas besoin de drivers
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je vois pas trop l'intérêt d'un << scanner professionnel >> sauf dans le cadre d'un atelier de reprographie.
# Tour d'horizon
Posté par gUI (Mastodon) . Évalué à 3.
En effet pour ma part je n'utilise pas de scanner, mais si je dois parler Linux autour de moi, c'est toujours sympa de pouvoir répondre à quelqu'un qui me demande "il est bon le support des scanners" ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Tour d'horizon
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Sauf qu'en général, par support des scanners, les gens incluent généralement la solution d'OCR qui va avec, et c'est là qu'est l'OS...
[^] # Re: Tour d'horizon
Posté par Psychofox (Mastodon) . Évalué à 2.
La plupart des gens qui ont un scanner, c'est pour garder une copie électronique de papiers importants pour les envoyer par email et/ou de faire des photocopies à la maison.
[^] # Re: Tour d'horizon
Posté par 16aR . Évalué à 2.
Du coup, j'ai une VirtualBox windows pour faire tourner mon scanner/imprimante HP. C'est juste un overkill (en plus le soft est bien pourrave. Heureusement que l'OCR est là)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.