The great TWAIN journey

Over the past decade, TWAIN has established itself as an important standard in the desktop publishing industry. This white paper...

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 Consortium

In 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 information

As 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 Specification

TWAIN 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 capacity

The 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.


TWAIN 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 revisions

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.

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

This was last published in July 1999



Enjoy the benefits of CW+ membership, learn more and join.

Read more on Operating systems software

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.




  • Passive Python Network Mapping

    In this excerpt from chapter two of Passive Python Network Mapping, author Chet Hosmer discusses securing your devices against ...

  • Protecting Patient Information

    In this excerpt from chapter two of Protecting Patient Information, author Paul Cerrato discusses the consequences of data ...

  • Mobile Security and Privacy

    In this excerpt from chapter 11 of Mobile Security and Privacy, authors Raymond Choo and Man Ho Au discuss privacy and anonymity ...