• by Rainer Erich Scheichelbauer
  • Tutorial

Font names are important because they determine font menu grouping and ordering, which is crucial for the way your fonts will appear to your users. What makes it difficult is the fact that the font names are stored in six different places in the font. Or actually, a few more places. Which makes it even more complicated. Historically grown, you know.

Oh, and different apps read the font naming information in different ways. Good luck.

Family Name and Style Name

Basically, fonts with the same Family Name can be grouped together somehow in a user interface. How exactly this is done, of course, depends on the software that employs your fonts. You can set your Family Name in File > Font Info > Font > Family Name:

The individual fonts of your family need to be differentiated by their Style Name, which is set in File > Font Info > Instances. Each instance has a Style Name field. Typical style names are: Regular, Italic, Bold, Medium, Light Italic, Display Bold, Caption Italic, etc. In other words, some combination of keywords for:

  • Weight: Thin, Light, Extralight, Regular, Medium, Semibold, Bold, Extrabold, Heavy, Black, etc.
  • Width: Compressed, Condensed, Extended, Expanded, etc.
  • Slope: Italic, Oblique, Upright Italic, Backslant, etc.
  • Optical Size: Display, Text, Caption, Small

Of course, you can use any style name. If it makes sense for your design, you can also call it Felt Tip or Hatched or Outline or anything you like. Western Latin accents in the name should not cause much of a problem in modern software.

If you want some instances to have different family names than the default family name set in File > Font Info > Font > Family Name, you can add a custom parameter called familyName.

So, you would end up with a naming scheme like this:

Family Name Style Name
MyFontFamily Regular
MyFontFamily Italic
MyFontFamily Bold
MyFontFamily Bold Italic
MyFontFamily Semibold
MyFontFamily Semibold Italic
MyFontFamily Black
MyFontFamily Black Italic
MyFontFamily Condensed
MyFontFamily Condensed Italic
MyFontFamily Condensed Bold
MyFontFamily Condensed Bold Italic
MyFontFamily Condensed Semibold Italic
MyFontFamily Condensed Black
MyFontFamily Condensed Black Italic

Localized Names

For maximum compatibility, however, there is something to be said for keeping the Family Name and Style Name plain-ASCII, English, and short. If you want to go beyond that, and use non-ASCII characters (e.g., for a Japanese or Armenian or Czech name), it is a good idea to add localized names.

To localize your family name, go to File > Font Info > Font, add a custom parameter by clicking on the Plus button in the Custom Parameters section, choose localizedFamilyName from the Property pop-up, and click into the Value field for choosing the language and setting the name:

Add a custom parameter for every language in which you want the name to appear different from the default Family Name. The choice of languages is limited, because the spec was written a long, long time ago in a galaxy far, far away. It supports Icelandic and Afrikaans, it can even differentiate between Flemish and Dutch, but it does not know about Malay, Mongolian or Macedonian. Sorry about that, but there is not much we can do about it.

To localize your style name, add the localizedStyleName custom parameter to the respective fonts in File > Font Info > Instances.

You can also localize the family name in the instances, i.e., the custom parameter localizedFamilyName is also available in File > Font Info > Instances > Custom Parameters. This can be useful if you have custom family names for some instances, and need to localize those too.

While we’re at it, you can also ‘localize’ the designer name entry. How? With the localizedDesigner parameter,of course. There is also another localization entry, explained further below. See if you can find it.

Style Linking

You can set up family relationships between individual fonts with something called style linking. You can define one instance as the Bold, Italic or Bold Italic of another instance. This is pretty easy with the Style Linking section in File > Font Info > Instances. All you need to do there, is activate the Bold and/or Italic checkbox, and fill in the name of the related instance, e.g.:

With style linking, you can create so-called ‘RIBBI families’. RIBBI is short for Regular, Italic, Bold and Bold Italic. This seems a bit limiting, but its purpose is to enable the Bold and Italic buttons and shortcuts in Office software. If you do this right, you can use Cmd-B in TextEdit to switch back and forth between the Regular and the Bold, or Ctrl-I in Word on Windows for toggling between the Upright and the Italic. Adobe InDesign uses Cmd-Shift-B and Cmd-Shift-I for the same purposes, by the way.

In other words, style linking can only create a relationship between four styles, not more. Another thing to consider ist that linked styles will not be displayed in Microsoft Office font menus. Only the Regular is visible, the linked styles are exclusively accessed through the B and I buttons (or the respective shortcuts). We therefore recommend the following strategy for style linking:

  • The ‘Bold’ instance is the Bold of the ‘Regular’.
  • The ‘Italic’ instance is the Italic of the ‘Regular’.
  • The ‘Bold Italic’ instance is the Bold and Italic of the ‘Regular’. (Careful here: not the bold of the italic or the italic of the bold.)
  • All other italics are the Italic of their respective upright, e.g., ‘Semibold Italic’ is the Italic of ‘Semibold’.
  • For all remaining uprights, leave these settings blank.

So, if we do everything right, our font family set up looks like this:

Family Name Style Name Style Linking
MyFontFamily Regular -
MyFontFamily Italic Italic of Regular
MyFontFamily Bold Bold of Regular
MyFontFamily Bold Italic Bold and Italic of Regular
MyFontFamily Semibold -
MyFontFamily Semibold Italic Italic of Semibold
MyFontFamily Black -
MyFontFamily Black Italic Italic of Black
MyFontFamily Condensed -
MyFontFamily Condensed Italic Italic of Condensed
MyFontFamily Condensed Bold Bold of Condensed
MyFontFamily Condensed Bold Italic Bold and Italic of Condensed
MyFontFamily Condensed Semibold -
MyFontFamily Condensed Semibold Italic Italic of Condensed Semibold
MyFontFamily Condensed Black -
MyFontFamily Condensed Black Italic Italic of Condensed Black

Pro Tip: Instead of typing the name Regular into the style link field, you can simply leave it blank. Glyphs will assume Regular in that case. One error source less.

Naming for Windows and Office Software

Microsoft Word currently focuses on Family Name and Style Name, or the WWSFamilyName and WWSSubfamilyName, if present. WWS stands for Weight, Width and Slope.

Good to know: In tech literature, Family Name and Style Name are usually referred to as Name IDs 1 and 2. The term ‘Name ID’ refers to the entries in the OpenType Naming Table, which is the way the naming information gets stored in the compiled font file. For more information, see the Naming Table specification.

Good to know: The WWS names are stored as Name IDs 21 (WWSFamilyName) and 22 (WWSSubfamilyName).

The Microsoft font menu assumes a family model where the only possible members of a font family are Regular, Bold, Italic, and Bold Italic, i.e., the RIBBI styles between which style linking is set up as described above. Anything else that isn't one of these four must be considered a separate family. Therefore, Microsoft officially recommends this naming strategy:

Family Name (ID 1) Style Name (ID 2)
MyFontFamily Regular
MyFontFamily Italic
MyFontFamily Bold
MyFontFamily Bold Italic
MyFontFamily Semibold Regular
MyFontFamily Semibold Italic
MyFontFamily Black Regular
MyFontFamily Black Italic
MyFontFamily Condensed Regular
MyFontFamily Condensed Italic
MyFontFamily Condensed Bold
MyFontFamily Condensed Bold Italic
MyFontFamily Condensed Semibold Regular
MyFontFamily Condensed Semibold Italic
MyFontFamily Condensed Black Regular
MyFontFamily Condensed Black Italic

And so on. In other words, the Style Name (ID 2) can only ever be one of the RIBBI styles. All the other info about Weight, Width and Slope goes into the Family Name (ID 1). What you can also see, of course, is that this is very different from the table you can see further above. There are a few problems with this. It is hard to handle. You have to add an awfully high number of familyName parameters, and what’s worse, you would lose your oversight in File > Font Info > Instances, because most of the style names are the same. Also, what may be right for Word, may not be ideal for other apps, like DTP programs.

But wait a minute…

There’s good news: You don’t have to do this. Glyphs will automatically take care of this at export time. Based on your style linking info, Name IDs 1 and 2 will be set accordingly in the Windows names of the Naming Table. (That’s right, the info in the name table is stored twice, once for Mac, once for Windows. Don’t even ask why.) That is why, from here on, I will not refer to the default family and style names (as entered in Font Info) by their Name IDs, because it’s more complicated than that.

If, for whatever reason, this automation does not work, i.e., the B and I buttons in Word do not produce the expected styles, you can take control of the style mapping with a custom parameter called styleMapFamilyName. This quote from the Glyphs Handbook says it all:

styleMapFamilyName: Family name used for bold, italic and bold italic style mapping. You can use this to create subfamilies within larger font families. ‘Up to four fonts can share the Font Family name, forming a font style linking group (regular, italic, bold, bold italic – as defined by OS/2.fsSelection bit settings). Glyphs uses the entries in Style Name field and in the Style Linking section of the instance for linking the four individual weights.

Again, you will most likely not need the parameter. But just in case.

Even less useful is the localizedStyleMapFamilyName parameter, which, as the name already suggests, is the localized variant of styleMapFamilyName. If I were to bet, I would guess it has been used less than 5 times in the history of this glorious application. But then again, I am not much of a gambler.

WWS Names: Name IDs 21 and 22

The WWS names, also known as Name IDs 21 and 22, are only needed:

  • if the family has style variants other than weight, width, and slope, i.e., a non-WWS axis;
  • and only for those fonts that have a non-normal value for that non-WWS axis, i.e., if the style cannot be expressed purely with weight, width and slope.

Let’s suppose we want to expand our font family with optical size variants, like ‘Subhead’, ‘Display’, ‘Caption’, etc. The fonts we have seen in the tables above would not require WWS names because they are not non-normal on our new Optical Size axis. But the new fonts we add, that take up a special, non-normal position on our Optical Size axis, they do need the WWS names.

And the way this works is that you create separate families with the non-normal names, and put those family names into ID 21, but keep all the weight, width and slope info in ID 22. So, Name ID 22 is not only for RIBBI names, but for anything that falls into the weight, width or slope category, like Medium Extended Italic or Bold Condensed Oblique.

Family Name Style Name WWS Family Name (ID 21) WWS Subfamily Name (ID 22)
MyFontFamily Display Light MyFontFamily Display Light
MyFontFamily Display Light Italic MyFontFamily Display Light Italic
MyFontFamily Display Medium Extended MyFontFamily Display Medium Extended
MyFontFamily Display Medium Extended Italic MyFontFamily Display Medium Extended Italic
MyFontFamily Display MyFontFamily Display Regular
MyFontFamily Display Italic MyFontFamily Display Italic
MyFontFamily Display Bold MyFontFamily Display Bold
MyFontFamily Display Bold Italic MyFontFamily Display Bold Italic
MyFontFamily Display Semibold MyFontFamily Display Semibold
MyFontFamily Display Semibold Italic MyFontFamily Display Semibold Italic

How do you do that in Glyphs? Easy. You add the appropriate custom parameters for the respective fonts in in File > Font Info > Instances. For the WWS Family Name, you used WWSFamilyName, and for the WWS Subfamily Name, you add a WWSSubfamilyName. Who would have guessed.

Note 1: Inclusion of IDs 21/22 should correlate exactly with the state of OS/2.fsSelection.bit8, if you know what that means. If you don’t, don’t worry, Glyphs takes care of this automatically.

Note 2: For a case like MyFontFamily Compressed, where the style name is purely expressible with WWS, name IDs 21/22 are not required, remember? But actually, the spec does not preclude including IDs 21 and 22, provided this fsSelection bit 8 is set. So if you feel like it and have a lot of time to kill, you can add them everywhere. But really, finish early and have an ice cream instead. If you want to take control of fsSelection bit 8 yourself, add the Has WWS Names parameter to your instance: According to the OpenType specification, this bit indicates that ‘the font has “name” table strings consistent with a weight/width/slope family without requiring use of “name” IDs 21 and 22.’ Keep in mind that this makes sense only if the naming of your font already adheres to the WWS scheme.

Naming for Adobe Menus

Fonts in Adobe menus are sorted into submenus based on their Family Name. This can be overridden by the Preferred Names (Name IDs 16 and 17). So if you don’t like the submenu arrangement, you can make your own submenus with PreferredFamilyName and put the rest of the respective font name into PreferredSubfamilyName.

Inside the submenu, the fonts are sorted by, and in this order:

  1. by the width class,
  2. by the weight class,
  3. by the slope (upright or italic),
  4. alphabetically by the style name.

You can set the width class by choosing from the Width menu (1), a weight class from the Weight menu (2), the slope with the Italic button (3), and the alphabetic order, of course, with the Style Name (4). Furthermore, if you need to differentiate further when it comes to width and weight classes (because several of the options will yield the same number displayed to the right to the menu), you can add widthClass and weightClass parameters and directly set the number for ordering.

Hint: Older versions of MS Office would automatically bolden fonts with weight classes lower than 250. This can lead to the weird effect that the Extralight with weight class 200 appears bolder than the Light with weight class 300. To avoid that, make sure your lowest weight class is 250 or higher. Of course, if you only cater to users with newer versions of MS Office, or no MS Office at all, you can ignore this and start at 100.

That means that you can do anything you like! If you want all the fonts to be in the same submenu, you just make sure that the preferredFamilyName is the same for all fonts. If, however, you want to have your fonts in different submenus, you can differentiate with the same parameter.

Just keep in mind that you only need to set these parameters if they differ from the Family Name and Style Name entries. Otherwise they are not necessary. In other words, only use the Preferred Names to override the defaults established by Family and Style Name. Needless to say, it makes no sense to override them with the same values.

Example: Let’s say you have a Weight and a Width axis. And let’s further assume that you have 5 widths and 9 weights, i.e., 45 fonts in total. Imagine that submenu, whoa. You have two choices:

(A) You want to keep all 45 fonts in one menu. Then you don’t have to change anything in the above setup. Congratulations, you can go and have a drink now.

(B) You want to have the font in five different submenus for the five widths. That way, you clutter your font menu with five entries instead of one entry, but at least your submenus will only have 9 entries each instead. In that case you would use the preferredFamilyName for all non-normal widths, e.g., ‘MyFont Compressed’, ‘MyFont Condensed’, ‘MyFont Semiextended’, and ‘MyFont Extended’. For the normal width, the ‘normal’ Family Name ‘MyFont’ suffices. Thus, it does not need a Preferred Family Name.

Windows vs. Mac: Full Name vs. Compatible Full Name

Windows uses Name ID 4 (‘Full Name’) for displaying the full name of the font, e.g., in a menu. Usually it consists of the family name, followed by a space, followed by the style name. This is also how Glyphs autocalculates the ID 4 name. You can override it with a Name Table Entry parameter (see below). So far, so good.

The Mac also uses Name ID 4 for this purpose. That is, unless there is Name ID 18 (‘Compatible Full Name’) present in the font. In other words: If, for whatever reason, you cannot live with the ID 4 name in your Mac menus, you can have a different name by adding a custom parameter called compatibleFullName to your instance in File > Font Info > Instances.

Needless to say, only do this if you have a really good reason. Using compatibleFullName may break cross-platform interoperability of documents. You have been warned.

Compatible Name Table

I told you above that Glyphs automatically takes care of juggling the Name table entries into their right spots, so that stuff works best in Adobe apps, as well as in Microsoft Office and CoreText apps on the Mac. Most apps are covered this way.

Occasionally, however, you will have a customer that complains. Especially users of Quark XPress and legacy versions of FontExplorer. If you hear the complaint that the font family is not correctly grouped in those apps, you can use a custom parameter called Compatible Name Table. It will cause Glyphs to export a legacy-style name table.

The font family will then be grouped properly in Quark XPress and FontExplorer. However, it will mess up family grouping in other apps, including Microsoft Office. Can’t have it all, I am afraid.

The PostScript Names

The PostScript names are a legacy from the PostScript Type 1 era. Some apps, and some (especially PostScript-based) file formats will use the PostScript Font Name for storing font information in documents. The PostScript Full Name is intended for the human reader only. Again, both are set automatically by Glyphs, and you will most likely not have any problems if you simply let the app do its magic. So you can jump to the next headline in this tutorial unless you have a really good reason to set it yourself.

The PostScript Font Name can be set in File > Font Info > Instances with a custom parameter called postscriptFontName. It is tricky for two reasons: the length of the name, and the character restrictions. Technically, the maximum length is 127 characters, which should be good enough for almost all fonts. Some legacy software like the Adobe Type Manager (ATM), however, only considers the first half, i.e., 63 characters. In other words, old apps may not be able to differentiate between two fonts, or even malfunction, if the first 63 characters of their PostScript Font Names are the same. The good news: If you do not care about legacy software, you can ignore this restriction. But if you do care about legacy compatibility, it can get even worse: early PostScript interpreters cannot have more than 29 (yes, twenty-nine) characters. Ugh.

Pro tip: The 29-character limit also applies to EOT webfonts. While EOT is rapidly becoming an outdated format, it may still be necessary in some cases, or the client wants to be on the safe side and have all available formats. So, if you are exporting an EOT, you may want to also set the PostScript Font Name, and make sure it does not exceed a length of 29 characters.

In terms of character restrictions, your PostScript Font Name can only contain 7-bit ASCII without control characters, without space, and without these 10 characters: [](){}<>/% because they are reserved in the PostScript language. The hyphen - is reserved for connecting family and style name. In other words, you get to use only these characters:


That means that MyFont Condensed Extrabold Italic will turn out to be MyFont-CondensedExtraboldItalic, which is 31 characters long. Let’s further assume that your client demands that you have to support that image setter from 1988, which can handle no more than 29 characters. In order to reach the length limit, you can abbreviate the part that makes up the style name to CdXBdIt. The complete font name, thus, turns into MyFont-CdXBdIt, which counts no more than 14 characters. Now you can dust off those machines from the museum again.

In Tech Note #5088, Adobe recommends these abbreviations for style names:

Short Full
Bd Bold
Bk Book
Blk Black
Cm Compressed
Cn Condensed
Ct Compact
Dm Demi (prefix)
Ds Display
Ex Extended
Hv Heavy
Ic Inclined
It Italic
Ks Kursiv (German for: Italic)
Lt Light
Md Medium
Nd Nord
Nr Narrow
Obl Oblique
Po Poster
Rg Regular
Sl Slanted
Sm Semi (prefix)
Su Super
Th Thin
Ult Ultra (prefix)
Up Upright
X Extra (prefix)

In case you were wondering, ‘Nord’ and ‘Nord Italic’ were the first released weights of Roger Excoffon’s famous Antique Olive typeface family in 1960. They are wide and very bold cuts. Since a digital version of it was in the Adobe Library, it was added to the list when Adobe put it together. To my knowledge, this is the only occurrence.

And there is the PostScript Full Name which can be set with the custom parameter postscriptFullName, again in File > Font Info > Instances. Here, human-readability is key, since it is the complete name of the font as it is supposed to appear to the user, and is thus allowed to contain spaces. It should be ‘suitable for display in font menus’, according to Adobe.

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’.

Again, set postscriptFontName and postscriptFullName only if you really feel an uncontrollable inner urge to do so, and would run amok if you cannot do it yourself. Otherwise, just forget about it and let Glyphs set the PostScript names, since these are so easily calculated anyway.

Name Table Entries

If you know what you are doing, and nothing can scare you anymore, you can also do the whole Name Table yourself. You can set each entry of the Name Table for all sorts of languages in all sorts of encodings on all sorts of platforms. All you need to do, is go to File > Font Info > Instances, pick an instance, add the Name Table Entry custom parameter, and then use one of the following structures for its value:

  • <nameID>; <nameString>
    Example: 4; MyFont Bold Italic (Windows English Full Name)

In this case, <platformID> will be assumed as 3 (Windows), and successively, <encID> as 1 (Unicode), and <langID> as 0x0049 (Windows English).
Note: Glyphs versions before 2.5 add the space after the semicolon to the entry in the Name Table. This bug has been fixed. If you need to stay compatible with older app versions, we recommend you leave out the space character and start the name immediately after the semicolon.

  • <nameID> <platformID>; <nameString>
    Example: 4 1; MyFont Bold Italic (Mac English Full Name)

If <platformID> is specified as 1 (Mac), then both <encID> and <langID> will be assumed as 0 (Mac Roman and Mac English).

  • <nameID> <platformID> <encID> <langID>; <nameString>
    Example: 4 3 1 0x040C; MaFonte Gras Oblique (Windows French Full Name)

If <platformID> is specified as 1 (Mac), then <encID> can be a number between 0 and 32, and <langID> between 0 and 150 (see Macintosh platform-specific encoding and language IDs).
If <platformID> is specified as 3 (Windows), <encID> can be between 0 and 10, and <langID> must be a hex number below 0x8000 (see Windows platform-specific encoding and language IDs).

The <nameID> can be anything except 1, 2, 3, 5, and 6, which cannot be set through this parameter. The <platformID> can either be 1 for Macintosh or 3 for Windows. The optional <encID> and <langID> represent either Windows or Macintosh encoding and language IDs, depending on the <platformID>. They must be numbers between 0 and 65536, and can be entered in decimal, octal or hexadecimal form. The AFDKO Syntax specification stipulates that ‘decimal numbers must begin with a non-0 digit, octal numbers with a 0 digit, and hexadecimal numbers with a 0x prefix to numbers and hexadecimal letters a-f or A-F.’

Between you and me, the only two platforms that really matter are platform ID 1 Macintosh and platform ID 3 Windows, or actually, only ID 3 Windows, really. The other platform IDs 0 Unicode, 2 ISO and 4 Custom are hardly, if at all, in use. One of them, 2 ISO, has even become officially deprecated. Still, be careful if you set Name Table entries yourself, especially if you choose the long form of the parameter, because each platform has its own unfathomable list of encoding and language IDs. Haha, they are coming to take me away, hahaha. So, if you really want to do this yourself, you will find yourself surfing to this web page a lot: Microsoft OT Spec: The Naming Table, which lists all the encoding and language IDs your font-geek heart desires.

Here is a quick table of the Name Table entries you can set with <nameID>, except the ones marked with an asterisk. The links take you to the Microsoft spec page:

nameID Description
ID 0 Copyright string.
* ID 1 Family name. Cannot be set through the Name Table Entry parameter.
* ID 2 Style name. Cannot be set through the Name Table Entry parameter.
* ID 3 Unique identifier string. Applications can use this to identify the font. Often a combination of family and style name, version number and year. Cannot be set through the Name Table Entry parameter.
ID 4 Full font name. A complete, unique and human readable name of the font. Used by Windows. Often a combination of family and style name.
* ID 5 Version string. Release and version information from the font vendor. Usually the word ‘Version’ followed by the version number. Cannot be set through the Name Table Entry parameter, use the versionString parameter instead.
* ID 6 PostScript full name. Cannot be set through the Name Table Entry parameter, use postscriptFontName parameter instead.
ID 7 Trademark string. Optional, only necessary if you registered your font as a trademark.
ID 8 Manufacturer name.
ID 9 Designer name.
ID 10 Description. Arbitrary text.
ID 11 URL of Vendor. Don’t forget the URL protocol, i.e., start with http:// etc.
ID 12 URL of Designer. Don’t forget the URL protocol, i.e., start with http:// etc.
ID 13 License Description. A 1- or 2-sentence summary of what the user may or may not do with the font, e.g., may install on x devices and must not resell.
ID 14 License Info URL. Link to web page containing the full text of the license agreement.
ID 16 Preferred family name. Only set if different from ID 1.
ID 17 Preferred subfamily name. Only set if different from ID 2.
ID 18 Compatible full name. Macintosh only. Only set if different from ID 4
ID 19 Sample text. Some apps display this when previewing a font.
ID 20 PostScript CID findfont name. Officially deprecated, but still in use in CJK fonts.
ID 21 WWS family name.
ID 22 WWS subfamily name.
ID 23 Light background palette name. Reserved for COLR/CMAP color fonts.
ID 24 Dark background palette name. Reserved for COLR/CMAP color fonts.
ID 25 Variations PostScript name prefix. Reserved for variable fonts.

For most of these entries, there are better ways to set them, usually a text entry field in the UI or a dedicated custom parameter. And if you do, you can usually get away by setting the Windows name only. In other words use the short form of the parameter <nameID>; <nameString> and you’re done.

And again, only do this if for some reason the Name Table produced by Glyphs does not work for you, and if you know what you are doing. Setting them yourself just for the sake of doing it yourself will likely break something.

Many thanks to Rob McKaughan from Microsoft for providing much of the information explained in this tutorial. Some passages are quoting Rob directly.

Update 2017-12-17: Fixed typos, added an example for the preferredFamilyName parameter.
Update 2017-12-17: Added paragraph about Antique Olive Nord. Merci bien, Jean François Porchez! Added some infos about Name Table Entries and PostScript Names in EOTs. Thank you, Phil Garnham!