> And there is another issue, that en_US.UTF-8 may have a different fontset
> than zh_CN.UTF-8 and ja_JP.UTF-8 - if we just do
> 
>  setlocale(en_US_UTF8_locale),
> 
> you effectively break locales which need a different fontset than
> en_US. (I suppose I have no need to tell you about the CJK font style
> variations)

If you took this issue seriously, you must noticed that what you 
had to do in this area is not to add the Xutf* APIs, but adding 
the following API:
	char *XFree86UTF8Locale(locale_name);
	... this function returns corresponding UTF-8 locale to
	    argument locale. 
	    e.g. XFree86UTF8Locale("ja_JP.eucJP") returns "ja_JP.UTF-8".
Then you can become to write the following code fragment:
	current_locale = setlocale(LC_CTYPE, NULL);
	setlocale(LC_CTYPE, XFree86UnicodeLocale(current_locale));
	... create Unicode FontSet here ...
	setlocale(LC_CTYPE, current_locale);

In other words, what you had to do in this area was to add ONLY ONE API,
rather than bunch of new Xutf8 APIs.

> > And as I already said, the Xutf8 API doesn't solve the problem. 
> > The only option to solve this problem is to make (very few) APIs
> > which have explicit locale argument.
> 
> That is an option, certainly. 

And Xutf8* APIs don't solve this problem.

> Have you got a patch to do that?

Patch to X11 part is quite trivial, isn't it?

> > In other words, Xutf8 APIs don't solve real problem, don't add 
> > any new feature, only add incompatiblity and make code bloat.
> 
> Bruno, how big is it, a couple of kilobytes or something?  That's little
> enough that it might not actually increase the memory footprint.

As I already said, current implementation of Xutf8 APIs isn't good
enough. It should become as big as IIIMXCF implementation.
--
soda