[sane-standard] More device properties

[abel deuring]

Olaf Meeuwissen wrote:
> abel deuring <adeuring at gmx.net> writes:
> 
>> Hi all,
>>
>> Étienne Bersac wrote:
>>
>>> Thanks for you comments. There are very useful.
>>>
>>>>   - alignment of original to scan origin or not (centered feeds)
>>> That's an important point. SANE should provide a "adf padding" option or
>>> similar.
>> Some hints how the alignment of the paper width in the feeder
>> affects the scan window settings may be useful, but I think this is
>> too simple.
>>
>> I see several "scanner parameters" that can affect the scan window
>> settings:
>>
>> (1) the paper can be centered/left aligned/right aligned in the
>>     feeder
>> (2) some scanners know about the parameters "page width" and "page
>>     length"
>> (3) the origin of the scan window coordinates is fixed, or it is at
>>     the "corner" of the selected page size.
>>
>> Another question is, if a frontend really needs to know about all
>> these details: If a user does not properly adjust the paper width of
>> the  feeder, the scan results will anyway be a bit messy. And if we
>> assume that the feeder is properly aligned, I think that (1) is no
>> longer important.
> 
> In the most extreme case a frontend doesn't need to know anything:
> just scan at the default settings.  The thing is that some users want
> to do things that require access to the very last little bit of
> configurability.  That doesn't automatically imply that every little
> option should be in the standard, of course.

Agree. But I had a hard time to figure out, how and why a frontend
should deal with the parameter "ADF centers/left aligns/right aligns
documents".

>>>>   - limiting scan area to page size
>>> This can be done via {tl,br}-{x,y}. Isn't it ?
>> right.
> 
> True, but I was thinking of an advanced boolean option where user
> could turn this behaviour off if they want to.

Couldn't this be left to the frontend, like a button "set scan
window size to page size"?

>>>>   - rotation of original
>>> Imo, this is post processing, device/sane/backend should not care this.
>> right.
> 
> On second thought, this option is not limited to ADF.  However, if the
> hardware can do rotation of the image data, there should be an option.
> I know of several scanners that can do mirroring in hardware.  Why
> have the backend or frontend do this if the hardware can?

Yes, if the _hardware_ can do that, providing an option is
reasonable. But a frontend that wants to support rotation has to
deal with backends/scanners that don't support rotation anyway, so
it must implement it for itself.

>> ...only for some, if any, ADF scanners. Those ADF/flatbed scanners I
>> know work a bit different in ADF mode: They do _not_ place the paper
>> on the glass pane and then move the scan head across the pane;
>> instead they acquire the scan data while the _paper_ is moving,
>> while the scan head stays at a fixed position. This is faster, since
>> the paper must be moved anyway in ADF mode, so first placing the
>> paper on the glass pane and then scanning it in "flatbed mode"
>> simply requires additional time.
> 
> I have experience with both types.  The higher end EPSON scanners (A3,
> business market) pull the page onto the bed.  If you scan A4 oriented
> so that two pages fit on the bed you get the situation where the first
> page results in a single page on the bed and all following pages will
> have _two_ pages on the bed.  Ideally, you would only scan the page
> that was just put on the bed and ignore the rest.  Of course, media
> size detection is a prerequisite to get this done.

Thanks. It was hard for me to believe that such machines really
exist, but you convinced me ;)

Abel