You'll need: FontCreator (Windows and macOS), and a font (or several fonts) you intend to ship as one family.
Font family settings are what tell every application that your fonts belong together — and which one to pick when a user clicks Bold or Italic. Get them right and your styles link cleanly in Microsoft Word, Adobe Illustrator, and the macOS Font Book. Get them wrong and the same fonts scatter into a dozen unrelated entries, or fake-bold the wrong weight. This page of the font editor's tutorials shows how to name and link a family so it behaves the way users expect, whether that family has four styles or twenty-four.
Windows ships with several font families (typefaces) that contain far more than four fonts. Calibri contains 6 fonts, Segoe UI comes with 12, and Sitka is king with 24. The trick to making a large family work is straightforward, but you have to be consistent.
The two family models: RIBBI and the typographic family
There are two different naming systems baked into every OpenType font, and a well-built family uses both at once.
The four-style RIBBI family. RIBBI stands for Regular, Italic, Bold, Bold Italic — the four styles older software can link together automatically. These four fonts use the Font Family and Font Subfamily name fields (name IDs 1 and 2). Older software, including Microsoft Office on Windows, links styles using this combination: a single Font Family name plus a Font Subfamily of Regular, Italic, Bold, or Bold Italic, paired with the Bold and Italic style-link flags.
The typographic family (name IDs 16 and 17). Because the RIBBI model only has room for four styles, anything beyond those four needs the typographic family fields: Typographic Family (name ID 16) and Typographic Subfamily (name ID 17). Modern software — including Adobe Illustrator and Microsoft Office on Mac — groups styles using these fields. They let an application present every weight and width in one menu, with all the named styles underneath.
The rule that ties it together: all fonts in the family must share the same Typographic Family name. The four common fonts (Regular, Italic, Bold, Bold Italic) leave the Typographic Family and Typographic Subfamily fields empty, so they fall back to Font Family and Font Subfamily. Every other font fills in its own Typographic Subfamily (for example "Black Italic" or "Condensed Light"), while the Font Family field groups those extra fonts based on their Width and Weight.
a 10-font "GreatFace" family laid out in a table, showing Font Family, Font Subfamily, Typographic Family, Typographic Subfamily, Weight, and Width for each style.
Where the settings live in FontCreator
All of these settings and flags are modified through the Font Properties dialog. Open it from the Format menu, then Font Properties (or press Ctrl+F4). The fields are spread across three tabs.
Identification tab
- Font Family
- Font Subfamily
- Width
- Weight
- Bold checkbox
- Italic checkbox
- Italic Angle
The Width and Weight values are what FontCreator and other applications use to group and sort the extra fonts in a large family, so set them deliberately for every style.
the Identification tab of the Font Properties dialog for the GreatFace Black Italic font.
Extended tab
- Typographic Family
- Typographic Subfamily
If the Typographic Family and Typographic Subfamily fields are empty, the values from Font Family and Font Subfamily are used. This is exactly why your four RIBBI styles can leave them blank.
the Extended tab of the Font Properties dialog showing the Typographic Family and Typographic Subfamily fields.
Characteristics tab
- PANOSE Weight
- PANOSE Proportion
the Characteristics tab of the Font Properties dialog showing the PANOSE Weight and Proportion settings.
> Watch out: Some versions of Windows and Word automatically add fake bold to any font with a weight set lower than 250 — for example Thin or Extra-light (Ultra-light). It is better to avoid these very low weight values, or to test carefully, so users don't end up with a synthesized bold over your delicate weight.
> Tip: Keep one master spreadsheet (or just a notes file) of your intended Font Family, Subfamily, Typographic Family, Typographic Subfamily, Weight, and Width for every style before you start filling in dialogs. Consistency across files is the whole job; a reference list makes mistakes obvious.
Family settings and variable fonts
A variable font reaches the same goal as a static family — many styles under one family name — but it does it inside a single file. The naming model above still applies, and two extra concepts connect the two worlds.
Named instances are the variable-font equivalent of the styles in a static family. Each named instance (for example "Light", "Regular", "Bold", "Condensed Black") is a fixed point in the font's design space that an application can offer to the user by name. For those names to slot cleanly into application menus, every instance shares the Typographic Family name of the font, and each instance supplies its own subfamily name — exactly the same Typographic Family / Typographic Subfamily logic the static family uses. Get this right and a variable font's instances appear in the style menu just like the members of a static family.
STAT axis values describe where each style sits along each axis. The STAT (Style Attributes) table tells applications how to label and order the styles along their axes — for example which Weight value is "Regular" and which is "Bold", which Width value is "Condensed". STAT is what lets an application present a coherent style menu and pick a sensible default. Keep your axis value names consistent with the subfamily names you used for the named instances, so the two agree on what each style is called.
The takeaway: the RIBBI and typographic naming you set up for a static family is the same naming that makes a variable font's named instances and STAT axis values behave. When you also export static styles from a variable font, those exported files inherit this naming, so a single, consistent naming scheme covers the variable file and every static cut you ship from it.
> Note: If you are building a variable font, each named instance also needs correct naming so applications can present the instances properly. See Named Instances & Static Export for how the instance names and STAT axis values relate to the family settings described here.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Bold or Italic button picks the wrong file (or nothing) | Style-link flags or RIBBI subfamily names inconsistent | On the Identification tab, confirm the Bold/Italic checkboxes and the Font Subfamily match the actual style |
| Extra weights show up as separate, unrelated families | Typographic Family name differs between files | Make the Typographic Family identical in every font of the family (Extended tab) |
| A thin weight renders artificially bold | Weight set below 250 triggers fake bold in some apps | Raise the weight value or test in the target application |
| Family looks correct on Mac but scatters on Windows (or vice versa) | One naming model filled in but not the other | Fill in both RIBBI fields (IDs 1/2) and typographic fields (IDs 16/17) consistently |
Frequently asked questions
Do I have to fill in Typographic Family and Subfamily for every font? No. The four RIBBI styles (Regular, Italic, Bold, Bold Italic) should leave them empty so they fall back to Font Family and Font Subfamily. Every font beyond those four should fill them in, all sharing the same Typographic Family name.
What's the difference between Font Family and Typographic Family? Font Family (name ID 1) is part of the older four-style RIBBI model that older Windows software uses to link styles. Typographic Family (name ID 16) is the modern field that lets applications group an unlimited number of styles under one family heading.
Why do my extra styles need a Weight and Width set? For families larger than four fonts, the extra fonts are grouped and ordered by their Weight and Width values, and each gets a Font Family name derived from them. Setting these deliberately keeps the family menu sorted correctly.
My family has exactly four styles — do I need the typographic fields at all? A clean RIBBI family can work with just Font Family and Font Subfamily plus the style-link flags. Filling in the typographic fields too does no harm and is good insurance for modern applications.
What to read next
- Named Instances & Static Export — how named instances and STAT axis values relate to these family settings.
- Font Metrics – Vertical Line Spacing — getting consistent line spacing across every style in the family.
