I18N #5 -- proposal and QUESTION (corrected)

[...slight correction to the sentence beginning "I18N Comment #5 pertains..."]

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 Comment #5 pertains to normalization of font names from the metafile 
and the 'cgmFont' value.  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 17:54:22 UTC