Question about weight range in the variable fonts

[jpamental]

First off: I'm really excited to see there is a variable font version in the works. I write and speak about them often and would love to share the news. Thanks for doing this!

I'm wondering if there is a reason for the weight range in the variable font version being 40-200 instead of something like 100-900.

The reason I ask is that in normal usage on the web, the CSS designation of 'normal' is an alias for 400, and 'bold' aliases 700. So if you want to be able to use the font without having to declare the weight every time, it would be helpful to adjust the weight range. Otherwise you'll have to always set font-weight: 92 for the regular weight or 150 for bold. Without doing that, the browser will clamp to the closest value to the alias (in this case 200), so the text will always appear in the heaviest weight.

Additionally, some browsers will attempt to synthesize a bold on top of that, making it even heavier unless you also declare font-synthesis: none

I put together a CodePen to show what I'm trying to explain. Also, please feel free to let me know if this is already known territory. I'm excited to include Public Sans in my talks on variable fonts, so when @maya gave me the link I wanted to jump right in—but also don't want to assume I have all the information on which to base my input!

https://codepen.io/jpamental/pen/qwYLqV

[davelab6]

My guess is that it's 40-200 because it's Glyphsapp you typically set the axis values to upm units corresponding with a key stem width, and the axis compilation isn't translating the source values into values compliant with the OpenType spec standards.

GitHub.com/googlefonts/fontbakery has a check for this as it was seen in fonts I commissioned.

[davelab6]

Which is to say, I think this is an urgent bug that should be fixed before VF files become widely available :)

[thisisdano]

Yeah — the variable fonts are completely untested at this point and should be considered not production worthy. I'm pretty sure @davelab6 is right about the source of the issue as that is exactly how the source files are set up. Is there a better tool for VF conversion than the output directly from Glyphs? I'll be working to automate my binary output and am very keen to try new solutions.

[eliheuer]

Building with fontmake fixes this issue.

I have a variable font build script that is part of Google Fonts Tools, it builds with fontmake and automates as much of the build process as possible.

[jpamental]

Well I'm happy to report @thisisdano that in all other ways, the variable font versions seem to work really well, and when I used woff2_compress to generate woff2 files, the file size is cut in half! It would be wondrful to see if @eliheuer 's solution could be made part of the workflow; it would make a huge difference in the usefulness of the fonts themselves.

I've been involved with the new web platform for Georgia, which is utilizing both static and variable versions of Source Serif and that just started to go live this week. It's working really well, leveraging @supports to deliver the variable font typography only for browsers that can display them. (and where it does, it cuts the font download by a significant margin)

[eliheuer]

There are also other options for build scripts, Inter has an interesting build system, but I think something like this would be too complicated for Public Sans: https://github.com/rsms/inter/blob/master/CONTRIBUTING.md#compiling-font-files

I talked to @thundernixon today and he suggested using a starter build script template he developed: https://github.com/thundernixon/googlefonts-qa-template/blob/master/sources/build.sh

It looks like starting with this might be the simplest and best way to go.

[thisisdano]

Thanks for your help @eliheuer — I'll be starting on the build script work today.