kopia lustrzana https://gitlab.com/sane-project/website
416 wiersze
14 KiB
HTML
416 wiersze
14 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="Mick Barry (mick@objects.com.au)">
|
|
<META NAME="Subject" CONTENT="Re: Writing Fujitsu M3091 backend">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: Writing Fujitsu M3091 backend</H1>
|
|
<!-- received="Thu Mar 1 00:45:04 2001" -->
|
|
<!-- isoreceived="20010301084504" -->
|
|
<!-- sent="Thu, 01 Mar 2001 17:27:41 +1100" -->
|
|
<!-- isosent="20010301062741" -->
|
|
<!-- name="Mick Barry" -->
|
|
<!-- email="mick@objects.com.au" -->
|
|
<!-- subject="Re: Writing Fujitsu M3091 backend" -->
|
|
<!-- id="3A9DEBDD.F583888F@objects.com.au" -->
|
|
<!-- inreplyto="3A9DBA1E.175A3A40@martoneconsulting.com" -->
|
|
<STRONG>From:</STRONG> Mick Barry (<A HREF="mailto:mick@objects.com.au?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DEBDD.F583888F@objects.com.au>"><EM>mick@objects.com.au</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Wed Feb 28 2001 - 22:27:41 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0001.html">mh: "QuiteInsane-0.1-alpha-2 released"</A>
|
|
<UL>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0003.html">mh: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0003.html">mh: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0007.html">Oliver Rauch: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#0">[ date ]</A>
|
|
<A HREF="index.html#0">[ thread ]</A>
|
|
<A HREF="subject.html#0">[ subject ]</A>
|
|
<A HREF="author.html#0">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Tom,
|
|
<BR>
|
|
<P>Thanks muchly for this.
|
|
<BR>
|
|
<P>I'm still unclear on how a f/e knows that there is new image, and not
|
|
<BR>
|
|
just a new frame for the current image. Is it implied by what frames
|
|
<BR>
|
|
have been recieved.
|
|
<BR>
|
|
So if we looked at just the getparameter replies is the following how it
|
|
<BR>
|
|
is intended to work:
|
|
<BR>
|
|
<P>GetParameters (format=Red, LastFrame=false)
|
|
<BR>
|
|
GetParameters (format=Green, LastFrame=false)
|
|
<BR>
|
|
GetParameters (format=Blue, LastFrame=false)
|
|
<BR>
|
|
// Implies a new image cause we've already read r, g & b
|
|
<BR>
|
|
GetParameters (format=Grey, LastFrame=false)
|
|
<BR>
|
|
// Implies a new image cause we've read grey image which only has simple
|
|
<BR>
|
|
frame
|
|
<BR>
|
|
GetParameters (format=RGB, LastFrame=false)
|
|
<BR>
|
|
// Implies a new image cause we've read rgb image which only has simple
|
|
<BR>
|
|
frame
|
|
<BR>
|
|
...
|
|
<BR>
|
|
<P>mick
|
|
<BR>
|
|
<P>Tom Martone wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Greetings,
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Mick Barry wrote:
|
|
</EM><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>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I searched through some of the archives and found these two messages
|
|
</EM><BR>
|
|
<EM>> that pretty well describes the issues around multiple pages, batches,
|
|
</EM><BR>
|
|
<EM>> adfs and duplexes...
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> The other way to understand more completely would be to examine, xsane,
|
|
</EM><BR>
|
|
<EM>> scanadf, and the bh and umax backends.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> (I would have put links to these, but the search server is down now
|
|
</EM><BR>
|
|
<EM>> and I don't know how else to do this other than insert it below)
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Tom Martone
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<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=<3A9DEBDD.F583888F@objects.com.au>">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=<3A9DEBDD.F583888F@objects.com.au>">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>
|
|
<EM>>
|
|
</EM><BR>
|
|
<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=<3A9DEBDD.F583888F@objects.com.au>">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=<3A9DEBDD.F583888F@objects.com.au>">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=<3A9DEBDD.F583888F@objects.com.au>">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>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> --
|
|
</EM><BR>
|
|
<EM>> Source code, list archive, and docs: <A HREF="http://www.mostang.com/sane/">http://www.mostang.com/sane/</A>
|
|
</EM><BR>
|
|
<EM>> To unsubscribe: echo unsubscribe sane-devel | mail <A HREF="mailto:majordomo@mostang.com?Subject=Re:%20Writing%20Fujitsu%20M3091%20backend&In-Reply-To=<3A9DEBDD.F583888F@objects.com.au>">majordomo@mostang.com</A>
|
|
</EM><BR>
|
|
<P><P><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=<3A9DEBDD.F583888F@objects.com.au>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0001.html">mh: "QuiteInsane-0.1-alpha-2 released"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0003.html">mh: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0003.html">mh: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0007.html">Oliver Rauch: "Re: Writing Fujitsu M3091 backend"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#0">[ date ]</A>
|
|
<A HREF="index.html#0">[ thread ]</A>
|
|
<A HREF="subject.html#0">[ subject ]</A>
|
|
<A HREF="author.html#0">[ 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>Thu Mar 01 2001 - 00:47:20 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|