Mike Fabian <[EMAIL PROTECTED]> writes:
> Aaron Lehmann <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> From: Anthony Fok <[EMAIL PROTECTED]>
>> Subject: Bug#113610: AbiWord-0.9.4.1 CJK fix is available
>> To: [EMAIL PROTECTED]
>> Date: Wed, 10 Oct 2001 10:18:38 +0800
>>
Hi Anthony,
I still can't use XIM with Abiword 0.99.1 although it worked with
Abiworrd 0.9.2. In the same way as I wrote below, it doesn't even
react to the key sequence to switch on XIM (Shift-Space for kinput2 or
Control-Space for xcin).
You wrote recently that Abiword is your favorite word processor,
therefore I assume that you can do Chinese input in Abiword.
Do you have any idea what could be wrong?
I can do Japanese and Chinese input in other Gnome/GTK applications.
Abiword doesn't seem to contain its own code for XIM but seems
to rely on the XIM support in the GTK library. Therefore it is quite
strange that I can't get XIM to work in Abiword although it works
in the other Gnome/GTK applications on my system.
Am I doing something stupidly wrong?
>> Thanks to Chinese i18n/L10n guru Rigel (Yong LI), the CJK input problem is
>> solved. I have tested it (locally built an abiword-0.9.4.1-3.1 package) and
>> it worked. So, please apply the following patch, and you can close this
>> bug. :-)
>
> [...]
>
> I tried this patch, but CJK input still doesn't seem to work in
> abiword-0.9.4.1. It worked in abiword-0.9.2, but abiword-0.9.4.1
> doesn't even react to the sequence to switch on XIM anymore
> (Shift-Space in case of the Japanese kinput2 XIM server). Am I doing
> something wrong? This patch doesn't seem to be XIM related.
>
>> ----- Forwarded message from Yong LI <[EMAIL PROTECTED]> -----
>>
>> Date: Sun, 07 Oct 2001 23:42:44 -0700
>> From: Yong LI <[EMAIL PROTECTED]>
>> Subject: [Patch] Fix multibyte key string conversion problem in 0.9.4.1
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> Content-type: text/plain; charset=us-ascii; format=flowed
>>
>> In the method ev_UnixKeyboard::keyPressEvent, a "UT_Mbtowc" object
>> is used to convert multibyte sequence to wchar. However the declaration
>> of this "UT_Mbtowc" object is placed inside the conversion loop, which
>> means for every byte to be converted a new "UT_Mbtowc" object is
>> constructed. This effectively disables the conversion of
>> multibyte-encoded characters which requires accumulation of multiple
>> bytes. One visible consequence of this problem is that input for all CJK
>> languages fail to work in 0.9.4.1.
>>
>> A patch is attached.
>>
>> regards,
>> rigel
>>
>>
>> diff -u abi.orig/src/af/ev/unix/ev_UnixKeyboard.cpp
>> abi/src/af/ev/unix/ev_UnixKeyboard.cpp
>> --- abi.orig/src/af/ev/unix/ev_UnixKeyboard.cpp Mon Sep 10 09:53:44 2001
>> +++ abi/src/af/ev/unix/ev_UnixKeyboard.cpp Sun Oct 7 15:04:38 2001
>> @@ -185,10 +185,10 @@
>> }
>> else
>> {
>> + UT_Mbtowc m;
>> ucs=new UT_UCSChar[mLength];
>> for(int i=0;i<mLength;++i)
>> {
>> - UT_Mbtowc m;
>> wchar_t wc;
>> if(m.mbtowc(wc,mbs[i]))
>> ucs[uLength++]=wc;
>>
>>
>> --
>> Anthony Fok Tung-Ling
>> ThizLinux Laboratory <[EMAIL PROTECTED]> http://www.thizlinux.com/
>> Debian Chinese Project <[EMAIL PROTECTED]> http://www.debian.org/intl/zh/
>> Come visit Our Lady of Victory Camp! http://www.olvc.ab.ca/
>
>
> --
> Mike Fabian <[EMAIL PROTECTED]> http://www.suse.de/~mfabian
> 睡眠不足はいい仕事の敵だ。
--
Mike Fabian <[EMAIL PROTECTED]> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
