[sane-standard] More device properties

[m. allan noah]

On 1/18/07, abel deuring <adeuring at gmx.net> wrote:
> É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.
>

correct.

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

[snip]

ok- but i seem to be missing something- _WHY_ does the frontend need
to know that an adf is in use? that, i think, is the problem that we
should fix.

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

yes- and this is exactly why i resist the standard listing all the
possible values for an option. It seems ok to suggest a certain
spelling, or a certain leading text for some options for use with
translations, but the backend must have the option to extend as
required.

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

yes, sane1 has much longer legs than most software, a tribute to the
simplicity and usefulness of its design.

allan

-- 
"The truth is an offense, but not a sin"