Anchors for Positioning

An anchor is a named point in a glyph that defines an attachment position. A guide gives you a line to align to; an anchor gives a component a point to meet. Placing those points deliberately lets many composites share the same attachment decision.

Anchors refine placement. A recipe or an Add Component operation still determines which glyphs are present in the construction.

Anchors as Attachment Points

The usual pairing rule is a plain name on the base and the same name with a leading underscore on the mark. A base's top pairs with the mark's _top. Positioning translates the mark so that those two points coincide.

The names can describe other attachment sides or purposes: bottom/_bottom, left/_left, or a design-specific pair such as ogonek/_ogonek. The name establishes the relationship; the coordinates establish where it happens. A top anchor need not sit exactly on the outline's topmost node.

Add and name anchors

Open the base glyph and choose Glyph > Add Anchor (Ctrl+R on macOS), or use + in Window > Panels > Anchors & Pins. The ordinary automatic route offers familiar names such as top, bottom, left, and right, using a corresponding underscore form for a glyph recognized as a mark.

FontLab checks the existing anchor names when choosing a default. Do not rely on the number of times you have invoked the command: deleting or renaming an anchor can change which name is available next. When the ordinary names have been used, a count-based name such as a5 can be supplied. Inspect and rename it to the intended attachment name.

With the Guides tool, Shift-click places an anchor at the pointer position. Its proposed name depends on position and context. Add Control to suppress snapping during placement. For a reproducible attachment pair, always check the resulting name rather than relying on automatic naming.

Create top in the base and _top in the mark, then position each at the point that should meet. If the mark already has another anchor, check which name it represents before adding a duplicate.

For an explicit custom name, use Add Named Anchor…, then inspect the name and placement on the glyph.

Read and edit the anchor

Anchors commonly appear as red rhombi with labels; automatically named anchors can use directional triangles, and appearance can be customized. Shape and color alone do not define the pairing. Read the name.

The Anchors & Pins panel has two participation controls beside the anchor name. The cloud button, Use in glyph construction, enables ordinary construction and Anchor Clouds. The M button, Generate mark features, includes the anchor in generated mark and mkmk features; it is available only while the cloud button is enabled. Generated mark features are covered in Mark Features and Export.

State	Cloud button	M button	List marker
Active	On	On	Filled
Recipes only	On	Off	Filled with a white center dot
Deactivated	Off	Off	Outlined

Use Recipes only for an attachment needed during construction but not in generated mark positioning. These states are retained in VFC and VFJ sources; older saved fonts retain their previous behavior. After changing participation, inspect affected recipes before rebuilding; the interaction with explicitly named deactivated anchors still needs checking.

Click the anchor to select it. Option/Alt-click its label when several points coincide and the name is easier to target. Click the name to rename it, or edit the panel's Name field and confirm with Return/Enter.

Drag with the Contour or Element tool, or use arrow-key movement, to change its position. Select anchors without contour points when applying Contour > Align Points to the anchors alone. Follow Italic Angle can affect vertical arrow movement, so check that setting when an anchor moves diagonally.

Before renaming or removing an attachment anchor, check which recipes and components use its name: they may no longer find the intended attachment point. Delete a selected anchor with Backspace/Delete or the panel's − control.

Copy anchors between glyphs

Select only the required anchors and choose the contextual Edit > Copy Anchors/Pins, then paste into the target glyph. Check the pasted names and positions. A mixed contour-and-anchor selection has a broader clipboard payload.

From the Font window, copy the source glyph, select the targets, and use Edit > Paste Special with Anchors selected. Review its replacement and scope options before applying. This is useful for a related set of bases, but a copied coordinate is only a starting point when the outlines have different proportions.

Position anchors with expressions

An anchor position can follow a design relationship instead of a fixed coordinate. Select it and use the calculator-marked location-expression controls in the panel or property bar.

For a point halfway across the advance and 40 units above the cap line, use:

Field	Expression
X expression	width / 2
Y expression	caps_height + 40

Enter the horizontal and vertical formulas in their separate expression fields. A vertical guide can supply an x reference; a horizontal guide can supply a y reference. For example, a y expression (topguide + bottomguide) / 2 follows the midpoint of those two named horizontal guides.

origin supplies the horizontal origin reference, width the advance boundary, and baseline the vertical zero reference. These are location expressions, so use their spelling and coordinate context rather than the different named-position syntax of a recipe. Check the referenced name and its coordinate context if the result is not as expected.

The Anchors tab shows named attachment points and their coordinates. This example also uses expressions to position them.

An expression-driven anchor can move when the source metric or guide changes. A small indicator beside the anchor can identify the coordinate with an expression. Inspect both its formula and evaluated position before trying to correct it by dragging.

Anchors also provide data for OpenType mark positioning. That is a separate output workflow: adding anchors or assembling a composite does not itself guarantee that the exported font has the required mark or mkmk lookups.

Construction Grammar for Anchors

In modern Glyph Construction syntax, an anchor name is another argument to @:

aacute = a + acutecomb@top

To try this construction, first create and position top in a and _top in acutecomb. Open Font > Build Glyphs… > Custom, turn off Use simple (FLS5) syntax, and enter the recipe. Review the generation options before building; if aacute already exists, rebuilding replaces its current content.

Here FontLab aligns the mark's _top with the base's top. Built-in alias.dat recipes use this same @top relationship: the rule, recipe, and designer-placed anchors cooperate in one construction mechanism. Inspect the resulting accent position against those two source points. The recipe still names both components. In an auto-layer recipe field, enter the construction with the leading syntax marker, for example = a + acutecomb@top.

Use matching, deliberately placed anchors in both sources. A missing name can lead to another named-position fallback or an incomplete result; a plausible-looking accent is not proof that the intended anchor pair was found.

Choose a particular attachment pair

When several base positions need the same mark anchor, an explicit mapping can identify both names:

ligature.marked = f_i + acutecomb@top_2[_top]

This aligns the mark's literal _top to top_2 in f_i. The source ligature must contain that anchor. The bracket form belongs to modern Glyph Construction syntax, not the legacy FLS5 syntax. Plain @top is the usual pairing represented explicitly by @top[_top]. Mapping the names separately avoids adding a helper _top_2 anchor to every mark used on a numbered ligature. Such a helper would also enter generated mark features, so an explicit mapping avoids that unwanted extra attachment name. The same notation can make a construction clearer than depending on whichever matching name is encountered first.

A later component normally refers to the preceding component. To return to an earlier base, name it explicitly before the position, such as @f_i:top_1[_top]. This matters when placing more than one mark around a ligature rather than stacking every mark on the last one.

Anchors in the built glyph

Attaching a mark consumes the two anchors used for the match: they no longer appear as that pair in the built glyph. Other anchors remain available, and a mark can pass the attachment onward when it contains a matching pair of its own.

For example, top and _top share the same root, top. They form a propagation channel, and the root also determines which marks appear in an Anchor Cloud; that preview is taught in Attaching Marks. If the mark attaches through _top, its outgoing top takes the target anchor's name at the outgoing anchor's transformed position. With @top_2[_top], that outgoing anchor becomes top_2. Without the outgoing partner, the consumed target is not recreated. The channel can work in either direction; top and _bottom do not form a matching-root pair.

This supports stacking:

=A+ringcomb@top+acutecomb@top

The ring needs _top for its incoming attachment and top for the acute above it. The outgoing replacement occupies the consumed target's place in the anchor order. Other inherited anchors retain their source order. A built glyph can consequently provide attachment points when used in another construction.

The rules apply to a one-time recipe build as well as to an auto layer. The one-time build receives the anchors when it is built; an auto layer re-evaluates the construction as its sources change. Append #?noanchors when the built glyph should receive no anchors from the recipe. This leaves the source anchors intact.

For an advanced mapping, either bracketed name can have an underscore. Suppose shadda-ar has top and _top, and kasratan-ar has _bottom and bottom. The construction =shadda-ar+kasratan-ar@_top[_bottom] places the kasratan below the shadda. The kasratan's bottom/_bottom channel passes the target name through: its outgoing bottom reappears as _top at the bottom of the stack. For this example, the recommended, better-positioned construction is =fathatan-ar+shadda-ar@top, using the equivalent top-mark shape. Both recipes require the stated source anchors; the names alone cannot supply them.

Use anchors when adding a component

In Glyph > Add Component…, blank placement fields permit automatic positioning, including matching anchors. Enter an anchor name in the X or Y placement field to request that named reference for the corresponding axis. Numeric fields still request numeric placement, so you can combine one coordinate with one anchor-based axis deliberately.

After adding, inspect the component's offset and its Anchored property. Ordinary initial placement computes a position once. Enabling Element > Anchored, the paper-clip control, or the corresponding Elements-panel state keeps eligible component placement controlled by the source anchors.

For a live Anchored component, FontLab collects available base-anchor names from the host and preceding components. Later preceding components can replace an earlier candidate of the same name; the mark's anchor order determines which available pair is chosen. Component order and anchor order therefore both matter.

The first base component can sit at the origin when there is no applicable host attachment. Later components need suitable reference information for the intended match; inspect the enabled attachment state instead of assuming every component can be anchored usefully. Move the controlling anchor to reposition an anchored component rather than trying to drag it freely.

Chain ligature components

Special #exit and #entry anchors can define the connection between successive base components. Put #exit in the first source and #entry in the next, then use a concatenating recipe such as:

f_i = f & i

The anchor-aware construction can align entry to exit instead of relying only on accumulated advances. Check the realized placement and attachment state; in a manual composite, enable Anchored where the chain should remain attached. These special anchors are construction references here, not instructions for generating a layout feature.

Built-in alias.dat recipes can use the same named-attachment mechanism. Their availability does not remove the need to provide the source glyphs and appropriate anchors. The recipe supplies membership and placement instructions; the anchor supplies the design-controlled point.

Anchors in Ligature Recipes

A ligature needs separate attachment positions for the letters it represents. Number those positions in reading order: top_1 and bottom_1 belong to the first component read, then top_2 and bottom_2 to the second. In the Anchors & Pins panel, edit names to set the indices and drag entries to group the anchors by component. Use the same organization for a hand-drawn ligature.

For =f&i, source top anchors become top_1 and top_2. A base without an anchor still occupies its component position; adding a mark with + does not allocate another position. An already numbered source ligature reserves its existing span when joined to another base. Ambiguous surviving names can cause a recipe error instead of a silent replacement.

A right-to-left ligature is built in left-to-right visual order but needs attachment indices in reading order, from the right. Inspect the generated names and panel order, and correct them before generating mark features (see Attaching Marks); do not assume that the recipe's component order supplies the required indices automatically. Because + is handled inside its base group before numbering, =f&dotlessi+dotaccentcomb@top still uses the unnumbered top of dotlessi for that attachment.

Carets within a ligature

A ligature caret gives a text cursor or selection a stopping position between the characters represented by one glyph. FontLab represents it with an anchor named caret_1, caret_2, and so on, displayed as a blue vertical line. The editor displays caret anchors in variable-font projects as well. GDEF, introduced in The Process Architecture, stores these positions in an exported font; FontLab also imports supported GDEF carets as editable caret anchors.

Modern & constructions generate a caret between successive spacing components. With &, it lies at the preceding component's advance boundary. With &\, it lies halfway through the kerning interval. For =f&\i, a kerning value of −10 places the caret 5 units before the end of f's advance. In a longer recipe, each boundary uses its own operator and accumulated placement. Positions are calculated for each master.

Check caret names and positions in reading order, especially in right-to-left ligatures. Add appropriate caret anchors by hand for a separately drawn ligature. Carets are excluded from Anchor Clouds and generated mark features; they do not replace ordinary attachment anchors or prevent their inheritance. Per-master caret positions in the editor do not by themselves establish how a particular variable-font export represents them.

Arabic construction examples

The following two constructions use existing Arabic source glyphs. Prepare their outlines and anchors first, and inspect the chosen master after building. Enter these = forms in an auto-layer recipe field; in Build Glyphs, put the intended destination name before the equals sign.

To assemble yeh_jeem_yeh-ar.fina from finished letters:

=yeh-ar.fina&jeem-ar.medi&yeh-ar.medi

The final yeh is listed first because it sits on the left. After building, inspect the joins and spacing, then arrange the attachment anchors by component in reading order, from the right, and check the generated carets. The finished letters supply their own dots.

A separately drawn dotless skeleton (rasm) can have a different shape from those three letters joined together; the distinguishing dots (i’jam) are added separately. Give behDotless_hah_alefMaksura-ar.fina the receiving pairs top_1/bottom_1 through top_3/bottom_3, numbered from the right, and place its two caret anchors by hand. Give each dot mark an incoming _bottom above its dots and an outgoing bottom below them. Then use this single-line recipe:

=behDotless_hah_alefMaksura-ar.fina+twodotshorizontalbelow-ar@bottom_1[_bottom]+dotbelow-ar@behDotless_hah_alefMaksura-ar.fina:bottom_2[_bottom]+twodotshorizontalbelow-ar@behDotless_hah_alefMaksura-ar.fina:bottom_3[_bottom]

The first dot group can use the preceding skeleton as its target. The later groups use the glyph: recipe-target prefix from Using Recipes for Composite Building to name the skeleton explicitly, so they do not attach to the previous dots. Each used bottom_N is replaced by the corresponding mark's outgoing bottom, inherited as bottom_N below the dots. The skeleton's unused top anchors and carets remain available. Inspect all three dot groups and the resulting anchor list before using the glyph for further mark attachment.

Limits of Anchor-Based Placement

A one-time anchor-based placement in an ordinary, unanchored manual composite stores an offset. Moving the source anchor later does not automatically recompute that stored offset, even though changes to the source's outline remain visible through the component reference.

That limit is not universal to every manual layer. A component with Anchored enabled can follow its attachment points without making the entire layer automatic. Likewise, Build Glyphs can copy anchors into an ordinary generated layer during construction; copied anchors are not necessarily live inherited anchors afterward.

An auto layer retains and re-evaluates the recipe, regenerating the construction and its attachment data as its sources change. Choose between a fixed manual placement, an individually anchored component, and an auto layer according to how much of the construction should remain under automatic control. Check the state explicitly rather than inferring liveness from how the accent was first placed.

Adding a source anchor after a one-time build does not automatically add a corresponding copied anchor to that existing manual composite. Rebuild the construction when it should acquire the new attachment data. The source drawing can therefore remain linked while copied placement data becomes outdated: these are separate relationships.

For example, after revising a base’s accent attachment, inspect existing hosts. A fixed component offset needs a deliberate placement update; an Anchored component follows the supported attachment relationship; an auto layer regenerates from its recipe. Choose the mechanism according to what must remain adjustable, and inspect both the accent position and the host anchor list afterward. Auto layers are taught in Auto Layers.