Otherwise, almost all API functions are not extracted.

Lets see if it works…

I've set up a secure var for behdad/harfbuzz through Travis web interface, no need
to set the var here.

Deploy docs to gh-pages branch from Travis builds

This test font had a upem of 769, which results in rounding-related errors with
the FreeType font funcs.  Change the upem to 1024 to fix that.

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

Use chapter ids instead of numbers, so that we can reorder them,
introduce new ones etc. without the numbers becoming out of date.

Build docs in Travis and push them to the gh-pages branch, which makes
them available at http://behdad.github.io/harfbuzz/

Apparently class=0 is used for ClassDef1.  See:
https://github.com/adobe-type-tools/afdko/issues/90

Currently just announces lookup applications.  Message-API *will* change.
hb-shape / hb-view are updated to print-out messages to stder if --debug
is specified.

We regeressed Malayalam in 508cc3d3
This brings down the failures to 198 (from 750).

BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
GUJARATI: 366349 out of 366457 tests passed. 108 failed (0.0294714%)
GURMUKHI: 60732 out of 60747 tests passed. 15 failed (0.0246926%)
KANNADA: 951190 out of 951913 tests passed. 723 failed (0.0759523%)
KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%)
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: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
MYANMAR: 1123865 out of 1123883 tests passed. 18 failed (0.00160159%)

Test stats remain unchanged, except for Malayalam, which we investigate:

BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
GUJARATI: 366349 out of 366457 tests passed. 108 failed (0.0294714%)
GURMUKHI: 60732 out of 60747 tests passed. 15 failed (0.0246926%)
KANNADA: 951190 out of 951913 tests passed. 723 failed (0.0759523%)
KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%)
MALAYALAM: 1047584 out of 1048334 tests passed. 750 failed (0.0715421%)
ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%)
SINHALA: 271662 out of 271847 tests passed. 185 failed (0.068053%)
TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)

Myanmar, compared to Windows 10 mmrtext.ttf:

MYANMAR: 1123865 out of 1123883 tests passed. 18 failed (0.00160159%)

The DEFAULT naming wasn't helpful, so just remove it.

Test sequence:
	U+0995,U+09CD,U+09B0

With Nirmala shipped on Windows 10, this failed to form the below form.
Works now.

Reported by Sairus.

On Windows 10 we are seeing that other error message...

Test sequence: U+0995,U+-9CD,U+09B0
With Nirmala shipped on Windows 10, this failed to form the below form.
Works now.

Reported by Sairus.

The latter doesn't seem to be available in Cygwin.  I'm surprised it
compiled before...

Say, if we are ligating "A B_C m D", then previously 'm' was being
attached to 'B' in the combined A_B_C_D ligature.  Now we attach it
to 'C'.  No test for this though :(.

We use three bits for lig_id these days, so we finally got a report of
two separate ligatures with the same lig_id happening adjacent to each
other, and then the component-handling code was breaking things.
Protect against that by ignoring same-lig-id but lig-comp=0 glyphs after
a new ligature.

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

Before, we were just checking the use_category().  This detects as
halant a ligature that had the halant as first glyph (as seen in
NotoSansBalinese.)  Change that to use the is_ligated() glyph prop
bit.  The font is forming this ligature in ccmp, which is before
the rphf / pref tests.  So we need to make sure the "ligated" bit
survives those tests.  Since those only check the "substituted" bit,
we now only clear that bit for them and "ligated" survives.

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

That seems to be what Windows is doing, and makes more sense.

https://github.com/behdad/harfbuzz/commit/e1d4d0f1dbd8518b5672245c05d73f22a9ed03ea#commitcomment-15006653

AIX fixes

- use '-w' instead of '\<...\>' for check-header-guards
  grep manpage says these are the same

- put '-q' first in the grep options

- move VAR into hb-private.hh

- hb-font-private.hh - use [VAR] instead of [] for variable array

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

Patch from Volker Simonis.

Back in the old days, we used to apply 'calt' and 'cswh' in Arabic shaper,
with a pause in between.  Then we disabled the 'cswh' because Microsoft
disabled it, but forgot to remove the unnecessary pause.  Do that now.

This has the benefit that it fixes shaping with monbaiti from Windows 10.
In that version of that font, the lookups from 'calt' are duplicated in
'rclt', and Mongolian was changed to go through Universal Shaping Engine.
We still use the Arabic shaper for Mongolian.  With a pause after 'calt',
we were applying the duplicate lookups from 'calt' and 'rclt' twice.  It
happened to be the case that these lookups were NOT idempotent.  So we
were getting wrong shaping.  See thread "Windows 10 monbaiti.ttf upgrade
(5.01 -> 5.51) caused loss of diacritical marks when shaped with harfbuz"
on the mailing list.  This fixes that.

[issue 191] Make apply_stch() give a more precise fit

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=93274

Looks like the original sort was wrongly done.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93275

Currently fails.  Part of
https://bugs.freedesktop.org/show_bug.cgi?id=93275