Currently, the following ‘mkmk’ code is auto-generated:
feature mkmk {
lookup mkmk_DFLT_bottom {
pos mark dotbelowcomb <anchor 200 -147> mark @mark_bottom;
...
} mkmk_DFLT_bottom;
lookup mkmk_DFLT_top {
pos mark dieresiscomb <anchor 200 566> mark @mark_top;
...
} mkmk_DFLT_top;
} mkmk;
I would suggest to add a MarkAttachmentType lookup-flag to each lookup which selects only the marks handled in the respective lookup, like so:
feature mkmk {
lookup mkmk_DFLT_bottom {
lookupflag MarkAttachmentType @mark_bottom;
pos mark dotbelowcomb <anchor 200 -147> mark @mark_bottom;
...
} mkmk_DFLT_bottom;
lookup mkmk_DFLT_top {
lookupflag MarkAttachmentType @mark_top;
pos mark dieresiscomb <anchor 200 566> mark @mark_top;
...
} mkmk_DFLT_top;
} mkmk;
Reasoning:
This allows marks of different positioning (top/bottom/…) to interleave and still attach correctly when decomposing precomposed glyphs.
Say I have the text /a/dotaccentcomb/dotbelowcomb/dotaccentcomb.
Normalization of the text transforms it into /adotaccent/dotbelowcomb/dotaccentcomb. But I want the /a and /dotaccentcomb to stay separate so that I can perform features on the base and the mark individually (e.g. substitute stacked marks by a more compact version to save space). Therefore, I decompose the /adotaccent in my ‘ccmp’ if it is followed by a combining mark, like so:
sub adotaccent' @CombiningAccents by a dotaccentcomb;
This results in the following glyph list:
/a/dotaccentcomb/dotbelowcomb/dotaccentcomb
Now the ‘mkmk’ feature is broken since I introduced a top-mark after the /a which is then followed by a bottom-mark /dotbelowcomb and then again a top-mark /dotaccentcomb. So while I can substitute marks with a more compact version, they do not attach anymore and overlay instead:
With the addition of the lookup-flag mentioned above, however, ‘mkmk’ can skip over bottom-marks when processing top-marks and vice-versa and all is good. This is what the output looks like with the lookup-flag set:
Notes:
- Source Serif Pro does the same in its mkmk.fea.
- Gentium does the same in its GentiumPlus_gpos_feats.fea (but with the
UseMarkFilteringSetflag instead ofMarkAttachmentType) - As I understand the AFDKO spec and OpenType spec,
MarkAttachmentTypeflag works for up to 15 class members.MarkAttachmentTypeworks in my tests, all of which have fewer than 15 class-members in@mark_topand@mark_bottom. For a generic, automatic implementation in GlyphsUseMarkFilteringSetmust probably be used for 16+ class-members. (Or in all cases but with reduced backwards compatibility sinceUseMarkFilteringSetwas added later to the OpenType spec.) - Test file: Test.glyphs (8.7 KB) This file has a manual ‘mkmk’ feature which can be enabled to see the effect of adding the lookup-flag. Since Glyphs appends manual ‘mkmk’ code to the automatic ‘mkmk’ code this is purely for demonstration as it adds a lot of redundant feature-code and requires manual adjustment of mark-classes/anchor-positions/etc.