Currently just announces lookup applications. Message-API *will* change.
hb-shape / hb-view are updated to print-out messages to stder if --debug
is specified.
We regeressed Malayalam in 508cc3d3cf
This brings down the failures to 198 (from 750).
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
GUJARATI: 366349 out of 366457 tests passed. 108 failed (0.0294714%)
GURMUKHI: 60732 out of 60747 tests passed. 15 failed (0.0246926%)
KANNADA: 951190 out of 951913 tests passed. 723 failed (0.0759523%)
KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%)
MALAYALAM: 1048136 out of 1048334 tests passed. 198 failed (0.0188871%)
ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%)
SINHALA: 271662 out of 271847 tests passed. 185 failed (0.068053%)
TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
MYANMAR: 1123865 out of 1123883 tests passed. 18 failed (0.00160159%)
Test stats remain unchanged, except for Malayalam, which we investigate:
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
GUJARATI: 366349 out of 366457 tests passed. 108 failed (0.0294714%)
GURMUKHI: 60732 out of 60747 tests passed. 15 failed (0.0246926%)
KANNADA: 951190 out of 951913 tests passed. 723 failed (0.0759523%)
KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%)
MALAYALAM: 1047584 out of 1048334 tests passed. 750 failed (0.0715421%)
ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%)
SINHALA: 271662 out of 271847 tests passed. 185 failed (0.068053%)
TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
Myanmar, compared to Windows 10 mmrtext.ttf:
MYANMAR: 1123865 out of 1123883 tests passed. 18 failed (0.00160159%)
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.
Say, if we are ligating "A B_C m D", then previously 'm' was being
attached to 'B' in the combined A_B_C_D ligature. Now we attach it
to 'C'. No test for this though :(.
We use three bits for lig_id these days, so we finally got a report of
two separate ligatures with the same lig_id happening adjacent to each
other, and then the component-handling code was breaking things.
Protect against that by ignoring same-lig-id but lig-comp=0 glyphs after
a new ligature.
Fixes https://github.com/behdad/harfbuzz/issues/198
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 '-w' instead of '\<...\>' for check-header-guards
grep manpage says these are the same
- put '-q' first in the grep options
- move VAR into hb-private.hh
- hb-font-private.hh - use [VAR] instead of [] for variable array
Back in the old days, we used to apply 'calt' and 'cswh' in Arabic shaper,
with a pause in between. Then we disabled the 'cswh' because Microsoft
disabled it, but forgot to remove the unnecessary pause. Do that now.
This has the benefit that it fixes shaping with monbaiti from Windows 10.
In that version of that font, the lookups from 'calt' are duplicated in
'rclt', and Mongolian was changed to go through Universal Shaping Engine.
We still use the Arabic shaper for Mongolian. With a pause after 'calt',
we were applying the duplicate lookups from 'calt' and 'rclt' twice. It
happened to be the case that these lookups were NOT idempotent. So we
were getting wrong shaping. See thread "Windows 10 monbaiti.ttf upgrade
(5.01 -> 5.51) caused loss of diacritical marks when shaped with harfbuz"
on the mailing list. This fixes that.
This aims to make Syriac Abbr Mark sizing more accurate when repeating segments are used, by adding an extra repeat and tightening up the spacing slightly rather than leaving a shortfall corresponding to a partial repeat-width.
This was brorken earlier, though, it's really hard to notice it.
Unlike the glyph_h_origin(), an unset glyph_v_origin() does NOT
mean that the vertical origin is at 0,0.
Related to https://github.com/behdad/harfbuzz/issues/187
Fixes https://github.com/behdad/harfbuzz/issues/187
Funcs implementations that have a non-zero horizontal origin must
implement the glyph_h_origin() callback, nothing new here.
Other implementations (all I know of!) can simply not set
glyph_h_origin() now. I did that for hb-ot and hb-ft in
44f8275080, though that broke the
fallback shaper because the default was returning false...
This prepares the headers for exporting symbols using visibility
attributes or __declspec(dllexport), so that we do not need to maintain
symbols listing files, as this is what was and is done in GLib and GTK+.
This is just to make it harder to be extremely slow. There definitely
are ways still, just harder. Oh well... how do we tame this problem
without solving halting problem?!
Fixes https://github.com/behdad/harfbuzz/issues/174
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 reverts commit f92bd86cc8.
We don't want to be like cairo, where as soon as there's an error,
nothing works anymore. So, lets process lookups as long as there's
no new memory needed. That's also a model that hides fewer bugs.
The feature is enabled for any character in the Arabic shaper.
We should experiment with using it for Arabic subtending marks.
Though, that has a directionality problem as well, since those
are used with digits...
Fixes https://github.com/behdad/harfbuzz/issues/141
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.
Also route fuzzing-related tests through hb-ot-font, to reduce dependency
on FreeType behavior for badly-broken fonts. Fixes failing test with
FreeType master.
The default FreeType load flags where changed from FT_LOAD_NO_HINTING
to FT_LOAD_DEFAULT in 2a9627c564.
This is crashing HarfBuzz-enabled FreeType as I suppose it causes
infinite recursion between HB and FT autohinter...
Revert the behavior change.
Fixes https://github.com/behdad/harfbuzz/issues/143
This changes the default load_flags of fonts created using
hb_ft_font_create() from NO_HINTING to DEFAULT. Hope that doesn't
break too much client code.
Code calling hb_ft_font_set_funcs() is unaffected.
The BCP-47 registry defines a variant subtag "fonipa" that can be used
in combination with arbitrary other language tags. For example,
"rm-CH-fonipa-sursilv" indicates the Sursilvan dialect of Romansh
as used in Switzerland, transcribed used the International Phonetic
Alphabet.
http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
A while back we marked every API as version:1.0. We should fix them all
to reflect real version they were introduced. This is a start.
Patch from Nikolay Sivov.