Subject: [IPP] NODRIVER: Seeking consensus on a solution for use cases 3.2.20 and 3.2.21

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 27 Mar 2020 12:56:52 +0000

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Paul Tykodi via ipp <[email-masked]>
Date: Fri, 27 Mar 2020 11:24:36 -0400

Hi Smith,

In the 3D Concrete Printing space, the print quality term is discussed in terms of creating a suitable object (i.e. has good quality) and the amount of time the concrete mix can be pumped (typically referred to as “open time”).

The following quote comes from “3D printing using concrete extrusion: A roadmap for research” https://www.sciencedirect.com/science/article/pii/S0008884617311924

“In parallel, the printability of the material is evaluated by printing a series of single filament stacks. Fig. 6a depicts this process for a test to evaluate flow stress on a cement paste containing a limestone powder. The print quality changes with time where t = 0 is when cement and water first come into contact. At 6 min after mixing, the yield stress of the mixture is too low to support the mass of the material deposited above. It develops until at 60 min, the material has reached a state where it is able to support multiple deposited layers. Continuing the test on this mix finds that the desirable behaviour is maintained through 80 min until at 99 min, the plastic viscosity has reached a point where pumping is difficult. This test can be used to determine the open time for a particular mix, which here was 37 min.”

If we are going to enhance the definition of print quality for 2D applications, we probably should determine how to define it more appropriately within our IPP 3D standard as well.

Thanks.

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked] <mailto:[email-masked]> 
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

This e-mail reply and any attachments are confidential and may be privileged.

If you are not the intended recipient, please notify Tykodi Consulting Services LLC 

immediately by replying to this message and destroying all copies of this message 

and any attachments. Thank you

From: ipp <[email-masked]> On Behalf Of Kennedy, Smith (Wireless & IPP Standards) via ipp
Sent: Friday, March 27, 2020 8:57 AM
To: PWG IPP WG Reflector <[email-masked]>
Subject: [IPP] NODRIVER: Seeking consensus on a solution for use cases 3.2.20 and 3.2.21

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.

 <https://tools.ietf.org/html/rfc2566#section-4.2.13> 4.2.13 print-quality (type2 enum)

 

 

 

 

 

Option 4: ???

 

Smith

/**
    Smith Kennedy
    HP Inc.
*/

---

From: Ira McDonald via ipp <[email-masked]>
Date: Fri, 27 Mar 2020 16:37:44 -0400

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/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
(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 <[email-masked]> 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:
>
> 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.
>
> 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 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: ???
>
>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Sat, 28 Mar 2020 11:35:19 -0400

I've created a wiki page to summarize everything we've talked about over the last several weeks:

    https://github.com/istopwg/ippsample/wiki/IPP-Print-Quality-Discussion

The wiki page also includes some potential member attributes of the proposed "print-quality-col" attribute.

....

All this said, while I can clearly see the benefit of providing a way to expand print-quality beyond the current 3 levels (which is why I had proposed a percentage), the vendor quality modes don't offer the same clear choices/benefits for me.

What I'd like to see it a focus on qualitative intent for the user ("I want the best output from the printer") vs. vendor process ("Use vendor mode XYZ") since the former is something that a generic print Client can support and present to the End User in an unambiguous way while the vendor print options tend to be, um, a bit more esoteric in their implementation and usage.  (I'm trying hard not to offend anyone!)

When there is a vendor print mode ("Vivid Color", "Eco Draft"), that would seem to be better served by a "job-presets" collection combined with vendor Job Template attributes and/or keyword values - doing this as a print quality mode doesn't seem to be a good fit.

When there is a choice in processing algorithms (quick/fast vs. slow/precise) for things like scaling and sampling of images, color transforms, color gamut, etc. then the End User should be able to pick them as "advanced settings".  But IMHO most users want to pick a relative quality and have the printer/driver make those choices for them.

> On Mar 27, 2020, at 4:37 PM, Ira McDonald via ipp <[email-masked]> wrote:
> 
> Hi Smith,
> 
> On Fri, Mar 27, 2020 at 8:57 AM Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked]> 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). I want to see if we can hash this out via email in between meetings.
> 
> 4.2.13 print-quality (type2 enum)
> 
> 

________________________
Michael Sweet