- 18 7月, 2014 6 次提交
-
-
由 Behdad Esfahbod 提交于
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.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
This reverts bf029281 and fixes it properly. That commit was not enough as it was only inheriting the shaping_action for prev_action, but not curr_action. Micro-test added. https://code.google.com/p/chromium/issues/detail?id=393896
-
由 Behdad Esfahbod 提交于
We now handle U+FFFD replacement in hb_buffer_add_utf*(). Any other manipulation can happen in user callbacks. No need for this. https://github.com/behdad/harfbuzz/commit/efe74214bbb68eaa3d7621e73869b5d58210107e#commitcomment-7039404 This reverts commit efe74214. Conflicts: src/hb-ot-shape-normalize.cc
-
由 Dominik Röttsches 提交于
-
- 17 7月, 2014 12 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
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: https://github.com/behdad/harfbuzz/commit/6f13b6d62daae4989e3cc2fe4b168e5c59650964 New API: hb_buffer_set_replacement_codepoint() hb_buffer_get_replacement_codepoint()
-
由 Behdad Esfahbod 提交于
Like hb_buffer_add_utf32, but doesn't do any Unicode validation. This is like what hb_buffer_add_utf32 used to be until a couple commits ago.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Same as what we do for UTF-8 and UTF-16.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Originally we fixed those in 79d1007a. 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
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 16 7月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 12 7月, 2014 9 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Enable tests that were disabled before, and adjust one test, and add more tests.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Though, looks like gcc was smart enough to produce the same code before...
-
由 Behdad Esfahbod 提交于
Simplifies hb_in_range() calls as the type can be inferred. The rest is obsessiveness, I admit.
-
由 Behdad Esfahbod 提交于
It's both faster and produces smaller code. Now I feel stupid for not writing it this way before.
-
由 Behdad Esfahbod 提交于
-
- 11 7月, 2014 7 次提交
-
-
由 Behdad Esfahbod 提交于
Only if the font doesn't support it. Ie, this gives the user to use non-Unicode codepoints as private values and return a meaningful glyph for them. But if it's invalid and font callback doesn't like it, and if font has U+FFFD, show that instead. Font functions that do not want this automatic replacement to happen should return true from get_glyph() if unicode > 0x10FFFF. Replaces https://github.com/behdad/harfbuzz/pull/27
-
由 Behdad Esfahbod 提交于
Test passes now.
-
由 Behdad Esfahbod 提交于
Currenty fails. Ouch!
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Previous code was broken logically, but harmless.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 10 7月, 2014 5 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-