Re: I18N comments -- #3 & #4 -- normalization issues

WebCGM --

Have a look at these two.  Is the proposed response for Comment #3 
okay?  Is it too lengthy?  I tried to make it clear why the different 
normalization rules are designed thusly, and make the explanation 
understandable to someone without a lot of CGM background.  If you think 
briefer is better, feel free to propose alternate draft.

-Lofton.

At 03:07 PM 11/19/2008 -0700, Lofton Henderson wrote:


>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:21:00 UTC