[Printing-architecture] Concept for PPD-less CUPS-spooled printing on Bonjour-discovered network printers

[Till Kamppeter]

Hi,

after some discussion in the "Some suggestions for the DNS-SD (Bonjour)
printer support in the dialog" thread I have now found a concept for
printing on Bonjour-discovered IPP network printers.

Requirements are:

 - Printer should be listed in the print dialog
 - Printer in power-save mode should not be woken up by solely
    o Entering the (W)LAN with a running client device
    o Booting a client device
    o Logging in on a client device
    o Opening the print dialog from any application
 - Printer capabilities, especially paper sizes should be shown at
   least when the user selects the printer in the print dialog
 - Jobs should be sent with the printer capabilities taken into account
   and accompanied by user-selected settings
 - Jobs should be spooled locally with the standard methods of CUPS, so
   that jobs, also of different users, get correctly queued, and
   already existing job managers can be used to handle (kill, move,
   ...) the jobs.
 - CUPS 1.6.x and newer should be supported without patching CUPS

I have found a concept which can be implemented in cups-filters and the
print dialogs and can be applied immediately in the next release of all
current Linux distributions (not needing to wait for feature additions
to CUPS):

Requirement is that all jobs are sent in PDF and only IPP printers which
do Bonjour broadcasting and understand at least one of the common
standard languages PDF, PostScript, PWG Raster (= IPP Everywhere), PCL
XL, PCL 5c/e.

Central part is the pdftoippprinter wrappper filter. This filter has the
following properties:

 - Input format is only PDF
 - If the pdftopdf filter is installed, pdftoippprinter passes the
   input data through pdftopdf first, passing on the options of the 5th
   command line argument, this way number-up, page-ranges, ... are
   supported, but also low-footprint configurations without pdftopdf
   are possible.
 - Following the option "output-format" the following filters to
   generate the output format are selected:
    o output-format=application/pdf: No additional filter
    o output-format=application/postscript: pdftops
    o output-format=image/pwg-raster: (pdf/gs)toraster + rastertopwg
    o output-format=application/vnd.cups-pclxl: gstopxl
    o output-format=application/vnd.cups-pcl:
      (pdf/gs)toraster + rastertopclx/hpcups
  Presence of the filters for the selected format is checked and path
  only executed if filters are present.
- Other standard-IPP/PWG options are accepted to control common
  settings like paper size, tray, resolution, quality, color/gray, ...

For each discovered IPP printer (which is not a non-raw remote CUPS
queue) cups-browsed auto-creates a print queue with pdftoippprinter as
System V interface script (the command line syntax of CUPS filters and
System V interface scripts is the same). This way we can make a CUPS
queue with filtering but without need of a PPD, as a PPD requires the
definition of at least one paper size and as we cannot IPP-poll the
printer (waking it up) we do not know its paper sizes. The
"output-format" option can already be set on queue creation as the
printer's input formats are listed in the text record. so queue creation
will be done with the equivalent of

lpadmin -p ... -E -v ... -i /usr/lib/cups/filter/pdftoippprinter
  -o output-format-default=image/pwg-raster

On most printers A4/Letter printing would even already work on such a
queue by sending a PDF file without any option settings.

The print dialog lists this queue (and it would also discover this
printer via Bonjour) and the user selects it. The dialog queries the
printer's capabilities via IPP from the printer (not from the local
CUPS) at the first of the following events:

 - The dialog wants to display a preview
 - The user makes the options screen getting displayed
 - The user clicks "Print".

If none of the events occurs, for example if the user clicks "Cancel" or
selects another printer, the printer does not get queried.

If the user clicks "Print", the user-selected settings (or the defaults
if the user did not change anything) are sent as IPP attributes
(options) in standard IPP/PWG format along with the PDF job to the CUPS
queue. The pdftoippprinter filter runs the filter chain appropriate to
the printer's input format and applies the options (getting them through
the 5th command line argument).

Notes for Linux distros:

- Security frameworks like AppArmor or SELinux can block System V
  interface scripts as this concept was never used in distros.
  Execution of files in /etc/cups/interfaces/ must get allowed (and
  this directory must be created). For quick tests in Debian or Ubuntu
  run "sudo aa-complain cupsd" to deactivate AppArmor for CUPS.
- Creating a queue with an interface script copies the script into
  a config file (all under /etc/ is considered config file) and so an
  update of the cups-filters package improving or fixing pdftoippprinter
  would make existing queues missing the fix. Here I could create a
  trivial wrapper which does nothing else than calling the real
  pdftoippprinter filter and create all queues with this wrapper.

WDYT?

   Till