Description of problem: Hangul/Hanja convertion doesn't work in some situation(Cut and paste from web site. and input Hangul char in between Hanguls). Version-Release number of selected component (if applicable): openoffice.org 2.0.33 How reproducible: Steps to Reproduce: 1. start oowriter 2. copy and paste the contents from the following URL: http://i18n.brisbane.redhat.com/~llim/rendering/CJKI%20bold-nornal%20font%20compare 3. ctrl-space to activate SCIM 4. input Hangul char in between Korean characters 5. press F9 6. choose one of them Actual results: disappear the hangul character Expected results: convert Hangul to Hanja Additional info: when i write some Hanguls and try like it again, the converting is working.
Please select the character and check format->character->Asian->Language, this conversion only works based on the language of the affected characters, not the unicode code points of the glyphs themselves. So the characters need to be set to Korean to be detected by the dialog.
the Language is korean in Asian font text. :)
I think I misunderstood this, I was thinking of ctrl+shift+F7 when the input engine is closed, i.e. the inbuilt writer hangul/hanga conversion. But you said F9, i.e. you are talking about the ability in the IM itself to change the letter being inputted ? Is that what we mean here, if so could you tell me a sample cursor position and what letter on the keyboard to press when using the hangul scim engine to reproduce this This *might* be related to something like bug 200728 where we need a way to get the surrounding text
Just follow the step until 3 The Hangul SCIM should be activated. and then write "rh" between ìì¤í in ko_KR Locale, i.e ìê³ ì¤í <-- "rh" should be in Korean(ê³ ) after that press F9 finally press 1(This action is selecting Hanja) It should convert from Hangul to Hanja eg: "ê³ " --> "ä¼°"
reproducable
It's actually a nasty glyph substitution bug, e.g. cutting and pasting the character from gedit into a blank line is ok, pasting it between those characters and it's not rendered at all. So it's the glyph rendering that's the problem, not the input engine handling.
very hard, fix checked in. Hopefully this one squashes this sort of problem permanently
Fixed, but failed. Far more cunning required.
Attempt 2
Created attachment 135119 [details] a glyph replacement test case A test document stuffed with troublesome scripts, and the sort of nasty edge cases which trip us up
ok, how about that in 2.0.4-2.2 ? Finally looks good to me now.