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

Till Kamppeter till.kamppeter at gmail.com
Thu Nov 7 19:14:59 UTC 2019

On 07/11/2019 17:49, Solomon Peachy wrote:
> 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.

The wrapping of existing legacy CUPS drivers method is only for the case that 
such drivers exist and it is not worthwhile or possible to rewrite the drivers 
to get native IPP applications.

This is for example the case with

- Proprietary drivers from which we do not have the source code

- Drivers for old printers which are not maintained any more and no one wants to 
dive into the driver's internals

- Quick solution to not loose functionality/hardware support in a Linux 
distribution when the first CUPS without PPD support appears and some drivers 
are not yet converted.

The preferable way are native IPP applications. Whenever possible, especially 
for new drivers or for drivers which are actively maintained, like Gutenprint or 
HPLIP this is the way to go.

> 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.

See above.

>> - 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.

Any custom backend code can go into the Printer Application, either as existing 
CUPS backends or in the code of a native IPP application.

>> 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.

Therefore I also first thought about Gutenprint to get the first native Printer 

> 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.

Is it not the case that the only backend coming with Gutenprint currently is the 
USB backend for the dye sublimation printers with proprietary USB protocol?

> ...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.

With restructuring you mean here to spin out the functional code of the 
ippsample utilities into a library and provide an API?

> 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.

Most GPLish of cups-filters is inherited from CUPS, so we can probably turn it 
into ASL2.


More information about the Printing-architecture mailing list