Hi Mike,
I'm going to get back to the new media keywords in a separate response, but it seems like there are some issues here that need resolution. More below
Smith
> On Mar 3, 2021, at 4:08 PM, Michael Sweet <msweet at msweet.org> wrote:
>> 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).
Agreed. So "media-family" (name(MAX)) or "media-group" (name(MAX))?
>>> 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.
OK, and I don't dispute this.
But let's say that a Printer supports a number of standard media sizes, and the Printer's manufacturer wanted to support some vendor-unique media sizes, and provide localized labels / names for these. If the Printer only provided "media-size", like the example from page 43 of 5100.7-2019, what value from the media-col collection would a Client be expected to use as the key to locate the appropriate string in the message catalog?
media-col-database={
/* Vendor size */
media-size={
x-dimension=22000
y-dimension=22700
}
media-source='auto'
media-type='stationery'
}
It seems that the Printer would need to provide "media-size-name" or "media-key" if the string were to be acquired from the IPP Message Catalog, and could provide both. But which member would the Client be expected to use as its key? Should the Printer provide the same strings for both keys? It seems like 5100.7 needs some guidance on this. The "finishing-template" member of "finishings-col" is the obvious (and required) member for finishings, but we don't seem to have this for "media-col".
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210310/053e9e2d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210310/053e9e2d/attachment.sig>