Smith,
> On Mar 9, 2021, at 9:25 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>> ...
>> 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))?
I think "media-group" (or "media-category") since "family" would imply the sizes are marketed together (like a family or series of printers) vs. the desired grouping of sizes. But I'd only want to add this if we had some idea that it would be supported by IPP Clients - otherwise why bother?
> ...
> 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?
You would localize the equivalent "media" keyword value, either from a "media-size-name" value or by looking up the printer's self-describing media size name (in media-supported) that corresponds to the dimensions of "media-size".
But like I said, no client that I am aware of uses the printer's strings file to lookup localized media names.
> ...
> 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.
media-key would allow for the combinations ("US Letter Borderless, Glossy Photo"), which a Client could lookup using the "media-key.value" string.
> 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.
I didn't bother because Clients don't use the printer's strings file to localize media sizes. This is because we've defined all of the common names that can be consistently localized for all printers by the client, have a common syntax that provides the dimensions, and because dimensional names provide the best user experience for uncommon sizes. Common photo sizes are a case in point - who knows that 8R refers to an 8x10" photo size?
> 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".
Because for finishing-template there is no standard for how the keywords are formed (beyond the simple enum keyword values), making localization with the printer's strings file desirable/the easy way out (otherwise you need to parse out the member attributes and their values to determine what the template does...)
________________________
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/20210310/d6aae021/attachment.sig>