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