[sane-standard] More device properties
abel deuring
adeuring at gmx.net
Thu Jan 18 00:02:25 CET 2007
Étienne Bersac wrote:
> Hi,
>
>
>> (1) the paper can be centered/left aligned/right aligned in the
>> feeder
>
> right and left depend on which side of the scan area the ADF is :
> top/bottom/left/right. The paper can be centered/"start" aligned/"end"
> aligned in the feeder.
What I meant is probably the same, what you called the "handles".
Some mechanical guides on the left and right side of the feeder
which are adjusted to match the width of the paper and which ensure
(more or less) that the paper is not skewed when it is moved.
>> (2) some scanners know about the parameters "page width" and "page
>> length"
>
> You mean that e.g. some ADF allow to press paper between two handles,
> and the scanner will scan only between the two handle ?
No, page width and length are parameters for the firmware of some
ADF scanners telling the device the size of the documents. The
length can be used by the firmware to detect feeding problems ("if
the paper does not end after moving it for paper length +/- 10mm,
raise a feeding error"); the width parameter can be used to set the
the origin of the scan window.
>
>> (3) the origin of the scan window coordinates is fixed, or it is at
>> the "corner" of the selected page size.
>
> I don't understand. That's too fuzzy. Please explain.
An attempt of an ASCII drawing:
A----------------- max scan/paper size--------------+
| |
| |
| B----------- paper size ---------------+ |
| | | |
| | | |
| | +-- scan window --+ | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-----------------+ | |
| | | |
| | | |
| +---------------------------------------+ |
| |
| |
+---------------------------------------------------+
Scanners that allow to set the paper size may set the scan window
coordinates relative to point A (top left corner of the max scan
size) or relative to point B (top left corner of the selected paper
size). An example for the latter are the Fujitsu 4120/5120. Their
max scan width is ~225 mm, and they center the paper in the ADF. If
you want to scan an A6 page (width 105mm), you select paper width
105 mm, tl-x=0mm, br-x=105mm. For a scanner that does not move the
origin of the scan window, but which ceneters the paper in the
feeder, you would have to select tl-x = 52mm or so, and br-x = 157mm.
How the area "paper size" is aligned within the area "max scan
size", depends on the paper guides: If both the left and right
guides can be moved/adjusted, or only one of them. ("Decent" ADF
scanners will center the paper in order to ensure that the rollers
which move the paper are placed "grab" the paper symmetrical in
order to avoid skewing the paper, but you never know...)
>> And if we
>> assume that the feeder is properly aligned, I think that (1) is no
>> longer important.
>
> frontend must know how the feeder is aligned.
Perhaps... well, this is probably useful, if you want to have a
selection list with standard paper sizes (A4/A5...). But the
frontend does _not_ need to care about the alignment, if the scanner
allows to set the page width/length, and if it sets the scan window
relative to the selected page size.
>>>> - "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:
>
> 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 the difference between
twain and Sane: A Sane frontend is supposed to support a wide range
of devices, while a Twain driver and its GUI can focus on more or
less special devices ;)
>
>> 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.
>
> I think that this source usage is a confusion of two separate options.
> That's a quirks common in various backend.
Maybe. Actually, I don't care that much about these details, as long
as we have the same options in all affected backends. If one or the
other way to specify the ADF mode does not fit the GUI concept of a
frontend, it is easy to use other GUI elements than suggested by the
backend's options and to "map" the values selected in the GUI to the
options.
>> "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 ;)
>
> ACK. frontend should ask for document size, orientation and duplex mode.
> For (3), please explain the option.
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:
The maximum scan width is limited by the width of the feeder and of
the CCD sensor; the maximum scan length is generally larger than the
scan width. (In other words, scans are mostly made in "portait
mode", though I'm trying to avoid this word -- it is easy to confuse
this with the orientation of the text/images on the paper, which can
also be in portait/landscape.) The feeder moves the paper "across"
the CCD sensor, and the host computer needs to read the scan data
directly from the scanner, while the scan is running.
Normally, you insert the paper into the ADF so that the top edge,
not the bottom edge, of a page is scanned first, so that the backend
"seems" the data coming in starting from the top edge. This data can
be stored in a straghtforward way to most image file formats, and it
is also straightforward to display it in a preview window.
So, no rotation is necessary, provided that for example an
"ordinary" A4 page, printed in "portait mode" mode (main text
direction parallel to the short edge of the paper...) is scanned,
and that the top (short) edge of the paper is scanned first.
For duplex scanners, this works too for the backside data, provided
that the text on the backside starts at the same edge (which is the
case for the average book page or magazine page).
>
>>> * 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).
>
> This option teach the frontend where is the ADF relative to the flatbed.
> The padding is just an offset, teaching where is placed the document in
> the wide scan area.
OK, I understand "padding" meanwhile. Let's call it the offset of a
page of a certain size from the the origin of the entire scan area.
"padding" sounds to me a bit like "pad bytes", i.e. some "fill-in
data" that you can discard.
>
>>> * 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.
>
> Please explain.
See the "ASCII drawing" above and the text below the drawing.
>
>> More important might be a flag like "processing hints" for options:
>
> ACK.
>
> Thanks for your comments.
>
>
>
> This is how i see the problem :
>
> User has a scanner with an ADF and a flatbed. The ADF can be either on
> top/bottom/left/right of the flatbed. The ADF has a padding relative to
> flatbed : when a document is introduced, the document is not at top
> right corner of the flatbed. The ADF can center the document or align it
> to start or end of the side.
>
> User has a multipage document. This document can be simplex or duplex,
> portrait or landscape.
>
>
> Here is an example :
>
> User A has an all-in-one printer with flatbed and ADF.
> * The feeder is at right side of the scan area.
> * The feeder center the document.
> * The center of the feeder is at 170mm from the top of the scan
> area. adf-offset = 170mm
> * Wide scan area (flatbed geometry) = 240x350mm
>
> User A has a multipage A4 document in landscape orientation with duplex
> printing.
>
> * He sets source to "Automatic Document Feeder"
> * He sets format to A4
> * He sets orientation to landscape (in portrait/landscape/reverse
> landscape).
> * He checks duplex.
>
> The frontend computes the scan area and rotation and set various
> options. The scanner geometry does not allow to scan an A4 landscape
> without rotating the document.
>
> * set source = ADF
> * Since the document is landscape (not reverse landscape), the
> images will naturally be rotated 90° clockwise for frontside and
> counterclockwise for backside.
> * Since the document is A4 landscape and rotated, the document
> will be introduced by the 297mm long side. So scan area width =
> 210 and scan area height = 297mm.
> * Since the feeder is at right of the scan area, set tl-x =
> 240-210.
> * Since the feeder center document and feeder center is at 170mm,
> set tl-y = 170-(297/2) = 21,5mm.
> * set br-x = tl-x + 210
> * set br-y = tl-y + 297
>
> According to this example, i don't really know if adf-duplex is usefull.
Why should it not be useful? As I understand you, this is basically
the same use case as for a "ordinary" ADF scanner intended for A4
size paper, where an A4 page is moved parallel to the long edge: If
you want to scan A5 pages, it is reasonable to let the scanner move
the A5 page parallel to the short edge. For many scanners, this will
be faster than to move the A5 page parallel to the long edge. But
you will need to rotate the scanned image by 90 degree, if the
"content" of the page is in "portrait orientation", and frontside
and backside images may need different rotation angles.
> Can device rotate the paper ?
The paper itself? Unlikely ;) The image? this is also unlikely --
RAM is too expensive as to be big enough to store a 600dpi RGB scan
inside a scanner, except for real high-end devices. More over, most
scanners do not have CPUs with a clock speed in the GHz range, so
rotation could easily slow down scanning.
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? Thinking
a bit more about this example, this is probably an A3 scanner,
having a Y range of something like 0..420mm ;) It is hard for me to
believe that an ADF scanner exists which limits the scan length (I
mean the direction of the paper movement) that is shorter than the
scan width... Either way - if this scanner (and you seem to have
access to a device that has at least some similarities to the one I
am trying to describe) is an A4 or A3 scanner: If the X range is
0..297mm, and you want to scan an A4 page so that the resulting
image is in portrait mode, you can do all necessary rotations within
the frontend, including the preview window.
> Another example :
>
> User B has a scanner with flatbed and ADF source.
>
> * The feeder is on bottom of the flatbed, document are introduced
> by the top (adf-side = top).
> * The feeder center document.
> * The feeder has two "handles" the user have to move to the
> "press" the fit the document in. This handles teach the device
> the width of the document. adf-offset is 0mm.
I am not aware of a scanner that has sensors for the paper guides,
but high end beasts might have them. The sensor readings will
probably be "mapped" to the page width.
> * The flatbed geometry is 220x320mm.
>
> User B has a one page simplex A5 document.
> * He set format to A4
> * orientationto portrait.
> * source to ADF
> * Uncheck duplex
>
> Behind the UI, the frontend
>
> * Compute that no rotation is needed (210 fit 220)
> * adf-offset is 0, set tl-x = 0
> * adf-side is top : set tl-y = 0
> * set br-x = tl-x + 210
> * set br-y = tl-y + 297
> * sane_start () :)
>
> Please tell me what you think of.
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?
Abel
More information about the sane-standard
mailing list