[sane-standard] More device properties

[m. allan noah]

On 1/17/07, Étienne Bersac <bersace03 at laposte.net> wrote:
> Hi,
>
> > >       * adf-alignement (string)  {centered, start, end}
> > >       * adf-offset (fixed mm)
> > >       * adf-side (string) {top,bottom,left,right}
> > >
> >
> > i still do not understand the need for these, are they only for
> > scanners that use the flatbed as part of the adf path? do they not
> > have paper guides on the input chute?
>
> They are for scanner which do not handle paper-size. However, if backend
> implement virtualy paper-size, this is better ; you're right.
>
> So, everyone is ok to add paper-width and paper-height option ? If yes,
> we then just have to "fix" the "duplex" option :)

only you and i are speaking now. that is not everyone :)

>
>
> > it is not enough to have such a flag. most fujitsu adf scanners can
> > do: adf front, adf back, or adf duplex, so i would need a tri-state
> > option, and the name 'duplex' would be misleading.
>
> Ok, for an enum {front,back,duplex}, what name do you propose ?

i propose not to use it at all, see below.

>
> > many units have no flatbed. in those models, the 'source' option would
> > be useless, if it was always adf.
>
> The backend does not have to implement source option if it's useless.
>
> > in models with both adf and flatbed, the 'duplex' option would be
> > enabled/disabled based on setting of 'source', requiring the user to
> > provide two inputs to change from 'flatbed' to 'adf duplex'.
>
> Yes, of course. That's two options.

but from the user's perspective, its only one action. for instance: i
was scanning the glass, now i want to scan the back of the paper in
the adf.

>
> > and so, fujitsu and avision currently use the 'source' option to do
> > this in one step. think of 'source' not as which piece of hardware
> > will be used, but rather which 'location' in the scanner will have a
> > paper over it. this fixes the problem of epson units with two TPU
> > locations as well...
>
> You mean that on some devices, there is two ADF : one which introduce
> paper frontside, and one which introduce backside ? Do "ADF duplex" and
> "ADF front" be physicaly the same source ? I'll test duplex on my HP
> (the backend propose a duplex option, but i don't know if the device
> actually scan duplex paper).

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.

>
> The idea is : if the device has two ADF mouth (front and side), then
> provide both in source option. However, keep a "duplex" option. (This
> might even be useful for both ADF :P).

you see that it is not enough for sane standard to list the only
possible sources as adf, tpu, and flatbed. this is artificially
limiting. the standard could certainly suggest or require certain
spellings or abbreviations of 'ADF', but it cannot know what 'source'
some future scanner will offer (slide holder, negative strip, film
reel). i agree fully with the idea of well-known option _names_, but
do not see a need to also enforce a series of _values_.

once you have made this mental leap that 'source' is entirely under
the control of the backend, it makes for a much simpler design to use
'source' to distinguish between different read-heads in the scanner.

allan

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