bevyengine
Replace Fira font with variable version
Replaces Fira font with a variable version. With two files (regular & italic) we get the whole range of weights 100-900. I was expecting that this would also reduce the file size weight but it's slightly bigger. The big advantage of switching is that increases the range of weights available, which I would like to use to improve the typography of the content pages (docs, news…).
Font taken from: https://github.com/hellogreg/firava (OFL license)
Differences:
- File size:
- Variable (regular+italic): 128kb
- Non-variable: 108kb
- Kerning is different, but I don't know which one is better
- The weight is not the same at any given point (e.g. 700). Also, in some cases there might differences because we were using unsupported weights (e.g. 800 when we only had a 700 font).
Looks like we drop from 1700 characters to 450 characters. Are we sure the added flexibility is worth it, especially in light of the increased size?
After challenging a little bit the idea… I would say that the main reason for not doing this is that if the webpage is translated to Chinese and there isn't a variable font for Chinese, then there might some visual differences (e.g. we used a variable weight of 250 for the English text but the Chinese font only support 200 or 300). It's probably easier to keep cross-language visual consistency if font-weights are limited.
I don't think that the file size (Firava can be subsetted to reduce file size) or not supporting other alphabets are issues, see below.
If we compare Firava (variable version) with the Fira-latin subset we're using in main then Firava actually comes with more characters. Although the extra languages that Firava supports still use latin alphabets. The size difference probably comes from this, if we generate a smaller subset of Firava to support the same languages as in main I expect that the file size will be lower than main.
main:
Firava:
If we need to support languages using other alphabets (e.g. Chinese), instead of adding more characters to the font files we're already loading, we could split the CSS by language. So we load the specific font files and CSS rules for that language. This allows to cohexist latin/non-latin, variable/non-variable… without bloating the user with stuff that they don't need.
<link rel="stylesheet" href="/site.css" />
<link rel="stylesheet" href="/fonts-{{language}}.css" />
Ah right I forgot we switched to the subset. In light of that this seem like an acceptable move (provided we're happy with how the font behaves in practice). Can you capture some images to compare (with a common anchor position so flipping between them is easy / useful). I'd also like this to include a pass over font weights in code to ensure we "snap" any existing weights to their previous "fixed" weights. Seems like there could be cases where a weight of 600 was specified, which got rounded down to 500. Switching to a variable weight would mean we are slightly bumping up the weight without intention.