Open simoncozens opened 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.
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.)
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.