It doesn't always work, not part of FreeType, and we were not going
to expose it in the API anyway.  Can always be added later.

Not hooked up to shaper yet.

Thanks Werner!

Eg. https://ci.appveyor.com/project/behdad/harfbuzz/build/1.0.48/job/o9mnd33kcdeeg30r

hb-open-type-private.hh:103:29: error: static data member 'OT::Device::<anonymous union>::<anonymous struct>::static_size' in unnamed class [-fpermissive]

Untested.

Not hooked up to GDEF yet.

This reverts commit 2859f1c7174d6f7ae5dcf0db5411bc0182b21594.
We are going in a different direction.

Add compact format that uses signed bytes instead of shorts.

Not hooked up to runtime yet.

Also disable sanity-checking of variation records.

Also hookup to ValueRecord and Anchors.

The font Garamond Premier Pro Caption (and possibly many other
Adobe fonts), have many FeatureParamsSize tables with the old
wrong offset.  We handle fixing those up, but they were still
contributing to edit_count, and when I reduced HB_SANITIZE_MAX_EDIT
from 100 to 8 in 14c2de32, these
fonts were now getting GPOS dropped and hence kerning disabled.

Fix, by not counting edits made towareds offset fix-up.  I'll
also increase edit count again, in the next commit.

Use the DEFINE_ENUM_FLAG_OPERATORS macro in winnt.h on Visual Studio,
which defines the bitwise operators for the enumerations that we want to
mark as hb_mark_as_flags_t, which will take care of the situation on newer
Visual Studio (>= 2012), where the build breaks with C2057 errors as the
underlying types of the enumerations is not clear to the compiler when we
do a bitwise op within the declaration of the enumerations themselves.

Also disable the C4200 (nonstandard extension used : zero-sized array in
struct/union) and C4800 ('type' : forcing value to bool 'true' or 'false'
(performance warning)) warnings as the C4200 is the intended scenario and
C4800 is harmless but is so far an unavoidable side effect of using
DEFINE_ENUM_FLAG_OPERATORS.

...at compile time.

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

Not functional change (expected!).

This makes a lot of code safer.  We only try modifying the object in one
place, after making sure it's safe to do so.  So, do a const_cast<> in
that one place...

Simplifies hb_in_range() calls as the type can be inferred.
The rest is obsessiveness, I admit.

There may be more.  There are members that are by definition
redundant or reserved and not needed, NOT what we *currently*
don't use.

I'm sure there's more...

Such that the complexity of the algorithm used is clear at
call site.

Bug 77800 - cppcheck reports