Ba_aa-khmer ligature problem

Scripting
1

I’m having a serious issue with getting the ba_aa-khmer ligature to correctly render with a coeng consonant. In logical order

ba-khmer + coeng-khmer + ka-khmer + aasign-khmer, should render correctly to look like ប្កា= ប ្ ក ា

11%20PM

in order to avoid the graphical representation of ba-khmer + aasign-khmer ប ា (which would give you the consonant ha-khmer ហ).

I need only the ba-khmer to be substitued out for its ba_aa ligature បា - everything else including the coeng subscript and aasign vowel should be displayed, but you cannot have this type of rule in the features:

sub ba-khmer coeng_ka.liga’ aasign-khmer by baaa.liga;

I know my code is cumbersome, but I opted for just replacing the entire cluster of characters into one glyph called bkaaa.liga (ba-coengka-aasign) by the feature

sub ba-khmer’ coengka.liga’ aasign-khmer’ by bkaaa.liga;

No problem getting the bkaaa.liga glyph to render properly when typed into the correct order, however, after typing the necessary letters to produce this glyph, all letters after are placed immediately to the left of the glyph instead of continuing onto the right side.

My question is, is Glyhph app smart enough to know how vowel marks positional placement in Khmer (and nearly all indic scripts) can be either before, after, above and below each consonant? And are those rules built into each vowel automatically or must I manually produce each imaginable cluster and possible pairings for each consonant + subscript (coeng)?

Also, is there a more efficient feature code to dealing with ba_aa-khmer with the coeng cluster? If so, please help me build up a better code to substitute ba-khmer for its ligature when dealing with a coeng as part of its cluster.

Feature code:

sub coeng-khmer ka-khmer by coengka.blwf;
04%20PM
sub ba-khmer aasign-khmer by baaa.liga;
31%20PM

ideally I would like to produce ប្កា with the following code
sub ba-khmer coengka.blwf’ aasign-khmer by baaa_aa.liga;

I haven’t explored mark filtering, but these feature codes are getting more complicated the larger the consonant-subscript-vowel clusters get.

2

I would need to see the feature code. And do you know about mark filtering? That might solve the problem of the extra glyphs (“everything else including the coeng subscript”).

3

I’m still new at building the my own custom features for glyphs app and I can just copy and paste my glyphs onto an existing khmer font with its native feature codes, but there is not any unified standard on features. This becomes a huge problem when you need to add a different looking ligature, or extend the length of the arm of a subscript, or add stylistic serifs to consonants and hopes that the unique aesthetics fit with the font.

What does Mark Filtering entail and how can I utilize that to solve the baaa.liga with the coengka.blwf to attach directly to baaa.liga’s left side? Perhaps I can make another coengka.blwf but extend its LSB more? In either case, the ba-khmer has to be changed to its ligature form in that sequence of ba-khmer coeng-khmer (any consoant-khmer) aasign-khmer and keep only the coeng.

4

The code doesn’t need to be any different for Ba_aa than for any other consonant_aa ligature. (Yes, the glyph shape is different but the placement of marks above or below is always in relation to the consonant part).

I don’t think you need mark filtering. Just add an IgnoreMarks declaration in the ligature lookup:

lookup aaLigs {
	lookupflag IgnoreMarks;
		sub ka-khmer aaSign-khmer by ka_aa-khmer;
		sub ka-khmer au-khmer.post by ka_aq-khmer;
		sub kha-khmer aaSign-khmer by kha_aa-khmer;
		sub kha-khmer au-khmer.post by kha_aq-khmer;
		...
} aaLigs;

That will allow the ligatures to form even when marks such as the coeng consonants are present (so make sure the coeng lookup is before this one). Then all you need to do is make sure your anchors on the ligature are in the right place.

1 Like