New version has axis flags.
New API:
+hb_ot_var_axis_info_t
+hb_ot_var_find_axis_info()
+hb_ot_var_get_axis_infos()
Deprecated API:
-HB_OT_VAR_NO_AXIS_INDEX
-hb_ot_var_axis_t
-hb_ot_var_find_axis()
-hb_ot_var_get_axes()
more than enough since local subrs immediately follow its corresponding private dict, as the result 2-byte redunction for each font dict with local subrs
updated api test expected subset fonts accordingly
If we have duplicae font files in different directories, that would
break the oss-fuzz build currently. So, rename some to avoid
name class with text-rendering-test. Would be better to find
another solution.
I added them but now that I think, it is a bad idea to have them as
fuzzing bots will find good seeds to tweak in order to find easy new
testcases which causes duplicated issues.
* hb_ot_layout_feature_get_characters
* hb_ot_layout_feature_get_name_ids
However HarfBuzz currently doesn't expose an API for retrieving the actual
information associated with NameId from the `name` table and that should be
done separately.
The font supports the deprecated tag 'DHV ' instead of 'DIV '. dv is
mapped to 'DIV ' and 'DHV ', in that order. The test specifies
`--language=dv`, demonstrating that if a font does not support the first
OpenType tag mapped to a BCP 47 tag, it will fall back to the next tag.
If the second subtag of a BCP 47 tag is three letters long, it denotes
an extended language. The tag converter ignores the language subtag and
uses the extended language instead.
There are some grandfathered exceptions, which are handled earlier.
The new script, gen-tag-table.py, generates `ot_languages` automatically
from the [OpenType language system tag registry][ot] and the [IANA
Language Subtag Registry][bcp47] with some manual modifications. If an
OpenType tag maps to a BCP 47 macrolanguage, all the macrolanguage's
individual languages are mapped to the same OpenType tag, except for
individual languages with their own OpenType mappings. Deprecated
BCP 47 tags are canonicalized.
[ot]: https://docs.microsoft.com/en-us/typography/opentype/spec/languagetags
[bcp47]: https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
Some OpenType tags correspond to multiple ISO 639 codes. The mapping
from ISO 639 codes lists OpenType tags in priority order, such that more
specific or more likely tags appear first.
Some OpenType tags have no corresponding ISO 639 code in the registry so
their mappings use BCP 47 subtags besides the language. For example, any
BCP 47 tag with a fonipa variant subtag is mapped to 'IPPH', and 'IPPH'
is mapped back to und-fonipa.
Other OpenType tags have no corresponding ISO 639 code because it is not
clear what they are for. HarfBuzz just ignores these tags.
One such ignored tag is 'ZHP ' (Chinese Phonetic). It probably means
zh-Latn. However, it is used in Microsoft JhengHei and Microsoft YaHei
with the script tag 'hani', implying that it is not a romanization
scheme after all. It would be simple enough to add this mapping to
gen-tag-table.py once a definitive mapping is determined.
The manual modifications are mainly either obvious mappings that the
OpenType registry omits or mappings for compatibility with previous
versions of HarfBuzz. Some of the old mappings were discarded, though,
for homophonous language names. For example, OpenType maps 'KUI ' to
kxu; previous versions of HarfBuzz also mapped it to kvd, because kvd
and kxu both happen to be called "Kui".
gen-tag-table.py also generates a function to convert multi-subtag tags
like el-polyton and zh-HK to OpenType tags, replacing `ot_languages_zh`
and the hard-coded list of special cases in `hb_ot_tags_from_language`.
It also generates a function to convert OpenType tags to BCP 47,
replacing the hard-coded list of special cases in
`hb_ot_tag_to_language`.
The old hb-ot-tag.cc functions, `hb_ot_tags_from_script` and
`hb_ot_tag_from_language`, are now wrappers around a new function:
`hb_ot_tags`. It converts a script and a language to arrays of script
tags and language tags. This will make it easier to add new script tags
to scripts, like 'dev3'. It also allows for language fallback chains;
nothing produces more than one language yet though.
Where the old functions return the default tags 'DFLT' and 'dflt',
`hb_ot_tags` returns an empty array. The caller is responsible for
using the default tag in that case.
The new function also adds a new private use subtag syntax for script
overrides: "x-hbscabcd" requests a script tag of 'abcd'.
The old hb-ot-layout.cc functions,`hb_ot_layout_table_choose_script` and
`hb_ot_layout_script_find_language` are now wrappers around the new
functions `hb_ot_layout_table_select_script` and
`hb_ot_layout_script_select_language`. They are essentially the same as
the old ones plus a tag count parameter.
Closes#495.
Makes our FT-backed hb_font_t safe to use from multiple threads. Still,
the underlying FT_Face should NOT be used from other threads by client
or other libraries.
Maybe I add a lock()/unlock() public API ala PangoFT2 and cairo-ft.
Maybe not.
How come this one is not generated by clang everything bot?!
../../../test/api/test-multithread.c:37:26: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
static char *font_path = "fonts/Inconsolata-Regular.abc.ttf";
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../test/api/test-multithread.c:38:21: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
Now that we added morx support, our OS X bot is running them through CoreText
and failing (with a DoS / infinite loop no less!). Always run tests through
our own shaper.
Fixes https://github.com/harfbuzz/harfbuzz/issues/1019
New numbers:
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707261 out of 707394 tests passed. 133 failed (0.0188014%)
GUJARATI: 366353 out of 366457 tests passed. 104 failed (0.0283799%)
GURMUKHI: 60729 out of 60747 tests passed. 18 failed (0.0296311%)
KANNADA: 951300 out of 951913 tests passed. 613 failed (0.0643966%)
MALAYALAM: 1048136 out of 1048334 tests passed. 198 failed (0.0188871%)
ORIYA: 42327 out of 42329 tests passed. 2 failed (0.00472489%)
SINHALA: 271596 out of 271847 tests passed. 251 failed (0.0923313%)
TAMIL: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
Devanagari regressed because Uniscribe doesn't enforce the full set.
Tests added with the *-vowel-letters.txt files in tree and Noto fonts.
Currently hb-subset always desubroutinizes CFF fonts.
Note that even with this option fonttools won't generate the expected subset CFF fonts. They were manually created & tweaked to match hb-subset output.
We might reintroduce it later, but for now remove, as it was unused.
Some things that should have been in this object (drop_hints, etc)
are already in hb_subset_input_t. So, for now, keep everything there.
Note that there's minor positioning differences, and ONE reordering
difference between what we get for these and what Uniscribe gets.
Probably same as what's described in commit message for
1a96cc825d
From the new code (first paragraph is from the OT Devanagari spec.):
/* o Reorder matras:
*
* If a pre-base matra character had been reordered before applying basic
* features, the glyph can be moved closer to the main consonant based on
* whether half-forms had been formed. Actual position for the matra is
* defined as “after last standalone halant glyph, after initial matra
* position and before the main consonant”. If ZWJ or ZWNJ follow this
* halant, position is moved after it.
*
* IMPLEMENTATION NOTES:
*
* It looks like the last sentence is wrong. Testing, with Windows 7 Uniscribe
* and Devanagari shows that the behavior is best described as:
*
* "If ZWJ follows this halant, matra is NOT repositioned after this halant.
* If ZWNJ follows this halant, position is moved after it."
*
* Test case, with Adobe Devanagari or Nirmala UI:
*
* U+091F,U+094D,U+200C,U+092F,U+093F
* (Matra moves to the middle, after ZWNJ.)
*
* U+091F,U+094D,U+200D,U+092F,U+093F
* (Matra does NOT move, stays to the left.)
Fixes https://github.com/harfbuzz/harfbuzz/issues/1070
Test case added with Adobe Devanagari.
* [subset] sanitize individual DeviceRecord's as part of hdmx sanitization.
* [subset] Fix out of bounds read with non-two byte align glyphs.
* [subset] Just use size_device_record >= DeviceRecord::min_size.
* [subset] Add TODO.
* [subset] Re-order checks in hdmx sanitize.
Before 1.7.5, we were setting -fno-exceptions etc on CXXFLAGS. In 1.7.6
we set it as CPPFLAGS. Try fixing. Also, I'm fairly sure it's safe to
set these unconditionally.
Fixes https://github.com/harfbuzz/harfbuzz/issues/880 (or so I hope)
Include stdbool.h in hb-setset-test.h instead of in the individual
sources, if it is found; otherwise use a simplistic fallback for it if
it is not found.
Also declare variables at the top of the block, to build on pre-C99
compiliers.
For the API tests, output the test programs at $(TOP_BUILDDIR) so that
the freshly-built DLLs will be available for the test programs. For
those that are run through the Python wrapper scripts, use
${PYTHON_EXECUTABLE} instead of plain 'python' in case the Python
interpreter is not in the PATH.
New API:
HB_BUFFER_FLAG_REMOVE_DEFAULT_IGNORABLES
hb-shape / hb-view --remove-default-ignorables
One more text-rendering-tests test passing. Eleven failing.
Previously we made CGJ unskippable. Now, if CGJ did NOT prevent
any reordering, allow skipping over it. To make this work we
had to make changes to the Arabic mark reordering algorithm
implementation to renumber moved MCM marks. See comments.
Fixes https://github.com/harfbuzz/harfbuzz/issues/554
Apparently a base glyph can also become an attached component of a
ligature if the ligature-forming lookup used IgnoreBase. This was
being confused with a non-first component of a MultipleSubst and
hence not matched for mark-attachment. Tweak test to fix.
Fixes https://github.com/behdad/harfbuzz/issues/543
New Indic numbers are:
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
GUJARATI: 366355 out of 366457 tests passed. 102 failed (0.0278341%)
GURMUKHI: 60729 out of 60747 tests passed. 18 failed (0.0296311%)
KANNADA: 951201 out of 951913 tests passed. 712 failed (0.0747968%)
KHMER: 299071 out of 299124 tests passed. 53 failed (0.0177184%)
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: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
Before 71c0a1429d GURMUKHI used to be at 15,
because Uniscribe seems to allow this character standalone, but that looks
wrong.
If two marks want to ligate and they belong to different components of the
same ligature glyph, and said ligature glyph is to be ignored according to
mark-filtering rules, then allow.
Example Burmese senquence:
U+1004,U+103A,U+1039,U+101B,U+103D,U+102D
Test font provided by Norbert Lindenberg.
Fixes https://github.com/behdad/harfbuzz/issues/545
I like to have a mode where CONTAINS_NOTDEF and CONTAINS_DOTTEDCIRCLE are not
returned. Abused a value of -1 for that. hb-shape now uses it. Fixes two
of the six tests failing with --verify in test/shaping/run-tests.sh.
Fixes https://github.com/behdad/harfbuzz/issues/294
Also fixes a bunch of other Indic issues. Test results after:
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%)
GUJARATI: 366355 out of 366457 tests passed. 102 failed (0.0278341%)
GURMUKHI: 60732 out of 60747 tests passed. 15 failed (0.0246926%)
KANNADA: 951201 out of 951913 tests passed. 712 failed (0.0747968%)
KHMER: 299071 out of 299124 tests passed. 53 failed (0.0177184%)
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: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
Before:
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%)
* Shaping tests for Tibetan vowels
* Test-cases for the Dzongkha contractions with multiple vowel-signs added.
* going to be removed
* Extended contraction-test-cases to all test cases in contractions.txt that actually use multiple-vowels (113 cases)
* Guard against underflow when adjusting length
With the fuzz-testcase in mozilla bug 1295299, we end up with a recursed lookup that removes 3 items, when `match_positions[idx]` is 0, which results in (unsigned) `end` wrapping to a huge value.
Making `end` a signed int is probably the simplest route to a fix.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1295299.
* Add testcase for #421.
* [indic] Add support for Grantha marks that may be used in Tamil to the Indic table.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1331339.
Testcase: U+0BA4,U+0BC6,U+1133c,U+0BAA,U+1133c,U+0BC6,U+1133c
* [indic] Add test for Grantha nukta that is allowed in Tamil by ScriptExtensions.txt
The numbers for right-to-left scripts are processed also from right to
left, so the order of applying “numr” and “dnom” features should be
reversed in such case.
Fixes https://github.com/behdad/harfbuzz/issues/395
It is desirable to be able to build against older versions of glib.
fd7a245 changed the configure check to require glib > 2.38 for
G_TEST_DIST. Before that, version 2.16 was required, but in fact,
since aafe395, G_PASTE is being used, which was introduced in 2.19.1.
And since 0ef179e2, hb-glib uses GBytes, which were introduced in
2.31.10.
2.19.1 is rather old, but 2.38 is rather new. For Firefox, building
against 2.22 is still supported, although we could probably get away
with bumping that to 2.28. Either way, GBytes is not available.
Arguably, if you build against a glib that doesn't support GBytes,
you're not going to use the hb_glib_blob_create function, so we hide
the function when building against such a glib.
As for G_TEST_DIST, when building against versions of glib that don't
support it, we can fallback to the previous behavior, which, AIUI, was
just making the test not work when building in a separate directory.
Note, the function now returns "half of horizontal advance width"
if top accent attachment for glyph is not explicitly defined.
This is what the spec requires. Updated tests.
The name id 0 is used as Copyright notice. It's quite unlikely that a
font supplies a color palette with the exact same name as the font's
copyright notice, but the API should not prevent this.
Also, try to fix a problem with GObject introspection, where the
auto-generated Python bindings could not return palette colors.
The so-called Python 2 “narrow” builds support UCS2 only, this is a
workaround to allow unichr to work with any Unicode character in such
builds. This fixes Travis-CI failure as it has narrow Python 2 builds.
Copied from:
https://github.com/behdad/fonttools/blob/master/Lib/fontTools/misc/py23.py
Fixes https://github.com/behdad/harfbuzz/issues/243
With javatext.ttf, the reodering medial Ra gets its advance width
zero'ed in Uniscribe implementation, and the font adds the advance
back. Our Indic shaper does not do that, but USE does. So, route
Javanese through USE. That's what Microsoft does anyway. Test:
U+A9A5,U+A9BA
This also seems to fix the following sequence, and variations thereof:
U+A99F,U+A9C0,U+A9A2,U+A9BF
Apparently some clients have reference-table callbacks that copy the table.
As such, avoid loading 'glyf' table which is only needed if fallback positioning
happens.
That commit moved the advance adjustment for mark positioning to
be applied immediately, instead of doing late before. This breaks
if mark advances are zeroed late, like in Arabic. Also, easier to
hit it in RTL scripts since a single mark with non-zero advance is
enough to hit the bug, whereas in LTR, at least two marks are needed.
This reopens https://github.com/behdad/harfbuzz/issues/211
The cursive+mark interaction is broken again. To be fixed in a
different way.
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
This is what Microsoft's implementation does. Marks that need advance
need to add it back using 'dist' or other feature in GPOS. Update tests to
match.
Fixes https://github.com/behdad/harfbuzz/issues/211
What happens in that bug is that a mark is attached to base first,
then a second mark is cursive-chained to the first mark. This only
"works" because it's in the Indic shaper where mark advances are
not zeroed.
Before, we didn't allow cursive to run on marks at all. Fix that.
We also where updating mark major offsets at the end of GPOS, such
that changes in advance of base will not change the mark attachment
position. That was superior to the alternative (which is what Uniscribe
does BTW), but made it hard to apply cursive to the mark after it
was positioned. We could track major-direction offset changes and
apply that to cursive in the post process, but that's a much trickier
thing to do than the fix here, which is to immediately apply the
major-direction advance-width offsets... Ie.:
https://github.com/behdad/harfbuzz/issues/211#issuecomment-183194739
If this breaks any fonts, the font should be fixed to do mark attachment
after all the advances are set up first (kerning, etc).
Finally, this, still doesn't make us match Uniscribe, for I explained
in that bug. Looks like Uniscribe applies minor-direction cursive
adjustment immediate as well. We don't, and we like it our way, at
least for now. Eg. the sequence in the test case does this:
- The first subscript attaches with mark-to-base, moving in x only,
- The second subscript attaches with cursive attachment to first subscript
moving in x only,
- A final context rule moves the first subscript up by 104 units.
The way we do, the final shift-up, also shifts up the second subscript
mark because it's cursively-attached. Uniscribe doesn't. We get:
[ttaorya=0+1307|casubscriptorya=0@-242,104+-231|casubscriptnarroworya=0@20,104+507]
while Uniscribe gets:
[ttaorya=0+1307|casubscriptorya=0@-242,104+-211|casubscriptnarroworya=0+487]
note the different y-offset of the last glyph. In our view, after cursive,
things move together, period.
This test font had a upem of 769, which results in rounding-related errors with
the FreeType font funcs. Change the upem to 1024 to fix that.
Fixes https://github.com/behdad/harfbuzz/issues/201
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
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
To fully test what these are supposed to test, they should be run
against libharfbuzz-fuzzing.la instead of libharfbuzz.la, but for
now just record the files.
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 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
Fails now. Fix coming. See thread "Issue with cursive attachment"
started by Khaled. Test fonts were made by modifying test font
from Khaled to add more anchors.
Based on test from https://code.google.com/p/chromium/issues/detail?id=497578
Currently fails. Basically, if there's a default_ignorable at the
start of text, and font has no space glyph, we remove the default_ignorable,
and that makes the first char in text to correspond to no cluster.
Fix coming.
Previously, when creating an object from inert inputs (eg:
"hb_font_create(hb_face_get_empty())") we returned the inert
empty object. This is not helpful as there are legitimate
usecases to do that.
We now never return the inert object unless allocation failed.
Tests are revised to reflect.
On ArchLinux, /usr/bin/python is linked to python 3 so
HarfBuzz `make check` is broken there.
This makes hb_test_tools.py compatible with python 3 while
no breaking it on python 2.
Fail if blob start plus length overflows; or if blob length
is greater than 2GB. It takes a while for fonts to get to that
size. In the mean time, it protects against bugs like this:
http://www.icu-project.org/trac/ticket/11450
Also avoids some weird issues with 32bit vs 64bit systems
as we accept length as unsigned int. As such, a length of
-1 will cause overflow on 32bit machines, but happily
accepted on a 64bit machine. Avoid that.
In Oriya, a ZWJ/ZWNJ might be added before candrabindu to encourage
or stop ligation of the candrabindu. This is clearly specified in
the Unicode section on Oriya. Allow it there. Note that Uniscribe
doesn't allow this.
Micro tests added using Noto Sans Oriya draft.
No changes in numbers. Currently at:
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: 1048147 out of 1048334 tests passed. 187 failed (0.0178378%)
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%)
After 763e5466c0, one doesn't
need to set flags for different pieces of text. The flags now
are something the client sets up once, depending on how it
actually uses the buffer. As such, don't clear it in
clear_contents().
Tests updated.
Seems to be what Uniscribe does.
At this point I think it's work checking our default...
Fixes Bug 76767 - Zeroing of advance of 2nd component of multiple
substitution with SBL Hebrew
https://bugs.freedesktop.org/show_bug.cgi?id=76767
Micro-test added.
Looks like Unsicribe responds to the 'mymr' tag by zeroing marks
GDEF_LATE instead of generic-shaper UNICODE_LATE. Implement that.
Fixes
Bug 81775 - Incorrect Rendering with harfbuzz-ng myanmar unicode
https://bugs.freedesktop.org/show_bug.cgi?id=81775
Micro-test added based on Padauk.
Follows the order of the Arabic/Syriac specs. Also don't stop
between rlig and calt in non-Arabic scripts.
Micro-tests for Arabic and Mongolian added for the latter.
With this change, we now by default replace broken UTF-8/16/32 bits
with U+FFFD. This can be changed by calling new API on the buffer.
Previously the replacement value used to be (hb_codepoint_t)-1.
Note that hb_buffer_clear_contents() does NOT reset the replacement
character.
See discussion here:
6f13b6d62d
New API:
hb_buffer_set_replacement_codepoint()
hb_buffer_get_replacement_codepoint()
Originally we fixed those in 79d1007a50.
However, fonts like MongolianWhite don't have GDEF, but have IgnoreMarks
in their LigatureSubstitute init/etc features. We were synthesizing a
GDEF class of mark for Mongolian Variation Selectors and as such the
ligature lookups where not matching. Uniscribe doesn't do that.
I tried with more sophisticated fixes, like, if there is no GDEF and
a lookup-flag mismatch happens, instead of rejecting a match, try
skipping that glyph. That surely produces some interesting behavior,
but since we don't want to support fonts missing GDEF more than we have
to, I went for this simpler fix which is to always mark
default-ignorables as base when synthesizing GDEF.
Micro-test added.
Fixes rest of https://bugs.freedesktop.org/show_bug.cgi?id=65258
HB_VERSION_CHECK's comparison was originally written wrongly
by mistake. When API tests were written, they were also written
wrongly to pass given the wrong implementation... Sigh.
Given the purpose of this API, there's no point in fixing it
without renaming it. As such, rename.
API changes:
HB_VERSION_CHECK -> HB_VERSION_ATLEAST
hb_version_check -> hb_version_atleast
If pre-base reordering Ra is NOT formed (or formed and then
broken up), we should consider that Ra as base. This is
observable when there's a left matra or dotreph that positions
before base.
Now, it might be that we shouldn't do this if the Ra happend
to form a below form. We can't quite deduce that right now...
Micro test added. Also at:
https://code.google.com/a/google.com/p/noto-alpha/issues/detail?id=186#c29
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
Bug 70509 - Candrabindu+Visarga doesn't work in Devanagari
https://bugs.freedesktop.org/show_bug.cgi?id=70509
We categorize both bindus and visarga as syllable-modifiers.
OT spec doesn't actually say what characters go in the syllable
modifier category, and allows one. We just allow up to two now.
Test case: U+0930,U+0941,U+0901,U+0903
Uniscribe currently doesn't support that and produces a
dotted circle.
More like Uniscribe... We still allow user-defined features to
work across syllables, but not pres,blws,abs,psts,etc.
This "regressed" Sinhala numbers by 11. These are cases were
there's Consonant followed by Ra,Halant,ZWJ at the of text.
The Ra,Halant,ZWJ ends up forming reph, which is wrong...
But before we were also ligating that reph with the previous
consonant. That's even more wrong. That's also what Uniscribe
does.
Current numbers:
BENGALI: 353732 out of 354188 tests passed. 456 failed (0.128745%)
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: 951030 out of 951913 tests passed. 883 failed (0.0927606%)
KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%)
MALAYALAM: 1048140 out of 1048334 tests passed. 194 failed (0.0185056%)
ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%)
SINHALA: 271655 out of 271847 tests passed. 192 failed (0.070628%)
TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
The new test suite runs tests included under
hb/test/shaping/tests/*.tests, which themselves reference
font files stored by sha1sum under hb/test/shaping/fonts/sha1sum.
The fonts are produced using a subsetter to only include glyphs
needed to run the test.
Four initial tests are added for (Chain)Context matching,
of which three currently fail.
After the Ngapi hackfest work, we were assuming that fonts
won't use presentation features to choose specific forms
(eg. conjuncts). As such, we were using auto-joiner behavior
for such features. It proved to be troublesome as many fonts
used presentation forms ('pres') for example to form conjuncts,
which need to be disabled when a ZWJ is inserted.
Two examples:
U+0D2F,U+200D,U+0D4D,U+0D2F with kartika.ttf
U+0995,U+09CD,U+200D,U+09B7 with vrinda.ttf
What we do now is to never do magic to ZWJ during GSUB's main input
match for Indic-style shapers. Note that backtrack/lookahead are still
matched liberally, as is GPOS. This seems to be an acceptable
compromise.
As to the bug that initially started this work, that one needs to
be fixed differently:
Bug 58714 - Kannada u+0cb0 u+200d u+0ccd u+0c95 u+0cbe does not
provide same results as Windows8
https://bugs.freedesktop.org/show_bug.cgi?id=58714
New numbers:
BENGALI: 353689 out of 354188 tests passed. 499 failed (0.140886%)
DEVANAGARI: 707305 out of 707394 tests passed. 89 failed (0.0125814%)
GUJARATI: 366349 out of 366457 tests passed. 108 failed (0.0294714%)
GURMUKHI: 60706 out of 60747 tests passed. 41 failed (0.067493%)
KANNADA: 951030 out of 951913 tests passed. 883 failed (0.0927606%)
KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%)
LAO: 53611 out of 53644 tests passed. 33 failed (0.0615167%)
MALAYALAM: 1048102 out of 1048334 tests passed. 232 failed (0.0221304%)
ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%)
SINHALA: 271666 out of 271847 tests passed. 181 failed (0.0665816%)
TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
TIBETAN: 208469 out of 208469 tests passed. 0 failed (0%)
The code was confused because it was expecting left matra to have
POS_PRE_M, like we do in the Myanmar shaper, but that is not what
we were doing in this shaper. Rewrite to rely on category only.
Test case: U+AA06,U+AA34,U+AA2F
David Corbett
Behdad Esfahbod
Michiharu Ariza
punchcutter
Ebrahim Byagowi
Khaled Hosny
Chun-wei Fan
lantw44
Garret Rieger
Jonathan Kew
violet-sippial
rsheeter
Dominik Schlösser
Dominik Schloesser
Philip Withnall
Sascha Brawer
Mike Hommey
Frédéric Wang
Romain Naour
Luis de Bethencourt