[sane-standard] More device properties

[m. allan noah]

On 1/17/07, Étienne Bersac <bersace03 at laposte.net> wrote:
> Hi,
>
> sorry, i mis explain the end of my mail.
>
> > So we should add to the standard :
> >
> >  - paper-width (fixed mm)
> >  - paper-height (fixed mm)
> > or
> >  - adf-alignement (string) {centered, start, end}
> >  - adf-offset (fixed mm)
> >  - adf-side (string) {top,bottom,left,right}
>
> I mean, SANE standard should state that :
>
> A backend which provide "Automatic Document Feeder" source should
> provide the following options :
>
>       *  duplex (boolean)

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.

many units have no flatbed. in those models, the 'source' option would
be useless, if it was always adf.

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

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

>
> and one of the following option set :
>
>       * paper-width (fixed mm)
>       * paper-height (fixed mm)
>

this pair makes sense to me :)

> and
>
>       * 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?

i assume that if the user sets the paper guides properly, and tells
the backend what the paper size is (or backend auto detects), then it
is very easy for those backends that need it (those that dont do it in
hardware), to tell the scanner's flatbed portion to add the offset to
the window before scanning. for those that do this in hardware
(fujitsu/avision/etc), you dont have to do anything to the backend or
frontend.

i guess my big problem with this idea of exposing offsets is that it
requires front-ends to understand that when 'adf' is set, the values
of tl-x/y br-x/y are not 'real' anymore, but must be 'fudged' with
some offset. (which is not true for all adf scanners...) this
distinction between adf and fb will lead to errors when front-end
writers dont have one of the affected adf's to test with.

therefore, let the adf units simulate a 'virtual' flatbed of 'paper'
size as much as possible, even to the point of changing the maximum
br-x/y when the paper size changes, and always moving the tl-x/y as
required.

please help me understand the 'adf-side' option? it would seem that
this is not something that the backend can 'know' without asking the
user, because the concept of 'top' or 'bottom' depends on how the
paper was loaded, not how the scanner was built...

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