- 30 9月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
Alternative woul have been to resurrect F_COMBINE that I removed in 70136a78 But this does it for now. I'm not sure why check-static-inits.sh didn't catch this before. Clang -Weverything bot did: CXX libharfbuzz_la-hb-ot-shape-complex-indic.lo hb-ot-shape-complex-indic.cc:99:1: warning: declaration requires a global constructor [-Wglobal-constructors] indic_features[] = ^ 1 warning generated. CXX libharfbuzz_la-hb-ot-shape-complex-khmer.lo hb-ot-shape-complex-khmer.cc:36:1: warning: declaration requires a global constructor [-Wglobal-constructors] khmer_features[] = ^ 1 warning generated.
-
- 25 9月, 2018 4 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Now I wonder if any bots will be unhappy we calling | in static const initializations... Or would that cost runtime init? Our tests don't detect any..
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 11 9月, 2018 3 次提交
-
-
由 Behdad Esfahbod 提交于
Use rand=255 to mean "randomize". Part of https://github.com/harfbuzz/harfbuzz/pull/803
-
由 David Corbett 提交于
Randomization only happens by default. If the user specifies a value for 'rand', that value is respected.
-
由 David Corbett 提交于
-
- 26 8月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
Sorry for the noise, downstream custom builders. Please adjust.
-
- 03 6月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
Ouch!
-
- 26 5月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 02 5月, 2018 2 次提交
-
-
-
由 Behdad Esfahbod 提交于
For consistency.
-
- 08 2月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 27 1月, 2018 1 次提交
-
-
- 30 10月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 16 10月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 15 10月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 14 7月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
Not used yet.
-
- 03 4月, 2017 1 次提交
-
-
- 17 12月, 2016 2 次提交
-
-
由 Behdad Esfahbod 提交于
Shape-plan caching is not implemented.
-
由 Behdad Esfahbod 提交于
In prep for more changes.
-
- 07 12月, 2015 1 次提交
-
-
- 17 11月, 2015 1 次提交
-
-
由 Chun-wei Fan 提交于
Use the DEFINE_ENUM_FLAG_OPERATORS macro in winnt.h on Visual Studio, which defines the bitwise operators for the enumerations that we want to mark as hb_mark_as_flags_t, which will take care of the situation on newer Visual Studio (>= 2012), where the build breaks with C2057 errors as the underlying types of the enumerations is not clear to the compiler when we do a bitwise op within the declaration of the enumerations themselves. Also disable the C4200 (nonstandard extension used : zero-sized array in struct/union) and C4800 ('type' : forcing value to bool 'true' or 'false' (performance warning)) warnings as the C4200 is the intended scenario and C4800 is harmless but is so far an unavoidable side effect of using DEFINE_ENUM_FLAG_OPERATORS.
-
- 05 11月, 2015 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 23 7月, 2015 1 次提交
-
-
- 12 7月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Simplifies hb_in_range() calls as the type can be inferred. The rest is obsessiveness, I admit.
-
- 29 4月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Before we were just relying on the compiler inlining them and not leaving a trace in our public API. Try to fix. Hopefully not breaking anyone's build.
-
- 23 12月, 2013 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 05 5月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 03 5月, 2013 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 22 4月, 2013 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
The compile() function is starting to become illegible...
-
由 Behdad Esfahbod 提交于
We always push a pause at the end such that each lookup falls in exactly one pause_map_t. Now, only if I can find a better name for that...
-
- 19 3月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
After the Ngapi hackfest work, we were assuming that fonts won't use presentation features to choose specific forms (eg. conjuncts). As such, we were using auto-joiner behavior for such features. It proved to be troublesome as many fonts used presentation forms ('pres') for example to form conjuncts, which need to be disabled when a ZWJ is inserted. Two examples: U+0D2F,U+200D,U+0D4D,U+0D2F with kartika.ttf U+0995,U+09CD,U+200D,U+09B7 with vrinda.ttf What we do now is to never do magic to ZWJ during GSUB's main input match for Indic-style shapers. Note that backtrack/lookahead are still matched liberally, as is GPOS. This seems to be an acceptable compromise. As to the bug that initially started this work, that one needs to be fixed differently: 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 New numbers: BENGALI: 353689 out of 354188 tests passed. 499 failed (0.140886%) DEVANAGARI: 707305 out of 707394 tests passed. 89 failed (0.0125814%) GUJARATI: 366349 out of 366457 tests passed. 108 failed (0.0294714%) GURMUKHI: 60706 out of 60747 tests passed. 41 failed (0.067493%) KANNADA: 951030 out of 951913 tests passed. 883 failed (0.0927606%) KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%) LAO: 53611 out of 53644 tests passed. 33 failed (0.0615167%) MALAYALAM: 1048102 out of 1048334 tests passed. 232 failed (0.0221304%) ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%) SINHALA: 271666 out of 271847 tests passed. 181 failed (0.0665816%) TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%) TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%) TIBETAN: 208469 out of 208469 tests passed. 0 failed (0%)
-
- 28 2月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
The overridden "or" operator was preventing the flag expression from being const, and putting the table in .data instead or .rodata.
-
- 15 2月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
Not for Arabic, but for Indic-like scripts. ZWJ/ZWNJ have special meanings in those scripts, so let font lookups take full control. This undoes the regression caused by automatic-joiners handling introduced two commits ago. We only disable automatic joiner handling for the "basic shaping features" of Indic, Myanmar, and SEAsian shapers. The "presentation forms" and other features are still applied with automatic-joiner handling. This change also changes the test suite failure statistics, such that a few scripts show more "failures". The most affected is Kannada. However, upon inspection, we believe that in most, if not all, of the new failures, we are producing results superior to Uniscribe. Hard to count those! Here's an example of what is fixed by the recent joiner-handling changes: https://bugs.freedesktop.org/show_bug.cgi?id=58714 New numbers, for future reference: BENGALI: 353892 out of 354188 tests passed. 296 failed (0.0835714%) DEVANAGARI: 707336 out of 707394 tests passed. 58 failed (0.00819911%) GUJARATI: 366262 out of 366457 tests passed. 195 failed (0.0532122%) GURMUKHI: 60706 out of 60747 tests passed. 41 failed (0.067493%) KANNADA: 950680 out of 951913 tests passed. 1233 failed (0.129529%) KHMER: 299074 out of 299124 tests passed. 50 failed (0.0167155%) LAO: 53611 out of 53644 tests passed. 33 failed (0.0615167%) MALAYALAM: 1047983 out of 1048334 tests passed. 351 failed (0.0334817%) ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%) SINHALA: 271539 out of 271847 tests passed. 308 failed (0.113299%) TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%) TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%) TIBETAN: 208469 out of 208469 tests passed. 0 failed (0%)
-