Kern On

Kern On is a kerning assistant, as a plug-in for Glyphs, devised and coded by Tim Ahrens.

Kern On user manual

What is Kern On and how does it work?

Kern On is a kerning assistant implemented as a plug‑in for the font editor Glyphs. It aims to do most of the work for you, ask questions as needed, make reasonable suggestions, but accept your personal preferences.

These videos give you a quick introduction:

The Kern On concept

Kern On does not provide fully automatic kerning in the sense that you would give it an un‑kerned font as the only input and get a kerned font in return.

Instead, you set a number of model pairs and say, “Now go on and finish my work.” Hence the name “Kern On”.

The central method in Kern On is comparison. It compares glyphs, pairs, and even comparisons themselves. It detects inconsistencies and removes them by setting autokerning values. In the end, that’s exactly what kerning is: The removal of inconsistencies.

Getting started

To show the Kern On panel, use Edit → Kern On.

The first time you use Kern On on a font, you have two options:

If the OpenType features fail to compile, Kern On cannot start as it needs to analyse the features in order to determine which glyph pairs to autokern. To fix the feature code, go the font info (⌘I) and have a look at the errors you get when pressing the Compile button.

While you are working in Kern On, only the visible pairs from the current edit tab are generated on‑the‑fly. So, Glyphs’ Kerning Window does not provide much useful information. It is best to close it and not worry about it anymore.

Pair settings

Kern On distinguishes between the following types of pairs:

The slider allows you to adjust the pair’s value and also indicates the possible range in which you can set it as a model without creating a contradiction. Kern On will often give you a little more leeway after you have moved the slider to the end, as certain parts of the engine may get adjusted and nearly-conflicting pairs “loosen their grip”. Strictly speaking, this implies that the original boundary was inaccurate, but in practice this behaviour proves to be useful as it gives you an idea when you are leaving the pair’s comfort zone, and start stretching the mechanism.

The little labels below the slider indicate which models define the boundaries. For autopairs, this practically tells you which models have most influence on the autokerning value.

The width of the range – which you can see from the number of tick marks (the little strokes on the slider) – also shows you how “tight the grip” of the models is for the current pair: A large range indicates that Kern On is still somewhat unsure about this value, and it’s often a good idea to set it as a model, to “fill the gap in the cloud of models.”

If you change the value of an auto pair, it gets switched to a model. Did you know? ⌥‑clicking the Model button also sets the pair’s value to zero – this is very handy in practice.

If you cut the number in the kerning value box (using ⌘X) and press enter, the pair switches to Auto – and you still have the old, manually set value in the clipboard. Simply paste it in again to switch back to the original model. Similar to holding the control key, this technique shows the effect on the pair in question – but it also reveals the impact of the model removal on all other autokerned pairs in the tab.

Feedback from Kern On

Finding the necessary models

Responding to the model sugggestions is just one method of setting up the “cloud of models” for your font. Keep in mind that examining proof documents, as you do throughout the design process, remains an important way of proofing the kerning. Of course, this means you need to finalize the kerning and export the fonts from time to time. Once you are happy with the overall look of your proof you probably have enough models. If you spot any irregularities, simply start Kern On again and set an additional model as necessary.

Another technique is to compare the current state to previous versions, or “snapshots”, of your font.

In a sans-serif design you typically have some glyphs (or glyph sides, strictly speaking) that do not need, and should not have, any kerning. The H is a typical example, or the left side of the h and the right side of the d (one could use the lowercase l but it often looks too similar to the uppercase I). The pairs drop-downs reveal potential problems: In the example, the positive kerning in is probably correct (which means our assumption that H must never be kerned was wrong), all zero pairs are also correct, but the negative pairs require attention. Do we need additional models? If the slider for the pair shows many tick marks and zero is within the range, this means we have found a sensible additional zero model. In case you cannot set the zero model without triggering a model removal, you can adjust the spacing (why not use autospacing?) of the glyph instead.

In serif, script or other irregular designs, there may not be any letter that clearly should not have any non-zero kerning. In this case, you may want to set up a non-exporting glyph specifically for this purpose: We can usually find a shape that, in combination with appropriate spacing, leads to zero-value autokerning. A rectangle of cap height or the bar character could work well.

Glyph settings

The sidebearing fields show the same as the info box at the bottom of the Edit view and you can also use the cursor keys to adjust the values. They don’t support for sidebearing formulas, though. There is another important – and very handy! – difference: Changing the sidebearing using the Kern On panel also adjusts the affected models accordingly. For example, if you realize that your C needs a larger RSB, but you have already set CO as a model (and you want this distance to be preserved), you can simply adjust the RSB of the C on the Kern On panel without having to adjust the CO model.

On a glyph level, we have these kerning types:

To show an overview of all glyphs that have No kerning or special spacing, select Show overview from the kerning type pop-up menu. For a more detailed overview of a particular special spacing group, select Show [...] glyphs and models from the menu below.

Sync kerning types from in the menu is a convenient way of transferring kerning types (this stands for No kerning or special spacing) from one file to the other, e. g. from the uprights to the italics. Note that within one file, kerning types are always the same in all masters. It is not possible to set them differently for different masters.

The Pairs drop-downs give you a quick overview of all right-hand and left-hand pairs for the current glyph. They also help you detect glyphs (more precisely, glyph sides) that are too loosely or tightly spaced: If a glyph side has only negative kerning pairs then it is most likely too loosely spaced – or intentionally loose, in which case it needs special spacing. Or, you can look at neutral glyphs (such as H or the right-hand side of d) that should not have any kerning, to find spacing errors or glyphs you need to set up special spacing for.


Did you know? You can also use Kern On to autospace!

The manual way to do this would be to:

Sounds a bit too tedious? Luckily, you can ask Kern On to imitate the process described above: In the sidebearing field, type in the name of a “partner glyph” against which the current glyph should have zero autokerning, and press enter. Kern On will adjust the sidebearing accordingly. What’s more, it tries to pick the sidebearing that results in a “perfect zero”, which is somewhat more refined than simply choosing the middle within the possible range.

You often have more than one partner with which you want to have zero kerning. In a sans, many glyphs are supposed to have zero kerning if they follow the H and the d, for example. In this case, you can enter several glyph names, preceded by slashes, such as /H/d. Kern On will try to achieve zero kerning against all the given partner glyphs but sometimes this is impossible. To specify which of the partners is particularly important, simply enter its name multiple times. For example, using /H/d/d for the LSB of the five, Kern On will ensure that d5 has zero kerning and, if possible, H5 as well. Using several partners has some interesting applications: To autospace a currency symbol, why not enter /zero/⁠one/⁠two/⁠three/⁠four/⁠five/⁠six/⁠seven/⁠eight/⁠nine as partners? (For convenience, you can select the glyphs, right-click and choose Copy Glyph Names → Slashed.) For the LSB, we may want to use /zero several times to give it higher priority, as it is particularly frequent before most currency symbols.

You can also autospace several glyphs at the same time. Why not select all digits and autospace them with /H/d on the left and /H/h on the right?

Note: Currently, this is a one-off operation; Kern On does not remember the zero-partners, and it does not automatically refresh the spacing. This feature will be added at some point.

Font settings

This gives you an overview of all “custom” pairs in the master: The number of models, user‑set auto pairs and independent pairs.

Click on the corresponding arrow to open a new tab with a list of these pairs.

Did you know? Showing the list of models has some interesting uses if you work with multiple masters or fonts.

You can show the models of one master, then switch to another master (or use copy and paste if it is a different Glyphs file) and select the text to see whether all the pairs are also models in this master. Usually, they aren’t, and you may want to select only a certain group of pairs or start at the top and select more pairs (using shift + cursor down) to find the differences. Of course, you can also use your favourite text editor’s diff functionality.

To un-set some or all models, show and then select them and switch them to auto.

To “transfer” all models to a different master or font, show them, go to the other master (or font, using copy and paste), select all and switch the pairs to models. At this moment the new models will have their previous autokerning values. In order to transfer the model pairs’ values as well you could close Kern On and use Glyphs’ Kerning Window (⌘⌥K) to copy and paste all kerning from one master or font to the other. As you start Kern On again, it will use these new values (internally it only stores which pairs are models but not their values; these are taken from Glyphs). Any autokerning values you may have transferred during the process will simply be ignored and discarded. Because of the different shapes and spacing in their “new home”, some models may have to be removed by Kern On.

Keep in mind that Add models and independents from in the menu is often more convenient.

Comparing fonts

If another Glyphs file is opened in addition to the one you are working on, you can select this file from the Compare to menu. Kern On will open a tab that shows the most significant changes.

Note: To get sensible results, the other font needs to be fully kerned:

Kern On will compare the kerning of the other font (as stored in the Glyphs kerning data) to its own current internal mechanism (it autokerns a number of relevant pairs temporarily). Possible adjustments to the sidebearings are taken into account – the comparison does not merely show the raw differences between the kerning values.

Note that the changes you will see are really the most significant changes out of thousands of pairs. You may get the impression that the kerning has changed a lot even though it has stayed 99% the same, just because you are being shown the main changes.

This can be a very useful technique to proof the kerning and to find potential new model pairs. In fact, some of the model suggestions often correspond to the most significant changes shown in a comparison, as these are the pairs that most sensitively react to changes of the autokerning engine.

Autokerning from a different master

Select Autokern from from the menu to have a master kerned entirely from a different master. The latter may be in a different file but it needs to be opened in Glyphs. Kern On will use the autokerning engine (i. e. the models) from the selected master – you cannot set additional “local” models but it is possible to use local independent pairs. One use case for this feature is to autokern the italic from the upright (i. e. the upright’s models). To avoid generating too much non-zero kerning for pairs that are usually not kerned, you may need to adjust the sidebearings (most conveniently using autospacing) of the glyphs.

Did you know? The moment Autokern from is deactivated, local models are generated automatically. You may want to give this feature a try for a certain font or master, and if you find that it needs its own models, just deactivate it, and you instantly have a selection of models with sensible values as a starting point.

Interpolated masters

Interpolate master kerning from the menu is available if there is a master that can be interpolated from the others. A typical case would be a file that contains a light, regular and bold master. You need a regular master because without it, by pure interpolation between light and bold, the glyph shapes of the regular would not look satisfactory. The kerning, however, may often be interpolated without a loss in quality, and you can save the work of setting models for the intermediate master.

Linked masters

If you work with layer fonts, you typically set up the extra masters using the custom parameter Link Metrics With First Master or Link Metrics With Master so as to guarantee they have the same advance width as the main master. This also implies that you want the kerning to be identical. Therefore, Kern On will also treat these as linked masters and they will have the same kerning after finalization.

Finalizing the kerning

While it is running, Kern On only generates the necessary pairs on‑the‑fly: As you type in text, the relevant pairs are kerned.

To generate the full kerning, click the Kern On button and choose the amount of data (in kB) you want to use for the kerning when the font is exported. Did you know? If you enter 0, this means Kern On will not restrict the kerning. It will not generate classes, only glyph-glyph pairs. This is essentially a dump of the internal data before it is compressed via class kerning.

Make sure the limit is not more than 64 kB as this is the technological limit for OpenType fonts, unless you use Extension Kerning.

If you plan to generate variable fonts keep in mind that all masters share the available 64 kB. For example, if your font has 4 masters you should enter 64 kB / 4 = 16 kB as the limit.

For webfonts, you probably want to stay much more compact than 64 kB even though the kerning is compressed along with the other data. Kern On will at some point implement specific strategies to make the kerning data in the font more “compressible” so as to reduce the webfont size (or fit more kerning into a given, compressed, data volume).

Using manually set kerning groups

If you prefer to define the kerning groups yourself, rather than having Kern On automatically generate them, simply uncheck “Re-generate kerning groups”. This can also be used to retain kerning groups previously auto-generated by Kern On.

Keep in mind that while Kern On is running, it is completely unaware of kerning groups. All models are glyph-glyph pairs and all autokerning is done on a glyph-glyph basis. When Kern On starts up, the kerning groups are left as they are but are not used (yet). This is why the question of whether to use (i.e. keep) manual groups only becomes relevant when the kerning is finalized.


Kern On does not support undo via Glyphs’ built-in mechanism, i.e. ⌘Z. Instead, you can undo most actions by selecting Undo from the menu.

Restarting Kern On

After finalizing, or if you simply close the Kern On window, Kern On becomes inactive. It is safe to close and restart Kern On as often as you wish. In fact, it is usually best to close Kern On before you make significant edits to the font, such as adding, removing or renaming glyphs. While Kern On is running, it would not notice these changes to the font and might get confused. Note that modifying glyph shapes or sidebearings is explicitly supported, though. These changes will be noticed and the engine will be instantly updated.

When Kern On starts, all the relevant information in the file is loaded into the engine, which ensures the internal representation is up-to-date. Careful! All kerning except for models and independent pairs is erased the moment Kern On is restarted. After making changes to the models or other settings, click the Kern On button again to generate the full kerning.

Which pairs get kerned

Kern On has a built-in list of Unicode pairs, which it considers relevant in real-world usage. You can find this list in the file pair_frequencies.txt if you right-click on the plugin file in Finder, select Show Package Contents, then open the folder Contents/Resources. This list is the result of extensive research, processing of several text corpora and dictionaries, and careful post-processing to tidy up the data, remove and add pairs. Of course, the built‑in list of Unicode pairs is not beyond all doubt and remains open to refinement. Many users have already contributed to this; if you think any characters or pairs are missing, please get in touch.

In order to include those glyphs that do not have any Unicode value, i.e. those that are only accessible via OpenType features, Kern On then applies the features to the list of pairs to generate all pairs that can occur if the various features are applied. Similar to InDesign, and unlike Apple apps, Kern On assumes that c2sc is always used in combination with smcp and not on its own. tnum aalt ccmp ordn frac and fwid are ignored. Note: Some advanced techniques are not fully supported yet. For example, ignore sub statements are not applied yet, so you may get some irrelevant pairs. As always, you can use independent zero-value pairs to switch them off, or user-set autopairs to explicitly add pairs.

What’s more, the Rename Glyphs custom parameter is also taken into account to generate additional necessary kerning pairs for glyphs that are not otherwise covered via Unicode or OpenType features.

If you need further support

If you have any questions, wishes or comments, feel free to post on the Kern On forum. You can also write an e-mail to

How kerning is stored in an OTF or TTF

As a user, you do not need to know the details of how the kerning will be written into the font file when you export the font. Glyphs and Kern On handle this in the most efficient way. However, user feedback has shown that it can be helpful to understand the inner workings of fonts to avoid being dissatisfied with the results of Kern On, based on a lack of understanding of the technological principles. Therefore, let’s take a closer look at the kerning “under the hood” in a font file.

There are two mechanisms for storing kerning in a font: class-class pairs and glyph-glyph pairs. In Glyphs, the terminology is kerning groups whereas in font technology, we typically refer to kerning classes. They are essentially the same.

In Glyphs’ Kerning Window, you can see pairs that have bold blue partners and start with an @ (class-class pairs), and green-brownish pairs that show the glyph names (glyph-glyph pairs). Furthermore, Glyphs displays a closed lock icon in the info box for class-class pairs, and an open lock icon for glyph-glyph pairs. Don’t be fooloed, though: There is nothing “locked” about the pairs that are shown with a locked icon in Glyphs.

As a side note, Glyphs allows the use of glyph-class pairs but these are expanded to glyph-glyph pairs when Glyphs generates the font, as this concept does not exist in OTF/TTF. This is why Kern On does not generate glyph-class pairs in the first place.

Class-class kerning

In OTF/TTF, class kerning is stored in a 2D table consisting of cells, like you know it from spreadsheet apps. Each kerning class represents a vector (which is shorthand for “row or column”) of the table. Each cell takes up two bytes, no matter whether it is “used” (i.e. non-zero) or not. When the font is exported, Glyphs simply has to fill all cells for which there is no kerning value with zeroes. What’s more, each class kerning cell usually represents many glyph-glyph pairs, as it will be applied to all combinations given in the class members. This has several implications:

As a side note, the class definitions also take up some space. Kern On estimates this overhead (unfortunately, it is impossible to determine precisely because the glyph order is unknown) and takes it into account.

Glyph-glyph kerning

Kerning between individual glyphs is stored as a list, grouped by the first glyph in the pair. First, the first glyph is specified (usually 4 bytes), then each second glyph along with the value (4 bytes). In other words, this uses at least 4 bytes per pair but we only need to write the pairs we really need. As the glyph-glyph pairs are applied last, they can override the kerning values already set via class kerning. This is why they are commonly called exceptions.

Avoiding subtable overflows

The beginning of the GSUB table, which contains the kerning, contains pointers to its internal data subsections, which contain pointers to the subtables. Note that in this case, “table” does not refer to a 2D table. Rather, in font files, “tables” are simply chunks of data that have a specific function. As the pointers cannot point further away than 64 kB, this is the limitation of the kerning data size. (To be precise, there would be very clever techniques that allow using more than 64 kB.)

In the current implementation in Glyphs, it is safest to set a total of 64 kB at most. Otherwise, you may encounter subtable overflow errors during export. Kern On simulates the kerning data in the final OTF/TTF as far as possible but the precise size of the kerning within the exported font is nearly impossible to determine. So, don’t expect the export errors to appear exactly when you switch from 64 kB to 65 kB.


Q: Why doesn’t Kern On autokern my small caps?

A: This probably means that you have not implemented the smcp or c2sc OpenType features yet. Note that Kern On ignores glyph names. Instead, it relies on Unicode values and OpenType features to determine which pairs to kern.

Q: Why does this pair have a final kerning value that is different from the one I can see while Kern On is running (or is even missing)?

A: This is because the algorithm that generates the final class kerning at a given kB size is essentially a lossy compression. If the pair is missing from the final kerning, this means it did not make it into the final list of pairs because it is too infrequent and/or has a small value. Try increasing the kB limit to allow more pairs to be written. Wrong values (sometimes even “added” pairs that should be zero) are essentially compression artifacts. You have probably seen this in strongly compressed JPEG images when we see ripples where there should be a plain, even colour. The lossy compression algorithm seems to “add data” but in fact, we are seeing information the compression did not manage to eliminate (because of the space restriction).

Q: Why does Kern On write this pair as an exception? Class kerning seems more sensible!

A: Most designers, when they kern the font manually, work by the principle of “class kerning first, exceptions later”. Kern On, however, first generates only glyph-glyph pairs and then figures out the most efficient way to write them as a combination of class kerning and glyph-glyph pairs. This sometimes leads to decisions and solutions that look unusual to humans even though they are correct from a rational point of view, considering the storage mechanisms in the exported font. If the effective, final kerning is not flawed then simply don’t worry about it – Kern On knows what is is doing.

Q: Can Kern On please generate all kerning as multiples of 5?

A: Not yet, but this is in the works. Let’s be honest: Isn’t the main motivation for this feature to keep things “pretty under the hood”? This seems to be a strong (though irrational) desire among many designers. In any case, the quantization of the autokerning values (multiples of 5 or something else) will soon be implemented, but for a different reason: It reduces the file size of WOFF and WOFF2 webfonts as it makes the data more “compressible”. At JAF, we have been applying this principle for many years.

Q: Why does Kern On generate so many unimportant pairs with small values? I heard this should be avoided as it takes up space.

A: These pairs with small values (i.e. close to zero) are usually class-class pairs, which means they don’t “use” any space: Omitting those pairs would not free up any space whatsoever (at least in the scenario of uncompressed fonts).

Q: When finalizing, why does Kern On write all models as exceptions?

A: When Kern On generates the full final kerning, it generates class kerning and glyph-glyph kerning. This whole process is somewhat lossy, however: In order to restrict the kerning to the given kB size, not all required glyph-glyph pairs are written. In order to guarantee that the values of the model pairs do not change when Kern On finalizes the kerning and then restarts, they are always written as glyph-glyph pairs. For many pairs, this is unnecessary but it does not do any harm: Superfluous glyph-glyph pairs will automatically be omitted when Glyphs generates the fonts. Knowing this, Kern On is simply too lazy to distinguish necessary and unnecessary pairs, and writes all models, including zeroes, as glyph-glyph pairs.

Q: Why doesn’t Kern On support kerning against the space character?

A: This will be added in the future. We need to figure out exactly what the reasoning is, though. Feel free to contribute your thoughts and ideas.

Q: Why is a model with special spacing removed if it contradicts another pair with different special spacing? I thought this would make them independent.

A: Special spacing is a mechanism to allow a group of glyphs to be more loosely spaced than another group of glyphs. It does not make them completely independent, though. The difference in spacing can be as much as you want; Kern On detects the necessary correction value so that the models with different special spacing do not contradict. Kern On compares all special spaced models, and some of these model-model comparisons show that one special spacing group must be looser than another. However, this system only works if the “order of looseness” of the special spacing groups is clear. In case a certain model-model comparison shows that group A must be looser than B, and another comparison shows that B must be looser than A, Kern On gets confused and it cannot work out the correction for each group. If you have cyclic dependencies and a complex setup of special spacing, involving many groups, it will become very difficult for Kern On to figure out the user’s intention.

These principles help avoid such situations:

Q: Why doesn’t Kern On accept that I just want this pair to be unkerned?

A: First we need to understand what is behind the “I want”:

When we design typefaces, we do two things: Looking and Thinking. Some decisions are based on Looking, such as “The w needs to be a little wider”. Other decisions are based purely on Thinking. While Thinking can be powerful and efficient, it can be

(1) undeniably correct,
(2) nothing but personal habits, or
(3) an error in reasoning.

(1) If, for example, you say, the sidebearings of the m must be identical to the n, based on Thinking, not Looking, then that’s usually undeniably correct. It’s elegant and efficient and more precise than spacing the m by Looking, even if you are an experienced designer.

(2) Personal habits are perfectly okay. If something works for you and it leads to good results, why not develop habits? They can certainly make the design process quicker and more predictable. It’s still important to be aware of what this kind of Thinking is: It’s not undeniably correct, and if Kern On insists on something that contradicts your habits, then you need to be flexible enough to change them. Kern On tries hard to support a wide range of designers’ habits but in the end, there are limits to its flexibility if the paradigm is that the results must be consistent in some way.

(3) Finally, if you prefer to Think rather than Look, there is always the risk that your Thinking is sometimes simply incorrect. We’re human, after all. This is why it is always good to use Looking as an additional means. If you insist that the kerning generated by Kern On for a particular pair is wrong, is this based on Thinking or Looking? Does the space really Look too loose to you, if it has the value given by Kern On? Or do you Think it is wrong? If so, are you sure it’s the type (1) kind of Thinking? In such a case, it is helpful to assume Kern On’s Thinking is more precise. You may want to adjust the sidebearings so that the pair becomes zero, unless that really Looks wrong.

Q: Why does my italic, when autokerned from the upright, get so many non-zero pairs? It is essentially just slanted.

A: If you slant a correctly spaced font then in practice, the spacing is usually still pretty much correct. From a geometric perspective, however, you can’t say that nothing happens to the space between the shapes. One thing is, the distance between the shapes gets smaller if you measure perpendicular, i.e. the smallest distance between the shapes (even though it stays the same if you measure horizontally, of course). Another thing is that the shapes get taller/longer if you measure along the shape (again, of course, they keep their “length” if you measure vertically).

The most fundamental principle of spacing is that tall shapes need more distance between them than less tall shapes. Imagine a purely rectangular/techno sans design. Of course, the P would have a smaller RSB than the D because its front is less tall. To go even further, the typical sans serif T has much smaller sidebearings than the H because its front is much less tall. (When you look at diagonals and rounds the question “How tall is the front” becomes much more fuzzy, this is why the development of Kern On took 4 years instead of 4 weeks. Still, that’s the central principle of the engine.)

Therefore, it makes sense, both from a rational and visual point of view, to say, the slanted italics need a little more space for the flats, given that the spacing is supposed to be exactly as the uprights. (Kern On does not yet support the concept of intentionally tighter italics, like a global special spacing.)

Also, look at the diagonals: After slanting HVH, the angle of the left stem of the V against the H has become larger, it has become more “pointy”. Plus, the tip of the V only faces the H at a point where part of the H’s front is missing: Looking from the tip of the V towards the H perpendicularly you will no even hit any black. On the right of the V, the effects are the opposite. Surely, the white area between the letters is guaranteed to remain the same but if you look very carefully you will see that after slanting, the V is no longer centred in HVH, it needs to be shifted left by a small amount to fix this.