[GDEF] >64k expansion

[behdad]

Of the GDEF fields:

• GlyphClassDef is addressed by [GDEF/GSUB/GPOS] Coverage / ClassDef tables >64k expansion #30.
• AttachmentList should be marked deprecated.
• LigatureCaretList allows specifying ligature carets for up to 64k glyphs, which are specified using a coverage table, which by way of [GDEF/GSUB/GPOS] Coverage / ClassDef tables >64k expansion #30 allows glyph indices >64k; so this might be okay as long as fonts are limited to 64k ligature glyphs needing ligature carets.
• MarkAttachmentClass is also addressed by [GDEF/GSUB/GPOS] Coverage / ClassDef tables >64k expansion #30.
• MarkGlyphSets allows specifying up to 64k different sets, specified as coverage objects, which by way of [GDEF/GSUB/GPOS] Coverage / ClassDef tables >64k expansion #30 allow glyph indices >64k, and these are referenced via 32bit offsets so that's great. So as long as the entire font does not need more than 64k distinct sets we are good.
• ItemVariationStore is extended separately as needed; it does not store glyph indices anyway; and the offset to it is 32bit (good).

That is to say, there is no pressing work to be done here. Definitely nothing for first milestone.

The biggest pressure here is the 16bit offsets; the combined size of the various structures make it hard to fit them all within those offsets.

Fortunately, MarkAttachmentClass's use can be reduced by the compiler in favor of MarkGlyphSets. And MarkGlyphSets and ItemVariationStore already use 32bit offsets, so they can escape far away enough. LigatureCaretList uses one layer of offset16's. So as long as GlyphClassDef for the whole font can be built in about just under 64k, the table is buildable. That probably will become the most pressing point on how to order the glyph-order. But, again, workable for even a whole-unicode font.

As such, no work to be done here for now. Yay!

[behdad]

Humm. Leaving open without first milestone to eventually address the limits.

[behdad]

Fortunately, MarkAttachmentClass's use can be reduced by the compiler in favor of MarkGlyphSets.

This is not entirely true, because MarkGlyphSets, just encoding the offset32's, takes considerable space. However, MarkGlyphSets is versioned. So we can add a Extension / trampoline version... Or... I'll just modify the Glyph Filtering proposal #25 to remove reliance on MarkGlyphSets for generalized glyph filtering and add a new GlyphSets entry that is referenced using an offset32. Then we can gradually move towards using glyph-filtering to reduce pressure on mark-filtering data structures.

[behdad]

Eventually we should add a version 2.0 table with Offset24's, like GSUB/GPOS: #58

But this is not pressing.

[behdad]

struct GDEFVersion2 {
  Version version; // 0x00020000
  Offset24To<ClassDef> glyphClassDef;
  Offset24To<AttachList> attachList;
  Offset24To<LigCaretList> ligCaretList;
  Offset24To<ClassDef> markAttachClassDef;
  Offset24To<MarkGlyphSets> markGlyphSets;
  Offset32To<ItemVariationStore> varStore;
};

Note that the varStore offset is 32bit, for compatibility with 0x00010003 version.

[behdad]

Speced: https://github.com/harfbuzz/boring-expansion-spec/blob/main/beyond-64k.md
Implemented in HarfBuzz.