[IPP] Potential errata/update for PWG Raster Format and/or IPP Everywhere specs

[IPP] Potential errata/update for PWG Raster Format and/or IPP Everywhere specs

[IPP] Potential errata/update for PWG Raster Format and/or IPP Everywhere specs

Michael Sweet msweet at apple.com
Mon Jun 2 15:29:34 UTC 2014


Ira,

On Jun 2, 2014, at 11:00 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> Hi Mike,
> 
> What I was trying to "fix" is that "pdl-override" of 'guaranteed' is largely
> useless, because the degree of override supported in a given PDL
> interpreter varies.

I think you mean 'attempted' here:

pdl-override-supported='guaranteed' means that the IPP Printer will guarantee it can override any PDL instructions with the IPP job ticket.  A Printer only reports this if it can do so, and I would expect printers to be able to do this for JPEG, PDF, and PWG Raster at a minimum.

pdl-override-supported='attempted' means that the IPP Printer will attempt to override any PDL instructions with the IPP job ticket.  It could see some printers report this for PWG Raster since they might not be able to rescale raster data for different media.

pdl-override-supported='not-attempted' means that the IPP Printer will not override any PDL instructions with the IPP job ticket. This is by far the most commonly reported value for PCL and PostScript printers.

> So the IPP Client (sending document data that it did NOT generate but
> that MAY contain job processing instructions) could use 'attempted' to
> learn what is ?safe? to try to override.

The Client will never use 'attempted'.  That is a Printer capability that the Client can discover via Get-Printer-Attributes. There is no "pdl-override" Job Template attribute.

A Client can specify ipp-attribute-fidelity='true' or job-mandatory-attributes, and can expect either an outright error at submission time (Printer sees a Job Template attribute it cannot override and doesn't even try) or an error during processing leading to an aborted job (Printer sees something it can't override and reports the error).  And for a non-conforming Printer the job might even print without errors.

> If this problem isn't worth "fixing", then I suggest that "pdl-override" with
> *any* value is not a useful IPP feature - and the Implementor's Guide 
> should warn IPP Client developers to avoid using it accordingly.

Again, "pdl-override" is not a Job Template attribute.  It doesn't exist.

The guidance here should be to prefer JPEG, PDF, PWG Raster, and other well-defined file formats over legacy formats like PCL and PostScript, specifically because overrides are better supported and output is more consistent.  And in the same place we can offer a warning/note about legacy PDLs - they are printer specific and often need the output intent embedded in them vs. as IPP Job Template attributes.

We should probably also provide guidance to Printer implementations (and I think we already have this) on what value(s) to report for "pdl-override-supported" and how to deal with attributes that cannot be overridden.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140602/5349926a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140602/5349926a/attachment.p7s>


More information about the ipp mailing list