[sane-standard] More device properties

[abel deuring]

Étienne Bersac wrote:

>>> ACK. However, some might allow ADF preview, we must support that. The
>>> backend must teach the frontend if it can preview with ADF.
>> Ummm, I would rather suggest to support a more general way to set
>> the scan window that is useful for every ADF scanner: Let the user
>> make a test scan with one page; display this page in a preview
>> window; allow to set page size (if possible/reasonable) and the scan
>> window; let the user insert the test page back into the ADF; let him
>> make again a test scan and so on.
> 
> That's just crazy. Users are just fed up to walk trough the room just to
> relaunch a preview. (In my case, my HP is networked and my mother has to
> walk from the living room to my bedroom in order to feed the scanner,
> that's quite long, and running the there and back trip more than twice
> just makes user crazy).

well I didn't want to suggest these repeated previews as a
recommended procedure -- I only wanted to point out that previews
for ADF scanners are a bit tricky. Consider this "trickyness" -- no
way to automatically put a paper back into the feeder, and no way to
repeat scans with the same document without placing it into the
feeder -- simply as a challenge for a frontend.

>> I was trying to figure out, how this "feed from the right side of
>> scan area" device works, to which you obviously have access.
>>
>> The "average" ADF scanner works this way, perhaps you can explain,
>> where your scanner works differently: […]
> 
> I own an HP OfficeJet G85 all-in-one printer which introduce paper
> left-side-first in the flatbed, scan the paper, then eject it and while
> feeder is no empty. The paper is moved left-to-right. I agree this is
> not the fastest way, and new HP all-in-one printers do not work like
> that. However, such device exsists and we must support it.
> 
>>> According to this example, i don't really know if adf-duplex is usefull.
>> Why should it not be useful?
> 
> You're right. In fact, some backend has a duplex option (hpaio does). We
> should add it to the well known option.
> 
>> Another viewpoint: If the scanner moves the paper "by default from
>> left to right", i.e., for example an A4 size ADF scanner that moves
>> the paper parallel to the short edge, shouldn't the backend simply
>> set the X range to 0...297mm and the Y range to 0..210mm? 
> 
> This mean that the backend rotate the picture in order to follow the
> scan area rotation. That's a wrong idea. Backend must not rotate, they
> just get data from device and drop them to frontend through sane_read
> ().

ok, another attempt: How does an image file look like that is made
from an A4 page using scanimage (no "fancy" frontend!) and this
scanner that moves the paper from left to right, i.e., parallel to
the short edge of the paper? Is the image in landscape or portrait
format? See also my comment on the words top/bottom/left/right below.

Does this scanner move the document first and scans it in a second
step the same way as when it had been placed manually on the glass
pane, or does it scan while moving the paper? (Olaf convinced me
that the former type really exists ;)

>> Well, as I understand it, both cases you describe boil down to these
>> parameters and questions:
>>
>> - alignment of the paper in the feeder: centered/corner 1/corner 2
>>   (other possible alignments should be considered broken...)
>> - "clever" support of the page width/length parameters by the
>>   frontend, which must be aware of a possible shift of the origin of
>>   the scan window coordinates to the top-left corner of the selected
>>   page size
>> - which information is missing for scanners that can move an A4 page
>>   parallel to its short edge?
> 
> Yes. Adding a offset info for scanne that do not support paper-size.
> 
> So we should add to the standard :
> 
>  - paper-width (fixed mm)
>  - paper-height (fixed mm)

...as a well-known (no a required) option for ADF scanners that
support it. Additionally, it might make sense to know, if setting
the page size affects the position of the coordinates origin for the
scan window.

> or
>  - adf-alignement (string) {centered, start, end}
>  - adf-offset (fixed mm)
>  - adf-side (string) {top,bottom,left,right}

"top,bottom,left,right" need to be clarified: The Postscript file of
the Sane1 standard http://www.sane-project.org/sane.ps has on page
11 a figure "transfer order of image data bytes". "ADF side top"
means that the ADF is positioned so that the paper is moved from
top/right/left/bottom, relative to the orientation of the output data.

Abel