[sane-standard] More device properties

[abel deuring]

Étienne Bersac wrote:

>> 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.

Well, I also contributed to the mess in the option names. I am the
one to blame for the option value "Automatic Document Feeder" in the
Sharp backend, so I don't dare to complain too loudly ;)

>>> 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.

What I meant is, that we only very seldom, if ever, managed to
extend the list of well-known options for Sane 1 -- and the result
is the mess with option names and values for ADF scanners and also
some other data. As an example, here is a list of the values for
SANE_Device.type:

  'virtual device': 	    test, v4l
  'flatbed scanner':        abaton, agfafocus, apple, avision,
                            canon630u, canon, epson, ibm, leo,
                            lexmark, ma1509, microtek, microtek2,
                            mustek, mustek_pp, nec, pie, pint,
                            ricoh, s9036, sceptre, sharp, sm3600,
                            sm3840, st400, tamarack, teco1, teco2,
                            teco3, umax, umax1220u

    'film scanner'          avision, canon
    'scanner'               bh, fujitsu (ALL models), hp3500
    'sheetfed scanner'      avision, matsushita
    'flatbed'               artec
    'processor'             bh (perhaps... the backend returns the
                               SCSI device type)
    'slide scanner'         coolscan
    'still camera'          dmc
    'flatbed (CCD 300 dpi)' mustek_pp
    'USB sheet-fed scanner' plustek
    'USB flatbed scanner'   plustek, u12
    'video camera'          qcam
    'flatbed/ADF scanner'   sp15c
    'webcam'                stv680
    'page scanner'          umax

(I made this list in August last year, so things may have changed a
bit meanwhile).

My point is that we should _actively maintain_ the "well-known
options", and we may need some more or less formal procedure for it,
like: Proposals for changes/extensions of the well options should be
announced on the sane-devel mailing list, and should be committed at
the earliest two weeks later.

> 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 :)

Right. Actually, that should be two files: a C header files with
#defines for the options, and a text file (ot Tex file) that
describes them.

Abel