Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 84860

Summary: (Regression) openoffice lost 'over-the-spot'
Product: [Fedora] Fedora Reporter: Warren Togami <wtogami>
Component: openoffice.orgAssignee: Akira TAGOH <tagoh>
Status: CLOSED RAWHIDE QA Contact: David Joo <djoo>
Severity: medium Docs Contact:
Priority: high    
Version: rawhideCC: dcbw, pcormier
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-02-03 23:29:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Warren Togami 2003-02-22 07:21:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030215

Description of problem:
Similar to Bug #84859 of Mozilla.  OpenOffice in Phoebe3 no longer has
"over-the-spot" XIM input that it had in Red Hat 8.0.  "over-the-spot" is
crucial to Asian language character input.

Version-Release number of selected component (if applicable):

Comment 1 Matt Wilson 2003-02-22 22:00:09 UTC
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
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.

Comment 2 Warren Togami 2003-03-03 09:24:58 UTC
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.

Comment 3 Warren Togami 2003-04-06 05:14:56 UTC
Tested this on RHL9.  It appears to be over-the-spot now?

Close bug?

Comment 4 Warren Togami 2003-04-24 07:55:14 UTC
I was wrong, over-the-spot is not working for the candidate selection window.

Comment 5 Warren Togami 2004-01-28 09:24:30 UTC
Still broken in

Comment 6 Warren Togami 2004-01-28 09:29:08 UTC
> Still broken in

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.

Comment 7 Akira TAGOH 2004-01-29 07:11:38 UTC
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.

Comment 8 Warren Togami 2004-01-29 21:27:19 UTC
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...

Comment 9 Akira TAGOH 2004-01-30 07:36:32 UTC
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

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.

Comment 10 Akira TAGOH 2004-01-30 07:40:00 UTC
So the option for this bug:
- fix the behavior of the candidate window according to 'over-the-spot'.
- use 'on-the-spot' correctly.

Comment 11 Warren Togami 2004-02-03 23:29:19 UTC
I spoke with otaylor briefly today about gtk and kinput2.  He said the
problem is basically this:
I think he indicated that kinput2 only needs to implement something
and gtk is not at fault. 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.)