> My name is Mark McLaughlin, and I am the current Chairperson
> on the TWAIN Working Group Technical Sub-committee. I am
> sending this message to the manager for the SANE website in
> the hope that it will reach the appropriate people.
I think it did. Thank you for contacting us.
> There is growing interest (as viewed on our mailing list) for
> seeing TWAIN support on UNIX platforms, particularly on Linux.
> This interest has finally reached a level where the TWAIN
> Working Group feels it needs to investigate the possibility of
> adding support for UNIX.
This is good news. The original reason for the development of SANE was the
lack of commercial drivers for the various Unix platforms we cover.
If TWAIN would start an effort in this direction, this would mean setting a
signal towards the manufacturers, that this is an interesting market worth
developing drivers for.
> We are interested in this because we believe there is an
> opportunity to help developers of image capture systems
> on UNIX, WIN32 and Macintosh platforms leverage their
> code run on one or more or the alternate platforms.
Yes. The variety of platforms on which SANE runs shows, that it is possible
to easily write code that is portable across platforms, if you have a decent
abstraction layer towards the hardware and towards the frontend (windowing
system).
> TWAIN has no intention of competing with SANE. Rather we
> wish to investigate a chance to employ the strengths of both
> standards. We are not against the idea of seeing SANE
> running on WIN32 or Macintosh platforms, and if there are
> ways we can help SANE achieve this we would be happy to
> discuss them. It is important that both groups benefit from any
> interaction.
Yes. I in deed see quite some possibilities for interaction ...
The advantages/disatvantages of Twain vs. SANE look to me like this:
[please correct me on the Twain part, I am sure I am wrong in some places,
as my knowledge is second hand on that.]
SANE TWAIN
separation of HW-driver (backend) usually monolithic driver
and user interface (frontend)
network transparent operation using normally not network transparent
a special front- and backend
User has choice of frontend only single frontend per driver
portable across many platforms only Windows and MacOS
API-internal hardware abstraction ?
layers.
only three well known frontends lots of colorful (though often
scanner-tied) frontends
not very widespread widespread, well known API
small driver base complete driver base.
no existing ability to process can transmit compressed data
precompressed data.
I think the best idea would be to take the good ideas from both standards
and try to merge them in a way that ensures maximum interoperability.
To achieve this I propose to:
1. Enhance the functionality of the WinSANE package, which is trying to
provide a SANE->Twain bridge in the sense, that it accesses a network-
exported SANE device and presents it to the system as a TWAIN source.
Using the cygwin tools and some minor hacking, this should allow SANE
drivers to work on the Windows platform. I assume a similar solution could
be worked out for the Mac.
2. If my information is right, and a TWAIN driver does contain both the
hardware driver and the GUI representation in one driver without a well
defined interface between them, I propose that we work together on such an
interface. I think SANE has shown a well working model (which can probably
take a few enhancements), which could serve as a base.
If we manage to assimilate our "intrafaces" that connect the HW driver to
the GUI, we are pretty much set to mutually combine front- and backend
drivers from both worlds, eventually using trivial glue layers, where things
differ.
I do see, that for most manufacturers there will not be a feel for needing
to support multiple frontends for one single scanner. However I think it
will both make writing drivers easier (as you can use a maybe not-so-pretty,
but universal existing frontend while designing the backend, and then write
the customized frontend), and allow for more flexibility for the user.
Please do not take this personally, but I have seen a lot of TWAIN
frontends, that are .. well very colorful, but pretty unuseable.
While it might please some casual users to have the GUI designed like a
car cockpit or a pinball game, it severely annoys me, when I have to wait
for the bubble help over each button to pop up, as the only symbols you
can guess what they are for are the brightness and contrast levers.
For professional users that are interested in quick results rather than
nifty look, a simple GUI is often more desireable.
So I think the way to go would be to first make sure TWAIN gets an interface
between frontend and backend, and we should as well define interfaces to
well known transport layers like SCSI, parallel port, USB and serial port.
This is what will make the drivers easily portable to Unixes. The main
difference between OSes usually are the HAL and the GUI. The split driver
model and the abovementioned interface-layers make sure that they are of no
concern for the drivers themselves.
Hardware driver layers for all OSes in questions need to be written, but
that should be a minor effort.
Frontend are GUI specific, so we expect the manufacturers to generally
continue to only provide customized frontends for their main market only.
However, as the above sketched scheme allows for arbitrary frontends, it
will suffice to have backends available for all platforms, as the
non-mainstream platforms can make use of generic frontends.
3. While doing so enhance SANE with some lacking properties that can be done
with TWAIN (like compressed data transfer).
Comments, suggestions, questions, ... welcome.
CU, ANdy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = ======== GGI - The Right Thing To Do : http://www.ggi-project.org/ ========
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com