Over the past decade, TWAIN has established itself as an important
standard in the desktop publishing industry. This white paper
details its history, specification and future.
TWAIN defines a standard software protocol and
application-programming interface for communication between
software applications and image acquisition devices. In the early
days of desktop publishing, most publications contained only text
plus simple black and white line drawings that were output to black
and white laser printers. In recent years, however, business
professionals and graphic artists have been able to create and
output complex, full-colour publications. This near-commercial
quality work may include black and white, greyscale and colour
images acquired from desktop and handheld scanners, or from still
video, digital cameras or image capture boards.
Image acquisition was always a difficult process. To acquire and
place an image in a publication, users had to leave the application
in which you were working. Then they had to locate and open a
hardware driver, set the device options, acquire the image, save it
to disk, close the hardware driver and return to the application.
Next, the image file had to be located and read in from the disk.
The process was time-consuming, tedious and not the way business
professionals, designers or publishers wanted to work, particularly
with the ever-increasing need for on-demand integration of images
acquired in real-time.When the image acquisition issue surfaced,
hardware and software developers began defining their 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 was inefficient to require
software developers to write a driver for each device they need to
support. Conversely, it did not make sense to ask hardware vendors
to write a different driver to interface with each software
application. Most importantly, from the user perspective, it was
unacceptable to deal with many unique application/device driver
files.What was needed was a painless way to get image data into
applications. Software developers needed compatibility with the
widest range of output devices without having to write and maintain
multiple device drivers. Hardware developers needed compatibility
with the greatest number of applications without
application-dependent coding.The solution was an open industry
interface that directly acquires image data from external sources
while within an application. Each hardware vendor writes one driver
for the device, which can 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.
Another benefit is that one single interface will support 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.
Forming the TWAIN ConsortiumIn early 1990,
the formation of the Macintosh Scanner Roundtable group heightened
awareness in the imaging industry of the need for an open
interface. But it proved difficult to resolve issues and progress
was slow. At one of the group's last meetings later that year, 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 result, the TWAIN
Working Group, was formed with representatives from Aldus, Caere,
Eastman Kodak, Hewlett-Packard and Logitech. The group's primary
goal was to promote imaging products through developing an easily
used image acquisition interface and educating users about it. A
key requirement of participation was that members were willing to
represent a broader interest than that of their own company. The
number of participants was kept low so that the specification could
be written quickly, while representation from a wide spectrum of
application developers (desktop communications and OCR) and
hardware vendors (handheld, desktop and high-end colour imaging
devices) was maintained. The result was that working group members
represented diversity in the industry, bringing in-depth imaging
experience to both hardware and software development, and marketing
fields.At the working group's first meetings, engineers faced the
huge task of reviewing specifications and resolving outstanding
requirement issues. Most working group companies had written their
own interface for direct image acquisition and these were
considered along with more than two dozen specifications provided
by other companies. No single specification or protocol ( including
those from operating system vendors ( provided the 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.Working group
engineers participated in monthly workshops to define the
specification. A separate marketing working group met to discuss
how to publish a toolkit, support the interface, plus 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 specification and provided feedback before its
release. The working group took comments and suggestions from the
coalition, examined the costs and benefits of the modifications,
and decided which to incorporate into the specification. The
specification is now in its third revision.
Consortium and
coalition informationAs of 1995, the TWAIN Working Group is
composed of four companies: Hewlett-Packard, Logitech, Documagix
and Canon. These companies continue to update and modify the
specification regularly, set the direction for future TWAIN
development and implement additions to the TWAIN Data Source
Manager and tools. In addition, the group provides the core answers
to questions from the TWAIN community.
Goals of the TWAIN
SpecificationTWAIN was designed to provide a consistent, easy
integration of image data between sophisticated input devices and
software applications. The interface must work across many
operating systems and use of platform-specific mechanisms should be
kept to a minimum.Supported devices include handheld scanners,
flatbed scanners, slide scanners, image capture boards or frame
grabbers, digital cameras and image databases ( a broad range of
raster image generating devices. The interface should be well
defined and enables the majority of leading hardware and software
developers to provide drivers for their devices or include support
through their applications and promote acceptance of
TWAIN.
Multi-data capacityThe 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 support data type extensions
outside the realm of images, such as text, facsimile data and
vector graphics.
ArchitectureTWAIN provides a simple
methodology for universally connecting TWAIN-compliant applications
with TWAIN-aware devices. The model for the interaction of
applications 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 take
data from a hardware device and provide it to a TWAIN-compliant
application. A source is typically written by the hardware vendor
to control a peripheral device. Such a device is usually a 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
connected locally or accessed remotely over a network.The central
element of this architecture is the source manager (SM), whose
primary role is to establish and manage 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.To acquire an image using the TWAIN
protocol, users choose Select Source from the Application menu.
This identifies the source device from which the image will be
acquired and is only accessed when it is necessary to switch
between connected devices. It also invokes the source manager,
bringing up a selection dialogue box. Once the source is selected,
choose Acquire to initiate the image acquisition process, which
brings up the source manager to facilitate a process called
capabilities negotiation. The process takes place between the
sending messages application (describing the data it wants) and the
source (defining the data it can provide). When negotiation is
complete, control is passed to the source. The source's user
interface allows you to set scanning options and start the scan, or
the user interface can be suppressed, leaving whatever has been
previously negotiated as the settings.
Extensibility and
revisionsAs 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.While the aim was
to provide a solution as quickly as possible, the standard was
designed to last for several years, or until such time as this type
of facility could be supported at the operating system level. It is
a goal of the working group that this functionality is incorporated
at the operating system level and is TWAIN-compatible.
The full
text of this white paper can be found at Hewlett-Packard's website.
Compiled by Richard Pitt