Check 161 (typographic family name) expects spaces in "SemiCondensed" and "SemiExpanded" for Encode Sans

Observed behaviour

When I check Encode Sans, I get the following fail:

🔥 FAIL: Check name table: TYPOGRAPHIC_FAMILY_NAME entries.

• com.google.fonts/check/161
• 🔥 FAIL Entry [TYPOGRAPHIC_FAMILY_NAME(16):WINDOWS(3)] on the ‘name’ table: Expected ‘Encode Sans Semi Condensed’ but got ‘Encode Sans SemiCondensed’. [code: non-ribbi-bad-value]

Expected behaviour

The expected value should be Encode Sans SemiCondensed, and the fail shouldn’t be triggered.

Resources and exact process needed to replicate

The latest Encode Sans VFs are here, along with fontbakery reports showing this fail: https://github.com/thundernixon/Encode-Sans/tree/d6e768f4f23b85e3ec5dbd04b2b928f564b06bcb/fonts/encodesanssemicondensed/split_vf

My guess is, this is caused by FontBakery wanting to find the canonical font family name by parsing the file name, which is EncodeSansSemiCondensed-Thin.ttf. However, if this is the case, we need a way to not apply this camel-case splitting logic for width-describing names.

[thundernixon]

Aesthetically, I also like Pablo’s proposal (in the earlier thread) for single, specific names. However, I don’t think Encode gets narrow enough to be “compressed” or wide enough to be “wide.” Like weight descriptions (e.g. “bold” vs “heavy”), width descriptions have connotations worth respecting.

As a modification of general width descriptions, “Semi” and “Extra” are helpful and obvious. To keep those clearly with their style words, it’s additionally helpful to camel case these.

[m4rc1e]

I see your point.

I’m more than happy for both width and weight styles to be camelcased. However, for families we have already released, we can’t change this.