So '--features=-trak' or 'font-feature-settings: 'trak' 0;' can prevent
applying of tracking if used.

https://github.com/harfbuzz/harfbuzz/pull/1273

Fixes https://github.com/harfbuzz/harfbuzz/issues/544

Test added with NotoSansCJK, eg. with U+FF38.

Unhooked.

Cherry-picked from cff-subset branch.

Test with Apple Color Emoji.ttf of ~66MB and following sequence:

./hb-shape Apple\ Color\ Emoji-old.ttf --font-funcs=ot -u U+1F468,200d,U+1F469,200d,U+1F467,200d,1f466

Should form full family if matching works correctly.  It first makes
family of three, then makes family of four out of that and the last
two characters.

Fixes https://github.com/harfbuzz/harfbuzz/issues/1292

  #define Null(Type) Null<typename hb_remove_const<typename hb_remove_reference<Type>::value>::value>()

raises:
  hb-blob.cc: In function 'hb_blob_t* hb_blob_get_empty()':
  hb-blob.cc:194: error: using 'typename' outside of template
  hb-blob.cc:194: error: using 'typename' outside of template

Removing "typename"s fixes the issue but makes newer compiler fail apparently.

Probably downstream can patch that locally till we get a solution.

Related https://github.com/harfbuzz/harfbuzz/issues/1301

Simplifies transient object creation.

Fixes https://github.com/harfbuzz/harfbuzz/issues/1301

Doesn't matter, but matches the description.

Fixes https://github.com/harfbuzz/harfbuzz/issues/1299

Removes anomaly I was seeing in cpal table trying to use implicit Null(NameID).

Normally I would have added to_string / from_string like other types
have.  But since we don't use hb_color_t much, I'm not going to do that.
Although, if we did, we could use it in hb-view to parse colors...

Now to hb_color_t.

Will come in through <T> if desired.

Doesn't work though, ouch :(.  Need to figure out if it's unreasonable
to expect Null(T) inside hb_array_t<T> to see the later specialization
of Null for NameID.

We cannot use a nullable offset here though.

COLR table has one function: return layers for a glyph, and we expose exactly
that, so should just wire it through.  Also use sub_array() for verifiable
safety.

Also, BaseGlyphRecord's null object is enough.  We don't need to special-case
the not-found.

We never return parallel arrays from functions.  That's inconvenient
and hard to bind.

Implement has_data() for realz.

We don't expose "gid" in API.

Not sure if MSVC would be unhappy about this.

Sanitize always comes just before data member definitions, so
it's easy to cross-check.

When a struct is plain old data with no references, etc, it's okay
to mark its members public.