Bug 203882

Summary: Hangul input bug on Input line in oocalc
Product: [Fedora] Fedora Reporter: Jong Bae KO <jko>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: eng-i18n-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-24 08:09:16 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 06:49:22 UTC 
Description of problem:
when you type Hangul in input line, and press accept button. Hangul input is
disappeared. It shows only last Hangul character.

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


How reproducible:
always

Steps to Reproduce:
1. type "gksrmf(íê¸)"" in Input line
2. click  Accept(Funchtion) button
3.  
  
Actual results 1:
ê¸

Expected results 1:
íê¸

Actual results 2:
ì´

Expected reults 2:
ëí´ë¬¼ê³¼ ë°±ìì°ì´

Additional info:
The character(ê¸) is remained in buffer. So when you click the other empty
cells, it shows the Hangul char(ê¸).
Comment 1 Caolan McNamara 2006-08-24 08:09:16 UTC 
When you click accept all the text that has been typed into the input line is
placed into the cell.

But you have clicked accept while still "currently pre-editing" the second
character, so the second character doesn't really exist yet in the input line
only the first character has really been typed. You can see similiar sort of
behaviour in e.g. gedit if you are still in pre-edit mode on the second
character and and use e.g. file->select all->copy and open another gedit and
paste, only the first "finished" character gets pasted into the 2nd gedit

So if you press the right arrow key to finish the character and then press
accept the right thing happens. 

The jumping around of the uncommitted preedit buffer to follow the current input
cell is something we need to address, and is logged upstream as
http://qa.openoffice.org/issues/show_bug.cgi?id=67316

We should also consider having accept clicked equivalent to a signal to commit
the currently being-edited characters.
Comment 2 Jong Bae KO 2006-08-25 02:30:28 UTC 
"currently pre-editing" might be big problem. I have to file the gedit bug as well.
Comment 3 Caolan McNamara 2007-01-25 12:54:18 UTC 

*** This bug has been marked as a duplicate of 222779 ***