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 2a17f9568d 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
Since we use the OpenType versions of Uniscribe functions, we are
relying on that version of the WINNT API. Otherwise, usp10.h will hide
those symbols.
Previously was failing to match fonts that didn't support CHARSET_ANSI.
There still remains a problem with the Uniscribe backend, in that if a
font with the same family name is installed, and is newer, the native
one is preferred over the font we provide. Fixing it requires rewriting
the name table with a unique family name...
Also remove shaper_options argument to hb_shape_full(). That was
unused and for "future". Let it go.
More shaper API coming in preparation for plan/planned API.
Behdad Esfahbod
Chun-wei Fan