Syntax for OpenType mark attachment?

We’re looking for some feedback from the font developer community on how you want the AFDKO/FontLab/FontMaster code syntax to work for mark attachment. Please comment! Comments received by Friday September 29th will be most likely to influence our implementation.

In OpenType fonts, mark attachment is the GPOS (glyph positioning) rule which dynamically positions diacritical marks (accents and the like) relative to base characters or other marks.

The currently available version of Adobe’s Font Development Kit for OpenType (AFDKO) does not support OpenType mark attachment. Hence, other tools based on the AFDKO, such as FontLab or DTL FontMaster, do not support it either. We’re currently implementing such support, which will in turn determine the underlying code used by such third party tools. This also means extending the syntax of the AFDKO language to represent mark attachment. However, mark attachment is complicated, and gets even more so when one makes it contextual. The best way to represent it in the same style as other AFDKO code is not entirely clear. Here’s what we’d like your feedback on.

(Special thanks to Read Roberts, AFDKO engineer, for the remainder of this post!)

[UPDATE 11 Sep 2008: See comments for latest proposal from Read]

The syntax for a mark-to-base positioning rule ( GPOS lookup Type 4) is planned to be:

         # The base glyph
          # the anchor position on the base glyph


# define a mark class
    mark [ acute grave]  @TOP_MARKS;

# use mark class name in a mark-to-base rule.
    position [a e o  ]  mark @TOP_MARKS;

Adding a contextual prefix and suffix to this is not obvious, as the input glyph in a mark-to-base rule ( that is, the glyph which is matched in the current text stream when the rule is applied) is the mark class rather than the base glyph class. The way that this rule is applied is that when the current glyph matches in the mark class for a mark-to-base rule, the application looks back in the input stream for a matching base glyph. (The lookup flag may also instruct the application to skip other mark glyphs when doing so).

Some possible representations:


This option can be described as:

  • Write the complete stand-alone base-to-pos position rule
  • Add double-quote to the base glyph or glyph class, to show that it is NOT part of preceding context.
  • Add one single quote to the mark class name, to show that this is the input that needs to match the current glyph position
  • Add the contextual prefix sequence before the base glyph
  • Add the contextual suffix after the mark class name

6 Responses

  1. George Williams says:

    In the “mark class” definitions it appears that all marks in the same mark class must have the same anchor location.Since this is not a requirement for the mark-to-base table itself that means there will be some fonts which cannot be expressed in this syntax. (FontForge wants to be able to generate a feature file from a font as well as a font from a feature file).Could you extend the mark class definition to allow for an anchor for each mark glyph?Perhaps:mark [ acute grave] [<anchor 300 0> <anchor 100 60>] @TOP_MARKS;mark [ acute <anchor 300 0> grave <anchor 100 60>] @TOP_MARKS;

  2. George Williams says:

    Should it not be possible to have contextual glyphs between the base and the mark? Other marks perhaps?

  3. Eigi says:

    I would like to see something that seperates the anchor positioning from the class definition. It is not sure that a set of marks, which belong to the same class, share the same anchor positions. If you force this and the designer wants to adjust the mark position, he/she has to move the outline relative to the anchor. This may be a problem, if the same mark is also used as a part of a composite.can we do something like this:# place anchors on marksacute <anchor 300 0> mark_anchor;grave <anchor 350 0> mark_anchor;# place anchors on base charsa <anchor 320 400> base_anchor;[e o] <anchor 340 400> base_anchor;# define classes as usual@marks = [acute grave];@basechars = [a e o];# define the mark to base positioningposition @basechars <anchor base_anchor> mark @marks <anchor mark_anchor>For this implementation it is only required that all glyphs of the same class have an anchor with the same name, but not with the same position.RegardsEigi

  4. Read Roberts says:

    I have since had an idea I like better. All contextual glyph sequences statements would be written as in the current feature file syntax. Any positioning rules to be applied to an glyph or glyph class in the input sequence would immediately follow the input glyph or glyph class, and be clearly distinguished from the context string by being enclosed with <>. Examples:position<backtrack glyph or glyph class>’*<input glyph or class>’+<<pos statement to be applied to input >>*<lookahead glyph or glyph class>*;where * means none, one or more,and + means one or more. Examples:Single Positionpos T’ < 0 0 30 0> W;Mark To Base:pos T [ a e o] @TOP_MARKS'<[ a e o] <anchor 300 400> mark @TOP_MARKS>;</pre>Mark To Mark:pos T [ a e o] @TOP_MARKS @MORE_TOP_MARKS'<mark @TOP_MARKS <anchor 300 400> mark @MORE_TOP_MARKS>;

  5. Read Roberts says:

    Yes, it should be possible to have contextual glyphs between the base glyph or glyph class and the mark class. That is why in the first version, the base glyph is not part of the context – that is what the double-quote is for. However, i think the second version of syntax that I suggest makes this even more clear.

  6. Read Roberts says:

    I have done more work, and post my latest proposal at:

Comments are closed.

Thomas Phinney

Adobe type alumnus (1997–2008), now VP at FontLab, also helped create WebINK at Extensis. Lives in Portland (OR), enjoys board games, movies, and loves spicy food.

Adobe, Web fonts and EOT

Thomas Phinney · September 1, 2008 · Making Type

Arial Narrow gets fixed

Thomas Phinney · September 11, 2008 · Making Type