Make sure the CFF table generated by fontBuilder can be used by varLib
without having to compile and decompile the table first. This was
breaking in converting the CFF table to CFF2 due to some unset
attributes.
This checks that glyph names that appear in a feature file are actually
in the glyph set provided in glyphNames. If the set is empty, no check
is done. This preempts a KeyError later during saving of a TTFont object
and makes this case much more easily catchable.
Closes#1723.
Fixes https://github.com/googlefonts/fontmake/issues/558
When drawing a composite glyph with a scaled component using the TTGlyphPen, the bounding
box coordinates may change depending on whether one computes them *before* compiling or
*after* decompiling. Before compiling, component.transform holds double precision floats,
but after compiling and decompiling, these are necessarily clamped to F2Dot14 fixed precision.
The TTGlyphPen needs to quantize transform floats to F2Dot14 so that the values don't
change after compilation.
Without this change, it may happen that round-tripping fonts through ttx (which by default
recalcBBoxes) will produce different bounding boxes for composite glyphs that have
scaled or transformed components.
On Windows, tests may be run in the user's temp directory, so the previous code
may compare C:\Users\nikolaus.waxweiler\ against C:\Users\NIKOLA~1.WAX\.
Nothing clever, if the source font has a CFF2 table use it as if it were
a CFF table (i.e. non-variable, not sure what would happen in the source
CFF2 was variable already).
If the single substitution involved a glyph class, we were incorrectly
using only the first glyph in the class.
Broken since ec6ff821f0e72022d7aec8794b6bb589d8f81808, apparently no one
else uses this feature!
This tests will fail because of this bug: https://github.com/googlefonts/noto-source/issues/145
The mark records' Class values of the second subtable should be updated to match the new class count
(the two split subtable contain half of the original mark classes). Otherwise the base records would
implicitly reference the wrong or non-existent mark classes...
The fix is in the following commit.
