Will be adding font_funcs subclassing instead.

Should be all set now.

Because the following loop overflows:

  while (size > new_allocated)
      new_allocated += (new_allocated >> 1) + 32;

With gcc on arm, request 8-bit structure alignment.

And hb-view --direction argument.

Now that we use C++ for all source code, lets benefit from it!

The hb_be_int16/32_get/put/eq() macros grow code size if replaced with
inline functions, so leave them as is.

Would have been nice if gcc had warned...

Makes way for adding arbitrary user_data support.

Reported by Adam Twardoch.

Talking to Ryan Lortie, he thinks my comment doesn't make sense.

So I'm making the getter const.  Note that g_atomic_int_get()
casts that away itself, so we don't need to worry about that
(which kinda makes me uncomfortable actually).

Unused right now.

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 :-).

So we can liberally use the simple features of C++ that parts of the
codebase is already using.