[HarfBuzz] Hangul GSUB features

Jonathan Kew jfkthame at googlemail.com
Sat Jan 25 07:43:48 PST 2014


On 25/1/14 03:14, Dohyun Kim wrote:

>
> Even after removing syllable decomposition table in ccmp and
> recompositon table in liga, jieubsida fonts will still have an issue
> regarding the case 4, that is multiple jamos to be composed to single
> jamo. If current hangul shaper could be modified so that it would not
> touch upon this sort of jamo sequence, then everybody would be happy.
>
> In other words, I propose that hangul shaper should not compose jamo
> sequence as follows to precomposed syllable even though it is
> composable:
>
>          <L, L, V> should not be compsed to <L, LV> but leave it as untouched.
>          <L, V, V> should not be composed to <LV, V> but leave it as untouched.
>          <L, L, V, T> should not be composed to <L, LVT> but leave it
> as untouched.
>          <L, V, T, T> should not be composed to <LVT, T> but leave it
> as untouched.
>
> Can this request be easily imported to current hangul shaper? If
> positive, then the remaining process could be done with opentype gsub
> features such as ccmp, calt, or other "global" features, even if *jmo
> feaures are not applicable. If the answer is negative, I don't care
> that much however, as these jamo sequences are not valid under the
> domestic standard KS X 1026-1.

We could do this, although I'm a bit reluctant to do so, as discussed in 
my response to Matthew.

In addition to my main concern - that making non-canonically-equivalent 
sequences behave as though they were identical is actually unhelpful, 
because it creates hidden incompatibilities with other text and systems 
- there'd probably be a (slight) performance impact on all Korean text 
because of the additional checking of context.

Then there'd also be the question of whether a sequence like <L, L, LVT> 
should actually be decomposed to <L, L, L, V, T>, in case the three L 
jamos want to compose themselves into a single complex L. If we don't do 
this, cases that *are* canonically equivalent might no longer render the 
same.

I really don't think we want to start down that path.

JK



More information about the HarfBuzz mailing list