Kerning, GPOS, and the kern Table

The editable kerning in FontLab can produce two different kinds of output data: the modern GPOS kern feature and, where needed, a legacy kern table. Their shared name does not make them the same structure or give them the same capabilities.

Visual Kerning and the kern Feature

The normal route is to let FontLab build the GPOS kern feature from visual kerning and classes. A Features-panel kern entry is not required just to make ordinary pair kerning export.

Use an explicit feature when you need behavior beyond the visual pair model, such as contextual positioning. In the Features panel, Create [kern] Feature creates source from the current master's kerning; an autofea wrapper can manage generated portions as described in Generated and Conditional Substitution. Keep the original project before taking over that source: the export profile's kerning-generation policy determines whether explicit code is retained or rebuilt.

A simple hand-authored pair rule looks like this, assuming both glyphs exist:

feature kern {
    pos A V -70;
} kern;

The scalar adjusts horizontal advance for the pair's first glyph. A positioning value record makes the fields explicit:

feature kern {
    pos A V <0 0 -70 0>;
} kern;

Those fields are X placement, Y placement, X advance, and Y advance. These two examples are alternatives, not two corrections to apply together.

Add contextual positioning deliberately

A contextual lookup can apply a narrower adjustment than a simple pair:

lookup ShortenO {
    pos o <0 0 -15 0>;
} ShortenO;

feature kern {
    pos T o' lookup ShortenO period;
} kern;

This example adjusts the advance of o when the current run contains T o period. It requires all three glyphs and the named lookup. The apostrophe marks the glyph receiving the operation; the surrounding glyphs supply context.

Custom positioning can coexist with suitable generated source, but check lookup order and cumulative adjustments. Two active lookups can both affect the same glyphs. A context-specific adjustment is not automatically a replacement for every earlier kerning value.

Keep master and output scope clear

Feature source is font-level. A literal -70 does not become a separate Light and Bold value when you switch masters. Use visual kerning for the ordinary varying pair data. Supported Font Info parameter expressions offer an advanced way to supply master/instance-dependent values in explicit source, but that requires a deliberate parameter setup and output checks.

The variable-output pipeline can rebuild positioning from master data rather than preserving a manually captured current-master kern definition. Do not assume a custom static feature will be interpolated or retained unchanged in a variable font. Verify the actual exported lookups, and keep a static-instance route when fixed custom code is the intended result.

Compile before proofing explicit code and inspect the Output panel. When testing the compiled kern feature, distinguish it from the visual-kerning preview so the displayed result is not interpreted as evidence for the wrong representation. If a decompiled or manual feature has become stale after visual edits, remove or regenerate it deliberately rather than leaving two inconsistent sources.

Legacy kern Table Support

Some older consumers require the legacy TrueType kern table instead of GPOS pair positioning. FontLab provides a legacy-kerning export option for that compatibility case; see Export Profiles. Recall the production-format and save/export distinction in Understanding Font Formats. The legacy table used by this workflow represents flat pair data, not the full class/contextual authoring model.

Legacy kerning only for encoded glyphs is an export restriction: when enabled, pairs involving unencoded glyphs are omitted from that legacy output. It is not a fundamental statement that the table's glyph identifiers can never refer to an unencoded glyph. Disabling the restriction can include more pairs, subject to the profile's limits and the consumer's capabilities.

Class-based source kerning may need expansion into individual pairs for formats without suitable class positioning, including Type 1 workflows. That can increase output size substantially. Contextual or richer GPOS positioning does not automatically reduce to an equivalent legacy pair list.

Choose legacy support for a known requirement and test that consumer. Keep the source's class model for editing, and inspect both modern and legacy behavior if both forms are delivered. Enabling an additional table is not proof that every application will select the same kerning data or reproduce the same result.