The Process Architecture
OpenType Layout organizes behavior through features, lookups, and rules. Understanding their different roles helps explain why enabling a feature may not produce the result you expect, and why changing a source-code block's position is not always enough to change processing order.
Features, Lookups, and Rules
The OpenType features introduced in Font Structures consist of individual units: a feature identifies a typographic behavior with a four-character tag, such as liga for standard ligatures or kern for kerning. The application and shaping engine decide which features apply to a text run according to script, language, variation state, and user settings.
A lookup is a unit of layout processing containing a particular kind of substitution or positioning operation. A rule describes the specific glyph input and result within that operation. One feature can use several lookups, and several features can refer to one lookup.
Think of the feature as the offered behavior and the lookup as the work used to implement it. A feature name by itself does not contain the drawings, invent replacements, or determine every aspect of execution.
Order follows the compiled lookups and shaping stages
The shaping engine applies features in stages appropriate to the script. Within a stage, the compiled lookup order matters. Feature blocks in source code can influence how that lookup list is built, but the visible order of feature names is not an independent execution script.
Misordered dependent lookups can prevent a later rule from seeing its intended input; the demonstration and authoring discipline are taught in Substitution Lookups.
Named lookups identify the operations associated with features. When several active features share a lookup in the same stage, do not assume the engine applies a separate copy merely because the lookup is mentioned several times.
Contextual lookup calls and script-specific stages add another level of control. Inspect the compiled behavior with a concrete input string rather than trying to infer it solely from the arrangement of panel entries.
Substitution and Positioning
GSUB, the Glyph Substitution table, changes glyph identities or sequences. It can replace one glyph with another, combine several into one, split one into several, or provide alternate choices. It does not directly store the position adjustments performed by GPOS, although replacing a glyph can naturally change the resulting advance or outline.
GPOS, the Glyph Positioning table, adjusts placements and advances and establishes attachments. It works on the resulting glyph run without using those operations to replace its glyph identities.
The typesetter analogy from Shaping Text separates choosing forms from placing them. A shaping engine develops that separation through ordered stages. The following is a conceptual model; script-specific processing can refine the sequence:
| Stage | Purpose |
|---|---|
| Pre-processing | Early required variants, localized forms, and composition-related substitutions |
| Reordering | Script-dependent preparation of the glyph sequence |
| Topographical | Positional forms, such as isolated, initial, medial, and final forms |
| Typographic | Contextual forms, ligatures, and applicable user-selected alternatives |
| Positioning | Kerning, cursive connections, mark attachment, and other placement adjustments |
The substitution stages produce the glyph sequence on which positioning operates. The source drawings and rules must therefore cover the forms that survive those earlier stages. A positioning rule for an original glyph cannot be assumed to cover a replacement simply because the two drawings represent the same character. The engine's script model determines applicable stages; the font supplies their rules.
Follow a small-cap sequence
Consider text containing f and i. The initial mapping produces the glyphs associated with those characters. If a small-caps feature is enabled and its rules run first, the sequence might become f.sc i.sc. A later ligature lookup must then recognize that sequence if you want a small-cap ligature.
If a ligature lookup runs on f i before small-cap substitution, it may instead produce f_i. The small-caps processing then needs an appropriate rule for that ligature. Merely having separate f.sc, i.sc, and f_i.sc drawings does not connect all of these paths automatically.
The example is a model of dependency, not a universal promise that smcp always precedes liga. The actual feature stages, lookup order, and authored rules determine which path is used.
Once the substitutions are complete, positioning must support the glyphs that are present. A ligature has its own advance and kerning needs. Combining marks need appropriate base or ligature attachment data. That is why substitution testing must be followed by spacing and attachment testing.
For complex scripts, the engine can organize several substitution stages, including localized forms, composition, reordering-related substitutions, and positional forms, before final positioning. A font's rules participate in that script process; they do not replace the engine's script model with an arbitrary list of feature toggles.
Classifying Glyphs
GDEF, the Glyph Definition table, describes functional glyph roles used by layout processing. These roles help the engine interpret lookup flags and identify marks for the attachment workflows in Attaching Marks. GDEF also stores ligature caret positions, which give a text cursor stopping points inside a ligature. FontLab represents supported caret positions as anchors named caret_1, caret_2, and so on, as introduced in Anchors for Positioning. Supported GDEF carets are imported as those anchors and written back on export; the round trip is developed in Authoring OpenType Layout.
| Role | FontLab label | Virtual tag |
|---|---|---|
| No assigned role | Unspecified | @otnone |
| Ordinary base glyph | Simple | @otsimp |
| Ligature glyph | Ligature | @otliga |
| Combining mark | Mark | @otmark |
| Component-role glyph | Component | @otcomp |
FontLab can assign glyph-definition classes automatically and exposes Auto Glyph Definition Class in the Glyph panel. Inspect those assignments when the font has unusual construction or naming. A mark's role should be consistent with the layout behavior it needs.
The GDEF Component role is not simply a count of FontLab components inside a composite drawing. GDEF describes a glyph's role in layout; FontLab components describe how its outline is constructed.
These glyph-definition classes are also different from FEA @-classes, which group glyph names for writing rules. An @Vowels class does not make its members marks or ligatures. The virtual tags introduced in Tagging Glyphs can expose GDEF roles as input sets for feature authoring, but the classification and the authoring set remain distinct mechanisms.