Kerning Lookup Subtables in FontForge

Lookup subtables in FontForge play a critical role in organizing, optimizing, and compiling kerning data within OpenType fonts. Kerning information is stored in the Glyph Positioning (GPOS) table, where lookups are divided into one or more subtables to structure pair adjustments and class-based kerning. Managing these subtables correctly determines whether a font compiles without errors, functions efficiently across different text rendering engines, and properly executes complex kerning exceptions.

The 64KB Subtable Size Limit

OpenType layout tables rely on 16-bit internal offsets, which imposes a strict 64-kilobyte (KB) size limit on any single lookup subtable. In fonts with extensive character sets—such as those supporting broad Latin, Cyrillic, or Greek coverage—pair kerning can quickly generate tens of thousands of kerning pairs. If all these pairs reside in a single subtable, the data will exceed the 64KB ceiling, causing FontForge to throw an offset overflow error during font generation or resulting in corrupted GPOS tables. Dividing kerning pairs across multiple subtables prevents this overflow and allows large kerning sets to compile cleanly.

Class Kerning vs. Pair Kerning Structure

FontForge allows kerning to be defined as individual glyph pairs or as glyph classes. Class-based kerning groups glyphs with similar profiles (such as "o", "c", "d", "e", and "q") together, drastically reducing the total number of rules and keeping subtable sizes small.

However, individual glyph exceptions often arise within a class. To handle these exceptions cleanly, FontForge relies on subtable separation:

  • Exception Subtables: Specific pair adjustments that override general class rules.
  • Class Subtables: Broad matrix rules that apply to entire groups of glyphs.

Separating pair exceptions from class kerning into distinct subtables keeps the font’s underlying data structured according to OpenType specifications.

Processing Order and Lookup Execution

The order in which FontForge arranges lookup subtables dictates how layout engines (such as HarfBuzz, DirectWrite, or Core Text) apply kerning:

  1. Sequential Evaluation: Shaping engines evaluate lookups and their subtables in top-down sequential order. Once a glyph pair finds a matching kerning rule in a subtable, processing for that pair typically halts.
  2. Exception Precedence: Subtables containing individual exception pairs must be placed before the subtables containing class kerning. If a class kerning subtable is evaluated first, the layout engine will apply the generic class value and ignore the subsequent exception subtable.
  3. Cross-Script Isolation: Separating scripts (such as Latin, Greek, and Cyrillic) into dedicated lookups or subtables prevents unintended kerning matches and ensures that script-specific shaping features do not interfere with each other.

File Size and Rendering Performance

While splitting kerning rules into multiple subtables solves the 64KB limit, an excessive number of subtables can negatively impact performance. Each subtable introduces its own lookup headers, coverage tables, and offset arrays, which increases the total file size. Additionally, text layout engines must traverse each subtable sequentially; an unoptimized font with dozens of fragmented subtables can introduce measurable layout latency in resource-constrained environments, such as embedded systems or mobile web browsers.

Best Practices in FontForge

To ensure optimal stability and performance when configuring kerning subtables in FontForge:

  • Rely primarily on classes: Build class-based kerning first to keep the subtable count and overall data footprint minimal.
  • Isolate exceptions: Place all pair exceptions in a dedicated subtable positioned immediately before the class kerning subtable within the same lookup.
  • Monitor subtable sizes: If FontForge warns of offset overflows during generation, manually split large class matrices into separate, smaller subtables based on script or frequency of use.