[sane-standard] More device properties

[abel deuring]

m. allan noah wrote:

>>       * 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 have too problems grasping these fine details ;)

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

The point is that some ADF scanners want to "know" the paper size
and others that "have no idea" about the paper size. For the former,
 some set the scan window relative to the paper size, like some
Fujitsu models, while others set the scan window relative to the max
scan size.

So we have the situation that either a frontend must be able to deal
with all cases or that the backends must "normalize" their options
to something defined for Sane2. I think it is better to leave the
details to the frontends -- it is too difficult to anticipate all
possible variants of ADF types and ADF related options as to try to
define something quite specific for the standard. Before Olaf
convinced me otherwise, I did not believe that ADF scanners exist
which do not acquire the scan data while the paper is moving...

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

Think about the scanners, where the feeder moves a document onto the
glass pane, and where the scanner make an "ordinary" flatbed scan.
Here it makes indeed sense to know, from which side a document is
moved onto the glass pane: If a frontend has a selection list for
document sizes, and if the the scanner's firmware has "no idea"
about paper sizes, the frontend must calculate the scan window
coordinates for the flatbed area.

Abel