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
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"
*any* value is not a useful IPP feature - and the Implementor's Guide
should warn IPP Client developers to avoid using it accordingly.
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 10:44 AM, Michael Sweet <msweet at apple.com> wrote:
>> 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
>> 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.
>>> On Jun 2, 2014, at 10:07 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> 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).
> - 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: 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 9:52 AM, Michael Sweet <msweet at apple.com> wrote:
>>>> On May 23, 2014, at 11:21 AM, Ira McDonald <blueroofmusic at gmail.com>
>>>> Hi Smith,
>>>> Actually, the Printer doesn't have to bind values to "xxx-actual" until
>> the Job
>>>> 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
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>-------------- next part --------------
An HTML attachment was scrubbed...