search

google / fonts

Font files available from Google Fonts, and a public issue tracker for all things Google Fonts
https://fonts.google.com
18.06k stars 2.6k forks source link

Update Barlow to variable font? #3625

Open cssobral2013 opened 3 years ago

monmonja commented 1 year ago

Would like to have an update on this one too, thanks

simoncozens commented 5 months ago

Sorry to keep this open for so long with no response. I've taken a look into this. I think it would be a great thing to do, and it fits with some other things we're trying to do in the catalogue this year. However, it's not terribly straightforward for certain very technical reasons:

1) The font sources don't currently build as a variable font using fontmake. This appears to be for a few different reasons; some of the instances contain axis locations with widths of 85, which is clearly wrong; these should be removed. glyphsLib does not support the way Barlow uses intermediate layers, and that's a glyphsLib bug which I just reported. (I've just noticed that there's a 1.5 branch of Barlow, which is better but still doesn't work.) 2) Even if we fixed the glyphsLib bugs and got that working, Barlow makes heavy use of Glyphs filters in its exports (e.g. rounding the corners, adding slant) which we don't support either.

So this is probably worth doing but probably also pretty hard to achieve in reality.

jpt commented 4 months ago
  1. The font sources don't currently build as a variable font using fontmake. This appears to be for a few different reasons; some of the instances contain axis locations with widths of 85, which is clearly wrong; these should be removed. glyphsLib does not support the way Barlow uses intermediate layers, and that's a glyphsLib bug which I just reported. (I've just noticed that there's a 1.5 branch of Barlow, which is better but still doesn't work.)

RE the glyphsLib issue: the masters that the brace layers align to don't really matter, I can re-align them with this script. I think barlow#98 will address the real issue (at least for Glyphs export, I'm not sure if glyphsLib takes care of this), which is that the designspace doesn't have all the edges filled in.

  1. Even if we fixed the glyphsLib bugs and got that working, Barlow makes heavy use of Glyphs filters in its exports (e.g. rounding the corners, adding slant) which we don't support either.

Glyphs 3.2 supports positive and negative rounding in variable fonts (though some glyphs will become incompatible and need to swap with alternates at certain designspace coordinates); slant is straightforward to add as an axis, though you're right, there's no slant axis yet. I don't know what GF plans are RE: supporting filters in glyphsLib, but if there are any fonts where you allow for a headless build in a Mac environment (Docker-OSX? a cloud mini?), that shouldn't be too bad to implement a remote script for. I'm trying to better understand the state of VF corner rounding in Glyphs. Current versions have a bug that breaks on any brace layer, so it's a pretty new feature. But I think 3.2 could really help with Barlow VF

So this is probably worth doing but probably also pretty hard to achieve in reality.

One unmentioned issue for the slant axis will be the way the condensed->regular transition is drawn. I expect a lot of kinks. I could fix this by changing the way those letters are drawn, so at condensed the letter o has flat sides and at regular width the points making them flat come together. But I guess we'd need to agree that the design compromise of sort-of-flat letters in the Semi Condensed (the least used width per GF analytics) are fine. I for one think they're fine, and they're what virtually every straight-to-round condensed-to-regular variable font does.

The rounded corners thing is tricky. Could be that the sources for VF simply have a destructive step, too. Or that corner components can be leveraged in a clever way.

Anyway, it's a tough problem, but things are in motion, and I have some availability for the first time in a long time to look into it