WebCGM fonts

Dear i18n Interest Group,

WebCGM recently went through last call.  The LC has actually finished, and this is rather late, and so we would like to action any comments asap.  A question arose last week about whether section 9.3.2 contained any i18n issues.

Please take a look and if you have comments, please send to this list by the end of this week.

http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Config.html#ACI-fontmap


Background:
Computer Graphics Metafile (CGM) is an ISO standard, defined by ISO/IEC 8632:1999, for the interchange of 2D vector and mixed vector/raster graphics. WebCGM is a profile of CGM, which adds Web linking and is optimized for Web applications in technical illustration, electronic documentation, geophysical data visualization, and similar fields.


Proposed comments
After discussing this briefly in the i18n Core WG telecon last night, I have the following potential comments, so far:

[1] typo: substitutionList="CDATA" should be bolded

[2] "The list syntax and normalization are derived from the specifications of CSS 2.0 [CSS20]. In particular, the values and syntax of the substitutionList attribute are derived from CSS's definition of the font-family property "
It is unclear where these rules are in CSS2, ie. whether there are more than in the font-family section. If so, we couldn't find where.

[3] Why is the normalization for cgmFont different from that for substitutionList?  

[4] For cgmFont  normalization, do you mean "stripping out all whitespace" or normalizing white-space to a single space, as per substitutionList?  

[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?

[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.

Do you have others?  Thanks.

RI
============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

Received on Thursday, 6 November 2008 16:23:42 UTC