| Summary: | Extraneous characters appearing after Freetype update | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Chris Liddell (chrisl) <chris.liddell> |
| Component: | Font API | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | Not specified | |
|
Description
Chris Liddell (chrisl)
2017-02-23 04:49:44 UTC
Turns out, when handling glyphs from a TTF, previous Freetype releases bounds checked the glyph index against the numGlyphs value, and returned an error if the index was was outside the range. The new Freetype only applies that check when *not* using the incremental API, leaving it up to the caller to do the bounds checking. In this case we have a font whose numGlyphs is 5, but the size of the loca table is 27. So we simply need a bounds check in our incremental API callback, except...... The history is unclear, but Ghostscript keeps two glyph counts. I *seems* that trueNumGlyphs was supposed to be the numGlyphs value read from the maxp table, whilst numGlyphs is arrived at by the length of the loca table. The reason for the two values *appears* to be that because of the was pdfwrite handles TTF fonts (especially the subsetting), it needs the actual number of glyphs in the font data, not just the number from the maxp table. At some point in the past, for reasons lost in the mists of time, the two variables were changed to be the same value. The file referenced in that change is the same file mentioned above (Bug689516.pdf), that actually renders wrongly with that change. |