From: Kenneth Whistler (kenw@sybase.com)
Date: Mon Oct 17 2005 - 13:08:01 CST
> In other words, the representative glyphs and the alphabetic order is
> correct (so is the encoding itself), but the names only are wrong for
>
> > U+0E9E : LAO LETTER PHO TAM
> > U+0E9F : LAO LETTER FO SUNG
>
> which are swapped, as well as:
> > U+0E1E : THAI CHARACTER PHO PHAN
> > U+0E1F : THAI CHARACTER FO FAN
The PHO's and the FO's are not mixed up.
What *might* be mixed up are some of the second elements of the names.
This would need to be demonstrated, however, by reference to the
relevant Thai encoding standard *and* Thai and Lao dictionary usage.
> This should be an exception to the rule of immutability of normative
> character names,
No, it should not be, nor will it be.
*If* the names are wrong, then they are wrong in the Unicode
Standard, in ISO/IEC 10646:2003, in ISO/IEC 8859-11, in ISO 11940-1,
in ISO/IEC 10367, in ISO/IEC 14651, in the Unicode Collation Algorithm,
and in gazillions of data tables -- all in *exactly* the same way.
That is why attempting to "fix" the names is utter mischief. It
would propagate inconsistencies across multiple standards in
ways that would take a *minimum* of 5 years to line up again,
all to no significant gain.
> because this is an editorial error that should not have
> happened.
Yet to be demonstrated, although it could be the case.
> I think that such change this should require an immediate "Public
> Review Issue", and a communication to ISO/IEC 10646, so that they can
> statuate on this case...
Someone please do the research and submit a document to the UTC
with a detailed demonstration that some names for Lao and Thai
are out of whack (if they are). At that point, the UTC and WG2
can make determinations that some annotations to that effect
may be added to the standards to clarify the issue. And we can
add them to the growing list of character names with one problem
or another.
In the meantime, don't get your hopes up that character names are
going to be changed in the standards. They won't be.
--Ken
This archive was generated by hypermail 2.1.5 : Mon Oct 17 2005 - 13:09:56 CST