[Printing-architecture] Will IPP printer devices and Printer Applications obsolete the cupsd?
till.kamppeter at gmail.com
Fri Aug 14 09:57:04 UTC 2020
On 14/08/2020 10:47, Johannes Meixner wrote:
> 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
> 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
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?
> 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