Subject: XIM, bug #435
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Tue May 30 2000 - 22:46:00 CDT
http://www.abisource.com/bugzilla/show_bug.cgi?id=435
OK, this bug is EVIL. I have spent over ten hours trying to track it down.
I finally, with the help of Owen Taylor, figured out that the reason why
the Compose key (Multi_Key) starts working if you click on a combo box is
that they enable XIM, which is necessary for the Compose key to operate. I
remembered that hj sent a patch awhile ago to make XIM work. hj, maybe you
could port this to the version in CVS? It would not only help with Chinese
editing but also fix bug #435 which is a very bad bug. If you're not
interested, I could try to implement XIM myself, but it seems that we
already have some code that just needs to be brought up to date.
Thanks,
Aaron Lehmann
On Mon, 27 Mar 2000, hj wrote:
> Top level window not support XIM. But s_ic and s_ic_attr must be static
> member. It will cause segment fault if I change to non-static. I don't know
> why.
> All Chinese and English Characters are encoded in unicode in abw.
> European languages are not encoded in unicode. In furture we display
> different languages in one document. So unicode encoding is needed.If you
> replace fonts.hj with european languages, Characters are unicode in abw.
> Chinese font files are too large to ship. I don't distribute Chinese
> fonts. I create a file "fonts.hj" in AbiWord font file that include Chinese
> printing font name, XLFD, printing font ascent, printing font descent and
> printing font width.
> All unixfonts are created as fontset not font. It can display both
> English and Chinese Character. Printing program can print both English and
> Chinese Character.
> We must resolve that keyval will be 0xffffff when I input Chinese with
> XIM. Chinese strings are stored in string not in keyval.
>
This archive was generated by hypermail 2b25 : Tue May 30 2000 - 22:46:23 CDT