[sane-standard] More device properties
abel deuring
adeuring at gmx.net
Thu Jan 18 20:14:05 CET 2007
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
More information about the sane-standard
mailing list