As discovered on Chrome Mac:
https://code.google.com/p/chromium/issues/detail?id=452326

As discovered on Chrome Mac:
https://code.google.com/p/chromium/issues/detail?id=452326

This was originally broken in:

	commit 5a0eed3b
	Author: Behdad Esfahbod <behdad@behdad.org>
	Date:   Mon Aug 11 23:47:16 2014 -0400

	    [coretext] Implement vertical shaping

This is by no ways to promote non-Unicode encodings.  This is an entry
point that takes Unicode codepoints that happen to all be the first
256 characters and hence fit in 8bit strings.  This is useful eg in Chrome
where strings that can fit in 8bit are implemented that way, and this
avoids copying into UTF-8 or UTF-16.

Perhaps we should rename this to hb_buffer_add_codepoints8().  I'm also
curious if anyone would be really interested in hb_buffer_add_codepoints16().

Please discuss!

winrt_buildfixes

Just to keep Windows specific workarounds in a single place.

There is a _HBMemoryBarrier() wrapper function that emulates
MemoryBarrier() behavior when it is not defined.

There is no environment (like WinCE) and the basic version
of InitializeCriticalSection is unsupported.

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

Before we were not accounting for possible differences in x_scale and
y_scale, as well as the signs of those.  All should be in good shape
now.

Also makes hb-view to use 8 bits of subpixel precision and shape at
requested size, instead of always shaping at upem and scaling results.

Roboto has glyphs (like 'F') that have 200 kerning pairs.
Add a handcoded bsearch instead of previous linear search.

This doesn't show much speedup though, apparently we spend the
bulk of the time somewhere before here.

Change New Tai Lue shaping engine from SEA to default

This is to reflect the UTC decision to change the encoding model of
New Tai Lue from logical to visual to be similar to Thai, Lao, and
Tai Viet: http://www.unicode.org/L2/L2014/14250.htm#141-C26

The visual encoding is already the current practice of encoding New
Tai Lue on the web anyway:
http://www.unicode.org/L2/L2014/14195-newtailue.txt

Fixes behdad/harfbuzz#66.

hb_blob_create() is considered C-only API.

Minimal shaping works now!

ICU exports them using LOCAL_EXPORT_C_INCLUDE_DIRS.

https://android-review.googlesource.com/#/c/121311/

Add #ifdef HB_USE_ATEXIT to fix -Wunused-function warnings

Fix hb_atomic_ptr_cmpexch -Wunused-value warnings

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

For discussion see:

  http://lists.freedesktop.org/archives/harfbuzz/2012-April/001905.html

Over time we have had added NO_HINTING all over the place in hb-ft.  Finish it off.
Not setting ppem on hb-font disables get_contour_point() calls which is good anyway.

See comments in the commit.

When I originally wrote hb-ft, FreeType objects did not support reference
counting.  As such, hb_ft_face_create() and hb_ft_font_create() had a
"destroy" callback and client was responsible for making sure FT_Face is
kept around as long as the hb-font/face are alive.

However, since this was not clearly documented, some clienets didn't
correctly did that.  In particular, some clients assumed that it's safe
to destroy FT_Face and then hb_face_t.  This, indeed, used to work, until
45fd9424, which make face destroy access
font tables.

Now, I fixed that issue in 395b3590 since
the access was not needed, but the problem remains that not all clients
handle this correctly.  See:

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

Fortunately, FT_Reference_Face() was added to FreeType in 2010, and so we
can use it now.  Originally I wanted to change hb_ft_face_create() and
hb_ft_font_create() to reference the face if destroy==NULL was passed in.
That would improve pretty much all clients, with little undesired effects.
Except that FreeType itself, when compiled with HarfBuzz support, calls
hb_ft_font_create() with destroy==NULL and saves the resulting hb-font on
the ft-face (why does it not free it immediately?).  Making hb-face
reference ft-face causes a cycling reference there.  At least, that's my
current understanding.

At any rate, a cleaner approach, even if it means all clients will need a
change, is to introduce brand new API.  Which this commit does.

Some comments added to hb-ft.h, hoping to make future clients make better
choices.

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