[HarfBuzz] Tai Tham NGA, SAKOT is not Kinzi

[Richard Wordingham]

On Fri, 12 Apr 2013 15:04:52 +0700
Theppitak Karoonboonyanan <thep at linux.thai.net> wrote:

> On Thu, Apr 11, 2013 at 6:08 AM, Richard Wordingham
> <richard.wordingham at ntlworld.com> wrote:
>> On Wed, 10 Apr 2013 13:08:06 +0700
>> Theppitak Karoonboonyanan <thep at linux.thai.net> wrote:

> I'd like to see some sample, for education's sake. Especially, is it
> explicitly explained in words?

I've uploaded some examples of mai kang lai associated with the
preceding consonant at
http://homepage.ntlworld.com/richard.wordingham/lanna/maikanglai.pdf .
There is not much explanation.

The Tai Khuen sample happens to include an example of _ruup_ written
with <SAKOT, BA> below and to the right of RA and with UU to the right
of <SAKOT, BA>.  

> >> If so, and if "tanglai" invalidates the use of kinzi model, how
> >> about having the rendering engine preprocess it without SAKOT? For
> >> example: <SA, MAI KANG LAI, LOW KHA, E, AA> ->
> >> <SA, E, LOW KHA, MAI KANG LAI, AA>.
> >
> > If a font is to replicate the style of the handbook, can a GPOS
> > table effectively rearrange the latter back to look like SA, MAI
> > KANG LAI, E, LOW KHA, AA?
> 
> The same question applies to the other style as well. Can the GPOS
> do the same to shift it to second consonant on the lack of
> preprocessing?

I believe mai kang lai should normally be positioned using a 'mark to
base' attachment.  That requires that the base precede the mark in glyph
order.  So no, I believe GPOS cannot shift it to the second
consonant.

If GPOS works on the whole string, rather than just a single syllable,
I think GPOS can undo the rearrangement.  My reading of the code is
that GPOS works on the whole string.

I am therefore leaning to the view that the rendering engine should
offer the capability to move MAI KANG LAI to after the next
consonant or consonant symbol.  This supports _tanglai_ with mai
kang lai.  This does not seem to fit in well with the form of the
rearrangement rules.

> In fact, my font also features some complicated GSUB rules to handle
> this, which I try to get rid of by the aids of rendering engine.
> Meanwhile, doing so would cause the other school to bear the same
> load instead.

I think the rearrangement should be optional.  A font should signal to
the rendering engine whether rearrangement should be performed.

> The question is, which one should be the default, and which one
> should be the exception?

With my signalling idea, neither is the default.

> As we discuss so far, only some parts of
> Lanna (which I haven't seen myself yet) advocates the non-shifting
> Mai Kang Lai, while Khuen, Lao, and the other parts of Lanna itself,
> all advocate the shifting version. (That's why it's called "Mai Kang
> Lai", isn't it?)

Khuen has mai kang lai in the same syllable as the first
consonant; Lao in the same syllable as the second syllable.  Doesn't
the name just come from the shape?  'Eel-like mai kang' would not be
too bad an English name.

> Meanwhile, Lanna seems to be more dynamic in styles, which makes
> things more complicated. For Lao, there is only one school. So, it's
> less problematic to bear the complication. But what about the
> shifting school of Khuen/Lanna?

> Another way, which I think most users tend to abuse already, is to
> encode it in semi-visual order, such as <HIGH SA, LOW KHA, MAI KANG
> LAI, E, AA>. Can we accept that?

I hate what that does to the spelling of Pali.  I don't think we want
confusing variation in its spelling.

> > Going through the Tai Khuen passages in that book, I found a case
> > (on p.150) where <HIGH SA, MAI KANG LAI, LOW KHA> had a line break
> > before the LOW KHA.  That may have been a mistake, and I'm not sure
> > how significant it is to rendering.
> 
> I have only seen counter-examples in Lao Tham. For example, the word
> <MA, U, MAI KANG LAI, LOW KA, U, RA> is seen in a palm leaf
> manuscript to break between <U> and <MAI KANG LAI>, with <MAI KANG
> LAI> over <LOW KA> on the next line.

This difference in line-breaking is exactly what I would expect.  For
applications, the fallback rule would be to not break on either side of
MAI KANG LAI.

Richard.