From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Dec 03 2003 - 21:30:41 EST
Frank Yung-Fong Tang
> As long as a product support UTF-8 and pass the test with MES-1, I can
> pretty sure that no code in between strip off any non ISO-8859-1
> characters, regardless they support MES-2 or MES-3.
>
> Of course, that does not guarantee surrogate characters won't get
> damanaged, but just as someone believe, it will be <1% of efforts for me
> to fix it later, right? :)
As MES-1, MES-2 or MES-3 do not use any character out of the BMP, their
support not enough to test compliance and support of surrogates... You can't
assume that adding later a feature that was never tested in a previous
distribution will require <1% work.
The only way to ensure it is to start supporting some character blocks out
of the BMP (for example language tags, or musical notation, or Deseret, or
other special characters in plane 14, notably the extended variation
selectors which should be easy to support and test so that they will not
break the normal rendering of characters not currently known to use them).
I do think that adding at least the correct and fully compliant support for
variation selectors 17 to 256 would be a more definitive proof that they
aren't broken as they do need to be coded by surrogates in UTF-16, and they
do need the 4 bytes encoding in UTF-8. Just adding this small subset of
characters out of the BMP will not require you to implement all scripts of
the BMP. But at least it preserves you from later bad surprises when you'll
see that you apps need a major revision with lots of change spreaded
everywhere in its code, to make it work with non-BMP characters.
__________________________________________________________________
<< ella for Spam Control >> has removed Spam messages and set aside
Newsletters for me
You can use it too - and it's FREE! http://www.ellaforspam.com
This archive was generated by hypermail 2.1.5 : Wed Dec 03 2003 - 22:27:21 EST