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:
position
# The base glyph
# the anchor position on the base glyph
mark
;
Example:
# 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:
position
"
mark
'
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
Comments are closed.
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] [ ] @TOP_MARKS;mark [ acute grave ] @TOP_MARKS;
Should it not be possible to have contextual glyphs between the base and the mark? Other marks perhaps?
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 mark_anchor;grave mark_anchor;# place anchors on base charsa base_anchor;[e o] base_anchor;# define classes as usual@marks = [acute grave];@basechars = [a e o];# define the mark to base positioningposition @basechars mark @marks 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
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’*’+<>**;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] mark @TOP_MARKS>;Mark To Mark:pos T [ a e o] @TOP_MARKS @MORE_TOP_MARKS' mark @MORE_TOP_MARKS>;
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.
I have done more work, and post my latest proposal at:http://typophile.com/afdko2#comment-301955