Port fonttools optimized PairPos subtable splitting?

[anthrotype]

@belluzj wrote in #610 (comment)

you may benefit from translating to Rust the GPOS compaction from here: fonttools/fonttools#2326. It's not super slow even though it's Python, so it might be fast enough in Rust, and it doesn't need to know about the glyph's Unicode properties (so no need for GSUB closure) in order to decide how to split the subtables, it does so only by looking at the filled-in/empty areas of the matrices. Let me know if you have any questions.

The code is here:
https://github.com/fonttools/fonttools/blob/main/Lib/fontTools/otlLib/optimize/gpos.py

It can be enabled by setting a config option on a TTFont before compiling, takes numbers from 0 (disabled by default) to 9:
https://github.com/fonttools/fonttools/blob/2b115eaae83dddb2638b079c7e88bda2e94cd6f9/Lib/fontTools/config/__init__.py#L25-L37

font = TTFont(...)
font.cfg["fontTools.otlLib.optimize.gpos:COMPRESSION_LEVEL"] = 9
font.save(...)

It's also possible to run as CLI on existing font file with fonttools otlLib.optimize --help

[rsheeter]

Does fontmake set this to on by default? If not, why not and do specific families actually enable it?

[anthrotype]

no it does not set it on by default, for it makes the build slower in exchange for smaller file size and not all fonts may enjoy substantial savings, it's mostly for multi-script projects. It made more sense before ufo2ft switched to one kern lookup per script, when it was doing one lookup per horizontal direction, as the latter is sparser than then former (for one can't kern across script boundaries). The work also predates the move to one-lookup-per-script.
Jany is proposing this as an alternative solution for fontc to doing the ufo2ft-style per-script GSUB closure, since it's agnostic of unicode glyph properties, just looks at how sparse/dense pairpos matrices are

[anthrotype]

actually, we would still need to do the GSUB closure regardless, because of the need to separate the LTR from the RTL kerning pairs (each requires a different kind of value record).
So maybe it's not worth implementing this. IIRC, there weren't much file size gains from doing both the split-by-script kerning and the optimized GPOS compaction as most of the sparseness came from non-interacting cross-script areas of the pairpos matrices.
/cc @belluzj @madig

[rsheeter]

Based on ^ I will close. Please reopen if there is reason to believe that there are file size benefits remaining even after doing split-by-script.

[belluzj]

Yes indeed, if you split by script then then the GPOS compaction is a very minor improvement. (thanks Cosimo for pointing out RTL vs LTR, I didn't realise that)