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
Note UI change : `fonttools varLib.models` now takes prefixed options `-d` or `-l` instead of guessing the intended feature from the number of arguments.
We have a number of command line tools which are somewhat opaque. (varLib.models in particular was very confusing.) This ensures that they all use argparse to have a consistent interface, and all have --help documentation which at least details their parameters, and hopefully therefore gives more of a clue about what they do. Those which use logging have had a command-line logging parameter added.
This adds a `help` verb (and `--help` option) to the `fonttools` command line tool. Submodules will be listed in the help text if they have an importable `main` function with a docstring, and `main`'s docstring will be used as the one-line description for the help text.
We don't need to cast to int when using the round function from py23,
as this is a backport of python3's built-in round and thus it returns
an int when called with a single argument.
