Full font name does not begin with the font family name

Hi all,

I’m having some issues exporting an extended font family. FontBakery is complaining that the full font name (ID 4) does not begin with the font family name (ID 1) in several instances:

There are two things that can cause this to happen:

  1. As in the above example, Glyphs shortens name ID 1 (Ultra → Ul) but not the full name (ID 4)
  2. The instances aren’t named in the order width, weight, slope. If e.g. “Bold” is in the middle of the string, it gets taken out from the middle and not the end

Should I ignore this error? The naming tutorial specifically states that the full name should start with the family name:

So we are completely free to write what we want, right? Well, not quite. According to Adobe Tech Note #5088, some systems match the font’s Family Name against the PostScript Full Name ‘for sorting into family groups.’ Therefore, the PostScript Full Name should start with the Family Name. The PostScript Full Name ‘is completed by adding style attributes — generally in this sequence: weight, width, slope, optical size’ (Adobe Technote #5088), e.g., ‘Bold Extended Italic Display’, or ‘Medium Condensed Oblique Caption’, or ‘Semibold Oblique’, or ‘Compressed Poster’, or ‘Light’.

Also, this paragraph seems to contradict (part 3 of the instance tutorial), which states:

Firstly, the Style Name is usually a combination of words indicating the width (condensed to wide), the weight (light to bold), and the slope (italic or not) of a font style, in that order.

So which of these orderings is correct? And should we ignore the FontBakery error?

It seems like there are (much like with vertical metrics) two differing strategies at work here. The OpenType specification states:

For extended typographic families that includes fonts other than the four basic styles (regular, italic, bold, bold italic), it is strongly recommended that name IDs 16 and 17 be used in fonts to create an extended, typographic grouping. (See examples provided below.)

So I see the following possibilities:

  1. If we simply “cut out” the RIBBI terms from name ID 1 and keep all others, we can’t guarantee that name ID 4 will always begin with name ID 1. Even if we ensure that weight and slope are at the end of the font name, we would have to shorten name ID 4 if name ID 1 gets shortened, which we don’t at the moment. This seems to be the “Microsoft way” :wink:

  2. We keep everything as it is and ignore the fact that the full font name does not begin with the font family name

  3. The “Adobe way” seems to be to ignore the (later?) recommendation in the Microsoft spec and include only the font name as ID 1 and the complete, non-RIBBI style description in ID 4, starting with weight.

  4. Edit: Glyphs 2 (see my later reply below) seems to use the MS strategy for the Windows name IDs 1 and 4 and the Adobe strategy for the Macintosh name IDs. Why doesn’t Glyphs 3 do this anymore? Is it a bug?

Any ideas what is the best way to proceed and whether Glyphs is doing everything right? Thanks!

Update: I’ve just compared the exports with Glyphs 2 and Glyphs 3. In Glyphs 2, the family and subfamily names differ according to platform (Win/Macintosh). For Win, they are RIBBI; for Mac only the font family name is included in ID1; the complete non-RIBBI style description is in ID4.

In Glyphs 3, both Mac and Win name IDs 1 and 4 are the same and reflect the Windows rules (RIBBI in ID4; the rest in ID1). Is this a bug?

No this is intentional. It used to make sense to have separate Mac entries. Now I recommend to not add Mac names at all.

Thanks @mekkablue. So should I ignore the fact that ID 4 does not always begin with ID 1 and disable that FontBakery check?

Or manually set the font name.

Thanks, Georg. How do I do that in Glyphs 3? Please see my post: postscriptFontName custom parameter in Glyphs 3

All naming is part of the General section now, not a custom parameter anymore.

The Naming tutorial needs another update I’m afraid.

1 Like