./hb-ot-layout-gpos-table.hh:674:43: error: loop variable '_' is always a copy because the range of type 'hb_zip_iter_t<hb_iter_type<hb_array_t<const OT::IntType<unsigned short, 2> > &>, hb_iter_type<hb_array_t<const OT::IntType<unsigned short, 2> > &> >' (aka 'hb_zip_iter_t<hb_array_t<const OT::IntType<unsigned short, 2> >, hb_array_t<const OT::IntType<unsigned short, 2> > >') does not return a reference [-Werror,-Wrange-loop-analysis]
for (const hb_pair_t<Value, Value>& _ : hb_zip (val_iter, first_val_iter))
^
./hb-ot-layout-gpos-table.hh:674:12: note: use non-reference type 'hb_pair_t<OT::Value, OT::Value>' (aka 'hb_pair_t<IntType<unsigned short, 2>, IntType<unsigned short, 2> >')
for (const hb_pair_t<Value, Value>& _ : hb_zip (val_iter, first_val_iter))
and
In file included from hb-subset.cc:44:
./hb-ot-vorg-table.hh:87:34: error: loop variable '_' is always a copy because the range of type 'hb_map_iter_t<hb_filter_iter_t<hb_sorted_array_t<const OT::VertOriginMetric>, const hb_set_t *, OT::HBGlyphID OT::VertOriginMetric::*, nullptr>, (lambda at ./hb-ot-vorg-table.hh💯15), hb_function_sortedness_t::NOT_SORTED, nullptr>' does not return a reference [-Werror,-Wrange-loop-analysis]
for (const VertOriginMetric& _ : it)
^
./hb-ot-vorg-table.hh:113:17: note: in instantiation of function template specialization 'OT::VORG::serialize<hb_map_iter_t<hb_filter_iter_t<hb_sorted_array_t<const OT::VertOriginMetric>, const hb_set_t *, OT::HBGlyphID OT::VertOriginMetric::*, nullptr>, (lambda at ./hb-ot-vorg-table.hh💯15), hb_function_sortedness_t::NOT_SORTED, nullptr>, nullptr>' requested here
vorg_prime->serialize (c->serializer, it, defaultVertOriginY);
^
./hb-ot-vorg-table.hh:87:10: note: use non-reference type 'OT::VertOriginMetric'
for (const VertOriginMetric& _ : it)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
Happens when compiled with -std=c++2a, the fix just makes the captures explicit to resolve the issue. Just adding this in addition to = doesn't work in C++11.
src/hb-ot-layout-gpos-table.hh:737:18: warning: implicit capture of 'this' with a capture default of '=' is deprecated [-Wdeprecated-this-capture]
{ return (this+_).intersects (glyphs, valueFormat); })
^
src/hb-ot-layout-gpos-table.hh:736:16: note: add an explicit capture of 'this' to capture '*this' by reference
| hb_map ([=] (const OffsetTo<PairSet> &_)
^
, this
Looks like static methods that do not get inlined end up exported.
We have a lot more. Need to protect all at some point. Wish there
was an easier way, like the visibility flag we pass that automatically
hides all inline methods.
Was exposed by check-symbols.sh when compiling on OS X 10.14 with:
$ make CPPFLAGS=-Oz CXXFLAGS=-flto=thin LDFLAGS=-lc++
hb-ot-layout-gsubgpos.hh:1707: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
...
Finally: Fixes https://github.com/harfbuzz/harfbuzz/issues/1356
Test case:
$ ./hb-shape GeezaPro.ttc -u U+0628,U+064A,U+064E,U+0651,U+0629
[u0629.final.tehMarbuta=4+713|u064e_u0651.shaddaFatha=1@0,-200+0|u064a.medial.yeh=1+656|u0628.initial.beh=0+656]
The mark positioning (kern table CrossStream kerning) only works if deleted
glyph (as result of ligation) is still in stream and pushed through the
state machine.
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
Not optimized to use sortedness yet. Also start putting in place infra
to faster reject bad data.
A version of Chandas.ttf found on some Chrome bots has 660kb of GPOS,
mostly junk. That is causing 48 million of set->add() calls in
collect_glyphs(), which is insane.
In the upcoming commits, I'll be speeding that up by optimizing
add_sorted_array(), while also reducing work by rejecting out-of-sort
arrays quickly and propagate the rejection.
Part of https://bugs.chromium.org/p/chromium/issues/detail?id=794896
Apparently a base glyph can also become an attached component of a
ligature if the ligature-forming lookup used IgnoreBase. This was
being confused with a non-first component of a MultipleSubst and
hence not matched for mark-attachment. Tweak test to fix.
Fixes https://github.com/behdad/harfbuzz/issues/543
Qunxin Liu
Behdad Esfahbod
Ebrahim Byagowi
Ali Javadi
Bruce Mitchener