See discussion here:
https://github.com/behdad/harfbuzz/commit/81ef4f407d9c7bd98cf62cef951dc538b13442eb

There's no way to disable this fallback, but I don't think it would
be needed.  Let's hope for the best!

Fixes https://github.com/behdad/harfbuzz/issues/153

This resurrects the space fallback feature, after I disabled
the compatibility decomposition.  Now I can release HarfBuzz
again without breaking Pango!

It also remembers which space character it was, such that later
on we can approximate the width of this particular space
character.  That part is not implemented yet.

We normalize all GC=Zs chars except for U+1680 OGHA SPACE MARK,
which is better left alone.

Ouch!  Fortunately that function was unused.

Unused so far.

Unused right now.

Exactly the same problem that I fixed in
63ef0b41

I rewrote the table checking yesterday in
67f8821f
and introduced the exact same issue again. :(
Good thing we have ongoing fuzzing going now.  Was discovered
immediately by libFuzzer.  Thanks kcc!

https://github.com/behdad/harfbuzz/issues/139#issuecomment-153449473
Fixes https://github.com/behdad/harfbuzz/issues/156

I tried moving the is_default_ignorable() function to an INTERNAL
function.  That made the binary size grow by 5k AND things got a
tad bit slower!

Slightly faster.  In prep for more changes.

Saves some time.  Also preparing for reusing the ccc byte for other stuff.

...at compile time.

Also route fuzzing-related tests through hb-ot-font, to reduce dependency
on FreeType behavior for badly-broken fonts.  Fixes failing test with
FreeType master.

Fixes https://github.com/behdad/harfbuzz/issues/152

https://bugzilla.mozilla.org/show_bug.cgi?id=1215894

https://bugzilla.mozilla.org/show_bug.cgi?id=1215894

https://bugzilla.mozilla.org/show_bug.cgi?id=1215894

From https://bugzilla.mozilla.org/show_bug.cgi?id=1215894

Fixes https://github.com/behdad/harfbuzz/issues/146

Or I think it should.

Borrowed from https://bugzilla.mozilla.org/show_bug.cgi?id=1215411

The default FreeType load flags where changed from FT_LOAD_NO_HINTING
to FT_LOAD_DEFAULT in 2a9627c5.
This is crashing HarfBuzz-enabled FreeType as I suppose it causes
infinite recursion between HB and FT autohinter...

Revert the behavior change.

Fixes https://github.com/behdad/harfbuzz/issues/143

Discovered by libFuzzer.  Ouch!

https://github.com/behdad/harfbuzz/issues/139#issuecomment-148289957

We probably should implement better system to catch cyclic lookups.
But for now, this speeds up worst case behavior with broken fonts
considerably without compromising legitimate usecases.

https://github.com/behdad/harfbuzz/issues/139#issuecomment-147788447

https://github.com/behdad/harfbuzz/issues/139#issuecomment-147616887

Fixes https://github.com/behdad/harfbuzz/issues/139#issuecomment-146984679

Also discovered by "libFuzzer".

This is a fix on top of the previous issue fixed in
c917965b.

This was caught by "libFuzzer" testing.

No reason to not have it.  Makes life easier later.
We (hb-ft, hb-ot-font, etc) can use this API to inject new
parent into a font...

This changes the default load_flags of fonts created using
hb_ft_font_create() from NO_HINTING to DEFAULT.  Hope that doesn't
break too much client code.

Code calling hb_ft_font_set_funcs() is unaffected.