lwsync() is a full read/write-barrier. That's all we need, never
need sync(). I'm not sure why an isync() was used in fetch_and_add,
but since that's a read-modify-write, I just changed it to have
lwsync() on both sides.
Originally, glib's atomic_get was implemented as "memory_barrier; load".
I copied this into cairo, fontconfig, and harfbuzz. However, that's
wrong. Correct way is "load; memory_barrier". The details are long
and hard to fully grasp. Best to read:
https://www.kernel.org/doc/Documentation/memory-barriers.txt
Also see my report against GNOME:
https://gitlab.gnome.org/GNOME/glib/issues/1449
Note that this is irrelevant if C++11-like atomic ops are available.
This reverts commit b1e5650c67.
After lots of head-scratching and finally finding the only truly
readable source to be the good old:
https://www.kernel.org/doc/Documentation/memory-barriers.txt
I've convinced myself that we need consume memory-ordering on get().
The location of memory-barrier in a load should be after, not before
the load. That needs fixing. I'll do that separately.
Oriya went down from 9 to 2.
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707311 out of 707394 tests passed. 83 failed (0.0117332%)
GUJARATI: 366355 out of 366457 tests passed. 102 failed (0.0278341%)
GURMUKHI: 60729 out of 60747 tests passed. 18 failed (0.0296311%)
KANNADA: 951300 out of 951913 tests passed. 613 failed (0.0643966%)
MALAYALAM: 1048136 out of 1048334 tests passed. 198 failed (0.0188871%)
MYANMAR: 1115830 out of 1123883 tests passed. 8053 failed (0.716534%)
ORIYA: 42327 out of 42329 tests passed. 2 failed (0.00472489%)
SINHALA: 271596 out of 271847 tests passed. 251 failed (0.0923313%)
TAMIL: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
This makes test suite happy again (at 44) while fixing the sequences
we were fixing, which were the following with KhmerUI.ttf:
U+1789,U+17BC
U+1789,U+17D2,U+1789
U+1789,U+17D2,U+1789,U+17BC
Fixes rest of https://github.com/harfbuzz/harfbuzz/issues/974
Khmer spec has only one reordering phase, and only simple prebase
matra and Coeng-Ro reordering. Implement that. Specifically,
this was done to address recognizing different orders of the matra
and Coeng-Ro sequence. That said, some combinations are now
reordered differently from Uniscribe. Not clear if that's intended
or a bug in Uniscribe. The following two sequences render the same
in Uniscribe whereas we reorder them differently:
U+17A0,U+17D2,U+179A,U+17C2
U+17A0,U+17C2,U+17D2,U+179A
For that reason, our test suite numbers regressed slightly. Used
to be at 34 for fails, now at:
KHMER: 299080 out of 299124 tests passed. 44 failed (0.0147096%)
But generally a good change, and removed lots of code.
Fixes https://github.com/harfbuzz/harfbuzz/issues/1026
This new API returns cvXX and ssXX related NameId, things like
featUiLabelNameId, featUiTooltipTextNameId, sampleTextNameId, ... of cvXX
and UINameId of ssXX, in a unified way.
However HarfBuzz currently doesn't expose an API for retrieving the actual
information associated with NameId from the `name` table and that should be
done separately.
When one is not using the msys2 python, the header files that are passed in as environment
variable cannot be found.
https://ci.appveyor.com/project/fonttools/ttfautohint-py/build/1.0.65/job/rkremny4jjid9nl2#L803
This is because msys2 shell and make use POSIX paths (e.g. /c/Users/clupo/...)
whereas non-msys2 python.exe uses native Windows paths (e.g. C:\Users\clupo\...).
Msys2 will automatically convert command line arguments (but not environment variables) from
POSIX to Windows paths when calling a native win32 executable, so we pass the header paths
as arguments instead of environment variables.
This way the gen-def.py script can support both mingw python running in an MSYS2 shell, and
native win32 python.
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.
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
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
* 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)
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.
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.
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.
Behdad Esfahbod
Ebrahim Byagowi
Garret Rieger
prrace
David Corbett
Cosimo Lupo
punchcutter