[sane-standard] More device properties

[abel deuring]

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.

>>   - limiting scan area to page size
> 
> This can be done via {tl,br}-{x,y}. Isn't it ?

right.

> 
>>   - rotation of original
> 
> Imo, this is post processing, device/sane/backend should not care this.

right.

>>   - "ADF preview" (feed first page, do a preview scan, leave it on the
>>     scan area so the user can fiddle with whatever other options before
>>     starting a scan of a 100 page document.  You may even want to allow
>>     for repeating the preview with the same page.)
> 
> That makes sense.

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

> So, I propose the following options add:
> 
>       * simplex/duplex document
>               * name: "adf-duplex"
>               * title: "Duplex/simplex"
>               * desc: "Wether the document in the ADF is duplex or
>                 simplex."
>               * type: string enum
>               * values: none/long-edge/short-edge

I think the options currently used by the Fujitsu and Avision
backends (and perhaps others) are sufficient: source = flatbed | ADF
front | ADF back | ADF duplex.

"long edge/short edge" depends on the paper size: I can scan an A5
size paper in landscape mode, if the maximum scan size is at least
A4. For proper rotation of the scanned images by a frontend, you
need to know several things:

(1) Which "rotation axis" is used by humans in order to turn the
    paper from the front side to the back side (aka "long edge
    binding/short edge binding" for books) -- this must be selected
    for each batch of documents,
(2) how this axis is oriented, when the paper in the ADF,
(3) the orientation of the frontside and backside images as produced
    by the scanner.

It might make sense to add an option for (3) to ADF-duplex backends,
but (1) and (2) are a challenge for the UI of a frontend ;)

>       * ADF introduced side
>               * name: "adf-side"
>               * title: "From which side of the scan area the document
>                 come from"
>               * desc: ""
>               * type: enum
>               * values: right/left/top/bottom

Is this really necessary? I have the impression that this mixes with
your suggested adf-padding and the details, how a scanner handles
the paper size settings (if the latter is settable at all).

>       * ADF document centered
>               * name: "adf-centered"
>               * title: "Document centered in ADF"
>               * desc: "Expose wether document are centered in ADF."
>               * type: Bool
>       * ADF padding
>               * name: "adf-padding"
>               * title: "ADF padding"
>               * desc: "Expose the padding of the document in the ADF,
>                 relative to scan area origin of the adf-side. If
>                 adf-centered is set to true, then the padding refer to
>                 the center of the document."
>               * type: Fixed
>               * unit: mm
>               * readonly

See above: The details, how the scan window coordinates are affected
by mechanical details of an ADF etc, are a bit more complicated, I
believe.

> 
> I guess adding those options worth adding a "adf" options group :)


More important might be a flag like "processing hints" for options:
We are talking about some options, which do not need to be shown to
the user, but which can help a frontend to make "better decisions"
how to set other options or how to post-process the data.

Abel