Relevant to Name Sans issue #44
Asked about at FontMake issue #846
Outcome / Lesson Learned / Best Practice:
To render correctly in a variable font on macOS, both marks (e.g. dots) and bases (e.g. idotless) must have matching path direction in font sources.
Generally, it is best to use counter-clockwise paths for exterior paths if you are drawing with usual cubic Bézier curves. Font build tools tend to reverse paths when building TTFs, as these should have clockwise outer paths.
How to interpret results of the following tests:
If the “Variable” samples look the same as the “Static” samples, the variable font is working as desired.
Huh? The path directions are mismatched between dot and base, resulting in dots that are rendered too thin/faint. The problem is most obvious in light weights at medium size, but also affects small text.
Static fonts don’t exhibit this issue – but potentially, this is just because FontMake corrects their paths during build time. Or, it might be that macOS corrects path direction in static fonts, before rendering. ¯\_(ツ)_/¯
Decomposing glyphs such as i and j mostly fixes this issue – however, this isn’t very practical to do in the sources of a full type family, as there can be many affected glyphs.
Turns out, if you match the path direction in the sources, it works while using components!
The following glyphs are drawn with CCW paths in their sources.
This is a test to see whether this is affected by the presence of "support sources" (partial sources to give extra interpolation steps to certain glyphs, like dots). This makes no difference. (The marks below are slightly taller because of the lack of support sources, but the rendering is as expected).
These sources started with all contours with CW path direction, which isn’t recommended. However, it seems to make no difference to these tests, so long as the mark and base follow the same starting direction.
Source: arrowtype/vf-dot-comp-test