I think that there is a misunderstanding about what we are trying to do with
the Media Name Standard. Yes, we call the tokens that we are defining using
the term "names" which suggests that they could be displayed directly to a
user.
I had suggested that they were really keywords, not names. But we agreed
not to change the terminology. I would expect that a client is supposed to
localize these tokens for the user as for any keyword. The client is not
supposed to just blindly display them to the user. In the case of the Media
Size Self Describing Names, the client should split up the Size Name part
(na-letter) from the Dimensions part (8500-11000). We changed the syntax to
use the "." to make it easier for the client to parse. Any client that
simply displays the Media Size Self Describing Name as is, is being very
lazy. The client should do the scaling and show the dimension values in a
more user friendly way, i.e., 8.5 x 11 inches.
Therefore, I do not see any problem with the '.' syntax to separate the Size
Name from the Dimensions part.
There are two simple client implementations:
a. Just lookup the entire Media Size Self Describing Name in a localization
data base as with any keyword. There is no parsing to be done. Just
display the string that comes back. For English language and English units,
the 'na-letter.8500-11000' value would come back from the localization data
base as something like: 'North American letter - 8.5 x 11 inches'
b. Parse the name, scale the units and display the Size Name (na-letter)
separate from the Dimensions (8.5 x 11 inches).
Perhaps we need some kind of a note to say that we are using the term
"name", but expect that a client will localize these Names for display to
users.
Tom
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Thursday, April 19, 2001 16:11
To: rbergma at hitachi-hkis.com; hastings at cp10.es.xerox.com; ipp at pwg.org
Subject: Problem with dot separator in media list
The use of a dot between the media name and dimensions is a human factors
trap. Maybe the concatenated self-describing media name is not intended
for human consumption but it will certainly be consumed by developers and,
in some cases, if the application or driver can't make heads or tails of
the associated alias or legacy information, it may just paste up the self
describing string in the UI.
The problem is that some alias names end in numerals. Example,
na-a2.4375-5750. It's too easy to trip and think 2.4375 is a dimension!
This can be easily corrected by moving the dimension "type" indicator
adjacent to the units, themselves. Example:
na-a2.4375-5750 would become a2-na-4375-5750.
Also, if we made this change, we would not be overloading the use of "na"
(and it's absence to mean metric). For example:
iso-a4.2100-2970 would become iso-a4-mm-2100-2979.
A better solution would be to define a complete structure... a standard
DTD for media, where the units would be specified in the DTD rather than
in a self describing name. I will address the need for a complete DTD in a
separate note.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------