Experiment with a non-centenary font weight

[gnprice]

Flutter supports specifying what font weight to use for text.

The main API for this, FontWeight, provides the weights 100, 200, etc., up to 900. (For example FontWeight.normal is an alias for weight 400, and FontWeight.bold is 700.)

That's plenty for many purposes, but one sometimes wants finer control with a weight like 450 or 550. In particular @terpimost would like to have the design flexibility to use such weights. Some discussion in chat.

It looks like we should be able to accomplish that using TextStyle.fontVariations. That allows specifying an arbitrary weight, as a number, by using design axis wght.

• In fact one can even use that to drive the weight with an animation, if you want; example here.
• The docs suggest this feature is there for the sake of variable fonts. Probably it works fine even if the font isn’t variable, though, as long as you pick a weight the font does have.

So it would be good to try that out and demonstrate that it does indeed work.

In order to successfully carry out the experiment, we'll need a font that has such a weight in the first place. This probably means we'll need:

• Try bundling fonts #64

and specifically to bundle a variable font, like Source Sans 3 VF as seen in the web PR zulip/zulip#24833.

[gnprice]

Other notes:

• The upstream tracker has a request for this ability (though expressed as a comment on a different issue): Configured font weights do not align with custom font flutter/flutter#50216 (comment)

  If we confirm that the ability is already there (i.e. that using fontVariations like that does the job), then it'd be good to augment the FontWeight docs with a cross-reference to that, and to follow up on that issue thread 50216.

• As an alternative, a workaround is suggested here: FontWeight.w200 actually displays w100 flutter/flutter#89960 (comment)

  Namely, one can define a font family that’s just the desired weight, and use that family where desired.

  That shouldn't be necessary for our purpose, though, if using fontVariations works as expected. (It's not clear what was the cause of the now-fixed issue the workaround was suggested for, so it's hard to say if using fontVariations would have successfully worked around that issue too.)

[chrisbobbe]

[…] specifying an arbitrary weight, as a number, by using design axis wght

[…]

[…] Probably it works fine even if the font isn’t variable, though, as long as you pick a weight the font does have.

Hmm, really? It sounds to me like a non-variable font wouldn't respond to turning a "wght" dial: AIUI, "wght" is an axis that a variable font can optionally declare. Are you thinking Flutter gives us some special "adapter" logic to interpret "wght" for a font that hasn't declared that axis?

In a test just now on iOS, I requested the system font "Menlo" and the text didn't visibly change when I changed "wght", including through the specific values 400 and 600.

In contrast, I tried bundling the variable font SourceCodePro-VariableFont_wght.ttf with the app, and it did respond to changing "wght". In fact I could tell a difference between 200, 250, and 300, which I think confirms that we can set a non-centenary font weight (yay!).

[gnprice]

The docs did sound that way:

• The docs suggest this feature is there for the sake of variable fonts. Probably it works fine even if the font isn’t variable, though, as long as you pick a weight the font does have.

but I'd hoped that was just a matter of emphasizing the use case. Ah well.

In fact I could tell a difference between 200, 250, and 300, which I think confirms that we can set a non-centenary font weight (yay!).

Sounds like the experiment is a success, though, so we can close this issue. Thanks for trying it out!

[chrisbobbe]

I think there might be more worth investigating in this area, but then again it could be a small thing.

When we request a variable font that supports wght, we'll control the weight with fontVariations / 'wght'. But I think we'll also want to set fontWeight, for the sake of glyphs that need to be handled by a fallback font. I'm concerned that setting fontWeight will actually interfere with the glyphs rendered in the desired, variable font. In my experiments, those glyphs sometimes respond to a fontWeight that's set alongside a fontVariations / 'wght'.

…Although I don't yet see that result when the fontWeight value matches the wght value. 🤷‍♂️

Does this seem like a useful area to investigate?

[gnprice]

Sure. I guess the question there is just: if you set fontWeight: FontWeight.w200 but fontVariations to have wght of 250, do you get glyphs for

• weight 250, same as if you'd set only wght
• or weight 200, same as if you'd set only fontWeight?

Should be a quick add-on to the experiment you already have handy.

[chrisbobbe]

Hmm. In that experiment, as far as my eye can tell, the glyphs I get are the same as I get if I only set wght. Then as I raise fontWeight, the glyphs stay the same until I cross from FontWeight.w500 to FontWeight.w600. Then, they're thicker, but they stay the same as I keep raising fontWeight.

I see that same "threshold" effect when I set wght to 300.

I see that same "threshold" effect when I set wght to 400.

I see that same "threshold" effect when I set wght to 401, except now the threshold is the cross from FontWeight.w600 to FontWeight.w700.

I also see that new "threshold" effect when I set wght to 500.

When I set wght to 501, the threshold changes again: it's the cross from FontWeight.w700 to FontWeight.w800.

I also see that new "threshold" effect when I set wght to 600.

When I set wght to 601, the threshold changes again: it's the cross from FontWeight.w800 to FontWeight.w900.

I also see that new "threshold" effect when I set wght to 700.

When I set wght to 701 or higher, it doesn't seem to matter if I pass fontWeight, or with which of the FontWeight constants. (They go up to FontWeight.w900.)

[gnprice]

Hmm. In that experiment, as far as my eye can tell, the glyphs I get are the same as I get if I only set wght.

IOW the good, hoped-for answer, right?

And then it sounds like wght continues to prevail unless the discrepancy between it and fontWeight is very wide, like 250 vs. 600, or 501 vs. 800.

It seems a bit odd that fontWeight starts having an effect in that case. Possibly there's a bug there. But in practice I think we're always going to want the two to be in alignment — the fontWeight value will be just wght to the nearest 100, or anyway the nearest available value. E.g. if wght is 450, we'll want fontWeight to be w400 or possibly w500.

So it seems like everything looks good for that. Does that sound right to you?

[chrisbobbe]

IOW the good, hoped-for answer, right?

Yes, that's right. Since I don't understand what's causing the effect, I'm not sure if we'll be safe with a different font that I haven't tested yet 🤷 or if the effect is likely to vary in future Flutter versions, or between Impeller and Skia, iOS and Android, etc.

But at least we have this thread that we can follow up on if something seems wrong in the future.

By the way I think we don't want to set a weight property for a variable font in the pubspec.yaml? Not 100% sure though 🙂 https://docs.flutter.dev/cookbook/design/fonts#2-declare-the-font-in-the-pubspec

[gnprice]

Cool. There's always the possibility of new problems, but we can deal with those as they arise. I think we've now done the experiment we wanted to do, so there's no longer something for this issue to track.

By the way I think we don't want to set a weight property for a variable font in the pubspec.yaml?

I agree. That property is supposed to correspond to the weight of what's actually in the font file, so there's no one value that would make sense for it to be set to in the case of a variable font.

[chrisbobbe]

Linking flutter/flutter#33709 just because it has context on support for variable fonts in Flutter.