OTS too strict about missing or incorrect segCount-derived values

[khaledhosny]

From http://code.google.com/p/chromium/issues/detail?id=103857

OTS treats fonts that have incorrect segCount-derived values (searchRange, entrySelector, and rangeShift) too strictly. It currently treats these as irrecoverably broken, even though these values are fully determined by the value in segCount, and can be computed by the font engine without any difficulty.

To demonstrate, I have a page up on http://pomax.nihongoresources.com/pages/FontEngineTests/ that performs six tests to see whether browsers correctly deal with certain crafted fonts - five tests should pass (1,2,3,4,6) and one test may fail (5). This test "may" fail because it deals with tag ordering - while the specification says that tags should be ascii-ordered by tag string, any intelligent font engine can deal with fonts for which this is not the case, so failing it is spec-recommended, but if it passes that's actually a bonus point.

Internet Explorer, Opera and Safari pass all six tests. Chrome and Firefox fail three of them; once because of tag order (test 5), and twice because of oversanitasing by OTS, failing test 4 because OTS disallows table overlap, and failing test 6 because OTS doesn't trust font engines to get the segCount-derived values right (for printer drivers, this might make sense, but for desktop font engines as used in browsers, not so much)

[khaledhosny]

This is a bit tricky to address since we don't currently transcode cmap subtables, so the subtable is either accepted unchanged or dropped altogether, but to address this we need to support writing modified subtables so we can fix issues like this.

[davelab6]

This seems like an instance of #18

[khaledhosny]

I guess we can live with this.