Don't skip over spacing marks when kerning

[simoncozens]

Consider the following font:

We want to kern between ka-deva and ra-deva:

But (to do certain bits of OpenType magic) we make highspacingdot-deva a "spacing combining" mark (spacing mark). This is so we can filter it out when doing conjuncts or something like that. (This is slightly contrived, but an analogous situation does exist for many Indic scripts.)

We also want kerning between ka-deva and the mark, so we make a base-mark kern:

But because it's a mark class in GDEF, when we apply base-base kerning, this gets skipped. So with a sequence like ka-deva|highspacingdot-deva|ra-deva, the result, with current ufo2ft, is:

• kern_Deva will IgnoreMarks and kern ka-deva|ra-deva -250
• kern_Deva_marks will kern ka-deva|highspacingdot-deva -150.

Instead what we need to do is, rather than filtering out all marks, only filter out non-spacing marks, allowing spacing marks to break the base-base kern, so that only base-mark kerning is applied:

[anthrotype]

LGTM, thanks!

[khaledhosny]

How does this work? Many font sources have none spacing marks with +ve advances and rely on the compiler to zero them, would they be considered spacing marks in this context? Or the zeroing would have happened already at this point (but this cide would be noop then)?

[khaledhosny]

If this depends on Glyphs’s “Spacing Combining” sub category, then it probably should have checked for this, checking for glyph width feels like the kind of indirection that comes back to bite you in the rear.

[anthrotype]

Only non-spacing combining marks are zeroed by the compiler, spacing ones are not and as such have a non zero advance width.

[khaledhosny]

But spacing combining marks do not exist in OpenType nor AFDKO feature files, only in Glyphs, so what happens to sources not coming from Glyphs that happen to have marks with advance widths (which is harmless as the layout engine will be zerowing them for most scripts)?

[simoncozens]

If your sources say that a glyph has advance width, you should not be surprised when ufo2ft treats it as a glyph with advance width.

(And remember, the change here only affects the very specific case of ignoring marks in kerning between two bases. It doesn't change anything that's already happening or not happening with regard to mark width zeroing.)

[anthrotype]

spacing combining marks do not exist in OpenType nor AFDKO feature files, only in Glyphs

well, "spacing combining marks" do exist in unicode, general category "Mc", don't they?

[khaledhosny]

If your sources say that a glyph has advance width, you should not be surprised when ufo2ft treats it as a glyph with advance width.

They have the right glyph class, the fact that they have an advance width is irrelevant as the layout engine will zero them when shaping.

[khaledhosny]

spacing combining marks do not exist in OpenType nor AFDKO feature files, only in Glyphs

well, "spacing combining marks" do exist in unicode, general category "Mc", don't they?

But we are not using that here, and it is also irrelevant as OpenType knows only about only one class of mark glyphs and the font sets the glyph class, but we are second guessing its intentions based on a tangentially relevant heuristic. The whole concept of feature writers is broken beyond repair, but adding more surprising exceptions and heuristics tuned for individual fonts is not helping.

[khaledhosny]

Here is a more real example. Some monospace fonts, e.g. DejaVu Sans Mono, give combining marks an advance width (so that legacy systems that require all glyphs in monospace fonts to have the same adcance width would still recognize them as monospace) then zeros the width using GPOS single positioning lookups. Monospace fonts obviously don't need kerning, but this shows a combining mark can have an advance width while not being a spacing combining one.