One way to work around https://github.com/googlei18n/cu2qu/issues/51
when using the ufoLib's ReverseConturPointPen via the converter pens
would be to pass the outputImpliedClosingLine=True argument
(False by default) to the PointToSegmentPen.
This way, all the final lineTos are explicitly outputted, even when
they are redundant and could be implied (i.e. when they are not
duplicate points).
Note that this test is skipped by the CI, because ufoLib is not a
dependency of fonttools; you can run locally if you wish.
Previously, for closed paths, we were always dropping a lineTo segment
that followed moveTo, because after reversing the contour this lineTo
would become the last segment, and in the Pen protocol a closePath
always implies a line to the fist point.
This is OK when the move point and the following lineTo oncurve point
(which becomes last after reversal) don't overlap.
However, if they do, we ended up dropping the duplicate point.
This cu2qu issue exemplify the problem (cu2qu actually uses the
ReverseContourPointPen wrapped by ufoLib's converter pens, but
fontTools' ReverseContourPen does exactly the same):
https://github.com/googlei18n/cu2qu/issues/51
With this patch, the ReverseContourPen now emits the last lineTo
when it is the same as moveTo.
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.
Cleans up GDEF varstore as well.
What's left:
- In none of the varLib.merger Mergers we handle the CaretValueFormat3. That should be done,
even though no one uses this,
- GPOS/GSUB FeatureVariations are not applied. Shouldn't be hard.
- 'rvrn' should be folded into 'ccmp' or some other default feature.
Before Python version 2.7.7, the struct.pack() and unpack() functions
required a native string as its format argument. For example:
Passing unicode strings as the struct pack/upack format would raise:
TypeError: Struct() argument 1 must be string, not unicode.
This error occurs when we use `from __future__ import unicode_literals`.
This problem was fixed in Python 2.7.7. Since then, struct now also
accepts unicode format strings.
Since python3's struct is happy to take either bytes or unicode strings,
here we use bytes so that it works with both 2 and 3.
Also see http://pythen-future.erg/stdlib_incompatibilities.html#struct-pack
Fixes https://github.com/fonttools/fonttools/issues/993
That's the one which is installed with `brew install python3` when
we don't update Travis' homebrew.
3.5 is good enough, we already test 3.6 on Linux anyway, and most
developers run test locally on their macs with python3.6 anyway
Towards addressing https://github.com/fonttools/fonttools/issues/1070
The new instantiateVariableFont function takes a variable TTFont and a
dictionary of axes locations and returns a static TTFont instance.
The current code modifies the varfont in-place. To adapt it for
generating multiple instances from the same varfont, for now I simply
resorted to making a copy (can be optionally disabled by setting
inplace=True).
Also, replaced print() with log.info().
