Subject: Re[2]: CJK patch test error report!
From: hashao (hashao@china.com)
Date: Tue Oct 31 2000 - 03:05:19 CST
Hello Belcon,
On Tuesday, October 31, 2000, Belcon wrote:
>> Do you have any ideas why it's impossible to input anything into AW with
>> my patch? It has exactly the same logic as HJ's patch with respect to
>> keyboard input. May be it it's also due to the fact that HJ's version of gtk
>> was also hacked in this respect?
B> No,I don't think so.I can input Chinese in AbiWord-0.7.10 patched with
B> HJ's
B> patch,although I don't know why I can't input Chinese in AbiWord-0.7.11.
B> I am still trying to find the reason.
I was thinking at the line:
+ if(charData>0xff)
+ result = m_pEEM->Keystroke(EV_EKP_PRESS|state|'a',&pEM);
+ else
+ result = m_pEEM->Keystroke(EV_EKP_PRESS|state|charData,&pEM);
Maybe the (charData>0xff) should be something like
((charData>0xff) || (charData==0)). According Xlib manual
13.5.10, if a input is completed in XIM, keycode will be
set to 0. I don't know what does the 0xff means in the
original patch. Maybe something for non-standard input
method other than XIM?
But since the patch works for 0.7.10, maybe the problem
is in somewhere else. Does the Keystroke changed lately?
BTW, according to
http://developer.gnome.org/doc/API/gdk/gdk-event-structures.html#GDKEVENTKEY
+ char *mbs=e->string;
+ int mLength=strlen(mbs);
can be replaced by mLength=e->length; :)
>> Or may be Input Methods should be setup on the frame?
>>
frame already setup the XIM at the initializing stage. I just
assume it is correctly setup.
>> Also, just curios, my RH6.0's glibc knows among others 3 encodings:
>> ISO-2022-JP-2, ISO-2022-JP, ISO-2022-KR
>> are they just synonims or they are different?
I don't know much about Japanese charset but apparently the
3rd one is a locale for Korean.
-- Best regards, hashao mailto:hashao@china.com.n.s.pam
This archive was generated by hypermail 2b25 : Tue Oct 31 2000 - 03:05:32 CST