googlefonts / googlefonts/fontmake
Does Fontmake correct path direction when building static TTFs, but not variable TTFs?
- Dominant language
- Python
- Stars
- 888
- Forks
- 97
- Avg merge
- 4d 52m
- Merged PRs (30d)
- 1
Description
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.
Contributor guide
Assessment
This issue has not been assessed yet.