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

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

[Johannes Meixner]

Hello,

I have a general question:

Will IPP printer devices and Printer Applications obsolete the cupsd?

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?

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"


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

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

[Till Kamppeter]

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

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

    Till

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

[Johannes Meixner]

Hello Till,

thank you for your explanatory reply.
It is always much appreciated!

There is still a point that I do not understand:

On 2020-08-14 11:57, Till Kamppeter wrote (excerpts):
> On 14/08/2020 10:47, Johannes Meixner wrote (excerpts):
>> 
>> 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.

Those excerpts point to what I do not yet understand:

I was thinking it is an intended advantage that clients communicate
normally directly with IPP printer devices
(and with Printer Applications for legacy support)
so that there is direct communication with the "final printing target"
compared to indicect communication with what the actual printing does
via a proxy IPP server in between what cupsd would be in this case
if I understand things correctly.

Cf. the section
"CUPS: The server between user and printer" in
https://en.opensuse.org/Concepts_printing
that reads in particular (excerpt):
---------------------------------------------------------------------
Strictly speaking from the computer's internal point of view
it usually doesn't know about the actual printer devices
but only about print queues. What CUPS and application programs
call "printers" are usually not the actual printer devices but
only their associated print queues. This sketchy usage of the
word "printer" for the computer's internal representation can
lead to confusion when it is not clear for the user what it
actually means when CUPS or application programs show that
everything is o.k. with the "printer". Usually this means that
the state of the print queue is o.k. (e.g. "ready")
but the state of actual printer device could be different
at the same time (e.g. "out of paper").
---------------------------------------------------------------------

So when clients communicate with a proxy IPP target of the cupsd
and not with the final IPP target (i.e. the one that actually prints)
I wonder if "final printing target state forwarding" happens properly
i.e. that the "final printing target state" gets forwarded via
the proxy IPP target to the client?

In particular in case of spooling by a proxy IPP target
I assume "final printing target state forwarding" is impossible
in practice because the client had finished its IPP communication
with the proxy IPP target when some (possibly longer) time later
the proxy IPP server starts the actual printing via its own
IPP communication with the final printing target so there is no
"client <-> proxy IPP server <-> final printing target"
communication - instead there is first only a
"client <-> proxy IPP server"
communication and some time later there is a separated
"proxy IPP server <-> final printing target"
communication.

In general cf. RFC 1925 item 6a
"It is always possible to add another level of indirection."
https://tools.ietf.org/html/rfc1925

Side questions:

I would assume IPP printer devices have sufficient built-in memory
to do sufficient spooling for the intended use case of the device
(e.g. home user devices versus enterprise-ready devices)?

I would assume IPP provides functionality when an IPP server
cannot receive too much printing data (e.g. "out of memory")
so that clients can react/respond appropriately?


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

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

[Michael Sweet]

Johannes,

> On Aug 14, 2020, at 7:45 AM, Johannes Meixner <jsmeix@suse.de> wrote:
> ...
> Those excerpts point to what I do not yet understand:
> 
> I was thinking it is an intended advantage that clients communicate
> normally directly with IPP printer devices

Client applications shouldn't be talking directly to printers - most printers don't handle spooling of multiple jobs or the full range of file formats we are used to on Linux.  The current division of labor (application browses for printers, asks local spooler service to talk to printer) will remain.

________________________
Michael Sweet

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

[Michael Sweet]

Johannes,

> On Aug 14, 2020, at 4:47 AM, Johannes Meixner <jsmeix@suse.de> wrote:
> 
> 
> Hello,
> 
> I have a general question:
> 
> Will IPP printer devices and Printer Applications obsolete the cupsd?

Not specifically, but certainly a future version of cupsd (that doesn't support printer drivers) can be much simpler.  That had been the point of my previous CUPS Plenary presentations in 2018 and 2019 - CUPS (and cupsd) can evolve into a local (per-user) spooler service that handles converting things to raster as needed, sending the print jobs to IPP Printers, and reporting status/asking for authentication/etc.

A separate sharing server can be used for the traditional print server functionality, and it will be able to provide proper quotas/billing/accounting/access control/etc.

________________________
Michael Sweet