From: "Chulkee Sung" <[EMAIL PROTECTED]> > I seems that support of gb18030 support in glibc level is quite solid, of > course I see many debates. I personally think that our glibc should handle > all code points regardless that they are assigned or not as long as that are > legal. This I believe is worth to continue to discuss.
While I agree solid support of GB18030 in GLIBC or libiconv is a must, but I fail to understand a. Why do we want GB18030 support in XLIB and b. Who is going to use it? 1. If iconv is used to support GB18030, then XLIB is going to depend upon iconv; if iconv is not used, then equivalent convertion table should be maintained in XLIB which is a duplicated effort. It is far better to let the application depend on iconv. 2. Should we define and use GB18030 encoded compound string? It seems that UTF8_STRING is the prefered way to go. 3. QT and GTK+ is not going to use GB18030 in XLIB, but they do support GB18030 through iconv. I am not aware of any other application which will use GB18030 support in XLIB. 4. Serveral people here mentioned that new development will be focused on Xft, and it seems to be Xft is going to use Unicode only. 5. For backward compatibility, supports of legacy encodings like GB2312, etc are kept in XLIB, but GB18030 is new, and there is no compatibility issue here. So unless there is a real need for GB18030 support here, I think propably we can leave current XLIB alone. > Q: How can a gb8030 characters be displayed without conversion with > gb18030 fonts. I don't know what do you mean when you say GB18030 fonts. So far, all the TTF fonts I have seen which cover GB18030 are really Unicode fonts. To access them, you (or someone somewhere) need to convert to Unicode first. Regards, Yao Zhang _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
