Move anchor propagation from glyphs-reader to fontir

[anthrotype]

Fixes #1704

This huge PR refactors anchor propagation to be source-agnostic by moving it from glyphs-reader (Glyphs-specific preprocessing) to fontir so that it works with not only for Glyphs sources but also for DS + UFOs or any other frontends.

GoogleSans.designspace markkern.txt goes from the current 82.760% to 97.262% (the remaining diffs are bugs on ufo2ft propagateAnchors filter's side which I'll fix separately).

The main problem when moving the implementation from glyphs-reader to fontir was that there was a circular dependency in the way GDEF categories are computed for Glyphs sources in particular, whereby on the one hand the anchor propagation algorithm needs mark/ligature information, but on the other hand some GDEF glyph categories (Base, Ligature) are inferred based on the presence of anchors and thus need anchors to be propagated first.
In the previous code on main, this wasn't a problem because glyphs-reader would use the glyph category/subCategory fields to do its propagate_anchors.rs, which would be performed at the very beginning when the Font was first loaded, so that by the time the GDEF categories were computed all the anchors (including propagated) would already be there.

To resolve the circularity, I resorted to a two-phase approach similar to the one we use for PreliminaryGlyphOrder vs GlyphOrder: i.e. first each frontends populate PreliminaryGdefCategories using only source metadata (such as Glyphs' category/subCategory or the UFO public.openTypeCategories) but without checking the anchors; then after anchor propagation is done inside fontir, the final GdefCategories are computed by also taking the anchors into account.
Note that for DS+UFOs workflow, the public.openTypeCategories are presumed to already be "final" and are not extented/pruned based on anchors (at least that's how ufo2ft treats these), so in fontc I follow this (source frontends can set a bool field on the PreliminaryGdefCategory struct to control whether final GdefCategories shoud be inferred from anchors or not).

I kept the current source-level defaults: i.e. for .glyphs source we run anchor propagation by default unless disabled via either "Propagate Anchors" (false) custom parameter (as well as a "propagateAnchors" ufo2ft filter hidden in the masters' userData which is a remnant of ufo2glyphs workflows); whereas for DS + UFO sources anchor propagation is disabled by default but it can be enabled via "propagateAnchors" filter in "com.github.googlei18n.ufo2ft.filters" lib key (like GoogleSans does). And in any case, a tri-state CLI flag --propagate-anchors={true,false} can be used to override these (omitted means follow source).

I ported all the tests from the previous implementation, while adding a few more, and deleted the glyphs-reader/src/propagate_anchors.rs.

I know it's a big change, and I tried to split into logical commits that make review easier as much as possible, but it's inevitable that a lot of modules are affected. I suggest to review single commits in the order the appear.

Last thing, #1661 is not implemented here yet but this should make it easier to implement since we are already interpolating glyph geometry in fontir (for decomposing and flattening) so adding anchor interpolation should be relatively simple.

EDIT: I also included in here a fix for propagating cursive anchors with suffixes from googlefonts/glyphsLib#1130

[cmyr]

no major notes on the impl, but this is causing a bunch of regressions for existing fonts.

Some examples of previously identical sources that are now producing diffs:

python3 -m ttx_diff 'https://github.com/mara-aa/elms-sans?bc5a52f349#sources/ElmsSans.glyphs'
python3 -m ttx_diff 'https://github.com/positype/Murecho-Project?0efba44c1c#sources/Murecho.glyphs'
python3 -m ttx_diff 'https://github.com/cyrealtype/Lora-Cyrillic?c44a1dde19#sources/Lora.glyphs'
python3 -m ttx_diff 'https://github.com/reddit/redditsans?60e19b50bd#sources/RedditMono.glyphs'
python3 -m ttx_diff 'https://github.com/solmatas/BitterPro?3238d7ae2c#sources/Bitter.glyphs'

[anthrotype]

Thanks for taking a look, I'll fix the regressions tomorrow!

[wmedrano]

Not actionable, just looking to learn.

In practice, how often do these flags change? Will user's want to experiment with propagate_anchors for the foreseeable future or is it a mechanism to roll out a feature that basically every user will leave alone.

[anthrotype]

it's mostly to be able to test the effect of anchor propagation (or its absence) without needing to modify the source itself. I'd expect users to prefer enabling/disabling this in the source via appropriate custom parameter (or ufo lib key).

[wmedrano]

I was confused for a second and thought these were all the same! What do you think of separating bytes with underscore?

0b100_00000000

[wmedrano]

This is used to build the StaticMetadata for fontra2fontir/src/source.rs. In that file, also_completes has not been updated. Does it get generated somewhere else for fontra or does fontra not need GDef categories?

StaticMetadataWork for fontir

impl Work<Context, WorkId, Error> for StaticMetadataWork {
    fn id(&self) -> WorkId {
        WorkId::StaticMetadata
    }

    fn also_completes(&self) -> Vec<WorkId> {
        vec![WorkId::PreliminaryGlyphOrder] // No PreliminaryGdef categories
    }

    fn exec(&self, context: &Context) -> Result<(), Error> {
        debug!("Static metadata for {:#?}", self.fontdata_file);
        context
            .preliminary_glyph_order
            .set(self.glyph_info.keys().cloned().collect());
        context
            .static_metadata
            .set(create_static_metadata(&self.fontdata_file)?);
        Ok(())
    }
}

[anthrotype]

I think this is ready for merge now. I've reviewed the 5 regressions that Colin reported back in December:

• ElmSans and Bitter are now identical (fixed by non-exporting glyph anchors fix 4132509)
• Murecho still has a diff in GDEF on this branch, but it becomes identical once Interpolate anchors when instantiating smart components #1885 is also merged
• RedditMono: the GDEF is now identical, but GPOS markkern.txt still contains a diff for "aeacute" because Anchor positions need to be interpolated during propagation #1661 is not implemented yet (but I have a branch that fixes this which I will push tomorrow)
• Lora has 1 extra GDEF Base entry + 1 extra MarkToBase rule for "cedilla". This one is the most problematic and I am not sure if/how to fix...

The "cedilla" is a composite glyph referencing "cedillacomb" as a component. In Glyphs.app's GlyphData.xml, "cedilla" has category=Mark, subcategory=Spacing (which is a bit of a misnomer since these are not combining marks, the Unicode category is "Sk" modifier symbol). Glyphs.app skips anchor propagation for category=Mark composite glyphs that already have their own anchors, it keeps them as-is without looking at components. This means cedilla (which happens to have "_bottom" in Lora) keeps only that anchor and doesn't inherit "bottom" from cedillacomb. As a result, fontmake doesn't classify it as GDEF Base, and doesn't add MarkToBase for "cedilla".
fontc only skips propagation for GDEF Mark glyphs, which are defined as Glyphs category=Mark and subCategory=Nonspacing or SpacingCombining. Since Mark/Spacing glyphs like cedilla are not GDEF Mark (they're spacing glyphs that shouldn't act as marks in GPOS), fontc propagates cedillacomb's bottom anchor into cedilla, which causes it to be inferred as GDEF Base and generates one extra MarkToBase rule.

I think fontc's behavior is defensible here:

• cedilla is not a combining mark (Unicode Sk, not Mn/Mc)
• Mark/Spacing glyphs are not marks in the OpenType sense (not GDEF Mark class)
• The _bottom anchor on cedilla is arguably a font bug, a non-combining spacing glyph shouldn't need a mark attachment anchor
• Glyphs.app's blanket category=Mark skip is an implementation shortcut, not a principled rule.

I considered these alternatives to match fontmake for Lora, none of which i'm 100% happy with:

1. Add something like marks_for_propagation: BTreeSet<GlyphName> to PreliminaryGdefCategories to track all source-level category=Mark glyphs (regardless of subcategory) and use that set alongside the GDEF Mark check when deciding whether to skip propagation. This works (verified Lora identical) but leaks a Glyphs-specific concept into the format-agnostic IR layer (would default to empty for UFO sources, which don't have this distinction).
2. Change glyphsLib to match fontc: only skip propagation for true marks (Mark/Nonspacing and Mark/SpacingCombining), not Mark/Spacing. This would align with Unicode and OpenType definition of a mark, but also deviate from Glyphs.app which is supposed to be the reference implementation for .glyphs sources (I verified that "bottom" is not propagated to "cedilla" in Glyphs.app).
3. Use some heuristic to treat glyphs containing underscore-prefixed anchors as mark-like. Simple change, but conflates a coincidental signal (presence of underscore anchors) with the actual source-level Mark category. It would work with this particular diff in Lora's cedilla, but it may have unwanted side effects.

I'm tempted to merge this PR now and file an issue about Lora to fix later.

[cmyr]

okay happy to checkpoint this and then go from there :)