Greetings,
> It does make a difference I think. If the front-end is expected to do
> something automatically - even if it's just saving the images with
> proper names - it would be good to know whether a certain image is
> "another image derived from the same sheet of paper" or "a new image
> derived from a new sheet of paper". You would probably want to assign
> different file names.
>
> Of course it can be "guessed" - if the front-end knows that duplex
> mode is on, every other image that the scanner delivers will probably
> be a back side - but that's not exactly cool. For example I've been
> looking at the Bell+Howell driver and saw that these scanners may
> produce a multitude of images from one page - things like "front
> thumbnail", "front barcode", whatever.
I agree that it's not exactly cool. The practical way of dealing with
it in the Bell+Howell case is that the front-end is in control of
requesting which set of possible images can be generated from a sheet
of paper, and the driver delivers them in a predictable, documented
order. So a front-end program can reliably know which image is it
working on at any time.
> So, in "some future version" of SANE, there ought to be a mechanism by
> which the backend can inform the front-end of the intrinsic relation-
> ships between images it delivers.
Agreed. For now, non-standard, xml-encoded text frames work like a charm.
By the way, scanadf can scan only some of the documents in the hopper by
using the --start-count and --end-count options. I think xsane has similar
capabilities. But in my version of "real-life" these options are never
used. The users control how many pages to scan by the size of the stack
of sheets that they place in the hopper.
Tom
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Thu Mar 01 2001 - 17:52:32 PST