I think that on-the-spot xim is much better supported in OOo than
over-the-spot.  The pre-edit strings are rendered by OOo, making
the output match.
                                                                                
I am not a native Japanese speaker.  Heck, I only know that
"shift+space, 'nihongo', space" gives me something that I can read in
Japanese.  But at least for Japanese I think people are becoming
accustomed to the way that on-the-spot works.

 There is one significant bug, and that's is that
the font defaults to something other than Kochi Gothic or Kochi
Mincho, so you can't get any Japanese text rendered until you choose
one.  Moving OOo to something like fontconfig (ugh) could help with
this.
                                                                                
If something needs correction, it's kinput2's candidate selection
window, which is just to far away from where you're typing.  This is
not the fault of using on-the-spot.
                                                                                
FWIW, from what I've seen in WinXP's IME, it's also on-the-spot now.
The candidate selection window is a fair amount better, though.

If a solution cannot be found in time, can we revert back to RH8.0's behavior
"over-the-spot" for release?  Otherwise this partially cripples Asian language
usability of this application.

Tested this on RHL9.  It appears to be over-the-spot now?

Close bug?

I was wrong, over-the-spot is not working for the candidate selection window.

Still broken in openoffice.org-1.1.0-23

> Still broken in openoffice.org-1.1.0-23

Well and also bad behafior with just about all gtk2 applications,
while all KDE apps are fine in this regard.  The last time we had
acceptable behavior was within RH8's openoffice.  This makes it very
unpleasant to use Japanese input with these applications, and almost a
certainty that users will trigger Bug #104296 too.

I would clarify why you reassign this to openoffice again. you think
for all openoffice should supports over-the-spot, right?
Bug#104296 is definitely a problem to usability. and correctly it's
XIM's spec bug, because it didn't define any behavior of the candidate
window when over-the-spot is used; it should be placed to where, etc.
Basically I agree using on-the-spot. over-the-spot needs more cost for
the applications to support it. it's not necessarily easy to be
implemented, and as you said, this problem appears on all gtk2
applications so that gtk2 is also using on-the-spot.
So what we actually should do is, we fix the defect for kinput2 and
implement it as kinput2 specific behavior since XIM spec wasn't mentioned.

I filed this against openoffice originally because we used to ship a
version of openoffice in RH8 where this worked.  All versions after
that reverted to the gtk2 behavior where kinput2 goes under the bottom
left of the window.

Do you have any screenshots of "on-the-spot" working in any
application?  I have not been able to get that to work in any
application, while "over-the-spot" seems to work acceptably in
non-gtk2 apps.  I might be totally misunderstanding the problem though...

Sorry, there was typo in previous my comment. correctly, when
'on-the-spot' is used, XIM spec wasn't defined the candidate window
should be placed to where. so it's incomplete spec regarding 'work'
you mean. but I'm sure causing Bug#104296 is gtk2 applications only.
it's what I tought as first comment of it. if we don't consider such
spec bug, 'on-the-spot' works without any crash. on except gtk2
applications.

Let me think as separated issue:
- 'on-the-spot' of kinput2 isn't usable, because the candidate window
is always placed under the bottom left of the window. it's what
kinput2 needs thing for the requirement of 'work' you mean, right? I
think it should be filed as another bug.
- right now the behavior of the status window on openoffice is
actually 'over-the-spot', but the candidate window isn't. so if
openoffice continues used incomplete 'over-the-spot', the behavior of
the candidate window should be fixed. I think it's *this bug*.
- and Bug#104296, it's really another test case of Bug#78017. and it's
actually not fixed.

So the option for this bug:
- fix the behavior of the candidate window according to 'over-the-spot'.
- use 'on-the-spot' correctly.

I spoke with otaylor briefly today about gtk and kinput2.  He said the
problem is basically this:
http://bugzilla.gnome.org/show_bug.cgi?id=66471
I think he indicated that kinput2 only needs to implement something
and gtk is not at fault.

openoffice.org-1.1.0-24 in rawhide I am realizing now actually works
quite well with kinput2.  The fonts don't appear to be anti-aliased,
but I suspect that is another general gtk bug filed elsewhere (also
effected gaim since around FC1.)

closing...