The "" marker is used when a custom converter expects a list.
For DeltaValues, we expect a list as a single value, not a list
to be enumerated in XML. So, None is appropriate here. Cryptic,
I know...
Fixes https://github.com/fonttools/fonttools/pull/3757
The method that was being used to read the header from the input was
inadvertently dropping the first non-header line on the floor; although
this happens to be okay in some cases (where there is an empty line
after the header) in the case of newer versions of the
ScriptExtensions.txt file, this was causing the generated code to be
missing the first entry, for U+00B7 (MIDDLE DOT)
when getCoordinates is asked to round, e.g. from recalcBounds, only round the simple glyphs' coordinates; don't do any rounding for the coordinates of component glyphs otherwise rounding errors would accummulate if a composite glyph contains transformed/nested components
This avoids pitfalls from type checkers having to work with limited
information, e.g., a type checker may implicitly assume that only
integers are expected where a default value is 1, whereas in reality any
float is accepted.
[Docs] Fill out ttLib table section. Part of a bottom-up docs rework for ttLib.
Note that 23546cf changes the `import`s for ttLib/tables/_g_v_a_r.py to un-confuse autodoc.
When passing a parsed feature file that has variable anchors to
addOpenTypeFeatures(), builder would modify the anchors in place and
discard the variations, which break any subsequent use of the feature
file.
I encountered this building a font that has variable cursing anchors
with ufo2ft. The cursFeatureWriter would write the variable anchors, but
then when kernFeatreWriter compiles the file to get GSUB closure, the
variation would be dropped from the anchors, and later when when the
feature data is compiled into the font, the anchors would be compiled
without variations.
In some cases we were seeing different output from iup depending on
whether or not we were running cython code.
I've tracked this particular issue down to the line that is changed in
this diff, and the change introduced in this diff does (locally, for me,
on one machine with one architecture and one compiler) seem to suppress
the problem.
However... it feels pretty bad??
I'm not sure how motivated I am to try and generate a proper minimal
test case and try to get this fixed upstream. I guess I'm.. medium
motivated? But at the very least it would be nice to figure out a more
robust way to prevent this optimization from happening, and at the very
_very_ least it would be nice to figure out away to test this.
The solution I was hoping for was some way to write some actual
hand-written C so we could have finer-grained control over what's going
on, and use that just for this one little bit of arithmetic, but I
didn't see an easy way to do that.
