On 11/05/2024 15:08, Alexander Pevzner wrote:
Regarding TWAIN Direct, I have few comments.
First of all, TWAIN Direct has nothing in common with the classical old-fashion
TWAIN except that it is backed by the same organization.
The classical TWAIN is the scanner API standard, like SANE. Driver may implement
any protocol under the hood, but if it implements the TWAIN API, it is
compatible with all apps that can work with TWAIN drivers.
The TWAIN Direct is the, first of all, network protocol. It is similar to eSCL
and WSD on its spirit, uses HTML as a transport and, as far as I remember,
DNS-SD for discovery. Requests and responses are encoded in JSON (unlike eSCL
and WSD; these are XML-based),
Specification is freely available, but it's quality, well, like WSD: many
ambiguous places that needs experimenting.
In theory, TWAIN Direct can be one of the driverless protocols for scanner, like
others already in use.
OK, good to know that TWAIN Direct is a forth network scanning protocol in
addition to IPP Scan, eSCL, and WSD and we have also specs for it naturally knot
knowing the quality of these specs.
Practically, scanners that support TWAIN Direct in firmware are very rare
things.
Also good to know. We must check whether these scanners are TWAIN-Direct-only,
in this case we would need a TWAIN-direct backend, if all these scanners are
also eSCL or WSD we can perhaps consider TWAIN Direct as dead standard.
So far I know only one such a device, Xerox D70n Scanner
(https://www.xeroxscanners.com/en/us/products/item.asp?PN=D70N) but never seen
it in real life.
If TWAIN Direct scanners will become more popular, I will consider adding
support of this protocol into sane-airscan. Currently I even don't have a device
for testing.
Yes, we would need at least one device for testing if we want to add support
for it.
So for me there is higher priority on adding support for IPP Scan, client (ans
backend, sane-airscan) and server (PAPPL).
Till
