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

From: Michael Sweet <[email-masked]>
Date: Mon, 02 Jun 2014 09:52:25 -0400

Ira,

On May 23, 2014, at 11:21 AM, Ira McDonald <[email-masked]> wrote:
> Hi Smith,
> 
> Actually, the Printer doesn't have to bind values to "xxx-actual" until the Job
> completes.
> 
> This reply is not about 'guaranteed'.
> 
> This reply is about the usability of 'attempted'.
> 
> An IPP Client could use Validate-Job with "document-format" and "pdl-override" and,
> when it receives the response that says ignored or substituted, examine the values 
> of "preferred-attributes" (from JPS3, PWG 5100.13-2012) to find out the extent to 
> which the Printer *could* and *could not* successfully 'attempt' to do the overrides.

Well, if a Client sends "ipp-attribute-fidelity" (not "pdl-override"), then Validate-Job needs to respond just like Create-Job/Print-Job/Print-URI.  So in that case "preferred-attributes" doesn't enter into the picture.

Instead, the Client would need to *omit* "ipp-attribute-fidelity" to see which overrides are supported.  Then you'll get the unsupported attributes/values and potentially the ones that would be used instead.

Based on my own experience, I'm not sure how useful/reliable this method would be, but we can certainly document it.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Mon, 2 Jun 2014 10:07:42 -0400

Hi Mike,

Right - what I (poorly expressed) meant to say was that with Validate-Job
and "pdl-override" of 'attempted' and specific "document-format" sent along
with whatever Job processing attributes, the IPP Client could query to see
how well the *attempt* would actually succeed (i.e., the extent of override
support for that specific document format).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Jun 2, 2014 at 9:52 AM, Michael Sweet <[email-masked]> wrote:

> Well, if a Client sends "ipp-attribute-fidelity" (not "pdl-override"),
> then Validate-Job needs to respond just like
> Create-Job/Print-Job/Print-URI.  So in that case "preferred-attributes"
> doesn't enter into the picture.
>
> Instead, the Client would need to *omit* "ipp-attribute-fidelity" to see
> which overrides are supported.  Then you'll get the unsupported
> attributes/values and potentially the ones that would be used instead.
>
> Based on my own experience, I'm not sure how useful/reliable this method
> would be, but we can certainly document it.
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 02 Jun 2014 10:44:51 -0400

Ira,

One of the other issues that I forgot to mention is that there is currently no way for a printer to indicate attributes that might not be supported.  For example, you might send a Validate-Job operation that specifies duplex output, and that might ordinarily be honored *except* if a particular PDL override was embedded in the document data.  In that case, there is no way for the Printer to respond definitively to the Validate-Job request.

But in most cases the PDL override question is moot: either the Client is generating the PDL or is providing an existing document file in a format (PDF, JPEG, etc.) that generally does not contain embedded PDL commands for output intent.  PostScript is probably the only PDL that was commonly shared and sent to a printer that can contain output indent (via setpagedevice), typically to set media size, duplex mode, and copies, and its use has been steadily replaced by PDF over the years as the document interchange format of choice.

So like I said, probably worth a mention but I wouldn't want to spend a lot of time trying to "fix" this.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 2 Jun 2014 11:00:22 -0400

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.

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.

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.

Cheers,
- Ira

On Mon, Jun 2, 2014 at 10:44 AM, Michael Sweet <[email-masked]> wrote:

> Ira,
>
> One of the other issues that I forgot to mention is that there is
> currently no way for a printer to indicate attributes that might not be
> supported.  For example, you might send a Validate-Job operation that
> specifies duplex output, and that might ordinarily be honored *except* if a
> particular PDL override was embedded in the document data.  In that case,
> there is no way for the Printer to respond definitively to the Validate-Job
> request.
>
> But in most cases the PDL override question is moot: either the Client is
> generating the PDL or is providing an existing document file in a format
> (PDF, JPEG, etc.) that generally does not contain embedded PDL commands for
> output intent.  PostScript is probably the only PDL that was commonly
> shared and sent to a printer that can contain output indent (via
> setpagedevice), typically to set media size, duplex mode, and copies, and
> its use has been steadily replaced by PDF over the years as the document
> interchange format of choice.
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 02 Jun 2014 11:29:34 -0400

Ira,

> useless, because the degree of override supported in a given PDL

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.

> 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

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.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 2 Jun 2014 11:45:38 -0400

Hi Mike,

Right - Of course there is no job template attribute for "pdl-override".

There is an "overrides (1setOf collection)" attribute with the specific
job processing instructions to use for forced override.

So my idea is that Validate-Job should tell you *which* of the "overrides"
values will be honored (with "ipp-attribute-fidelity" of 'true').  Why isn't
this useful?

Cheers,
- Ira

On Mon, Jun 2, 2014 at 11:29 AM, Michael Sweet <[email-masked]> wrote:

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

---

From: Michael Sweet <[email-masked]>
Date: Mon, 02 Jun 2014 12:05:58 -0400

Ira,

> job processing instructions to use for forced override.

The "overrides" attribute specifies the per-page/document override intent.

"ipp-attribute-fidelity" and "job-mandatory-attributes" are the attributes used to force the overrides (or whatever other intent is present in the Job Ticket).

> values will be honored (with "ipp-attribute-fidelity" of 'true').  Why isn't

First, you'd just get a binary result (OK or not supported) that in the case of pdl-override-supported='attempted' you might not be able to trust because the Printer may not be able to tell you whether the override can be honored until the document is processed.

Second, if a Printer actually supports the OPTIONAL "overrides" attribute for a given document format, I strongly suspect that "pdl-override-supported" will be 'guaranteed' for that format since 'attempted' would be rather weak for per-page/document overrides.

In any case, I think our focus should be on common cases where the Client might want to override basic PDL instructions: copies, media/media-col, print-color-mode, sides, etc.  I don't think we should waste cycles on improving things that were only added in IPP/1.0 to address the concerns of products that could not/cannot provide PDL override support for legacy document formats like PCL and PostScript.  There are hundreds of millions of operating IPP printers that will never be upgraded - we should document and acknowledge that, tell Clients to generate modern PDLs whenever possible and to match the output to the job ticket, and tell new Printers to support PDL override for those modern PDLs to enable consistent output.