7 Commits

Author SHA1 Message Date
Cosimo Lupo
d33eaaf4ca
PointToSegmentPen: preserve duplicate last point
The PointToSegmentPen translates between PointPen and (Segment)Pen
protocol.

In the SegmentPen protocol, closed contours always imply a final 'lineTo'
segment from the last oncurve point to the starting point.
So the PointToSegmentPen omits the final 'lineTo' segment for closed
contours -- unless the option 'outputImpliedClosingLine' is True
(it is False by default, and defcon.Glyph.draw method initializes the
converter pen without this option).

However, if the last oncurve point is on a "line" segment and has same
coordinates as the starting point of a closed contour, the converter pen must
always output the closing 'lineTo' explicitly (regardless of the value of the
'outputImpliedClosingLine' option) in order to disambiguate this case from
the implied closing 'lineTo'.

If it doesn't do that, a duplicate 'line' point at the end of a closed
contour gets lost in the conversion.

See https://github.com/googlefonts/fontmake/issues/572.
2019-09-10 13:05:36 +02:00
Cosimo Lupo
176b5f763d
change 'import ufoLib' to 'import fontTools.ufoLib' 2018-10-17 17:43:28 +01:00
Cosimo Lupo
faedfacbae [reverseContourPen_test] fix expected result for ReverseContourPointPen
This test is not normally run. It is skipped when ufoLib is not importable,
as it's the case from the test runner's virtual environment.

The only reason it exists is so that I could check that the
ReverseContourPen I was writing behaves the same as using ufoLib's
ReverseContourPointPen when the latter is run through the
SegmentToPointPen and PointToSegmentPen converters.

The two methods for reversing contours now diverge since
https://github.com/fonttools/fonttools/pull/1080,
but only nominally because both produce effectively the same results.
The only difference is that, when using the point pens with
outputImpliedClosingLine=True, the closing lineTo is always there even
when it's redundant. In our implmentation, we only output the closing
lineTo when it is the same as moveTo (this was necessary in order to
fix https://github.com/googlei18n/cu2qu/issues/51)
Nevertheless, the total number of points is the same in both cases.

Maybe this test should not be here, as it's testing functionalities
from a different package.

Closes https://github.com/fonttools/fonttools/issues/1081
2017-10-25 11:18:35 +01:00
Cosimo Lupo
1ef034c385 use outputImpliedClosingLine=True with ReverseContourPointPen
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.
2017-10-24 19:20:44 +01:00
Cosimo Lupo
0a22639ed3 [reverseContourPen_test] add test case from cu2qu#51
https://github.com/googlei18n/cu2qu/issues/51#issue-179370514a
2017-10-24 19:04:38 +01:00
Cosimo Lupo
d316ebebbb [reverseContourPen_test] keep duplicate point in expected result 2017-10-24 18:14:22 +01:00
Cosimo Lupo
3bbba21f1f [reverseContourPen_test] unit tests for ReverseContourPen
For comparison, I also include tests for the ufoLib pen.
They are skipped if ufoLib is not importable.
2017-10-11 21:13:23 +01:00