On Thu, 21 Dec 2000, Noriyuki Soda wrote:

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

I do take this issue seriously. And this had not occured to me.

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

I'm glad to see a slightly more sensible suggestion. However, this still
doesn't solve the problems of

  * UTF-8 input
  * UTF-8 string <-> COMPOUND_TEXT string conversion
  * thread safety
  * ickiness
  * requiring UTF-8 locales to be installed

And I'm sorry, but lack of ickiness counts for a lot.

> And Xutf8* APIs don't solve this problem.

Indeed.

> > Have you got a patch to do that?
> 
> Patch to X11 part is quite trivial, isn't it?

So in other words, you should be able to do it quite quickly. I look
forward to seeing your patch.

Myself, I don't think its very high priority, so I won't be writing it,
but I won't object to it.

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

Whatever.

-- 
Robert