some misuse in XLC_LOCALE file

While digging XLCD related code in xlib recently, I found several misuse in some locale. In some cases, it doesn't cause visible effection, things just don't work as intention. In other cases, these misuse must cause incorrect behavior.

 1. In zh_CN.gbk locale, "GBK-0:GLGR" charset defined in XLC_LOCALE has ct_encoding as "GBK-0:GLGR:\x1b\x25\x2f\x32\x80\x88\x47\x42\x4b\x2d\x30\x02". It should be "GBK-0:GLGR:\x1b\x25\x2f\x32". With current define, Compound Text will be construct incorrectly, and most of Inter-Client Communication won't work. But most user may use XFree86 with GB18030 support patch, which add a "GBK-0:GLGR" entry in default_ct_data in lcCT.c, and thus cause the ct_encoding define in XLC_LOCALE useless. The problem is bypassed unintentionally.
 2. In zh_HK.big5hkscs locale, same problem exists for BIG5HKSCS-0:GLGR;BIG5HKSCS-1:GLGR;BIG5HKSCS-2:GLGR and BIG5-1:GLGR;BIG5-2:GLGR, but I don't know any patch can make it work. So, does anybody ever use zh_HK.big5hkscs successfully?
 3. In zh_CN.gb18030 locale, -- I know it's not in XFree86 CVS, but redhat's patch based on James Su's work was widely used. -- "ISO10646-1" charset was written as "iso10646-1"(in low case). This make no ISO10646-1 in charset, but again, xlib code make this error invisible because of ISO10646-1 act as fallback
charset. If one traces ICC process, he can find some characters become "BIG5" or "JIS" charset.

All these problems are caused by lack of document on XLC_LOCALE file and complexity of XLCD code.

The document should be update. "X Locale Database Definition" in XFree86 tarball is far too old. Many new features isn't include. I have read a lot os code, but I'm afraid my poor English make me not the proper one to do this job. And some related code seem not be used, thus the intention is hard to guess.

More importantly, xlib should up-to-date in i18n area. My idea is to introduce a new lib, replaces a bunch of old xlib APIs. With new APIs, an application can use utf8- or wc- functions, base on Unicode internally, and without creation of XLCD object. While old API and xlib leaves not touched to keep backward compatibility, like Xft did before.

Any comments?


BTW, there is another annoying thing. The X locale dir and alias files, namely locale.dir, locale.alias and compose.dir, are generated with R63Compat set to YES in Imakefile. I guess the meaning is X11R6.3 compatible, but I don't see any sense here. However, each file has two parts, while the first part, which without ":" to separate items, is totally useless. Although this doesn't cause any problem except waste of time, it's not neat!



Xie Qian
 
Open System and Chinese Information Processing Center,
Institute of Software, Chinese Academy of Sciences,
P.O. Box 8718, Beijing 100080, CHINA