- 03 10月, 2017 2 次提交
-
-
由 Behdad Esfahbod 提交于
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
-
由 Behdad Esfahbod 提交于
Mark it as matra below to allow the sequence U+0A15, U+0A51, U+0A47. Oh well... Fixes https://github.com/behdad/harfbuzz/issues/524
-
- 02 10月, 2017 1 次提交
-
-
- 02 9月, 2017 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Fixes https://github.com/behdad/harfbuzz/issues/528 "Kannada JIHVAMULIYA and UPADHMANIYA insert dotted circles"
-
- 09 8月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 15 7月, 2017 2 次提交
-
-
- 14 7月, 2017 4 次提交
-
-
由 Behdad Esfahbod 提交于
Part of https://github.com/behdad/harfbuzz/issues/376 Also see https://github.com/roozbehp/unicode-data/issues/6 Test added, using NotoSansCham built from Noto Phase III sources.
-
-
由 Behdad Esfahbod 提交于
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%)
-
由 Dominik Schlösser 提交于
* 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)
-
- 18 5月, 2017 1 次提交
-
-
由 Khaled Hosny 提交于
Hide them like Mongolian Free Variation Selectors instead. Fixes https://github.com/behdad/harfbuzz/issues/463
-
- 11 3月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
This reverts commit b9b005f3. This introduced invalid access cases. Revert until I fix correctly.
-
- 02 3月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
This was broken forever, since days that we did not allow moving tape backwards. Works now. Reported by Doug Felt.
-
- 26 2月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 17 2月, 2017 2 次提交
-
-
由 jfkthame 提交于
* 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.
-
由 jfkthame 提交于
* [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
-
- 27 1月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
Fixes joined Adlam rendering. Fixes https://github.com/googlei18n/noto-fonts/issues/828
-
- 19 1月, 2017 1 次提交
-
-
由 Khaled Hosny 提交于
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
-
- 06 1月, 2017 1 次提交
-
-
- 22 12月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
As discovered by libFuzzer / Chromium fuzzing. Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=659496 CC https://github.com/behdad/harfbuzz/issues/139
-
- 05 12月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 27 10月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 09 8月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
Using font from https://github.com/behdad/harfbuzz/issues/300
-
- 07 5月, 2016 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 02 5月, 2016 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
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.
-
- 27 4月, 2016 1 次提交
-
-
- 05 4月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 24 2月, 2016 3 次提交
-
-
由 Behdad Esfahbod 提交于
Not sure why the FT functions were returning advance 1024. This caused failure on drone.io. Switch to hb-ot-font and disable glyph names.
-
由 Behdad Esfahbod 提交于
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.
-
由 Behdad Esfahbod 提交于
Apparently I broke this 86c68c7a. Fix coming.
-
- 23 2月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
They are unused currently. We can add later if we hook them up to anything useful.
-
- 22 2月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
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
-
- 19 2月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
Test from https://github.com/behdad/harfbuzz/issues/223 I forgot that we do run hb-fuzzer on tests in shaping/tests/fuzzed.tests.
-
- 16 2月, 2016 2 次提交
-
-
由 Behdad Esfahbod 提交于
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.
-
由 Behdad Esfahbod 提交于
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.
-
- 11 2月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
-