Scanning documents online
Scanning documents over the network on the one hand seems to be there, but on the other hand it has not become a standard practice, unlike network printing. Administrators still install drivers, and the remote scan setting is individual for each scanner model. What technologies are there at the moment, and does this scenario have a future?
Currently, four types of drivers are common: TWAIN, ISIS, SANE and WIA. In fact, these drivers serve as the interface between the application and the low-level library from the manufacturer, which is associated with a particular model.
Simplified Scanner Connection Architecture
It usually means that the scanner is connected directly to the computer. However, no one restricts the protocol between the low-level library and the device. This could be TCP / IP. Thus, most network MFPs are working now: the scanner is visible as local, but the connection goes through the network.
')
Plus, such a decision is that the application doesn’t care how the connection is made, the main thing is to see the familiar TWAIN, ISIS or other interface. No need to implement special support.
But the disadvantages are obvious. The solution is tied to the dextop OS. Mobile devices immediately fall out of support. The second disadvantage is that drivers may operate unstable on complex infrastructures, for example, on terminal servers with thin clients.
The way out is to support direct connection to the scanner via HTTP / RESTful protocol.
TWAIN Direct was proposed by the TWAIN Working Group consortium as an option for driverless access.
Twain direct
The basic idea is that all logic is transferred to the side of the scanner. A scanner provides access to the REST API. Additionally, the specification contains a description of the publication of the device (autodiscovery). Looks nice. For the administrator, this is getting rid of possible driver problems. Support for all devices, as long as there is a compatible application. For the developer, there are also pluses, first of all a familiar interaction interface. The scanner is a web service.
If we consider the actual use scenarios, then there are also disadvantages. The first is the deadlock situation. There are no devices with TWAIN Direct on the market and there is no point for developers to support this technology and vice versa. The second is security, the specification does not impose requirements on user management, the frequency of updates to close possible holes. It is also not clear how administrators control updates and access. The computer has antivirus software. And in the firmware of the scanner, which obviously will be a web server, this may not be the case. Or to be, but not what the company’s security policy requires. Agree, to have a malware that will send all scanned documents to the left is not very good. That is, when implementing this standard, tasks that were solved by setting up third-party applications are passed on to device manufacturers.
The third minus is the possible loss of functionality. Drivers may have additional post-processing. Barcode recognition, background removal. Some scanners have a so-called. imprinter is a function that allows the scanner to print on the processed document. This is not in TWAIN Direct. The specification allows for an extension of the API, but this will lead to the appearance of sets of custom implementations.
And one more minus in the scripts working with the scanner.
Let's take a look at how normal scanning happens from within an application. I put the paper. Then I open the application and scan. Then pick up the document. Three steps. Now imagine that the network scanner is in a different room. You need to make at least 2 approaches to it. It is less convenient than network printing.
Another thing is when the scanner itself is able to send the document. For example, by mail. I put the paper. Then scan. The document immediately flies to the target system.
This is the main difference. If the device is connected to the network, it is more convenient to scan directly to the target storage: folder, mail or ECM system. In this scheme, there is no place for the driver.
Seen from the outside, we use network scanning without changing existing technologies. And both from desktop applications through the driver, and directly from the device. But remote scanning from a computer did not become as massive as network printing, due to differences in operating scenarios. Scanning to the right store immediately becomes more popular.
Support by TWAIN Direct scanners as a replacement for drivers is a very correct step. But the standard is a bit late. Users want to scan directly from a network device, sending documents to the destination. Existing applications do not need to support the new standard, as now everything works fine, and scanner manufacturers do not need to implement it, as there are no applications.
In conclusion. The general trend shows that a simple scan of one or two pages will be replaced by cameras on the phones. Industrial scanning will remain, where speed is important, support for post-processing features that TWAIN Direct cannot provide, and where tight integration with software will remain important.
Installable driver or direct access
Currently, four types of drivers are common: TWAIN, ISIS, SANE and WIA. In fact, these drivers serve as the interface between the application and the low-level library from the manufacturer, which is associated with a particular model.
Simplified Scanner Connection Architecture
It usually means that the scanner is connected directly to the computer. However, no one restricts the protocol between the low-level library and the device. This could be TCP / IP. Thus, most network MFPs are working now: the scanner is visible as local, but the connection goes through the network.
')
Plus, such a decision is that the application doesn’t care how the connection is made, the main thing is to see the familiar TWAIN, ISIS or other interface. No need to implement special support.
But the disadvantages are obvious. The solution is tied to the dextop OS. Mobile devices immediately fall out of support. The second disadvantage is that drivers may operate unstable on complex infrastructures, for example, on terminal servers with thin clients.
The way out is to support direct connection to the scanner via HTTP / RESTful protocol.
Twain direct
TWAIN Direct was proposed by the TWAIN Working Group consortium as an option for driverless access.
Twain direct
The basic idea is that all logic is transferred to the side of the scanner. A scanner provides access to the REST API. Additionally, the specification contains a description of the publication of the device (autodiscovery). Looks nice. For the administrator, this is getting rid of possible driver problems. Support for all devices, as long as there is a compatible application. For the developer, there are also pluses, first of all a familiar interaction interface. The scanner is a web service.
If we consider the actual use scenarios, then there are also disadvantages. The first is the deadlock situation. There are no devices with TWAIN Direct on the market and there is no point for developers to support this technology and vice versa. The second is security, the specification does not impose requirements on user management, the frequency of updates to close possible holes. It is also not clear how administrators control updates and access. The computer has antivirus software. And in the firmware of the scanner, which obviously will be a web server, this may not be the case. Or to be, but not what the company’s security policy requires. Agree, to have a malware that will send all scanned documents to the left is not very good. That is, when implementing this standard, tasks that were solved by setting up third-party applications are passed on to device manufacturers.
The third minus is the possible loss of functionality. Drivers may have additional post-processing. Barcode recognition, background removal. Some scanners have a so-called. imprinter is a function that allows the scanner to print on the processed document. This is not in TWAIN Direct. The specification allows for an extension of the API, but this will lead to the appearance of sets of custom implementations.
And one more minus in the scripts working with the scanner.
Scan from application, or scan from device
Let's take a look at how normal scanning happens from within an application. I put the paper. Then I open the application and scan. Then pick up the document. Three steps. Now imagine that the network scanner is in a different room. You need to make at least 2 approaches to it. It is less convenient than network printing.
Another thing is when the scanner itself is able to send the document. For example, by mail. I put the paper. Then scan. The document immediately flies to the target system.
This is the main difference. If the device is connected to the network, it is more convenient to scan directly to the target storage: folder, mail or ECM system. In this scheme, there is no place for the driver.
Seen from the outside, we use network scanning without changing existing technologies. And both from desktop applications through the driver, and directly from the device. But remote scanning from a computer did not become as massive as network printing, due to differences in operating scenarios. Scanning to the right store immediately becomes more popular.
Support by TWAIN Direct scanners as a replacement for drivers is a very correct step. But the standard is a bit late. Users want to scan directly from a network device, sending documents to the destination. Existing applications do not need to support the new standard, as now everything works fine, and scanner manufacturers do not need to implement it, as there are no applications.
In conclusion. The general trend shows that a simple scan of one or two pages will be replaced by cameras on the phones. Industrial scanning will remain, where speed is important, support for post-processing features that TWAIN Direct cannot provide, and where tight integration with software will remain important.
Source: https://habr.com/ru/post/458908/
All Articles