I had a problem typing Hebrew in Abiword on Windows2000 with English-Hebrew
keyboard support. The first character after switching the language was
garbled, and subsequent characters were emitted with a one-character delay.
Thus typing alpeh-bet-gimmel resulted in garbage-aleph-bet. I couldn't find
a bug on this, I hope my experience is not unique.
libiconv seems to have been designed for bulk-translation. The keyboard
routine uses libiconv to translate a single keypress into a unicode
equivalent. There are languages, among them Hebrew, where a single
keycodes can consist of more than one character, for instance if you wish
to place a vowel under a letter.
Anyhow, the point is that the iconv(3) instance must be told to flush its
output by sending a NULL (or pointer to a NULL) input. I read the iconv
man page, and patched the keyboard routine accordingly. Could someone,
preferably someone who understands iconv, review this, test it under other
versions of windows, and (hopefully) check it in?
Thanks,
Matti
Index: abi/src/af/ev/win/ev_Win32Keyboard.cpp
===================================================================
RCS file: /cvsroot/abi/src/af/ev/win/ev_Win32Keyboard.cpp,v
retrieving revision 1.27
diff -c -r1.27 ev_Win32Keyboard.cpp
*** abi/src/af/ev/win/ev_Win32Keyboard.cpp 2001/06/14 14:49:59 1.27
--- abi/src/af/ev/win/ev_Win32Keyboard.cpp 2001/09/22 18:30:27
***************
*** 559,565 ****
len_in = (m_bIsUnicodeInput || (nVirtKey & 0xff00)) ? 2 : 1;
len_out = 4;
if (UT_iconv( m_iconv, &In, &len_in, &Out, &len_out ) == -1)
UT_ASSERT(UT_SHOULD_NOT_HAPPEN);
}
else
--- 559,571 ----
len_in = (m_bIsUnicodeInput || (nVirtKey & 0xff00)) ? 2 : 1;
len_out = 4;
if (UT_iconv( m_iconv, &In, &len_in, &Out, &len_out ) == -1)
UT_ASSERT(UT_SHOULD_NOT_HAPPEN);
+ if (Out == (char *)charData)
+ {
+ // m_iconv is waiting for a combination keystroke. Flush
the buffer
+ if ((ret = UT_iconv( m_iconv, NULL, &len_in, &Out, &len_out )) ==
+-1)
+ UT_ASSERT(UT_SHOULD_NOT_HAPPEN);
+ }
}
else
