Fontbakery: Checks name/fullfontname, name/postscriptname and name/match_familyname_fullfont falsely reject abbreviated font names

Created on 5 Dec 2018 · 16Comments · Source: googlefonts/fontbakery

Observed behavior

As described in Issue #2179, nameIDs 4 & 6 sometimes have to be abbreviated to under 29 characters (the limit is slightly debated, but it's 31 _maximum_, based on sources I've read).

However, Check 159 simply seems to expect nameID 4 to _always_ equal a concatenation of familyname_with_spaces and style_with_spaces, which are (I think) nameIDs 1 & 2.

Expected behavior

When nameIDs 4 & 6 are abbreviated to work in legacy software, nameIDs 1 & 2 do not need to be abbreviated. Therefore, I think this test could be an INFO or a WARN, but should not be a FAIL.

Resources and exact process needed to replicate

You can build statics in Encode Sans with the build script sources/scripts/build-statics.sh...

...or visit the FontBakery report at https://github.com/thundernixon/Encode-Sans/blob/master/fonts/encodesanssemicondensed/static/EncodeSansSemiCondensed-ExtraLight-fontbakery-report.md

...but the relevant part is this:

:fire: FAIL: Check name table: FULL_FONT_NAME entries.

com.google.fonts/check/159
:fire: FAIL Entry [FULL_FONT_NAME(4):WINDOWS(3)] on the 'name' table: Expected 'Encode Sans Semi Expanded ExtraLight' but got 'Encode Sans SemiExpd ExLght'.

:fire: FAIL: Check name table: POSTSCRIPT_NAME entries.

com.google.fonts/check/160
:fire: FAIL Entry [POSTSCRIPT_NAME(6):WINDOWS(3)] on the 'name' table: Expected 'EncodeSansSemiExpanded-ExtraLight' but got 'EncodeSansSemiExpd-ExLght'.

:fire: FAIL: Does full font name begin with the font family name?

com.google.fonts/check/068
:fire: FAIL On the 'name' table, the full font name (NameID 4 - FULL_FONT_NAME: 'Encode Sans Condensed Black') does not begin with font family name (NameID 1 - FONT_FAMILY_NAME: 'Encode Sans Cond Black') [code: does-not]

P2 Important

Source

thundernixon

👍1

All 16 comments

As one additional thing to flag here (this can be split into a different issue if it makes more sense), the text of check 068 is a bit confusing / misleading.

:fire: FAIL On the 'name' table, the full font name (NameID 4 - FULL_FONT_NAME: 'Encode Sans Condensed Black') does not begin with font family name (NameID 1 - FONT_FAMILY_NAME: 'Encode Sans Cond Black') [code: does-not]

However, in this particular static instance:

NameID 4 is actually Encode Sans Cond Black, not "Encode Sans Condensed Black" as seems to be indicated by the check message
NameID 1 is actually Encode Sans Condensed Black, not "Encode Sans Cond Black" as seems to be indicated by the check message

So, it seems like the text is either mixing those strings up, or possibly the values of FULL_FONT_NAME and FONT_FAMILY_NAME aren't getting defined in a bulletproof way.

Here's the TTX file for Encode Sans Condensed Black

thundernixon on 6 Dec 2018

👍1

Note: We need to standardize short-versions of canonical names and then I can make all fontbakery checks adhere to that as well.

felipesanches on 7 Dec 2018

Per our call today, we need a standard way to abbreviate font naming.

I mentioned that we might follow the cited by the GlyphsApp Naming Tutorial with the header "The PostScript Names", which are from an earlier technical note on naming for PostScript, from Adobe (see page 27).

The one downside is that they are _very_ short, and therefore not always very easy to understand. Would the average user know that "Sm Bd" is "SemiBold"?

thundernixon on 7 Dec 2018

If this became a real standard, applications could display the long names whenever the short names are used.

One problem with this table is that not all entries map to our current set of not-shortened canonical names.

felipesanches on 7 Dec 2018

Well... the ideal solution would be for the applications to lift the maximum length restriction on name entries. But we have to deal with legacy applications...

felipesanches on 7 Dec 2018

I think a set of Short/Medium/Full names would be better, so for things that are too long when full, but very short so almost undecipherable, and medium is not too long, that would be good

davelab6 on 14 Dec 2018

@thundernixon please propose medium names :)

davelab6 on 14 Dec 2018

Example of where medium names are useful: "Encode Sans SemiExpanded Black" is too many pixels wide to fit in the MS Word font menu, where the style of the font itself is shown, along with the name. For this, I've shortened names in the <name> table to make them (mostly) fit:

I'll write down a list of medium-sized abbreviations that I think work well and share them here for discussion in a bit.

thundernixon on 14 Dec 2018

thanks!

felipesanches on 14 Dec 2018

My proposal

Background:
Font names often need to be shortened to allow installation on platforms, and sometimes to work well within UI contraints (e.g. narrow font menus). There are existing guidelines from Adobe on shortening style names for Postscript naming. However, these two-letter abbreviations are often shorter than needed, and their meaning is sometimes unclear (especially for non-type designers). Today, type designers tend to come up with medium-length abbreviations on-the-fly, but it will be simpler for users to limit the amount of abbreviations for stylistic names, and simpler to test in FontBakery if there is a canonical list of abbreviations.

Proposed system
A useful balance of clarity and brevity is the primary goal of font name abbreviations, and these dual considerations should guide decisions. Rules:

Medium-length abbreviations have 3 to 4 letters (e.g. "Med" makes perfect sense).
Style names that are already 3 or 4 letters don't need medium-length abbreviations.
A type family can mix short, medium, and long style names, based on contextual needs and the designer's discretion. For example, it would be valid for the same font family to have styles _XLight, Med Ital,_ and _DmBold_ (these include short, medium, and full names).
Type families should generally be consistent in using the same abbreviation everywhere, but it shouldn't be treated as a "fail" to mix naming between styles. For example, a type may use both _Familyname ExtraBold_ and _Familyname Ext XBd Ital_ (the first is clear as a simple name, but the second may be necessary to fit within limitations).

Prefixes (These have no trailing space, e.g. _DemiBold_)

| Short |Full | ✨Medium ✨| _Note_ |
| :-- | :-- | :-- | :-- |
| Dm | Demi | - | _Prexfix_ |
| Sm | Semi | - | _Prexfix_ |
| X | Extra | Extr | _Prexfix. Not sure if medium name needed._ |
| Bd | Bold | - | |
| Bk | Book | - | |
| Blk | Black | - | _Short name is already medium-length_ |
| Cm | Compressed | Comp | |
| Cn | Condensed | Cond | |
| Ct | Compact | Cmpt | |
| Ds | Display | Disp | |
| Ex | Extended | Ext | |
| Hv | Heavy | Hvy | |
| Ic | Inclined | Incl | |
| It | Italic | Ital | |
| Ks | Kursiv | Krsv | |
| Lt | Light | Lght | |
| Md | Medium | Med | |
| Nd | Nord | - | |
| Nr | Narrow | Nrrw | |
| Obl | Oblique | Oblq | |
| Po | Poster | Pstr | |
| Rg | Regular | Reg | |
| Sl | Slanted | Slnt | |
| Su | Super | Supr | |
| Th | Thin | - | |
| Ult | Ultra | Ultr | |
| Up | Upright | Uprt | |

New names (not included on Adobe's list)

| Short |Full | ✨Medium ✨| _Note_ |
| :-- | :-- | :-- | :-- |
| Exp | Expanded | Expd | |
| Mc | Micro | Micr | _For optical sizing; opposite of Display. Not sure of this one._ |
| Mn | Monospaced | Mono | |
| Pr | Proportional | Prop | |
| Rd | Round | Rnd | |
| Sn | Sans | - | |
| Sr | Serif | Srf | |
| SC | Smallcaps | - | _Specific to Google Fonts_ |
| Tx | Text | Txt | _For optical sizing_ |
| Wd | Wide | - | |
| VF | Variable | Var | _Google Fonts may not use this, but others are._ |

Of course, there will still be custom names we can't account for, especially for experimental and display fonts and for currently-uncommon stylistic axes like Grade. Still, this list might be a helpful starting point for extending the checks listed in this issue.

Open questions:

Does anyone have suggestions for better medium names? Feel free to leave suggestions!
I've copied Adobe's list and made a few additions below, but are there other style names I may have missed? Or, should any of these be excluded? Again, feel free to add comments below.

thundernixon on 14 Dec 2018

Still getting this issue, I suggest renaming the issue as the issues referenced are now known as:

com.google.fonts/check/name/fullfontname
com.google.fonts/check/name/postscriptname
com.google.fonts/check/name/match_familyname_fullfont

weiweihuanghuang on 23 Jan 2020

Similarly my fonts fail this test when I abbreviate part of the typographic family name, as fontbakery tries to untagle the camelcasing:

🔥 FAIL: Check name table: TYPOGRAPHIC_FAMILY_NAME entries.

com.google.fonts/check/name/typographicfamilyname

🔥 FAIL Entry [TYPOGRAPHIC_FAMILY_NAME(16):WINDOWS(3)] on the "name" table: Expected "Bananas Extra Extended" but got "Bananas ExtraExtended". [code: non-ribbi-bad-value]

weiweihuanghuang on 23 Jan 2020

Should this same issue go under here?

🔥 FAIL: Check name table: TYPOGRAPHIC_FAMILY_NAME entries.

com.google.fonts/check/name/typographicfamilyname
🔥 FAIL Font style is "Bold" and, for that reason, it is not expected to have a [TYPOGRAPHIC_FAMILY_NAME(16):WINDOWS(3)] entry! [code: ribbi]

The name tables are:
ID 1 FONT_FAMILY_NAME: Bananas XExt
ID 2 FONT_SUBFAMILY_NAME: Bold
ID 4 FULL_FONT_NAME: Bananas XExt Bold
ID 6 POSTSCRIPT_NAME: BananasExtraExtended-Bold
ID 16 TYPOGRAPHIC_FAMILY_NAME: Bananas ExtraExtended

It needs the ID 16 since ID 1 has been abbreviated.

weiweihuanghuang on 13 Feb 2020

I would like to follow up on this issue as I am running into it on several fonts that I'm working on. It really shouldn't be a "FAIL" IMO.

aaronbell on 6 Nov 2020

👍1

Something else I'd like to suggest—that in the case of prefixed short names, like "Sm Bd", that we allow them to have no space between them, ala "SmBd". That saves an additional character, which might be very important 😄

aaronbell on 6 Nov 2020

👍1

I'd also like to suggest that for the prefix forms, like with Extra, it would be useful to be able to collapse to a single letter in extreme cases:

aaronbell on 13 Nov 2020

Was this page helpful?

0 / 5 - 0 ratings