Re: some misuse in XLC_LOCALE file

  Hi,

>  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".

It is funny but this bug was reported in our Bugzilla week ago
( http://bugs.xfree86.org/show_bug.cgi?id=1362 ).  The patch is already commited
to CVS.

>  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?

I think the similar fixes should help.  But I can't test it.

>  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).

I don't see reasons why it couldn't be fixed there. :)

> 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.

I'm not a native English speaker too.  But there is another reason, I don't
think it would be useful.  You noticed that some code is not used and you want
to replace API.  Also note that an adding new locale to X11 can't be done
writing new XLC_LOCALE file only but requires additions into the Xlib code.
If we even keep the existent API but rewrite it using iconv it can make the
adding new locale simplier.  But in such case we could change XLCD (and
XLC_LOCALE) and then describe it.

> 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?

I agree. :)  Do you have a detailed plan?
You know the locale depended part of Xlib consists of three relatively
undepended parts:
* keyboard input and interaction with IM servers
* subroutines for a selection conversions (and conversion of resource strings)
* text output.
I don't think we need another one API for the text output.
The second part (text property<->text list conversion) needs only from/to CTEXT
converter in addition to iconv. (It is needed for the compatibility with 'old'
applications, new ones should use UTF-8 for a communication.)
The simplest keyboard input (key to wc or utf8) needs only a table for the 
'legacy keysyms' to Unicode conversion.
Hence there is only IM server interaction part where some new API can be added.
Are there any other functions that absent now but are worth adding?

Any comments? :)
-- 
 Ivan U. Pascal         |   e-mail: [email protected]
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia