Hi,
I generated an OTF with Glyphs 2.3.1 (905). The GPOS has a line in the kern feature:
IgnoreMarks yes
When I generated the same file a few months back, the same line read:
IgnoreMarks no
Nothing has changed in the file, so has something changed in Glyphs to cause this?
I guess my version of Glyphs has been updated since the first time I generated the font.
Also does it make any difference if it is yes or no?
Regards,
Alistair
What scripts are you having it that file?
Yes, this is a change in Glyphs. I think it’s a result of working on the Southeast Asian scripts, where we needed to be able to kern bases from each other without the marks interrupting the kerning lookups. For cases where bases need to be kerned off a mark, as with cases of contextual kerning, we have to write manual GPOS lookups.
Yes, this is in a Thai script. Thanks for the information.
Georg, I wonder if there would be a way to compile the Thai contextual GPOS lookups automatically. As you know, the tall vowels โ ใ ไ may crash into preceding marks above, and perhaps any kern pairs between those marks and the tall vowels could be checked and written into the kern feature? That way the kerning could be different for each instance (without using instance-specific replaceFeature) and interpolatable (whereas manually entered pos aboveMark tallVowel' <150 0 150 0>; declarations are not). (BTW same behaviour in Lao with ໂ ໃ ໄ.)
I wonder about that, too. Any new insights on this particular issue? What’s the best strategy? I failed with manual kerning since the topMarks seem to be ignored in the kerning (e.g. ด้ใ) and cannot figure out how to make the kern feature working without using any of these groups in the regular kerning. Seems all very hacky to me 
The difficulty is that different designs will call for different kerning strategies.
The left sidebearings of โ ใ ไ need not to be too big, otherwise when occurring line-initially, they will cause an indent in a block of text.
Some designs will have abovemarks that extend far to the right (mai tho and mai tri the most) of the base consonant on which they sit, and โ ใ ไ should be positively kerned away from these.
However, abovemark vowels ิีึื may also require that โ ใ ไ are positively kerned also.
Now, the problem arises when those four abovemark vowels also have tone marks in the upstairs slot. Some designs (particularly UI fonts where things are squished vertically) may require the upstairs slots to also require โ ใ ไ kerning, and other designs may have these upstairs marks far enough above the level of โ ใ ไ to make kerning unnecessary.
If the upstairs marks do require kerning, do we then also have to factor in any existing kerning of the abovemark vowels ิีึื with โ ใ ไ? There’s no single answer, and in many cases the kerning will need to be contextual…every combination of vowel mark and tone mark will have to be tested, I’m afraid.
If there’s any nice way that this can be given a graphical UI and written into the kern feature automatically I’d love to hear about it. As mentioned above, writing a manual kern feature for each instance is not very efficient, nor interpolatable.
Note also there will be the same questions in Lao.
Thanks for that, Ben. My question also mainly targeted towards the technical procedure. The lack of interpolation and/or different values for different masters (well, of course one could find/replace feature code in a custom parameter) in a kern feature is something I somehow would like to refuse. Getting the values is rather a trial-and-error workflow and I don’t like the idea to have several kernings in different places of the file and UI.
1)
I guess that the neglection of the abovemark in the basic kerning is due to the fact that it is categorized as non-spacing? Would it help to change the category in info for selection?
2)
What would the feature code has to look like exactly? There is a discrepancy in my sources:
# Adobe:
position A Y -100;
# Glyphs Forum:
pos @MMK_L_A' -100 @MMK_R_Y;
3)
What about the mentioned activation of the kerning group in the hand written kern feature code? How exactly does it have to be triggered in the basic kerning? Will I kern these just into the blue out of nowhere and then overwrite the value(s) in the kern code?
Re Tool:
If I’d understand the exact problem and a possible solution, I could indeed develop a tool to ease that issue up. Time for that doesn’t fit into my current workload, though. But, at least generating the feature code is probably pretty quickly written as a makeshift script.
Yes, I would like to refuse this too.
Not sure. But note that it’s necessary for marks to normally be ignored so that pairs of base consonants can be kerned correctly. Changing a mark to something else might interrupt those base consonant kern pairs.
I’ll email you en example.
If I understand your question right, I found the right positioning after the marks using the normal kern UI, and then noted those values into the manual kern lookup.
You’re right, changing the non-spacing would cause more trouble than solving anything 
Thx!
I was referring to the statement of @mekkablue »Please note that there must be at least one regular kerning pair employing the groups you want to use, otherwise it won’t work.« As I understand this (and please correct me if I’m wrong): I can write kern code manually, but in order to see anything happening, I have to employ kerning for these called groups manually in the Glyphs UI. Only then the manually written kern code will have any effect. I find it really weird to do that. Really weird.
I think I get more confused 
Edit:
So as I can see in Ben’s example code, the kern classes doesn’t have to be declared as sth like »@MMK_L_XXX« but can be defined the usual OT-Feature code style. I tried with a random sample and I can get this to work. Now I am one tiny step closer. At least it works somehow The interpolation and try/error are still issues to be solved.
Ben, with your code I can make it work. So I won’t use Rainer’s proposal to employ the glyphsapp kerning groups (@MMK_L_etc)
This was about reusing existing kerning groups in your manual feature code. If a kerning groups is not used anywhere in the font, Glyphs will not write it into the features.fea. I do not think this is weird, because it keeps your font file free of redundant data, and therefore, small. The downside is, of course, is that if you want to reference such a kerning group in your manual feature code, it must be used at least once. But in that case, one can simply build one’s own OT groups.
Ah, good, I see.
Used? What does that mean? If I specify a kerning class in my manual feature code, isn’t that already using it?
The check for usage is not looking into the manual feature code. Only in the kern data.
No, but a zero-kerning pair would constitute usage. The kerning subsetting algorithm does not go through the manual feature code, and it probably should not, because parsing it may be less trivial than one should assume.
So we have a choice when using kern classes in manual kern lookups: a) write manual kern feature using kerning classes defined explicitly in the OT panel b) reference kern groups contained in the kern table, ensuring that those kern groups have kerning pairs defined (‘defined’ includes kerning values of zero).
Is there any functional difference between the two approaches? I’ve been following approach a) and would be happy to stick with it, but if there are any advantages/disadvantages it would be good to know.
Yes.
No.
Okay, now I understand the whole thing (way better) thanks @all for clarifying!