A digital document scanning over a network seems to exist on one hand, but on the other hand, it hasn't become a common practice, unlike network printing. Administrators still need to install drivers, and the setup for remote scanning is unique for each scanner model. What technologies are currently available, and does this scenario have a future?
Driver installation or direct access
Currently, there are four common types of drivers: TWAIN, ISIS, SANE, and WIA. Essentially, these drivers serve as an interface between the application and the low-level library from the manufacturer, which connects to a specific model.
Simplified architecture for connecting to the scanner
Typically, it is assumed that the scanner is connected directly to the computer. However, there are no restrictions on the protocol between the low-level library and the device. This can also be TCP/IP. This is how most network multifunction devices currently operate: the scanner appears as local, but the connection goes through the network.
The advantage of this solution is that the application does not care how the connection is made; it just needs to see the familiar TWAIN, ISIS, or other interface. There is no need to implement special support.
But the drawbacks are obvious. This solution is tied to a desktop OS. Mobile devices are immediately excluded from support. Another downside is that drivers may work unstably in complex infrastructures, for example, on terminal servers with thin clients.
A solution would be to support direct connections to the scanner via the HTTP/RESTful protocol.
TWAIN Direct
was proposed by the TWAIN Working Group consortium as an option for driverless access.
TWAIN Direct
The main idea is that all the logic is transferred to the scanner side. The scanner provides access via REST API. Additionally, the specification includes a description of device publication (autodiscovery). It looks good. For the administrator, this eliminates potential driver issues. Support for all devices, as long as there is a compatible application. For developers, there are also advantages, primarily the familiar interaction interface. The scanner acts as a web service.
Se considerarmos cenários reais de uso, também existem desvantagens. A primeira é a situação de deadlock. No mercado, não há dispositivos com TWAIN Direct e os desenvolvedores não veem sentido em suportar essa tecnologia, e vice-versa. A segunda é a segurança; a especificação não apresenta requisitos para gerenciamento de usuários ou frequência de atualizações para fechar possíveis brechas. Também não está claro como os administradores controlarão as atualizações e acessos. Nos computadores, existe software antivírus. Já no firmware do scanner, isso pode não estar presente. servidor web, ou pode até estar, mas não de acordo com as políticas de segurança da empresa. Concorde que ter um malware que envia todos os documentos digitalizados para o lado não é nada positivo. Ou seja, ao implementar este padrão, as tarefas que eram resolvidas pelas configurações de aplicativos de terceiros são transferidas para os fabricantes dos dispositivos.
A terceira desvantagem é a possível perda de funcionalidade. Os drivers podem ter um processamento posterior adicional, como reconhecimento de códigos de barras e remoção de fundo. Alguns scanners possuem uma função chamada imprinter, que permite que o scanner imprima no documento processado. Isso não existe no TWAIN Direct. A especificação permite a extensão da API, mas isso levará ao surgimento de múltiplas implementações proprietárias.
E há mais uma desvantagem em cenários de trabalho com o scanner.
Digitalização a partir de um aplicativo, ou digitalização a partir do dispositivo.
Vamos considerar como ocorre a digitalização padrão a partir de um aplicativo. Coloco o documento. Em seguida, abro o aplicativo e digitalizo. Depois, pego o documento. Três etapas. Agora, imagine que o scanner de rede está em outra sala. É necessário fazer pelo menos duas idas até lá. Isso é menos conveniente do que a impressão em rede.
Por outro lado, quando o scanner pode enviar o documento por conta própria—por exemplo, para o e-mail. Eu coloco o documento, digitalizo e ele vai imediatamente para o sistema de destino.
Essa é a principal diferença. Se o dispositivo está conectado à rede, é mais conveniente digitalizar diretamente para o armazenamento de destino: uma pasta, e-mail ou sistema ECM. Nesse esquema, não há espaço para o driver.
Ao olhar de fora, utilizamos a digitalização de rede sem alterar as tecnologias existentes. Tanto de aplicativos de desktop via driver, quanto diretamente do dispositivo. No entanto, a digitalização remota a partir de um computador não se tornou tão popular quanto a impressão em rede, devido a diferenças nos cenários de uso. A digitalização diretamente para o armazenamento desejado está se tornando mais demandada.
O suporte a scanners TWAIN Direct como substituto de drivers é um passo muito acertado. Mas o padrão chegou um pouco atrasado. Os usuários querem digitalizar diretamente de dispositivos de rede, enviando documentos para o destino. As aplicações existentes não precisam suportar o novo padrão, pois tudo já funciona bem atualmente, e os fabricantes de scanners não têm necessidade de implementá-lo, uma vez que não há aplicações.
E, por fim. A tendência geral mostra que a digitalização de uma ou duas páginas será substituída por câmeras de telefones. A digitalização industrial permanecerá, onde a velocidade e suporte a funções de pós-processamento, que o TWAIN Direct não pode fornecer, serão importantes, e onde a integração estreita com o software continuará sendo essencial.
Fonte: habr.com
