Generated and Conditional Substitution

FontLab can generate many substitution rules from glyph names. Use that automation for predictable relationships, then inspect the code and add the script, context, and variation behavior that the design requires.

Making an alternate available

Suppose you have drawn two forms of a and want the reader to choose between them. Keep the default glyph named a and name the alternate a.ss01. The suffix associates the alternate with the first stylistic set, ss01. Both glyphs need drawings; feature generation supplies the rule that selects the alternate.

Open Window > Panels > Features.
Use the + menu to add the available generated ss01 feature. Add Auto Features in the panel menu can instead add all applicable features from your glyph set.
Select ss01 and look for sub a by a.ss01; in its code. This means “replace glyph a with glyph a.ss01.”
Click Compile features and check the Output panel. Resolve compilation errors before testing.
Type ordinary a characters in the Glyph window or Preview panel, then turn ss01 off and on in that view's Features selector.

The drawing should switch between your two forms while the typed text stays the same. If it does not, check the names, the compilation result, and the feature setting in the view you are using. Displaying a.ss01 directly shows its drawing, but does not test the substitution.

The Autofea System

Autofea manages marked regions of feature source. A generated block begins and ends with comment lines:

#> feature

#< feature

When you update the block, FontLab regenerates its contents. Code outside those delimiters is retained. The delimiters are comments to an ordinary FEA compiler, but FontLab reads them as instructions about which source it manages.

The feature list distinguishes generated and manual states. A filled star indicates an autofea block is present. An outlined star indicates that generation is available although the current definition is manual. No star means there is no current managed block or applicable generation route indicated for that entry.

The list indicator is different from the toolbar's generation action. Clicking Autogenerate code for selected features can replace manual definitions with generated ones; do not use it as though it merely inspects their status.

Three routes begin generated work:

Add Auto Features in the local menu adds applicable features from the current glyph set.
The + menu offers individual features that can be generated.
An empty feature can be generated afterward when FontLab has the necessary source glyphs and generation support.

Inspect the code after adding it. A suitable suffix identifies a candidate relationship; it does not establish that the replacement drawing, spacing, or feature interaction is correct.

Naming Glyphs for Autogeneration

The basic pattern is basename.suffix alongside the base glyph. For example, a suitable small-cap suffix lets FontLab generate a relationship from a base letter to its small cap.

A double dot separates a compound base from another feature suffix. In a.smcp..ss01, the intended base for the stylistic-set step is a.smcp. The generated ss01 relationship can therefore act on a glyph already reached through small-cap substitution.

Common naming relationships

Feature	Source naming used by generation
`smcp`	`.smcp`, or shared small-cap conventions such as `.sc` and `.small`.
`c2sc`	`.c2sc`, with supported `.sc`/`.small` relationships for capitals.
`case`	`.case` or `.cap`.
`ss01`–`ss20`	Matching `.ss01`–`.ss20`; supported `.alt1`–`.alt20` conventions.
`salt`	Suitable stylistic-set alternates, `.alt`, and numbered alternates such as `.1`.
`swsh`	`.swsh`.
`locl`	Language/script naming such as `.loclTRK` or `.latn.TRK.locl`.
`sups`	`.sups` or `.superior`, with supported encoded superscript fallbacks.
`subs`	`.subs`, with supported encoded subscript fallbacks.
`sinf`	`.sinf` or `.inferior`, with supported subscript fallbacks.
`ordn`	Recognized ordinal-related glyphs such as `ordfeminine`, `ordmasculine`, and `numero`.
`init`, `medi`, `fina`	Corresponding positional suffixes on the base glyph names.
`liga`	Recognized standard ligature names, or underscore-separated names with `.liga`.
`dlig`	Other suitable underscore-separated ligatures, or an explicit `.dlig`.
`rlig`, `hlig`	Suitable underscore-separated ligatures with the corresponding explicit suffix.
`frac`	Numerator/denominator forms with `slash` and `fraction`, or recognized prebuilt fraction glyphs.

These are generation conventions, not syntax that a shaping engine reads from glyph names. Inspect the actual generated rules when using synonyms, compound names, or a glyph set with missing bases.

Standard ligature conventions include f_i, f_l, f_f, f_f_i, f_f_l and established names such as fi, fl, ff, ffi, and ffl. Other recognized standard names include f_b, f_f_b, f_f_h, f_f_j, f_f_k, f_f_t, f_h, f_j, f_k, and f_t. An arbitrary combination such as Q_y normally belongs to the discretionary route. An explicit suffix can override that assignment: Q_y.liga, f_i.dlig, or a .rlig ligature states the intended feature.

Coordinate the figure styles

Figure generation considers height/style and spacing together:

Convention	Intended combination
`.lf` or `.lnum_pnum`	Proportional lining
`.osf` or `.onum_pnum`	Proportional oldstyle
`.tf` or `.lnum_tnum`	Tabular lining
`.tosf` or `.onum_tnum`	Tabular oldstyle

Individual suffixes such as .lnum, .onum, .pnum, and .tnum are also used. Check all combinations you intend to offer. Enabling tabular figures should not accidentally discard the user's oldstyle choice merely because one conversion path is missing.

For contextual fractions, prepare the .numr numerator and .dnom denominator forms, the fraction slash, and the ordinary slash that the generated rules expect. Without that material, generation may instead use recognized prebuilt fractions such as onequarter, onehalf, or threequarters. Test arbitrary digit sequences separately from those prebuilt cases.

Updating, Mixing, and Freezing

After adding or renaming glyphs, select the relevant features and use Update selected auto features. Use Update Auto Features, or the supported Alt action on the update control, for all managed blocks.

For example, after adding a drawn b.ss01 alongside b:

Select ss01 in the Features panel.
Choose Update selected auto features.
Inspect the code for the new b relationship.
Compile again and test ab with ss01 off and on.

The Features menu includes the automatic-feature commands and the Update on Compile setting.

The Features menu includes the automatic-feature commands and the Update on Compile setting.

With Update on Compile enabled, FontLab refreshes managed source when you compile in the Features panel. It keeps generated relationships current but adds work to the compile path and can replace edits made inside a managed block.

Keep manual rules outside managed blocks

A generated and manual feature can coexist:

feature ss01 {
    #> feature
    sub a by a.ss01;
    #< feature

    sub c by c.swash;
} ss01;

FontLab can regenerate the marked a relationship while retaining the manual c rule. Check for duplicate or competing inputs after an update; preserving the manual text does not guarantee that it still combines correctly with the new generated text.

To add managed content to an existing manual feature, insert an empty #> feature / #< feature block at the intended position and update it. This is safer than replacing the entire definition and assuming its custom structure will be recovered automatically.

To freeze generated code, remove the delimiter lines, or use the disabled markers #/> feature and #/< feature. The rules remain ordinary source, but routine block updates no longer regenerate them. A later deliberate whole-feature autogeneration can still replace a manual definition; freezing is not protection against that explicit action.

Keep source history when switching between managed and manual code. Restoring the active delimiters and updating them gives control of that region back to FontLab.

Positional Forms for Complex Scripts

Generated init, medi, and fina rules are a starting point for script support. A complete Arabic design also needs appropriate joining glyphs, language coverage, mark handling, and testing with the shaping engine's Arabic process.

Declare the supported language systems in PREFIX. For example:

languagesystem DFLT dflt;
languagesystem arab dflt;
languagesystem arab URD;
languagesystem arab FAR;

Use a named lookup to give the positional rules a clear scope. The following is a small structural example requiring uni0628 and uni0628.init; it is not a complete Arabic font:

feature init {
    script arab;
    language dflt;
    lookup InitArabic {
        lookupflag IgnoreMarks;
        #> feature
        sub uni0628 by uni0628.init;
        #< feature
    } InitArabic;
    language URD exclude_dflt;
    lookup InitArabic;
    language FAR exclude_dflt;
    lookup InitArabic;
} init;

Keep the managed block inside the selected feature definition and put the script, language, and lookup structure outside its delimiters. Updating the generated substitutions then retains that surrounding organization.

IgnoreMarks controls how a lookup treats glyphs classified as marks. Correct GDEF classification remains necessary. You may encounter RightToLeft in older templates, but that lookup flag does not set GSUB text direction: its defined effect concerns cursive positioning. Arabic direction and joining analysis come from the shaping context.

Add Urdu or Persian language behavior according to the glyphs and localized substitutions the font actually supplies. Declaring a language does not draw its required forms or prove the script support complete.

FontLab does not auto-generate isol; add an empty feature named isol through the + menu and author its rules where needed. This completes the positional-form offering introduced in Substitution Features. Test joining and nonjoining neighbors, intervening marks, and language-specific forms. Use script-aware feature selection, not a generic word-initial interpretation of every init rule.

Conditional Substitution

A heavier part of a variable font may need a different drawing altogether. For example, you might draw dollar.heavy to replace dollar from weight 700 upward. This uses a conditional tag on the replacement glyph.

For a font whose weight axis code is wt and whose design range extends below and above 700:

Prepare an encoded dollar and a drawn dollar.heavy, with suitable master compatibility, spacing, and anchors.
Select dollar.heavy and add the tag dollar~wt>700 through the Glyph tags field or the Classes panel's Tags mode. In an additive tag-entry field, enter +dollar~wt>700.
Preview text containing $ below, at, and above weight 700.
Check the spacing and any mark attachment, then test the exported variable font too.

In FontLab's tag syntax, wt>700 includes the boundary: the replacement applies at 700 and above. The values are design coordinates for the named axis. Switching Glyphs Dynamically covers the complete tag syntax and the choice between early ~ and later ^ substitutions.

Conditional glyph tags describe designspace regions, while feature code describes the substitution actions. On variable TT or PS export, FontLab converts tilde tags to the GSUB rvrn feature for early required variation, and caret tags to GSUB rclt by default, or the configured target feature for later behavior.

An ordinary sub a by a.alt; rule contains no axis-range condition. Writing it inside a feature named rvrn does not by itself reproduce the tag's condition set. Use FontLab's conditional-tag workflow for its supported source-to-variable-output path; do not assume every external compiler's extended variation syntax is supported by FontLab's FEA editor.

The tag mechanism describes one-glyph-to-one-glyph replacements. A conditionally changing ligature operation is a more advanced GSUB variation construction, not a longer string of glyph names before the tag marker. It can require direct table-level work, such as a deliberately authored GSUB/TTX workflow, with careful preservation through export.

Test conditions together with other substitutions. A later rule needs the glyph produced by earlier processing, and an early replacement may require corresponding small-cap, figure, or ligature rules. Static character remapping and variable shaping are different output paths, so check the intended one explicitly.

Keep the native source and verify any import round trip. Recovered tags or decompiled feature text do not alone establish that every original condition, lookup association, or engine-dependent behavior was preserved.

Autogeneration of kern, mark, and mkmk is GPOS work, taught in Kerning, GPOS, and the kern Table and Mark Features and Export. Per-format resolution of conditional features is covered in OpenType, Variable, and Web Fonts.