Re: [patch] wide characters support



In article <yben2562q14.fsf@fresnel.labs.redhat.com>
otaylor@redhat.com writes:

>I've been working for the last few days on integrating
>the older version of your patch into GTK+, so I was
>quite happy to see the new version.

Thanks a lot.

>But I was a bit puzzled. A lot of things that were
>in the old patch don't seem to be in the new patch.

The new patch doesn't contain changes not related to wc support
because the old patch is so confusing.

> - The "--default-fontset" flag to configure. I tend
>   to agree that this wasn't a good thing to add.
>   I'd rather see a mechanism like I proposed here
>   of looking up a default gtkrc for the current
>   locale.

I think so too. This one is unnecessary.

> - Setting LC_CTYPE instead of LC_ALL. 

In some environments, setlocale(LC_ALL) fails but setlocal(LC_CTYPE)
succeeds (e.g., LANG=ja_JP.EUC on FreeBSD 2.2.5). But I think it's a
bug of OS, and I found that localeconv() and strftime() are used in
gtk+. It sould be LC_ALL after all.

> - A change to gdk_window_new with colormap allocation.
>   (It looks like this one might have been accidental
>    in the first patch)

Oops. Sorry.

> - The removal of gtk_editable_finalize() which
>   destroyed editable->ic() (possible for a second
>   time)
>
> - enter/leave handlers for the text and entry widgets,
>   which reset the point location.
>
> - A change to the ordering of gtk_widget_unrealize(),
>   to prevent windows from being destroyed before
>   their input contexts.

These changes are related to input methods, and Takashi Matsuda
wrote more complete patch: gtk-matsu-981109-0.patch. So these
are unnecessary already.

>We can install a system-dependent header file for GDK
>in /usr/local/lib/gtk/include. (We have a bunch of other
>GDK-specifc XIM stuff in glibconfig.h, but I don't want
>to continue that trend)

Hmm, it sounds overdone. Please keep my code if you feel that
code not so ugly.

>>   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. 
>
>I don't understand this. Although in the past new ideographs
>were created in China and Japan, this does not happen any more
>as far as I know.

I mean that a standardized character set is always only a subset
of characters used in CJK. There are many variant shapes,
miswritten characters, local characters, etc. No one can determine
the total number of Chinese characters.

Actually, a new standardization of character set is in progress
in Japan (http://jcs.aa.tufs.ac.jp/new-jis/). Of course some
characters in it aren't in Unicode. I afraid it will become
impossible to use these characters with gtk+.

>I don't think it is a bad assumption at all that all CJK
>characters that will ever be used for anything but transcriptions
>of a few rare old manuscripts are currently in Unicode. I believe
>there is work being done to add some rare characters to the the
>part of the UCS-4 code space outside of the first 65536
>characters.

I hope UCS-4 become easy to extend such as ISO-2022. But, as far
as I know, ISO-10646 says nothing about outside of the region
corresponding to UCS-2.

I have more to say, but I will not complain anymore, because it's
not a problem of gtk+ but a problem of ISO-10646.

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]