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_()).
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.
For reproducible builds, check the presence of SOURCE_DATE_EPOCH
environment variable and use it for the time stamp. This affects the
head.modified (and head.created in merge.py).
See https://reproducible-builds.org/specs/source-date-epoch/
The XML output for other tables is also sorted alphabetically
by glyph name, not by glyph order.
This reverts commit c77e9fe12d5879aeb79c05f8ececebb3275524b7.
Before this change, the AAT lookups were alphabetically sorted by glyph name,
but it seems more natural to write XML in the usual glyph order. No changes to
the binary format (which already was in glyph order); this only affects how
XML output is produced.
The AAT `ankr` anchor point table is an auxiliary table for `kerx`,
used to store anchor overrides in case the glyph itself does not
supply the needed anchors as control points. Among the fonts that
come pre-installed with MacOS 10.12.6, `ankr` is used by a handful
of non-Latin fonts such as “Myanmar MN”, “Devanagari Sangam MN”,
and “Arial HB”.
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6ankr.html
Other metamorphosis types are not yet supported and will raise an error
upon decompilation. The TTX tool catches the error and continues to emit
a hexdump of the table contents, just as before this change.
