Re: [patch] wide characters support
- From: a-higuti math sci hokudai ac jp (Akira Higuchi)
- To: gtk-devel-list redhat com
- Subject: Re: [patch] wide characters support
- Date: Sun, 6 Dec 1998 19:55:39 +0900 (JST)
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]