Hello all,
My trip report from the TWAIN/SANE meeting is long overdue, so I won't
procrastinate any longer...
As you may know Mark McLaughlin and Jon Harju (both members of the
TWAIN board) met with me on July 21 in Ottawa to discuss the
possibility of a SANE based TWAIN interface for Unix. The meeting was
very friendly and we spent the first two hours or so explaining each
other some of the more subtle aspects and ideas of the respective API.
The interesting point that I got out of this meeting is that TWAIN and
SANE, while providing similar functionality, focus on opposite ends:
TWAIN makes it very easy for application developers to make use of a
scanner whereas SANE makes it very easy to write a device driver for a
scanner. Given this difference in focus, it's actually not
unreasonable to want to put TWAIN on top of SANE. Even if
TWAIN-on-SANE may not be preferrable for developers of new
applications, it would definitely ease portability issues as
independent software vendors such as Adobe could port some of their
applications to Linux much faster if there was a TWAIN interface on
Linux that worked similar to how TWAIN works on Windows.
Putting TWAIN on top of SANE is not easy, as there are some
fundamental issues: Linux (and certainly not UNIX, OS/2, and all the
other OSes SANE supports) has no standard user-interface, yet TWAIN
applications do expect that the TWAIN driver ("TWAIN source") can
handle the device dialog itself. One suggestion is to use HTML to
describe the user-interface. Personally, I don't think that's a very
attractive solution. After all, the main reason to embed the scanner
interface into an application is to make it integrate seamless. Now,
if the application happens to use, say, GTK and the scanner user
interface is presented via Netscape, then that's certainly not
seamless to the user (and it could be outright confusing). I
personally think we won't be able to find magic here---there will need
to be one GUI frontend for each major toolkit in use (Motif, GTK, Qt,
Win32 come to mind). If TWAIN-on-SANE is done properly, it should be
possible to "plug in" a different GUI frontend relatively easily
(perhaps not on the fly, but at least through simple recompilation).
There are some implications of putting TWAIN on SANE, which will
eventually require some extensions to SANE (though they shouldn't be
necessary for a prototype). I don't have a problem with these
extensions, because they're all things we were planning to address for
v2 of the standard anyhow:
o add many more well-known options (though well-known, most of them
would be optional)
o add support for other image types (jpg for example)
o colorspace support (I don't know what this would entail exactly)
o add support for callbacks (to support things like the "scan" button
found on many scanners)
Mark and Jon offered to start working on a prototype for
TWAIN-on-SANE. I offered them help with constructing a GUI builder
based on our existing GTK frontends (probably xsane).
Clearly, one area of weakness for SANE is that today there is no easy
way to seamlessly embed SANE-based scanner support into an
application. Perhaps a good way to fix this to convert one of the
existing graphical frontends into a embeddable component. Given that
the frontends are based on GTK+ already, I think the Bonobo component
model would be a natural fit. This would allow us to re-use the xsane
interface in many applications and without much effort.
Also, Mark and Jon said that the scanner vendors really like to be
able to customize the look of the scanner GUI. While this is at odds
with providing a unified user experience, I do think SANE could
provide a large amount of customization without completely sacrificing
the uniform interface. For starters, it would be nice to be able to
associate a custom-logo for each device (and/or vendor) (I thought
xsane already could do this, though it doesn't show with my HP
scanner). Slightly fancier would be to have a simple language that
would control how and where each SANE option gets laid out in the
device dialog. Of course, a driver vendor could also feel free to
implement a GUI from scratch if they want full customization, but that
would be a fair amount of work. I think some level of scriptability
would provide a very good tradeoff between custom look and a uniform
user experience.
So, in summary I'd say that we should support TWAIN-on-SANE as a means
to attract ISVs to SANE and perhaps to get more support/endorsement
from scanner manufacturers. At the same time, there are a few things
we can learn from TWAIN and use that to make SANE a better, more
comprehensive and easier to use standard.
Cheers,
--david
-- 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 : Mon Jul 31 2000 - 22:37:24 PDT