[write-fonts/gvar] add axis_count param to Gvar::new

[anthrotype]

this ensures that we (e.g. fontc) can make valid empty gvar tables where the axis_count matches the expected (fvar's) axis_count as per OT spec.

Will eventually fix googlefonts/fontc#815 once fontc is updated to use the new API.

This is a breaking changes which warrants minor write-fonts version bump.

[cmyr]

Okay so to understand the situation here: sometimes we would like to have an empty gvar table, but set an explicit axis_count?

If yes: is it true that there are basically two ways we expect the new API to be called:

• previously, where the axis_count could be inferred from the input
• the empty case, where there are no variations but we want a non-zero axis count?

If yes, my one nit with this PR is that it introduces a new error and possible error condition that we might be able to avoid. For instance, we could have a separate constructor Gvar::empty(axis_count: u16) that would handle this case, and since there would be no provided variations we wouldn't need to worry about a possible error?

That does push the responsibility down to the caller, to ensure that they call a different constructor to get an empty table, so there is that downside.

What do you think?

[anthrotype]

sometimes we would like to have an empty gvar table, but set an explicit axis_count?

yes, because some old apps expect gvar to always be present in a VF even if empty, and the spec wants gvar's axis_count == fvar.axis_count no matter what (e.g. fonttools fails to decompile an empty gvar with axis_count of 0 where fvar.axis_count != 0)

previously, where the axis_count could be inferred from the input...

technically it would still be possible for the caller to construct a gvar table where all the provided variations have the same, consistent axis_count, but the latter turns out not to match the global fvar's axis_count, but you could argue that's not write-font's fault.

But I'm not opposed to the proposed additional Gvar::empty(axis_count) constructor either. I think we are splitting hairs for an arguably-very-limited use case so whatever makes you guys happy. /cc @rsheeter

[cmyr]

My preference is just for simpler code and fewer error conditions, but agree it's not a big deal.

[cmyr]

minor preference for the alternative version I think but merge this if you prefer!

[anthrotype]

I think I can wait until tomorrow to let @rsheeter chime in. Feel free to cut a release without this or wait