 |
|||||||
 |
|
|
|||||
|
|
|
|
|||||||||
|
|
|
| Copyright (c) 2019 DynaRithmic Software. All rights reserved. |
You are a programmer, and you want to implement image retrieval using a scanner or digital camera in your Microsoft Windows applications. How do you get the scanner or digital camera to work in the application?
If you have bought a scanner, and the manufacturer specifications states that the scanner (or digital camera) comes with a TWAIN driver (also called the Source or data source), your application needs to implement TWAIN calls so that there is an interface with the TWAIN source. You can do this by getting the TWAIN specification documentation, reading through it, implementing it, and then getting the scanning or image retrieval to work. This sounds simple, but many factors come into play when attempting to implement TWAIN.
In general, TWAIN is a protocol and Application Programming Interface (API) that standardizes communication between an application and image acquisition devices such as scanners and digital cameras. This standard allows a developer to make standard calls to any image acquisition device that supports TWAIN. Thus the application would not have to be rewritten to support every device. TWAIN has been in existence since 1992 and is governed by the TWAIN Working Group. Even though it is a mature API, it still has many hurdles to overcome when an application is attempting to communicate with a TWAIN device and has some flaws as specified below.
- TWAIN is a message driven Application Programmers Interface (API). Unlike other API's that you may be familiar with such as the Microsoft Windows API, ODBC, etc. TWAIN works by constantly sending messages to your application whenever an image is being acquired, your application must respond to these messages correctly. To make a TWAIN application work, your application must adjust the application's main event loop and prepare to process TWAIN messages that are sent to the application whenever an image is being acquired.
- The TWAIN specification is designed for C and C++ programs (and it still isn't easy to implement with these languages!). If you use Visual Basic, Delphi, Java, or any other language, you're going to have difficulties getting TWAIN image retrieval to work in your application.
- TWAIN must be controlled by means of state transitions. This basically means that the application must call certain TWAIN functions in a specific order. If the order is not followed, TWAIN most likely fails, either gracefully (the error is reported) or ungracefully (the application causes a GPF or causes an exception error).
- TWAIN is a specification that is not rigorously adhered to by a few Source writers. A series of TWAIN calls may work with one Data Source, but may not work with another Data Source. This is more of an anomaly than what is usually encountered, but it does happen. Part of the reason for this is that there is no official TWAIN governing body that determines whether a Source meets the TWAIN standard. This gives way for some Source writers to "cut corners" and sometimes improvise their implementations.
Overall, implementing TWAIN correctly within an application is a difficult job, even for the best programmers. The specification says what you need to do, but it is a very tedious job of setting things up, debugging, and can lead to many hours, days, and weeks of frustration.
What does DynaRithmic Software offer to overcome these limitations?
DynaRithmic Software offers the DTWAIN library to help relieve most, if not all of these limitations. How does DTWAIN fit into this picture? DTWAIN allows you to overcome all of the above limitations, and encapsulates the difficult TWAIN API into just a few function calls!
When writing a traditional TWAIN-compliant application, the TWAIN Data Source Manager (DSM) sits between your application and the actual device. The TWAIN Data Source Manager is available from the TWAIN Working Group and is the same for every computer equipped with an installed TWAIN device.
Your application sends commands to the TWAIN DSM, which in turn controls 1 or more Data Sources. The Data Source (or for short, Source) is the piece of software that comes bundled with the scanner or digital camera. The Source is proprietary for each device and is usually created by the manufacturer of the device, since the Source provides the code to actually make the scanning device function. The Source usually displays a graphical User Interface (UI) that is created specifically for the hardware device, and the UI is activated when the Data Source Manager requests that the Source acquire an image (some Sources allow an application to turn off the User Interface).
The scanning hardware is denoted in the picture above as Device #x. Note that your application makes no calls directly to the Source or to the actual device. All communication between your application and the hardware is done via the TWAIN DSM. Also important is that the TWAIN DSM sends messages back to your application. As was stated before, this layout seems simple in concept (and it is), but is a very different matter when it comes to implementation.DTWAIN comes into play by placing itself between your application and the TWAIN DSM. This allows you to use a much easier interface to TWAIN than if your application had to interface with the TWAIN DSM directly. Here is a pictorial layout of this relationship:
Note that DTWAIN now sits between your application and the TWAIN DSM. By letting DTWAIN be the "traffic cop" to the TWAIN manager, you will be up and running implementing TWAIN in your application in just a few minutes instead of days or weeks! Using DTWAIN, don't be surprised if you implement the most difficult of TWAIN tasks without having to read the TWAIN specification (although it is always to your advantage to read it in your newly found spare time! ). See a DTWAIN code example here. If you already have implemented some TWAIN in your application, compare what DTWAIN can do with your own code!
Copyright (c) 2019 DynaRithmic Software. All rights reserved.