attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Ira,<div><br><div><div>On Jun 2, 2014, at 11:45 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div><div><div><div><div>Hi Mike,<br><br></div>Right - Of course there is no job template attribute for "pdl-override".<br><br></div>There is an "overrides (1setOf collection)" attribute with the specific<br>
</div>job processing instructions to use for forced override.<br></div></div></div></blockquote><div><br></div>The "overrides" attribute specifies the per-page/document override intent.</div><div><br></div><div>"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).</div><div><br><blockquote type="cite"><div dir="ltr"><div>So my idea is that Validate-Job should tell you *which* of the "overrides" <br>values will be honored (with "ipp-attribute-fidelity" of 'true'). Why isn't<br>
this useful?<br></div></div></blockquote></div><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></body></html>