Herd Software Development
DaVinci Graphics Library
DaVinci Documentation

Leonardo: Problems with TWAIN implementations

The TWAIN-API

Unlike the APIs for printers, soundcards, video cards and so forth, the TWAIN API used for scanners was not specified by Microsoft.

During the introduction of Windows, Microsoft didn't react on the need for a scanner API fast enough. Scanner manufacturers saw the need of a uniform interface (API) between scanners and application programs. The TWAIN group is an alliance by scanner manufacturers and manufacturers of graphics programs who defined such an API interface. In addition to the API definition the TWAIN standard also included the source manager (SDM), as small DLL just used to connect the applications with the scanners as needed.

TWAIN driver as company know-how

Apparently the TWAIN participants were not interested in also sharing the knowledge on TWAIN driver development. The TWAIN group offers merely a data source that reads in data from a BMP file as example implementation and remarkably not even all the fundamentally marked as "necessary for all data sources" functions are working in that example.

Unlike genuine "Open Source"-Projects like Linux and GNU projects TWAIN drivers are usually not available with source code, so fixing the problems is not possible.

Implementation differences

So obviously many scanner manufacturers had to develop their device drivers from scratch themselves. On account of ambiguities of the API definition, and also because most application programs use only few features, many features are implemented differently or simply defective.

This unfortunately, concerns not only products very economical the drivers but also expensive special-purpose tools.

Basic features

Those features can be regarded as basic features, that are required by mass applications like Photoshop, Coreldraw and similar aplications. These applications open the data source and display the user interface dialog. They leave the setting of the parameters to the dialog of the scanner driver.

Unattended scanning

Compared to that, performing a scan process without use of the user interface of the TWAIN data source is a functionallity not used as often. Expiriences show that TWAIN data source drivers oftenly do not allow control of features by TWAIN that are well controllable by the user interface dialog even if there is a TWAIN API to do so.

Required Feature

This even applys to features which are defined as required features in the TWAIN API standard. The following cases became known to us up to now:

• When querying data by means of MSG_GET or MSG_GETCURRENT, some drivers do not always return the current values set by means of MSG_SET.
  
  
• The specification in different units (inches, pixel, centimeters) by means of ICAP_UNITS is ignored.
  
  
• The driver ignores the fraction in TW_FIX32 in the elements, calculates inaccurately.
  
  
• The native transfer mode marked as "Every Source must transfer this transfer Mode" is unsupported.
  
  
• In spite of the API feedback to availability of a function (Capability negotiation) and error-free execution of the setting process (MSG_SET), the function is not executed.

Alternative TWAIN drivers

There are independent vendors of TWAIN drivers selling their drivers independently from the Hardware.

Recommendations for the development of applications

• Use all features except the absolute baseling as "optional supplementary functions" selectable by the user as needed.
  
  
• Don't rely in the data source to do exactly what it has been told, for example it might send a color image in spite of you selected a black & white image. Attempt react on such cases by calls to ConvertDIB or StretchDIB.
  
  
• Do not rely on parameters retrieved by MSG_GET operations.

Þ example for unattended scanning

Þ function TWAINInitialize

Þ function TWAINAquireExt

Þ function TWAINSetResolution

Þ function TWAINSetRect

Þ function TWAINCallDS

Þ function TWAINIsDSMOpen