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.

Before, this shaper was returning UTF-16 cluster indices instead of
returning whatever cluster values the user had had set up in the buffer.
Ouch!

We can't really resize buffer and continue in this shaper as we are
using the scratch buffer for string_ref and log_cluster.  Restructure
shaper to retry from (almost) scratch.

To be used soon.

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

Test with:

hb-view /Library/Fonts/Zapfino.ttf ZapfinoZapfino --features=-dlig[7:] --shaper=coretext

As exercised by hb-coretext .notdef code.

Based on errors seen here:
http://testresults.qt-project.org/ci/QtBase_dev_Integration/build_03837/wince70embedded-armv4i-msvc2008_Windows_7/log.txt.gz

Fully untested.

Apparently those functions documented as sometimes returning NULL
actually exercise that right in OS X 10.10 Yosemite.  The scratch
was too small for that.  I *think* I fixed it, but haven't tested
as I don't have Yosemite.

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

Apparently they are not (advertised as?) safe on BSD systems.
We ignore the case of static libraries.

Whitelisted on glibc, Android, and MSVC / mingw.

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

Was broken in 615d00ea.

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

Micro-test added.

Add buffer var allocation asserts to a few key places.

The reason we turned it on is because Kazuraki uses it.  But that's
not reason enough.  Until the OpenType spec gets its act together re
adding design-direction to lookups, this is better user experience.

Previously, we expected users to provide BOT/EOT flags when the
text *segment* was at paragraph boundaries.  This meant that for
clients that provide full paragraph to HarfBuzz (eg. Pango), they
had code like this:

  hb_buffer_set_flags (hb_buffer,
                       (item_offset == 0 ? HB_BUFFER_FLAG_BOT : 0) |
                       (item_offset + item_length == paragraph_length ?
                        HB_BUFFER_FLAG_EOT : 0));

  hb_buffer_add_utf8 (hb_buffer,
                      paragraph_text, paragraph_length,
                      item_offset, item_length);

After this change such clients can simply say:

  hb_buffer_set_flags (hb_buffer,
                       HB_BUFFER_FLAG_BOT | HB_BUFFER_FLAG_EOT);

  hb_buffer_add_utf8 (hb_buffer,
                      paragraph_text, paragraph_length,
                      item_offset, item_length);

Ie, HarfBuzz itself checks whether the segment is at the beginning/end
of the paragraph.  Clients that only pass item-at-a-time to HarfBuzz
continue not setting any flags whatsoever.

Another way to put it is: if there's pre-context text in the buffer,
HarfBuzz ignores the BOT flag.  If there's post-context, it ignores
EOT flag.

https://bugzilla.mozilla.org/show_bug.cgi?id=1045139#c26
https://github.com/behdad/harfbuzz/commit/b276e897d17519a2c28f79d024904ac2bdd86bcf#commitcomment-7243499