> On Apr 18, 2019, at 10:17 AM, Sean Kau <skau at chromium.org> wrote:
>> For soft-proof-icc-profile, would this be obviated by the proof operations in Enterprise Print Extensions?
They both have the word "proof" in them but they are different. Proof Printing is where you submit a multi-copy job, it prints one copy for you to inspect ("hard proof") before approving additional copies of it to be produced.
"Soft proofing" is a faithful attempt to emulate on-screen the exact layout and color production that will be produced on hardcopy. For unique color transformations, some way to represent that transformation on the Client will be needed to preview that transformation. We didn't want to mix up the ICC profiles for color management from "printer-icc-profiles" with this soft proofing use, so we decided to declare a new collection to isolate these ICC profiles.
>> Regarding UI suggestions, it would seem to make sense to include these recommendations in a separate document as they don't pertain specifically to the proposed attributes.
>> I'm concerned that adding vendor extensions to print-color-mode will significantly complicate client applications attempting to render previews of content as the behavior is predictable now. I would prefer to add a standard value for printer-color-mode that indicates we defer to an advanced setting for color.
I'm not sure I understand your alternative. That's actually what the "soft-proof-icc-profiles" is supposed to facilitate. But if clients don't want to support that feature, it is their choice.
>> Sean
>>>> On Thu, Apr 18, 2019 at 7:32 AM Ira McDonald via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
> Hi Smith,
>> Bit or arcana,
>> In Printer MIB and many other IETF MIBs, enum '1' is 'other' and '2' is 'unknown',
> so we avoid them for compatibility in IPP as a rule.
>> 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 <https://protect-us.mimecast.com/s/xLfSCDkr5rf2okXNtW4Olt?domain=sites.google.com>
>http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/eArdCERv5vsrlNBVFwxOow?domain=sites.google.com>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>> On Wed, Apr 17, 2019 at 9:41 PM Kennedy, Smith (Wireless & Standards Architect) via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
>>>> On Apr 17, 2019, at 5:40 PM, Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>> wrote:
>>>> Some quick comments:
>>>> 1. The tooltip stuff in strings files should be a separate Best Practice. Yes it will be mostly boilerplate... :(
>> OK. Can reference that from this doc.
>>>>> 2. print-color-mode-default: Drop
>> I'm interpreting this to mean to remove it from this document, since it is already defined in 5100.13?
>>>>> 3. print-color-mode-supported: Should be print-color-mode
>> I'm interpreting this to mean just relabel the sub-section to be "print-color-mode"?
>> FWIW, I've been struggling with a related stylistic concern. If one is defining an attribute, say that specifies a keyword type syntax, and there are standard keywords defined as well, should those standard keyword definitions be made in the "xxx-supported" or "xxx" subsection?
>>>>> 4. print-quality enum extensions: enums are not supposed to use values 1 and 2... :(
>> Hum - I always puzzled over that. Why is that? Whatever the reason, we need to capture the reason for that in our as-yet-to-be-started IPP Design Patterns document...
>>> Maybe we could look at a "print-quality-col (collection)" attribute with more details? Or define a separate range (10-19?) representing 10 different vendor-specific qualities?
>> I'd probably tend toward the latter since that attribute is already widely supported, and I don't know what other fields a "print-quality-col" might provide. Let's see if others have thoughts on that.
>>>>>>>>>> On Apr 17, 2019, at 2:10 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
>>>>>> Greetings,
>>>>>> I just posted a first draft of a "IPP Custom Print Quality and Intent Extensions
>>> (CUSTOMPQI)" white paper that proposes some additions to IPP that relate to supporting print quality hint and settings additions.
>>>>>>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/white-hp-ipp-custompqi-20190412.pdf <https://protect-us.mimecast.com/s/s2WtCG6xjxhxBQwKhpnQng?domain=ftp.pwg.org>
>>>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/white-hp-ipp-custompqi-20190412.docx <https://protect-us.mimecast.com/s/JyXrCJ6AmAhGBDx3cLmc7W?domain=ftp.pwg.org>
>>>>>> We won't likely have time to review it at our April 2019 F2F in a session, but I encourage those at the F2F to take a look at it so we can discuss after hours, etc. if you have an interest in what it proposes.
>>>>>> Cheers,
>>> Smith
>>>>>> /**
>>> Smith Kennedy
>>> HP Inc.
>>> */
>>>>>> _______________________________________________
>>> ipp mailing list
>>>ipp at pwg.org <mailto:ipp at pwg.org>
>>>https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/wT06CKrBnBFgDGLzFpKToM?domain=pwg.org>
>>>> _____________
>> Michael Sweet
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/wT06CKrBnBFgDGLzFpKToM?domain=pwg.org>
> _______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/wT06CKrBnBFgDGLzFpKToM?domain=pwg.org>
>>> --
> Sean Kau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190418/06fe5f2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190418/06fe5f2e/attachment.sig>