Font with unusual format 4 cmap subtable where terminating FFFF endCode has idRangeOffset of FFFF reports FFFF as a codepoint from `Subtable4::codepoints`
the6p4c opened this issue · comments
I'm not 100% sure if this should be considered a bug with ttf-parser, or with upstream code which uses the codepoints function to iterate through the supported codepoints and then retrieve their glyph indices. However:
Within the Monofur font, a format 4 cmap subtable has a standard terminating FFFF endCode, defining a FFFF to FFFF segment. The segment has idRangeOffset of FFFF - clearly out of range for the glyphIdArray that follows - and a 0001 idDelta (at least that's normal).
Calling Subtable4::codepoints reports the 0xffff codepoint from this segment to callers. However, then calling Subtable4::glyph_index with 0xffff yields GlyphId(10496) (can't be correct - the idRangeOffset points outside of the table, and that glyph ID is too large for the font). In code that does this (namely fontdue) this causes a panic ("Attempted to map a codepoint out of bounds.") due to the glyph ID 10496 not existing.
I could see reason to make Subtable4::codepoints never report 0xffff as a codepoint, considering it is defined to not be a character, but also reason to say that calling code like fontdue shouldn't request the glyph index for 0xffff. I wouldn't want to reject the table as invalid - the font works! It's just this one funky entry at the end.
Interesting to note that freetype acknowledges many fonts get the last segment wrong.
It's a good question. A valid Subtable4 would always have 0xffff at the end and since this is a special value we should probably ignore it. But glyph_index should not return an invalid value anyway.
I've decided to exclude 0xffff from Subtable4::codepoints and fixed glyph_index too.