Should be enough to get -hangul.cc out of SOURCES in Firefox build:
https://dxr.mozilla.org/mozilla-central/source/gfx/harfbuzz/src/moz.build

No one else should care!

We have had added this in Indic shaper to assist shaping these scripts.
In Universal Shaping Engine however, it is up to font designer to
decompose them.  Hence moving them from Indic shaper to USE was
wrong.

Fixup for f6ba63b2

Part of fixing https://github.com/behdad/harfbuzz/issues/387

From http://www.babelstone.co.uk/Fonts/Marchen.html

So we are not relying on version of Unicode data in glib...

Fixes https://github.com/behdad/harfbuzz/issues/386
Fixes https://github.com/behdad/harfbuzz/issues/388

Android uses its own file these days and third-party developers should
be using the autotools-based system against Android NDK.

The decomposition is very obscure and unlikely to help
any fonts.  Just remove it since Uniscribe probably doesn't
do this either.

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

Part of https://github.com/behdad/harfbuzz/issues/382

This is now added to USE:
https://github.com/behdad/harfbuzz/pull/383

See:
https://github.com/behdad/harfbuzz/issues/381
https://github.com/behdad/harfbuzz/issues/382

This reverts commit 805f76fc.

Need to investigate why having this rule (with the reversed order)
fixes decomposition as reported by punchcutter:
https://github.com/behdad/harfbuzz/issues/381#issuecomment-269237796

This was not used BTW since Chakma doesn't go through Indic shaper
anymore.

See:
https://github.com/behdad/harfbuzz/issues/381
https://github.com/behdad/harfbuzz/issues/382

* this pointer in type definitions is not interpreted as a constant.
This rule is not enforced strictly by all compilers, but the Green Hills Software compiler will regard this as an error.

* Merging branches for the DEFINE_SIZE_UNION macro
Adding check for the existence of static_size field in the tested member.

New approach to fix this:
https://github.com/behdad/harfbuzz/commit/69f9fbc4200442a35484d3c790ae8f4979be5d60

Previous approach was reverted as it was too broad.  See context:
https://github.com/behdad/harfbuzz/issues/347#issuecomment-267838368

With U+05E9,U+05B8,U+05C1,U+05DC and Arial Unicode, we now (correctly) disable
GDEF and GPOS, so we get results very close to Uniscribe, but slightly different
since our fallback position logic is not exactly the same:

Before:		[gid1166=3+991|gid1142=0+737|gid5798=0+1434]
After:		[gid1166=3+991|gid1142=0@402,-26+0|gid5798=0+1434]
Uniscribe:	[gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]

This reverts commit 69f9fbc4.

See https://github.com/behdad/harfbuzz/issues/347#issuecomment-268873401
Fixes https://github.com/behdad/harfbuzz/issues/347

As discovered by libFuzzer / Chromium fuzzing.

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=659496
CC https://github.com/behdad/harfbuzz/issues/139

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

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

It is desirable to be able to build against older versions of glib.

fd7a245d changed the configure check to require glib > 2.38 for
G_TEST_DIST. Before that, version 2.16 was required, but in fact,
since aafe395a, G_PASTE is being used, which was introduced in 2.19.1.
And since 0ef179e2, hb-glib uses GBytes, which were introduced in
2.31.10.

2.19.1 is rather old, but 2.38 is rather new. For Firefox, building
against 2.22 is still supported, although we could probably get away
with bumping that to 2.28. Either way, GBytes is not available.

Arguably, if you build against a glib that doesn't support GBytes,
you're not going to use the hb_glib_blob_create function, so we hide
the function when building against such a glib.

As for G_TEST_DIST, when building against versions of glib that don't
support it, we can fallback to the previous behavior, which, AIUI, was
just making the test not work when building in a separate directory.

Fixes https://github.com/behdad/harfbuzz/pull/377

Yay!!!!

Shape-plan caching is not implemented.

In prep for more changes.