Skip unhandled marks in ‘mkmk’

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 UseMarkFilteringSet flag instead of MarkAttachmentType)
  • As I understand the AFDKO spec and OpenType spec, MarkAttachmentType flag works for up to 15 class members. MarkAttachmentType works in my tests, all of which have fewer than 15 class-members in @mark_top and @mark_bottom. For a generic, automatic implementation in Glyphs UseMarkFilteringSet must probably be used for 16+ class-members. (Or in all cases but with reduced backwards compatibility since UseMarkFilteringSet was 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.

I second this request, as I need it for my Arabic fonts and glyphs does not allow controlling lookup flags for generated features.

UseMarkFilteringSet allows overlapping sets, too, while MarkAttachmentType does not. I’d forget about MarkAttachmentType as it only matter for very ancient OpenType implementations that do not support UseMarkFilteringSet.

1 Like

As a workaround you can open ~/Library/Application Support/Glyphs 3/Temp/YOUR_FONT/features.fea, copy the ‘mkmk’ section, paste it into the Features-tab as a manual ‘mkmk’ and add the lookup-flags yourself. But as mentioned in my 4. note above, this creates a lot of redundant feature-code since the automatic ‘mkmk’ is still processed in addition to the manual code.

Good to know! I was hesitant to suggest the UseMarkFilteringSet flag, as I don’t have any idea of which versions of OpenType are considered “ancient” and which still need to be supported. Is there an overview somewhere where I can lookup which OpenType version has which marketshare, user-base, or similar?

Or use fontmake, as I just found out that it sets UseMarkFilteringSet on mkmk lookups.

No idea, you will need to test it in the applications/implementations you care about. HarfBuzz, DirectWrite/Uniscribe, and Core Text support it for sure, no idea about Adobe implementations but these are often the ones left behind.

Glyphs uses UseMarkFilteringSet in other parts pf the feature code without a problem for year now. So that shouldn’t be a problem. I’ll have a look.

Have there been any progress in this. I’m working on an Arabic fonts with decomposed glyphs (beh-ar gets decomposed to behDotless-ar and dotbelow-ar etc.), and mark positioning over glyphs with multiple marks is broken. Fonts generated with fontmake don’t suffer from this because ufo2ft have the UseMarkFilteringSet lookup flag.

Added UseMarkFilteringSet to the mkmk feature.

2 Likes

Just found out that the UseMarkFilteringSet is messing with something else: When you have a mark at the top and anchor and need a mkmk to a different anchor. This can happen in Khmer.

1 Like

Was the addition of UseMarkFilteringSet reverted, I came across this issue again and was pretty sure it have been working at some point, but I opened the generated feature file and there were not any UseMarkFilteringSet in it.

I don’t understand the point being raised here. Do you have an example?