[g11n-ko-discuss] [i18n-discuss] Please review the onepager for "Korean Input Method Enhancement" project

[Ienup Sung]

Thanks for your answers.

Based on the answers you provided, it appears to me that the one pager
and project should explicitly mention about and include the EOF of KOLE and
Hanja Tool and also add proper interface stability definitions for the EOF.
(EOF announcement at a S10UR and EOF execution at Nevada.)

If Hanja Tool's EOF is definite and if there is no other replacement or
user data migration path planned, then, there should be a justifiable
argument why those are not needed as part of EOF statement and also
explanation.

Re auto completion, as long as people can input characters (including
"invalid" characters) as they intended, that should be fine. Mentioning
such should be good enough.

Okay, I understand there is no UDC/PU area support in the project scope.

Please send me the current Hanja image file or source of the aux window and
I'll be happy to update and send it back to you.

Ienup

Aijin Kim wrote at 01/22/08 20:17:
> Hi Ienup,
> 
> Thanks a lot for your comments.
> Please see my reply below.
> 
> Ienup Sung 쓴 글:
>> Hi Kim, Aijin-si,
>>
>> Thanks first of all for doing this good project. I've also cc'd
>> g11n-ko-discuss mailing list at OpenSolaris.org.
>>
>> I have a few questions to ask on the project:
>>
>> It appears to me that this project will replace the existing so-called
>> KOLE with HangulLE at Nevada while supply both at S10UR, correct?
> 
> Yes, we plan to leave KOLE as a secondary LE in S10UR according to 
> GTO-core's advice. We think that It'd be safer to have a transition 
> stage of  the replacement.
> 
>>
>> What are the compatibility issues in terms of user's usage perspecitive?
>> Are all existing input modes and key sequences and so on be the same and
>> supported with new HangulLE?
> 
> All the features of existing KOLE will be covered by HangulLE or 
> alternative ways. However, there is a few changes with user's usage.
> 
> As you know, there are four input mode in KOLE:
> - Hangul
> - Hex(KS X 1001)
> - Hex(UTF-8)
> - Symbol
> 
> Among them, Hex(UTF-8) mode will be covered by UNICODE engine of IIIMF.
> For Symbol input, instead of symbol input mode, HangulLE provides a 
> feature symbol input with virtual keyboard. User can input hangul and 
> symbols without switching input modes. And also 'consonant+Hanja key' is 
> supported for symbol input just like Windows IME and SCIM-hangul.
> 
> And some key sequences especially for Hanja conversion are changed. It 
> is mainly because of the reported issue:
> CR6267800    shortkey for hanja convertion can not work in some gnome 
> application, such as gedit
> 
> KOLE is using several shortcut keys which are already defined in some 
> applications such as 'Ctrl+W','Ctrl+N','Ctrl+P'. HangulLE doesn't use 
> 'Ctrl+' key sequences and defines shortcut keys to be similar with 
> Windows IME and SCIM.
> 
>>
>> With HangulLE, would you or how do you support user-defined characters?
> 
> I'm not so sure of this question. Is this question related the below 
> question regarding the five characters of EUC locale?
> 
>>
>> How the Hanja Tool and existing user Hangul-Hanja dictionary plays their
>> roles with new HangulLE?
> 
> HangulLE uses the Hanja dictionary in libhangul. Existing Hanja 
> dictionary won't be used.
> 
>>
>> In Korean EUC locale with KS C 5601-1987 fonts, as you know, there are 
>> five
>> characters that are not in the KS C 5601-1987 character set while in
>> the course of composition of Hangul syllables, do required to be
>> present/visible at preedit window as visual feedback. They are 뢔, 쌰, 
>> 쎼,
>> 쓔, and 쬬 (in UTF-8) and in our Korean EUC fonts, the glyphs for them 
>> are
>> intentionally added at user-defined area between 0x497a and 0x497e so 
>> that
>> during preedit, those glyphs will be shown as user visual feedback.
>> Would such characters also be supported at the new HangulLE for
>> the Korean EUC locale?
> 
> Thanks for the good point. I didn't consider the issue. I think HangulLE 
> should support the characters as well. I'll think of how to support them 
> in HangulLE.
> 
>>
>> In the section 4.1.4. (1), the one pager describes the auto 
>> composition when
>> vowel starts a syllable. Would such auto auto composition a feature 
>> that can
>> be turned on and off and if so what would be the switch? 
> 
> All the hangul processing include auto composition is handled by 
> libhangul, not HangulLE codes. I'm afraid that on/off is not currently 
> available.
>> In the (2),
>> would step Hangul-to-Hanja conversion still be supported using Ctrl+N 
>> and P?
> 
> As explained above regarding shortcut key, HangulLE doesn't use 'Ctrl+' 
> key to avoid conflict with applications.
> Ctrl+N and P is for page up and down. HangulLE uses page Up/Down key and 
> also can move candidate pages clicking arrow icon on the candidate list 
> window.
> 
>>
>> In the section 4.1.5, the aux window layout is shown as:
>>
>> +-------------------------------------------------------------------+
>> | Mode Switch | Hanja | Full/Half  | Virtual Keyboard | Properties  |
>> +-------------------------------------------------------------------+
>>
>> which appears reversed "Hanja" and "Full/Half" of the current aux window.
>> Is there any specific reason why that has to be that way possibly 
>> increasing
>> confusion among users? Also, would it be possible to change the "Hanja"
>> image at the aux window? (If necessary, I could supply a better image
>> too. Please let me know.)
> 
> As you pointed, it'd be better to keep the current order of buttons. 
> I'll revise the onepager.
> And it'd be appreciated if you could provide a better Hanja image. :)
> 
>>
>> Would you please specify OSR numbers for Sun internal reviewers?
> 
> Sure, I'll revise the onepager.
>>
>> It appears to me that this project will require an ARC approval as
>> a fast track mainly due to imported interface of libhangul. For that,
>> the section 4.5 would need a little bit of update also possibly based on
>> the answers to the questions above.
> 
> I'll update the onepager soon.
> 
> Thanks again for your valuable advices.
> 
> Regards,
> Aijin
>