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:

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.

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

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

• Erase all existing kerning (if there is any) and start from scratch. You will be asked to specify a set of initial pairs that are not to be kerned. These will form the initial set of models, each with a value of 0.
• Let Kern On use the existing kerning as a starting point. An initial set of models will be selected automatically. It’s a good idea to work with a copy of the original file, which allows you to compare the new autokerning to the old, manual version.

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.

Kern On distinguishes between the following types of pairs:

• Model: These are set by you, the designer. You usually need 30–100 models per font (per master). Keep in mind that you can also set zero-value models, i. e. explicitly un‑kerned pairs. These zero-models are just as effective at controlling the autokerning as negative or positive models. The models are analyzed (as a group and individually) by Kern On and, together, form the central part of the mechanism that kerns the Auto pairs. Did you know? Holding the control key temporarily deactivates the model and autokerns it. This is an easy and quick preview of what would happen to this model if it was removed.

• Auto: These pairs are autokerned by Kern On by “applying” the model pairs.

• Independent: Use this type for pairs you want to set manually but don’t intend to use them as models. Kern On will preserve these pairs, no questions asked. Note that currently, you cannot set independent pairs between groups of glyphs. This may become a feature at some point.

• Some glyph combinations are simply not in the Kern On system at all. If none of the Model/Auto/Independent segments are active, this means Kern On does not consider this pair worth autokerning, and ignores it.

  You can explicitly switch an ignored pair to Auto so as to ensure it gets autokerned. Kern On refers to this as a user‑set auto pair (think of it as adding it to the list of autopairs for this font). You can undo this by clicking on the Auto button again. Note that you cannot deactivate Auto pairs from the built‑in list of pairs. If Kern On generates Auto pairs that you do not wish to be kerned, you can make them zero-value independent pairs to effectively remove them, or use No kerning for the glyph.

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.

• If Kern On is unable to integrate all models into its engine without contradictions then models have to be removed – they are switched to independent pairs. Click on the arrow to show the pair in the current tab. Did you know? ⌘‑clicking the arrow opens the pair in a new tab.

  If the removed pair is important to you then you can click Try again. Kern On will give it a higher priority and remove another pair, usually the other pair mentioned in the removal notice. Note that you will get precisely the same effect by clicking OK and then switching the pair from independent back to model. The Try again button serves as a convenient shortcut and as a hint to the novice user that persistently setting a model is interpreted as a statement by the user and makes it more likely to preserve the model. Did you know? Clicking Try again multiple times increases both pairs’ priorities. This may lead to the removal of another pair, which allows keep both of the originally conflicting pairs. Sometimes this is a way of finding the real culprit. However, you will often end up with two pairs infinitely removing each other because they absolutely mismatch, and there is no other solution but to remove or change one of them.
  As a side note, the very first time you set a model, it has a lower priority than the existing ones and will be removed in case of a mismatch. In practice, this behaviour has shown to work better than letting a new model instantly remove some old ones. To reset the increased priorities of repeatedly set models, just close and restart Kern On.

  When Kern On removes models it “deactivates” them by switching them to independent. You can consider this to be a “parking” for deactivated models where they retain their original value for reference when you try to resolve the issues. (If they were switched to auto, this information would be lost.) Careful! The independent state of removed models is not meant to be a permanent solution. You should always try to understand and resolve the contradiction so that the removed model can be restored or becomes an auto pair.

• Sometimes, all pairs can fit into the engine but there are some nearly inconsistent pairs, and Kern On will issue a warning. Take these warnings seriously: Often, fixing a warning by removing or adjusting a model makes life much easier as you proceed with your work on the kerning. However, if you are certain that the pairs are correct and necessary for achieving the desired kerning, clicking Ignore is the right choice.

• When there are no warnings to be shown, Kern On has model suggestions, which can help find pairs that could be good models because they:

  • are under-defined, meaning they have a large span (many tick marks), and/or
  • react sensitively to changes in the engine, i. e. show significant change to their autokerning value if models change.

  If you have no strong opinion on the pair in question it is perfectly okay to skip it. You may prefer to focus on pairs that currently don’t have the right autokerning or are important to you in any case.

  Beware: Kern On will not tell you when you have enough models. If you continue playing this game for too long you will end up with more models than necessary.

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 Hî 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.

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:

• Standard kerning is used for letters and other glyphs that have similarly tight spacing.
• No kerning completely deactivates kerning for the given glyph side. This deactivates the autokerning and disables models for this glyph side, but you can still use independent pairs if necessary. A typical use case is tabular figures (in fact, as you start using Kern On with a font, they are switched to No Kerning by default). You may also decide that some glyphs play a typographic role that doesn’t link them to their neighbours, such as section, dagger, bullet or copyright, and should therefore be un-kerned. Careful! No kerning is not meant to be used for letters that should have no kerning. If you notice letter pairs with non-zero autokerning even though you think conceptually, they should not be kerned, don’t use No kerning as a quick fix to eliminate non-zero kerning from certain letters. It is always worth investigating why Kern On gives the pair (or letter side) non-zero autokerning and resolving the issue.

• Use Special spacing for glyphs that intentionally have looser or tighter spacing which you do not want to be “kerned away”. A typical example would be the left side of the exclam, when it is intentionally loosely spaced. Select a group or set up a new one, to tell Kern On that the glyph side has special spacing, and define at least one relevant model (usually a zero model such as H-exclam works best). The amount of special spacing is determined by Kern On internally. You may want to give several glyphs or glyph sides the same special spacing to ensure visual consistency and to reduce the number of necessary models. Being in the same special spacing group does not require having similar shapes at all; it only means all glyph sides in the group are supposed to have the same amount of extra space. Careful! Special spacing is not meant to be used with letters. Use it only gor glyphs that are supposed to have visually looser or tighter spacing. Don’t use special spacing as a hack when letters are kerned in a way that does not suit your taste. Instead, try to solve the issue by setting models or by adjusting the sidebearings.

  Note that positive special spacing loosens negative kerning but it does not make zero or positive kerning even looser. The internal value is not simply added – instead, Kern On “loosens its grip” on the special-spaced autopairs.

  What’s more, Kern On internally treats all uppercase glyphs as one special spacing group even if they are not explicitly defined by the user.

  Finally, note that Kern On recognizes when the special spacing within a particular group is different from the spacing between a group member and other glyphs. For example, in order to create somewhat loosened UC‑UC letterspacing “baked into” the kerning, you could define positive kerning for pairs such as HH, without loosening UC‑LC pairs such as Hn. Another use case: You may want to give generous space for pairs between letter and superior figure (by setting positive kerning for d-twosuperior) but define e. g. onesuperior-twosuperior as a zero pair to tell Kern On that you do not want loosened spacing within the superiors.

  As you start using Kern On with a font, it automatically sets default special spacing groups for your convenience. However, it is usually best to decide for yourself which glyphs you want to have the same amount of extra space and re-work the special spacing accordingly. If you add glyphs to the font when Kern On is already in use, you need to assign special spacing as necessary. In practice, it is usually best to have as few special spacing groups as possible.

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:

• Type a pair that includes the glyph-side in question and should have no (i. e. zero) kerning. For instance, if you want to “manually autospace” the LSB of the s this pair could be ds (at least in a sans).
• Activate the Text tool and move to the glyph you want to autospace.
• On the Kern On window, adjust the sidebearing in question until the autokerning value on that side becomes zero (using the cursor keys up and down is very convenient). Note: If you “manually autospace” the LSB this is the value shown on the Kern On window; if you adjust the RSB you will need to look at the kerning value shown in Glyphs’ glyph info box.
• You will notice that there is usually a certain range for the sidebearing that results in zero kerning because the autokerning engine tends to pick zero if it is within the minimum-maximum span. It’s probably best to choose a value somewhere in the middle of the range.

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.

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.

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:

• either manually – if you switched from manual kerning to Kern On, this is a very insightful technique
• or finalized by Kern On – it is usually interesting to compare the current state to backups, i. e. previous versions of your file.

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.

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.

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.

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.

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.

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.

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 have any questions, wishes or comments, feel free to post on the Kern On forum. You can also write an e-mail to maskme@kern-on.com

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:

• Removing a class-class pair does not save any space whatsoever. Glyphs will write a zero (which also uses two bytes) instead of the removed pair. (The only exception would be removing the last pair in a vector, in which case the latter would be omitted entirely.)
• Sparse vectors are inefficient. If a vector has few non-zero cells and these cells don’t represent many glyph-glyph pairs, it is better to write these pairs as glyph-glyph pairs and omit the whole vector from the class kerning table.
• The number of pairs defined in the font editor (i.e. what you can see when you open Glyphs’ Kerning Window) has no relevance. It does not tell us much about the data size that will be used by the kerning (this will be as specified during finalization), and there is no such thing as “too many” pairs.

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:

• Don’t use more special spacing groups than necessary. You don’t need to group glyphs by semantics or similar shapes. If you want glyphs to have the same visual looseness they should be in the same group.
• Don’t use more special-spaced models than necessary. Usually, it is enough to set one or two pairs against “neutral” letters such as H or the left side of h, and maybe one that controls the strongly kerned pairs such as T- or A”.
• Make up your mind which special spacing group should be visually looser or tighter than the other and set the models that express this. If you are unsure whether one group is tighter or looser than another then consider merging the groups.
• If you encounter unexpected non-zero pairs, consider eliminating the kerning by using autospacing instead of forcing them to be zero via additional models.

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.