Mark Features and Export

Anchor preview and exported attachment are separate checkpoints. The first shows source relationships; the second requires generated or authored layout data in the output font. Check which source the build uses before relying on an attachment seen in the editor.

Compiling Features

The mark feature carries mark-to-base and mark-to-ligature attachment; mkmk carries mark-to-mark attachment. FontLab can generate both from anchors under the export profile’s policy. The Create [mark] and [mkmk] features command creates current-master code for inspection or deliberate editing; it is not an independent handwritten definition for every master.

The OpenType mark attachment choices are Create [mark/mkmk] code if not present, Always create [mark/mkmk] code, and Do not create [mark/mkmk] code. Inspect the chosen profile rather than assuming a universal default. Always create suits deliberate anchor-based rebuilding across masters but can replace custom code. The profile workflow and exact output behavior are taught in Export Profiles.

This generation route creates mark and mkmk; recipe entry/exit anchors do not establish that it also creates curs. Verify or author cursive attachment separately.

Participation and inheritance

In Anchors & Pins, Use in glyph construction enables construction/cloud participation, while Generate mark features controls generated mark features. Cloud on and M off is the Recipes-only state. Caret anchors remain excluded from mark generation.

Check two distinct stages. First, inspect which anchors the composite or auto-layer construction actually inherits from its sources, including their GDEF roles. Second, inspect which resulting glyphs are eligible for generated attachment. A generation filter does not by itself establish that an underscore anchor was inherited.

Preferences > Operations > Features > [mark/mkmk]: only mark/component restricts eligibility during Features-panel generation. The export profile has a separate Use only glyphs flagged as mark/components in feature generation option. When enabled, this allows Mark or Component glyph roles; inspect both settings when using both routes.

For ligatures, preserve missing component slots. An absent receiving anchor does not mean an origin anchor should be synthesized, and sparse numbered families must retain their intended positions.

Source and compiled results

Compiled mark/mkmk preview is separate from Show mark attachment, which uses source anchors. Stale feature code, generation policy, and earlier substitutions can make the results differ.

Opening a production font can reconstruct supported attachment data, but it is not a substitute for the original editable anchor source. Preserve the native font and compare precomposed, decomposed, stacked, and ligature-mark sequences after a round trip. The lookup debugger described in The Lookups Panel can trace the compiled attachment operations; contextual calls are covered in Contextual Substitution.

In Lookups, select a positioning lookup and one of its rules to compare the input on the left with the positioned result on the right. Blue glyphs let you sample different members of a class. Attachment rules identify the anchors used; for mark-to-ligature attachment, choose a Component to inspect the receiving position for that component. If an anchor is reported missing, inspect its glyph and component.

Hand-Written Feature Code

Use explicit FEA or supported lookup editing when the required relationship is not expressed by the ordinary source-anchor workflow. Contextual positioning and specialized lookup organization may need that route.

A literal anchor coordinate in font-level code is fixed unless a supported generation or parameter mechanism supplies a different value. Font Info parameters referenced as ${name} provide an advanced source mechanism, but they require correct values and validation for the intended masters and output. Do not assume that handwritten coordinates interpolate merely because the font contains several masters.

Visual kerning has a separate warning/rebuild path for imported or hand-written kern code. Anchor edits do not automatically rewrite your manual mark or mkmk code. Keep the two representations consistent yourself, or choose a deliberate rebuild policy that replaces the code. This is especially important after generating a current-master feature merely to inspect it and then continuing to move anchors.

The last successful compilation in Features or Lookups determines which document supplies normal previews and font export. Compiling Lookups does not update Features-panel code; compiling Features does not replace the Lookups document. Import or copy between the panels explicitly when you want to transfer an edit.

If a compiled attachment is wrong, identify the document last compiled, the applicable anchor-generation policy, and the glyphs reaching the positioning stage. In the lookup debugger, leave Script shaping on for the selected script and language, enable the relevant features, and test a base with its marks. Select the positioning step to inspect Shift X/Y and Spacing X/Y, then inspect Result for the completed attachment chain. This tests binary positioning; it is separate from the Glyph window’s source-anchor attachment preview.

Other explicit positioning includes single-glyph value records and the optical-bound features lfbd and rtbd. Those can support specialized spacing or margin-alignment behavior, but their presence does not guarantee that an application uses them. Keep such rules separate from the basic mark-generation workflow and test their actual consumer.

For a single or pair adjustment edited in Lookups, the X and Y fields change placement; the width field changes advance. Compare both rule previews, then trace the text run. These stored positioning values do not become separate per-master values merely because you select another master; use the master-specific kerning or anchor workflow when the relationship must interpolate.