[fonttools/fonttools] 6df4fd: [varLib] Support beyond-64k extended formats in OT...

[Cosimo Lupo]

Branch: refs/heads/varlib-merger-beyond64k
Home: https://github.com/fonttools/fonttools
Commit: 6df4fd8704f61db9c7a6c79af7cb10bb8c51dd86
https://github.com/fonttools/fonttools/commit/6df4fd8704f61db9c7a6c79af7cb10bb8c51dd86
Author: Cosimo Lupo <cos...@anthrotype.com>
Date: 2026-06-16 (Tue, 16 Jun 2026)

Changed paths:
M Lib/fontTools/varLib/__init__.py
M Lib/fontTools/varLib/merger.py

Log Message:
-----------
[varLib] Support beyond-64k extended formats in OTL merger

The OTL mergers dispatch on the format 1/2 GPOS subtable layouts, so
merging masters whose GPOS uses the beyond-64k extended layouts (PairPos/
SinglePos format 3/4, mark/cursive format 2) raised UnsupportedFormat. feaLib
promotes a master's layout to these by glyph count, so every master of a font
with more than 65535 glyphs is already extended.

Demote the extended GPOS subtables to format 1/2 before merging and promote
the merged output back afterwards, reusing the converter in ttLib.beyond64k;
only the records that embed glyph ids/counts/offsets are reclassed (Coverage and
ClassDef pick their wire format at compile time). This lives in the shared Lookup
merger, so it covers both varLib.build and the instancer's per-master OTL merge.
Contextual positioning, mark-to-ligature and GSUB go through the generic object
walker and are left as-is.

Also let _merge_OTL attach the VarStore to a beyond-64k v1.4 GDEF without
asserting v1.2 or dropping its extended fields.


Commit: 44bd373b610953a991674970936f4446745218c5
https://github.com/fonttools/fonttools/commit/44bd373b610953a991674970936f4446745218c5
Author: Cosimo Lupo <cos...@anthrotype.com>
Date: 2026-06-16 (Tue, 16 Jun 2026)

Changed paths:
M Tests/varLib/varLib_test.py

Log Message:
-----------
[varLib] Test beyond-64k GPOS/GDEF merging

Build a beyond-64k VF through the per-master OTL fallback path: one test
round-trips the whole font and checks all five GPOS lookup types come out in the
extended formats with the high glyph id intact and the GDEF VarStore at v1.4; the
other checks PairPos coverage alignment and backfill across disjoint masters.
Interpolated values are resolved against the VarStore.


Compare: https://github.com/fonttools/fonttools/compare/6df4fd8704f6%5E...44bd373b6109

To unsubscribe from these emails, change your notification settings at https://github.com/fonttools/fonttools/settings/notifications

[Cosimo Lupo]

Commit: dd4e9bc80bcb8f80d961d73b8accb8f74c4da2ae
https://github.com/fonttools/fonttools/commit/dd4e9bc80bcb8f80d961d73b8accb8f74c4da2ae

Author: Cosimo Lupo <cos...@anthrotype.com>
Date: 2026-06-16 (Tue, 16 Jun 2026)

Changed paths:

M Lib/fontTools/varLib/merger.py

M Tests/varLib/varLib_test.py

Log Message:
-----------

[varLib.merger] Merge beyond-64k v1.4 GDEF GlyphClassDef2 leniently

The lenient GDEF merger that unions per-master glyph class assignments was
keyed on the GlyphClassDef attribute only, so a beyond-64k v1.4 GDEF stores
its class def in GlyphClassDef2 and fell through to the strict generic merge,
raising ShouldBeConstant whenever masters diverged (even on non-conflicting
glyphs). Register the merger for both names so v1.4 fonts get the same union
semantics v1.2 always had.


Compare: https://github.com/fonttools/fonttools/compare/6df4fd8704f6%5E...dd4e9bc80bcb