On Fri, 12 Apr 2013 15:04:52 +0700 Theppitak Karoonboonyanan <[email protected]> wrote:
> On Thu, Apr 11, 2013 at 6:08 AM, Richard Wordingham > <[email protected]> wrote: >> On Wed, 10 Apr 2013 13:08:06 +0700 >> Theppitak Karoonboonyanan <[email protected]> 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. _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
