[patch] wide characters support

[a-higuti math sci hokudai ac jp (Akira Higuchi)]

Hello,

I've uploaded a patch to ftp.gtk.org.

gtk-a-higuti-981202-0.patch.gz

This patch adds support for wide characters to gdk, and adds
support for Asian languages to GtkText.

I have some questions, and a suggestion.

* Will it be applied? If not, what's the problem?

* What is the best way to determine the definition of the type
  of wide characters?

  In my code, GdkWchar (the type of wide characters) is always
  guint32, and size conversions are performed if wchar_t does not
  equal to guint32. The reason why I had to use such an ugly way
  is that I couldn't find a good way of getting the size of
  wchar_t works even if X_LOCALE is used. Of course it's easy to
  add a test to configure.in, but it seems that there are no
  other test which records system-dependent settings onto header
  files that will be installed. Or should the definition of
  GdkWchar be in glibconfig.h?

* Why Unicode?

  I heard that gtk+ is inclined toward Unicode, but I can't agree
  on it. I understand that there are some advantages of settling
  a particular coding (e.g., Unicode) for wide characters in gtk+,
  but such a change will be inconvenient for Asian users.

  As you know, a Chinese character is an ideograph, i.e., each
  character itself has meaning and nearly corresponds to a word
  of phonograms. So the idea 'all the characters' does not make
  sense. In general, the best way to handle such a mutable set
  of characters is to keep programs independent of a paticular
  encoding. The mb* and wc* functions defined in ISO C and XPG4
  are ideal for this purpose, and Xmb* and Xwc* functions in
  Xlib are so, too. Indeed Unicode is useful for the purpose of
  implementing ISO C i18n functions (for instance, glibc2 uses
  UCS4), but we had better not make codes depend on Unicode but
  use mb/wc functions. As long as we keep this policy, we can
  take prompt measures to support a new character set in the
  future. I guess this is why Unicode has a bad reputation in
  Japan. Indeed locale dependent multibyte encodings are
  troublesome a bit, but their difficulty is reasonable. If you
  feel multibyte strings too inconvenient, you have only to use
  wide characters instead.

  Well, I think right-to-ieft languages can be supported using
  X Output Method. XOM can deal with context dependent drawings,
  too. I don't know whether there exists an implementation or
  not, but the best way to support such languages is to use
  these functions in either case.

  IMHO, we should
  (1) do without ISO C mb/wc functions as far as support for
      X_LOCALE is needed. In my code, gdk_wcstombs() and
      gdk_mbstowcs() exist for this purpose.
  (2) next, switch over from above functions to ISO C mb/wc
      functions (and XPG4 functions if needed).
  Or it may OK to skip (1).

Comments are welcome.

--------------------------------------
Akira Higuchi
Dept. of Mathematics, Hokkaido Univ.
Hokkaido, Japan
Email: a-higuti@math.sci.hokudai.ac.jp