For soft-proof-icc-profile, would this be obviated by the proof operations
in Enterprise Print Extensions?
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.
Sean
On Thu, Apr 18, 2019 at 7:32 AM Ira McDonald via ipp <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>http://sites.google.com/site/highnorthinc> 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> wrote:
>>>>>>> On Apr 17, 2019, at 5:40 PM, Michael Sweet <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> 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/W969CG6xjxhMD2MKTK84n2?domain=ftp.pwg.org>
>>>>>>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/white-hp-ipp-custompqi-20190412.docx>> <https://protect-us.mimecast.com/s/iQcRCJ6AmAhY6gY3hGy9KW?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>>https://www.pwg.org/mailman/listinfo/ipp>> <https://protect-us.mimecast.com/s/CCdKCKrBnBFnXZnzc3PXr6?domain=pwg.org>
>>>>>> _____________
>> Michael Sweet
>>>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>
--
Sean Kau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190418/c7b800f2/attachment.html>