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

[Aijin Kim]

Sorry, I misunderstood the EOF process.
I'm going to prepare EOF of Hanja Tool and KOLE, and revise the onepager 
accordingly.

Thanks,
Aijin


Aijin Kim 쓴 글:
> Hi Ienup,
>
> I have a few questions.
>
> Ienup Sung wrote:
>> 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.)
>>   
>
> - In terms of S10UR, the existing KOLE won't be removed. Then we don't 
> have to go with EOF process, do we?
> - If HangulLE replace all the feature of KOLE, don't we have to apply 
> EOF of KOLE?
>> 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.
>>   
>
> Currently, there are community discussions how to support user-defined 
> dictionary in libhangul. If a new feature is provided by libhangul, 
> libhangul will also be able to replace Hanja Tool in future.
> I think we'd better to wait for new version of libhangul and leverage 
> community's work. However, in this case, we need to apply EOF of Hanja 
> Tool in Nevada.
>
>> 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.
>>   
>
> Thanks for your help!
> I'm going to send the source to you.
>
> Thanks again,
> Aijin
>
>> 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
>>>
>>>     
>>
>> _______________________________________________
>> g11n-ko-discuss mailing list
>> g11n-ko-discuss at opensolaris.org
>>   
>