Apache OpenOffice (AOO) Bugzilla – Issue 19822
pre-1933 orthography Korean support with U+1100 Hangul Jamos and opentype fonts for Korean
Last modified: 2013-08-07 15:00:01 UTC
Korean Hangul is a complex script that requires rendering with opentype fonts and caret movement based on syllables. (http://i18nl10n.com/korean/hunmin.html) MS Office XP has a full support of over 1.5 million Hangul syllables made up of sequences of Hangul Jamos (in U+1100, http://www.microsoft.com/typography/otfntdev/hangulot ) Mozilla can render all those HAngul syllables as well (http://bugzilla.mozilla.org/show_bug.cgi?id=176290 , http://bugzilla.mozilla.org/show_bug.cgi?id=177877 , http://bugzilla.mozilla.org/show_bug.cgi?id=176315) There's a patch to Pango for this (http://bugzilla.gnome.org/show_bug.cgi?id=95708 , http://bugzilla.gnome.org/show_bug.cgi?id=112467) Now that we have a free opentype font (http://www.i18nl10n.com/fonts/UnBatangOdal.ttf), openoffice has to support Korean (supporting only pre-composed syllable can hardly be regarded as full Korean support). Perhaps, an easy way to do that is to port my patches for Mozilla and Pango to ICU layout engine because I heard that openoffice already makes use of ICU layout engine to support Indic scripts.
DL->HDU: Would you please takeover?
The first task is to enable OpenType processing for Hangul Jamo. This fix is easy, I could easily put it into OOo 1.1.1 or SO7pp1. The problem with a 1.1.1 target would be, that the fix mentioned above would only work on XP, but not yet for our unix platforms, because the OOo 1.1.x version will still have ICU 2.2, which does not do process OpenType for Hangul scripts. For OOo 2.0 we will use ICU >= 2.6, which does Hangul OpenType processing. Could you assess if the quality of ICU's 2.6 layout engine is sufficient to properly layout complex Hangul? Is the OOo 2.0 target ok for you, or is this target too late? If not, I could apply the fix mentioned at the top of this comment which would fix the behaviour on XP immediately. For the unix platforms we could submit a followup issuezilla task to implement or backport Hangul OpenType processing to ICU's 2.2 layout engine. Since you are the expert in this field I'd love if you volunteered for it. What do you suggest?
Thank you for your kind explanation. However, I'm afraid I'm at loss because as far as I can tell, even the CVS trunk of ICU layout engine doesn't support (pre-1933 orthography) Hangul rendering with Hangul Opentype fonts. ICU's layout/LETypes.h has three enum values for 'ljmo', 'vjmo', and 'tjmo' defined, but that's about it. The cvs log doesn't have any trace of it, either. That's why I filed ICU bug 3274 (http://www.jtcsv.com/cgibin/icu-bugs/incoming?id=3274). If I'm mistaken about Hangul opentype support in ICU 2.6 or later, I'd be glad to stand corrected. As for Hangul opentype support on Windows XP (with the latest Uniscribe) or Win2k(with MS IE 6 that comes along with the latest Uniscribe), it's not perfect but acceptable. With some 'pre-processing' added (http://www.jtcsv.com/cgibin/icu-bugs/layout?id=2259), it'd be better (i.e OpenOffice can support Hangul better than MS Office XP). As for 2.0 target, I think it's reasonable given that ICU doesn't yet support Hangul rendering with ljmo/vjmo/tjmo GSUB features (assuming I am not missing anything).
I see now that just an upgrade to a new ICU version is not sufficient, thank you. Do you agree that the next step would be to implement the required Hangul processing in ICU? Once this is done we just need to enable complex layout processing for Hangul Jamo in vcl/source/gdi/outdev3.cxx's OuputDevice::ImplLayout(...) method: if( ((*pStr >= 0x0590) && (*pStr < 0x10A0)) + || ((*pStr >= 0x1100) && (*pStr < 0x1200)) // hangul jamo || ((*pStr >= 0x1700) && (*pStr < 0x1900)) In the meantime I'm assigning this issue back to you for the work on ICU's HangulLayoutEngine. Thank you very much for volunteering. When it is done please reassign this issue back to me, so we can integrate it all into OOo.
Yes, I agree that the pre-requisite to fixing this bug is to add Hangul opentype support to ICU's layout engine. Because I'm not familar with ICU's LE, I need some initial help about its overall structure and inner working to take off. I sent Eric Mader an email about the issue in addition to filing a bug at Jitterbug and am hoping to hear back from him soon. Once I'm done with Hangul OT support in ICU LE (which could take pretty long), I'll let you know and assign this bug back to you. Thanks.
taking. I'm still waiting for a reply from Eric Mader. Perhaps, I have to write to him once more.
Pointer issue 14640: Adding Hangul Jamo to scripts needing CTL processing.
Due to missing resources, this task has to be set the target 'OOo later'. If we do not get any responce in the next 4 weeks, we will close this enhancement.
I would like to see work on this issue done. Not having good hangul font rendering and importation of Hangul Office files make Openoffice much not a possiblity when dealing with documents written in Hangul. It like having not being able to import doc files here. Yes they are two diffrent issues but they work togeather to form a major block on use here.
Thanks for your interest. However, this issue should not prevent you from importing MS Office files in _modern_ Korean. This issue has to do with supporting pre-1933 orthography Korean text. It depends on implementing U+1100 Hangul Jamo rendering support in ICU rendering engine, but I have yet to hear back from Eric Mader. I'll try once more to ask him for some help with which I hope I'll be able to implement rendering Hangul (Jamos) with opentype fonts.
Reset assignee on issues not touched by assignee in more than 2000 days.