[maximum_color] Ignore variation data when converting COLRv1=>SVG

[anthrotype]

Fixes https://github.com/googlefonts/nanoemoji/issues/426

[m4rc1e]

Thanks Cosimo! it looks good on Safari

Foldit using this pr

Foldit currently in google/fonts

[m4rc1e]

LGTM but I'm not a maintainer. I like the mapping approach you've used.

[anthrotype]

Hm the spacing looks suspiciously bad in that screenshot.. maybe safari is applying the metrics of the regular but the SVG has the outlines of the thin?

[m4rc1e]

I'm just checking to see if the testing site itself is to blame.

[anthrotype]

It's not the site, it's the font that advertises itself as variable (has fvar, HVAR, etc.) but then the SVG outlines are not. Honestly I think it doesn't make much sense to have hybrid COLRv1+SVG when the COLR table contains variations, since there can't be a 1:1 translation between the two; besides, leaving variable tables alongside static SVG leads to issues like the one above. Only static COLRv1 font can be meaninfully converted to OT-SVG. Once we have support for instancing COLRv1 in fonttools https://github.com/fonttools/fonttools/issues/2699 one could, say, cut an instance of the Regular or any other instance, and then pass that through maximum_color to obtain the hybrid COLRv1+SVG.

[m4rc1e]

Here's a screenshot in safari using diffenator2

Seems to be getting more compressed as the weight increases.

test.zip

[anthrotype]

yes, that's expected. The font has HVAR, which varies along wght axis. The SVG doesn't move, the rest does..

[anthrotype]

See discussion https://github.com/googlefonts/nanoemoji/issues/426#issuecomment-1228414249, in particular Rod's last reply

I believe (I hope) we currently subset away all the variation data when we serve these fonts to browsers that only understand OT-SVG but not COLR

We do not. The default request for a family is for a static instance, but if you ask for variation to be included we'll merrily do it.

[anthrotype]

basically, the only way to currently make an OT-SVG font for Foldit-VF is to 1) run maximum_color on it 2) drop the variable COLR table altogether 3) strip it of the variation data (instantiate it at the default location)

this will give you the Foldit-Thin.ttf (and only that one) with an SVG instead of a COLR table.

[m4rc1e]

Seems better to just leave the font as is. At least that way Safari users will get a font without any color which imo is better than just the thin weight. If we leave as is, maximum_color could raise a warning for this issue.

[anthrotype]

maybe we need a separate tool (colr_instancer?) that takes a variable COLRv1 and spits out static OT-SVG fonts (for all named instances or specific selection). But that would first require implementing CORLv1 instancing in fontTools https://github.com/fonttools/fonttools/issues/2699

[vv-monsalve]

Seems better to just leave the font as is. At least that way Safari users will get a font without any color which imo is better than just the thin weight. If we leave as is, maximum_color could raise a warning for this issue.

From the above tests, I'd support this idea. Otherwise, it would break the whole idea of the font: serving a font that goes from thin-ultracondensed to black-extraexpanded with gradients that seems consistent through the entire range