Hi Mike,
From: Michael Sweet <msweet at msweet.org>
Sent: Tuesday, March 2, 2021 1:13 PM
To: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>
Cc: PWG IPP Workgroup <ipp at pwg.org>
Subject: Re: [IPP] IPP Registration Request for Addition: New keywords for the "media" attribute
Smith,
At first blush I see some duplicated sizes from the registry:
na_arch-c_18x24in
na_arch-d_24x36in
and the MSN2 spec doesn't allow those...
[Smith K.] I know we have in the past agreed to not register certain new media keywords because their dimensions were redundant with others already registered. The recent discussion about media “family” grouping has made me question that. (I’m also having a hard time finding the clauses in PWG 5101.1-2013 that mandates the “no size redundancy” restriction.)
If a Client were implemented to present supported media using a hierarchical system where families are grouped together (e.g. Architectural, Photo, etc.) and the Printer vendor wanted that Client to offer the user both an “Architectural C” in the Architectural family and a “Super C” in the Photo family, this would be impossible using only the “media-supported” attribute without the Client knowing a-priori that na_arch-c_18x24in should be shown in two different places and with two different strings (which the Client presumably provides since the Printer can only provide one localized string in its message catalog for a given keyword).
If the Client were implemented to use “media-col-database” rather than “media-supported”, the “media-key” value for the two variants could both use “na_arch-c_18x24in” and then I suppose the “Super C” could have some suffix on it (‘na_arch-c_18x24in_photo-super-c’) to make it unique, and that would then provide a unique key in the message catalog so it could have a different label. But we would still have no standard solution for the family problem, though.
Also, while I appreciate keeping the na_WIDTHxHEIGHT_WIDTHxHEIGHTin form for those dimensional sizes, if they are primarily for photo/art printing I'd like to see a 'photo' prefix in the name portion, e.g.:
oe_photo-16x20_16x20in
Similarly, the om_photo sizes should include the dimensions if there is no corresponding well-known name:
om_photo-300x400_300x400mm
[Smith K.] I don’t have a problem with this recommendation in principle, but I’d like to see it codified in an update to MSN2. Seeking information on the “oe_10x12_10x12in” and such – more soon.
> On Mar 2, 2021, at 12:29 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org<mailto:ipp at pwg.org>> wrote:
>> Greetings,
>> HP Inc. is requesting the registration of additional keywords for the “media” attribute [STD92] for some standard sizes that aren’t yet registered. Here is the registration template and the keywords to be added:
>> Attributes (attribute syntax)
> Keyword Attribute Value Reference
> -------------------------------------------------------- --------------
> media (type2 keyword | name(MAX)) [RFC8011]
> na_arch-e1_32x40in [HP20210302]
> na_super-c_18x24in [HP20210302]
> na_super-d_24x36in [HP20210302]
> oe_10x12_10x12in [HP20210302]
> oe_10x15_10x15in [HP20210302]
> oe_14x18_14x18in [HP20210302]
> oe_16x20_16x20in [HP20210302]
> oe_20x24_20x24in [HP20210302]
> oe_22x28_22x28in [HP20210302]
> oe_24x30_24x30in [HP20210302]
> om_photo_300x400mm [HP20210302]
> om_photo_300x450mm [HP20210302]
> om_photo_350x460mm [HP20210302]
> om_photo_400x600mm [HP20210302]
> om_photo_500x760mm [HP20210302]
> om_photo_600x900mm [HP20210302]
> media-supported (1setOf (type2 keyword | name(MAX))) [RFC8011]
> < all name values > [RFC8011]
>> Let me know if there are any issues.
>> 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://www.pwg.org/mailman/listinfo/ipp>
________________________
Michael Sweet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210303/75d2126b/attachment.html>