Hi Mike,
From: Michael Sweet <msweet at msweet.org>
Sent: Wednesday, March 3, 2021 1:22 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,
On Mar 3, 2021, at 1:10 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com<mailto:smith.kennedy at hp.com>> wrote:
Hi Mike,
From: Michael Sweet <msweet at msweet.org<mailto:msweet at msweet.org>>
Sent: Tuesday, March 2, 2021 1:13 PM
To: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com<mailto:smith.kennedy at hp.com>>
Cc: PWG IPP Workgroup <ipp at pwg.org<mailto: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.)
Ugh, it looks like MSN 2 lost this text from MSN 1:
5.1.4 For interchange between programs, the dimensions presented in this standard must never be converted to the another system of units, but must remain as defined in this standard. Furthermore, an identical size shall never appear in this standard with different units. Programs may convert the dimensions to other units when displaying these names to human users and for internal use, both of which are outside the scope of this standard.
[Smith K.] I filed an errata: https://www.pwg.org/dynamo/issues.php?U106
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).
So three notes:
1. CUPS-based systems (including Linux, macOS, and iOS) never use any localized media size names from the Printer
2. Windows 10's IPP class driver only supports well-known media sizes at present (where "well known" seems to be limited to standard office printer sizes) - yes, I've filed a bug report on it...
3. macOS (at least) groups media sizes by dimension, for example "US Letter" and "US Letter (Borderless)" while iOS and CUPS clients do no grouping.
[Smith K.] Understood. And it is up to the Client implementor to take advantage of message catalog provided strings or family information (or not). But there are other clients that do use the behavior I described, including HP vendor drivers for Windows and Android. We can do it with a vendor extension but I would prefer to not do that.
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”
"media-key" is a *unique* keyword for a combination of media-size, media-type, etc. "media-name" (the localized name) might be the same but I don't see any Client using it since (as I've noted previously) current Clients use the dimensions to lookup the corresponding localized name (even if it is a dimensional name like "4 x 6")
[Smith K.] I think we are talking about two different things: how the PWG has defined the members of the “media-col” collections to be used along with other facilities of IPP such as printer-resident message catalogs, and how some clients have been implemented to use those members and other IPP facilities. I don’t doubt your assertion that CUPS-based systems have been implemented to choose non-printer-resident strings based on “media-size” or “media-size-name” and ignore “media-key”. But is that how we in the PWG are intending “media-col-ready” and “media-col-database” to be used?
(I don’t see a “media-name” member registered with IANA or in 5100.7…)
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.
It isn't super clear in MSN2, but section 5.1.5 says:
The common usage of some names can represent several physical sizes, e.g., folio, quarto, foolscap, and executive. To avoid naming and sizing conflicts, a hyphenated identifier MUST be used to link the names to a specific size.
and then we define multiple sizes using the name prefix "photo", "index", "govt", "fanfold", etc. with "-extra" and "-tab" suffixes for many sizes as well.
Like I said, if those dimensional sizes are more widely used then there is precedence (just look at MSN2) for registering purely dimensional names, but if all we cared about was the dimensions we'd just use the media-size collection in media-col...
________________________
Michael Sweet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210303/c2adc30f/attachment.html>