Mark Attachment as Positioning

A combining mark can be positioned when text is shaped instead of requiring a separate precomposed glyph for every combination. The font supplies attachment points; the shaping engine uses them to place the mark against the base or another mark.

Dynamic Diacritics

Mark attachment is a GPOS relationship between glyphs in a text run. A base supplies a receiving location and a mark supplies an attaching location. The compiled relationship aligns those locations during shaping.

This lets the same mark work over many bases. Moving a base's receiving anchor changes the placement of the paired marks, while moving a mark's attaching anchor changes how that mark meets its targets. The relationship is reusable without requiring every combination to be redrawn.

The separate piece accent of metal composition provides a useful physical comparison: a separate accent could supply a combination unavailable as a precomposed sort, notably an accented capital or uncommon pairing. The accent and letter remain distinct pieces whose placement must be coordinated. Digital attachment makes that relationship part of the font's layout data, including combinations and stacks that would be impractical to maintain as individual precomposed drawings.

A precomposed composite remains useful. It stores a complete glyph drawing and can itself use live components or an automatic recipe in the source. Mark attachment is different: it positions separate text glyphs during shaping. A component arrangement inside one glyph is not automatically a GPOS attachment between glyphs.

Precomposed Glyphs and Decomposition

Text can represent an accented letter in more than one way. é may arrive as U+00E9, or as e followed by U+0301 COMBINING ACUTE ACCENT. Combining marks have their own character identities; they are not merely unencoded drawings inside accented glyphs.

If a precomposed character maps to a suitable precomposed glyph and remains that glyph, its accent does not need mark-to-base positioning. If the run contains a base and separate mark, attachment data can position them. Mark stacks and productive combining systems make that second route essential.

Some combinations have precomposed Unicode characters and some do not. Vietnamese can involve both precomposed characters and multiple combining marks; Arabic vowel marks, Hebrew points, and many phonetic combinations also require deliberate mark support. Do not infer the text representation solely from the visible result.

Shaping engines can normalize or otherwise prepare the input. Depending on the script, available glyphs, and engine, a decomposed sequence can become a precomposed glyph or a precomposed character can be handled as separate base and mark glyphs. Test both input forms rather than assuming the engine always delivers the same run to attachment.

A ccmp decomposition can deliberately turn a precomposed glyph into a base and mark sequence. The later attachment rules can then serve that sequence along with directly decomposed input. This requires the appropriate substitution and attachment data; enabling a mark feature alone does not perform the decomposition.

Anchors, Marks, and Mark Classification

In FontLab's source, a base anchor such as top pairs with a mark anchor such as _top. The underscore identifies the attaching side. One top/_top pairing can serve each eligible base and mark carrying those anchors, instead of requiring a separately drawn accented glyph for every combination; outgoing anchors can extend that relationship into stacks. The names guide source generation; compiled GPOS stores the attachment classes and coordinates that the engine needs, not editable named FontLab anchors.

Place those anchors per master. A top anchor may need to move as a stem widens or a bowl changes height. Corresponding anchors and suitable export generation let attachment follow the varying design rather than using one fixed current-master position everywhere.

GDEF classification identifies marks, bases, and ligatures for lookup processing. Check that combining marks have the intended Mark role, especially for unusual names or unencoded alternates. FontLab's @otmark virtual set can help inspect the classification, but it is not a replacement for checking the actual glyph role.

Anchor presence, GDEF role, compiled feature coverage, and the glyphs that reach the shaping stage all matter. A visually correct anchor cloud is useful source feedback; it does not, by itself, prove that an exported font contains the required attachment lookups.

Anchor authoring and preview are taught in Attaching Marks. Generation, export, and the contrast with fixed hand-written feature coordinates are developed in Mark Features and Export.