Fixes#2361. Stores tables in the builder in a hashmap so you end up with at most one copy of each table. Table serialization order is now based on tag sort order instead of order of insertion into the builder.
There's no easy way to undo a "using namespace" in our sources, so by the time
we get to include hb-coretext.cc from harfbuzz.cc, we already have "using namespace OT"
active, which clashes with Mac headers.
Error was:
$ gcc -O3 -Wall -arch i386 -DHAVE_CORETEXT=1 -c harfbuzz.cc -o harfbuzz.o -std=c++11
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/TextUtils.h:288:3: error:
reference to 'OffsetTable' is ambiguous
OffsetTable offsets,
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/IntlResources.h:115:41: note:
candidate found by name lookup is 'OffsetTable'
typedef OffPair OffsetTable[3];
^
./hb-open-file.hh:81:16: note: candidate found by name lookup is 'OT::OffsetTable'
typedef struct OffsetTable
^
1 error generated.
Delete assignment operator of OffsetTo<> instead of Offset<>.
In simple ArrayOf<>::sanitize() assert that Type has assignment operator.
Ideally we should SFINAE this and fallback to calling Type::sanitize()
if assignment operator is not available. But we don't have a case of
that in the codebase.
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++
Previously, ResourceForkHeader was defined as 30 bytes, having the typeCountM1 as last member.
There was a mysterious offset-by-2 in the code, derived from FontTools and JDK code this was
ported from.
In testing, I observed that typeListZ offset is actually 28. Suggesting that the typeCountM1
does NOT actually belong to ResourceForkHeader, but belongs to the array itself. Adjusting for
that resolves the mystery +2 offset hack, so everything is clean and good now.
This, concludes my dfont hacking. The code looks great now, and I'm happy to leave it.
Fuzzers might disagree though, we will see!
Behdad Esfahbod
Garret Rieger
Ebrahim Byagowi
Bruce Mitchener