I'm working on a backend for Bell+Howell document scanners and a
command line frontend suitable for batch scanning. These scanners
are typically equipped with automatic document feeders and are not
flatbed scanners. Some models are capable of duplex scanning. These
have dual cameras which capture both sides of the paper as the paper
travels through the scanner.
In a scenario where 3 pages are loaded into the feeder, a "scan all
pages in the feeder" operation is requested in duplex mode, one would
expect to produce 6 images (3 fronts and 3 backs). The following
sequence of calls are made. Elipses indicate many such calls and
in the case of sane_read, the last call returns SANE_STATUS_EOF.
[bh] sane_init called
[bh] sane_open called
[bh] sane_control_option called (option:0, action:0)...
[bh] sane_get_option_descriptor called (option:0)...
[bh] sane_start called
[bh] sane_get_parameters called
[bh] sane_read called...
[bh] sane_start called
[bh] sane_get_parameters called
[bh] sane_read called...
[bh] sane_start called
[bh] sane_get_parameters called
[bh] sane_read called...
[bh] sane_start called
[bh] sane_get_parameters called
[bh] sane_read called...
[bh] sane_start called
[bh] sane_get_parameters called
[bh] sane_read called...
[bh] sane_start called
[bh] sane_get_parameters called
[bh] sane_read called...
[bh] sane_start called (returns SANE_STATUS_NO_DOCS)
[bh] sane_cancel called
[bh] sane_close called
[bh] sane_exit called
I'd be interested in knowing whether you think that the call sequence
above is following the standard, specifically the portion I've quoted
below, from section 4.4 Code Flow.
"Image data is collected by repeatedly calling sane_read().
Eventually, this function will return an end-of-file status
(SANE_STATUS_EOF). This indicates the end of the current frame.
If the frontend expects additional frames (e.g., the individual channels
in of a red/green/blue image or multiple images), it can call sane_start()
again. Once all desired frames have been acquired, function sane_cancel()
must be called. This operation can also be called at any other time to
cancel a pending operation. Note that sane_cancel() must be called
even if the last read operation returned SANE_STATUS_EOF."
I'd argue that a batch scanning front-end is expecting additional
frames when it is attempting to empty the feeder and it need not
call sane_cancel until it has detected an empty feeder (sane_start
returning SANE_STATUS_NO_DOCS). In fact, I'd say that this judicious
calling of sane_cancel is the only way that a front-end can "hint"
to a back-end the duration of a "batch". This is important
if one wants to take advantage of a high-performance batch mode that
the Bell+Howell implements. In this mode, the scanner is free to
be ahead of the host during a scan operation, buffering image data
in its own memory. This batch mode needs to be started (I do it in
the first start_scan call) and then aborted (I do it in the sane_cancel
call).
If you are thinking that the code flow above is NOT following the
standard, then consider the following:
In duplex mode, the backend delivers the front image for first sane_start
and the back image for the next sane_start. Up until this point only a
single "real" START SCAN has been sent to the scanner, but there are
two images available for the backend to read and transmit to the frontend.
Also, if the frontend calls sane_cancel each time after sane_read returned
SANE_STATUS_EOF, there would be no way for the backend to know whether
the user wants the behavior above (normal) or whether they cancelled
the operation after the first front page and have started a new scan
(in which case scanning the front page of the next document would
be the correct action for the backend).
Thanks,
Tom Martone
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com