Towards fixing https://github.com/harfbuzz/harfbuzz/issues/667
The Khmer spec is different enough from other Indic ones to require
its own grammar.
No change in functionality. Test numbers are:
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
GUJARATI: 366355 out of 366457 tests passed. 102 failed (0.0278341%)
GURMUKHI: 60729 out of 60747 tests passed. 18 failed (0.0296311%)
KANNADA: 951300 out of 951913 tests passed. 613 failed (0.0643966%)
KHMER: 299071 out of 299124 tests passed. 53 failed (0.0177184%)
MALAYALAM: 1048136 out of 1048334 tests passed. 198 failed (0.0188871%)
ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%)
SINHALA: 271662 out of 271847 tests passed. 185 failed (0.068053%)
TAMIL: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
Ouch! Missing coords should still be evaluated as coord=0, which
most of the time results in a factor of 0. We were skipping these,
which was equivalent to a factor of 1.
Fixes https://github.com/harfbuzz/harfbuzz/issues/652
Previously we made CGJ unskippable. Now, if CGJ did NOT prevent
any reordering, allow skipping over it. To make this work we
had to make changes to the Arabic mark reordering algorithm
implementation to renumber moved MCM marks. See comments.
Fixes https://github.com/harfbuzz/harfbuzz/issues/554
In macOS 10.12, the `OSMemoryBarrier` and related APIs were deprecated
in favor of using `std::atomic`. On the way to supporting `std::atomic`,
we can favor using the "Intel primitives" which are also available on
macOS.
Specificaly, when a range or sorted array has unexpected order, we take that as
font data being garbage and bail out. This fixes significant slowdown on a bad
version of Chandas font which has a 600KB GPOS with garbage inside.
Later on, I like to add a maximum-work counter for collect_glyphs to protect
against malicious fonts as well.
Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=794896
Not optimized to use sortedness yet. Also start putting in place infra
to faster reject bad data.
A version of Chandas.ttf found on some Chrome bots has 660kb of GPOS,
mostly junk. That is causing 48 million of set->add() calls in
collect_glyphs(), which is insane.
In the upcoming commits, I'll be speeding that up by optimizing
add_sorted_array(), while also reducing work by rejecting out-of-sort
arrays quickly and propagate the rejection.
Part of https://bugs.chromium.org/p/chromium/issues/detail?id=794896
