[sane-standard] More device properties

[abel deuring]

Étienne Bersac wrote:

>> no, i mean that the scanner has two or three read-heads, and can use
>> any one of them, or even two of them at once. that is the 'source'
>> IMHO.
> 
> Ok. I think that a source is a combination of a feeders+read-head. How
> does the backend handle two image at once ? How is this handled by
> sane_read ?

The typical situation is that the scanner sends one chunk of
frontside data, one chunk backside data, frontside data, backside
data... (Allan, yes, I know that some Fujitsu scanners caused you
some headaches because they work a bit more strange ;)

After the first call of sane_start, the backend returns the
frontside data and writes the backside data into a temporary buffer;
when the frontside data is completely transferred, the frontend call
sane_start again, and the backend returns the buffered backside data.

>> i agree fully with the idea of well-known option _names_, but
>> do not see a need to also enforce a series of _values_.

Perhaps not enforced, but encouraged ;) From Eikazo's file Widgets.py:

       # grepping the Sane backend sources, the following ways exist
       # to select and detect an ADF:
       #
       # option source has one of the values:
       #   'ADF'                       (avision, hp, microtek2,
       #				sp15c)
       #   'ADF Rear'                  (avision)
       #   'ADF Duplex'                (avision, fujitsu)
       #   'ADF Front'                 (fujitsu)
       #   'ADF Back'                  (fujitsu)
       #   'Automatic Document Feeder' (bh, epson, mustek, nec,
       #				 pixma,
       #                                sharp, umax)
       #   'Document Feeder'           (snapscan)
       #   'Filmstrip'                 (microtek2)
       #     I'm not 100% sure about Filmstrip, but it could make
       #     sense to treat it similary to an ADF
       #
       # bool option 'adf': artec, ibm
       # bool option 'noadf': canon
       # string option 'feeder-mode', value 'All Pages': matsushita

I did not yet had a look into any external backend -- I might have
found even more variants ;)

We should strongly encourage the usage of options and option values
defined in saneopts.h (or its equivalent for Sane2) and we should
add new options/option values to this file more frequently. At
present, the file contains nothing related to ADFs...

Another point: Think about an ADF-only scanner, that has no duplex
capabilities. If a backend does not define the option "source" (or
whatever else), a frontend has no way to figure out, if the scanner
it is controlling is capable to make ADF scans or not. Hence we
should either require^H^H^H^H^H^H^Hrecommend the usage of the source
option with exactly one value, or we should add some "purely
descriptive" option telling the frontend that a scanner can make ADF
scans.

> Well knowm option types should also be considered. About values. The
> problems with variable string for the same value are :
> 
>       * How to translate ?
>       * How to make backend-independent code (real generic code) ?
> 
> Of course, If the device has more than three sources, then you must
> extends the standard. I think we must redesign source standard in order
> to handle such case. Using ADF is not bad :).
> 
> Frontend programmers should not read each backend documentation, only
> SANE standard. That's the purpose of the standard.

ummm, in theory, yes. But in the real world it is quite difficult to
 anticipate all possible options that might be used by more than one
backend. Just consider how difficult our discussion is, if it makes
sense to add an option "adf-side". We have quite different concepts,
how many variants of ADFs exist/make sense/can be thought of, and
what formal descriptions are required to deal with all possible
devices properly. My crystal ball is defunct since a long time, so I
don't dare to predict that we will be able to cover today all
possible features that may become a standard for scanners produced
in five years ;)

When the Sane1 standard was developed, nobody thought for example of
an infrared channel, but quile many film scanners seem to produce
infrared data. Having an "open way" to respond to such features is
IMHO more important than to attempt to specify everything today.
(And, BTW, except infrared data, the Sane1 standard has proven that
is indeed "good enough" to represent quite many different scanner
features, which were probably not anticipated by the authors.)

Abel