Scanning documents over the network

    Scanning documents over the network on the one hand seems to be there, but on the other hand it has not become common 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 such a scenario have a future.

    Installable driver or direct access


    Four types of drivers are currently common: TWAIN, ISIS, SANE, and WIA. In fact, these drivers act as the interface between the application and the low-level library from the manufacturer, which is associated with a specific model.

    connection sequence with the scanner

    Simplified scanner connection architecture

    It is generally understood that the scanner is connected directly to a computer. However, no one restricts the protocol between the low-level library and the device. It can be TCP / IP. Thus, most network MFPs now work: the scanner is visible as local, but the connection goes through the network.

    The advantage of this solution is that the application doesn’t exactly how the connection is made, the main thing is to see the familiar TWAIN, ISIS or another interface. No special support needed.

    But the cons are obvious. The decision is tied to the desktop OS. Mobile devices immediately fall out of support. The second minus, drivers can work unstably on complex infrastructures, for example, on terminal servers with thin clients.

    The solution is to support direct connection to the scanner via the HTTP / RESTful protocol.

    TWAIN Direct


    TWAIN Direct was proposed by the TWAIN Working Group as a driverless access option.

    twain direct

    TWAIN Direct

    The main idea is that all the logic is transferred to the side of the scanner. And the scanner provides access via 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, the main thing is that there is a compatible application. There are pluses for the developer too, primarily the familiar interaction interface. The scanner acts as a web service.

    If we consider the real use cases, then there are also disadvantages. The first is the deadlock situation. There are no TWAIN Direct devices on the market, and it makes no sense 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 unclear how administrators control updates and access. The computer has antivirus software. And in the scanner firmware, in which the web server will obviously be, this may not be. Or to be, but not what the company's security policy requires. Agree, having 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 the settings of third-party applications are transferred to device manufacturers.

    The third minus is a possible loss of functionality. Drivers may have additional post processing. Barcode recognition, background removal. Some scanners have the so-called imprinter - a function that allows the scanner to print on a processed document. This is not in TWAIN Direct. The specification allows the extension of the API, but this will lead to the emergence of many custom implementations.

    And one more minus in the scenarios of working with the scanner.

    Scan from an app, or scan from a device


    Let's look at how a normal scan from an application occurs. I put a document. Then I open the application and scan. Then I pick up the document. Three steps. Now imagine that the network scanner is in a different room. You need to do at least 2 approaches to it. This is less convenient than network printing.


    Another thing is when the scanner itself can send a document. For example, by mail. I put a document. Then I 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 immediately to the target storage: folder, mail or ECM system. There is no driver in this circuit.

    If you look from the side, 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 work scenarios. Scanning immediately to the desired storage becomes more popular.

    Support for TWAIN Direct scanners as a replacement for drivers is a very good step. But the standard was a little late. Users want to scan directly from a network device, sending documents as intended. Existing applications do not need to support the new standard, since now everything works fine, and scanner manufacturers do not need to implement it, since 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 phones. There will be industrial scanning, where speed is important, support for post-processing functions that TWAIN Direct cannot provide, and where close integration with the software will remain important.

    Also popular now: