You seem to have a sufficient insight of both TWAIN and SANE.
You don't happen to be interested to code something ? :-)
> > > If I read correctly Andy stated that it is possible to have
> > > something like a TWAIN backend for SANE.
> > No. To my knowledge, this is not possible.
> This IS possible, but only for TWAIN sources which comply with some of
> the most recent additions to the TWAIN standards (in relative terms,
> the original TWAIN is now quite old). In particular when I asked about
> this I was told that few if any mass-market scanners have the necessary
> TWAIN features to do SANE-on-TWAIN. Such "high-end" features are
> unfortunately optional :(
Uh - yes. I should have stated that more clearly. The point you make came up
on the ML here in the past. However as you say, it's probably not worth the
bother to implement it, as the number of working sources for the system
would be very limited.
> However, the other way around TWAIN-on-SANE would be comparatively easy
> to do, and would work with every existing SANE backend, though not
> necessarily to maximum advantage.
Yes. What is your opinion about that ?
I would suggest to add an exported API to the existing SANE frontends, like
a common commandline option that will make it connect to some pipe or
something. That allows to use any backend as the hardware driver, and any
frontend (the exports the "remote control" interface) as the GUI driver.
The TWAIN library itself could then work similar to what the GIMP does.
It would look up the command to run in its configuration files and then
call e.g. "xscanimage -twain" (like gimp does with -g) and talk to it.
The other, less flexible but somewhat simpler possibility would be to
make a single custom TWAIN frontend.
CU, Andy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com