- 07 7月, 2018 1 次提交
-
-
由 David Corbett 提交于
Completes #1037 and fixes #1035.
-
- 05 7月, 2018 3 次提交
-
-
由 Behdad Esfahbod 提交于
Disable vectorization for now. To correctly use them, we should use posix_memalign() to allocate them. Otherwise, can cause misaligned access. https://bugs.chromium.org/p/chromium/issues/detail?id=860184
-
由 Behdad Esfahbod 提交于
../../src/hb-ot-layout-gsubgpos-private.hh:391:18: warning: missed loop optimization, the loop counter may overflow [-Wunsafe-loop-optimizations]
-
由 Behdad Esfahbod 提交于
-
- 04 7月, 2018 1 次提交
-
-
由 Ebrahim Byagowi 提交于
-
- 03 7月, 2018 4 次提交
-
-
由 Behdad Esfahbod 提交于
From the new code (first paragraph is from the OT Devanagari spec.): /* o Reorder matras: * * If a pre-base matra character had been reordered before applying basic * features, the glyph can be moved closer to the main consonant based on * whether half-forms had been formed. Actual position for the matra is * defined as “after last standalone halant glyph, after initial matra * position and before the main consonant”. If ZWJ or ZWNJ follow this * halant, position is moved after it. * * IMPLEMENTATION NOTES: * * It looks like the last sentence is wrong. Testing, with Windows 7 Uniscribe * and Devanagari shows that the behavior is best described as: * * "If ZWJ follows this halant, matra is NOT repositioned after this halant. * If ZWNJ follows this halant, position is moved after it." * * Test case, with Adobe Devanagari or Nirmala UI: * * U+091F,U+094D,U+200C,U+092F,U+093F * (Matra moves to the middle, after ZWNJ.) * * U+091F,U+094D,U+200D,U+092F,U+093F * (Matra does NOT move, stays to the left.) Fixes https://github.com/harfbuzz/harfbuzz/issues/1070 Test case added with Adobe Devanagari.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
The get_table imple was wrong, as table offsets in a dfont are relative to the resource. We were treating them as relative to the big blob itself. To be fixed. Part of https://github.com/harfbuzz/harfbuzz/pull/1085
-
- 01 7月, 2018 3 次提交
-
-
由 Ebrahim Byagowi 提交于
In collaboration with Behdad
-
由 Ebrahim Byagowi 提交于
-
由 Ebrahim Byagowi 提交于
-
- 30 6月, 2018 4 次提交
-
-
由 Behdad Esfahbod 提交于
From the issue: "In this font, the virama,ya first forms a ligature, then decomposes back to virama,ya. This causes those two to be marked parts of a MultipleSubst sequence. When attaching the matra, we look for the first of the MultipleSubst sequence because that's where we attach to (because of eg #740). In this case, the first glyph in the MultipleSubst sequence is a mark, so we skip it and attach to the base char before it." Font in question is Nirmala UI from Windows 10. Test sequence: U+0926,U+094D,U+092F,U+0941 Fixes https://github.com/harfbuzz/harfbuzz/issues/1020
-
-
由 punchcutter 提交于
-
由 Behdad Esfahbod 提交于
Indic shaper already had this check. We removed it when forking Khmer shaper by mistake. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1464623
-
- 28 6月, 2018 2 次提交
-
-
由 Ebrahim Byagowi 提交于
Fixes #1081
-
由 Ebrahim Byagowi 提交于
Oops
-
- 27 6月, 2018 4 次提交
-
-
由 Ebrahim Byagowi 提交于
-
由 Ebrahim Byagowi 提交于
-
由 Ebrahim Byagowi 提交于
* Handle EINTR on fallback reader * Increase fallback reader limitation size limitation to 2 << 28 * Ensure _O_BINARY does exist if MMAP is used on Windows (maybe superfluous but makes me more confident)
-
由 Behdad Esfahbod 提交于
Makes compiling without HAVE_ROUND on systems that do have it work.
-
- 26 6月, 2018 3 次提交
-
-
由 Ebrahim Byagowi 提交于
Add one more "unlikely" annotation and use explicit nullptr check for more consistency.
-
由 Garret Rieger 提交于
-
由 Ebrahim Byagowi 提交于
And assign one bot to use the path always using NOMMAPFILEREADER token. It's limited to 200mb so no more fun with using /dev/zero on hb-view!
-
- 25 6月, 2018 2 次提交
-
-
由 Ebrahim Byagowi 提交于
-
由 Ebrahim Byagowi 提交于
-
- 23 6月, 2018 1 次提交
-
-
由 Behdad Esfahbod 提交于
In particular, if CoverageFormat2 has unsorted ranges, bail out. Otherwise, 64k ranges of each 64k glyphs can DoS closure() method. We can do the same for CoverageFormat1, but that one does not expose the quadratic behavior, so, fine.
-
- 19 6月, 2018 1 次提交
-
-
由 Ebrahim Byagowi 提交于
With this hb-view/hb-shape support pipes and possibly socket and named pipe also, anything fails just on mmap. We can later do the same for Windows also. This however reveals two issues, the fact most of our bots don't have HAVE_MMAP and using this instead the other fread/fopen reader can make failure on CI. I should look at them separately this change however is very low risk I believe.
-
- 18 6月, 2018 1 次提交
-
-
由 Ebrahim Byagowi 提交于
As https://github.com/harfbuzz/harfbuzz/pull/1059#issuecomment-397912812 we like to still work with blobs that harfbuzz itself can't handle directly that are failing sanitization currently apparently.
-
- 17 6月, 2018 2 次提交
-
-
由 Ebrahim Byagowi 提交于
This checks if the blob isn't empty and uses `hb_face_count` to see if the font file passes the simple font file sanitization so can detect if the input is actually a font and checks also whether input font-index is out of range.
-
由 Ebrahim Byagowi 提交于
We were passing the font path directly to freetype so rendering was broken when we are getting the font from stdin. This fixes it by using FT_New_Memory_Face instead. This fixes: * build/util/hb-view /dev/stdin text < font.ttf * build/util/hb-view - text < font.ttf * cat font.ttf | build/util/hb-view - text but doesn't work on * cat font.ttf | build/util/hb-view /dev/stdin text which I will try to fix separately.
-
- 13 6月, 2018 4 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Fixes https://github.com/harfbuzz/harfbuzz/issues/864 Unfortunately 1.7.7 and 1.8.0 went out with the wrong hb-version.h contents.
-
由 Behdad Esfahbod 提交于
Just include hb-static.cc in libharfbuzz-subset.so source list as well. Those building it built-in will include hb-static.cc once already. No need for any gymnastics.
-
- 12 6月, 2018 4 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-