Anchor propagation differences between ufo2ft and Glyphs
Opened this issue · 7 comments
Rendering the sequence H᷊́Hͬ͏̗ in Noto Sans, as compiled by Glyphs, looks like this:
Fontmake, on the other hand, does this, which is wrong:
This is because rcombbelow is made up of a component r plus a _below anchor, and ufo2ft propagates all anchors of the r component (i.e. above and below) so the resulting rcombbelow glyph has an above mark-to-mark anchor.
However! The sequence H᷊᷊ looks like this in Glyphs:
It feels like Glyphs just doesn't propagate any anchors to mark glyphs. Fontmake, on the other hand, gets it right:
I don't know if there's a good solution here, but the results should at least be consistent.
(Tagging @schriftgestalt because the second example is also, arguably, a Glyphs bug.)
The anchor propagation stops when it finds any underscore-anchor. Because it is not clear what anchors are stil valid. When you would use a component to "rcomb", then you can’t use any of the existing anchors.
So the "rbelowcomb" needs a "_below" and a "below" anchor to properly support mkmk.
OK, I suppose that's a reasonable position to take; the only alternative is to get into weird heuristics to determine whether a mark-to-mark anchor should be propagated (i.e. if your glyph has _bottom, you should not propagate top, you should propagate bottom but what you should do with bottomleft is a mystery).
I guess we should probably do the same thing. Thoughts, @anthrotype?
composite glyph anchor propagation is just a mess, it's entirely undocumented, we have three implementations of it (one in ufo2ft, another in glypshLib, plus of course Glyphs.app's own black box) and nobody except Georg seems to be confident about how exactly it is supposed to work, considering all the various edge cases and hacks accummulated over the years.
I'm dreading the time when I will have to implement this in fontc...
ok apologies for the rant.
I guess we should probably do the same thing
I read this post several times, and I am still not sure what "the same thing" actually means. If you send a PR maybe it's easier to understand what exactly you mean.
Just a reminder, that the ufo2ft propagateAnchors filter is not normally used by fontmake, unless one is building a DS+UFO set of sources ahd has explicitly opted in via the filters lib key; when you build from a .glyphs source it is actually the glyphsLib anchor_propagation.py module that is being used, so the current issue might be misplaced.
It feels like Glyphs just doesn't propagate any anchors to mark glyphs.
I believe @schriftgestalt once confirmed this in another thread googlefonts/glyphsLib#368 (comment)
- If it is a Mark and there are anchors, it will not look into components.
... but it looks like we never actually fixed our implementation(s) to match that. We should
That's what I mean - "we should do the same" as Glyphs does in not propagating anchors in the mark-to-mark case.