|Summary:||(Regression) openoffice lost 'over-the-spot'|
|Product:||[Fedora] Fedora||Reporter:||Warren Togami <wtogami>|
|Component:||openoffice.org||Assignee:||Akira TAGOH <tagoh>|
|Status:||CLOSED RAWHIDE||QA Contact:||David Joo <djoo>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-02-03 23:29:19 UTC||Type:||---|
|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): openoffice-1.0.2-2
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 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 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 openoffice.org-1.1.0-23
Comment 6 Warren Togami 2004-01-28 09:29:08 UTC
> 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 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 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 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: 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...