- 02 5月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
For consistency.
-
- 07 3月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 24 2月, 2018 1 次提交
-
-
由 Ebrahim Byagowi 提交于
-
- 21 2月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 20 1月, 2018 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 12 1月, 2018 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 10 1月, 2018 4 次提交
-
-
由 Behdad Esfahbod 提交于
New API: HB_BUFFER_FLAG_REMOVE_DEFAULT_IGNORABLES hb-shape / hb-view --remove-default-ignorables One more text-rendering-tests test passing. Eleven failing.
-
由 Behdad Esfahbod 提交于
So I can merge this to master...
-
由 Behdad Esfahbod 提交于
Also makes hb-ot-shape call morx for now instead of GSUB... Just for testing.
-
由 Behdad Esfahbod 提交于
-
- 21 11月, 2017 1 次提交
-
-
由 ebraminio 提交于
-
- 15 11月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
This only counts recursions right now. Good start. Hopefully... Fixes https://github.com/behdad/harfbuzz/issues/429
-
- 23 10月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 15 10月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 03 10月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
This should affect mark attachment in vertical text. I have no font to test, but this sounds the right order. Noticed while debugging https://github.com/behdad/harfbuzz/issues/532
-
- 05 9月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
Fixes tests/shaping/tests/cluster.tests
-
- 31 8月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
Fixes tests/automatic-fractions.tests
-
- 12 8月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
Makes consumption easier.
-
- 11 8月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 03 3月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 04 2月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 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
-
- 23 12月, 2016 2 次提交
-
-
由 Behdad Esfahbod 提交于
New approach to fix this: https://github.com/behdad/harfbuzz/commit/69f9fbc4200442a35484d3c790ae8f4979be5d60 Previous approach was reverted as it was too broad. See context: https://github.com/behdad/harfbuzz/issues/347#issuecomment-267838368 With U+05E9,U+05B8,U+05C1,U+05DC and Arial Unicode, we now (correctly) disable GDEF and GPOS, so we get results very close to Uniscribe, but slightly different since our fallback position logic is not exactly the same: Before: [gid1166=3+991|gid1142=0+737|gid5798=0+1434] After: [gid1166=3+991|gid1142=0@402,-26+0|gid5798=0+1434] Uniscribe: [gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]
-
由 Behdad Esfahbod 提交于
This reverts commit 69f9fbc4. See https://github.com/behdad/harfbuzz/issues/347#issuecomment-268873401 Fixes https://github.com/behdad/harfbuzz/issues/347
-
- 17 12月, 2016 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Shape-plan caching is not implemented.
-
- 18 3月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
Previously we only synthesized GDEF glyph classes if the glyphClassDef array in GDEF was null. This worked well enough, and is indeed what OpenType requires: "If the font does not include a GlyphClassDef table, the client must define and maintain this information when using the GSUB and GPOS tables." That sentence does not quite make sense since one needs Unicode properties as well, but is close enough. However, looks like Arial Unicode as shipped on WinXP, does have GDEF glyph class array, but defines no classes for Hebrew. This results in Hebrew marks not getting their widths zeroed. So, with this change, we synthesize glyph class for any glyph that is not specified in the GDEF glyph class table. Since, from our point of view, a glyph not being listed in that table is a font bug, any unwanted consequence of this change is a font bug :). Note that we still don't get the same rendering as Uniscribe, since Uniscribe seems to do fallback positioning as well, even though the font does have a GPOS table (which does NOT cover Hebrew!). We are not going to try to match that though. Test string for Arial Unicode: U+05E9,U+05B8,U+05C1,U+05DC Before: [gid1166=3+991|gid1142=0+737|gid5798=0+1434] After: [gid1166=3+991|gid1142=0+0|gid5798=0+1434] Uniscribe: [gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434] Note that our new output matches what we were generating until July 2014, because the Hebrew shaper used to zero mark advances based on Unicode, NOT GDEF. That's 9e834e29. Reported by Greg Douglas.
-
- 24 2月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
New API: - hb_font_get_nominal_glyph_func_t - hb_font_get_variation_glyph_func_t - hb_font_funcs_set_nominal_glyph_func() - hb_font_funcs_set_variation_glyph_func() - hb_font_get_nominal_glyph() - hb_font_get_variation_glyph() Deprecated API: - hb_font_get_glyph_func_t - hb_font_funcs_set_glyph_func() Clients that implement their own font-funcs are encouraged to replace their get_glyph() implementation with a get_nominal_glyph() and get_variation_glyph() pair. The variation version can assume that variation_selector argument is not zero.
-
- 22 2月, 2016 3 次提交
-
-
由 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
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 11 2月, 2016 3 次提交
-
-
由 Behdad Esfahbod 提交于
Right now the position_finish_advances() is empty. To be used for spacing attachments proposal later.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Is confusing. I already hit it myself. Remove. We can optimize ASCII based on Unicode properties. But should not do based on assumptions on the font.
-
- 10 2月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 27 11月, 2015 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
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
-