Subject: White Paper
Date: Tue, 17 Mar 92 15:52:12 MST


TWAIN 
Linking applications and images

 
The Issue
^^^^^^^^^
In desktop publishing's early days, most publications contained only text 
and simple black-and-white line drawings that were output to black-and-white
laser printers. In recent years, however, computer hardware and software 
has become much more sophisticated. Both business professionals and graphic 
artists can now create and output complex, full-color publications. This 
near-commercial-quality work may include black-and-white, greyscale, and 
color images acquired from desktop and hand-held scanners, or from still 
video, digital cameras or image capture boards. This growth in technology 
means vendors are faced with a challenge: to supply customers with hardware 
and software products that enhance productivity by working together 
seamlessly for an efficient, easy-to-use computing process. Unfortunately, 
image acquisition remains a difficult process. To acquire and place an 
image in your publication, you must leave the application in which you are 
working. Then you must locate and open a hardware driver, set the device 
options, acquire the image, save it to disk, close the hardware driver, 
return to the application, then locate and read in the image file from 
disk. The process is time-consuming and tedious, and not how business 
professionals, designers, or publishers want to work, particularly with 
the increasing need for on-demand integration of images acquired in real 
time. 


The Solution
^^^^^^^^^^^^
When the image-acquisition issue surfaced, hardware and software 
developers began defining their own image acquisition interfaces. This 
was a step in the right direction, but it soon became apparent that high 
numbers of proprietary interfaces were not the ultimate solution. It's 
inefficient to require a software developer to write a driver for each 
device they need to support. Conversely, it doesn't make sense to ask a 
hardware vendor to write a different driver to interface with each 
software application. Most importantly, it isn't acceptable that users 
must deal with many unique application/device driver files. 

Users need a painless way to get image data into their applications. 
Software developers need compatibility with the widest range of output 
devices without writing and maintaining multiple device drivers. 
Hardware developers need compatibility with the greatest number of 
applications without application-dependent coding.

The most obvious solution to this situation is an open industry 
interface that directly acquires image data from external sources while 
within an application. In this scenario, each software developer 
supports a standard data acquisition manager and each hardware vendor 
writes one driver for their device. Hardware vendors will benefit 
because they need only provide one standard driver for their device, 
which can then be used by all software applications supporting the 
standard data acquisition interface. Software vendors will be freed 
from writing and supporting device drivers, or from soliciting support 
for their own proprietary interface. Software vendors will also benefit 
because one single interface will support those vendors writing these 
device drivers. Users will benefit because they can place a smaller set 
of drivers at the operating system level and take advantage of seamless 
images acquisition from a large number of applications. 
 
History and structure of the TWAIN consortium
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In early 1990, the formation of the Macintosh Scanner Roundtable group 
heightened the imaging industry's awareness of the need for an open 
interface. While participation in the roundtable was high, it was 
difficult to resolve issues and progress was slow. At one of the group's 
last meetings in 1990, it was suggested that a smaller set of industry 
leaders form a consortium and create a specification for review, 
revision, and ultimate adoption by the imaging industry. 

The TWAIN Working Group was formed with representatives from Aldus, 
Caere, Eastman Kodak, Hewlett-Packard, and Logitech. The Working Group's 
primary goal was defined as promoting imaging product use by developing 
an integrated easy-to-use image acquisition interface and educating 
users about its existence. A key requirement of participation was that 
members be willing to represent a broader interest than that of their 
own company. The number of participants was kept low so the 
specification could be written quickly, while representation from a 
wide spectrum of application developers (desktop communications and 
OCR) and hardware vendors (hand-held, desktop, and high-end color 
imaging devices) was maintained. The result was that working group 
members represent diversity in the industry, and bring in-depth imaging 
experience to both hardware and software development, and marketing 
fields. 

At the TWAIN Working Group's first meetings, engineers faced the huge 
task of reviewing specifications and resolving outstanding requirements 
issues. Most Working Group companies had written their own interface for 
direct image acquisition, and these were considered, as well as more 
than two dozen specifications provided by other companies. No single 
specification or protocol, including those from operating system 
vendors, provided the completeness, richness of functionality, and ease 
of implementation that was required. Eventually, a composite of Silicon 
Beach/Adobe Plug-ins, an internal Aldus protocol, an HP protocol under 
development and Logitech's SAPI was used as the basis for TWAIN.

TWAIN Working Group engineers participated in monthly workshops to 
define the specification. A separate Marketing Working Group meets to 
discuss publishing a toolkit, supporting the interface, and other issues, 
including how to inform the industry and public about the interface. 

Besides the TWAIN Working Group, more than 175 major imaging hardware 
and software companies form a group called the "TWAIN Coalition." This 
larger group reviewed the TWAIN specification and provided feedback prior 
to its release. The TWAIN Working Group took comments and suggestions 
from the TWAIN Coalition, examined the costs and benefits of the 
modifications, and decided which to incorporate into the specification. 
Some Coalition members have completed a review of the specification and 
endorse it as being technically sound and beneficial for the industry; 
they are identified on an endorser's list available from any Working Group 
contact. The specification is now nearing completion, and applications 
and sources supporting TWAIN will soon be available.

Goals of the TWAIN Specification
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TWAIN was designed to provide a consistent, easy integration of image 
data between sophisticated input devices and software applications. More 
detailed Working Group goals for the specification included: 

o Multiple platform support - The interface must work on the Macintosh 
  and under Windows, but should also have the ability to extend to UNIX, 
  OS/2 and other platforms. Use of platform-specific mechanisms should be 
  kept to a minimum.
o Support for multiple devices - These include hand-held scanners, 
  flatbed scanners, slide scanners, image capture boards or frame grabbers, 
  digital cameras and image databases-a broad range of raster image-
  generating devices.
o Widespread acceptance - Provide an interface that is well-defined and 
  enables the majority of the leading hardware and software developers to 
  provide drivers for their devices or include support through their 
  applications.
o Extensibility and revisability - As the industry grows, the 
  specification's architecture should be extensible and able to handle 
  new, unknown conditions. Revisions will be backwards-compatible with 
  code written to earlier versions of the specification.
o Easy implementation - The interface and its documentation should be 
  clear, well structured, well written, and intuitively designed for 
  developers to learn and write the code for it.
o Longevity - While the aim is to provide a solution as quickly as 
  possible, the Working Group is doing all it can to make sure the 
  interface is structurally sound and encompasses all functionality 
  necessary to provide a single solution for the industry that will last 
  for several years, or until such time as a facility like this might be 
  supported at the operating system level. It is a goal of the Working 
  Group that this functionality be incorporated at the operating system 
  level and be TWAIN compatible. 
o Multidata Capacity - This general data interchange mechanism must be 
  able to transmit data in existing standard formats and native file 
  formats such as TIFF, PICT, and DIB. Furthermore, TWAIN was designed to 
  easily support data type extensions outside the realm of images (such 
  as text, facsimile data and vector graphics.) 

Architecture         
^^^^^^^^^^^^
TWAIN provides a simple, yet rich, methodology for universally connecting 
TWAIN-compliant applications with TWAIN-aware devices. The model for how 
applications interact with the source of input data can be described 
through a four-layer protocol: the Application Layer, Protocol Layer, 
Acquisition Layer and Device Layer.  The acquisition components correspond 
to these layers and include the application, Source Manager, Source and 
physical hardware device.  The application communicates through the Source 
Manager to a Source driver which represents the physical hardware device 
that generates image data. 

The hardware interface element of the TWAIN architecture is the Source. 
A Source is a TWAIN entity whose purpose is to get data from a hardware 
device and provide it to a TWAIN-compliant application. A Source is 
typically written by the hardware vendor to control their peripheral 
device.   These devices are usually a physical piece of hardware, such as 
a scanner, although a virtual device (such as an image database) also fits 
the Source model. The device may be locally connected or remotely accessed 
over a network.

The core element of this architecture is the Source Manager (SM). The 
SM's primary role is to establish and manage the connections between the 
application and the sources. The SM allows the user to select the desired 
source, loads and unloads the selected source, and makes sure that all 
calls from a particular application are correctly routed to the 
appropriate source. The SM is implemented as a code resource on the 
Macintosh and a Dynamically Linked Library (DLL) under Microsoft Windows. 
Under Windows, there will be only one copy of the SM active in memory at 
any given time. On the Mac, there will be a separate copy of the SM for 
each application accessing it. When the application needs to communicate 
with a Source, it calls the SM with a correctly addressed message. An 
application never calls a Source directly.

Let's review how to acquire an image with TWAIN: From the application, 
the user first chooses "Select Source" from the menu. "Select Source" 
identifies the source device from which the image will be acquired, and 
is only accessed by the user when it's necessary to switch between 
multiple connected devices. "Select Source" invokes the Source Manager 
and a selection dialog box appears. Once the source is selected, the 
user choses "Acquire" to initiate the image acquisition process. 
"Acquire" brings up the Source Manager to facilitate a process called 
"capabilities negotiation." This takes place between the application 
sending messages (describing the data it wants) and the Source (defining 
the data it can provide). When negotiation is complete, all user 
interface control is passed to the Source. The Source's user interface 
allows the user to set scanning options and start the scan. The Source 
passes the image data back through the Source Manager to the Application, 
which allows the user to place the image in their document if they 
haven't already specified its destination.

TWAIN implementation allows a high degree of flexibility. Application 
developers can choose from four different levels of support, which 
increase in complexity. They include Glue Code, Basic, Advanced, or 
Custom Support. Source developers can decide among three support 
options: Basic, Advanced, or Custom. These options give developers the 
ability to either support TWAIN with minimal engineering investment, or 
to use TWAIN for greater differentiation through their user interfaces 
and more complete access to all their product's capabilities.

How you can become involved
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Developers: In the U.S or Canada, call 1-800-722-0379 to order the TWAIN 
Toolkit.  Outside U.S. or Canada, call (206) 628-5737 from your fax 
machine and fax yourself document number 9154, the TWAIN Toolkit order 
form.  The toolkit will contain the TWAIN specification, Source Manager, 
a header file, code for a sample application and Source, as well as a 
marketing guide. Developer support will be available from all Working 
Group companies.

Users: Look for the TWAIN logo or name on any hardware or software you 
purchase. Ask product vendors when they will be supporting TWAIN. Refer 
developers to any TWAIN Working Group member listed below if they are 
not yet aware of this interface. Let Working Group companies know how you 
work with TWAIN, especially if you have ideas on how the interface can be 
improved or extended to better meet your needs and the way you work.


TWAIN Working Group Contacts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Aldus           - Developers Desk (206) 628-6593
  Caere           - Fax Support (408) 354-2743
  Eastman Kodak   - Support Line (716) 724-1682
  Hewlett-Packard - TWAIN Support (303) 350-4830
  Logitech        - TWAIN Developer Support (510) 713-5DEV 


A note on our name 
^^^^^^^^^^^^^^^^^^
Some of you may have been introduced to the TWAIN interface under the 
names "Direct-Connect" or "CLASP." While this effort has been promoted 
under these names in the past, trademark searches turned up too many 
conflicts for us to feel comfortable using either of these as the final 
name. After numerous searches, we selected the name TWAIN to describe 
this interface which brings together two entities, applications and 
input devices, in a meeting of the "TWAIN." 

/* end document */