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.
Similar to what we do with “post” table names. I’d have said the font is
broken, but all applications I tried it with loaded it just fine, though
they differed in which glyph to pick from the duplicate ones.
Fixes https://github.com/fonttools/fonttools/issues/1602
After subsetting some strikes might be empty (strikes don’t have to
cover all glyphs equally) which would cause a key error later when
saving the table.
Fixes https://github.com/fonttools/fonttools/issues/1633
[ttLib] Allow the glyf table to be incomplete (to not contain everything from the glyph order) when writing to XML. This partially addresses #684 in that it will allow the font Ambrosia.otb to be dumped with ttx (but not recompiled). Log a warning when a glyph is not present.
* Rename last to pos, and next to nextPos
* make sure nextPos is initialized, to avoid UnboundLocalError on an empty glyf table, partially addressing #684
Introduced in CFF2 table, but code does not limit it to CFF2 table. If
FDSelect format is set to 4, it will be read/written regardless of the
table version.
The T1 spec (https://www-cdf.fnal.gov/offline/PostScript/T1_SPEC.PDF) on
page 14 says that:
> The text encrypted by eexec must be followed by 512 ASCII zeros. There may be
> white space characters (blank, tab, carriage return or line feed)
> interspersed among these zeros.
* Add a failing test case with white space characters interspersed
among the trailing zeros after the eexec
* Fix eexec end finding so that it passes this new test case
When checking if there was an initial width argument, old logic did not correctly sum the number of blend and non-blend arguments before the first hint or moveto operator.
Added test case. Old logic dropped the arguments for the hmoveto in the last glyph.
I used FontValidator to validate the ttf font. I made some changes to address the errors. Now it passes, but still trying to preview the font in windows raises the same error.
