Twain

With the introduction of scanners, digital cameras, and other image-capturing devices, users are eagerly discovering the value of integrating images into their documents and other work. However, the cost of supporting the display and operation of this raster data is high, and application developers need to create user interfaces and built-in devices to control the wide variety of graphics devices available. Once their application is ready to support a given device, they face a frustrating reality: the device is constantly updated with new functions and features. Application developers find that they are constantly modifying their products to keep up to date with image capture devices and software application developers both recognize the need for standard communication between image devices and applications. A standard facilitates the use of their products. It will allow more applications to access device vendors’ products, and application vendors can access data from those devices, regardless of what type of device or specific device is providing the data. TWAIN was developed out of a need for consistency and simplicity.

Introduction to Twain Development

TWAIN defines a standard software protocol and API(application Programming interface) for communicating between software applications and the image acquisition device (the source of the data). Twain’s three key elements are:

  • Application software

Applications must be modified to use TWAIN.

  • Source Manager software

The software manages the interaction between the application and the source. This code is available in the TWAIN developer’s toolkit, and should be freely available for every TWAIN application and source code.

  • Source software

The software controls the image acquisition equipment and is written by the equipment developer according to THE TWAIN specification. Traditional device drivers are now included in the source software and do not need to be provided by the application.

What is the relationship between these elements? Twain is a protocol that does not require us to communicate with devices (scanners here). The communication is provided by a Data Source Manager. Our applications only need to call the corresponding functions of the Data Source Manager. The Data Source Manager is then responsible for communicating with the devices that support THE Twain protocol (specifically, the device drivers).

The Data Source Manager in Windows is implemented by twain_32.dll.

Twain protocol PDF ask.qcloudimg.com/draft/76519…

Twain Communication Process

Communication between TWAIN elements can be achieved through two entry points. They are DSM_Entry() and DS_Entry(). DSM refers to the data source manager (i.e. Twain_32.dll) and DS refers to the data source (driver).

The goal of the application is to get data from the source. But the application cannot call the source directly. All requests for data, functional information, error information, and so on must be processed through the source manager.

Twain defines about 140 operations. The application sends them to the source manager for transport. The application specifies which element (source manager or source) is the final destination for each requested action. Applications communicate with the source manager through the source manager’s unique entry point, the DSM_Entry() function. The argument list of the DSM_Entry function includes:

  • An identifier structure that provides information about the application that initiated the function call.
  • The destination (source manager or source) of the request.
  • The triplet describes the requested operation. Triples are: Data group of the operation (DG_) Data parameter type of the operation (DAT_) Message of the operation (MSG_)
  • A function call returns a value (return code) indicating the success or failure of the operation.
TW_UINT16 TW_CALLINGSTYLE DSM_Entry
    (   pTW_IDENTITY pOrigin, // source of message
        pTW_IDENTITY pDest, // destination of message
        TW_UINT32 DG, // data group ID: DG_xxxx
        TW_UINT16 DAT, // data argument type: DAT_xxxx
        TW_UINT16 MSG, // message ID: MSG_xxxx
        TW_MEMREF pData // pointer to data
    );
Copy the code

Twain states

The application, source manager, and source must communicate to manage the acquisition of data. It is logical that this must happen in a particular order. For example, an application cannot successfully request a transfer of data from a source until the source manager is loaded and ready for request communication. To ensure proper sequence execution, the TWAIN protocol defines seven states that exist in a TWAIN session. A session is a period of time during which an application connects to a specific source through the source manager. The time an application is connected to the Source Manager is a unique session, with both the Source Manager and the TWAIN elements of the Source occupying a specific state. The transition to the new state is caused by an operation requested by the application or the source, and the transition can take place backwards or forwards. Most transitions are single-state transitions. The transition status diagram is as follows:

State 1 to 2 – Load Source Manager to get DSM_Entry interface State 2 to 3 – Open Source Manager State 3 – Select Source State 3 to 4 – Open Source State 4 – Set the Capabilities of Source State 4 to 5 – Request to get data from Source State 5 to 6 – Data can be prepared message State 6 to 7 – Start data transfer State 7 to 6 to 5 – Complete transmission State 5 to 1 – Disconnect

C # call

The application calls the Source Manager, operates using NTwain, and adds references to nuGET.

Github, which has the source code and demo: github.com/soukoku/ntw… After adding the reference, open the Source Manager, and you can select source or load the default source.

With Source open and the state being 4, we can set the device, and there are many kinds of Settings, but there are default values, current values, possible values and other optional values that can be supported. These types can be found in the protocol, which is the corresponding Settings in the driver. Twain calls these Capabilities, and the CORRESPONDING NTwain package contains them, such as setting up a scanner to perform double-sided scanning

_twain.CurrentSource.Capabilities.CapDuplexEnabled.SetValue(BoolType.True);
Copy the code

About Fujitsu set image mode: multiple image output

There is a big hole here. When using NTwain Settings, you can only set the image mode of black, white, gray, and color by CapPixelType, using the following code:

_twain.CurrentSource.Capabilities.ICapPixelType.SetValue(PixelType.RGB)
Copy the code

Can not set multi-picture output, in the driver to find pictures really only support these ways, and then I always thought THAT I looked at which function, read the Twain protocol, and then go to the Internet to find a variety of information on this aspect, most of them are very simple introduction, tangled for a week did not know. Then I found the Website Vintasoft and saw a question. It turned out that this is not in the standard protocol for setting Twain. I think it was made by Fujitsu. The preceding Twain communication process says that operations can only be performed through the DSM_Entry() function as long as the (TW_UINT16 DAT,// data argument type: DAT_xxxx) Id of the triples you pass in is correct and supported.

Use the following code to new a multi-image output function object and then set it like any other.

new CapWrapper<MutilImageOutPutType>(dataSource, (CapabilityId)0x80f2, ValueExtensions.ConvertToEnum<MutilImageOutPutType>,
                    value= >new TWOneValue
                    {
                        Item = (uint)value,
                        ItemType = ItemType.UInt16
                    });
Copy the code
public enum MutilImageOutPutType : ushort
    {
        Disabled = 0,
        RGBAndBW = 1,
        BWAndRGB = 2,
        Enabled = 3,
        Auto = 4,}Copy the code

Finally scan to get the picture