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

[Till Kamppeter <till.kamppeter@gmail.com>]

Some time ago, I have presented my concept for PPD-less printing on
Bonjour-detected IPP printers.

Now I am working on implementing this. I have made gstoraster working
PPD-less, by getting page size, resolution, color space, duplex, ... via
the 5th command line argument (sent from the client along with the job
as IPP attributes, with the same option and choice names as reported by
the printer via IPP).

But I am running into the following problem:

The document to be printed has varying page sizes, so the one size
supplied as IPP attribute is only a default value for the case that the
sizes are not specified in the input document. Currently, the "cups"
output device of Ghostscript compares each page of the document with the
page sizes listed in the PPD (Ghostscript reads the PPD for that) and
selects the best-fitting page size from the PPD.

Now without having a PPD the list of the supported/available paper sizes
on the printer can only be requested from the printer via IPP. The
client has already done this to display the available options in the
print dialog and to know the printer capabilities for generating the job
PDF file correctly.Now there are three possibilities:

1. The client sends only pages with sizes valid for the printer, so that
the server does not need to check. This does not allow simply sending an
arbitrary PDF file at CUPS. A PDF viewer has to prepare the print jobs
appropriately.

2. The client has to send a full list of the supported/available paper
sizes (name, size, tray, ...) to the server along with the job, so that
the server can use this list instead of a PPD file. In this case, what
is the syntax of the key=value pairs which I have to send as IPP
attributes together with the job?

3. The pdftoippprinter filter requests the printer's capabilities from
the printer by itselfaccessing the printer via IPP. Should a filter do
that should it do it somehow through the IPP backend of CUPS? Is it
possible to do this through the IPP backend of CUPS?

WDYT? How should one proceed here?

(1) is probably the easiest for the server side, (3) would allow to let
arbirary clients to send jobs, even clients which do not poll
capabilities from the printer and send no or only generic attributes as
the filter could set decent defaults in such a case.

   Till


On 06/14/2013 01:52 AM, Till Kamppeter wrote:
> 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
>