Full font name does not begin with the font family name

Glyphs
1

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:

grafik
grafik896×129 28.1 KB

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!

2

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?

3

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

4

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

5

Or manually set the font name.

6

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

7

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
8

I get the same fontbakery error because a couple of instances get name ID 1 with Cond instead of Condensed on export:
Sans Condensed Medium → Sans Cond Medium
Sans Condensed Medium Italic → Sans Cond Medium Italic

Those are not even the longest names — Regular is one letter longer than Medium, but it exports with full Condensed in it, and fontbakery is ok with the length.

So, Glyphs shortens the names of some instances (but not the others) which causes fontbakery errors, while just leaving them as is would pass the checks. The workaround is to add Style Map Family Names to those instances, but isn’t it strange to manually fix the “outsmarting”, unless I’m missing the point?

9

You want to keep name ID 1 as short as possible because the only remaining significant usecase today is the tiny font menu for Word on Windows.

I have a suspicion that this test is too strict. Should be a warning, not a fail. Or are there known issues?

11

But the shortening logic is unclear: Of over 100 instances in my case, it only shortens Condensed Medium and Condensed Medium Italic, even though many other instances with the word Italic such as Condensed Light Italic are longer than just Condensed Medium, and Condensed Regular Italic doesn’t get shorten despite being longer than the Mediums.

This is font bakery’s explanation:

The FULL_FONT_NAME entry in the ‘name’ table should start with the same string as the Family Name (FONT_FAMILY_NAME, TYPOGRAPHIC_FAMILY_NAME or WWS_FAMILY_NAME).

If the Family Name is not included as the first part of the Full Font Name, and the user embeds the font in a document using a Microsoft Office app, the app will fail to render the font when it opens the document again.

NOTE: Up until version 1.5, the OpenType spec included the following exception in the definition of Full Font Name:

“An exception to the [above] definition of Full font name is for Microsoft platform strings for CFF OpenType fonts: in this case, the Full font name string must be identical to the PostScript FontName in the CFF Name INDEX.”

name - Naming table (OpenType 1.5) - Typography | Microsoft Learn

And this is the error note:

On the ‘name’ table, the full font name ‘Sans Condensed Medium Italic’ does not begin with the font family name ‘Sans Cond Medium’ in platformID 3, encodingID 1, languageID 1033(0409), and nameID 1.

12

I’ll see if I can reproduce this. But embedding in Word documents is pretty buggy in any case.