Thanks Cosimo! it looks good on Safari

Foldit using this pr

Foldit currently in google/fonts

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

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?

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

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 fonttools/fonttools#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.

Here's a screenshot in safari using diffenator2

Seems to be getting more compressed as the weight increases.

test.zip

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

See discussion #426 (comment), 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.

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.

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.

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 fonttools/fonttools#2699

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