Bug 84860 - (Regression) openoffice lost 'over-the-spot'
(Regression) openoffice lost 'over-the-spot'
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: Akira TAGOH
David Joo
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-22 02:21 EST by Warren Togami
Modified: 2013-01-10 16:39 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-03 18:29:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2003-02-22 02:21:44 EST
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):
openoffice-1.0.2-2
Comment 1 Matt Wilson 2003-02-22 17:00:09 EST
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.
Comment 2 Warren Togami 2003-03-03 04:24:58 EST
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 00:14:56 EST
Tested this on RHL9.  It appears to be over-the-spot now?

Close bug?
Comment 4 Warren Togami 2003-04-24 03:55:14 EDT
I was wrong, over-the-spot is not working for the candidate selection window.
Comment 5 Warren Togami 2004-01-28 04:24:30 EST
Still broken in openoffice.org-1.1.0-23
Comment 6 Warren Togami 2004-01-28 04:29:08 EST
> 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.
Comment 7 Akira TAGOH 2004-01-29 02:11:38 EST
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 16:27:19 EST
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 02:36:32 EST
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.
Comment 10 Akira TAGOH 2004-01-30 02:40:00 EST
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 18:29:19 EST
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...

Note You need to log in before you can comment on or make changes to this bug.