- 12 12月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 03 12月, 2013 1 次提交
-
- 02 12月, 2013 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Jonathan Kew 提交于
-
由 Behdad Esfahbod 提交于
Will fix by removing shape_plan->face completely.
-
- 30 11月, 2013 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Khaled Hosny 提交于
CoreText does automatic font fallback (AKA "cascading") for characters not supported by the requested font, and provides no way to turn it off, so detect if the returned run uses a font other than the requested one and fill in the buffer with .notdef glyphs instead of random indices glyph from a different font.
-
- 27 11月, 2013 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 26 11月, 2013 3 次提交
-
-
由 Behdad Esfahbod 提交于
The spec and Uniscribe don't allow these, but UTN#11 specifically says the sequence U+104B,U+1038 is valid. As such, allow all "P V" sequences. There's about eight sequences that match that structure, but Roozbeh thinks it's fine to allow all of them. Test case: U+104B, U+1038 https://bugs.freedesktop.org/show_bug.cgi?id=71947
-
由 Behdad Esfahbod 提交于
The spec and Uniscribe treat it as consonant in the grammar, but it's not in IndicSyllableCategory.txt, so fix up. Test sequence: U+1004,U+103A,U+1039,U+104E https://bugs.freedesktop.org/show_bug.cgi?id=71948
-
由 Behdad Esfahbod 提交于
This is broken sequence according to OpenType spec, Uniscribe, and current HarfBuzz implementation. But Roozbeh says this is a valid sequence, so allow it. There are multiple "(DB As?)?" constructs in the grammar, but Roozbeh thinks only this one needs changing. Test case: 1014,1063,103A Fixes https://bugs.freedesktop.org/show_bug.cgi?id=71949
-
- 25 11月, 2013 2 次提交
-
-
由 Roozbeh Pournader 提交于
Based on research into latest SIL and Windows fonts, pulling in the latest OpenType language tag proposal from Microsoft, and updating to latest language tags and names from ISO 639.
-
由 Roozbeh Pournader 提交于
Tags based on support in Windows 8.1's 'Myanmar Text' font.
-
- 21 11月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 16 11月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
Previously we were only setting this in hb_buffer_clear_contents(), but set_length(0) is a valid way to reinitialize buffer to use with new text.
-
- 14 11月, 2013 3 次提交
-
-
由 Behdad Esfahbod 提交于
Fixes last of scratch alignment warnings in hb-coretext.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 13 11月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 07 11月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
Patch from Scott Fleischman. Warnings were: harfbuzz/src/hb-font-private.hh:121:42: Implicit conversion loses integer precision: 'long long' to 'hb_position_t' (aka 'int') harfbuzz/src/hb-font-private.hh:126:42: Implicit conversion loses integer precision: 'long long' to 'hb_position_t' (aka 'int') harfbuzz/src/hb-font-private.hh:400:85: Implicit conversion loses integer precision: 'long long' to 'hb_position_t' (aka 'int') harfbuzz/src/hb-ot-layout-common-private.hh:1115:37: Implicit conversion loses integer precision: 'long long' to 'int' harfbuzz/src/hb-ft.cc:421:97: Implicit conversion loses integer precision: 'unsigned long long' to 'int' harfbuzz/src/hb-ft.cc:422:97: Implicit conversion loses integer precision: 'unsigned long long' to 'int'
-
- 31 10月, 2013 2 次提交
-
-
由 Behdad Esfahbod 提交于
Patch from Jonathan Kew.
-
由 Behdad Esfahbod 提交于
Patch from Emil Eklund.
-
- 29 10月, 2013 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
See thread started by Jonathan with subject "an optimization for complex fonts".
-
- 28 10月, 2013 4 次提交
-
-
由 Behdad Esfahbod 提交于
This reverts commit d5bd0590. The reasoning behind that logic was flawed and made under a misunderstanding of the original problem, and caused regressions as reported by Jonathan Kew in thread titled "tibetan marks" in Oct 2013. Apparently I have had fixed the original problem with this commit: 7e08f125 So, revert the faulty commit and everything seems to be in good shape.
-
由 Behdad Esfahbod 提交于
Avoids "deprecated" warnings.
-
由 Behdad Esfahbod 提交于
For Javanese (pref_len == 1) only reorder if it didn't ligate. That's sensible, and what the spec says. For other Indic (pref_len > 1) only reorder if ligated. Doesn't change any test numbers.
-
由 Behdad Esfahbod 提交于
Patch from Jonathan Kew. "These changes seem to yield a small but just-about-measurable improvement with old fonts that lack GPOS kerning."
-
- 27 10月, 2013 1 次提交
-
-
- 24 10月, 2013 2 次提交
-
-
由 Behdad Esfahbod 提交于
Followup from 6e613f33.
-
由 Behdad Esfahbod 提交于
-
- 19 10月, 2013 6 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
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 Test with U+0CB0,U+200D,U+0CCD,U+0C95,U+0CBF and tunga.ttf. Improves some scripts. Improves Bengali too, but numbers are up because we produce better results than Uniscribe for some sequences now. New numbers: BENGALI: 353724 out of 354188 tests passed. 464 failed (0.131004%) 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: 1048140 out of 1048334 tests passed. 194 failed (0.0185056%) 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%)
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
This seems to generate much better, almost-perfect, positioning for Arabic as well as Latin above marks.
-