Variable Fonts support: GVAR and CVAR table parsing

[Connum]

Description

This PR adds parsing capability for the gvar and cvar tables, as these share a common format and adding cvar was practically free. It does not implement any actual variation/transformation functionality, but with this the groundwork for variable font support should be finished. Similar to glyph paths, delta values are not directly added to the table during parsing, for performance and memory saving reasons. They are only parsed when accessed.

TODOs for future PRs:

• maybe add even more thorough tests, especially for edge cases like those from the Unicode test suite
• add writing capability
• add actual variation functionality (implementing this before writing support will make testing way easier)
• add HVAR parsing and writing support
• add higher level methods for working more comfortably with variation data (like color glyph layers and palettes)

Motivation and Context

With this table data parsed, we finally "only" need to add the actual glyph transformation process.

How Has This Been Tested?

Loaded all the GVAR/CVAR test fonts from the Unicode test suite (even the ones we can't ship due to unclear licenses) and randomly cross-checked the parsed results with other parsing implementations. Added several tests.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I did npm run test and all tests passed green (including code styling checks).
• I have added tests to cover my changes.
• My change requires a change to the documentation.
• I have updated the README accordingly.
• I have read the CONTRIBUTING document.

[yne]

I like the idea of lazy-parsing to save memory/CPU
but for constency reason, do you think we migrate some other parsing API to this method ?

[yne]

excellent.
always happy to see more table support !

[Connum]

Sure, everything that doesn't need to be there directly after loading could be parsed at runtime, especially if it's as much data as there is in the gvar table. I didn't do it for the COLR/CPAL implementation, because there isn't that much data involved. We could definitely move towards more runtime parsing in the future, but I think what's more important is adding caching mechanisms for the path calculations with added complexity due to added features like SVG and cpal/colr emojis support. I already have something in mind that I will explore when tackling the font variation rendering.