Hi Smith,
I prefer Option 3 "print-quality-col". Lots of precedent in tricky
bits of IPP and still extensible. I agree that any single simple
new attribute (such as "print-quality-percent") won't be a good
solution.
To respond to Paul's comment about 3D Printing, I think that
the "print-quality-col" solution would be the only acceptable
one.
Question. Would we encourage implementors to support
*both* "print-quality" and "print-quality-col" (simultaneously
present)? Because there's a huge legacy of "print-quality"
implementation.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
(to 30 April 2020) 203 W Oak St Ellettsville, IN 47429 812-876-9970
On Fri, Mar 27, 2020 at 8:57 AM Kennedy, Smith (Wireless & IPP Standards)
via ipp <ipp at pwg.org> wrote:
> Greetings,
>> In the last review of IPP Driverless Printing Extensions v2.0, concerns
> were once again raised about extending the set of enum values for
> "print-quality" to solve the "Manufacturer-Deployed Print Quality Mode" and
> "Administrator-Deployed Print Quality Mode" use cases (3.2.20 and 3.2.21 in
> the 20200204 published draft
> <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v20-20200204.pdf>).
> I want to see if we can hash this out via email in between meetings.
>> Before we dive into the implementation choices, I want to focus on the use
> cases and the user experience(s) we want to support. The use cases I have
> articulated are important to HP, and I have to believe that they are also
> important to other printer vendors.
>> The "print-quality" attribute as defined originally in IPP/1.0 (RFC 2566)
> has remained unchanged for over 20 years:
>> 4.2.13 <https://tools.ietf.org/html/rfc2566#section-4.2.13> print-quality (type2 enum)
>> This attribute specifies the print quality that the Printer uses for
> the Job.
>> The standard enum values are:
>> Value Symbolic Name and Description
>> '3' 'draft': lowest quality available on the printer
> '4' 'normal': normal or intermediate quality on the printer
> '5' 'high': highest quality available on the printer
>>> Since semantically there is a linear progression from "draft" to "normal"
> to "high", a "Print Quality" UI selection control could be presented as a
> slider, or more generically as a radio button group or a pop-up or table
> list, where only one option can be chosen. The ordering of the three
> choices is clear and common sense dictates that they should be presented in
> order rather than out-of-order.
>> Unfortunately, though, this long-standing definition doesn't provide for
> the possibility that the Printer supports more than 3 quality levels. Nor
> does it provide space for vendor-defined or site-defined levels, which have
> existed for quite some time, but always been described in terms of
> vendor-unique attributes or via legacy (non-IPP) mechanisms. I strongly
> believe that we need to find a way to allow printers to express their
> additional print quality options in a way that allows simpler UIs to
> maintain their simplicity but still allows access to these printer-provided
> non-standard print quality levels.
>> So, my questions are these:
>> 1. Are there any specific objections to these use cases? I believe these
> are important to all printer manufacturers, not just HP, as a way of
> expressing an important vector of product differentiation without having to
> adopt vendor-unique or site-unique attributes, which many universal clients
> ignore. This undermines efforts to move away from model-specific drivers.
>>> 2. Assuming agreement with the use cases, if we had a green field / blank
> sheet of paper, how to support the use cases in IPP?
>> Option 1: Extend "print-quality" as per the current proposal
>>> Option 2: "print-quality-percent" as per Mike's proposal, which I don't
> think adequately addresses the use cases
>>> Option 3: Define a new "print-quality-col", which could contain a
> "print-quality-percent" but could also have printer-provided localized
> labels and tooltips.
>>> Option 4: ???
>>> Please share your thoughts and feedback!
>>> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200327/f9b55568/attachment.html>