- From: Lofton Henderson <lofton@rockynet.com>
- Date: Mon, 15 Dec 2008 18:49:28 -0700
- To: WebCGM WG <public-webcgm-wg@w3.org>
Hi WebCGM WG -- [...please see my questions, after "Proposed response"...the latter is what we roughly discussed and agreed to in telecons...] This is one of a series about the six I18N comments. Although I18N sent a separate message for each of their comments -- which is how we should reply to I18N -- all comments are conveniently found in a single table [1]. All comments apply to 9.3.2.2, the ACI mapList element [2] [1] http://www.w3.org/International/reviews/0811-webcgm/ [2] http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Config.html#ACI-maplist In this message, I have proposed a response. Email discussion welcome. We will resolve definitely in a WG teleconference ("as proposed" if no discussion). I18N labels Comments #5 pertains to normalization of font names and font-name lists. It is labelled Substantive by I18N. Comment #5 ===== "These normalization rules are applicable for font names specified using the characters of ISOLatin1. They will likely be inapplicable for font names specified using other non-Latin characters." What happens in the case of Latin-2 (Eastern Europe), which is similar to Latin1 but contains a few additional characters. Does a single non-Latin1 character cause normalization to be abandoned for the whole string? It seems like the only thing that wouldn't apply to all non-Latin1 font names is converting to lower-case, though that is still a relevant consideration for many other Latin characters outside Latin1, and for Armenian, Greek and Cyrillic. Why restrict to Latin1? Proposed response: ---------- The apparent restriction to Latin 1 was unintended. As you point out, the normalization would work nearly the same if the same names were expressed in Latin 2. Latin 1 got the special mention because: the default character encoding of WebCGM is ISO 8859-1; and the vast majority of current and legacy WebCGM instances use this character encoding and a restricted core set of thirteen specific font names. As pointed out in WebCGM's reply to I18N's issue #3 (@@link@@), these WebCGM-specific normalization rules were targeted at the substantial legacy and current metafile volume that intend to invoke this restricted core set of fonts, but that contain well-known, trivial deviations in the construction of the names. In other words, the real target is trivially deviant usage of the 13 specific core-font names, regardless of the character encoding. (More background: the valid character encoding for any particular WebCGM instance is one of the three ISO 8859-1, unicode UTF-8, or unicode UTF-16. WebCGM will reword to clarify the useful scope of these normalization rules, to remove the implication of a normative restriction of applicability, and instead to be advisory about the usefulness of that normalization outside of its primary intended scope. Replace the sentence in question with: "Note: These normalization rules are derived from and intended for a substantial volume of existing metafiles that aim to invoke fonts from WebCGM's restricted core set of thirteen specific fonts, that contain well-known and trivial deviations in the construction of those font names, and that most often are encoded in WebCGM's default character encoding of ISO 8859-1. The rules may be less useful outside of that intended scope of normalization." QUESTION 1: I think that is more accurate, yes? QUESTION 2: If "yes", then... should 2.1 font-sub stuff contain a parameter to control whether or not that core-13-deviant normalization is applied? Regards, -Lofton.
Received on Tuesday, 16 December 2008 01:50:50 UTC