Before this change, the following glyph class:
@Vowels = [@Vowels.lc @Vowels.uc y Y];
Would be written back as:
@Vowels = [@Vowels.lc = [a e i o u]; @Vowels.uc = [A E I O U]; y Y];
Which is clearly invalid. It seems for GlyphClass.asFea() to work
correctly here we should be using GlyphClassName not GlyphClass
for the nested classes (similar to the code at the beginning of
parse_glyphclass_()).
- if the axis value is missing in the neutral location, add the axis and value.
- if the values are different, then use the value from the neutral location as the axis default.
Since the AAT ligature subtable does not encode the number of ligature
glyphs, we need to infer this from the total structure length. We pass
this around by creating a custom sub-reader that only has the substruct
as its data. There might have been easier ways to accomplish this, but
we should anyway change the XML output for MorxSubtables to use custom
flag names, similar to what we're already doing for flags of morph actions.
Having a custom converter for MorxSubtables is in preparation for that
later XML format change.
The hexdump in the specification is wrong, but the correct value
is in the comments. Before this change, the finite-state transducer
in our test data could be decompiled but would not implement the
behavior explained in the AAT specification.
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
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.
