[HarfBuzz] Mai Kang Lai in Tai Tham, summary draft

[Theppitak Karoonboonyanan]

On Tue, May 21, 2013 at 4:39 AM, Richard Wordingham
<richard.wordingham at ntlworld.com> wrote:
> On Mon, 20 May 2013 15:08:19 +0700
> Theppitak Karoonboonyanan <thep at linux.thai.net> wrote:
>
> For the recoding solution, you wrote:
>
> "A possible workaround is to exclude LA from the above rule. This is
> quite safe because NGA and LA are never conjoined in Pali grammar."
>
> While Pali doesn't have -ṅl- or -ṃl-, we do have Sanskrit influence
> to contend with.  Thus, although Pali for 'masculine' is _pullinga_, the
> MFL lists <BA, U, MAI KANG, LA, I, NGA, SAKOT, LOW KA> ปุงลิงคะ with
> this meaning. Given the dictionary's spelling habits, I half expected to
> see MAI KANG LAI sitting on the BA.  I don't think we can rely on MAI
> KANG LAI never sliding forward onto a LA.

OK. The example implies that งฺล conjunct is still possible even in Pali.
So, I've removed the workaround from the text.

The Unicode amendment may not help, either, as the use of MEDIAL LA
and side-subjoined LA is somewhat arbitrary.

> If we're going to go for a coding solution, I'd rather go for a new
> character.  However, out of ignorance, I have to ask - are non-shifted
> MAI KANG LAI and CONSONANT SIGN NGA different?  Lao Tham suggests they
> might be the same thing.

Yes, they are the same for Lao Tham. When used to write Pali, it's MAI
KANG LAI. When used to write Lao/Thai, it's FINAL NGA. But I heard
that the two are of different shapes in Khuen. So, they can't be used to
encode the same entity, I suppose.

> Another conceivable solution you mention is, "Fonts for Lao Tham and
> the shifting school of Lanna may provide GSUB rule to reorder Mai Kang
> Lai themselves."
>
> This goes against what I first learnt about GSUB.  I suppose it is
> tied up with how one handles editing of clusters of characters.
> Perhaps I'm just a semi-literate foreigner, but I frequently find
> myself having to edit 'legacy grapheme clusters'.  It's helpful when
> the cursor actually shows me where I am within the cluster - but that
> can only be done if the connection between characters and glyphs is
> maintained.  Using GSUB to change the order of characters destroys that
> information, which is why reordering is supposed to done by the
> script-specific shaping logic.

Understood. I've added some text describing the problem.

> I still haven't equipped myself to experiment with GPOS as a way of
> correcting the minor deficiencies of shaping.  I'm about two weeks away
> at my current rate of progress.

Let's add that to the page when you find some way out.

> However, I think we are at a point where Behdad can say what he thinks
> of the 'rphf' option.

Agreed.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/