Mmm...
>So one more reason to
>use ISO 2022 if you need linguistically exact information on CJK
>characters.
Unicode does not preclude you doing so. If we look at the horizontal
extension, you can perform the same 'feature' within your program.
Regards,
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael Kung
40P-972 Phone: (650) 506-6954
Manager, Server Globalization Technology Fax: (650) 506-7225
Languages and Relational Technology Email: mkung@us.oracle.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
attached mail follows:
On Fri, 7 Nov 1997, John H. Jenkins wrote:
> On 11/7/97 9:15 AM, Werner Lemberg (sx0005@sx2.hrz.uni-dortmund.de) wrote:
>
> >BTW, when will the Unicode CJK extension be officially adopted?
>
> Probably not until 1999, I'd guess. IMHO it's got an uphill battle to be
> put in the BMP; there's no real conflict over its contents.
>
> And, of course, it still doesn't cover all of CNS.
I assume it will never do due to unification rules. So one more reason to
use ISO 2022 if you need linguistically exact information on CJK
characters. Of course, it's possible to use SGML tags or something like
that to select the proper variant of the unified Unicode character, but
this is neither elegant nor readable.
Another interesting approach is Christian Wittern's Chinese Encoding
Framwork (CEF) (see http://www.gwdg.de/~cwitter for details): he uses SGML
entities to indicate an embedded character from another encoding (e.g. in
Big 5 text, the entry &C3-265F; indicates the character 265F from CNS
plane 3).
Werner
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:37 EDT