On Friday, July 18, 2003 2:18 AM, Kenneth Whistler <[EMAIL PROTECTED]> 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.
