Hi,as leader of the OpenPrinting project and so also the principal architect of the printing environment of Linux and other POSIX-style operating systems I have already started to work on sandboxed packaging for printing (CUPS, printer drivers, applications which print or administrate printing) and due to multi-function printers also worked on sandboxed packaging for scanning. The implementation is already in the works by a student project.
Printer and scanner drivers were added to a system by putting the driver's files (filters and PPD files for printers, shared libraries for scanners) into reserved directories of CUPS and SANE.
With sandboxed packages (Snap. flatpak, ...) this does not work as each package has its own, separate file system. As we are working towards distros totally based on sandboxed packaging, like an all-Snap Ubuntu.
By the way, I am working for Canonical, doing also the packaging of printing-related stuff for Ubuntu, therefore I am more familiar with Snap than with flatpak, but for flatpak it is probably similar.
For solving this problem we did not have to design something new from the ground up, as the Printer Working Group (PWG, http://www.pwg.org/) came up with IPP (Internet Printing Protocol) already 20 years ago and more recently, they add the driverless IPP Everywhere printing and IPP scanning standards.
CUPS which was based on IPP currently uses filters and PPD files as printer drivers, but due to the fact that PPD files are decades ole, designed for PostScript printers, and not covering the needs of modern printers, this concept is deprecated. CUPS should only support driverless IPP printers in the future, most modern printers are driverless, and if a driver is needed the driver should be provided as a Printer Application, an emulated driverless IPP printer on the local machine, a daemon which behaves as an IPP printer and internally converts the job to the physical printer's format and sends it off to the printer. The Printer Application advertises itself via DNS-SD, so CUPS easily finds it, and via IPP CUPS can poll all capabilities, so no local data files, like PPDs needed, purely driverless.
The communication between CUPS and the Printer Application is a network (IP) communication, even if CUPS and the Printer Application are running on the same machine. It is easy to create sandboxed packages which can do IP communication, Snap for example has an appropriate interface for that. So CUPS can be in a Snap and the Printer Application can be in another Snap, and there can be any number of Printer Applications on the same machine, for example if you use printers of different manufacturers.
Snaps (and probably flatpak packages, too) are distribution independent. A Printer Application in the Snap Store should work on all distributions, so manufacturers have much more ease to create drivers for their hardware.
Seeing all this and also that the PWG created an IPP Scan standard to complete IPP for multi-function devices I came up with an extension of this idea to also allow snadboxed packaging of scanner drivers.
For this we create Scanner Applications, emulation of IPP scanners. The Scanner Application listens for scan requests via IPP and passes on the request to the actual scanner, and returns the scanned image, if needed, converted to the requested data format. A client (a GUI application like simple-scan for example) simply needs to talk IPP to the scanner (or better Scanner Application), so it always works driverless.
So the Scanner Application replaces the classic SANE driver but as with Printer Applications we have again a pure IP communication. So the client and the drivefr can be in different Snaps (or flatpaks) and distribution-independent scanner driver packages in the Store.
Naturally a Printer Application can also be an emulation of a multi-function device, containing both printer and scanner drivers. We can imaging that HPLIP could for example be provided this way. But this is not required, the printing part of a multi-function device can be supported by a Printer Application for Gutenprint and the scanning part by a Scanner Application for SANE, think about Epson multi-function devices.
Do not think that I want to kill SANE, SANE will still be used but not be that visible any more. We will create Scanner Applications which use SANE internally, so that existing SANE drivers stay available in the new world of IPP Scan, all scanners supported by SANE will also be supported by a Scanner Application. We will also have an IPP Scan SANE backend, so that client applications can scan on scanners supported by a Scanner Application. As CUPS finds printers via DNS-SD, this backend will find scanners (Scanner Applications) via DNS-SD.
For the sandboxed packaging, if one packages some SANE frontend, an application which scans, one packages it with the IPP Scan SANE backend. Then this sandboxed application can scan on all scanners supported by Scanner Applications. The Scanner Applications get also sandboxed, like Printer Applications.
Implementation of all this is already in the works, by two students working in a Linux Foundation Mentorship Program project One student expands sane-airscan to support IPP Scan as a client, to be packaged with SANE frontends, applications which scan. The other student implements IPP Scan as a server, to have the framework for Scanner Applications.
And here are some links for more details about all this: OpenPrinting Microconference on Linux Plumbers Conference 2019 https://openprinting.github.io/OpenPrinting-Microconference-on-Linux-Plumbers-Conference-2019/Here we have started the discussion about the driverless IPP scanning concept.
My monthly news posts about the work at OpenPrinting https://openprinting.github.io/news/Here you can see how the development of driverless scanning and Printer/Scanner Applications was going
OpenPrinting Microconference on Linux Plumbers Conference 2020 https://openprinting.github.io/OpenPrinting-News-September-2020/#openprinting-microconference-on-linux-plumbers-conference-2020A lot has happened between the two microconferences on Linux Plumbers. Here you get more concrete information about the new concepts.
Linux Foundation Mentorship Program project "IPP scan (or virtual MF device) server (Scanner Application)":
https://people.communitybridge.org/project/55cdb4a1-76bd-423a-ab48-3bdf1502a171The implementation of IPP Scan, extension of sane-airscan for IPP Scan as a client support and extension of PAPPL for IPP Scan as a server support
Ongoing Google Season of Docs project on designing and packaging printer and scanner drivers
https://piyushgoyal16.github.io/openprinting.github.io/documentation/Guidelines/Tutorial for free software projects and for hardware manufacturers on creating printer and scanner drivers. It is not yet complete, we are only one week into the 3 months of GSoD, but already a lot of interesting info.
PAPPL - Printer Application Support Library https://github.com/michaelrsweet/pappl/Everything which Printer/Scanner Applications have in common, to emulate a complete network multi-function device, including DNS-SD advertising, supply of full capability info via IPP, job handling, and also a web admin interface, as on a physical printer.
sane-airscan - SANE backend for driverless scanning https://github.com/alexpevzner/sane-airscanCurrently it supports the protocols multi-function devices which claim to do AirPrint use for scanning (AirScan): eSCL and WSD. IPP Scan support is about to be added.
CUPS Snap - The CUPS printing stack in a Snap https://github.com/OpenPrinting/cups-snapThis is the official CUPS Snap, intended to be the standard printing environment of Ubuntu, but can be used on any distribution with snapd installed.
Bastien, so this is more your second approach of drivers being on the host side, but we use IPP Scan as IPP is an established standard protocol and it is used for both printing and scanning, so ideal for multi-function devices. We get also interoperability between different operating systems, scanning from mobile devices, ....
Till On 17/09/2020 11:40, Bastien Nocera wrote:
Hey,
I wanted to finally start looking at how to properly integrate SANE-
based scanning applications into Flatpak[1].
I looked at 2 different ways to implement this:
- either the drivers are bundled with the application itself, and we
need to punch holes for those drivers to be able to communicate with
the hardware (eg. network, or USB[2]),
- or just as for a lot of other drivers, we can expect the drivers to
live on the host side, with the distribution, and we'd communicate with
those drivers (free or proprietary, like the ones for Epson V600...)
through a service that's outside the sandbox.
I think that the latter is the best one to put in place, especially if
we want to support more complicated setups like networked scanners,
multi-function devices, and proprietary drivers.
The idea would be to reimplement the client (based on the "net" driver)
to use D-Bus and reimplement or extend the server ("saned") to use D-
Bus.
Would the SANE project want to ship those in its own repositories? Are
there are dependencies that wouldn't be acceptable? I plan on using
systemd's D-Bus library, sd-bus, as it doesn't require a GLib mainloop
like the very capable GDBus, so would be less disruptive when loaded
into apps. Should I extend saned, or write a new daemon?
Cheers
[1]: https://github.com/flatpak/xdg-desktop-portal/issues/218
[2]: https://github.com/flatpak/xdg-desktop-portal/issues/227
