[Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service

[Solomon Peachy]

On Thu, Nov 07, 2019 at 04:34:32PM +0100, Till Kamppeter wrote:
> - Legacy interface functions: For filters/PPDs and
>   for SANE drivers.

(all of my comments are limited to printing, not SANE)

I'm not sure what form this can meaningfully take, other than 
effectively being "Legacy CUPS in a container"

In my view there are really two parallel thrusts; Wrapping existing 
legacy CUPS drivers, and the brave new world of native-IPP solutions.

Where they are similar is in their interfacing to the outside system 
(OS integration, port selection, dns-sd, and so forth but once you 
step past that, they diverge rapidly.  For example, CUPS 
filter wrapping is necessarily PPD-centric, but that's a lot of 
baggage (and complexity) that is presumably unnecessary for native, 
directly-integrated stuff.

> - Communication with printers and scanners,
>   functionality of the CUPS backends.

Most printers can get away with the standard legacy CUPS backends, but 
there are custom backends to contend with (often proprietary), and a lot 
of quirks just to keep life interesting.

> For testing this we should create a native Printer Application from
> Gutenprint for example, or one for PostScript printers for which we have PPD
> files. We also should create a native Scanner Application wrapping SANE with
> its current driver collection.

Gutenprint is a good canidate for this as, at its core, it is a library 
that provides a rich API for printer description, configuration, and 
rasterization.  Its existing CUPS driver and GIMP plugin are 
effectively stand-alone applications that rely on that library, and 
would presumably be a decent example of how one would need to integrate 
third party code into any printer application framework.

Gutenprint's CUPS backends are sort of bolted onto the side, and 
typically support extensive printer configuration/status reporting and 
issuing OOB commands, areas where the IPP model offers substantial 
benefits over the (significant) inadequacies of the legacy CUPS model.

...suffice it to say I'm really looking forward to a native IPP wrapper 
around Gutenprint, and will help any way I can.

> The code should get preferably hosted at OpenPrinting as part of
> cups-filters or in separate projects/repositories. Probably we need to
> overtake some parts of the ippsamples code. Or should the lib then better be
> at the PWG as part ippsamples?

I agree that this effort will require subsuming substantial chunks of 
the ippsample code, if only because of tight integration requirements 
that probably don't align well with ippsample's existing codebase.

But IMO a development goal here would be to try to keep the IPP stuff 
self-contained, and if restructuring is necessary, try to convinve 
upstream ippsample to accept those changes as to minimize everyone's 
maintenance burdens.

Oh, one are of concern here is licensing; As well as chosing a license 
for the (substantial) new code that needs writing, of the code we'd 
presumably want to re-use or otherwise integrate, there's quite an 
assortment.  For example, ippsample is ASL2, gutenprint is GPL2+, and 
cups-filters is a mismash of GPL2, GPL2+, GPL3, GPL3+, and MIT.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20191107/7f7e6fd1/attachment.sig>