Correct TWAIN Usage
We recommend against applications identifying scanner models. TWAIN is designed to expose functionality through capability negotiation. Writing applications that use functionality based on a model number makes it harder to maintain the code as new models come out that mix that functionality. For example:
Model 100 has features A, B, C
Model 200 has features A, X, Y
Code is written as follows:
Always use A
If (100) use B, C
If (200) use X, Y
A new model 300 has features D, C, X
If (100 200) use A
If (100) use B, C
If (200) use X, Y
If (300) use C, X
There are other ways to code this, but they all get unwieldy over time. The preferred method is:
If A is supported use A
If B is supported use B
If C is supported use C
If X is supported use X
If Y is supported use Y
In TWAIN a capability is tested for support using DG_CONTROL / DAT_CAPABILITY / MSG_QUERYSUPPORT.
Alternative TWAIN Usage
Every effort is made to make sure that the standard TWAIN capabilities are presented in a consistent fashion across all scanner models. Unfortunately, this same requirement is harder to enforce for the custom driver features. In situations like this it may be easier to identify a group of functions by associating them with a model number.
Before performing any custom operation an application must unambiguously identify the driver. For all KDS drivers this is done by examining the TW_IDENTITY returned by the DG_CONTROL / DAT_PARENT / MSG_OPENDS, and looking for the following:
Manufacturer "Kodak"
Version.Info "KDS v#.#.# YYYY/MM/DD"
This information does not apply to the 1500/2500 or the i50/i60/i80. These scanner models use different drivers, so one or both of the above fields will be different.
KDS Version 5/6.x drivers and higher report a specific scanner model through DG_CONTROL / DAT_DEVICEINFO/ MSG_GET when it is called in State 4 or higher. The model information is returned in the TW_DEVICEINFO.dwModelNumber or TW_DEVICEINFO.szModelName field. This is a custom feature of our driver.
KDS Version 4.x drivers and higher report a specific scanner model through DG_CONTROL / DAT_IDENTITY / MSG_GET when it is called in State 4 or higher. The model information is returned in the TW_IDENTITY.ProductName field. This is a custom feature of our driver.
KDS Version 3.x, 2.x and 1.x drivers do not support this feature, so it is necessary to use another method to identify the scanner model. The technique involves the systematic examination of standard and custom capabilities. The pseudo-code for this is provided below.
Note that it is not possible in all situations to uniquely identify all models in this way. However, from the viewpoint of the driver all of the models grouped in a section support exactly the same operations and capabilities, so for the purpose of testing for functionality, this technique is sufficient.
if CAP_MODE supported: 5xx/9xx/5xxx/7xxx/9xxx
if ICAP_FRAMELENGTHCONTROL supported
if CAP_PRINTERENABLED supported
if ICAP_XRESOLUTION includes 400 dpi
500/7560
else
500A/5520/7520
endif
else
if ICAP_XRESOLUTION includes 400 dpi
500/7550
else
500A/5500/7500
endif
endif
else
if ICAP_XRESOLUTION includes 300
900/923/9500/9520
else
990
endif
endif
else if CAP_IMAGEADDRESS supported: 8xx
if ICAP_PIXELTYPE includes TWPT_RGB
i820/i840
else
if ICAP_XRESOLUTION includes 400 dpi
i830
else
i810
endif
endif
else it must be mid-volume: 3xxx/4xxx
if CAP_ENABLECOLORPATCHCODE supported
3590
else if ICAP_PIXELTYPE includes TWPT_RGB
4500
else if CAP_AUTOMATICBORDERDETECTION supported
3520
else if CAP_MULTIFEEDTHICKNESSDETECTION supported
3510
else
3500
endif
endif