Offsets from LigatureArray must be relative to the beginning of the LigatureArray table. For the serialization mechanism to use the correct beginning point the LigatureArray must be created using the push()/pop() mechanism. So convert LigatureArray subsetting to use serialize_subset() instead of a manually called serialize and subset.
This matches fontTools behaviour. glyphset_gsub does not contain gids added from closing over composite glyphs in glyf, since these cannot particpate in GSUB/GPOS processing.
Added a variant of subset_offset_array which takes an extra arg passed to serialize_subset for this impl.
Added a new api test "test-subset-gpos" for this.
./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.
Garret Rieger
Qunxin Liu
Behdad Esfahbod
Ebrahim Byagowi
ariza
Ali Javadi
Bruce Mitchener