From: Philippe Verdy (email@example.com)
Date: Wed Oct 19 2005 - 15:07:23 CST
From: "Richard Wordingham" <firstname.lastname@example.org>
> Doug Ewell wrote:
>> Philippe Verdy <verdy underscore p at wanadoo dot fr> wrote:
>>> This should be an exception to the rule of immutability of normative
>>> character names, because this is an editorial error that should not
>>> have happened.
>> Surely no more so than U+1D0C5.
> That is a relatively harmless fault - someone looking for 'fthora skliron
> chroma vasis' is not going to pick the wrong character. On the other
> hand, someone looking for Lao fo sung could very easily pick the wrong
> character from a pick list - with a legible name, why bother to look at
> the very tiny distinction in the top left hand corner. (It's illegible in
> the Windows character map.) This will cause confusion for a thousand
> years - changing the name would only cause confusion for five years!
> Are there are other routes available for reducing confusion? (...)
The problem is not for users of the script, when they use their word
processor, this is a problem for font and keyboard designers, because in
that case they will ignore the representative glyph, and will focus on the
character names that is displayed in their dont design tool.
I see only one way to solve the problem, if the normative name can't be
changed: adding a usage notice in the standard (in the names list file),
revealing their effective semantic, so that no font will be made
erroneously, and texts or keyboards later encoded with the wrong codepoint.
Without such notice published with the standard itself, this standard
remains confusive (and given that the representative glyph is not completely
normative and can be changed at any time for another or less confusive
representation of some encoded character, users may favor the interpretation
given by the normative character name, hence generating encoding errors...).
Note that the encoding order is just a possible hint of the effective
letter, but it is not normative regarding collation in Lao, where a tailored
collation and some preprocessing is still needed to manage the effective Lao
A good option would then be to provide the effective Lao letter names using
Lao orthography and spelling (something that is missing anyway in the
standard, that just published english names that are often unrelated to
their actual usage; the English character names are only good in the
standard itself for languages sharing the same Latin script, otherwise it
should have adopted as much as possible the strictected rules for the roman
transliteration from the most common language using that script, and for the
case of Han, Unicode and ISO/IEC 10646 did not even chose to give any Roman
names for the characters, not even any form of Pinyin or simple
transliteration from Kana).
This archive was generated by hypermail 2.1.5 : Wed Oct 19 2005 - 15:10:29 CST