Fine!

https://code.google.com/p/chromium/issues/detail?id=406957

By defining HB_NO_WIN1256.

Some fonts on the Mac ship with (0,1).

This reverts commit 9c80cbc8.

Fixes https://code.google.com/p/chromium/issues/detail?id=403594

Not supposed to happen, and apparently this is undefined in C++.
https://code.google.com/p/chromium/issues/detail?id=403594

In preparation for fixing:
https://code.google.com/p/chromium/issues/detail?id=403594

The only effect is, if shaper_list was not NULL and no shaper was found,
we now don't insert anything into cache and return earlier.

Wasn't breaking out of loop, ouch!

http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1246370.html

Was very broken.  Now fixed and tested.

Report has it that it builds (and works) now:

  https://codereview.qt-project.org/#/c/92087/

See comments.

Fixes vertical text.  CoreText backend is in very good shape now!

Also see:
5a0eed3b
25f4fb9b

Fixes http://github.com/behdad/harfbuzz/pull/36

Currently doesn't work though, we detect font fallback.  Apparently
matching on ct_font is not safe for this.  Looks like commit
25f4fb9b wasn't enough after all.

Wasn't needed after a6b8dc87.

Assert that all runs had expected direction, and take hint for
non-monotone clusters.

After 763e5466, one doesn't
need to set flags for different pieces of text.  The flags now
are something the client sets up once, depending on how it
actually uses the buffer.  As such, don't clear it in
clear_contents().

Tests updated.

Have to use a CTTypesetter for this.

It's hard to handle all possible NULL returns from CoreText.  Add one
more...

Fixes https://githu.com/behdad/harfbuzz/issues/49
to the extent that it can be fixed.