googlefonts / fontc

Where in we pursue oxidizing (context: https://github.com/googlefonts/oxidize) fontmake.
Apache License 2.0
62 stars 10 forks source link

Glyphs non-spacing marks not added to GDEF GlyphClassDef mark class #850

Open simoncozens opened 3 weeks ago

simoncozens commented 3 weeks ago

This is a bug in the GDEF writer. If a glyph in Glyphs is set to category=Mark and subcategory=Nonspacing, it should be recorded as a mark glyph in GDEF; currently it's not appearing in the GDEF table at all.

cmyr commented 3 weeks ago

We currently do not have the equivalent of a GDEF feature writer period, and we do need one. ~I had thought that the GDEF table generated during FEA compilation would be useable, but since we are no longer generating FEA for marks the FEA compiler can't infer mark classes based on the FEA, which I had overlooked.~

edit: This was incorrect: fea-rs is computing glyph classes based on what glyphs are used as marks/bases/ligatures in the respective lookups; so if these glyphs are not being recorded as marks either they aren't being used as marks in any rule, or there is a bug somewhere?

My current feeling is that we should generate the various relevant bits of GDEF (the glyph categories as well as the ligature caret table... do we also generate the AttachList? I haven't thought about this table very much) while compiling marks, since all that data is there at that point, and then we can assemble everything after we've run the fea compilation step.

simoncozens commented 3 weeks ago

fea-rs is computing glyph classes based on what glyphs are used as marks/bases/ligatures in the respective lookups

Right. But this is the wrong thing to do.

so if these glyphs are not being recorded as marks either they aren't being used as marks in any rule

They're not used for attachment in any rule, true. But they're definitely used as mark glyphs. And I've explicitly said in the sources that I want them to be considered as marks, so that should be respected.

(In this case, Noto Nastaliq Urdu, they are marker glyphs which are used to record how much kerning should be applied. They're marks so that they can be ignored in other feature rules using lookup flags. And in combinations like beh-ar space0 twodotsbelow-ar, the dots need to attach to beh-ar; if space0 suddenly becomes a base glyph, they won't attach.)