In Part 1 of this 2 part series I covered the kerning list. It detailed how I checked whether things were properly spaced in the first place, and how to figure out which pairs need kerned.
In this post I will cover the rest of the actual kerning process:
- Creating kerning classes in FontLab VI
- The act of kerning itself
The assumption at this point (leaving off at the end of Part 1) is that I have a list of pairs that need kerned.
It was pointed out to me that my method of checking for kerning pairs is a somewhat “brute force” method, checking every single pair. I do this because I’m either incredibly thorough, or I’m an anal-retentive glutton for punishment. Both of these are probably correct.
An alternative method for compiling kerning pairs (after spacing is complete, of course) is to just list glyphs with problematic shapes on at least one side. (E.g.— A, L, P, T, V, Y, etc.)
Regardless of how the kerning list is put together, the rest of this post still applies.
Make Kerning Classes in FontLab VI
Kerning each glyph to each other glyph is tedious at best, and mind-numbingly soul crushing at worst. Thankfully, there’s a bit of a short cut: kerning classes. Does one glyph share the same shape on one side as many other glyphs? Then they can all be added to a class and kerned to another glyph or class of glyphs at the same time. Yay!
For example, the left side of the A in Protest is the same as all 3 of it’s contextual alternates, and also the same as all the A’s with diacritics, plus all of their alternates. That’s 48 glyphs that can all be put in a class and kerned simultaneously!
FontLab has good documentation for using kerning classes, but if you want a pared down process, keep reading.
To add glyphs to a class in FontLab VI start by selecting the glyphs in the Font Window.
Next, go the the Classes Panel and click the + symbol in the bottom left corner.
In the menu that opens, click either “Kerning 1st“ or “Kerning 2nd,” depending on which side the glyph will be on. The blue on the left (kerning 1st) means the glyph is on the left; the green on the right (kerning 2nd) means the glyph is on the right.
Remember: the 1st kerning class (blue on the left) means the glyph is on the left, NOT that it’s adjusting the space to the left of the glyph. Vice versa for the 2nd kerning class. I got this mixed up and had to remake a bunch of my kerning classes.
The class will automatically be named based on the first glyph in the class. The name of the class can be changed in the box at the top of the Classes Panel. Based on the recommendation from the FontLab VI documentation, I’m naming 1st kerning classes (left) with a “kl” prefix and 2nd kerning classes (right) with a “kr” prefix. For instance, “kl_A” is the name of the 1st kerning class with all the A’s.
If I’ve just made a 1st kerning class, then while the glyphs are still highlighted in the Font Window I can go through these steps again for the 2nd kerning class.
Remember that kerning classes are about glyph shape. If a character has the same shape as another character on one side (e.g.—D and Ð on the right side), all those glyphs can be added to the same kerning class, regardless of whether they are the same character. This is because the kerning class only cares about the one side.
Some characters will only need a kerning class for one side (like F), so I had to be sure to reference my kerning sheet before proceeding to make kerning classes for both right and left sides based on my list.
I also thought as I went that some kerning was unnecessary. While noting alternating upper- and lowercase letters on my test sheet, I found myself listing kerning pairs with lowercase letters on the left and uppercase on the right. The only instances I can think of when this might happen are for file names or perhaps hashtags. This seemed rare enough that I declined to create a kerning class for a lowercase character if the only case in which it needed kerning is when followed by uppercase. But then I got to thinking…
As far as finding letter pairs that don’t seem to exist in natural language, I figure, “Why bother?” Just because a letter pair doesn’t occur in natural language, doesn’t mean there isn’t an acronym or someone won’t come up with some strange spelling or make up a new word or name. So instead of using my time researching whether or not I should bother with kerning a specific pair based on whether it occurs naturally, I’m just going to kern every combination that needs kerning, even the lowercase followed by the uppercase. Given that I’ve put quite a bit of time into spacing things properly, this shouldn’t appreciably increase the workload.
I only need to make kerning classes for character groups, so much of the punctuation (which has no duplicates… sorry) will not need classes. However, some of the punctuation shares a shape (or at least a similar interaction) with each other (like . … , ). For those I do need to make kerning classes.
Side note: I’m writing about my process as I go in order to better document things. It’s astounding the number of things I’ve figured out I need to do simply because I chose to write about it. Process documentation isn’t required for any project, but boy howdy is it highly recommended.
Ready… Set… Kern!
So I have over 100 kerning classes. Now what?
I need to go back to my kerning list. All of the kerning pairs are written down, but I need to place them in a new context to kern them.
Kerning is like spacing: the space between the kerning pair needs to match that of the H O and n o. So I want to type out my list in the context of on and OH, with these key letters on either side. The uppercase pairs will be in between OH and HOH, and the lowercase in between on and non. For uppercase paired with lowercase, I’ll check against both OH and on.
So I end up with a list that contains sets like this:
Now in FontLab I can select the Text Tool (the T in the toolbar) to open up a Text Window. I can use my contextualized list to copy a few lines at a time and paste them into the Text Window.
Then I can select the Edit Kerning Tool from the Toolbar (the AV icon) to switch to kerning mode. Once there, I can click in between the pair to be kerned to select that pair. This will highlight the pair with a green line underneath them. They are now ready to be kerned.
In the middle of the top of the Kerning Window is a glyph or class name followed by a white text box followed by another glyph or class name. Names of kerning classes will be bold. This is the pair that’s been selected, and the text box will contain the number of units the pair has been kerned, as well as an × to delete the kerning pair. (It will be empty if the pair is unkerned.)
If I have the “Show spacing controls” icon in the upper left selected, then it will show a little house-shaped “thumb” below the selected pair. This can be clicked and dragged to adjust spacing. However, I prefer to use the arrow keys. By using the left and right arrow keys I can increase or decrease the amount of spacing in between the glyphs, which shows in the box at the top. By holding Shift while using the arrow keys it will increase or decrease the kerning in 10 unit increments.
Now I just adjust that number until it looks right, in the same way I’ve been spacing the font.
Once I’ve done the pairs in the window I can go back to the Text Tool by hitting T key, then delete these pairs and copy and paste in the next set of pairs from my list.
After I’ve finished kerning everything that needs kerned using the font software, I have to generate the kerning feature and compile it into the font. Remember, kerning is a positional OpenType feature, just as the contextual alternates and such are replacement OpenType features.
From the FontLab documentation:
- Open the Features panel (Window > Panels > Features)
- In the panel’s “hamburger” menu, select Create [kern] feature.
- Click on Compile triangle button and preview your kerning working in the Glyph Window or the Preview panel.
Test, test, and test again… ad nauseam
Once I’ve compiled the features, I can export the font and test it again, just as I did when checking spacing and making the kerning pair lists on paper. In fact this whole process is that same as in Part 1, but I’m no longer checking for spacing patterns, just checking kerning.
In addition to printing the exhaustive lists, I can print sample texts to check text color in the context of real or simulated language that includes kerning pairs. For a look at good ways to test for typographic color, check out my post on Testing, Specimnn Sheets, & Typographic Color.
While these are good ways to test, they aren’t the only ways. It’s also good to print kerning pair sheets and other specimens out at different sizes. If this gets too overwhelming (and believe you me, I got total tunnel vision and became fairly overwhelmed), remember that so much of type these days is viewed digitally. So simply checking out the kerning on screen will get me more than halfway there.
Some other good tips Thomas Phinney shared with me:
- Show your font to other people. Get other eyes on it for a fresh perspective.
- Take a break. Tunnel vision is a real thing, and sometimes type just needs to “season” for a while (even weeks or months) before being viewed again with new eyes.
- It doesn’t hurt to compare the kerning to other similar typefaces. It’s not cheating to take a look at what others have done. There’s no need to re-invent the wheel.
This advice is difficult for me to follow, because I tend to like doing things the hard way, and I’m used to being a solo actor. But I’ve also learned that going out of my comfort zone and expanding on my usual way of working is one of the best things I can do for my work.