I18N #6 -- proposal (incomplete)

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 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.  I have one 
omission/uncertainty about the specific issue.  Email discussion 
welcome.  We will resolve definitely in a WG teleconference.

Comment #6 pertains to using a "unicode normalization form" to compare the 
font names in the metafile with the 'cgmFont' value.  It is labelled 
Substantive by I18N.

Comment #6
=====
"Normalization for string comparison should include conversion to a Unicode 
normalization form, to eliminate issues related to precomposed vs. 
decomposed characters and issues related to ordering of multiple combining 
characters."

Proposed response:
----------
WebCGM agrees that this is the consistent and reliable way to perform such 
comparisons.  Text to this effect will be added to the description of the 
'cgmFont' value -- conversion to unicode normalization form should precede 
the comparison and follow the other WebCGM-specific normalizations.

Add a new sentence to the end of the 'cgmFont' description.  "Correct and 
consistent results when comparing metafile font names with the 'cgmFont' 
value -- for font names outside of WebCGM's restricted @@core set of 
thirteen specific fonts@@ [@@link to section 6.5, T.16.13@@] -- require 
that WebCGM processors convert to a @@unicode normalization form@@ [@@link 
to the right place in I18N spec "Character Model for the World Wide Web@@] 
before performing the comparison.  This should happen after the 
WebCGM-specific normalizations."

Altogether now, the changes proposed for I18N-5 and I18N-6 would change the 
'cgmFont' description:

Change 'cgmFont' paragraph from:

"The name of the font in the metafile for which font substitution is 
requested. Before attempting to match a font used in the metafile to the 
string cgmFont, the both font names are normalized by: converting to 
lower-case; and stripping out all whitespace, UNDERSCORE, and HYPHEN 
characters. Note: 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."

to:

"The name of the font in the metafile for which font substitution is 
requested. Before attempting to match a font used in the metafile to the 
string cgmFont, both font names are normalized by a WebCGM-specific 
normalization: converting to lower-case; and stripping out all whitespace, 
UNDERSCORE, and HYPHEN characters. Note: This WebCGM-specific normalization 
is derived from and intended for the substantial volume of existing 
metafiles that aim to invoke fonts from WebCGM's restricted core set of 
thirteen specific fonts (see @@section 6.5, T.16.13@@).  Many such 
metafiles contain well-known and trivial deviations in the construction of 
those font names, and they are most often are encoded in WebCGM's default 
character encoding of ISO 8859-1. The rules may be less useful outside of 
this intended scope of normalization.  After this WebCGM-specific 
normalization, correct and consistent results when comparing metafile font 
names with the 'cgmFont' value -- for font names outside of WebCGM's 
restricted @@core set of thirteen specific fonts@@ [@@link to section 6.5, 
T.16.13@@] -- may require that WebCGM processors convert to a @@unicode 
normalization form@@ [@@link to the right place in I18N spec "Character 
Model for the World Wide Web@@] before performing the comparison."

INCOMPLETE:  We don't yet have a reply from I18N to our question about 
whether we should recommend a specific one of the four normalization 
forms.  Maybe it doesn't matter, i.e., any one of the 4 forms would work 
equally well?

Regards,
-Lofton.

Received on Tuesday, 16 December 2008 18:36:25 UTC