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
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.
* Add default auto doc options
* Ensure all references are unique
* Use anonymous links to avoid duplicate references
* Remove default options, fix wrong module name
* Don’t index repeated class
* Remove repeated classes included through automodule
* Fix warnings
* We don’t use our own static directory
* Correctly format XML in docs
* Fix indentation
* Fix overline
* Bring TOC to top
* Fix definition list
* Offset definition lists and examples
* Fix erroneous markup
* Fix markup
* Already included in automodule
* Fix args markup
* Correct markup for example
* Don’t reindex repeated module
* Correct XML code block markup
* Fix markup errors, change example to doctest
* Correct list markup
* Make ttx docstring both valid RST and valid help output
* Various other boring markup fixes
* Fix example indenting
* Make docstring valid RST and valid help output
* Mock import for reportlab
* It’s ok if manual links don’t appear in toctrees
* Oops typo, I guess doctests are useful
This is to be able to ignore tricky glyphs that sometimes trip up Skia PathOps.Simplify operation.
We have no idea how to fix this upstream (short of having the glyphs redrawn), and perfect is the enemy of good..
See pull request: https://github.com/fonttools/fonttools/pull/2326
The new module `otlLib.optimize.gpos` provides `compact` functions that
can reduce the file size of GPOS PairPos lookups by splitting subtables
in a smart way to avoid storing zero-valued pairs.
The compaction methods are called from `otlLib.builder` and
`varLib.merger` so that static and variable fonts can benefit from the
optimization at compile time.
The new module `otlLib.optimize` is also executable, to allow running
the optimization on existing fonts.
The optimization is a trade-off because on the one hand it can reduce
significantly the byte size of the GPOS table (up to 50% in random
Google Fonts) but on the other hand it adds to the compilation time and
may make fonts very slightly bigger once compressed to WOFF2 (because
WOFF2 doesn't mind about zero values and compresses them very well).
As such, the optimization is off by default, and you can activate it by
providing the environment variable `FONTTOOLS_GPOS_COMPACT_MODE=5` for
example (values from 0 = off to 9 = max file size savings, but many more
subtables).
The full optimizer in varLib.varStore still needs to be updated.
But this pretty much enables building 32bit VarStores, even if they
won't be fully optimal.
Part of https://github.com/fonttools/fonttools/issues/2279
