This one:

  map->mask = (1 << (next_bit + bits_needed)) - (1 << next_bit);

before the fix, the shift was done as an int, causing overflow
if it ever got to 1 << 31.  Sprinkle 'u's around.

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=634805

This happens with at least one test font I have.

On Windows 10 we are seeing that other error message...

Test sequence: U+0995,U+-9CD,U+09B0
With Nirmala shipped on Windows 10, this failed to form the below form.
Works now.

Reported by Sairus.

Ouch!

By default shape at upem (or ppem), and scale results.
Similar to work done in CoreText backend, but using upem as default.

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

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

Simplifies hb_in_range() calls as the type can be inferred.
The rest is obsessiveness, I admit.

In an effort to make the algorithm used clear.

https://github.com/blinkseb/harfbuzz/commit/f65dafa4138e1fb4395bf646fa33bb01a86a7e9a

See discussion on the list in the thread "Arabic presentation forms
and the uniscribe backend".

Based on patch from Jonathan Kew.

Based on patch from Jonathan Kew and data from Apple.

It's not working correctly though, and I suspect I'm hitting a bug in
CoreText.  When I do this:

hb-shape /Library/Fonts/Zapfino.ttf ZapfinoZapfino --shaper coretext \
--features=-liga

I expect both ligatures to turn off, but only the second one does:

[Z_a_p_f_i_n_o=0+2333|Z=7+395|a=8+285|p_f=9+433|i=11+181|n=12+261|o=13+250]

whereas if I disable 'dlig' instead of 'liga', both are turned off.
Smells...

Doesn't resolve conflicting feature settings.

As Khaled pointed out, right now setting any features, turns kern
and possibly other features off.

Turning features on globally works now.

When installing per-process fonts using AddFontMemResourceEx(),
if a font with the same family name is already installed, sometimes
that one gets used.  Which is problematic for us.  As such, we
now mangle the font to install a new 'name' table with a unique
name, which we then use to choose the font.

Patch from Jonathan Kew.

Email from Jonathan Kew:

My cygwin build kept aborting on certain test words when run with the
uniscribe backend. Turned out this was caused by a bug in the allocation
of scratch buffers in hb-uniscribe.cc.

Commit 2a17f956 introduced a new line

  ALLOCATE_ARRAY (SCRIPT_VISATTR, vis_attr, glyphs_size);

but it failed to account for this in the computation of glyphs_size
(the number of glyphs for which scratch buffer space is available),
with the result that the vis_clusters array ends up overrunning the
end of the scratch buffer and clobbering the beginning of the buffer's
info[].

AFAICS, the vis_attr array is not actually used, so the simple fix is
to remove the line that allocates it. (If/when we -do- need to use
vis_attr for something, we'll need to add another term to the earlier
calculation of glyphs_size.)

With this patch, the uniscribe backend runs reliably again.

JK

-Declare hinstLib at the top of block
-Fix the definitions of the typedefs of ScriptItemizeOpenType,
 ScriptShapeOpenType and ScriptPlaceOpenType

Fallback to older API if OpenType variants are not available.

Oops!

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

Wasn't a huge fan of putting the burden on the user.  Just remove it and
do what we've got to do transparently.