[sane-devel] Driverless IPP Scanning with SANE - Google Summer of Code 2019

Olaf Meeuwissen paddy-hack at member.fsf.org
Thu Mar 14 12:23:45 GMT 2019


Hi Till,

Till Kamppeter writes:

> Hi,
>
> I posted this already last year (see my mail from then below) but there
> we finally decided to give preference to other student projects.
>
> It is about driverless scanning using the IPP (Internet Printing Protocol).

Doesn't that sound oxymoronic?  Using a printing protocol to scan?

> "Driverless" means that on the client side no software specific to the
> scanner model in use is required. The client can ask the scanner for all
> its capabilities and use standard commands to do the scanning work.
>
> [...]
>
> We did not do it last year as there was no manufacturer yet who had
> adopted driverless IPP scanning. This year we also do not have any
> further notice from hardware manufacturers, but we have a new idea of
> nmaking use of driverless IPP scanning.
>
> In SANE scanner drivers are libraries which need to be present in a
> given directory of the system so that applications find them and so the
> applications can scan on all scanners which are supported by the
> available SANE backend libraries.

Nitpick, the SANE backends only need to be in a directory where the
application looks or, if using the dll backend, (lt)dlopen looks.  There
is no restriction on where you put stuff as long as you make the proper
adjustments to library load paths.

> This works well on systems with standard Debian or RPM packaging but not
> on systems with sandboxed packaging, like Snap for example. Here one
> cannot simply let one package (the scanner driver) drop a library in a
> directory where other packages (applications) search for it. For printer
> drivers we introduce the so-called Printer Applications, a simple
> daemon, emulating a driverless IPP printer on localhost and passing jobs
> on to the physical printer (which can be on USB or on the network and
> Printer Application converts incoming PDF to the printer's native
> language). The network-style communication on localhost is no problem
> for communication between two sandboxed applications.

What's wrong with using saned?  It's a simple daemon, emulating a SANE
backend passing API calls to the backend that supports the scanner.  Any
applications can use the SANE net backend to communicate with saned.
Simply installing the net backend as libsane (instead of the dll backend
that most if not all distribution use now) would be enough.  None of the
backends would need to be available in /usr/lib/sane (or wherever your
distro of choice puts them).  Only the saned sandboxed application would
need access to all the SANE backends needed.

> For scanners we want to do the same. We put a collection of SANE
> backends with SANE frontend library into a so-called Scanner Application
> and let it emulate a driverless IPP scanner on localhost. Such a Scanner
> Application can contain the standard SANE modules or it can be a Scanner
> Application provided by a scanner manufacturer to hold their
> (proprietary) driver. Applications scan then via IPP and for legacy
> applications which use SANE we need an IPP backend for SANE.
>
> [...]
>
> I am very grateful if someone could step up.

Sorry but I won't be volunteering this year around.  Too busy with other
stuff I find interesting.

> ----------
>
> [...]
>
> The PWG has recently also developed an IPP scanning standard, which
> provides a standard protocol for communicating with scanners in IPP
> multi-function devices (via network or IPP-over-USB):

What about scanners without a printer?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join



More information about the sane-devel mailing list