[Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Till Kamppeter]

Hi,

on today's OpenPrinting conference call Ira told that first IPP 
Everywhere printers will get available on the market.

I am thinking about use of IPP Everywhere printers with Linux. There are 
two questions:

1. How to print from a Linux machine to an IPP Everywhere printer?
------------------------------------------------------------------

The intention of IPP Everywhere printers is that they get available to 
clients without any client-side configuration or driver. Now ho am I 
supposed to implement this on a Linux machine so that the available IPP 
Everywhere printers appear in the print dialogs (GTK, Qt, LibreOffice) 
of the applications and the user-settable options for the printers get 
shown in the dialog? Am I supposed to set up a CUPS queue? Do I have to 
generate a PPD file somehow (or is CUPS providing a virtual PPD file)? 
Or is it the full responsibility of the print dialog (no CUPS daemon 
needed) to browse the printer's Bonjour broadcasts, to read out the 
options from the IPP attributes and display the appropriate options? 
Probably I will need a local CUPS queue so that the application's PDF 
goes through pdftopdf and if the printer is not a PDF printer also 
through pdftoraster and rastertopwg? How do I tell to the CUPS queue to 
use these filters when it has no PPD file?


2. How to make a Linux CUPS server emulate IPP Everywhere?
----------------------------------------------------------

Another use case for IPP Everywhere is having a Linux machine running 
CUPS and with a conventional (non-IPP Everywhere) printer connected via 
network or USB and a CUPS queue with driver and PPD (HPLIP, Gutenprint, 
PostScript, etc.). Now I have a mobile device or TV set (Android, 
Windows Phone, ...) which supports printing on IPP Everywhere printers. 
How do I make CUPS emulate IPP Everywhere, so that the shared CUPS 
queues appear like IPP Everywhere printers? Or does CUPS do this already?

    Till

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Michael Sweet]

Till,

Responses inline...

On Jan 9, 2013, at 1:49 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> 1. How to print from a Linux machine to an IPP Everywhere printer?
> ------------------------------------------------------------------
> ...

Currently the only way to do this is to query the printer and generate a PPD file from the data. Then add the queue.  All of the generated PPDs should contain:

    *cupsFilter2: "application/vnd.cups-raster image/pwg-raster 100 rastertopwg"

Printers with PDF support should list:

    *cupsFilter2: "application/vnd.cups-pdf application/pdf 0 -"

Printers with JPEG support should list:

    *cupsFilter2: "image/jpeg image/jpeg 0 -"

I have this on my to-do list for CUPS, but thus far haven't had the time to write it...

> 2. How to make a Linux CUPS server emulate IPP Everywhere?
> ----------------------------------------------------------
> 
> Another use case for IPP Everywhere is having a Linux machine running CUPS and with a conventional (non-IPP Everywhere) printer connected via network or USB and a CUPS queue with driver and PPD (HPLIP, Gutenprint, PostScript, etc.). Now I have a mobile device or TV set (Android, Windows Phone, ...) which supports printing on IPP Everywhere printers. How do I make CUPS emulate IPP Everywhere, so that the shared CUPS queues appear like IPP Everywhere printers? Or does CUPS do this already?

CUPS already implements the required (and many of the optional) parts of IPP Everywhere, sans WS-Discovery (which really needs system-level support and I have 0 interest in implementing it...)  You just need to add the following to cupsd.conf to make the Bonjour registrations report the _print subtype:

    BrowseDNSSDSubTypes _cups,_print

Of course, without the WS-Discovery stuff your WinPhone won't be able to discover the printer, but AFAIK Microsoft has not yet implemented IPP Everywhere...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Till Kamppeter]

On 01/09/2013 08:53 PM, Michael Sweet wrote:
> Till,
>
> Responses inline...
>
> On Jan 9, 2013, at 1:49 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> 1. How to print from a Linux machine to an IPP Everywhere printer?
>> ------------------------------------------------------------------
>> ...
>
> Currently the only way to do this is to query the printer and generate a PPD file from the data. Then add the queue.  All of the generated PPDs should contain:
>
>      *cupsFilter2: "application/vnd.cups-raster image/pwg-raster 100 rastertopwg"
>
> Printers with PDF support should list:
>
>      *cupsFilter2: "application/vnd.cups-pdf application/pdf 0 -"
>
> Printers with JPEG support should list:
>
>      *cupsFilter2: "image/jpeg image/jpeg 0 -"
>
> I have this on my to-do list for CUPS, but thus far haven't had the time to write it...
>

For when this is planned? 1.7?


>> 2. How to make a Linux CUPS server emulate IPP Everywhere?
>> ----------------------------------------------------------
>>
>> Another use case for IPP Everywhere is having a Linux machine running CUPS and with a conventional (non-IPP Everywhere) printer connected via network or USB and a CUPS queue with driver and PPD (HPLIP, Gutenprint, PostScript, etc.). Now I have a mobile device or TV set (Android, Windows Phone, ...) which supports printing on IPP Everywhere printers. How do I make CUPS emulate IPP Everywhere, so that the shared CUPS queues appear like IPP Everywhere printers? Or does CUPS do this already?
>
> CUPS already implements the required (and many of the optional) parts of IPP Everywhere, sans WS-Discovery (which really needs system-level support and I have 0 interest in implementing it...)  You just need to add the following to cupsd.conf to make the Bonjour registrations report the _print subtype:
>
>      BrowseDNSSDSubTypes _cups,_print
>
> Of course, without the WS-Discovery stuff your WinPhone won't be able to discover the printer, but AFAIK Microsoft has not yet implemented IPP Everywhere...
>

In scheduler/conf.c is a line

   cupsdSetString(&DNSSDSubTypes, "_cups,_print");

Does this not mean that

   BrowseDNSSDSubTypes _cups,_print

is already set by default, not needing to set it in cupsd.conf?

    Till

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Michael Sweet]

Till,

On 2013-01-10, at 9:20 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> I have this on my to-do list for CUPS, but thus far haven't had the time to write it...
>> 
> 
> For when this is planned? 1.7?

Definitely not for 1.7 - I simply don't have the time to complete it.  And at some point in the (hopefully near) future it will be unnecessary since we'll have a "native" IPP Everywhere rendering pipeline that does not depend on PPDs.

I just created a cups.org bug to track this, since I didn't previous have one:

    http://www.cups.org/str.php?L4258

> ...
> In scheduler/conf.c is a line
> 
>  cupsdSetString(&DNSSDSubTypes, "_cups,_print");
> 
> Does this not mean that
> 
>  BrowseDNSSDSubTypes _cups,_print
> 
> is already set by default, not needing to set it in cupsd.conf?


Whoops, my bad.  Yes, I guess I already made that change... :)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Till Kamppeter]

On 01/10/2013 05:49 PM, Michael Sweet wrote:
>> ...
>> In scheduler/conf.c is a line
>>
>>   cupsdSetString(&DNSSDSubTypes, "_cups,_print");
>>
>> Does this not mean that
>>
>>   BrowseDNSSDSubTypes _cups,_print
>>
>> is already set by default, not needing to set it in cupsd.conf?
>
>
> Whoops, my bad.  Yes, I guess I already made that change... :)
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>

There is another thing missing in CUPS to make it emulating an IPP 
Everywhere printer: AFAIK CUPS does not accept PWG Raster as input 
format. There are no pwgto... filters, especially not pwgtopdf.

    Till

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Michael Sweet]

Till,

On 2013-01-27, at 10:09 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> There is another thing missing in CUPS to make it emulating an IPP Everywhere printer: AFAIK CUPS does not accept PWG Raster as input format. There are no pwgto... filters, especially not pwgtopdf.


While there currently are no PWG Raster to xyx filters, it is unlikely that they would be used since clients will almost certainly prefer sending PDF or JPEG (less work).

(but feel free to file a bug on cups.org and I'll add it to the list of things to do - PWG Raster to xyz will be super-easy)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Till Kamppeter]

On 01/28/2013 03:10 AM, Michael Sweet wrote:
> While there currently are no PWG Raster to xyx filters, it is unlikely that they would be used since clients will almost certainly prefer sending PDF or JPEG (less work).
>
> (but feel free to file a bug on cups.org and I'll add it to the list of things to do - PWG Raster to xyz will be super-easy)

Feature request added as

https://www.cups.org/str.php?L4266

    Till

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Till Kamppeter]

On 01/09/2013 08:53 PM, Michael Sweet wrote:
> Till,
>
> Responses inline...
>
> On Jan 9, 2013, at 1:49 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> 1. How to print from a Linux machine to an IPP Everywhere printer?
>> ------------------------------------------------------------------
>> ...
>
> Currently the only way to do this is to query the printer and generate a PPD file from the data. Then add the queue.  All of the generated PPDs should contain:
>
>      *cupsFilter2: "application/vnd.cups-raster image/pwg-raster 100 rastertopwg"
>
> Printers with PDF support should list:
>
>      *cupsFilter2: "application/vnd.cups-pdf application/pdf 0 -"
>
> Printers with JPEG support should list:
>
>      *cupsFilter2: "image/jpeg image/jpeg 0 -"
>
> I have this on my to-do list for CUPS, but thus far haven't had the time to write it...

I have seen in the source of the IPP backend that for PDF and all image 
formats the IPP attributes are carried on to the IPP printer. So this 
means that for PDF, JPEG, and PWG Raster the PPD simply needs to have 
the option and choice names being the ones of the IPP attributes 
reported back by the Get-Printer-Attributes request and no PostScript 
code needs to get assigned to the choices. Am I right? Will CUPS supply 
all atributes on the filter/backend command line then?

Another problem would be some PPD options where the Adobe specs impose 
certain option and choice names, like PageSize, InputSlot, Duplex, 
OutputBin, Resolution, ... How do I proceed with these options?

Can I "translate" the IPP attributes somehow into PostScript commands so 
that I can also generate PPDs for PostScript printers?

    Till

Re: [Printing-architecture] IPP Everywhere: How to make CUPS queue so that applications can use these printers

[Michael Sweet]

Till,

On 2013-01-28, at 4:20 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> I have seen in the source of the IPP backend that for PDF and all image formats the IPP attributes are carried on to the IPP printer. So this means that for PDF, JPEG, and PWG Raster the PPD simply needs to have the option and choice names being the ones of the IPP attributes reported back by the Get-Printer-Attributes request and no PostScript code needs to get assigned to the choices. Am I right? Will CUPS supply all atributes on the filter/backend command line then?

No, we only do that if the other end is another CUPS server.  Otherwise we map the core IPP Job Template attributes used for IPP Everywhere from the PPD options.  Look at the ppd-private.h header, specifically the PPD cache stuff, for inspiration.

Basically we map/pass-through:

    PageSize/PageRegion to media/media-col.media-size/media-xxx-margin
    InputSlot to media-col.media-source
    MediaType to media-col.media-type
    ColorModel to print-color-mode
    Duplex to sides
    OutputBin to output-bin
    cupsPrintQuality to print-quality
    copies
    finishings
    job-account-id, if cupsJobAccountId is in the PPD
    job-accounting-user-id, if cupsJobAccountingUserId is in the PPD
    job-password, if cupsJobPassword is in the PPD
    any IPP options listed in the cupsMandatory keyword in the PPD

> Another problem would be some PPD options where the Adobe specs impose certain option and choice names, like PageSize, InputSlot, Duplex, OutputBin, Resolution, ... How do I proceed with these options?

Proceed according to the Adobe requirements - the PPD cache maps to/from Adobe names.

> Can I "translate" the IPP attributes somehow into PostScript commands so that I can also generate PPDs for PostScript printers?


That may prove tricky since a) most IPP printers do not support PDL override for PostScript, and b) the PostScript commands for a printer are likely different than the commands needed for Ghostscript/xxxtoraster to generate PWG Raster data.

For now, at least, I would focus on a) determining whether a printer supports IPP Everywhere and b) using the standard IPP Everywhere formats (i.e. NOT PostScript) when that is the case.  If the printer doesn't support IPP Everywhere then you should probably gracefully fall back to doing the legacy driver dance.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair