Should the presence of anchors overwrite or warn if they contradict set categories/subcategories?

[kontur]

I was investigating an issue compiling from a GlyphsApp source to UFO with fontmake and found that although I had anchors set in some glyphs, they would not generate the correct mark attachments down the line. To my surprise, the categories/subcategories set in GlyphsApp for some unencoded custom glyphs take precedence over what anchors are actually found in the glyph design.

e.g.:

• a foo_bar glyph was automatically categorized as "Letter"/"Combining" and would not receive mark attachment for top anchors; only when explicitly setting it to "Letter"/"Letter" would the attachment work
• a foobar.calt mark glyph was automatically categorized as "Mark"/"Spacing" and would not be included in markClass definitions despite having _top anchors; only when setting as "Mark"/"Non-spacing" would the attachment work

This was evident from the generated UFO lib.plist <key>public.openTypeCategories</key> as well as keys in the glif files.

Would it not make sense to at least warn, or even overwrite, those categories written to the UFO, if they are contradicting with the anchors found in those glyphs?

Where is the exact code for how categories/subcategories get sorted into base/mark openTypeCategories and is a straight mapping the best metric here, seeing as GlyphsApp "guesses" wrong or uses categories that contradict the anchors?

I'm thinking, simply:

• the presence of a underscored anchor should warn/fix if a glyph is not in the mark category
• the presence of an anchor should warn/fix if the glyph is not in the base category

[schriftgestalt]

Anchors can be defined for aligning the components. So it needs a way to decide what glyphs should be used for the mark/mkmk feature. That is what the category/subCategory are meant for.

[khaledhosny]

I think a ligature glyph should be allowed to get a non-ligature anchor. I tested this before and it works in HarfBuzz, so ufo2ft shouldn’t prevent it. It might be a mistake, so a warning might help in this case, but it also can be intentional and the warning will be annoying in this case. We don’t have a readily way to selective suppress warnings, I’d side with no warning. Garbage in, garage out.

A base glyph getting a ligature anchor probably makes no much sense, but it might be useful for something so I don’t see why we should to get out of our way to prevent it. Again, garbage in, garbage out.

The really must-respect category is mark, because if the glyph is not mark it won’t attach in mark to base or mark to ligature lookups, or be base in mark to mark lookups.