Bug 203872
| Summary: | Hideous OOo character commit bug | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jong Bae KO <jko> |
| Component: | openoffice.org | Assignee: | Caolan McNamara <caolanm> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6 | CC: | aalam, eng-i18n-bugs |
| Target Milestone: | --- | Keywords: | i18n |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.0.4-3.1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-09-08 10:06:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jong Bae KO
2006-08-24 05:32:19 UTC
Hmm, I think this is working for me now. Might be working because of the fontconfig fixes. Hmm. It still doesn't work in openoffice, but it is working in gedit. is it fontconfig problem? No I mean the use of fontconfig in OOo itself, not a fontconfig bug, but a problem in how we do some font substitution work based on fontconfig feedback Well, that is odd. It worked on my x86_64 box, but not on the i386 one, and the code in question is a horrible tangled hack to try and munge a single character im commit into a key event to keep older OOo widgets working. But it tries to keep count of the real keystrokes pressed to re-use for a single character commit, and this fails horribly when (as on my i386) the events are in sequence of... last pre-edit changed right arrow pressed OOo gets "right-arrow" key event OOo gets "buffer commit" event, check to see what key was pressed and reuse keycode (which is arrow) document gets -> arrow keycode, but with "unicode character from buffer" value, processed as arrow arrow key processed document gets -> arrow keycode, and with arrow value, processed as arrow on my x86_64 the sequence happens to be... last pre-edit changed right arrow pressed OOo gets "buffer commit" event, check to see what key was pressed and reuse keycode (which is either nothing, or e.g. 'k') document gets -> 'k' keycode, but with "unicode character from buffer" value, processed as "normal character with val unicode character" OOo gets "right-arrow" key event arrow key processed document gets -> arrow keycode, and with arrow value, processed as arrow I have an alternative patch which solves this for me, but let's check with upstream for any obvious flaws I'll check my changes in provisionally. I tested on openoffice.org-writer-2.0.4-2.2 which is released on Tue 29 Aug 2006 10:03:13 It isn't upstreamed yet. I will test it on newer version later. Hi Jong I am not the native speaker of any of the CJK language. So, I want some more info to test this bug. Would u please supply these informations!! 1. did u mean scim-hangul in ko_KR to be selected from scim table? 2. typing "gksrmf" for me its showing korean chars. And what is meant by "(íê¸)"? did not understand really!! pls explain once again. 3. Which arrow key it is to be pressed. up, down, left, or right arrow key? pls inform. 4. what is meant by the sentence -- "A cursor should be on "ê¸"" " ? did not get it really!! Please explain. Cheers Satya woah, I have a fix for this checked in. But not delivered in a build yet. 1. yes 2. yes, gksrmf with that input engine active will show two korean characters, and the 2nd one will be highlighted at this stage 3. any of them, e.g. right arrow 4. the problem is that the highlighted second character will disappear when e.g. right arrow is pressed What we'd like to happen is that the highlighted character gets committed to the document instead of disappearing. When is it going to build? *** Bug 205560 has been marked as a duplicate of this bug. *** |