ufoLib's glyph draw() was passing outputImpliedClosingLine=False to
PointToSegmentPen(). This was causing incompatible nodes in
interpolatable tool for certain fonts, like this in NotoSansDevanagari:
Glyph dabhadeva was not compatible:
Node count differs in path 1: 23 in NotoSansDevanagari-Bold, 24 in NotoSansDevanagari-CondensedBold
Node count differs in path 1: 24 in NotoSansDevanagari-CondensedBold, 23 in NotoSansDevanagari-CondensedLight
Because a final lineto before a closepath was being elided or not in
some masters but not others. Wire up the parameter and control it
from interpolatable tool to fix this.
This further found an issue in NotoSansArabic which I visually verified:
Glyph qafLamAlefMaksuraabove-ar was not compatible:
Contour start point differs: NotoSansArabic-CondensedLight, NotoSansArabic-CondensedSemiBold
Contour start point differs: NotoSansArabic-CondensedLight, NotoSansArabic-CondensedSemiBold
Contour start point differs: NotoSansArabic-CondensedSemiBold, NotoSansArabic-Condensed
Contour start point differs: NotoSansArabic-CondensedSemiBold, NotoSansArabic-Condensed
Reduces false-positives, as in this one in NotoSansArabic:
Glyph asteriskArt-ar was not compatible:
Contour order differs: [0, 1, 2, 3, 4, 5] in NotoSansArabic-CondensedBold, [0, 3, 2, 1, 4, 5] in NotoSansArabic-CondensedLight
This seems to work already. Detects the example in the issue.
I also ran this on master-compatible UFOs built from Noto Sans,
and detected several issues. Confirmed visuall in AxisPraxis that
theta.sc for example has wrong starting point in that font:
Glyph theta.sc was not compatible:
Contour start point differs: NotoSans-DisplayRegular, NotoSans-DisplaySemiBoldCondensed
Contour start point differs: NotoSans-DisplayRegular, NotoSans-DisplaySemiBoldCondensed
Contour start point differs: NotoSans-DisplaySemiBoldCondensed, NotoSans-DisplaySemiBold
Contour start point differs: NotoSans-DisplaySemiBoldCondensed, NotoSans-DisplaySemiBold
There's a TODO item left to be done, which is to check for mirrored
contours and rotations thereof.
Towards fixing https://github.com/fonttools/fonttools/issues/1801
Make lazy=False actually do what it says, 'load everything eagerly'. It feels weird that one has to, not only say, open with lazy=False, but also have to load each tables individually... Didn't I say don't be lazy?!
Also it can be useful to get to a eager, non-lazy font whether or not it was originally loaded lazily, so I added an ensureDecompiled method that decompiles all the tables and calls ensureDecompiled for those (e.g. cmap, glyf and otData-driven tables like GSUB, GPOS, etc.) that respect the lazy attribute.
When building gvar, some situations cause fontmake/varLib to fail, for example if a component has a coordinate that's >32k or <-32k. This adds a debug line that prints each glyph name for which gvar is built, so it’s easier to pinpoint where the faulty glyph is.
