- 07 1月, 2015 1 次提交
-
-
由 Behdad Esfahbod 提交于
Minimal shaping works now!
-
- 06 1月, 2015 1 次提交
-
-
由 Behdad Esfahbod 提交于
ICU exports them using LOCAL_EXPORT_C_INCLUDE_DIRS. https://android-review.googlesource.com/#/c/121311/
-
- 05 1月, 2015 2 次提交
-
-
由 Behdad Esfahbod 提交于
Add #ifdef HB_USE_ATEXIT to fix -Wunused-function warnings
-
由 Chris Peterson 提交于
-
- 04 1月, 2015 2 次提交
-
-
由 Behdad Esfahbod 提交于
Fix hb_atomic_ptr_cmpexch -Wunused-value warnings
-
由 Chris Peterson 提交于
-
- 03 1月, 2015 1 次提交
-
-
- 29 12月, 2014 6 次提交
-
-
由 Behdad Esfahbod 提交于
For discussion see: http://lists.freedesktop.org/archives/harfbuzz/2012-April/001905.html Over time we have had added NO_HINTING all over the place in hb-ft. Finish it off. Not setting ppem on hb-font disables get_contour_point() calls which is good anyway. See comments in the commit.
-
由 Behdad Esfahbod 提交于
When I originally wrote hb-ft, FreeType objects did not support reference counting. As such, hb_ft_face_create() and hb_ft_font_create() had a "destroy" callback and client was responsible for making sure FT_Face is kept around as long as the hb-font/face are alive. However, since this was not clearly documented, some clienets didn't correctly did that. In particular, some clients assumed that it's safe to destroy FT_Face and then hb_face_t. This, indeed, used to work, until 45fd9424, which make face destroy access font tables. Now, I fixed that issue in 395b3590 since the access was not needed, but the problem remains that not all clients handle this correctly. See: https://bugs.freedesktop.org/show_bug.cgi?id=86300 Fortunately, FT_Reference_Face() was added to FreeType in 2010, and so we can use it now. Originally I wanted to change hb_ft_face_create() and hb_ft_font_create() to reference the face if destroy==NULL was passed in. That would improve pretty much all clients, with little undesired effects. Except that FreeType itself, when compiled with HarfBuzz support, calls hb_ft_font_create() with destroy==NULL and saves the resulting hb-font on the ft-face (why does it not free it immediately?). Making hb-face reference ft-face causes a cycling reference there. At least, that's my current understanding. At any rate, a cleaner approach, even if it means all clients will need a change, is to introduce brand new API. Which this commit does. Some comments added to hb-ft.h, hoping to make future clients make better choices. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=75299
-
由 Behdad Esfahbod 提交于
We require FreeType >= 2.8.3. This symbol was introduced earlier than that.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
HB_MEMORY_MODE_READONLY_MAY_MAKE_WRITABLE is deprecated and fairly useless now.
-
由 Behdad Esfahbod 提交于
"Fixes" https://bugs.freedesktop.org/show_bug.cgi?id=86300 Based on discussion someone else who had a similar issue, most probably the user is releasing FT_Face before destructing hb_face_t / hb_font_t. While that's a client bug, and while we can (and should) use FreeType refcounting to help avoid that, it happens that we were accessing the table when we didn't really have to. Avoid that.
-
- 19 12月, 2014 2 次提交
-
-
由 Behdad Esfahbod 提交于
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.
-
由 Behdad Esfahbod 提交于
This will crash now, if blob was created with wrong length. Check for that coming next commit.
-
- 18 12月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 13 12月, 2014 8 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 11 12月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
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%)
-
- 21 11月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 30 10月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Otherwise, we might process a lookup thousands of times, with no benefit. This pathological case was hit by Noto Nastaliq Urdu Draft in Firefox's code to determine whether space glyph is involved in any GSUB/GPOS rules. A test page is at http://behdad.org/urdu See: https://bugzilla.mozilla.org/show_bug.cgi?id=1090869
-
- 15 10月, 2014 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
-
-
- 03 10月, 2014 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 02 10月, 2014 8 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-