Re: Some thoughts on Unicode.
"Stephen J. Turnbull" <[email protected]> Mon, 30 Aug 2004 14:01:01 +0900
| Newsgroups | gmane.emacs.xemacs.mule,gmane.emacs.xemacs.beta |
|---|---|
| Organization | The XEmacs Project |
| Message-ID | <[email protected]> |
>>>>> "Aidan" == Aidan Kehoe <[email protected]> writes: Aidan> What I'm about to do, if no-one convinces me that it's a Aidan> stupid idea, is go and code up changes such that Ichars are Aidan> almost UCS-4, and the arrangement of Ibytes almost UTF-8. Been there, done that, got the T-shirt. It's called UTF-2000 XEmacs/CHISE, and it's available from Kyoto University or www.m17n.org/utf-2000, IIRC. Your proposal, IIUC, is exactly what they did at first, although at this point they use "real" Unicode (UTF-8) internally and convert at redisplay. We have efficient chartables for Unicode that can convert to font indicies very quickly; it's not a terrible hit. Aidan> What I propose is that we say that any character in our Aidan> Ibyte encoding that has its first five bits set is still Aidan> four octets long, and its value after masking should be Aidan> added to 2^22 to get its XEmacs internal code. Let's not go there. Just go straight to UTF-32, and deal with space efficiency later. The structures for widechar representations are already in place, but the code for widechar buffers still needs to be written, I think. In the next release, we do NOT want fonts to be determined by charset, we want them determined by "culture" (probably == language). In most cases UTF-16 plus a global language environment will be sufficient, which will actually be a saving over the Mule encoding for Asians. Connoisseurs and Buddhist scholars will need language information attached to text, presumably to an extent. Aidan> However, I am of the opinion that this code _should_ be Aidan> using latin-unity in some shape or form at the moment, latin-unity is an egregious kludge; buffer representation should be Unicode, and that automatically gives us proper identification of Latin characters across ISO 8859 coded character sets. It will cause issues because of Han unification, but we can deal with Han disunity later. The charset coverage check should be embedded in the coding system I/O routines, I'm not sure where. Aidan> What's Windows It unifies them, depending on font selection to disambiguate. Aidan> and XFT doing at the moment with unified characters? Being very broken AFAIK. Just plain doesn't work in XEmacs. Maybe the Tuebingen guys have something by now. Aidan> As I understand it, those APIs can't distinguish between Aidan> CJK versions of han characters, and what gets displayed Aidan> depends on the fonts used. Mr. Ohta[1] notwithstanding, that is what should happen. All of the Japanese and Chinese national bodies have made far more egregious identifications in their national standards than those Unicode's "Han unification" makes. They are the same characters (read any Japanese textbook on Chinese poetry; of course they use Japanese fonts!) What differs is how the different languages like them to look. An alternative experiment: What I've been doing (15 minutes at a time :( ) is converting the buffer representation to UTF-8 using Mule character codes. Ie, Ichars are the same, but instead of using Mule-style leading bytes, the buffer representation does int-to-utf8 on the Ichar. The next step after that is to change the internal representation to UTF-8 and use unicode-to-char to index into the fonts (except for Xft). Finally we can cache font indicies in a Unicode chartable. The next step after that is to arrange for the codecs to set extents in the buffer for the charsets decoded. This may require a fairly big rewrite of the current codecs because they take responsibility for a whole stream, and therefore they may not be amenable to stopping, creating an extent, and going on, but maybe it's not a big deal. Footnotes: [1] Masataka Ohta wrote an anti-Unicode polemic entitled "The Japanese Language Is Now Endangered!" -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.