Apache OpenOffice (AOO) Bugzilla – Issue 26
Input from Kinput2 Japanese Text in Font Supporting Codeset == Crash
Last modified: 2003-12-06 14:52:34 UTC
* Set font to font that does not support codeset for Japanese inputed from IME * Engage the input method (ie. Shift-space, etc.) * type * in-line conversion starts working but displays incorrect glyph (can't tell which character) * initiate conversion of inline characters to Chinese character * crash * Set font to font that supports codeset for Japanese inputed from IME * Engage the input method (ie. Shift-space, etc.) * type... * in-line conversion starts working but displays initial roman character in selected font then goes blank * initiate conversion of inline characters to Chinese character * crash
Don't expect email responses back from yositune@hotmail.com. Please email me at the same login at bigfoot.com. Thanks.
Change component status from code to ui
I asked the submitter in a private mail for further information.
Stephan, thanks for your mail. BTW, you can mail to this email at @hotmail what I meant was I don't check it very often. To summarize our private email: I am using the Kondara.org distribution, with some modifications. Elsewhere some other RH related and debian distros also. Kinput2 is the input method I use and is hte standard for entering Japanese text. I say standard but there are others (skk, etc.) and for Chinese and Korean there are deriviates and independent packages, I'm not peronsally familiar with. As a l10n primer for Japanese and multi-byte enablement you're dealing with a codeset that contains more than 254 characters so QWERTY alone is insufficient for charcter entry. A Roman to Native text conversion input layer makes entering Japanese text possible. (there's more to it than this of course but that should be enough info to address the bug.) In a i18n'ed system that has properly installed locales and available fonts you should be able to set environment variables, the applicatoin should read them, and be able to accept input from input engines via an input protocol (par example, kinput2) The 605-613 builds seem to allow inline text editing and are talking to the input method, evidenced by the fact that initiating a Japnaese text entry results in an inline character glyph getting rendered--albeit incorrectly--and a crashing on initiating a kana to kanji conversion. The Kana to Kanji conversion crash is confusing because the input method is converting the qwerty input to Japanese script (alphabet characters) then passes that string off to another layer that does conversion of Japanese script to the proper Chinese character (Kanji) combination. The major Kanji conversion engines available open source are Canna (my preferred engine) and wnn. I'm not familiar with kinput2 to tell you what's going on there but my guess is kinput2 is holding the text inline at first and Openoffice isn't rendering it correctly. Then when Kinput2 passes the string in opennoffice throws an exception or buffer overflows and crashes. My guess is hte text doesn't make it to the conversion engine. Are the text widgets prepared for Japanese and other multi-byte locales?
YIPPEE!! The new 614 is working displaying and entering Japanese in truetype, bitmap and type1 fonts (at least the one I have installed). Copy paste seems to be working. Find/Replace, etc. Dialogs are not working!! (The font's are set to New Times so I'll see if that works after I reset the default fonts to a Japanese supported font). I don't have Xprint working so I'll see how the printing support goes.
closed