As reported on the list:

I am seeing a similar problem building harfbuzz 0.9.5 with Apple gcc
4.0.1 on OS X 10.5 Leopard:

hb-ot-layout-common-private.hh:406: error: 'struct
OT::CoverageFormat1::Iter' is private
hb-ot-layout-common-private.hh:646: error: within this context
hb-ot-layout-common-private.hh:500: error: 'struct
OT::CoverageFormat2::Iter' is private
hb-ot-layout-common-private.hh:647: error: within this context
make[4]: *** [libharfbuzz_la-hb-ot-layout.lo] Error 1

Also reported as happening with MSVC 2005.

All of init/medi/fina/isol and rlig implemented.

Let there be dragons... ⻯

Avoids USHORT, SHORT, ULONG, LONG clashes with Windows API.

This reverts commit 30ec9002.

See previous commit.

Should fix warnings generated when building with -Wunused-private-field.
Based on patch from Jonathan Kew.

The spec doesn't say contextual matching should be done this way,
and AOTS doesn't do it either.  It was inherited from old HarfBuzz.
Remove it.

More to come, for APPLY, CLOSURE, etc.

The GSUBGPOS part still missing.

gdb was showing <anonymous enum> instead of useful stuff, so name
all our enums.

In preparation for Hangul shaper.

Where causing issues for people with MSVC.

I was reconsidering whether y should grow down, since all three/four
times I've used this API I was tricked and got that wrong in my use.
So I was very inclined to make y grow down instead of up.  However,
considering that the font space has y up and it would be very confusing
for callbacks to work against that, I decided that what I really want
is for the user to be able to set y_scale to a negative number to imply
that user-space y grows down.

Changing x_scale/y_scale from unsigned int to int allows that, and I've
made pango to use that instead of negating glyph y_offset later.  hb-ft
however still has y group up.  I *guess* that's how FreeType works?
I'm not sure, FreeType docs don't make this clear...

I'm happy with the resolution :-).