|
White Paper
|
|
| June 2000 | ||
| Expanding TWAIN's Portability to Include Unix |
||
|
In This White Paper: |
||
| Back to Top |
This document justifies the reasons for providing TWAIN on Unix
platforms, as well as addressing the fundamental technical changes needed to make
it happen. Where technical issues are discussed, enough background material is
supplied to make it clear for all readers. It is not necessary to be technically
familiar with either the TWAIN Specification or the SANE Standard, or with Microsoft
Windows, Macintosh or Unix systems (though this does not hurt). It is necessary to
have a passing knowledge of image capture and some common programming jargon.
|
|
| Back to Top |
TWAIN has existed since 1992. It is an application programming interface
(API) for image capture. It supports Apple Macintosh and all versions of Microsoft Windows.
It is most commonly used with paper scanners and digital cameras, although any source of
images is possible.
The TWAIN Working Group (TWG) is a consortium of companies who meet regularly to advance the standard. The TWAIN Working Group provides the TWAIN Specification (version 1.9 at this writing), a C language header file (for use by application and driver writers), and a set of binaries used to discover the presence of TWAIN drivers. A TWAIN driver (often called an [image] Source) is code written by a hardware vendor (scanner, digital camera, etc.), to support their particular device. For more information on TWAIN or the TWAIN Working Group, please refer to the following Web site: www.twain.org. "Linux is a free, Unix-like Operating System" (quoted from www.linux.com.). The growing popularity of Linux has led to a situation similar to what Macintosh and Windows users experienced in the early 90’s: application and image capture devices do not communicate together as well as is desired. The number of requests from the TWAIN user community for TWAIN on Linux has reached a point where the TWAIN Working Group feels obligated to address the issue. Our intention is to address Linux with a technical solution that should be sufficient to address any version of Unix. Unix is not without its own standards designed to address this issue. The most notable effort is SANE (Scanner Access Now Easy). SANE is an API that occupies the same design space as TWAIN, placed between an application and an image capture device. The most obvious technical difference between TWAIN and SANE is that TWAIN requires the support of a GUI, while SANE does not. The most obvious difference between TWAIN and SANE is that many more application and hardware vendors support TWAIN. The TWAIN Working Group is looking to create a working relationship with SANE. The idea is that SANE has the background and experience to support devices on Unix. TWAIN has the greater number of application developers. A "TWAIN on SANE" implementation would make Unix more accessible to developers writing applications that include image capture. It would not replace SANE, since TWAIN drivers would use SANE as their interface to the device. More details on this design will be discussed later in this document. For more information on SANE, please refer to the following Web site: www.mostang.com/sane. |
|
| Back to Top |
TWAIN is its current form has a small number of problems that make
it less than ideal for Unix. The purpose of this document is to address those issues
with a minimum number of changes to the Specification. This will also be done in such
a way that the benefits can be brought back to the Microsoft Windows and Apple Macintosh
platforms.
The TWAIN Working Group is dedicated to the backwards compatibility of TWAIN. As of this writing, any well designed application of any version of TWAIN since 1.5 can work with any well designed TWAIN driver of any version since 1.5. This will not be compromised. There are three perceived difficulties with TWAIN:
|
|
| Back to Top |
This section addresses the general implementation details for
expanding TWAIN’s portability to include Unix. Only enough information
is presented to prove the feasibility of each of the solutions. This section will
expand as more information is gathered, and the design is finalized.
|
|
| Back to Top | ||
| Back to Top |
4.1.0 Running TWAIN in a Separate Process The Source Manager is a shared library owned and maintained by the TWAIN Working Group. Its sole purpose is to help an application discover what TWAIN drivers are installed on the system. After that, it primarily serves as a pass-through layer. The current design is as follows. Note that all of the modules occupy the same space in memory, which means that a poorly written TWAIN driver is capable of crashing or hanging the application calling it.
The new design is as follows. It uses the Source Manager to isolate the TWAIN driver in its own process space. 
The Source Manager is very small code and will be Open Source, so it is safe to include it in the same address space as the application. The initial design will use shared memory, with a fallback to sockets if shared memory is not available. Note that the use of sockets creates the potential for TWAIN to run across the network. |
|
| Back to Top |
4.1.1 An Alternative to the Message Loop TWAIN requires an application to pass all of its windowing messages through the TWAIN driver (keystrokes, mouse movements, etc.). It also requires it to monitor any messages coming back from the TWAIN driver (ready to transfer images, cancel, ok, etc.).In the new design, the TWAIN driver will be running in its own process. Therefore, it is no longer necessary for an application to pass all messages to the driver. The agreed upon mechanism for knowing that this is happening will be to use the Group Mask. A TWAIN driver will indicate that it is capable of supporting this new mode by setting bits in its Group Mask. An application will indicate that it wishes to run in this mode by enabling bits in the Group Mask. The Source Manager will make sure that incompatible applications and TWAIN drivers are blind to each other. Since the message loop will be gone in this new mode, we require an alternate mechanism for monitoring messages coming from the TWAIN driver. The proposed mechanism is to use a single callback function that indicates the arrival of an out-of-band message. This callback will do nothing more than inform the application that the TWAIN driver needs attention. The proposed mechanism will be similar to the existing DAT_DEVICEEVENT operation. This operation is capable of queuing events in the TWAIN driver, so none are lost. The flow will be as follows: 
The arrival of an event at the Source Manager will increment an incidence counter. A successful query about the event will decrement the counter. The Source Manager will own the counter. The application will be responsible for reading messages from until the counter goes to zero (emptying the queue, in case more than one message is pending). |
|
| Back to Top |
It’s hard to imagine a stickier problem than the TWAIN GUI.
Its one undeniable advantage is that it allows an application writer to
quickly and generically write code that allows image capture from the maximum
number of devices. It also allows for the full feature set of the device to
be exposed, since most hardware vendors have a vested interest in providing
easy access to the features that differentiates their device from the devices
made by their competitors.
This strength is also the problem. There is no consistency in the device control dialogs created by vendors. For most users this is no problem, but for some this is very annoying. The solution is to allow the application writer to take on the burden of presenting the GUI to the user, relying on the programmatic interface to negotiate capability settings with the TWAIN driver. TWAIN has significantly expanded its programmatic interface to address this issue, but the amount of code that must be written by an application developer to take advantage of this is very significant. It remains a fact that most applications will be content to rely on the TWAIN driver’s GUI, because the amount of code required to manage this can be finished in a day or two. And, since TWAIN’s whole purpose is "Linking Images With Applications," the TWAIN Working Group must address this issue with Unix. Unix is very different from Microsoft Windows and Apple Macintosh in that it has no one standard interface; a number of GUI window managers are available, as well as the ability to run in console mode (essentially an old-style cursor addressable character-based terminal). A number of options have been considered:
At the base level, the driver vendor would be required to provide standard HTML pages that would run well on all systems (the worst case scenario would probably be running Lynx on a console). More complex features would be negotiable, such as the use of CSS and Java and other high-level browser features. In this way, it should be possible for a driver vendor to write a front-end interface that looks and operates in a professional manner on the maximum number of Unix systems. This is not being offered as an ideal solution; it is merely the best one available with the technologies at hand. TWAIN driver vendors will still be able to write directly to some specific GUI, such as X-Windows. The TWAIN Working Group cannot prevent this, but it will be made clear in the TWAIN Specification that the use of a browser is the only correct way to write a TWAIN driver. |
|
| Back to Top |
In addition to the technical changes outlined above, there
are a number of other tasks required to make TWAIN on Unix a reality.
|
|
| Back to Top |
SANE is an established standard for Unix. It has the benefit
of years of Open Source development work solving some of the more intractable
problems, such as hiding the differences in direct device control for SCSI
between the various flavors of Unix.
TWAIN does not intend to replace SANE. It is looking for a synergy between the two standards. By using SANE as its backend, TWAIN will avoid having to reinvent solutions to fundamental device communication problems. SANE will benefit from the TWAIN’s need to for a very rich capability command set. Both standards will benefit from the increased attention, which will hopefully lead to common USB and 1394 layers. This effort should lead to more device support on Unix as well as more and different kinds of imaging applications. Device vendors will be encouraged to support SANE and TWAIN, since doing so will maximize their application coverage. The TWAIN Working Group recognizes that on the surface this appears to be twice the amount of work for driver writers. This should not need to be the case. Consider the following breakdown of a standard TWAIN driver. 
If we add SANE, the picture changes to the following: 
The TWAIN Working Group will supply sample code to help with the Capability Pass-through mechanism. The effort involved for a driver developer is basically split between TWAIN and SANE, so the same basic amount of work should be required as if the developer was just writing a TWAIN driver. The best sample code is something that really compiles and runs, and which does enough useful work that a developer can leverage it as seed code. It must also not include so many additional features that a developer is required to remove large amounts of code, or has difficulty reading the code to understand the flow of commands or the theory of operation. The proposal is to write a generic TWAIN on SANE driver, one that follows the new architectural guidelines, and which can be used as the basis for new drivers. This driver would expose a small number of generic features, maximizing the number of existing SANE supported devices that would work with this TWAIN driver. The TWAIN Working Group would arrange for the creation and release of the first version of this code and then would rely on Open Source practices to correct and modify it. The most immediate benefit of this would be the existence of a working TWAIN driver. As mentioned previously, this solves an essential chicken-and-egg problem. We want application writers to know that there is a working driver waiting for them to integrate into their solutions. Application writers who want to access TWAIN programmatically will have the initial advantage, since the generic TWAIN on SANE driver will not offer as robust a feature set as the programmatic controls. In anticipation of this there will need to be an assessment of the SANE programmatic feature set, followed by proposals to the SANE group for the addition of new features. There will also need to be initiatives to get device vendors to consider writing TWAIN on SANE drivers so that the GUI issues can be addressed as quickly as possible. |
|
| Back to Top |
On the application side, the differences between TWAIN on Unix and
traditional TWAIN on Microsoft Windows and Apple Macintosh should be very minimal.
This is desirable, since one of the goals is to leverage off the years of expertise
developers have in writing image capture applications that use TWAIN.
To expose the few necessary differences the TWAIN Working Group will arrange for the creation and release of a new version of the Twacker program. This program has been supported on Microsoft Windows for years now, and is suitable as seed code for anyone writing a TWAIN enabled application. A new version will be written for Unix. Once released the TWAIN Working Group will rely on Open Source practices to correct and modify it. As a secondary goal it is proposed that the new Twacker program be designed to be portable across all three platforms: Unix, Microsoft Windows, Apple Macintosh. If this is done it will be necessary to preserve the old Twacker code (to show legacy behavior), so a new name will be needed for this program. This new program will also using HTML based dialogs, and will not necessarily be as complete as Twacker in its first version. |
|
| Back to Top |
Of the three platforms only Microsoft Windows currently offers
professional testing tools for validating the correctness of TWAIN drivers and
applications. The TWAIN Working Group is investigating ways to grant access to tools
on the Apple Macintosh platform. If this investigation is successful the TWAIN Working
Group will pursue the same effort for Unix. The TWAIN Working Group knows that good testing
methodologies are a critical part of driver and application development. As the group
learns more about this issue it will share its findings with the general community.
|