Should we allow intermediate (non-100) weights?

thundernixon commented 5 years ago

I'm hoping that @davelab6, @m4rc1e, @laerm0, or others might be able to give their view this.

Observed behaviour

Fira Code currently has a named instance, "Retina," halfway between Regular and Medium, to allow users a bit more of a choice on font weight in their text editors.

To me, this seems like it should (ideally) be a valid design choice – it makes sense to offer users a bit more choice in font weight, without having to do something more complex like adding in a "grade" axis.

For instance, IBM Plex has a "Text" instance with a weight value of 450 (https://github.com/IBM/plex/blob/master/scripts/data/weights.js).

I know that the GF Docs say that weights must be in a valid CSS value of 100–900. But, might this be something that becomes less rigid with variable fonts?

Currently, this causes a fail in FontBakery:

🔥 FAIL: Variable font weight coordinates must be multiples of 100.

* [com.google.fonts/check/varfont_weight_instances](https://github.com/googlefonts/fontbakery/search?q=com.google.fonts/check/varfont_weight_instances) * 🔥 **FAIL** Found an variable font instance with 'wght'=450.0. This should instead be a multiple of 100.

It also has caused some problems in FontMake, as the Fira Code source currently labels the Retina instance with weightClass: 900, presumably just to use an open slot.

For now, I've tried:

A test of giving both "Regular" and "Retina" 400 in GlyphsApp results in "Regular" having a value of 364.70589 (obviously not great). FiraCode-VF-retina.ttf.zip
unchecking this as an active instance in GlyphsApp, which prevents it from building into static or variable fonts. This makes things work at a basic level, but misses part of the design. FiraCode-VF.ttf.zip

Expected behaviour?

Should we allow intermediate weights, or just put a blanket "no" on it to keep things easy for us (though not necessarily as good as possible for font users)? Do VFs change this at all?

If we can allow intermediate weights, what might be a good way to do so? Should I just give the "Retina" instance a "Medium," 500 weight class, then bump up the existing Medium to 600? Or is there a better way I'm not seeing?

Resources and exact process needed to replicate

You should be able to replicate this issue if you build then check from the GlyphsApp source at 2eb3fc6b

laerm0 commented 5 years ago

I can't see any logical reason not to allow weights not in multiples of 100, but I am not a web developer so I dunno how CSS would handle it.

thundernixon commented 5 years ago

As I understand it, you can’t get a non-100-multiple weight from CSS today, if you’re calling in a static font. However, you could set that “Retina” static as a weight value like 500 when pulling it in as a static font via @font-face, and then call it as 500.

In a variable font, so long as the @font-face calls a VF file and sets a font weight range, the user could call any font weight value in that range.

There is also a spec to allow CSS users to call named instances in a font: https://www.w3.org/TR/css-fonts-4/#font-named-instance

thundernixon commented 5 years ago

As a small update here, I've found a way to set up the instance in GlyhpsApp such that it exports a font as expected: "Retina" gets a custom parameter of weightClass: 450, and a glyphs menu-weight of "Normal." Tested in axis-praxis, it seems to work well (FiraCode-VF.ttf.zip).

In this case, is there still a reason to avoid non-100-multiples, or is this check overly-strict?

Instance setup in Glyphs:

TBBle commented 2 years ago

I know that the GF Docs say that weights must be in a valid CSS value of 100–900. But, might this be something that becomes less rigid with variable fonts?

Poking around, I noticed that the CSS Fonts 4 current draft removes the multiple-of-100 requirement from font-weight, as part of allowing variable fonts to function correctly on the Web. So that indeed turns out to be becoming less rigid, at least in CSS. Hopefully GF rules will follow suit as that moves through the ecosystem.

davelab6 commented 2 years ago

This check is in the gf profile (com.google.fonts/check/varfont_weight_instances) not universal, and gf continues to require this due to workspace code. @m4rc1e did this intersect with your latest name table check rewrite?

m4rc1e commented 2 years ago

Yes it did intersect with my new checks so I removed it. If a user is checking a font using the google fonts profile and their instances are not multiples of 100, it will still error on the new check.

fonttools / fontbakery