Does Fontmake correct path direction when building static TTFs, but not variable TTFs?

[arrowtype]

I recently chased down an issue wherein dot components were rendering too light on macOS, and finally found that it was because bases like /idotless had an opposite winding direction from dots like /dotcomb and /dieresiscomb. Here’s a screenshot of the problem:

Here’s a test site and open repo reproducing the issue: https://arrowtype.github.io/vf-dot-comp-test/

/idotless and /dotcomb from a problem source

The exported variable font

In a variable font build, FontMake reverses path directions. In https://github.com/googlefonts/fontmake/issues/489, @anthrotype says that FontMake:

assumes that for PostScript outlines the designer (or the font editor) has correctly set the outlines in counter-clockwise direction, and thus when converting to TrueType it simply reverses the directions to get the recommended clockwise direction.

That is reasonable enough (even if I would prefer FontMake to do the corrections). However, the confusing thing is that it seems like the corrections are made for static TTF fonts (below).

Images of the exported static font

In a static TTF output from the same "problem" designspace, strokes appear to have been corrected. Though, I haven’t looked super closely in a TTX dump, so it’s possible RoboFont is doing the corrections... but I doubt it would.

/idotless and /dotcomb from a source that corrects the issue

Meanwhile, if those bases & marks have paths pointing in the same direction in the sources (whether clockwise or counter-clockwise), it seems to fix the issue.

My question

So, does FontMake correct path directions for static TTFs? And if so, could it make corrections for variable TTFs?

Stroke direction is slightly hard/annoying to pay attention to as a designer, and I bet that many designers don’t think they need to think about it beyond reversing strokes to make counters. I have drawn fonts for quite a few years, and I literally never thought the CW/CCW winding was something I had to pay attention to as a designer – until doing these tests yesterday.

It seems like FontMake might be doing the helpful thing already in some cases (static TTFs), so if this is relatively simple to extend to variable builds, I think it would be a small but meaningful upgrade!

Thanks for any thoughts, advice, insights, and answers! And thanks, as always, to everyone who contributes to FontMake.

[belluzj]

It might be the overlap removal that corrects the path direction for static fonts? If so, you wouldn't want to run it on VFs, because you want to keep the overlaps there.

[anthrotype]

ufo2ft.preProcessor reverses the contour directions for both static and variable TTFs (reverseDirection=True by default for both). It simply flips them whatever they were to begin with. I believe Jany is correct, the difference b/w static vs VFs is the fact that only in the former there's the removeOverlaps step, and there (at least in skia-pathops, not 100% sure about booleanOperations/pyclipper) we have code to fix contour winding direction, but that only makes sens for simplified paths which don't intersect with themselves or one another (i.e. after overlap removal), VF sources usually (should) contain overlaps.

[anthrotype]

but this discovery you made about macOS font rendering being sensible about path direction is quite curious, it's actually the first time that I see the CW/CCW contour direction make a meaningful visual impact; i'd always assumed it was one of those legacy OT/TT spec recommendations that didn't really make a difference in practice..

[arrowtype]

the difference b/w static vs VFs is the fact that only in the former there's the removeOverlaps step, and there (at least in skia-pathops, not 100% sure about booleanOperations/pyclipper) we have code to fix contour winding direction, but that only makes sens for simplified paths which don't intersect with themselves or one another

Ahhhh this makes a lot of sense! Thank you for pointing out the reason static fonts were getting that help.

Indeed, my variable fonts have a lot of overlaps that would probably make a path-fixing solution a challenge to make, and I’m sure that making a universal path direction correction step would be a much bigger challenge. Designers want to do a lot of creative stuff with curves structure, and I’m sure I haven’t considered or tried a lot of the possibilities.

I suppose if a path correction step were to ever be added to variable builds, it would probably be important to have an option to skip it, or perhaps even the possibility to provide args to skip certain glyphs by name. That way, even if the code tripped up on certain edge cases, users could go around such issues. Then again, I can understand if this doesn’t merit work in FontMake – potentially, this is something that Apple could/should just fix in macOS rendering.

it's actually the first time that I see the CW/CCW contour direction make a meaningful visual impact; i'd always assumed it was one of those legacy OT/TT spec recommendations that didn't really make a difference in practice..

Same here! I’m glad I wasn’t the only one who thought this was a legacy thing that didn’t really matter in modern fonts.

For now, I will probably add a step to my build to set the path direction of any glyph with a single contour, and that would at least handle things like /idotless and /dotcomb, where this issue is most visually obvious. In the long run, I guess I will try to be more consistent about setting CCW path direction when I draw, and I’ll be on the lookout for a tool that might help me do that.

[arrowtype]

For now, I will probably add a step to my build to set the path direction of any glyph with a single contour

As a little update, in case anyone else comes across this and intends to fix the same thing... It isn’t quite this simple.

I used a basic script to orient all paths in single-contour glyphs, and that ALMOST worked, but it failed on some glyphs that have a single contour overlapping a multi-contour component. For example, the slashed zero:

As mentioned above, however, it wouldn’t be trivial to script a universal fix for all such glyphs. BUT, it’s not that many glyphs for me: basically just the zero slashed and Oslash. One approach to fixing this would be opening the set of fonts in GlyphsApp and testing their "Correct Path Directions" function. For my current project, this would be quite a few UFOs, including support/sparse sources, so I’d rather not try to open them all in GlyphsApp.

Instead, I made a couple of script to find and fix issues in a lot of UFOs. Here they are, in case anyone else ends up wanting to do this:

https://gist.github.com/arrowtype/98e98405d1575672f86fdce307c11b08

[arrowtype]

Oh, lol. There is already a method for this in FontParts!

BaseGlyph.correctDirection()

I’ll probably shift to this, as it could probably work well right in my build prep rather than being a separate process.

[arrowtype]

As a final (?) update here, I used the FontParts method BaseGlyph.correctDirection() to correct most directions, and it worked better than my quick scripts. However, it still had a few flaws which required additional correction (notably, the zero was an issue, despite a simple two-contour construction). A won glyph with a stroke that disappeared into the center of an outer contour was also a problem, but that is more obvious, as it’s easy to see why a central stroke / rectangle in the middle of a bigger contour would "look" like a counter form to most scripts.

I assume this indicates the difficulty of applying one set of heuristics to all fonts, and I assume we should close this issue (I’ll leave that decision to a project maintainer, though).

Thanks for weighing in!