sane-project-website/old-archive/1999-08/0080.html

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