[Printing-architecture] Will IPP printer devices and Printer Applications obsolete the cupsd?

Till Kamppeter till.kamppeter at gmail.com
Fri Aug 14 09:57:04 UTC 2020

On 14/08/2020 10:47, Johannes Meixner wrote:
> Hello,
> I have a general question:
> Will IPP printer devices and Printer Applications obsolete the cupsd?

No, cupsd does spooling, pre-filtering (convert PDF to Raster, 
flattening PDF forms, N-up, booklet, scaling photos to page, print A4 on 
Letter and vice-versa, ...), printer sharing on networks, also with 
authentication like Kerberos, ...

> My current understanding about future Linux printing is that
> "printing targets" (i.e. whereto clients send what to print)
> will be only IPP servers
> either as IPP server running inside an IPP printer device
> or as IPP server running in a Printer Application
> and
> clients autodetect the "printing targets" via DNS-SD
> (mostly indirectly via a DNS-SD listener like Avahi)
> and then
> clients communicate via IPP directly with a "printing target"
> to get the actual printing done.
> The cupsd is also an IPP server
> but when clients communicate directly with
> IPP printer devices or Printer Applications
> I wonder what is left as use case to have a cupsd running?

There are two ways how a client can find available printers:

1. As you mention, DNS-SD and IPP, finds physical network printers, 
Printer Applications, and remote CUPS queues (a CUPS daemon is also a 
certain kind of Printer Applications).

2. The (new) CUPS API. cupsEnumDests() of libcups lists the printers 
available for the local (or default) cupsd.

User applications should use CUPS, find printers via method (2). Why?

SPOOLING: Printer Applications (and also network printers) are not 
required to spool jobs. If you send a job to a non-spooling target it 
can happen that your application is blocked until the target has taken 
in the job completely.

Non-spooling targets are for example the IPP-over-USB daemons ipp-usb 
and ippusbxd, also cheaper printers can be non-spooling. PAPPL is 
probably spooling, but I am not sure. Michael? cupsd always spools jobs.

RASTER-ONLY PRINT TARGETS: There are Printer Applications and also 
network printers which do not accept PDF as input format, but user 
applications send jobs in PDF.

We do not want the application and GUI developers to have to chabnge the 
print dialogs of applications to send both PDF and Raster on the 
target's needs. It is difficult enough to make them change something 
(think of CUPS' temporary queues or the Common Print Dialog Backends 
(CPDB). We are lucky that all applications send PDF nowadays. CUPS 
happily converts PDF input to Raster.

PDF HANDLING: Printer Applications or network printers which accept PDF 
can easily have problems to correctly print PDFs with filled forms or 
annotations. They also are not able to do N-up, booklets, even/odd 
pages, print a photo filling the whole paper without white borders left, 
... or not in a very sophisticated way. CUPS runs all jobs through the 
pdftopdf filter which flattens filled forms and annotations to ordinary 
PDFs (with the filled-in data), and does the page management, ...

NETWORK PRINTING: Most Printer Applications are intended to replace the 
classic printer drivers, to get rid of the old, clunky PPD files, and 
also to have a way to to work with a sandbox-packaged CUPS and 
sandbox-packaged printer drivers, for distribution-independent driver 
packages, and extra security. Other Printer Applications (ipp-usb, 
ippusbxd) take USB devices into the wonderful world of driverless 
printing and scanning (by the way, the Canon Lide 400 scans perfectly 
under Linux),

BUT the many different developers of all these do not put in a very 
highly sophisticated network interface, but only the basics, sometimes 
only to work on localhost (loopback devices) or at least on the network 
interface of the local machine, for the local network. No sophisticated 
things like Kerberos authentication, also encrypted communication is not 
always assured. CUPS does all this and even gives much better 

> Or in other words:
> When filters and backends are dropped from CUPS
> what would be still left to do for a cupsd?
> I.e. what service would a cupsd still provide then?
> Cf.
> https://www.cups.org/doc/man-filter.html
> and
> https://www.cups.org/doc/man-backend.html
> that read (excerpt)
> "CUPS printer drivers and backends are deprecated and
> will no longer be supported in a future feature release of CUPS"

Classic drivers are deprecated and replaced by Printer Applications. 
This does not mean that CUPS filters are deprecated. The driver filters, 
rasterto... will go away, but not general filters, like ...topdf, 
pdftopdf, pdftoraster. Backends will most probably go away, and the IPP 
backend as the only remaining one get built-in.

cupsd has still enough to do: Spooling, pre-filtering, networking.

Michael, am I right, did I see it correctly?

I hope Apple will recover working on CUPS and I do not actually start a 
bug-fix fork for the distro maintainers on OpenPrinting.


More information about the Printing-architecture mailing list