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

[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

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

[Till Kamppeter]

One additional remark:

This concept does not introduce a D-Bus dependency to cups-filters.
D-Bus is not needed at all for it.

   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.

[...]

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

[James Cloos]

I need to read that through after dinner, but my initial question is,
does it work with (cups’) lp(1) and lpr(1)?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Till Kamppeter]

On 06/16/2013 11:52 PM, James Cloos wrote:
> I need to read that through after dinner, but my initial question is,
> does it work with (cups’) lp(1) and lpr(1)?
> 
> -JimC
> 

Yes, it works with lp and lpr. Only problem is that you cannot display
the available options with the lpoptions command. If you simply send a
job without supplying options, the job gets printed with default
settings, if you supply standard IPP options with choices actually
available for your printer they will get obeyed.

So it works but is not very comfortable on the command line, but the
main use case for this are mobile devices, where you usually do not use
the command line and apps show printing dialogs and option screens with
options and choises polled from the printer.

   Till

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

[James Cloos]

>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:

TK> Only problem is that you cannot display the available options with
TK> the lpoptions command.

So, in other words, it doesn't support lp/lpr.  ☹

The cli remains vastly more useful than most GUI.  It is often the only
way to get work done.

And one must know the available options in order to use lp/lpr.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Michael Sweet]

James,

On 2013-06-17, at 8:42 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:
> 
> TK> Only problem is that you cannot display the available options with
> TK> the lpoptions command.
> 
> So, in other words, it doesn't support lp/lpr.  ☹

There are some ways of getting the options to show, but long-term I plan on extending lpoptions to list the supported IPP options as well...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[James Cloos]

>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:
>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:

TK>>> Only problem is that you cannot display the available options with
TK>>> the lpoptions command.

MS> There are some ways of getting the options to show, but long-term I
MS> plan on extending lpoptions to list the supported IPP options as well...

Cool.

That should leave the pdf-only submission format as the only issue.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Till Kamppeter]

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
> 

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

[Michael Sweet]

Till,

On 2013-07-25, at 10:46 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> 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.

Generally speaking, this is the approach we take in Apple OS's, with arbitrary PDF files getting scaled/centered/rotated to the default media if any rasterization occurs.

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

I don't see the client sending any printer capability information to the server with a job; it *might* provide a list of supported sizes (media-supported) or collections (media-col-database) when configuring a local queue, but in general I think it is better for the server to grab its own copy (as needed).

For current CUPS the way you pass this configuration information is with a PPD file. Future versions of CUPS might adopt a different format, e.g. IPP attributes in a file.

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

No.

> WDYT? How should one proceed here?

If you are printing through cupsd, you need a PPD.  If you are implementing some other kind of spooler, have the client pass the printer URI and default media size/color mode/type/resolution info.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Till Kamppeter]

Hi,

I have now done a first implementation of my concept of PPD-less
printing on IPP network printers (see below). It is implemented in the
cups-filters 1.0.41 package which I have released today.

This works as described below: cups-browsed discovers appropriate IPP
network printers via Bonjour and creates queues for them using the new
pdftoippprinter filter called by a simple System V interface script
(which passes through all command line options and adds an output-format
option to fit to the printer's accepted data formats (supported are PWG
Raster, PDF, PostScript, PCL-XL, and PCL 5c/e). The discovery of the
printers and creation of the queues does not actively poll info from the
printers, avoiding that they are woken up from power-save mode.

Printing a PDF file (other formats not supported) to such queues with a
simple "lpr" command with no options usually works if the document has a
standard page size (A4 or Letter, what is loaded into the printer), but
a GUI should give more control and make sure that the print data fits
well to the printer.

What is required from a GUI is that as soon as the user selects a
printer for printing (or with the default printer when just opening the
dialog) is that if the printer is such PPD-less queue, to poll the
printer via IPP (code example below) to get its capabilities, show the
user-settable options on the dialog's option panel (like PPD options)
and send the job accompanied with the option settings, including the
ones which the user has not changed and the ones which have only one
choice (and so are not changeable). The job itself should be in PDF
format and (if the printer supplies appropriate info) in a page size
supported by the printer.

Marek, John, I want to ask you whether you could download and install
cups-filters 1.0.41 and add support for these auto-created queues to
your print dialogs (GTK, Qt). This will allow easy (mobile) printing
without model-specific driver collections and without printer setup tool.

Note that the PPD-less printing is not yet perfect and needs some
additional polishing in the filters. Probably PWG Raster works best of
all formats.

   Till

----------

Code snippets for IPP polling of printer capabilities:

Input:  "uri" is the URI of the IPP printer to poll.

debug_printf() is a wrapper around printf(), printing only if the
program is called with the "--debug" option, you can simply replace it
by the normal printf() for testing.

The code needs libcups.

  #include <cups/cups.h>

  int i, uri_status, port, status;
  http_t *http;
  char scheme[10], userpass[1024], host_name[1024], resource[1024];
  ipp_t *request, *response;
  ipp_attribute_t *attr;
  static const char * const requested_attrs[] =
    {	/* Requested attributes for getting IPP network printer
capabilities */
	/* Explicit attribute listings for the case that "all" does not cover
	   everything */
      "job-template",
      "printer-description",
      /*"document-format-supported",
      "color-supported",
      "pages-per-minute",
      "pages-per-minute-color",
      "media-supported",
      "media-ready",
      "media-default",
      "media-type-supported",
      "media-source-supported",*/
      "media-col-database",
      /*"sides-supported",
      "sides-default",
      "output-bin-supported",
      "output-bin-default",
      "finishings-supported",
      "finishings-default",
      "print-color-mode-supported",
      "print-color-mode-default",
      "output-mode-supported",
      "output-mode-default",
      "print-quality-supported",
      "print-quality-default",
      "printer-resolution-supported",
      "printer-resolution-default",
      "copies-supported",
      "copies-default",*/
      /* Catch things which were forgotten above or newly introduced */
      "all"
    };
  static int versions_to_try[] =
    {
      20,
      11
    };

    uri_status = httpSeparateURI(HTTP_URI_CODING_ALL, uri,
				 scheme, sizeof(scheme),
				 userpass, sizeof(userpass),
				 host_name, sizeof(host_name),
				 &(port),
				 resource, sizeof(resource));
    if (uri_status != HTTP_URI_OK)
      goto fail;
    if ((http = httpConnect(host_name, port)) ==
	NULL) {
      debug_printf("cups-browsed: Cannot connect to remote printer %s
(%s:%d), ignoring this printer.\n",
		   p->uri, host_name, port);
      goto fail;
    }
    for (i = 0;
	 i < sizeof(versions_to_try) / sizeof(versions_to_try[0]);
	 i ++) {
      /* Create IPP request */
      request = ippNewRequest(IPP_GET_PRINTER_ATTRIBUTES);
      /* Set IPP version */
      ippSetVersion(request, versions_to_try[i] / 10, versions_to_try[i]
% 10);
      /* Printer URI */
      ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_URI,
		   "printer-uri", NULL, p->uri);
      /* Requested IPP attributes */
      ippAddStrings(request, IPP_TAG_OPERATION, IPP_TAG_KEYWORD,
		    "requested-attributes",
		    sizeof(requested_attrs) / sizeof(requested_attrs[0]),
		    NULL, requested_attrs);
      /* Do it */
      response = cupsDoRequest(http, request, resource);
      if (response == NULL) {
	debug_printf("cups-browsed: No answer to Get-Printer-Attributes IPP
request from remote printer %s, ignoring this printer (IPP Error: %s
%s).\n",
		     p->uri, ippErrorString(cupsLastError()),
		     cupsLastErrorString());
	httpClose(http);
	goto fail;
      }
      status = cupsLastError();
      debug_printf("cups-browsed: Remote printer %s, IPP %3.1f: %s (%s)\n",
		   p->uri, versions_to_try[i] / 10.0,
		   ippErrorString(cupsLastError()),
		   cupsLastErrorString());
      /* If succeeded, go on, on error try a lower IPP version */
      if (status < 0x0400)
	break;
    }
    if (i >= sizeof(versions_to_try) / sizeof(versions_to_try[0])) {
      /* All IPP versions failed */
      debug_printf("cups-browsed: Remote printer %s: All IPP versions
failed\n",
		   p->uri);
      goto fail;
    }
    /* Read out the printer's capabilities */
    attr = ippFirstAttribute(response);
    while (attr) {
      debug_printf("Attr: %s\n",
		   ippGetName(attr));
      for (i = 0; i < ippGetCount(attr); i ++)
	debug_printf("Keyword: %s\n",
		     ippGetString(attr, i, NULL));
      attr = ippNextAttribute(response);
    }
    attr = ippFindAttribute(response,
			    "document-format-supported",
			    IPP_TAG_ZERO);
    if (attr)
      for (i = 0; i < ippGetCount(attr); i ++)
	debug_printf("Format: %s\n",
		     ippGetString(attr, i, NULL));
    else
      debug_printf("No formats\n");

    /* Clean up */
    ippDelete(response);
    httpClose(http);

----------

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
> 

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

[Michael Sweet]

Till,

On Oct 30, 2013, at 6:18 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> What is required from a GUI is that as soon as the user selects a
> printer for printing (or with the default printer when just opening the
> dialog) is that if the printer is such PPD-less queue, to poll the
> printer via IPP (code example below) to get its capabilities, show the
> user-settable options on the dialog's option panel (like PPD options)
> and send the job accompanied with the option settings, including the
> ones which the user has not changed and the ones which have only one
> choice (and so are not changeable). The job itself should be in PDF
> format and (if the printer supplies appropriate info) in a page size
> supported by the printer.

Till, I am curious why you are not using the CUPS APIs from 1.6 and later for this?

Also, I have my concerns of this approach - with cupsd not knowing anything about the printer, and with there being no way for a non-aware app to know what the printer's capabilities are, I foresee a lot of interoperability issues.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Till Kamppeter]

On 11/01/2013 03:48 PM, Michael Sweet wrote:
> Till,
> 
> On Oct 30, 2013, at 6:18 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> What is required from a GUI is that as soon as the user selects a
>> printer for printing (or with the default printer when just opening the
>> dialog) is that if the printer is such PPD-less queue, to poll the
>> printer via IPP (code example below) to get its capabilities, show the
>> user-settable options on the dialog's option panel (like PPD options)
>> and send the job accompanied with the option settings, including the
>> ones which the user has not changed and the ones which have only one
>> choice (and so are not changeable). The job itself should be in PDF
>> format and (if the printer supplies appropriate info) in a page size
>> supported by the printer.
> 
> Till, I am curious why you are not using the CUPS APIs from 1.6 and later for this?
> 

Which new CUPS APIs do you mean?

> Also, I have my concerns of this approach - with cupsd not knowing anything about the printer, and with there being no way for a non-aware app to know what the printer's capabilities are, I foresee a lot of interoperability issues.

What alternative would there be without waking up the printer when the
mobile device enters the WLAN?

   Till

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

[Michael Sweet]

Till,

On Nov 1, 2013, at 11:06 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> Till, I am curious why you are not using the CUPS APIs from 1.6 and later for this?
>> 
> 
> Which new CUPS APIs do you mean?

All of the new destination APIs, including:

    cupsConnectDest
    cupsCopyDestInfo
    cupsEnumDests

> ...
> What alternative would there be without waking up the printer when the
> mobile device enters the WLAN?

Don't create queues until you use/select a printer.  Trying to shoe-horn the former 1990's CUPS browsing experience just exposes the problems with that browsing experience in 2013.

A create-on-first-use approach allows you to list (but not wake up) local printers. And then the queue you create can be full-function, wake up the printer you are about to print to it, etc.
 
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Till Kamppeter]

On 11/01/2013 03:48 PM, Michael Sweet wrote:
> Till,
> 
> On Oct 30, 2013, at 6:18 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> What is required from a GUI is that as soon as the user selects a
>> printer for printing (or with the default printer when just opening the
>> dialog) is that if the printer is such PPD-less queue, to poll the
>> printer via IPP (code example below) to get its capabilities, show the
>> user-settable options on the dialog's option panel (like PPD options)
>> and send the job accompanied with the option settings, including the
>> ones which the user has not changed and the ones which have only one
>> choice (and so are not changeable). The job itself should be in PDF
>> format and (if the printer supplies appropriate info) in a page size
>> supported by the printer.
> 
> Till, I am curious why you are not using the CUPS APIs from 1.6 and later for this?
> 

AFAIR The cupsEnumDests() function is not passing on all needed
information, especially not the TXT record which contains important info
like the printer's PDLs. It also lists only local and remote CUPS queues
and not my IPP network printers (is it restricted to input formats, like
PDF? Or IPP Everywhere/PWG Raster?). For only doing the original task of
cups-browsed, creating local queues pointing to remote CUPS queues to be
able to easily print on these remote printers from the current
applications cupsEnumDests() would even work.

Another question is whether cupsEnumDests() can run in parallel with
other, independent services, in my case Tim Waugh's backward
compatibility CUPS browsing/broadcasting.

> Also, I have my concerns of this approach - with cupsd not knowing anything about the printer, and with there being no way for a non-aware app to know what the printer's capabilities are, I foresee a lot of interoperability issues.

The problem of this kind of queues is really that if an application is
not aware of them, it prints (if the app sends PDF it actually prints,
as the correct filter chain is called) on them but with unsatisfying
results do to not knowing enough of the printer.

They work only to their full extent if the app is aware of them and
polls the capabilities record of the printer via IPP. And this record
cannot be polled by cups-browsed already as then entering the network
with a mobile device can wake up all printers from power saving mode,
some models even getting noisy then.

Any suggestion for a better implementation of this scenario is welcome.

   Till

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

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Tue, 2013-11-12 at 23:23 +0100, Till Kamppeter wrote:
> Another question is whether cupsEnumDests() can run in parallel with
> other, independent services, in my case Tim Waugh's backward
> compatibility CUPS browsing/broadcasting.

It isn't meant to. The BrowsePoll and Browsing(send) support is for
legacy sites, and Browsing(recv) is a stop-gap until all the dialogs use
cupsEnumDests() or the equivalent. For GTK+, it uses its own
implementation (as cupsEnumDests is blocking -- Mike, please stop
writing blocking interfaces ;-) ). For Qt, I've written a patch to use
cupsEnumDests():
https://bugzilla.redhat.com/show_bug.cgi?id=980952

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Michael Sweet]

Tim,

WRT GTK+ and blocking APIs in general, it is really really hard to get away from blocking behavior when you are dealing with networking.  The strategy we opted for was to support timeouts and asynchronous cancellation of blocking/semi-blocking calls so that applications and toolkits can wrap those calls appropriately.

Ideally everyone would adopt Grand Dispatch (patches were provided to the GCC folks a long time ago) which essentially adds singletons (blocks) to C/C++/ObjC along with lighter-weight threads and basic scheduling queues (async for running blocks on parallels threads and sync for serializing a series of blocks on a particular thread).  This greatly simplifies thread management and offers a compelling replacement for callback functions, thus the support in libcups for them…

But in the meantime, GTK+ and others should be doing printer discovery and queries on a separate thread from the main thread, otherwise they WILL block even if every API CUPS provided was “non-blocking” - networks are unpredictable.

For the record, we *did* consider making cupsGetDests run a background thread doing the equivalent of cupsEnumDests so that callers would get a current snapshot of the available printers.  However, doing it without having the application “opt in” would cause a lot of problems for programs like Firefox that think it is OK to unload a dynamic library like libcups that is not designed for such use (few are), and providing an opt-in method (cupsStartEnumDests or something like that) isn’t much better - code changes are still required, so why not just use the new API in the first place?


On Nov 13, 2013, at 5:38 AM, Tim Waugh <twaugh@redhat.com> wrote:

> On Tue, 2013-11-12 at 23:23 +0100, Till Kamppeter wrote:
>> Another question is whether cupsEnumDests() can run in parallel with
>> other, independent services, in my case Tim Waugh's backward
>> compatibility CUPS browsing/broadcasting.
> 
> It isn't meant to. The BrowsePoll and Browsing(send) support is for
> legacy sites, and Browsing(recv) is a stop-gap until all the dialogs use
> cupsEnumDests() or the equivalent. For GTK+, it uses its own
> implementation (as cupsEnumDests is blocking -- Mike, please stop
> writing blocking interfaces ;-) ). For Qt, I've written a patch to use
> cupsEnumDests():
> https://bugzilla.redhat.com/show_bug.cgi?id=980952
> 
> Tim.
> */
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Michael Sweet]

Till,

On Nov 12, 2013, at 5:23 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> AFAIR The cupsEnumDests() function is not passing on all needed
> information, especially not the TXT record which contains important info
> like the printer's PDLs.

Keep in mind that the TXT record often only provides a subset of the supported values; once you actually decide to use a printer you need to query the document-format-supported attribute, which you can already do with the new APIs.

> It also lists only local and remote CUPS queues
> and not my IPP network printers (is it restricted to input formats, like
> PDF? Or IPP Everywhere/PWG Raster?). For only doing the original task of
> cups-browsed, creating local queues pointing to remote CUPS queues to be
> able to easily print on these remote printers from the current
> applications cupsEnumDests() would even work.

Currently we require printers to support PDF to support direct printing.  The next feature release of CUPS will be adding support for “temporary” print queues, at which point I will “throw the switch” to allow PWG Raster printers to be shown as well.  Printing to such a queue will cause a local (temporary) print queue to be created and used to print to the corresponding printer.

> Another question is whether cupsEnumDests() can run in parallel with
> other, independent services, in my case Tim Waugh's backward
> compatibility CUPS browsing/broadcasting.

There is no reason it can’t, the main thing you’ll need to do is suppress duplicates.

>> Also, I have my concerns of this approach - with cupsd not knowing anything about the printer, and with there being no way for a non-aware app to know what the printer's capabilities are, I foresee a lot of interoperability issues.
> 
> The problem of this kind of queues is really that if an application is
> not aware of them, it prints (if the app sends PDF it actually prints,
> as the correct filter chain is called) on them but with unsatisfying
> results do to not knowing enough of the printer.
> 
> They work only to their full extent if the app is aware of them and
> polls the capabilities record of the printer via IPP. And this record
> cannot be polled by cups-browsed already as then entering the network
> with a mobile device can wake up all printers from power saving mode,
> some models even getting noisy then.

Thus my point about not adding the printer queue until you actually need to use it. Browse to discover, add a local queue as needed to print to it (at which time it is OK to wake the printer up with a direct query…)

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Till Kamppeter]

On 11/15/2013 05:14 PM, Marek Kasik wrote:
> Hi all,
> 
> just an update. I'm working on the problem of waking avahi printers up
> in gtk print dialog. It will show just name, location and state when the
> printer is not selected but once it is selected it will perform an IPP
> request to get its abilities.
> 
> Regards
> 
> Marek

OK, this is how I imagined it should be.

   Till

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

[Till Kamppeter]

Marek, thank you for the patch.

Mike, should printer status (for example Paused) not be in the TXT
record or somewhere else in the Bonjour broadcast, so that a client can
determine the status without further query?

   Till

On 11/20/2013 05:01 PM, Marek Kasik wrote:
> Hi,
> 
> I've filled bug for the waking of Avahi printers up here:
> https://bugzilla.gnome.org/show_bug.cgi?id=712751 .
> Unfortunately the print dialog doesn't show state of such printers
> before user selects them because I don't have information about paused
> state (e.g. through "printer-state-reasons") of the printer in TXT records.
> 
> Regards
> 
> Marek
> 
> 
> On 11/15/2013 05:14 PM, Marek Kasik wrote:
>> Hi all,
>>
>> just an update. I'm working on the problem of waking avahi printers up
>> in gtk print dialog. It will show just name, location and state when the
>> printer is not selected but once it is selected it will perform an IPP
>> request to get its abilities.
>>
>> Regards
>>
>> Marek
> 

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

[Michael Sweet]

Marek,

Generally speaking, I don’t recommend showing the printer status in the chooser since that is a discovery/selection step. A busy or offline printer status is temporary, so it probably isn’t a criteria for a user picking a particular printer.  A printer that is truly “down” will not be browsable.

FWIW, I *do* think it is appropriate to show the status once a printer is selected (including the number of jobs in queue), and to update the status when it changes.


On Nov 20, 2013, at 11:01 AM, Marek Kasik <mkasik@redhat.com> wrote:

> Hi,
> 
> I've filled bug for the waking of Avahi printers up here:
> https://bugzilla.gnome.org/show_bug.cgi?id=712751 .
> Unfortunately the print dialog doesn't show state of such printers
> before user selects them because I don't have information about paused
> state (e.g. through "printer-state-reasons") of the printer in TXT records.
> 
> Regards
> 
> Marek
> 
> 
> On 11/15/2013 05:14 PM, Marek Kasik wrote:
>> Hi all,
>> 
>> just an update. I'm working on the problem of waking avahi printers up
>> in gtk print dialog. It will show just name, location and state when the
>> printer is not selected but once it is selected it will perform an IPP
>> request to get its abilities.
>> 
>> Regards
>> 
>> Marek
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Michael Sweet]

Till,

The printer status does not belong in the TXT record.  TXT records and service registrations are used for discovery, not for conveying state.

See my other message to Marek for more info…


On Nov 20, 2013, at 11:09 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:

> Marek, thank you for the patch.
> 
> Mike, should printer status (for example Paused) not be in the TXT
> record or somewhere else in the Bonjour broadcast, so that a client can
> determine the status without further query?
> 
>   Till
> 
> On 11/20/2013 05:01 PM, Marek Kasik wrote:
>> Hi,
>> 
>> I've filled bug for the waking of Avahi printers up here:
>> https://bugzilla.gnome.org/show_bug.cgi?id=712751 .
>> Unfortunately the print dialog doesn't show state of such printers
>> before user selects them because I don't have information about paused
>> state (e.g. through "printer-state-reasons") of the printer in TXT records.
>> 
>> Regards
>> 
>> Marek
>> 
>> 
>> On 11/15/2013 05:14 PM, Marek Kasik wrote:
>>> Hi all,
>>> 
>>> just an update. I'm working on the problem of waking avahi printers up
>>> in gtk print dialog. It will show just name, location and state when the
>>> printer is not selected but once it is selected it will perform an IPP
>>> request to get its abilities.
>>> 
>>> Regards
>>> 
>>> Marek
>> 
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Till Kamppeter]

Some days ago, I have released cups-filters 1.0.43. It improves a lot on
PPD-less printing:

- PPD-less PCL 5c/e printing with rastertopclx, in grayscale and color
- PPD-less PostScript printing with pdftops, duplex, resolution, input
  tray, color mode, and make/model (for quirk rules) can now be
  supplied by the command line
- pdftoippprinter switches to Poppler-based pdftoraster if Ghostscript
  is not present, eliminating need of Ghostscript for PPD-less printing
- gstoraster and pdftoraster are capable to output PWG Raster
- Support unprintable margins supplying them on the command line via
  "media-left-margin", "media-right-margin", "media-bottom-margin", and
  "media-top-margin" (in 1/100th of a mm).
- Handle options duplex/sides, fit-to-page/fitplot, orientation-
  requested/landscape correctly when printing PPD-less
- A lot of bug fixes.

I also had to fix a bug in Poppler, see

https://bugs.freedesktop.org/show_bug.cgi?id=72312

This should allow PPD-less printing on most supported printers now. Bug
reports and patches are welcome.

   Till

On 10/30/2013 11:18 AM, Till Kamppeter wrote:
> Hi,
> 
> I have now done a first implementation of my concept of PPD-less
> printing on IPP network printers (see below). It is implemented in the
> cups-filters 1.0.41 package which I have released today.
[...]