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

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

[Till Kamppeter]

Hi,

CUPS 2.3.0 came out recently and looking deeper into it, the removal of PPD file 
support comes closer.

If you create a print queue using the lpadmin command, not using "-m 
everywhere", but any other "-m ..." or "-P ..." argument, causing the queue to 
get a PPD file in /etc/cups/ppd/, you get the following warning message:

lpadmin: Printer drivers are deprecated and will stop working in a future 
version of CUPS.

With this explicit warning issued by command the removal seems to be close.

So we need it to make the next step of development in OpenPrinting to prepare 
for printer drivers being delivered as Printer Applications.

So we need to concentrate on Printer/Scanner Applications and IPP System Service 
from know on.

This is a substantial change in the printing architecture on Posix-style 
operating systems.

Especially we need to create libraries to allow easy creation of Printer/Scanner 
Applications.

They should provide:

- Acquisition of a port on localhost (or on all
   network interfaces for sharing). Managing the
   port numbers in a useful way.

- DNS-SD advertising of the services (printer,
   scanner, fax, config interfaces, ...)

- IPP server: Answering all types of requests and
   calling functions to do the needed interactions
   with the printer/scanner and the application-
   internal printer/scanner capability data.

- Processing and filtering the incoming job data:
   Printer Applications will take PDF and raster
   formats as input and convert to the printer's
   native format. Functionality of the filters in
   cups-filters should be moved into a library, to
   be available as API functions.

- Legacy interface functions: For filters/PPDs and
   for SANE drivers.

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

- IPP System Service as a server, to allow
   configuration of the Printer/Scanner Application
   via an external GUI (IPP System Service client).
   Then there can even be a Printer Application for
   a legacy printer which cannot be auto-discovered
   in the network. The application starts only
   providing IPP System Service. As soon as the
   user has entered the printer's IP address via
   the configuration interface, the application
   connects to the printer and starts to offer IPP
   print service.

- Perhaps also a web server for legacy clients.
   Then commodity functions of the library for
   building up a configuration interface should add
   each interface element to both the IPP System
   Service server and the web server.

- IPP System Service as a client, for GUI (and
   also CLI) apps to configure IPP printers and
   also Printer/Scanner Applications. This will be
   a central part of printer setup tools in the
   future.

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.

Additional things to do:

- Turn cups-browsed into a Printer Application:
   Instead of creating a local CUPS queue for a
   printer cluster emulate an IPP printer which
   prints to the cluster (and local CUPS picks it
   up automatically, but how to prevent local CUPS
   from seeing the member printers directly?). We
   can also pick up legacy CUPS broadcasts (or
   BrowsePoll from legacy servers) and provide
   these printers as IPP printers. Configuration of
   cups-browsed then also via IPP System Service.

- Overtake PPD support API functions and pstops
   filter as soon as they get dropped from CUPS,
   for legacy support in Printer Aplications and
   cups-browsed.

- SANE driver for IPP scanners, so that
   applications accessing scanners via SANE can
   also access IPP scanners and Scanner
   Applications.

Documentation/Community reach-out:

- Design guidelines for printer and scanner
   drivers as Printer/Scanner Applications,
   instructions to do this with our new libraries.

- As soon as SANE is wrapped into Scanner
   Applications, move GUI developers to base their
   scan frontends on IPP scanning and not SANE any
   more.

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?

    Till

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Till Kamppeter]

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

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

    Till

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Thu, Nov 07, 2019 at 08:14:59PM +0100, Till Kamppeter wrote:
> - 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.

I think this should be the primary beneficiary.  I'm personally not 
going to lose any sleep over already-abandoned proprietary drivers that 
were never really supported to begin with.  :)

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

Absolutely.

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

Correct, althrough there are also some utilites for administrative 
actions on some inkjet families (alignment, cleaning, etc).

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

Yes, ideally with the cooperation of the ippsample authors. IMO it would 
be a win-win for everyone.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Andreas Radke]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Am Thu, 7 Nov 2019 21:06:31 -0500
schrieb Solomon Peachy <pizza@shaftnet.org>:

> On Thu, Nov 07, 2019 at 08:14:59PM +0100, Till Kamppeter wrote:
> > - 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.  
> 
> I think this should be the primary beneficiary.  I'm personally not 
> going to lose any sleep over already-abandoned proprietary drivers
> that were never really supported to begin with.  :)

If some big player wants to keep PPD driver support alive they should
keep maintaining a cups 2.3.x fork until the last non-IPP driven device
is dead.

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

IPP without any backward compatibility should be the preferred way to
go.

When cups 2.4.x will be out I will probably disable any ppd driven
driver support in Arch. Just to stop people using closed source driver
and to push open standards. Anything else will probably go into our
community maintained unsupported AUR repositories.

-Andy
Arch Linux

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

On Fri, Nov 08, 2019 at 11:57:51AM +0100, Andreas Radke wrote:
> When cups 2.4.x will be out I will probably disable any ppd driven
> driver support in Arch. Just to stop people using closed source driver
> and to push open standards. Anything else will probably go into our
> community maintained unsupported AUR repositories.

It's not proprietary drivers I'm concerned about -- There's a _huge_ 
install base of SMB-exported or native networked PCL/PS+PPD printers, 
and MajorDistros(tm) can't get away with just dropping legacy CUPS 
before there is a JustWorking(tm) alternative folks' existing printers.

The goal ahead is good, and very much achievable, but as Till's original 
email laid out, it's a pretty long road and we're not exactly drowning 
in manpower...

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Sweet]

Solomon,

> On Nov 8, 2019, at 8:33 AM, Solomon Peachy <pizza@shaftnet.org> wrote:
> 
> On Fri, Nov 08, 2019 at 11:57:51AM +0100, Andreas Radke wrote:
>> When cups 2.4.x will be out I will probably disable any ppd driven
>> driver support in Arch. Just to stop people using closed source driver
>> and to push open standards. Anything else will probably go into our
>> community maintained unsupported AUR repositories.
> 
> It's not proprietary drivers I'm concerned about -- There's a _huge_ 
> install base of SMB-exported or native networked PCL/PS+PPD printers, 
> and MajorDistros(tm) can't get away with just dropping legacy CUPS 
> before there is a JustWorking(tm) alternative folks' existing printers.

Even at Apple, we are quite aware that some of our customers depend on SMB printing.  Our focus is on enterprise-class printers (so PostScript and PCL) which can largely be supported using "generic" drivers already, which means something like ippeveprinter (running as the logged-in user, which has the side benefit of cleaning up Kerberos support) to act as the software that talks to the SMB server.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer