From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu Jul 17 2003 - 20:59:16 EDT
On Friday, July 18, 2003 2:18 AM, Kenneth Whistler <kenw@sybase.com> wrote:
> MES-2 was not designed by the UTC, nor did it take any of
> these considerations into account. It is not really an
> appropriate construct for the Unicode Standard. A more
> meaningful way to think of it is: if you want to sell software
> in Europe, you better be able to input and display all the
> characters we Europeans have in this list.
I interpret it like this way:
MES-2 is a collection of characters independant of their actual encoding.
To support MES-2 in a Unicode-compliant application, extra characters
need to be added, notably if the minimum requirement for information
interchange is the NFC form used by XML and HTML related standards.
It would be interesting to inform CEN about how MES-2 can be
documented to comply with all normative Unicode algorithms, and
the minimum is to ensure the NFC closure of this subset, which
should have better not included compatibility characters canonically
decomposed to singleton decompositions, and should now reintegrate
the missing NFC form.
For obvious reasons, the case mappings should also be closed, but
not necassarily compatibility decompositions, or characters needed
for the NFD form (notably combining diacritics, which may be added
only on applications that can process and recompose them on the
when querying supported precomposed characters in fonts).
Does the default TrueType fonts for Windows support the whole
MES-2 repertoire (Times New Roman, Arial and Courrier New),
including on Windows 95 without Uniscribe installed and used?
In practice, MES-2 support will always need additional characters
to ensure the minimum closures, and ISO10646 should work with
CEN to fix their set in a revision.
-- Philippe. Spams non tolérés: tout message non sollicité sera rapporté à vos fournisseurs de services Internet.
This archive was generated by hypermail 2.1.5 : Thu Jul 17 2003 - 21:43:23 EDT