[sane-standard] More device properties

[Étienne Bersac]

Hi,

> Translations are indeed a good reason to enocurage the usage of
> well-known options.

I even vote for easy parsable value like "flatbed", "adf-front",
"transparent-film", not string like "Flatbed", "ADF front", "Transparent
Film", "Automatic Document Feeder" which are more "human readable". In
fact, we should use string like extensible C enum values, not as source
label.

> As I understand Etienne, he is aiming for a set of options (or some
> other data provided by a backend) that allow to map userfriendly GUI
> options like "prepare for ADF scans of A4 pages" to a proper set of
> backend options. And this becomes the more difficult, the more
> "option variants" we have.

Yes. See http://home.gna.org/gnomescan/screenshots . Also, i think that
a frontend developer should be able to develop for every backend just by
using test backend. That's crazy to see that Ekaizo developer has to
grep SANE source in order to know how all backends handle ADF source.
That's a quirk.

> > yes, sane1 has much longer legs than most software, a tribute to the
> > simplicity and usefulness of its design.
> 
> ...and this should stay so for Sane2. But we can also try to clean
> up at least a part of the mess we had with unnecesarily varying
> option names and option values in Sane1 backends. While these
> options should not be fixed in the standard itself, we can aim for a
> sort of procedure or "good practice" or whatever else to prevent an
> uncontrolled growth of the number of similar option variants.

Agree. I really find sane options handling great ! It make backend and
frontend developer's live easier. What you name "good practice" is just
what SANE call "Well-known option". We should extends as far as possible
well known option. As soon as an option can be implemented in two
backends, add it in the standard.

I even think the list of well know option should be a seperate document
(can be implemented either in sane 1 or 2) and this document can evolve
as needed by new devices. This will make SANE very open both in the code
and in the doc :)

Étienne.
-- 
Verso l'Alto !
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.alioth.debian.org/pipermail/sane-standard/attachments/20070118/45592590/attachment.pgp