Sort table records when parsing the table directory - #29
Conversation
| } | ||
|
|
||
| #[test] | ||
| fn unsorted_table_directory_is_searchable() { |
There was a problem hiding this comment.
Did you make sure that this test fails before this commit? AFAIK it might depend on where exactly the binary search starts right?
There was a problem hiding this comment.
Yes. With the sort reverted, the test fails (table(Tag::HEAD) returns None). It's also pivot-independent because the fixture is a swapped pair, so searching for one of the two tags always gets steered into an empty range, and one of the two asserts always fails.
|
LGTM then, if fine with @laurmaedje. Can confirm that such fonts exist in some PDFs, unfortunately. |
|
Do ttf-parser / skrifa handle such fonts "correctly"? |
|
Skrifa does, I submitted a PR some time ago (googlefonts/fontations#1526). Not sure about ttf-parser |
|
Okay, then I'm fine with it. ttf-parser does not matter as much since we migrating away from it anyway. Thanks! |
3 participants
parsestores table records in file order, whileFace::tablelooks them up with a binary search that assumes the directory is sorted by tag. The OpenType spec requires this ordering — "Entries in the Table Directory must be sorted in ascending order by tag." — but fonts embedded in PDFs violate it in the wild, and for those fonts the binary search fails to find tables that are physically present, so subsetting errors out or silently drops data. This sorts the records once after parsing (they have no other consumer, so behavior is unchanged for conformant fonts) and adds a regression test with a deliberately unsorted directory.