kopia lustrzana https://gitlab.com/sane-project/website
348 wiersze
12 KiB
HTML
348 wiersze
12 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>sane-devel: Re: Writing Fujitsu M3091 backend</TITLE>
|
|
<META NAME="Author" CONTENT="Tom Martone (tom@martoneconsulting.com)">
|
|
<META NAME="Subject" CONTENT="Re: Writing Fujitsu M3091 backend">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: Writing Fujitsu M3091 backend</H1>
|
|
<!-- received="Wed Feb 28 18:25:55 2001" -->
|
|
<!-- isoreceived="20010301022555" -->
|
|
<!-- sent="Wed, 28 Feb 2001 21:55:26 -0500" -->
|
|
<!-- isosent="20010301025526" -->
|
|
<!-- name="Tom Martone" -->
|
|
<!-- email="tom@martoneconsulting.com" -->
|
|
<!-- subject="Re: Writing Fujitsu M3091 backend" -->
|
|
<!-- id="3A9DBA1E.175A3A40@martoneconsulting.com" -->
|
|
<!-- inreplyto="3A9D8542.4F65CEFC@objects.com.au" -->
|
|
<STRONG>From:</STRONG> Tom Martone (<A HREF="mailto:tom@martoneconsulting.com?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DBA1E.175A3A40@martoneconsulting.com>"><EM>tom@martoneconsulting.com</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Wed Feb 28 2001 - 18:55:26 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0263.html">abel deuring: "Re: xsane - kernel 2.4.2 - sym53c860"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0262.html">Mick Barry: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#264">[ date ]</A>
|
|
<A HREF="index.html#264">[ thread ]</A>
|
|
<A HREF="subject.html#264">[ subject ]</A>
|
|
<A HREF="author.html#264">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Greetings,
|
|
<BR>
|
|
<P>Mick Barry wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Would it be possible to back up just a little and explain how scanning
|
|
</EM><BR>
|
|
<EM>> multiple pages (currently) appears to a f/e?
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<P>I searched through some of the archives and found these two messages
|
|
<BR>
|
|
that pretty well describes the issues around multiple pages, batches,
|
|
<BR>
|
|
adfs and duplexes...
|
|
<BR>
|
|
<P>The other way to understand more completely would be to examine, xsane,
|
|
<BR>
|
|
scanadf, and the bh and umax backends.
|
|
<BR>
|
|
<P>(I would have put links to these, but the search server is down now
|
|
<BR>
|
|
and I don't know how else to do this other than insert it below)
|
|
<BR>
|
|
<P><P>Tom Martone
|
|
<BR>
|
|
<P><P><EM>>--------------------------------------------------------------
|
|
</EM><BR>
|
|
<EM>>Date: Mon, 09 Aug 1999 21:42:50 -0400
|
|
</EM><BR>
|
|
<EM>>From: Tom Martone <<A HREF="mailto:tom@martoneconsulting.com?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DBA1E.175A3A40@martoneconsulting.com>">tom@martoneconsulting.com</A>>
|
|
</EM><BR>
|
|
<EM>>To: sane mailing list <<A HREF="mailto:sane-devel@mostang.com?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DBA1E.175A3A40@martoneconsulting.com>">sane-devel@mostang.com</A>>
|
|
</EM><BR>
|
|
<EM>>Subject: Interpretation of the Standard
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>Greetings,
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>I'm working on a backend for Bell+Howell document scanners and a
|
|
</EM><BR>
|
|
<EM>>command line frontend suitable for batch scanning. These scanners
|
|
</EM><BR>
|
|
<EM>>are typically equipped with automatic document feeders and are not
|
|
</EM><BR>
|
|
<EM>>flatbed scanners. Some models are capable of duplex scanning. These
|
|
</EM><BR>
|
|
<EM>>have dual cameras which capture both sides of the paper as the paper
|
|
</EM><BR>
|
|
<EM>>travels through the scanner.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>In a scenario where 3 pages are loaded into the feeder, a "scan all
|
|
</EM><BR>
|
|
<EM>>pages in the feeder" operation is requested in duplex mode, one would
|
|
</EM><BR>
|
|
<EM>>expect to produce 6 images (3 fronts and 3 backs). The following
|
|
</EM><BR>
|
|
<EM>>sequence of calls are made. Elipses indicate many such calls and
|
|
</EM><BR>
|
|
<EM>>in the case of sane_read, the last call returns SANE_STATUS_EOF.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>[bh] sane_init called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_open called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_control_option called (option:0, action:0)...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_get_option_descriptor called (option:0)...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_start called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_get_parameters called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_read called...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_start called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_get_parameters called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_read called...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_start called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_get_parameters called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_read called...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_start called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_get_parameters called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_read called...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_start called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_get_parameters called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_read called...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_start called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_get_parameters called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_read called...
|
|
</EM><BR>
|
|
<EM>> [bh] sane_start called (returns SANE_STATUS_NO_DOCS)
|
|
</EM><BR>
|
|
<EM>> [bh] sane_cancel called
|
|
</EM><BR>
|
|
<EM>> [bh] sane_close called
|
|
</EM><BR>
|
|
<EM>>[bh] sane_exit called
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>I'd be interested in knowing whether you think that the call sequence
|
|
</EM><BR>
|
|
<EM>>above is following the standard, specifically the portion I've quoted
|
|
</EM><BR>
|
|
<EM>>below, from section 4.4 Code Flow.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> "Image data is collected by repeatedly calling sane_read().
|
|
</EM><BR>
|
|
<EM>> Eventually, this function will return an end-of-file status
|
|
</EM><BR>
|
|
<EM>> (SANE_STATUS_EOF). This indicates the end of the current frame.
|
|
</EM><BR>
|
|
<EM>> If the frontend expects additional frames (e.g., the individual channels
|
|
</EM><BR>
|
|
<EM>> in of a red/green/blue image or multiple images), it can call sane_start()
|
|
</EM><BR>
|
|
<EM>> again. Once all desired frames have been acquired, function sane_cancel()
|
|
</EM><BR>
|
|
<EM>> must be called. This operation can also be called at any other time to
|
|
</EM><BR>
|
|
<EM>> cancel a pending operation. Note that sane_cancel() must be called
|
|
</EM><BR>
|
|
<EM>> even if the last read operation returned SANE_STATUS_EOF."
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>I'd argue that a batch scanning front-end is expecting additional
|
|
</EM><BR>
|
|
<EM>>frames when it is attempting to empty the feeder and it need not
|
|
</EM><BR>
|
|
<EM>>call sane_cancel until it has detected an empty feeder (sane_start
|
|
</EM><BR>
|
|
<EM>>returning SANE_STATUS_NO_DOCS). In fact, I'd say that this judicious
|
|
</EM><BR>
|
|
<EM>>calling of sane_cancel is the only way that a front-end can "hint"
|
|
</EM><BR>
|
|
<EM>>to a back-end the duration of a "batch". This is important
|
|
</EM><BR>
|
|
<EM>>if one wants to take advantage of a high-performance batch mode that
|
|
</EM><BR>
|
|
<EM>>the Bell+Howell implements. In this mode, the scanner is free to
|
|
</EM><BR>
|
|
<EM>>be ahead of the host during a scan operation, buffering image data
|
|
</EM><BR>
|
|
<EM>>in its own memory. This batch mode needs to be started (I do it in
|
|
</EM><BR>
|
|
<EM>>the first start_scan call) and then aborted (I do it in the sane_cancel
|
|
</EM><BR>
|
|
<EM>>call).
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>If you are thinking that the code flow above is NOT following the
|
|
</EM><BR>
|
|
<EM>>standard, then consider the following:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>In duplex mode, the backend delivers the front image for first sane_start
|
|
</EM><BR>
|
|
<EM>>and the back image for the next sane_start. Up until this point only a
|
|
</EM><BR>
|
|
<EM>>single "real" START SCAN has been sent to the scanner, but there are
|
|
</EM><BR>
|
|
<EM>>two images available for the backend to read and transmit to the frontend.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>Also, if the frontend calls sane_cancel each time after sane_read returned
|
|
</EM><BR>
|
|
<EM>>SANE_STATUS_EOF, there would be no way for the backend to know whether
|
|
</EM><BR>
|
|
<EM>>the user wants the behavior above (normal) or whether they cancelled
|
|
</EM><BR>
|
|
<EM>>the operation after the first front page and have started a new scan
|
|
</EM><BR>
|
|
<EM>>(in which case scanning the front page of the next document would
|
|
</EM><BR>
|
|
<EM>>be the correct action for the backend).
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>Thanks,
|
|
</EM><BR>
|
|
<EM>>Tom Martone
|
|
</EM><BR>
|
|
<P><P><EM>>--------------------------------------------------------------
|
|
</EM><BR>
|
|
<EM>>Date: Tue, 17 Aug 1999 09:18:46 -0700
|
|
</EM><BR>
|
|
<EM>>From: David Mosberger-Tang <<A HREF="mailto:David.Mosberger@acm.org?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DBA1E.175A3A40@martoneconsulting.com>">David.Mosberger@acm.org</A>>
|
|
</EM><BR>
|
|
<EM>>To: <A HREF="mailto:sane-devel@mostang.com?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DBA1E.175A3A40@martoneconsulting.com>">sane-devel@mostang.com</A>
|
|
</EM><BR>
|
|
<EM>>Subject: Re: SANE frames
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>>>>>> On Mon, 16 Aug 1999 17:42:47 +0200, Oliver Rauch <<A HREF="mailto:oliver.rauch@Wolfsburg.DE?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DBA1E.175A3A40@martoneconsulting.com>">oliver.rauch@Wolfsburg.DE</A>> said:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Oliver> the sane standard defines of how much frames an image
|
|
</EM><BR>
|
|
<EM>> Oliver> consists. After the last frame - that means if the image is
|
|
</EM><BR>
|
|
<EM>> Oliver> transferred completly - the frontend has to call
|
|
</EM><BR>
|
|
<EM>> Oliver> sane_cancel.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>Actually, IIRC, our intent was indeed to allow the call sequence that
|
|
</EM><BR>
|
|
<EM>>Tom describes. Note that in 4.4 it says:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> "If the frontend expects additional frames (e.g., the individual channels
|
|
</EM><BR>
|
|
<EM>> in of a red/green/blue image or multiple images), it can call sane_start()
|
|
</EM><BR>
|
|
<EM>> ^^^^^^^^^^^^^^^^^^
|
|
</EM><BR>
|
|
<EM>> again."
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>Also, note that xcam does acquire multiple images without calling
|
|
</EM><BR>
|
|
<EM>>sane_cancel(). (It's an amusing exercise to test a scanner with xcam,
|
|
</EM><BR>
|
|
<EM>>actually ;-)
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>>In other words, the idea is to have sane_start() be called, and
|
|
</EM><BR>
|
|
<EM>>collect as many images as the frontend wants (which could in turn
|
|
</EM><BR>
|
|
<EM>>consist of multiple frames each as indicated by frame-type) and when
|
|
</EM><BR>
|
|
<EM>>the frontend is done, it should call sane_cancel(). Sometimes it's
|
|
</EM><BR>
|
|
<EM>>better to think of sane_cancel() as "sane_stop()" but that name would
|
|
</EM><BR>
|
|
<EM>>have had some misleading connotations as well, that's why we stuck
|
|
</EM><BR>
|
|
<EM>>with "cancel".
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> --david
|
|
</EM><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?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DBA1E.175A3A40@martoneconsulting.com>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0263.html">abel deuring: "Re: xsane - kernel 2.4.2 - sym53c860"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0262.html">Mick Barry: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#264">[ date ]</A>
|
|
<A HREF="index.html#264">[ thread ]</A>
|
|
<A HREF="subject.html#264">[ subject ]</A>
|
|
<A HREF="author.html#264">[ author ]</A>
|
|
</UL>
|
|
<!-- trailer="footer" -->
|
|
<HR NOSHADE>
|
|
<P>
|
|
<SMALL>
|
|
<EM>
|
|
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
|
: <EM>Wed Feb 28 2001 - 18:27:32 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|