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@hp.com> wrote:
> 
> Hi Mike,
>  
> From: Michael Sweet <msweet@msweet.org> 
> Sent: Tuesday, March 2, 2021 1:13 PM
> To: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy@hp.com>
> Cc: PWG IPP Workgroup <ipp@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.

> 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.

> 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")

> 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