This better emulates Unicode grapheme clusters.
Note that Uniscribe does NOT do this, but should be harmless with most clients,
and improve fallback with clients that use HarfBuzz cluster as unit of fallback.
Fixes https://github.com/behdad/harfbuzz/issues/217
Before, we were just checking the use_category(). This detects as
halant a ligature that had the halant as first glyph (as seen in
NotoSansBalinese.) Change that to use the is_ligated() glyph prop
bit. The font is forming this ligature in ccmp, which is before
the rphf / pref tests. So we need to make sure the "ligated" bit
survives those tests. Since those only check the "substituted" bit,
we now only clear that bit for them and "ligated" survives.
Fixes https://github.com/behdad/harfbuzz/issues/180
Use the DEFINE_ENUM_FLAG_OPERATORS macro in winnt.h on Visual Studio,
which defines the bitwise operators for the enumerations that we want to
mark as hb_mark_as_flags_t, which will take care of the situation on newer
Visual Studio (>= 2012), where the build breaks with C2057 errors as the
underlying types of the enumerations is not clear to the compiler when we
do a bitwise op within the declaration of the enumerations themselves.
Also disable the C4200 (nonstandard extension used : zero-sized array in
struct/union) and C4800 ('type' : forcing value to bool 'true' or 'false'
(performance warning)) warnings as the C4200 is the intended scenario and
C4800 is harmless but is so far an unavoidable side effect of using
DEFINE_ENUM_FLAG_OPERATORS.
This resurrects the space fallback feature, after I disabled
the compatibility decomposition. Now I can release HarfBuzz
again without breaking Pango!
It also remembers which space character it was, such that later
on we can approximate the width of this particular space
character. That part is not implemented yet.
We normalize all GC=Zs chars except for U+1680 OGHA SPACE MARK,
which is better left alone.
"Fixes" https://bugs.freedesktop.org/show_bug.cgi?id=86300
Based on discussion someone else who had a similar issue, most probably
the user is releasing FT_Face before destructing hb_face_t / hb_font_t.
While that's a client bug, and while we can (and should) use FreeType
refcounting to help avoid that, it happens that we were accessing
the table when we didn't really have to. Avoid that.
Sometimes font designers form half/pref/etc consonant forms
unconditionally and then undo that conditionally. Try to
recover the OT_H classification in those cases.
No test number changes expected.
Normally if you want to, say, conditionally prevent a 'pref', you
would use blocking contextual matching. Some designers instead
form the 'pref' form, then undo it in context. To detect that
we now also remember glyphs that went through MultipleSubst.
In the only place that this is used, Uniscribe seems to only care
about the "last" transformation between Ligature and Multiple
substitions. Ie. if you ligate, expand, and ligate again, it
moves the pref, but if you ligate and expand it doesn't. That's
why we clear the MULTIPLIED bit when setting LIGATED.
Micro-test added. Test: U+0D2F,0D4D,0D30 with font from:
[1]
https://code.google.com/a/google.com/p/noto-alpha/issues/detail?id=186#c29
Before we were just relying on the compiler inlining them and not
leaving a trace in our public API. Try to fix. Hopefully not
breaking anyone's build.
Unicode 6.2.0 Section 16.2 / Figure 16.3 says:
"For backward compatibility, between Arabic characters a ZWJ acts just
like the sequence <ZWJ, ZWNJ, ZWJ>, preventing a ligature from forming
instead of requesting the use of a ligature that would not normally be
used. As a result, there is no plain text mechanism for requesting the
use of a ligature in Arabic text."
As such, we flip internal zwj to zwnj flags for GSUB matching, which
means it will block ligation in all features, unless the font
explicitly matches U+200D glyph. This doesn't affect joining behavior.
If there's a mark ligating forward with non-mark, they were
inheriting the GC of the mark and later get advance-zeroed.
Don't do that if there's any non-mark glyph in the ligature.
Sample test: U+1780,U+17D2,U+179F with Kh-Metal-Chrieng.ttf
Also:
Bug 58922 - Issue with mark advance zeroing in generic shaper
Behdad Esfahbod
Chun-wei Fan