Re: Adding Tai Tham Script to GNU/Linux Distribution's Version of Emacs

[Richard Wordingham <richard.wordingham@ntlworld.com>]

On Thu, 19 Mar 2015 05:41:16 +0200
Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 18 Mar 2015 21:33:22 +0000
> > From: Richard Wordingham <richard.wordingham@ntlworld.com>
> > 
> > The problem is that function font-shape-gstring, defined in file
> > font.c, which *appears* to be the correct composition function,
> > does not grok the m17n FLT module, or at least not at Version 1.6.3.
> 
> That sounds pretty strange.  Have you tried to discuss this with m17n
> FLT developers?  Emacs is supposed to fit m17n very well, since the
> same developers contributed to both projects.

If one follows the Microsoft example of making an Indic orthographic
syllable a grapheme cluster, the problem largely (entirely?) goes away.
Moreover, apart from the swapping round of consonant and vowel or
dependent RA glyphs, the problem examples (bug 20140) all include U+1A60
TAI THAM SIGN SAKOT, which was quietly given a non-zero canonical
combining class despite the explicit recommendation in the encoding
proposal that it be given a canonical combining class of 0.  Its low,
positive canonical combining class (9 for virama) causes no end of minor
problems.

The main issue with m17n itself is that the from and to fields don't
handle discontiguous substrings.  Discontiguous substrings, typically
but not necessarily associated with canonical equivalence, are
generally not handled well.

There might be some more unusual (from, to) sequences once I get the
<NA, AA> ligature working.  It's not forming under m17n for some reason,
but Emacs is innocent.

Richard.