It is easy to extend Glyphs: tap into the realm of existing scripts and plug-ins, or even write your own extension. It’s easier than you may think.

Basically there are two ways of extending the functionality of Glyphs: with scripts and with plug-ins. Both may require additional installations called modules. So let’s first get our Glyphs prepared, so you can extend it any way you want it. Don’t worry, this part you only have to do once.

Modules

Go to Window > Plugin Manager to open the Plugin Manager. This is the place where we install and uninstall all our extensions. Many scripts require Vanilla and pretty much all extensions need Python 3, so I would definitely recommend to install those:

While you are at it, you can also install the other modules listed there. True, relatively few extensions need FontTools and RoboFab, but it doesn’t hurt to have them, and what’s done is done.

Preferences

In Glyphs > Preferences > Addons, go to Python version pop-up menu, and make sure a Python version marked ‘(Glyphs)’ is selected:

In any event, after installation of any of these modules and setting the preferences, we recommend to restart the app, so all changes can take effect.

Scripts

Typically, scripts are small pieces of Python code that do one or two particular things well. They are stored in text files with a .py ending in a special folder called Scripts inside of Glyphs’ Applications Support folder, somewhere deep in the guts of the macOS Library. Glyphs will load and display all scripts in the Script menu. The submenus in that menu replicate the subfolder structure of that Scripts folder.

Scripts are quick and easy to write. Even if you have never coded before, you can learn basic scripting in one afternoon. They are also easy to install and their installation does not require a restart of the app.

Installing scripts: Plugin Manager

There are two ways of installing scripts. First, with an easy one-click install through Window > Plugin Manager > Scripts. Just browse through the available script collections, and pick the ones you want:

After that, you can reload the Script menu by holding down the Option key and simultaneously choosing Script > Reload Scripts (Cmd-Opt-Shift-Y). And voilà: next time you open the Script menu, the newly installed script collection is available already:

Here is the takeaway: script collections installed through the Plugin Manager (as described above) are kept up to date automatically. Every time you start Glyphs, and your Mac is connected to the internet, it will check if you have the latest version and update your installation if you haven’t done that already.

Manually installing scripts

The second way of installing scripts is by manually placing them inside the Scripts folder. The quickest way to access that folder, you guessed it, is to run Script > Open Scripts Folder (Cmd-Shift-Y). You can organize script files in subfolders, which will appear as submenus in the Script menu. Once you are done, do not forget to hold down the Option key again and choose Script > Reload Scripts (Cmd-Opt-Shift-Y).

Needless to say, manually installed scripts cannot be kept up to date automatically. Instead, you will have to manage them yourself.

Running scripts

Run scripts by simply choosing them from the Script menu. If you are not sure what a script does, hold your mouse over its menu entry for a second, and a tooltip will appear, describing what the script will do:

If it looks like the script has not done anything, the script may have run into an error. In that case, look in the Macro Window (Window > Macro Panel, Cmd-Opt-M) for error messages. They may give you a clue as to what went wrong. If you find a message that says something like this:

ModuleNotFoundError: No module named 'vanilla'

… the script requires something called a module. See the section called ‘Modules’ further above.

Plug-ins

With plug-ins, coders can dig deeper into the ecosystem of Glyphs, and do more advanced stuff. Though most plug-ins will show up in Filter and View, they can appear in any menu or even show up as palette in the right sidebar. Plug-ins are a bit more challenging to make still no biggie though, and different from scripts, they require a restart after installation or update.

Installing plug-ins through the Plugin Manager

Similar to scripts, you can install plug-ins with a single click in Window > Plugin Manager. Simply pick the Plugins section, browse through the plug-ins, and click on the Install button to install it. Or, if it is already installed, click on the Remove button to, well, you guessed it: remove it. That’s it.

Manually installing plug-ins

Commercial third-party plug-ins like Tim Ahrens’ essential RMX Tools (a.k.a. ‘Font Remix Tools’), the amazing LetterInk, or Makkuk’s LayerWhale for recording your design process, or one of Mark Frömberg’s many cool plug-ins: they come with their own instructions. Usually, you can simply double click the plug-in file, and Glyphs will ask you if you want to install it:

Simply confirm the dialog by pressing Install, then restart the app, and the plug-in will be active and available. You can find a selection of third-party plug-ins on the Resources page.

Show your love

Like a script or plug-in? Why not treat the developer to a coffee?

Almost all of the scripts and plug-ins in the Plugin Manager are available for free. Some developers, however, have donation links next to the URLs of their most popular items in the Plugin Manager. A click on the icon takes you to their micropayment page:

Consider how much better an extension made your life and show your appreciation. 💝

Advanced options

There are more ways to customize your experience of extending Glyphs, especially if you need to manage foundry-specific installations. In any event, this chapter is for specific environments and advanced Terminal acrobats only. So do not worry if the following does not make any sense to you, because it probably does not apply to you.

Your own Python 3 installation

You can brew your own Python 3 installation and use it within Glyphs. Simply pick your home-made Python from the pop-up menu in Glyphs > Preferences > Addons > Python:

Then restart Glyphs, and you are all set.

Wait, not quite. There actually is one more thing. If you use a different Python than the one offered to you in Plugin Manager, you are lacking an additional Python module called pyobjc. Try this in Terminal:

pip3 install pyobjc

And now it should work. You may need to restart the app once more.

Your own Plugin Manager content

Let’s say your foundry has custom scripts, plug-ins, and/or modules that need to be made available to everyone in the company. You have two options: either you publish them under an open-source license on GitHub and let us know about it. Then we will add them to our Glyphs Packages repository on GitHub, and a minute later, they are part of the Plugin Manager.

Or, especially if it is proprietary or top-secret code that cannot be published, you can set up your own packages list! It is easy: Go to Glyphs > Preferences > Addons again, and in the Alternate Plugin Repos field, add the URL for a publicly reachable .plist file that contains the scripts, plug-ins and modules you want to distribute to your co-workers.

All you need to do is set up and maintain that .plist file, and make your colleagues enter that URL in that field in Glyphs > Preferences > Addons. That’s it. Next time they open Window > Plugin Manager, they can access the additional extensions.

Your own scripts and plug-ins

Have not found that script or plug-in that fits your project? Why not write your own?

In case you have not coded before, let me tell you that Python is a great first scripting language. You can get started in an afternoon or two. No kidding. Read through the Scripting Glyphs tutorials. The first three are super-easy. After that, admittedly, it does get a little challenging. But you know what, others have done it before, and once you get the hang of it, it is hard to stop.

Once you are ready, you can continue with writing plug-ins. That will take you one step further, and you’ll feel so much more powerful.

Update 2020-10-20: Completed unfinished sentences (thanks Nathalie).

Of course you can type all your feature code yourself. But you don’t have to. Tokens help you automate your feature code in a smart way.

Add dynamic feature code with tokens. Syntactically, tokens are pieces of code that follow a $ dollar sign. You can use tokens for two purposes: interpolated number values and glyph class predicates for collecting glyph names.

Number values

First, you can use the token syntax for a number value, sometimes sloppily dubbed ‘number token’. You define number values in File > Font Info > Masters > Number Values. In a nutshell, number values are variables that interpolate. For instance, in Masters, you define a number value called pad as 50 in the light master, and 5 in the bold master:

In your feature code, you can add a kern (Kerning) feature with something like this:

pos @L @A $pad;

And in the resulting GPOS feature code, the respective interpolated value of pad would get inserted in the token’s place. Nice. But what if you need something more complex. Let’s add a cpsp (Capital Spacing) feature with a positioning rule like this:

pos @brackets <$pad 0 ${pad*2} 0>;

Yes, that’s right. Inside a ${...} structure, you can add calculations. This is very useful for all kinds of manual GPOS code. There is a good example in the Positioning with Number Values tutorial.

Glyph class predicates

Glyph class predicates, also referred to as ‘class tokens’ or ‘predicate tokens’, have a $[...] structure, and it will dynamically expand to a space-separated list of glyph names, useful for class definitions in your OpenType feature code. Between the square brackets you put Apple’s NSPredicate code for filtering glyphs. This works very much like a smart filter in Font view (Cmd-Opt-1). In fact, under the hood, smart filters actually use NSPredicate.

One example:

sub [ $[case==smallCaps] ] slash' by slash.sc;

The structure $[case==smallCaps] consists of the object case, a comparison operator ==, and a value smallCaps. In this special case, the value is one of these predefined constants: noCase, upper, lower, smallCaps, minor, and other. The constants correspond with the options in the glyph info accessible through Edit > Info for Selection. So the token expands to a space-separated list of glyph names that match this comparison, for which the predicate evaluates as true: in this case, all glyphs where the case is equal to small cap. In other words, we will get a.sc b.sc c.sc d.sc and so on. So, the whole line expands to:

sub [ a.sc b.sc c.sc d.sc ] slash' by slash.sc;

… and very likely many, many more glyphs than just those four. The best thing is that it does that dynamically, so you do not need to collect all small caps glyphs yourself, or worry about subsetting, because that feature code is updated automatically at all times. And you can insert that token anywhere in your Prefix, Classes or Features code. To verify a predicate token, Opt-click on the token code, and a glyph list will pop up:

The overview is valid for the current set of exporting glyphs, and will be shown with glyphs of the currently selected master.

Okay, so let’s recapitulate. A predicate token starts with a dollar sign $, followed by square brackets [], inside which we put an object comparison. An object comparison is a logical expression that compares a specific property of each exporting glyph (the ‘predicate object’) to a value, usually a number or a string. For the comparison, it uses one of the available NSPredicate comparison operators. Each glyph for which the expression turns out to be true will make it into the eventual list of glyph names.

Predicate objects

In principle, any attribute of the GSGlyph object is a valid object for a predicate expression. You can run print("\n".join(dir(GSGlyph))) in the Macro window, and start fishing for possible predicates in the output. Or look in the GSGlyph documentation on docu.glyphsapp.com.

Boolean objects

A boolean glyph property can evaluate to true or false, or in an alternative spelling, yes or no. So, you can compare it like $[hasComponents == true]. Available are the following glyph properties:

hasAlignedWidth
hasAnnotations
hasComponents
hasCorners
hasCustomGlyphInfo
hasHints
hasPostScriptHints
hasSpecialLayers
hasTrueTypeHints
isAligned
isAppleColorGlyph
isColorGlyph
isCornerGlyph
isHangulKeyGlyph
isSVGColorGlyph
isSmartGlyph
justLocked
locked
mastersCompatible
outlineHasChanges

Number objects

Numbers can be integers or floating point numbers. They can be compared to other numbers with the usual mathematical operators, for instance $[countOfUnicodes > 0]. Available are the following glyph properties:

case
changeCount
colorIndex
countOfLayers
countOfPartsSettings
countOfTags
countOfUnicodes
direction

Yes, case technically is an integer, but you would usually compare it to the constants I mentioned above already.

Many of the number values you really care about are attached to the layers, not the glyphs, e.g. layer0.width, layer0.LSB, etc. For details on which layer properties are available, take a look at the GSLayer documentation on docu.glyphsapp.com.

String objects

Strings are pieces of text. You can compare them to a reference string like this: $[name like "*.ss01*"]. That reference string must be typed between dumb quotes "..." and can contain jokers like *. The following glyph properties are available as strings:

baseString
bottomKerningGroup
bottomMetricsKey
category
charName
charString
description
glyphDataEntryString
lastChange
leftKerningGroup
leftKerningKey
leftMetricsKey
name
note
production
productionName
rightKerningGroup
rightKerningKey
rightMetricsKey
script
sortName
sortNameKeep
string
subCategory
topKerningGroup
topMetricsKey
unicode
unicodeChar
unicodeString
vertWidthMetricsKey
widthMetricsKey

Complex objects

You would usually access their attributes, like layer0.width.

glyphInfo 
layer0
userData

The only one of those that really makes sense is layer0 which represents the first layer of the glyph, i.e., the first master. You can access its GSLayer properties with the familiar dot notation. You can even drill down in the object tree and do stuff like $[layer0.anchors.top.y > 600].

Almost all glyphInfo objects like unicode, script or subCategory are accessible directly as glyph attributes, so you will not need glyphInfo often, except maybe for glyphInfo.accents, but I would not know what that would make sense for. And userData can be anything, but it is only really accessible through scripting. So it will only make sense in very, very specific circumstances.

Comparison operators and compounds

According to NSPredicate documentation, you can use the following comparison operators with as much whitespace as you like, and in lowercase or uppercase, whichever way you prefer.

• BEGINSWITH The object begins with the value, e.g., $[name beginswith "x"]
• CONTAINS The object contains the value, e.g., $[name contains ".alt"]
• ENDSWITH The object ends with the value, e.g., $[name endswith ".sc"]
• LIKE The object equals the value: ? and are allowed as wildcard characters, where ? matches 1 character and matches 0 or more characters. E.g., $[name like "?.sc" or name like "*.sc*"]
• MATCHES The object equals the right hand expression using a regex-style comparison according to ICU v3. This only makes sense for regex nerds. If you do not know what regular expressions are, ignore this.
• =, == The object is equal to the value. $[layer0.LSB = 0]
• >=, => The object is greater than or equal to the value. $[layer0.RSB >= 0]
• <=, =< The object is less than or equal to the value. $[layer0.countOfPaths <= 3]
• > The object is greater than the value: $[countOfUnicodes > 1]
• < The object is less than the value. $[layer0.LSB < 0]
• !=, <> The object is not equal to the value. $[layer0.countOfHints != 0]
• BETWEEN The object is between, or equal to either of, two comma-separated values between curly braces. E.g., $[layer0.width between {400,600}] or $[name between {"V","Z"}]
• IN The object must appear in the collection of comma-separated values between curly braces. $[layer0.width in {200, 400, 600}] (Technically, IN is an aggregation, but I’ll add it here anyway.)

Compounds are logical concatenations of multiple comparisons. You may know them from coding:

• AND, && Logical AND, combines two or more comparisons. The whole expression evaluates as true only if all comparisons are true. E.g., $[layer0.LSB < 0 and layer0.RSB < 0]
• OR, || Logical OR, combines two or more comparisons. The whole expression evaluates as true if at least one comparison is true. E.g., $[name endswith "superior" or name beginswith "ord"]
• NOT, ! Logical NOT operator, negates the comparison that follows. The tricky thing is to prefix an existing predicate to negate it. E.g., $[not layer0.width in {200, 400, 600}] gets you all glyphs for which the first layer width is not one of the three numbers.

Sample code

To give you a little inspiration, here is a handy cheat sheet for predicate tokens:

$[name endswith '.sc'] # will expand to all glyph names that end in ".sc"
$[layer0.width < 500] # layer0 = first master
$[layers.count > 1] # compare numbers with: == != <= >= < >
$[direction == 2] # 0=LTR, 1=BiDi, 2=RTL
$[colorIndex == 5]
$[case == smallCaps] # predefined constants: noCase, upper, lower, smallCaps, minor, other
$[name matches "S|s.*"] # "matches": regular expression
$[leftMetricsKey like "*"] # "like": wildcard search
$[name like "*e*"] # e anywhere in the glyph name
$[script like "latin"]
$[category like "Separator"]
$[leftKerningGroup like "H"]
$[rightKerningGroup like "L"]
$[unicode beginswith "03"] # beginswith, endswith, contains
$[note contains "love it"] # glyph note
$[countOfUnicodes > 1]
$[countOfLayers > 1]
$[subCategory like "Arrow"]
$[hasHints == 0] # boolean: false, no, 0 versus true, yes, 1
$[isColorGlyph == true]
$[hasComponents == true and script == "latin"] # connect multiple conditions with ORor AND
$[hasTrueTypeHints == false]
$[hasAlignedWidth == true]
$[hasPostScriptHints == true]
$[hasAnnotations == true]
$[hasCorners == true] # corners = corner components
$[hasSpecialLayers == yes] # special layers = color, brace and bracket layers
$[isHangulKeyGlyph == no]

Whoa, that was something for the geeks among us, which leaves me really curious what you are going to use this for. Have fun.

Now that you’ve finished the upright of your font, you’re confronted with a severe case of italic angst. An easy way out is an oblique. But in fact, even in a real italic, the caps and small caps will still need to be obliqued. Quickly find out the best method to slant your letterforms.

A good first start for creating an oblique is the Transform filter, one of the pre-installed filters that come with the standard installation of Glyphs. Your mileage may vary, but good oblique angles are usually somewhere between 6 and 12 degrees.

Choose Path > Transformations, and do not translate (i.e., leave the values at zero), do not scale (leave at 100%). But do pick an Origin: As best practice, we recommend picking half x-height because this is also what Glyphs uses for calculating italic sidebearings. That means that you can use metrics keys with cross references between LSBs and RSBs. Don’t know what that means? Take a peek at the Spacing tutorial.

Slanting vs. cursivying

Then pick an angle and a mode of knocking your design into an italic angle. The Transform filter offers two possibilities: The first option, Slant is a simple geometric shear as you probably know it from your favorite vector application. The problem is that you will lose the weight of verticals through the distortion while your horizontals stay keep their weight. Not good.

The second option, Cursivy (click on the word Slant to switch to Cursivy), tries to counteract the distortion of curves. Here is a comparison:

But how does Cursivy know what to do? It simply makes use of your standard stems for calculating curve corrections. So do make sure you enter appropriate, average horizontal and vertical stem values in File > Font Info > Masters (Cmd-I):

Since the standard stems entered in File > Font Info > Masters determine the curve correction, you can influence the amount of correction by experimenting with different stem values. Or, even better, put the cursivied version in the foreground, and a merely slanted version in the background. Then interpolate between the two by using the slider in Path > Interpolate with Background:

This can be especially useful when the counter appears overcorrected and too pointy.

Fixing extremum points

Also, the positions of your path extrema on curves are not adjusted accordingly. This makes vertical hints impossible and some operations such as interpolation or nudging pretty difficult. If you do not care about hinting, and you are not interpolating, or relying on nudging, well, you do not need to care about your extremes. You can keep your paths like they are in this sample on the left:

However, if you need to hint your vertical stems, and plan to interpolate, it is a good idea to fix the extremes, like in this sample on the right. You can use Paths > Add Extremes, or Shift-click a curve segment with your Draw tool (P) to insert a node at the nearest extremum. To get rid of the slanted former extremums, select them one by one, and press the Delete key. Glyphs will do its best to reconstruct the curve segment as well as possible, but you may still need to adjust curvatures here and there with the Fit Curve palette (Cmd-Opt-P).

Toshi Omagari wrote a script called Path > Delete Diagonal Nodes Between Extremes that speeds up the process by trying to remove all those diagonal extremums, on all masters, at once. You can install this script, along with lots of others, by installing Toshi’s scripts from Window > Plugin Manager.

Correcting straight stems

But be careful: While Cursivy can do a pretty good job with your bowls, straight stems will still simply be slanted. But the higher your angle, the more extreme your slanting distortion, i.e., the more your vertical and right-leaning stems will thin out, and the more your left-leaning stems will bolden. So be prepared to adjust your stems a little bit afterwards. For example, slanting a vertical stem 30 degrees will thin it out by approximately 13 percent. But if the stem used to be 30 degrees left-slanted, and now is slanted into the upright, its stem weight will gain no less than 16 percent:

Needless to say, 30 degrees would be a very extreme angle. I chose it for this example to make the stem distortion more visible.

Useful scripts and plug-ins

• Filter > Italic Extremes: plug-in for switching extremum points between slanted and upright.
• View > Show Italic: plug-in that shows the corresponding glyph from the italic in a roman and vice versa, if roman and italic are in two ifferent files and share the same family name. Also indicates if the glyph heights are the same.

• View > Show Next Font: similar to the above, but with whatever is the second font.
• The mekkablue scripts have a submenu called Compare Frontmost Fonts, which are great for comparing font info, glyph sets, glyph heights and widths, etc., between the upright and the italic.
• The script collections of Daniel Gamage and Guido Ferreyra have scripts for comparing and syncing roman and italic fonts.

Update 2015-07-30: updated screenshot for Glyphs 2.
Update 2016-12-03: partial rewrite. Updated and added screenshots, added slant distortion, extremes, titles and illustrations.
Update 2016-12-05: Added Pro Tip, moved note about slanting origin to where it belongs.
Update 2022-08-01: updated title, related articles, minor formatting.
Update 2023-04-20: Added useful scripts & plug-ins, minor formatting. Updated link to Toshi’s scripts.
Update 2023-07-11: Recreated a paragraph about Path > Transformations that got lost a year ago. Added Italic Extremes plug-in.

Glyphs offers a smart way to add your own contextual kerning in a separate OpenType feature. Warning: rather advanced level.

So, you have optimized the sidebearings of your glyphs, then added kerning pairs where necessary. But still, you come across some cases where the white space between the letters still isn’t optimal in certain glyph triplets.

There are some usual suspects. For instance, when a glyph with a negative RSB is followed by a space and a glyph with a negative LSB, e.g. f space T, f space V and f space W. In these cases, the word space gets eaten up by the surrounding negative sidebearings. To a reader, the result may look like a forgotten space. So the white space needs to be increased a bit.

Or take the L quoteright A triplet, where the apostrophe (we assume quoteright will be used for the apostrophe) usually ends up too close to the A and too far away from the L. We need to fix that:

Typical triplets usually include space, punctuation and quotes, like period quoteright space. Also, it’s not necessarily always triplets, it can be quadruplets too, like f period space V etc. Of course, the mileage varies greatly depending on the design. The only way to find out which combinations you need is to have long texts set in your typeface, preferably with lots of punctuation in different languages, and look for spots where the white space seems messed up.

Contextual kerning lookup

Enter the kern feature. Glyphs actually creates it automatically for you at export time, using all the kerning pairs you created. Now, you can add some extra kerning on top of the existing kerning by adding a separate lookup to the kern feature. How? Well add a feature and call it kern:

To do that, go into File > Font Info > Features and add a new feature called kern by clicking on the plus button next to features in the left sidebar of the window. In the code, you start by adding the Automatic Code Placeholder, best through the Snippets menu in the bottom right of the Features window:

This will add the following bit of code:

# Automatic Code

This represents the automatically generated kern feature, derived from whatever you have in Window > Kerning. So, this way, you can tell Glyphs to add the code after or before the automatic code. Typically, you want it afterwards, so this placeholder is the first line of your code.

Now let’s assume we want to fix the triplets containing f space as well as the L quoteright A combo, which is important for languages like French and Italian. Okay, here’s what we put into kern:

# Automatic Code
pos f' 50 space [T V W Y];
pos L' -40 quoteright' 80 [A Aacute Agrave];

The first line looks for an f followed by a word space, but only before T, V, W or Y. Only in that case will the f space pair get an additional white space of 50 units.

The second line looks for an L, followed by an apostrophe and an A, with or without an accent. In that case, the apostrophe is shoved into the L by 40 units, while the space between the apostrophe and the A is increased by 80 units, effectively moving the apostrophe closer to the L, and increasing the space between L and A, preventing them from colliding with each other.

This is called a chaining contextual positioning with a marked subrun. If you’re familiar with AFDKO feature coding, the structure of the positioning rules may surprise you. The kerning values are not placed at the end of the line, but right between the names of the affected glyphs. Also, as with any contextual rule, some glyphs need to be marked with a ‘dumb quote’. In this case, we need to mark every glyph that is followed by a kerning value.

Interpolating kerning values

Ever since Glyphs 3.1.1, you can interpolate numbers in the feature code. The way this works is simple. After any kerning value, you specify additional coordinates in the designspace between parentheses, e.g., (wdth:150), followed by the kerning value at that designspace coordinate. Look at this:

# Automatic Code
pos f' 50 (wdth:150) 95 space [T V W Y];

The above piece of code means that, in the origin master, f will get an extra 50 units of space if it appears before space followed by any of the glyphs in [T V W Y]. In an extended style, or in other words, at designspace coordinate (wdth:150), that same extra space is 95 instead of 50. And the best thing: along the width axis, this value will interpolate for every instance, and even variable fonts. Pretty cool.

Let’s take it a notch further. What if you have multiple axes? Again, easy. You just specify multiple series of designspace coordinates with the kerning value in question. Like this:

# Automatic Code
pos f' 50 (wdth:150) 20 (wdth:150 wght:220) 70 (wdth:100 wght:220) 70 space [T V W Y];

If it makes things easier, you can also reformat like this:

# Automatic Code
pos f' 50 
  (wdth:150) 20
  (wdth:150 wght:220) 70
  (wdth:100 wght:220) 70
space [T V W Y];

It’s the same thing.

Technicalities

Under the hood, Glyphs adds a lookup called kernCustom to the end of the kern feature:

The sequence of marked glyphs, the ‘marked subrun’, must not be interrupted by unmarked glyphs. That means you can have x x' x' x' x but not x' x' x x' x'. Otherwise you get this error: ‘Unsupported contextual GPOS target sequence: only one run of marked glyphs is supported’.

And you cannot mix regular kerning with contextual kerning, because they are two different lookup types. If you do mix them, you will receive this error: ‘Lookup type different from previous rules in this lookup block’.

Drawbacks

Since our lookup is feature code that gets injected into every instance at export time, the contextual kerning does not interpolate. But that is not much of a biggie, usually. Remember that the additional contextual kerning does not replace the other kerning pairs you already have, but it gets added on top of them.

Except for regular, non-contextual kerning, Glyphs does not give you GPOS preview in the edit view. That’s bad luck for us contextual kerners. But there’s an easy workaround: Just keep exporting your fonts to the Adobe Fonts folder and you can test your kerning triplets, quadruplets and quintuplets in InDesign right away. After all, this is where it counts because it’s where people are going to use it.

SAMPLE FONT: PLAYFAIR DISPLAY, COURTESY OF CLAUS EGGERS SØRENSEN.

Update 2020-01-08: corrected Font Info menu entry (thx @Galifer).
Update 2020-03-30: corrected typo.
Update 2022-07-25: updated title, related articles, minor formatting.
Update 2023-04-26: added Interpolating kerning values, and the automatic-code placeholder.

In Catalonia, you will sometimes see a dot in mid air between two L’s. Here is why, and how to implement it in your font.

Catalans type L·L (L–periodcentered–L) when they mean to type a punt volat between two L’s in order to indicate that it is an ela geminada, as opposed to a double L, which is pronounced differently.

Typographically, there are two things to consider. Firstly, there is no word space between the two L’s or l’s. In other words, it should still look like one word, not two. So, the extra distance caused by the insertion of the middot must not be too much. Secondly, the dot needs to appear in the optical center between the two L’s or l’s:

Type designers employ different solutions for this problem. Personally, I recommend a combination of the ‘spacing solution’ and the ‘Ldot solution’. But… not so fast, let’s go through the possible ways to solve the punt volat:

The kerning solution

There are type designers who prefer a pure kerning solution. For this, you’d simply kern the sequence L-periodcentered-L. Type Catalan words like COL·LEGI and paral·lel in your Edit tab, and kern it until you’re satisfied. You may also consider contextual kerning.

The good thing is that this works in language-agnostic typesetting environments, like Apple’s TextEdit and most other Cocoa apps. That is because the Mac text engine does not allow specifying the language and thus ignores the locl OpenType feature (Localized Forms, see below).

There are a few problems with this approach though:

• It doesn’t work when kerning is disabled or if the font is used in an environment where there is no kerning available.
• You may want to use the periodcentered for other purposes as well, e.g. to indicate syllables in a dictionary, and then you may run into problems with a word like ‘col·li·sion’.
• The default periodcentered may not be at the right height for this purpose.
• The periodcentered may not fit both uppercase and lowercase L’s (and small-cap L’s if you have small caps in your font), and you may have to resort to a bad compromise.

The spacing solution

Because of these issues, I recommend to solve the problem without kerning. To do this, build the following glyphs:

1. Lowercase: create a glyph called periodcentered.loclCAT containing the punt volat. Design it in such a way that it fits perfectly between two lowercase L’s.
2. Uppercase: repeat the process with periodcentered.loclCAT.case. The glyph should contain a punt volat that is optically centered between two uppercase L’s.
3. Smallcaps: if you have small capitals in your font, create a periodcentered.loclCAT.sc that centers optically between two small-cap L’s.

Important: do not kern, rather only use spacing for fitting the punts volats between the respective L’s. Exclude them from kerning completely, do not even set a kerning group.

‘What do those suffixes mean?’, I hear you ask. Easy, .case stands for Case-Sensitive Forms, an OpenType feature for shifting ‘punctuation marks […] up to a position that works better with all-capital sequences or sets of lining figures’, whereas locl is the four-letter code for the Localized Forms feature, which is intended to substitute default glyphs with ‘localized variant forms’. And the CAT part is the Language System Tag for Catalan.

And if you make use of this suffix, Glyphs can automatically add the localized mid dots to the Localized Forms feature. Go to File > Font Info > Features and press the Update button, and take a look in the locl feature. There should be a section that reads approximately like this:

lookup locl_latn_1 {
    script latn;
    language CAT;
    sub l periodcentered' l by periodcentered.loclCAT;
    sub L periodcentered' L by periodcentered.loclCAT.case;
} locl_latn_1;

The number (‘1’ in this example) may be different for you, depending on which other localizations you have in your font. The code means: only when (a) the language is set to Catalan, and (b) the periodcentered appears between two lowercase L glyphs, it will be replaced with the Catalan periodcentered.loclCAT; and with periodcentered.loclCAT.case between two uppercase L glyphs.

Many type designers consider this the best solution, mostly because it survives increased tracking, even though the space between the dot and the surrounding lowercase l’s should not increase as much as space between two letters. And it also works in environments where there is no kerning. Consider that, by default, kerning is off in Microsoft Word.

One downside is that it requires the users to set the language of the text. And another is that it will fail in language-agnostic environments. But if you feel like you can ignore the dictionary case mentioned above, you can copy the code to the calt (Contextual Alternates) feature:

Make sure you remove the script and language statements, because it wouldn’t be language-agnostic otherwise. And don’t forget to rename the lookup, e.g. to lookup CATALAN, because it would collide with the code in the locl feature. So, your calt code may end up looking like this:

lookup CATALAN {
    sub l periodcentered' l by periodcentered.loclCAT;
    sub L periodcentered' L by periodcentered.loclCAT.case;
} CATALAN;

If you also have small caps, insert a corresponding line for the .sc glyphs:

lookup CATALAN {
    sub l periodcentered' l by periodcentered.loclCAT;
    sub L periodcentered' L by periodcentered.loclCAT.case;
    sub l.sc periodcentered' l.sc by periodcentered.loclCAT.sc;
} CATALAN;

Alternate small-cap feature code

Alternatively, you can opt for an advanced feature code solution. Add additional smcp and c2sc entries after the autogenerated ones you already have. Disable automatic code generation for the new feature entries. Then add a lookup with the small-cap code in the first one (typically c2sc comes first):

lookup CATALANSC {
    sub l.sc periodcentered' l.sc by periodcentered.loclCAT.sc;
} CATALANSC;

… and the respective lookup call in the second one:

lookup CATALANSC;

So your small-cap features will end up looking like this:

Press the Compile button and see if the code checks out fine.

The ligature solution

Assuming you have L, l, and periodcentered in your font, add these ligatures, best via Glyph > Add Glyphs (Cmd-Shift-G):

• L_periodcentered_L.loclCAT
• l_periodcentered_l.loclCAT
• l_periodcentered_l.loclCAT.sc if you have small caps

Glyphs will then auto-generate the following code in a locl lookup:

script latn;
language CAT;
sub l periodcentered l by l_periodcentered_l.loclCAT;
sub L periodcentered L by L_periodcentered_L.loclCAT;

By now, I suppose you can tell the pros and cons. On the plus side, we have perfect control of our ela geminada. But it will fail in language-agnostic environments, and it will not work well with increased tracking. Therefore I do not recommend this solution. If, however, you do employ this solution, you can duplicate the code in calt, just like above, for language-agnostic environments.

The Ldot solution

Or, and especially if you care a lot about backwards compatibility, we can actually build the legacy glyphs Ldot and ldot and design them in such a way that they look great with a following upper or lowercase L.

Wait a minute: why ‘legacy’?

In an old 8-bit encoding from the eighties, there used to be a separate Ldot and ldot. They survive to this day as U+013F LATIN CAPITAL LETTER L WITH MIDDLE DOT and U+0140 LATIN SMALL LETTER L WITH MIDDLE DOT in Unicode. They are not supposed to be used anymore, because they are mere compatibility characters. And actually, chances are very low you will ever encounter them in texts typed in this century.

But hey, this only applies to people who produce texts with characters. We’re the font-making people, and on the glyph level, we can do what we want, as long as it looks good. So here we go:

When you create Ldot and ldot, Glyphs gives you a glyph with an L or l component and a periodcentered. Of course you can delete, replace or decompose the periodcentered component if you want to roll your own punt volat.

If you have the .loclCAT glyphs from the spacing solution above, it is best to simply insert them as components into Ldot. You can use the mekkablue script Build Ldot and ldot for this (see below). Or take matters in your own hands with this recipe in Glyph > Add Glyphs:

L+periodcentered.loclCAT.case=Ldot
l+periodcentered.loclCAT=ldot
l.sc+periodcentered.loclCAT.sc=ldot.sc

Again, if Glyphs finds all the involved glyphs your font, it will build this locl feature automatically for you:

script latn;
language CAT;
sub  l' periodcentered' l by ldot;
sub  L' periodcentered' L by Ldot;

Many type designers are not really happy with this solution, because it looks really stupid with increased tracking. Duh.

Combining multiple solutions

There is nothing wrong with combining multiple solutions, especially language-agnostic solutions with the localized solutions. This way you can maximize compatibility.

But if you have multiple locl solutions, which one will the automatic feature generator pick? Well, the spacing solution will take precedence over the ligature solution, and the ligature will take precedence over the Ldot solution. Of course, if you are not happy with the automatism or the precedence order, please feel free to disable the automatic generation for the locl feature, and type your own code.

We whole-heartedly recommend the spacing solution, and adding the Ldot’s for good measure.

Useful scripts

In the mekkablue scripts, there is:

• Build Glyphs > Build Ldot and ldot: The script assumes that you have the .loclCAT glyphs from the spacing solution, and will reset the Ldots in your font with it.

• Build Glyphs > Center punt volat: Will go through all your periodcentered.loclCAT glyphs you have in your font, find corresponding L’s for it, and adjust the spacing in such a way that the dot appears in the middle between them. It will not change the advance width of the punt volat.

And ta-daaa: Now, your font is ready for Catalan!

Update 2014-12-01: added Spacing and Ligature solutions, double underscore hack, and combining solutions; many small improvements.
Update 2016-02-19: updated screenshots for Glyphs 2.
Update 2016-10-16: Corrected long-standing typo in ela geminada (thx Joan Montané).
Update 2017-09-12: fixed typo.
Update 2019-10-25: fixed typos.
Update 2021-09-10: partial rewrite for Glyphs 3, useful scripts, new screenshots, removed double underscore hack.
Update 2022-08-11: updated title, related articles, minor formatting.
Update 2023-05-10: added Center punt volat script.

Corner components are pretty much like magic for creating serifs. And not only serifs.

Corner components are shapelets you can attach to corner nodes. Perfect for serifs, they also lend themselves for rounded corners or inktraps, and are a great way to keep these partial shapes in sync across many glyphs. Best of all, they interpolate and export in variable fonts. Take this n, for example:

All of the serifs are corner components, which, in Glyphs 3 and later, are represented as blue particles:

Build corner components

All we need for this is two new glyphs with special naming: A corner component must start with _corner and have an arbitrary dot suffix. The underscore at the beginning of the name ensures that the glyph will be created as non-exporting. Add two new glyphs, and call them, for example, _corner.leftSerif for the left serif, and _corner.rightSerif for the right serif. The best way to do this is invoking the menu command Glyph > Add Glyphs (Cmd-Shift-G), typing _corner.leftSerif _corner.rightSerif, and pressing the Generate button.

But let’s begin with drawing a serif. Our left serif could look like this:

As you can see, the serif is an open path that start vertically, winds counter-clockwise (just like your closed paths), and the last part is on the baseline. The final point in the bottom right needs to be a bit to the right in respect to the first point. The initial vertical movement and the final horizontal movement complement each other to a perpendicular shape corner.

There are also three anchors. You can add the default anchors left, right and origin with Glyph > Set Anchors (Cmd-U) or Set Anchors for all Masters (Cmd-Opt-U):

The origin anchor represents the corner of the host path (onto which the corner component will be injected later). If you do not have this anchor, you need to move the serif over the left sidebearing, and make sure it winds around the origin point (x=0, y=0), where the baseline meets the left sidebearing.

The left and right anchors are the pivotal points for optical adjustments on non-perpendicular corners. More about that later.

Add corner components

Now, how do we get our serifs to stick to our glyphs? Easy. Go to your glyph, made of paths and select a corner node, then right-click on it to open the drop-down menu, and select Add Corner Component:

In the dialog that follows, select _corner.leftSerif, and voilà, your serif gets injected into the path! Coolio.

For the other corners you can select and copy the corner, select the target node, and paste. Or add again through the context menu.

But, oops, what happened here:

Well, it is a left serif, and that is how a left serif fits on a right corner. But don’t despair, because you can select the malrotated serifs and mirror them with one of the mirror buttons in the Transformations panel:

Of course, that is only an option if the design of your serif lends itself to mirroring in the first place. If that is not the case, you may need a _corner.rightSerif, and arrange the anchors like this:

The right anchor is close to the end of the path, the left anchor on the initial segment. Again, take note of the path direction: counter-clockwise, like most other paths.

Diagonal stems

Corner on diagonal stems are adjusted automatically, by slanting the outermost segment of the corner component into the angle of the stem:

Your corner component was drawn perpendicularly, but the two segments in the corner of the v are not perpendicular. So the question is, which segment will the corner component align to, and which segment will it distort into. Glyphs often guesses right, but not always. In that case, you can adjust the alignment manually, with the four little buttons in the grey info box (Cmd-Shift-I):

• left arrow: alignment for left serifs or mirrored right serifs. The beginning of the corner component path gets slanted into the angle of the host path, the end of the path stays straight.
• right arrow: alignment for right serifs or mirrored left serifs. The end of the corner component path gets slanted into the angle of the host path, the beginning of the path stays straight
• double arrow: the corner component is fitted half way between incoming and outgoing path segment; best for inktraps. Bending will be done along both, the beginning and the end of the corner component path, along the three anchors, with the origin anchor as pivot.
• x: no alignment, the corner component is forced in as is. For special cases only, will typically give you funny results.

So, one side of the corner component will be aligned, the other will be bent into the diagonal. Can we control how? Yes, we can! With the position of the left or right anchor, respectively:

The anchor serves as pivotal point. Effectively, you get more optical correction the more you move the anchor away from the origin anchor. Your mileage may vary.

Scale corner components

With slab serifs, you can easily change the scale. Simply write another percentage for the horizontal or vertical scale. Or even better, place your cursor in the scale field, and use the up and down arrows on your keyboard to change the value. Add Shift for increments of 10, Cmd for increments of 100:

But you also see the problem we have here: the corner component gets distorted with a simple scale. The rounding changes its character, and bracketed serifs will suffer when you scale them. Bummer. We would need something like interpolation for a better result… wait… we can actually do just that. Read on.

Go back to your corner component. In the Layers panel, duplicate the master layer, then right click on the layer copy to bring up its context menu, and redefine it as Intermediate. Assuming that the master layer has a scale of 100% horizontally and 100% vertically, define the intermediate layer as 150% width and 100% height:

And now draw a widened serif, the way it is supposed to look like. Adjust the curvature accordingly, perhaps you want to keep a certain angle the same, whatever is required for your design. In my case, it is a bit more simple:

So now, when you enter a different scale percentage, the serif gets interpolated properly:

Or, add an Intermediate at 150% height, 100% width, and you can scale your serifs vertically without losing the serif thickness, e.g., in the classic example of the right serifs of a high-contrast V:

Inktraps

For inktraps, make sure that end points, handles and left & right anchors are aligned towards the origin anchor. Sounds complicated? Fair enough, here is a picture that says more than a thousand words:

I added guides for clarity. If you leave out left and right anchors, then the origin anchor will be the pivot. Experiment with the positions of points and anchors along the guides. Again, take note of the path direction. You see, the arrangement of points and anchors does not necessarily need to be vertical and horizontal. The relation between points and anchors is what counts.

For the next step, keep in mind that corner components also work on ‘extra nodes’, the predicted intersection points between two paths. This makes inktraps possible without removing overlaps. To do that, first make sure you turn on View > Show Nodes > Show Extra Nodes:

Select them by Shift-clicking each one of them. Then, again, add corner components from the context menu. Then, experiment with alignments and scales for each corner component:

And the best thing: you can still move the crossbar up and down, and keep your inktraps aligned properly!

Complex corner components

You can add any number of closed paths in a _corner glyph to compliment the open corner path. Finally, time for the long overdue return of the page curl:

Path directions of closed paths will be preserved when mirrored.

Tips

Sometimes, even corner components hit a ceiling in their flexibility. Then you need to decompose in order to make individual adjustments. Select one or more corner components by (Shift-)clicking on their blue line, then choose Decompose Corner Component from the context menu, and you are all set. See the Decompose Corner Components script below for batch decomposition.

You can navigate between _corner glyphs and the glyphs that contain them. Select a placed corner component and click on the little circled arrow in the grey info box, next to the name of the corner component, to open the _corner component:

While we’re here, click on the name directly to replace the corner component. Just like you would do with a regular component.

Inside a _corner glyph, you can choose Show all glyphs that use this glyph as a component from the context menu:

Access all corner components at once by repeatedly pressing Cmd-A for selecting all:

In this case, Select All cycles through: all paths, all paths and anchors, all corner components, all anchors. Once you reach all corner components, you can convenietly get rid of all of them at once by pressing the Delete key.

In a _cornerglyph, you do not necessarily need to keep your first or final path point beyond the pivot anchors. For instance, this is how you can do the top serif in the n:

Once inserted, the missing segment will be completed automatically:

Useful scripts

In the mekkablue scripts, there are a few scripts for corner (and cap) components:

• Propagate Corner Components: will apply the corner component setup of the current master to all other compatible layers in selected glyphs. This way you only have to set up your components once, then run the script. Also useful for keeping a glyph with corner components compatible for interpolation.
• Remove Detached Corners: sometimes it happens that a corner component is not attached to a node anymore. This script finds those situations, reports them in the macro window, and removes orphaned corner components.
• Find and Replace Corner and Cap Components and Find and Replace Corner and Cap Components at Certain Angles: will give you a user interface for batch-replacing corner components.
• Decompose Corner and Cap Components allows you to batch-decompose corner components in many glyphs at once.

Update 2022-07-26: updated title, related articles, minor formatting.
Update 2023-07-07: rewrite for Glyphs 3.2.

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. Naming your font family can be a little tricky, so you will be happy that we shared our best tips in the following tutorial.

It is important to adopt a good practice in font naming. What makes it challenging 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. Following is what we suggest as best practice.

Family name and Subfamily (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 > Name:

The individual fonts of your family need to be differentiated by their Subfamily Name (a.k.a. Style Name), which is set with the Name field in File > Font Info > Exports. 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 (the one set in File > Font Info > Font > Name), you can add a general property called Family Names to the respective instances in File > Font Info > Exports.

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

Localized names

For maximum compatibility, however, there is something to be said for keeping the Family Names and Style Names 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 general property by clicking on the plus button in the General section, choose Family Names from the pop-up, then pick a language and set the name:

Add an entry 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, Mongolian, Malay and Macedonian, it can even differentiate between Flemish and Dutch, but it does not know every language. Sorry if the one you need is not in the menu, but there is not much we can do about it.

To localize your style name, add the Style Names general property to the respective font instances in File > Font Info > Exports. Adding languages works exactly the same as for Family Names. Speaking of which, you can also localize the family name in the exporting instances, i.e., the general setting Family Names is also available in File > Font Info > Exports > General. 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 many other entries, such as the designer and manufacturer names for example. How? With the respective general properties, of course: Designers and Manufacturers in our example. If an added entry is localizable, it will sport a language menu and allow you to add all the language variants you have always wanted for your font.

Style linking

You can set up family relationships between individual fonts with something called style linking. You can define one instance as the Bold, the Italic or the Bold Italic of another instance. This is pretty easy with the Style Linking section in File > Font Info > Exports. 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 keyboard 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 is that linked styles will not be displayed in Microsoft Office font menus. Only the Regular is visible, the linked Bold, Italic or Bold Italic styles are exclusively accessed through the B and I buttons (or the respective keyboard 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:

Perhaps you noticed that I called it ‘Condensed’ and not ‘Condensed Regular’, same thing with ‘Italic’, rather than ‘Regular Italic’. That is because the name particle ‘Regular’ is considered elidable. That means that as soon as it is combined with any other name particle (like ‘Condensed’ or ‘Italic’), it disappears.

Naming for Windows and office software

Microsoft Word currently focuses on Family Name and Subfamily (Style) Name, or alternatively, on the WWS Family Names and WWS Subfamily Names, if present. WWS stands for Weight, Width and Slope.

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:

And so on. In other words, the Subfamily (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 > Exports, 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.

Quick note about Windows vs. Mac names: In Glyphs 2, the above was done only in the Windows names of the Naming Table. That’s right, the info in the name table is stored twice in your font, once for Mac (a.k.a. platform ID 1), once for Windows (platform ID 3). Don’t even ask why. In Glyphs 3, the Mac names are kept in sync with the Windows names. And if you think it through, this makes the Mac names superfluous. You can suppress Mac names by adding a custom parameter called Export Mac Name Table Entries in Font Info > Font, and set it to off (disable the second checkbox).

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 general property called Style Map Family Names. This quote from the property pop-up says it all:

Style Map Family Names: 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 property, and even less so to localize it. But just in case.

WWS names: name IDs 21 and 22

WWS stands for Weight, Width, Slope. Weight refers to the apparent color or stroke thickness of your design, i.e. light, medium, bold, black, etc. Width to the stretch of your font, from condensed to wide. Slope is the apparent angle of your font, usually upright or italic. 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., if the font has 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.

How do you do that in Glyphs? Easy. You add the appropriate custom parameters for the respective fonts in File > Font Info > Exports. For the WWS Family Name, you use the general property WWS Family Name, and for the WWS Subfamily Name, you add a WWS Subfamily Name. 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 Typographic Names, also known by their deprecated name, the Preferred Names (Name IDs 16 and 17). So if you don’t like the submenu arrangement, you can make your own submenus with Typographic Family Names and put the rest of the respective font name into Typographic Subfamily Names. Both of them are general properties, which you can add by pressing the plus button in the top right corner of the File > Font Info > Exports window.

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. and finally, 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).

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 of the menu), you can directly set the numbers for ordering in the general properties Width Class and Weight Class. E.g., if you need an extra weight between Regular (400) and Medium (500), you would enter 450 in Weight Class:

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 Typographic Family Names are 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 Typographic Family Names 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 Typographic (a.k.a. Preferred) Family Name.

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

Windows uses Name ID 4 (‘Full Font Name’ or ‘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 subfamily (style) name. This is also how Glyphs autocalculates the ID 4 entry. You can override it with a Name Table Entry custom parameter (see further 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 general property called Compatible Full Names to your instance in File > Font Info > Exports.

Needless to say, only do this if you have a really good reason. Using Compatible Full Names 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 (Name table ID 6, in the latest version of the specification simply ‘PostScript Name’) for storing font information in documents. The PostScript Full Name (Name table ID 4, now simply ‘Full Font 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 (‘PostScript Name’, ID 6) can be set in File > Font Info > Exports with a general property called Font Name. 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.

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 subfamily (style) name. In other words, you get to use only these characters:

!"#$&'*+,-.0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_@abcdefghijklmnopqrstuvwxyz|~

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:

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 (‘Full Font Name’, ID 4), which can be set with the general property Full Name, again in File > Font Info > Exports > General. 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. According to Adobe, it should be ‘suitable for display in font menus’.

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 the (PostScript) Font Name and Full Name 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 both of 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 > Exports, 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).

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 (MacRoman and Mac English).

nameID platformID encID langID; nameString
Example: 4 3 1 0x040C; MaPolice 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 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, forget about the Mac names, only ID 3 Windows matters, 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. But seriously, don’t waste your time with this, only keep the platform ID 3 parameters, because the whole concept of platform differentiation is a thing of the past.

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:

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 (Typographic Family Names) 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!
Update 2018-07-05: removed some old limitations of the Name Table Entry parameter, because you can now set all Name IDs with the parameter.
Update 2019-03-19: corrected typos; replaced MaFonte for MaPolice, and Mac Roman for MacRoman (thx Nathalie).
Update 2019-11-14: updated the wording to the most recent spec version (thx Joachim).
Update 2020-11-13: updated for Glyphs 3.
Update 2020-02-17: added and argued advice to keep platform ID 3 only.
Update 2023-01-24: updated the Adobe Tech Note link (thx Zachary).
Update 2023-10-04: added tip about suggested PS name charset.

Changing the whitespace enclosed inside a pair of glyphs is called kerning. Here’s how to do it in Glyphs, with lots of good tips to make your task easy.

Kerning is usually something you do very late in the fontmaking process. Try to get as far as possible with properly spacing your glyphs. But you’ll notice that, no matter how well you do it, some letter combinations never really work out properly. This is when you have reached the point at which you will not get around without kerning. One of the usual suspects is the combination ‘VA’, i.e. when a capital V is followed by a capital A.

This is important: keep in mind that the term kerning means adjusting the whitespace enclosed by a combination of two letters, a glyph pair. You cannot kern a single letter. Adjusting the left and right sidebearings of a single letter is called spacing.

Shortcuts

Okay, so you have optimized the sidebearings of your V and your A, but there is still too much whitespace in between them. This becomes apparent when you type a word like ‘VAND’, which, I believe, means ‘water’ in Danish and ‘sell’ in Romanian and Moldovan. (Actually, the latter is spelled ‘vând’ with a circumflex, or so I have been told by a trusted source.) I recommend you do not merely type the combination that needs adjusting, but also add some context, a few letters where the whitespace seems alright already. This way, you have direct comparison. And in this example, I think the space between N and D is pretty much alright already:

But it looks more like ‘V AND’ instead of ‘VAND’, right? So, if you agree, we need to do something about the space between V and A. In other words, we need to kern ‘VA’.

The easiest way to do so is to move the cursor between V and A, hold down the Ctrl and Opt keys and then adjust the kerning with the left and right arrow keys. Add Shift for increments of 10:

You may have noticed that, except for the additional Opt key, these are the same shortcut as for adjusting the left sidebearing of a letter, Ctrl-arrows or Shift-Ctrl-arrows. Being the logical people that we are, adding the Opt key to the RSB spacing shortcut, Cmd-arrows or Shift-Cmd-arrows, should result in manipulating the kerning to the right of the current letter. And it actually does: Cmd-Opt-arrows or Shift-Cmd-Opt-arrows changes the kerning between A and N in our example.

Displaying kerning pairs

You can keep track of kerning pairs in the sample text by switching to the Measurement tool (shortcut L). Negative kerning will be shown in light blue, positive kerning in light yellow. Even though it is not necessary for the font in this example, I added positive kerning between N and D, so you can see what it looks like:

In fact, you will see small stubs of these colors in Text tool (shortcut T) as well. Just make sure View > Show Metrics (Shift-Cmd-M) is on, and you are zoomed in enough:

Also, in the grey info area (Cmd-Shift-I), you can see the kerning value in relation to the current letter. In this example, the kerning between the V and the A is –80:

Group kerning

You probably want to Kern ‘VA’ just like ‘VÄ’, ‘VÅ’ and ‘VÀ’. And perhaps even like ‘WA’. In this case, you can put the glyphs into groups and use the kerning not just for the specific glyphs but for whole groups of glyphs. In this case, V and W would form one group, and A, Ä, Å and À would form another group.

So, how do we do that? Easy. Every glyph has two fields labeled ‘Group’ in its info panel (Cmd-Shift-I). Now, this is important: each glyph can belong to one left group and one right group. A good example is the lowercase æ: on the left it looks like an a, on the right, it looks like an e. So we put it in the left ‘a’ group and the right ‘e’ group:

The group names are arbitrary, though. For example, the left kerning groups of e, c, o and q can be called o, because they share the same shape. But you could also name themlowercaseRound or something else, as long as it makes sense to you. Unlike metrics keys (see the Spacing tutorial), the kerning group names are not references to glyphs.

Now, pay attention to the lock symbols next to the kerning entries:

• If the lock is closed, you have group kerning. This means that the kerning value applies to the whole group, not just the individual glyph displayed.
• If the lock is open, you have a kerning exception. I.e. the value only applies to that very glyph displayed, not the whole group.

In this example, the kerning of ae with the glyph to the left (v) is a kerning exception, whereas the kerning of ae with the glyph to the right (w) applies to all glyphs in the right e group:

That means that the -15 kerning of ‘væ’ applies to all the glyphs of the right v group, but only to the æ, and no other glyphs of the left a group, i.e., not to ‘va’ or ‘vä’ or ‘và’, etc. Personally I would not recommend an exception here, so I would close that lock again.

The kern pair ‘æw’, with a value of -10, applies to all the glyphs of the right e group and the left w group. So the kerning value also applies to the pairs such as ew, èw, éẃ, ëẅ, ẽẁ, œw, etc. You get the idea.

A good way to manage your groups is to switch Font view (Cmd-Opt-1) into List mode with this button in the top left corner of the window:

Then you can manage the data of your glyphs like in a spreadsheet:

Press Tab to move to the next field, Shift-Tab for the previous field. Press the Return key to go to the next line. Click on column headers for sorting, click again for reversing the sort order. Right-click on column headers to customize the columns.

Batch-setting groups

You can apply kerning groups to multiple glyphs at once. Select more than one in font view (grid or list mode), and manipulate the settings in the bottom left of the window:

In grid mode, you can also invoke the context menu on a multiple glyph selection (right-click or Ctrl-click) and set the kerning groups there:

Viewing groups

When you do group kerning, activate View > Show Group Members and Glyphs will display all group members for the current letter pair superimposed on top of each other. Sounds complicated, but one screenshot explains it all at one glance:

You can see all members of the respective kern group, including all diacritics. This makes it much easier to spot possible collisions. And you know when to introduce an exception.

Kerning exceptions

Okay, so we established what an exception is. It is when at least one of the two locks is open. So there are three types of kerning exception:

• group-to-glyph: left lock is closed, the right lock is open. All the glyphs in the group on the left kern with that single glyph on the right.
• glyph-to-group: left lock is open, the right lock is closed. The single glyph on the left kerns with all the glyphs in the group on the right.
• glyph-to-glyph: both locks are open. The single glyph on the left kerns with the single glyph on the right.

All nice and fine, but when do I need to open which lock? Easy. You will open the lock on the side of the exception. I’ll give you a good example. Say you have kerned ‘Yo’ by -70 units. Like this:

Of course, the locks are closed, because you want to take advantage of group kerning. After all ‘Yø’ and ‘Yó’ look just fine, just like ‘Ýo’ and ‘Ỳç’, and all other combinations of Y diacritics with a lowercase round letter. And then you check all the diacritic combinations, and you run into this:

The dieresis mark of the ö is getting too close to the Y. You cannot just change the group kerning, because that would create a gap for the original ‘Yo’ pair. So, you open the lock of the odieresis, hold down Ctrl-Opt-Shift and press the right arrow repeatedly, and thus create a group-to-glyph exception:

All the other letters in the o group remain group-kerned. Just the odieresis has an individual exception. Uppercase letter with lowercase diacritic is the most frequent scenario for exceptions in Latin. So, group-to-glyph kerning happens often.

Occasionally you will also have glyph-to-group situations, e.g. when the Q and the O share the same right group. Typically the Q will have many more collisions on its right, for example in the pair ‘Qp’. Then you would open the left lock (the lock for the right side of the Q), and add positive kerning.

In Latin and similar simple scripts, it is rather rare that you will get to open both locks. But it happens too, especially for narrow diacritics. The dreaded combination ‘ïï’ (double i dieresis) counts among these situations.

Kerning strategies

Since you will end up with a couple of hundred, potentially even more than a thousand pairs of kerning, it is a good way to approach kerning methodically. Different designers will advise different methods, of course. But most will roughly agree on this:

• Group kerning
  • Set the kerning groups.
  • Go through combinations of right groups with left groups, make sure you keep the locks closed. When doing so, group your glyphs, decide which group pairings make sense, for example:
    • Lowercase to lowercase
    • Uppercase to lowercase
    • Uppercase to uppercase
    • Punctuation around letters
    • Punctuation around (proportional) figures
    • Punctuation to punctuation
  • Do not overkern: keep an unkerned pair (like ‘nn’ or ‘HH’) around for reference.
  • Avoid kerning for certain glyphs altogether, e.g., tabular figures.
• Exceptions
  • Find pairs with collisions or close encounters, open the lock where it most makes sense (left, right or both), and add positive kerning.
  • Find pairs with gaps, open the lock where it most makes sense, and add negative kerning.
  • Avoid overkerns.

Decide what your minimum kerning is, and what your increment is. Usually it makes sense to space as precisely as possible, but kern only roughly. If you feel you need to have many very small kerning pairs (less than 10 units), consider revisiting your spacing.

Tips

Once you get the hang of it, the keyboard shortcuts Ctrl-Opt-arrows or Shift-Ctrl-Opt-arrows are really handy, even Cmd-Opt-arrows and Shift-Cmd-Opt-arrows for the following kern pair. The only trouble is that sometimes you slide off the Opt key, and you suddenly you are messing up your spacing rather. But fear not, there is help! You can switch Glyphs into kerning-only mode if you repeatedly click the lock in the bottom right of the window until it looks like this:

This means that spacing is disabled, and kerning is enabled. So Ctrl-arrows is ineffective, and will not do anything. Until you click on that icon again, of course.

While we are at it, it is a good idea to set up keyboard shortcuts for stepping through sample texts. Set up good text samples in Glyphs > Preferences > Sample Strings. Then, access them through Edit > Select Sample Text… And in Glyphs > Preferences > Shortcuts, you can add keyboard shortcuts for Edit > Other > Select Next Sample String and Edit > Other > Select Previous Sample String. That way you can kern, step to the next sample string, kern, step to the net sample string, kern, and so on, until you grow tired of it. And you can kern even quicker if you play faster music while you’re kerning.

Avoid negative overkerning. Any given glyph should not be kerned more than half of its width. Better less than that: To be on the safe side I personally suggest to never kern more than 40% of a glyph’s width. Why? Because otherwise the triplet ‘T.T’ will end up tighter than the pair ‘TT’. And that is also the most typical example: an uppercase letter with following punctuation, like a comma or a period.

Avoid GPOS table overflows. Internally, OpenType fonts are made up of so-called tables that hold information. On of these tables is called GPOS, short for ‘glyph positioning’. Among other things, it stores all the kerning info. Sometimes that table ‘overflows’, meaning that it becomes larger than the allowed maximum of 64 kilobytes. If, while trying to export a font, you get a GPOS overflow error, do any of the following:

• Reduce the amount of kerning: get rid of small and insignificant pairs. A Latin-only font should have between 500 and 1500 pairs, not more. In Cyrillic, you typically have much less kerning.
• Reduce the amount of exceptions: group-to-glyph and glyph-to-group kerning cause trouble, particularly if the group involved is large.
• In File > Font Info > Font, add the custom parameter Use Extension Kerning. It does some magic and allows for more kerning. It used to be problematic because it is was deemed less compatible. In fact, some old apps do not support Extension Kerning, but these apps are all twenty years and older, and it is better to ignore those apps.

Then try to export again. Repeat until the font exports without an error.

Importing kerning

If you have already set up your own groups in one font, and you want to have the same groups in your frontmost file, then:

• Select all glyphs in your target font, because this will only import kerning for selected glyphs.
• Choose File > Import > Metrics and pick the font file you want to copy the kerning groups from.
• In the dialog that appears, pick whether you want to import kerning and/or kerning classes (another word for groups):

The import function accepts UFO and Glyphs files. The Import Kerning option is only active when you import from .ufo files. But wait a minute, what if I want to import the kerning from a .glyphs file?

Easy: with the kerning window. Read on.

Kerning window

You can manage, sort, and above all, copy and paste kerning via Window > Kerning a.k.a. the kerning window. Just select the kerning pairs you want to copy (or simply select them all with Cmd-A), copy, switch to another font (or another master in the same font) and paste them into the kerning window of that font. Kerning groups are displayed with a preceding at sign (@) and in blue, individual glyphs in brown.

And of course, the kerning window will give you an overview of all kerning pairs for the currently selected font master and writing direction:

You can sort the kerning by clicking in the respective column headers. Clicking a column header again toggles the sort order between ascending and descending. If you click a pair in the Kerning window, Glyphs will insert the glyphs for the selected pair at the current cursor position in the main window. If you have many kerning pairs, you can use the search field to quickly find the one you want. Click on the little magnifying lens next to the search field in order to access additional search options:

Wait, there’s more. Take a look at the gear menu at the bottom right of the kerning window. There are three helpful functions hidden there:

1. Clean up removes ineffective kerning values, e.g., leftovers like kerning entries of letters that are not in the font anymore.
2. Compress does two things. First, it turns exceptions into group kerning as much as possible. To be precise, it will turn glyph-to-glyph kerning into group-to-glyph kerning, and glyph-to-group or group-to-glyph pairs into group-to-group kerning. So you may need to compress twice. Secondly, it removes unnecessary kerning exceptions, e.g. the group kerning between the A group and the V group is –80, but you also have an individual ‘ÄV’ kerning pair of –80. Since that kerning exception makes no visible difference, the Compress function deems it unnecessary and will remove it.
3. Show all glyphs will give you an overview of all possible combinations of the currently selected kern pair: all group members of the left side with all group members of the right side:

Custom increments

If you think that single-unit increments do not work for you in kerning, you can set your own. To do this, open Window > Macro Panel and paste the following:

Glyphs.defaults["GSKerningIncrementHigh"] = 20
Glyphs.defaults["GSKerningIncrementLow"] = 5

Then, press the Run button. This will set your Cmd-Option-arrows and Ctrl-Option-arrows to steps of 5 units, and your Shift-Cmd-Option-arrows and Shift-Ctrl-Option-arrows to 20 units. Of course, you can replace the numbers 5 and 20 by whatever you feel comfortable with.

To reset the kerning increments to their default, simply run this code in the Macro window:

Glyphs.defaults["GSKerningIncrementHigh"] = None
Glyphs.defaults["GSKerningIncrementLow"] = None

This deletes the settings and Glyphs will revert to the default, increments of 1 and 10 units.

Useful extensions

There are many plug-ins and scripts helping you cope with kerning. Feel free to explore Window > Plugin Manager. Here are a few highlights:

Plug-ins

Kern-A-Lytics by Frank Grießhammer visualizes kerning across masters, and lets you edit, average and interpolate kerning values. Useful for finding inconsistencies. Glyphs lead developer Georg Seifert ported it to Glyphs:

Show Kern Values displays the kerning values above the text.

Mark Frömberg’s Show Kerning Groups superimposes all glyphs of the left and right kerning groups of the current glyph. Sounds complicated? But it’s clear once you see it:

Remove Kerning Exceptions removes all kerning exceptions of selected glyphs in the current master, leaving only group kerning intact. Useful in situations where you change the shape of a letter with a Rename Glyphs parameter, and its kerning exceptions do not apply anymore.

Mark Frömberg’s Kernkraft lists unkerned pairs. After installation, you will find it in the Glyph menu. It comes with step-by-step documentation in a wiki:

In the same download, by the way, there is Kernschmelze. It helps copy and interpolate kerning between masters of a font family:

Scripts

The mekkablue scripts have an extensive Kerning submenu. Here are some of the highlights, for more details, see the readme:

• Set Kerning Groups does a pretty good job of guessing the kerning groups for each side of each of your glyphs. You may need to adjust the results here and there, but it does get you pretty far.
• Adjust Kerning in Master can add a value to all kerning pairs, multiply all pairs by a value or round them by a value:

• Auto Bumper: specify a minimum distance, left and right glyphs, and Auto Bumper will add the minimum necessary kerning for the current master.
• GapFinder and KernCrasher open a new tabs with kerning combos that have large gaps or too little room between them:

• New Tab with Overkerned Pairs: Asks a threshold percentage, and opens a new tab with all negative kern pairs going beyond the width threshold.
• Sample String Maker: Creates kern strings for user-defined categories and adds them to the Sample Strings. Group kerning only, glyphs without groups are ignored.
• Remove Small Kerning Pairs and Exception Cleaner help reduce unnecessary kerning pairs.

Toshi Omagari’s scripts contain a few scripts for managing kerning. Among them:

• Display Unlocked Kerning Pairs shows exceptions in Edit view.
• Rename Kerning Groups renames kerning groups and pairs associated with them.
• Permutation Text Generator outputs glyph permutation sample text for kerning:

• Copy Kerning Pairs copies patterns, e.g., from caps to small caps. It supports pair-to-pair and preset group copying:

In Tim Ahrens’ Freemix scripts (full readme), there is a script for expanding kerning. Expanding is meant to be the opposite of compressing: it turns group kerning into all possible kerning exceptions. That means a lot of exception pairs. You have been warned.

Kern On

I kept the best thing for last. Tim Ahrens wrote a commercial plug-in called Kern On. It takes a look at the kerning you have done and finishes it for you in a minute. No setting of kerning groups required, just good spacing. And for 200 bucks, you can forget the contents of this tutorial altogether. Just saying.

Sample Fonts: Playfair Display, courtesy of Claus Eggers Sørensen, cameo appearances of Lawabo Unrounded and Plantago, courtesy of Schriftlabor.

2016-02-16: updated for Glyphs 2 (thanks Sacha Rein)
2018-01-30: Added Custom Steps, Scripts, and note about Show All Glyphs
2018-08-10: added View > Show Group Members
2019-03-26: corrected typos (thanks Nathalie Dumont)
2021-09-29: updated for Glyphs 3, new screenshots, added extensions, tips, strategies, partial rewrite.
2022-11-03: removed a superfluous word (thanks Curtis).
2023-10-04: added a note about the terms left and right in different contexts (thanks Michael).

Variable fonts open a whole new world of possibilities. Creating them is a breeze in Glyphs.

What are variable fonts?

If you have not read John Hudson’s excellent introductory article, stop right now what you are doing, and read it. No, really.

Done? Okay. So let’s set up a variable font in Glyphs, step by step. Here we go:

Step 1 Define axes

If we want to interpolate, we first need to set up a design space. The design space is a coordinate system defined by axes, much like the Cartesian coordinate systems we know from high school. Just that, instead of x, y, z axes, we have design axes that make sense for typography, such as Weight, Width, Slant, etc.

So, we go to File > Font Info > Font > Axes, and add an axis by clicking on the plus button:

In the axis entry that appears, pick the kind of axis that you would like. You can take any of the official ‘registered’ axes: Weight, Width, Italic, Slant, Optical Size, and a range of proposed new axes. Or, you can make up your own ‘private’ axis.

You can add almost any number of axes, each of them must have a unique four-letter axis tag. In this example, I will stick to one ‘registered’ axis, Weight, with the predefined tag wght.

Step 2 Set up masters

In the same File > Font Info window, switch to the Masters tab, and add masters with the plus button in the lower left corner of the window, or duplicate existing masters, very much like you would for a Multiple Masters project. In our example, we will add two masters, Light and Bold.

For each master, pick the following settings:

1. Most importantly, set the axes coordinates for each master. In our example, set the Weight value, e.g., 50 for the Light Master, and 200 for the Bold Master. Many designers like to use the stem thickness as value for the weight axis value, but you can enter whatever you like, as long as the values are sufficiently different, so that Glyphs can calculate intermediate instances. In our example, we could calculate an instance at numbers between 50 and 200, e.g., 75, 120, 182, etc.

2. Make sure you pick an appropriate master name for each master. In our case, I would say Light and Bold are good guesses. The master names are not exported into the final font file. They are important for your own orientation when you work in Glyphs.

3. Optionally, pick a master icon from the Icon pop-up in the General section of each master. You can select from a range of lowercase n’s representing all sorts of weight and width combinations. You can also enter a glyph name at the bottom, and Glyphs will use an image of the respective glyph as master icon. Again, this is only for your orientation, so pick something that makes sense to you.

Okay, now we have the masters set up, we can add drawings in each master. Here we go.

Step 3 Draw compatible glyphs

To keep it short and simple, we will stick to an uppercase A for this tutorial. I draw the light A (Cmd-1) with a stem width of approximately 50 units:

… and the bold A (Cmd-2) with a stem 200 units wide:

Add anchors by choosing Glyph > Set Anchors (Cmd-U) or even better, holding down the Option key, Glyph > Set Anchors for All Masters (Cmd-Opt-U). Most importantly, keep all your outlines and anchors compatible between both masters, just as you would in a Multiple Master setup.

Step 4 Add predefined instances

Even though our font is variable, and we have an endless amount of instances already, we can still pick some spots in the design space and define them as instances for the font submenu. In File > Font Info > Exports, add as many of those predefined instances as you like. Simply add new instances with the plus button in the lower left, or Option-drag an existing instance entry in the left sidebar to duplicate it.

All you need to do in each instance is this:

1. Set an appropriate Style Name: e.g., Light, Regular, Medium, Semibold, Bold, Extrabold in our example.
2. Optional: you can pick a Weight and Width Class from the pop-up menu right below the Name. The downside: this will only apply to the correlating static font exports, and not be written into the variable font. Read more about it in the Naming tutorial.
3. Pick appropriate design space coordinates for each of your axes. Read more about the distribution of weights in the Multiple Masters, part 3 tutorial.
4. Pick a Style Linking. In the uprights, you leave these usually blank, only the Bold is the Bold of the Regular. And every italic is the Italic of its upright counterpart, e.g., Semibold Italic is the Italic of Semibold. Only the Italic instance is the Italic of Regular, and the Bold Italic is the Bold and Italic of Regular. Read more about it in the Naming tutorial.
5. And I hate to break it to you, but most custom parameters do not work in an OTVar instance, especially ones that do shape post-processing, like most filters. If you have any of those in your instance, they will be blissfully ignored by the software. Why? Because they jeopardize outline compatibility.

6. Optional: pick a Variable Style Name to override the (style) name of the instance. If you are using the same instances for both static and variable font exports, and for whatever reason, you are using different style names for static and variable styles, you can specifically set the variable style name with this property in the General section.

Step 5 Add a variable font setting

OK, so many custom parameters in instances do not work. For example, of course you cannot have different glyph sets in different instances of the same variable font, duh. Makes sense because a glyph cannot (and should not) just disappear or reappear when you move your sliders. That is why Export Glyphs and Remove Glyphs parameters are ignored in the instances. And you will find similar logical reasons for other parameters.

But what if we could apply parameters to the whole variable font? Well, we can. From the same plus menu in the lower left corner, add a Variable Font Setting:

… and define all the things you want to define, even glyph subsetting with the Keep Glyphs parameter, or changing the OpenType features and classes with the respective parameters, o, etc.

In Glyphs 3.1 and later, here is our recommendation:

• Name: Call it Italic if the entire font is italic. Otherwise call it Regular. This will ensure style linking works even if romans and italics are in different files.
• Family Name: Must be different from the static family name if you plan to ship both static and variable fonts. That is because a user could install both and have a font conflict. Typically, you will use the same family name with an extra signifier like ‘VF’ or ‘Var’ or ‘Variable’, for example: ‘Myfont VF’. If you have uprights and italics in different files, this entry must be the same in both files.
• VariationsPostScriptNamePrefix: optional. Setting for name ID 25, and Glyphs will derive the fvar postScriptNameID entries from it as well. This is a PS name, so just use A-Z, a-z and 0-9, but no spaces or symbols or non-ASCII characters. If you have uprights and italics in different files, this entry must be different, e.g., ‘MyfontVarRoman’ and ‘MyfontVarItalic’.
• Optional custom parameters: The variable font setting will provide you with all possible custom parameters when you click on the plus button. Consider fileName and Variable Font Origin.

Keep in mind: You can have multiple variable font settings, for exporting more than one variable font at the same time.

Step 6 Export and test your variable font

Choose File > Export and click on the Variable Fonts tab:

If you have the latest Adobe Illustrator, Adobe Photoshop (CC 2108 or later), or InDesign (CC 2020 or later), you can export into the Adobe Fonts folder, choose the font in the Character panel, and open the little slider pop-up to experiment with the Weight axis:

Alternatively, you can drop the font file in one of the amazing web pages that allow you to test fonts. My favorites are Roel Niesken’s great Wakamai Fondue, ABC Dinamo’s Font Gauntlet (which also lets you animate your variable font), and of course Laurence Penney’s Axis Praxis page:

Or, you install the mekkablue scripts and run Test > Variable Font Test HTML, which creates an HTML file next to the latest OTVar export, and opens the enclosing folder in Finder. So all you need to do is drag that into a browser:

Circumvent bugs

Adobe’s OTVar implementation is buggy. So, if the font does not interpolate properly in Illustrator or Photoshop, it may not be your font’s fault. Symptoms vary, but may include glyphs staying static and not reacting to slider position changes at all, or ugly small kinks appearing during slider movements, e.g., like this:

If that happens, you can try to set different start points in your outlines. We found that this sometimes helps circumvent AI’s rendering bug. In any event, if you see that the same glitch does not appear in the web browsers, it’s not your font’s fault. And it is best to send your font file to Adobe support, alongside an AI file containing a simple test case.

Update: In recent CC versions, these rendering issues have become very rare. Actually, we have not seen any of these in CC 2021.

Another annoying implementation bug is sitting deep in Apple’s renderer CoreText. Offsets of components are miscalculated if the LSB is changing. Watch how the a behaves correctly, while the a-umlaut shifts more than it is supposed to do:

This affects all environments that make use of CoreText rendering, which include pretty much all browsers on the Mac. In that case, the best you can do is make sure that all composites are decomposed when you export. Best way to do this: Add a Decompose Components in Variable Font parameter to File > Font Info > Font > Custom Parameters. Needless to say, the resulting TTF will be much larger, and not fit for web use until Apple fixes the issue.

We reported the bug to Apple, but if you have a good case in your hands, please let Apple know as well.

Update: Apple fixed the problem. Make sure you have the latest dot update of macOS 10.13, or a newer macOS.

Another bug in Apple’s rendering: The Optical Size axis (opsz) is misinterpreted in Safari. At the slider position that coincides with the origin master (i.e. the first master unless you specify a different Variable Font Origin with the custom parameter of the same name), it shows the rendering for the maximum value. This only appears in Safari, not in other browsers. Again, please let Apple know. Update: There is a feedback for this bug with ID FB6055886 filed. Make sure you reference it if you file another bug.

Then, there is a rendering problem that is caused by the fact that variable fonts keep their overlaps. Not really a bug, but it may appear to your users as such. If the edge of a shape is drawn by two (partially) overlapping path segments, anti-aliasing will cause the edge to appear darker than the ‘clean’ edges that are drawn only by one outline:

The only solution for this is to rewire your outlines in such a way that the outer edge of your shape is always ‘clean’, i.e., drawn by only one path at any given spot. E.g. like this:

In the very most cases, you will be able to fix this by removing overlaps and subsequently opening corners or reconnecting nodes. Both functions, Open Corner and Reconnect Nodes are available in the context menu of a respective point selection: individual corner nodes for opening corners, and pairs of corner nodes for reconnecting.

The mekkablue script Paths > Rewire Fire helps you find nodes that need to be reconnected. It cannot find everything, but usually most of the cases that cause unclean edges like the ones shown above. What you want is the option that finds ‘nodes on top of line segments’:

Optional: add a virtual master

Imagine you need an axis which only applies to some glyphs. Let’s say, the crossbar height, which is applicable to letters like A, E, F, H, but not S, D, J, O, etc., and not to any non-letters, like figures, punctuation and symbols. It would not make sense to draw a new master for all the font, would it? Rather, you would introduce an extra master only for those glyphs that have a crossbar. Well, for cases like these, we have something called a Virtual Master:

1. In File > Font Info > Font, add a new axis to the Axes parameter. Since this is not one of the standard axes, names are arbitrary. In this example, I suggest the name Crossbar Height and the four-letter tag CRSB:

2. In the same window tab, add a parameter called Virtual Master, and give it the value of the the Light master for the Weight axis, 50 in our example, and a minimum value for the Crossbar Height, let’s say zero:

3. Go through all masters in File > Font Info > Masters, and make sure the axis coordinate for Crossbar Height is not zero but, e.g., 100. The idea is that the values make sense semantically somehow. In our case, zero represents the lowest possible crossbar position, and 100 the highest possible position. You can edit all of them at once if you select all the masters:

Now that the virtual master is set up in Font Info, you can draw the low-crossbar version of each glyph that needs it:

1. Open the glyph in Edit view.

2. In the Layers palette, duplicate the Light layer with the plus button. It will create backup layer carrying the current date and time as name.

3. Right click the backup layer and turn it into an intermediate layer by choosing Layer Type > Intermediate Layer from the context menu:

4. Double click the intermediate layer, and in the pop-up dialog that appears, set its design space coordinates for Weight (50 representing the Light master in our example) and Crossbar Height (0 representing the lowest crossbar position in our example):

5. Now change the drawing to what the letter should look like with Crossbar Height zero:

Now the cool thing is: unless you want to do fine-tuning, you will not need to add a Brace layer for the bold master. In Variable Fonts the deltas (point movements) of the two axes compliment each other and can be added up to form the bold with the low crossbar. So the best strategy may be to see if it works with just one master, and only add additional ones if the result is not good enough.

That’s it. Now all you need to do is export, and try the font again in Illustrator, Axis Praxis or the Variable Font Test HTML script, et voilà: a second axis is available, for lowering the crossbar towards the baseline:

Effectively, we have added a second dimension to our design space. If you do that, it is advisable to keep the masters in a rectangular arrangement, or even better yet in a vertical or horizontal offset in respect to the origin master. In our example, the Bold master is horizontally offset towards the Light master (difference in the first coordinate only), and the master with the low crossbar is vertically offset (difference in second coordinate only). This way you have the most control because you can reach any point within the design space rectangle by simply adding the vertical and horizontal deltas you created by arranging your masters as described.

Optional: setting a different origin

Only one set of outlines is stored in the font. Non-OTVar-capable software will only be able to display these ‘default outlines’. That default is usually your first master. You can pick a different default, though. To do so, go to File > Font Info > Font or to a Variable Font Setting in File > Font Info > Exports and add a custom parameter called Variable Font Origin. As its value, pick the name of a master from the pop-up menu:

Yes, it must be a master. If you want any of your instances to be the origin, you would need to add the instance as an additional master: In File > Font Info > Exports, select the instance you want to define as your origin, open the Plus button in the lower left corner of the window, and pick Instance as Master from the pop-up menu that comes up. Now you have an additional master in File > Font Info > Masters, and you can set that as your Variable Font Origin.

Two things to consider:

1. Default Appearance: One of the founding ideas behind variable fonts is that you can pick your most used instance as the default, typically the Regular. In Multiple Masters, you designed the extremes of the design space (i.e., your least used instances) and would interpolate everything in between. A variable font can go the opposite direction: it only stores the most important outlines, somewhere in the middle of the design space, and all other instances are derived from that one. So, for desktop fonts, pick the Regular as origin, or whatever the user will expect as the ‘default appearance’ of your font family. If all else fails, this is the weight the user will still be able to use.

2. File Size: Picking a middle master will likely increase the number of your point deltas, and therefore, also increase the eventual file size. On a single-axis setup, it will likely double the number of deltas, if not more. In other words, for webfonts, it makes more sense to pick one of the masters in an extreme end of the design space, because you want to keep file sizes and load times down.

What works and what does not

Some things you may have gotten used to, do not work quite as you may expect them to in a variable font.

1. I briefly mentioned above that all post-processing with custom parameters in File > Font Info > Exports is ignored because they are too likely to break outline compatibility or glyph set consistency. That includes filters and the Rename parameters.
2. Corner and segment components work. But they work differently: in variable fonts, Glyphs applies them before interpolation, whereas in a classic Multiple Master setup, they are inserted and adjusted afterwards. So, the result may be a little different between static and variable instances.
3. Both intermediate and alternate layers work.
4. Alternate layers do not translate into composites. There is a script solution for that though. See further below. Update: it should work in Glyphs 3.1 and later.
5. Brushes work, as long as they are applied the same way in all masters.
6. Path attributes like strokes do not work currently. The translation into TrueType curves would break outline compatibility.

Not really optional: STAT table

In new fonts, including all Variable Fonts, naming info is stored in the STAT table. STAT is short for Style Attributes, and includes, among other things, information about axes, instances, and something called the display strings, or name strings: These are names for sections on an axis. E.g. a weight axis may be sectioned into Light, Regular, Medium, Semibold, Bold; a width axis into Condensed, Regular, Extended.

The idea behind this is that an application can name a user’s current instance, no matter what his or her slider settings are. Effectively, in a multiple-axis setup, you get n-dimensional fields of possible names. E.g., if your font has a weight and a width axis, you get columns of weights, and rows of widths, like in the table below. And in order to name the combination of a weight in the Bold section with a width in the Condensed section, an application can simply combine the display strings, and ta-daaa, we have ‘Bold Condensed’:

A display string is deemed elidable if it is left out when combined with other display strings. Usually, this is the case for default-style names like ‘Regular’, ‘Normal’, or the like. The semibold weight combined with regular width is usually just called ‘Semibold’, not ‘Semibold Regular’; or the normal weight in combination with the italic style is simply called ‘Italic’, not ‘Regular Italic’. Thus, the display name ‘Regular’ is considered elidable.

Usually, Glyphs takes care of this pretty smartly by analyzing the names of your predefined instances. If however, you find that in the STAT table entries, the display strings are not properly stored in the file, you can take control with these two parameters in File > Font Info > Exports:

• Style Name as STAT entry: Takes the instance style name as combinable display string for an axis range. As value, use the four-letter axis tag to which the display string applies. Use this only in instances that are non-normal on one axis and normal on all others. That is because the normal attributes have elidable names and do not appear in the style name (e.g., ‘Semibold’ or ‘Condensed’). Example: In the Light instance, use this parameter with the value wght, because Light is a value on the weight axis.

• Elidable STAT Axis Value Name: Declares the instance style name as elidable for the axis specified in the parameter value. As value, use the four-letter tag of the respective axis. Typically, you will add this parameter in the regular style, and you will add one for each axis for which the name is an elidable display string. Example: An instance called Regular has two Elidable… parameters, one with wght and one with wdth as parameter values.

Axis mappings and locations

One more thing about axes. Obviously, axes start somewhere and end somewhere. In a user interface, the beginning and end of an axis can be (and usually are) represented by the leftmost and rightmost positions on a slider. Everything in between, of course, is spread out evenly between these extremes. In other words, in order to display 25% of the interpolation, you put the slider at the quarter position, for 50% of the interpolation, you put it exactly in the middle, and so on. Makes sense, doesn’t it?

Wait a minute. Does it really? Giving it more thought, it really only makes sense if the instances that the user should be able to access are also spread out (more or less) evenly across the complete slider range. For the sake of the argument, let’s imagine a situation where the important positions are crammed in a small part of the slider range, and a large part of the slider is not doing much for the user.

This actually happens to be the case for the Weight axis (axis tag wght). In (almost all) weight interpolations, the various weight styles are not distributed evenly. Depending on how thin the lightest master is and how fat the boldest, you will have more styles grouped together at different ‘focal points’ along the axis. For instance, interpolating from very thin to a ‘normal’, not-too-extreme bold will have styles concentrated towards the light end of the slider:

Why? Because in principle, equidistant movements of the slider correspond to the same changes in units, no matter where on the slider you make the movement. E.g., a certain back-and-forth here changes the design by 10 units, and the same back-and-forth there also changes by 10 units. However, adding 10 units to the stem thickness is a lot for a Hairline, which has only a few units to start with. But the exact same amount is practically negligible for a Medium or Semibold, because in comparison to the stem thickness, it is just a small change.

It is the other way around, if you go from a not-too-extreme Light or Book or Regular on one end towards a very bold Ultra Heavy on the other end of the slider. Now, the styles gather at the bold end of the spectrum:

How is that possible? Well, actually it is the reverse situation to the above, because what changes this time is the white in the letters. For a very, very heavy design, adding or removing 10 units to the white is a lot because there is so little white left. Yet, in the ‘normal’ range of weights between the average Book and Semibold designs, we still have the same situation: the styles are further apart.

Putting one and one together, it is now clear that interpolating from very thin to very bold usually has style concentrations towards both ends of the spectrum:

But on the other hand, the users do not care about our distribution problems, do they? For the users, accessing the different styles works best if they are distributed evenly across the axis, like this:

In other words, we need to somehow translate the evenly distributed user-accessible positions (‘external coordinates’) to the appropriately distributed design positions (‘internal coordinates’), like this:

This is called an axis mapping. We map what the user sees on the axis, to what the user actually gets on the axis. There are these conventions we are expected to fulfill:

• Weight axis: external coordinates for the wght axis are expected to match the usWeightClass numbers. Minimum value is 1, maximum value is 1000. The higher the value, the bolder the font. Expected external coordinates are: 100 Thin, 200 Extralight, 300 Light, 400 Regular, 500 Medium, 600 Semibold, 700 Bold, 800 Extrabold, 900 Black. If you need something lighter than Hairline, use 1, the minimum. If you need something bolder than Black, use the maximum, 1000. There are no prescribed names for those extra weights, but I have seen ‘Laser’ and ‘Hairline’ for the very lightest weights, and ‘Extrablack’ and ‘Superheavy’ for the boldest of the bold. (spec)
• Width axis: external coordinates for the wdth axis are expected to match the percentages described in the usWidthClass specification. The default letter width perceived as a ‘normal’ width is assumed to be at 100. More condensed designs will have a smaller value, wider letters will have a higher value, roughly indicating the percentage of line length in relation to the default width. In other words, wdth=50 means that the font is so condensed that it takes up only approximately half the space it needs at wdth=100. At wdth=200, the text would need approximately twice the space. (spec)
• Italic axis: external coordinates for ital are assumed at 0 for upright/roman, 1 for italic. Note that you can interpolate between 0 and 1. (spec)
• Slant axis: external coordinates should roughly reflect the counter-clockwise slant angle in degrees, ranging (theoretically) from −90 to +90. Yeah right, I want to see a design with an angle of 90°... but you get the idea. And the math buffs among you will note that the angles are not linearly distributed between the min and max slider positions, but well, it is good enough for non-technical people. Attention: the degrees are measured counter-clockwise, so a 10° slant angle would need to be specified as -10, no kidding. And, if you plan to interpolate between what you consider the upright and the italic, and you want your users to toggle between them with the Italic button, forget the Slant axis and use the Italic axis instead. (spec)
• Optical size axis: external coordinates for opsz are simply the type sizes in points, at an average reading distance (40 cm). A regular size is thus assumed at 10–16 points, and the opsz value cannot ever be zero or negative. (spec)

All other axes, and of course custom axes, do not have expected values. In such a case, put yourself into the position of your users, and pick external coordinates that would make sense to you as a user of your own typeface. Sometimes, there is an agreed inofficial convention, though. So perhaps it is a good idea to ask in the forum what is the best course of action if you are being created with axes.

Whatever axis we pick, we can achieve a mapping for it through two methods: the Axis Mappings parameter, or through a setup of Axis Location parameters. Axis Mappings work well in single-axis setups. When you start having multiple dimensions, Axis Location parameters are definitely easier to handle and more precise. If you ask us, we will recommend Axis Location parameters to you.

Option 1 Axis Location parameters

With Axis Location parameters, you can exactly define the external coordinates for each master and instance. Glyphs will take this information and calculate the distributions for each axis. You will need to add the parameters in two places:

1. In File > Font Info > Masters, add an Axis Location parameter for each master. You can select all masters, and add the parameter to all of them at once. You will still have to step through them and adjust each external coordinate manually.

2. In File > Font Info > Exports, add an Axis Location parameter for each instance. Again, you can batch-add the parameter to all instances at once, exactly as with the masters. The external coordinates of the instances must be within the range of the masters, of course. And if an instance shares internal coordinates with a master, they also must share the same external coordinates. Makes sense, but it needs to be said.

That’s it, nothing else to be done. Next time you export your variable font, the font will have the desired (external) axis distribution for the user. Cool.

Of course, if you have many masters and many instances, it is tedious to edit all the Axis Location settings, ugh. That is where some useful scripts come in. See further below.

Note: If you are switching shapes, do not change the numbers in Brace and Bracket layers, or in the condition statement in your feature code. Those still adhere to internal interpolation values.

Option 2 Axis Mappings parameter

We can also achieve such a mapping with an Axis Mappings parameter plus Axis Location parameters for the masters. But how do we set it up? Easy:

1. For each master in Font Info > Masters, add Axis Location parameters with appropriate external coordinates. You can skip the step if your external coordinates are the same as the internal coordinates. In our case, we cannot, simply because internal coordinate 50 should match external coordinate 300 (usWeightClass for Light).
2. Add the Axis Mappings parameter in Font Info > Font.
3. Click the parameter’s value to edit it. Add new values for each weight on your wght axis, each width on your wdth axis, etc. You can add a value by clicking the plus button at the bottom, or by clicking on a segment in the graphic next to it:

4. The left column (or horizontal axis in the UI) represents the internal coordinates, make sure you match at least the instances you have set up. You can be more detailed though. The right column (or vertical axis in the UI) represents the external coordinates. Those should match the conventions described above.

In our example, the Axis Mappings may end up looking like this:

Testing axis distributions

Usually, axis mappings will only create subtle changes to the way your font behaves when you drag the slider from one end to the other. So, it will be hard to verify if everything worked out the way you intended it to be. Therefore we need a special tool to inspect the avar table. Luckily, Laurence Penney’s Samsa is such a tool: drag the font onto the page, and in the Axes inspector, turn on the Show avar option:

And then drag the slider to see the green arrow that indicates how the visible slider position (top) maps to the actual design distribution (bottom). You can get geeky extra information if you hover over the visualization and wait for the tooltip to pop up:

To explain, the avar values go between −1.0, 0.0 and +1.0. Glyphs will usually put your interpolation between 0.0 and +1.0. In other words, in avar, your light master will correspond to 0.0, and your bold master to +1.0. For instance, the tooltip pictured above says that the current slider position 550.4 (at 0.562988... or 56.3%) to the actual design position 540.38 (at 0.550476… or 55%), halfway between Medium (500) and Semibold (600).

Useful scripts

In the mekkablue scripts collection (link includes readme with installation instructions), you will find a number of useful scripts for making your variable font work:

1. Interpolation > Composite Variabler: Reduplicates alternate layers of components in the composites in which they are used. Makes brace layers work in composites too. E.g., if you have a lowercase g with a brace layer that switches from a double- to a single-story design as it gets bolder, you need to reduplicate the bracket layer in the composites gcircumflex, gcommaaccent and gbreve. You will still need to decompose the bracket layers after running the script:

   Update: Composite Variabler should not be necessary anymore in Glyphs 3. Use this only as an emergency hack to fix things.

2. Kerning > Zero Kerner: Adds group kernings with value zero for pairs that are missing in one master but present in others. Helps preserve interpolatable kerning in OTVar exports. Use this if you find that some kerning goes missing, especially kern pairings that only exist in some masters.

   Update: Zero Kerner should not be necessary anymore in Glyphs 2.6.5, builds 1300 and above.

3. Interpolation > Set Weight Axis Locations in Instances: Will attempt to set Axis Location parameters for all instances according to their weight class (e.g., 600 for Semibold). If a master coincides with an instance, and does not have an axis location assigned, it will receive the same axis location as the instance. (The same functionality is baked into the Insert Instances script.) Hidden extra: if there are width classes set in the instances, and no axis location available for the width axis yet, it will attempt to populate width axis locations as well.

4. Interpolation > Axis Location Setter: Will (re)set internal and/or external coordinates in instances and masters, based on the style name. E.g., all instances containing the name ‘Semibold’ (including Condensed Semibold Italic, Wide Semibold, etc.) should have internal weight axis coordinate 140, and external axis location 600. Useful for batch-moving instances in a multi-axis setup.

5. Interpolation > Instance Cooker: Batch-create all instances from predefined locations for each axis. Very useful if you have many axes and need to create many instances. Description in the UI:

6. Font Info > OTVAR Maker: Helps (batch) create variable font settings in File > Font Info > Export.

7. Post Production > Fix Italic PS Names (OTVAR): If you run this after export of an italic variable font, the script will fix the postScriptNameID entries in the exported fvar table. Specifically it fixes ‘Italic’ double namings, i.e., it will turn MyfontItalic-MediumItalic into the suggested MyfontItalic-Medium. It outputs its progress in the Macro Window.

Additional resources

Want to dig deeper and know more about variable fonts? We have a few links for you:

• Microsoft: OpenType specification
• Microsoft GitHub: proposals for new OpenType Design Variation Axis Tags
• Tom Rickner’s background story, ‘From TrueType GX to Variable Fonts’
• Irene Vlachou’s barebones guide to Building variable fonts with Feature Variations
• Roel Niesken’s Wakamai Fondue (‘What can my font do?’)
• ABC Dinamo’s Font Gauntlet
• Laurence Penney’s Axis Praxis
• Laurence Penney’s Samsa for variable font analysis (source code on GitHub)
• Font Drop by the Nübel brothers
• Travis Kochel’s I Can Variable Font, ‘notes on generating variable fonts’
• Andrey Kuzmin’s Font Dimensions, a tool to visualize dimensions of a variable font
• Underware’s fun showcase and proofs-of-concept: Very Able Fonts
• Nick Sherman’s track-keeping of variable font releases: V-Fonts, ‘a simple resource for finding and trying variable fonts’
• Christoph Koeberlin’s variable fonts resource list with many useful links (partially in German, but don’t let that scare you off)

STAT table sample font: Plantago by Viktor Solt-Bittner and Schriftlabor.
Many thanks to Rob McKaughan for his commentary and advice on this tutorial.

Update 2018-03-16: corrected some typos (thx Jeff Kellem).
Update 2018-06-22: clarified wording for the example values (thx Karl).
Update 2018-11-20: updated naming of Variable Font Origin parameter.
Update 2019-02-15: added links for Font Gauntlet and Wakamai Fondue. Updated test script and browser support info. Added Circumventing Bugs.
Update 2019-03-13: added Additional resources.
Update 2019-03-04: corrected typos and replaced Variation Fonts by Variable Fonts of the Export window (thx Nathalie Dumont).
Update 2019-03-20: Corrected typos, replaced Add Instance as Master for Instance as Master, and modified link to Nick Sherman's V-Fonts (thx Nathalie Dumont).
Update 2019-10-23: added Useful Scripts.
Update 2019-12-04: added section about the anti-aliasing problem.
Update 2020-03-08: added paragraph about Safari opsz bug, the hint about the Rewire Fire script, and Samsa to the resources.
Update 2020-06-14: added Axis Mappings chapter, updated Useful scripts, added a GIF for the Safari opsz bug.
Update 2020-07-09: minor change of phrase in the paragraph about the Rewire Fire script.
Update 2020-11-17: partial adaptation for Glyphs 3.
Update 2020-12-14: largest part and screenshots updated for Glyphs 3.
Update 2022-04-19: rewrote ‘Axis mappings and locations’ (removed separate ‘Optional: axis location’ chapter). Added new useful scripts for axis locations.
Update 2023-10-16: added suggestions for variable font settings and two new scripts, updated Font Gauntlet link.
Update 2023-12-02: better explanation of the Safari opsz bug, added Apple Feedback ID.

Vertical metrics determine the first baseline in a text, the distance between lines of text, and the padding to the following object below the last baseline.

For historical reasons, there are no less than three sets of values that deal with your vertical metrics. They’re known as hhea, typo (a.k.a. sTypo or OS/2) and win (or usWin) metrics. Depending on which OS you’re on and which application you’re in, a different set is used for rendering the font on the screen.

Unfortunately, all of these values relate to each other in a pretty complicated way. Fortunately, Glyphs does its best to calculate them based on the vertical metrics you enter for each of your masters: ascender, cap height, x-height and descender. You may run into problems, however, if these values change between masters.

Custom parameters

So, in order to avoid vertical jumps when you switch between different fonts of your family, it is a good idea to synchronize all values across all masters. You will do this with custom parameters in File > Font Info > Masters (Cmd-I). Set the values in one master, then copy and paste the parameters into the Custom Parameters fields of all other masters.

But what do these values mean? Let me give you a quick rundown.

hhea

The name hhea refers to the hhea OpenType table. ‘hhea’ is supposed to be an abbreviation for ‘horizontal typesetting header’. Apple devices such as Macs, iPhones, iPads, etc., use these values for rendering. The hhea table knows three vertical metrics values. For convenience, I will list them here with the custom parameter names that Glyphs uses:

1. hheaAscender: the height of the ascenders in units
2. hheaDescender: the depth of the descenders in units (negative value)
3. hheaLineGap: the recommended whitespace between lines

OS/2 sTypo (typo)

These values are part of the OS/2 OpenType table. Anybody remember the operating system by the same name? Type pros commemorate it every day, thanks to vertical metrics. Sometimes, they are also referred to as sTypo or simply typo values, though. I have seen designers refer to them as OS/2 values, but that is a little imprecise, because the win values are also part of the OS/2 table.

1. typoAscender: the height of the ascenders in units
2. typoDescender: the depth of the descenders in units (negative value)
3. typoLineGap: the recommended whitespace between lines

To quote Yannis Haralambous (p.724), these values ‘are oddly similar to ascent, descent, and lineGap in the hhea table but that should not necessarily be so precise or so closely tied to the vagaries of the glyphs’ outlines. Windows supposedly uses these values to find the ideal parameters for layout; thus we have a certain degree of artistic freedom.’

The big layout apps, XPress and InDesign, use the typoAscender and typoDescender values to determine the offset of the first baseline in a text box and the minimum size of a text box below which the display of type is suppressed. In DTP apps, the line gap is set by the user, hence typoLineGap is ignored.

Office software and browsers should prefer the typo values over win if the Use Typo Metrics parameter is set to yes. In that case, typoLineGap will be respected as well.

The UPM dogma

There is one thing you need to watch out for, though: the ‘UPM dogma’. In the dark past of electronic typesetting, the TrueType/OpenType specifications used to stipulate that the span from typoAscender to typoDescender should be as large as the font’s UPM (usually 1000 or 2048). This used to make things really complicated.

A few years ago, the ‘UPM dogma’ has gotten under fire, because it simply did not work for scripts that require different metrics than Latin. One of the proponents of letting go of the UPM dogma was Victor Gaultney from SIL, who wrote both Best Practice: Design Metrics and Best Practice: Line Metrics.

In the meantime, the dogma was dropped altogether from the OpenType specification:

It is not a general requirement that sTypoAscender - sTypoDescender be equal to unitsPerEm. These values should be set to provide default line spacing appropriate for the primary languages the font is designed to support.

(Source: OS/2 sTypoAscender specification on Microsoft Typography)_

Yet, the UPM dogma still plays a role in the (legacy) Adobe and Microsoft strategies discussed below.

OS/2 usWin (win)

The win (or usWin) values are also part of the OS/2 table.

1. winAscent: the top extremum of the font rendering box
2. winDescent: the bottom extremum of the font rendering box (positive value)

Attention: whatever extends above or below these values, will likely be cut off when rendered by the Windows text engine. Hence, the easiest way, it seems, is to make sure everything in the font fits into the win span. So, usually, nothing you do in your font will exceed the win span.

Use typo metrics

There is one more thing. If you can safely ignore older (i.e., pre-2006) MS Office versions, you should add a Use Typo Metrics parameter to File > Font Info > Font. If checked, applications that respect this setting (in particular, versions of Microsoft Office since 2006) will prefer typoAscender, typoDescender, and typoLineGap over winAscent and winDescent for determining the vertical positioning.

Technically, what it does is set bit 7 (‘don’t use Win line metrics’) of the fsSelection field in the OS/2 table. According to the MakeOTF User Guide, this bit was introduced ‘so that reflow of documents will happen less often than if Microsoft just changed the behaviour for all fonts.’

All modern fonts should have this parameter. It tells Office apps to prefer the OS/2 values over the win metrics. So if you do not have a good excuse, add it to your font.

Alas, one good excuse may be that, with this parameter, legacy Office software (i.e., pre-2006) may apply clipping at the OS/2 values rather than at the win values. If you find yourself in the position of needing to support ancient software: Duh. Everyone else is entitled to consider this a problem of the past.

Another problem is that, in Microsoft Office software, values for underlinePosition and underlineThickness are ignored when Use Typo Metrics is on. Even if it is off, and if the underline does not fit above winDescent, it will be raised accordingly. In other words, underlinePosition plus underlineThickness must be smaller than winDescent. If Use Typo Metrics is on, default underline values will be used instead. If you find the correct display of underlines in Microsoft Word more important than proper linespacing, disable Use Typo Metrics, and follow one of the legacy strategies. Most likely the Microsoft Strategy (see below) will be a good idea then.

Strategies

With the custom parameters listed above, you can override the automatic calculation and set the values manually. Let me show you the most popular strategies for manually setting your vertical metrics. First, two historical methods, the Adobe and Microsoft strategies. They are handy to know because you may have to make your font compatible with legacy software. But keep in mind that both of these strategies are outdated because they both adhere to the UPM dogma. Therefore, if you need a good overall compromise for DTP, Office and web use, I recommend to employ the Webfont strategy described below.

Legacy: the Adobe strategy

The hhea values are synchronized with the OS/2 values.

1. hheaAscender = typoAscender
2. hheaDescender = typoDescender
3. hheaLineGap = winAscent + winDescent – UPM
4. typoLineGap = hheaLineGap
5. Font Info > Font > Custom Parameters: Use Typo Metrics = yes

With this strategy, the linegap tends towards the small end of the spectrum. So it may be a good idea to use this method if your font has a low x-height (below half UPM). Advantage: better synchronization of font display between Mac apps and layout apps (XPress, InDesign), and usually tight default leading. Disadvantages: differences between Mac and Win display; accents on caps may be cut off in office apps.

Legacy: the Microsoft strategy

The hhea values are synchronized with win values, thus to the BBox maxima.

1. hheaAscender = winAscent
2. hheaDescender = −winDescent (negative value)
3. hheaLineGap = 0
4. typoLineGap = winAscent + winDescent – UPM
5. Font Info > Font > Custom Parameters: Use Typo Metrics = yes

For the rest, as already mentioned above, the span from typoAscender to typoDescender must add up to your UPM value (usually 1000). You could put the depth of the descender into typoDescender (e.g. −200), you put the rest (800) into typoAscender. In this strategy, the sum of the hhea and win ascender and descender will most likely be much more than 1000, or whatever your UPM is. Subtract your UPM value from that sum and put the result into typoLineGap.

With this strategy, the linegap tends towards the large end of the spectrum. So it may be a good idea to use this way if your font has a large x-height (above half UPM). Advantages: better synchronization of font display between Win and Mac apps; accents are not cut off in Mac apps because winAscent tends to be higher than typoAscender. Disadvantage: differences between Mac apps and layout apps (XPress, InDesign), and default leading may appear to be too much.

The Webfont strategy (2019)

Here, you set the winAscent and winDescent values first, because what is clipped and what not is most important on Windows machines.

On the Mac, the Safari and Chrome browsers use the hhea values for positioning text, regardless of the Use Typo Metrics setting. When text is placed inside an HTML element such as <div> or <p>, these browsers will add hheaAscender plus half of hheaLineGap, and use this to calculate the position of the first baseline in respect to the top edge of the HTML element. Similarly, the distance from the very last line of text inside an HTML element to the bottom edge of the same element is determined by hheaDescender plus half of hheaLineGap. That’s right, the line gap is distributed evenly above and below the line.

Notable exception on the Mac: Firefox respects the Use Typo Metrics setting, and will do the same with the OS/2 typo metrics if it is set, i.e., the first baseline will be put at typoAscender plus half typoLineGap, and the space below the last baseline is equal to typoDescender plus half typoLineGap. If, however, Use Typo Metrics is not set, it will act like the other browsers on the Mac and employ the hhea values.

On Windows, all browsers respect the Use Typo Metrics parameter. If it is set, first baseline will be positioned at typoAscender plus half typoLineGap, and the distance between last baseline and bottom edge will be typoDescender plus half typoLineGap. If, however, Use Typo Metrics is not set, then all Windows browsers will default to the win values. In that case, the first baseline will be at winAscent from the top edge, and the bottom edge will be padded winDescent away from the last baseline.

As a consequence, if we do make use of the Use Typo Metrics parameter as we are supposed to, the win values are now completely independent of the hhea and typo values. So we can use the hhea and typo values for what they were intended for, including the line gap. Simply set the win values to the vertical extremes in your font family, and make sure, like in the Adobe strategy, to sync typo and hhea values. So what we get is this:

1. winAscent = vertical maximum round this value up
2. winDescent = vertical minimum (positive value) round this value up
3. typoAscender = hheaAscender = include important uppercase diacritics (e.g. É, Å, Ñ, Ő, etc., or the letters reaching high above the baseline you care most about) round this value
4. typoDescender = hheaDescender = include descenders completely (the lowest point in j, g, p, q, y, or the letters reaching below the baseline you care most about) round this value down
5. typoLineGap = hheaLineGap = sensible padding between lines: approx 10–20% of the sum of typoAscender and typoDescender, consider more if descenders and ascenders touch each other across lines (in browsers and Office software), less if your ascender and descender values are pretty large
6. Font Info > Font > Custom Parameters: Use Typo Metrics = yes

About finding a proper linegap value (point 5): Simply imagine a word on a button or in a box on a web page. Half of the linegap amount will be padded above, and half below the (OS/2 and hhea) ascender and descender positions.

And if, for whatever reason, you cannot or do not want to enable Use Typo Metrics, you can try:

• typoLineGap = hheaLineGap = (winAscent − typoAscender) × 2

The offset of the first baseline will be consistent even without the Use Typo Metrics parameter. That may make sense if you want to support legacy software as described above. However, the leading may still differ unless the difference between winDescent and typoDescender happens to be exactly the same as the difference between winAscent and typoAscender.

If the calculations lead to large line gap values (anything larger than a fifth of the UPM), consider reducing the line gaps and increasing the hhea and typo ascenders by the same value.

First baseline in Adobe apps

You may do everything right, and still get complaints from users, particularly about the positioning of the first line of text in a text frame. In InDesign and Illustrator, the the first baseline offset depends on the settings in the respective document.

The weirdest thing though is that the default setting, ‘Ascent’, is the measurement of the Latin lowercase d. So, if you need to make sure that your font aligns well with others, and you do not want to spend a lot of your precious lifetime on explaining to Adobe users the two dialogs below, consider synchronising the heights of your lowercase d’s.

Especially if you are making a layered font, and the shapes must align, you may need to make use of the lowercase-d hack. See the Layered Color Font tutorial for details.

InDesign:

In InDesign, select a text frame, and choose Object > Text Frame Options… (Cmd-B), and in the dialog, pick the Baseline Options tab at the top, and where it says First Baseline, you have the following Offset options:

• Ascent: The height of the “d” character in the font falls below the top inset of the text frame.
• Cap Height: The top of uppercase letters touch the top inset of the text frame.
• Leading: Use the text’s leading value as the distance between the baseline of the first line of text and the top inset of the frame.
• x Height: The height of the “x” character in the font falls below the top inset of the frame.
• Fixed: Specify the distance between the baseline of the first line of text and the top inset of the frame.
• Min: Select a minimum value for the baseline offset. For example, if Leading is selected and you specify a minimum value of 1p, InDesign uses the leading value only when it’s greater than 1 pica.

Find more info about InDesign text frames on the Adobe help page.

Illustrator:

In Adobe Illustrator, select a text frame and choose Type > Area Type Options…, and in the dialog that pops up, pick an option in Offset > First Baseline:

• Ascent: The height of the “d” character falls below the top of the type object.
• Cap Height: The tops of uppercase letters touch the top of the type object.
• Leading: Uses the text’s leading value as the distance between the baseline of the first line of text and the top of the type object.
• x Height: The height of the “x” character falls below the top of the type object.
• Em Box Height: The top of the em box in Asian fonts touches the top of the type object. This option is available regardless of the Show Asian Options preference.
• Fixed: Specifies the distance between the baseline of the first line of text and the top of the type object in the Min box.
• Legacy: Uses the first baseline default used in Adobe Illustrator 10 or earlier.

Find more info about Illustrator text frames on the Adobe help page.

TT Zones

If you are exporting TTFs and still experience cut-offs in apps like Microsoft Word, especially with double accents (like the ones in Vietnamese or Pinyin), then try this: First make sure your winAscent and winDescent are properly set, e.g., they encompass the highest and lowest glyphs you want to keep from being cut off. And now, you need TT zones at winAscent and winDescent. These additional zones cause the renderer to include everything up to their position.

If you are manually TrueType hinting, you can add the winAscent and winDescent zones with the TTF Zones parameter in File > Font Info > Masters (Cmd-I).

If, however, you are relying on ttfautohint, there is an even easier way. All you need to do is go to File > Font Info > Exports > Custom Parameters enable the Windows Compatibility option in the TTFAutohint options parameter. Repeat that for every TTF instance, and you are done:

Useful plug-ins and scripts

The plug-in View > Show Vertical Metrics can visualize your custom parameters in Edit view. You can find it in Window > Plugin Manager:

In the mekkablue scripts, you will find Font Info > Vertical Metrics Manager and Test > Report Highest and Lowest Glyphs.

The Vertical Metrics Manager will try and apply the Webfont Strategy as much as possible. It can measure any set of glyphs and determine viable values to some extent. You can edit the values yourself, before you apply them to the font. Extensive documentation is available in the tooltips: if there is a thing you do not understand, just hover the mouse over it for a second or two. Once you run the script functions, the script will document its process in Window > Macro Window.

Report Highest and Lowest Glyphs simply spits out the most extreme glyphs in terms of vertical extension, and writes a small report in the Macro Window. This can be useful for finding good win values.

Whoa. And now, for a coffee break. Or some ice cream. Or both.

Update 2013-05-25: updated to new parameter naming scheme, fixed a few wordings.
Update 2015-07-17: corrected a mistake (typoDescender must be negative), removed Typophile link and reference for version 1.3, added Webfont Strategy.
Update 2016-12-02: added section about TT Zones.
Update 2017-04-25: added note, corrected typo in Webfont Strategy, added Further Reading.
Update 2017-11-30: added note about Use Typo Metrics parameter.
Update 2018-07-04: added link to John Hudson’s Vertical Metrics tutorial.
Update 2018-10-11: changed outdated Wideman link to Wayback Machine.
Update 2019-05-16: added more general variant of Webfont Strategy, made Use Typo Metrics more prominent.
Update 2019-08-20: corrected typos (thanks Nathalie).
Update 2019-09-12: reworked Webfont Strategy (2019), updated spec info about the UPM dogma in Further Reading; updated screenshots; partial rewrite.
Update 2019-10-30: added chapter about Adobe first baseline offsets.
Update 2020-02-18: added Useful Scripts, and a paragraph about underlineThickness and underlinePosition (thanks Henrique Beier.).
Update 2020-03-02: clarified the wording about how the Mac browsers use the hhea values (thanks Nathalie).
Update 2020-03-05: changed defer to differ.
Update 2021-09-12: cleanup and updates for Glyphs 3.
Update 2024-02-20: added note about typo metrics on Apple devices.