- From: Lofton Henderson <lofton@rockynet.com>
- Date: Wed, 19 Nov 2008 15:07:52 -0700
- To: WebCGM WG <public-webcgm-wg@w3.org>
Hi WebCGM WG -- 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 will 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 responses and asked questions. Email discussion welcome. We will resolve definitively in a WG teleconference. I18N labels Comments #3 and #4 both pertain to normalization of font names and font-name lists. They are labelled Substantive by I18N. Comment #3 ===== "Why is the normalization for cgmFont different from that for substitutionList?" Proposed response: This was a very deliberate choice. The 'cgmFont' normalization defines how, in advance of the string comparison, to prepare for both the font name extracted from WebCGM instance and the parameter value of the 'cgmFont' attribute. The rule is based on extensive real-world usage of CGM and WebCGM, both present usage and legacy usage. The WebCGM specification itself (T.16.13 of section 6.5 [3]) has since 1999 required a core set of fonts, or their metric equivalents, with names such as "Helvetica-BoldOblique". But the specifications allowed no trivial variations (e.g., blanks, underscore-for-hyphen, etc). other than "case insensitive". In reality, there is now a large legacy of files that conform to profiles closely related to WebCGM (e.g., ATA) but that have trivial difference in these names, or that are WebCGM instances with trivially erroneous variations on the names. The 'cgmFont' normalization rules' purpose is to enable the application of the font substitution mechanism to this substantial legacy of CGM instances. On the other hand, the 'substitutionList' attribute of the WebCGM specification defines the set of fonts from which a substitute is to be selected. This font substitution mechanism is a new feature of WebCGM, and so there is no legacy to consider for 'substitutionList'. The best design of syntax and mechanism, and one that is already used by some WebCGM constituents in other contexts, is the CSS 2.0 specification. This was therefore closely adapted to the needs of WebCGM 2.1's font substitution mechanism. [3] http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Profile.html#webcgm_4_5 Comment #4: ===== "For cgmFont normalization, do you mean "stripping out all whitespace" or normalizing white-space to a single space, as per substitutionList?." Proposed response: The intent is "stripping out all whitespace". This, for example, enables the identical normalization results, for example, for a font name that used whitespace instead of camel case on the one hand, and on the other hand a font name that used only camel case (with no whitespace), or one that used hyphen or underscore in place of whitespace. See response to Comment #3 for more detail Regards, -Lofton.
Received on Wednesday, 19 November 2008 22:08:43 UTC