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
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
mailto: blueroofmusic at gmail.com
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 11:29 AM, Michael Sweet <msweet at apple.com> wrote:
>> 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
> 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"
> *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
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>-------------- next part --------------
An HTML attachment was scrubbed...