Smith,
> On Mar 3, 2021, at 5:51 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
> ...
> 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 we are using media-col-database, I would rather have another member attribute that provides the grouping information because modern clients use media-col-database/ready and *not* media-supported/media-ready (in order to get supported media types, sources, and margins).
> 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?
Yes.
The "media-size" member attribute is REQUIRED while "media-size-name" and "media-key" are just RECOMMENDED. The whole purpose of MSN size names was to formalize the syntax of keyword names so they were self-describing with "natural" dimensions, so that the "media" attribute would only specify the desired media size (and not the type or source). All legacy media values were deprecated with STD92, making media-col the only way to specify media size, type and source (via member attributes).
> (I don’t see a “media-name” member registered with IANA or in 5100.7…)
Sorry, "media-info" (RECOMMENDED).
________________________
Michael Sweet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210303/7e423fe5/attachment.sig>