2 Replies Latest reply on Feb 4, 2008 3:29 PM by (Read_Roberts)

    Request for comment on new feature file syntax for mark and attachment glyphs

    Level 1
      I am beginning to implement support for GPOS lookup types 3-6, the attachment lookup types, in makeotf. I would like to change the feature file syntax for Mark-to-Base and Mark-To-Mark, and would welcome comments on the following proposal.<br /><br />Background:<br /><br />The way these lookups work is to first define one or more classes of glyphs as mark glyphs (for example, TopMarks and BottomMarks). Mark glyphs are glyphs used only for adding marks to base glyphs. No glyph can be used both as a mark glyph ine one context and as a base glyph in another context.<br /><br />Each base glyph must then have defined an attachment point for each mark class ( say, Top Attachment Point and Bottom Attachment Point). A particular base glyph attachment point is associated with a particular class of mark glyphs simply by index order: the first mark class goes with the set of first attachment point in each base glyph.<br /><br />I see a couple problems with the current feature file syntax for Mark-to-Base. First, it implies that the user can associate a different class of mark glyphs with each base glyph. This is not the case; all mark glyphs used in a look up are associated with all base glyphs used in a lookup.<br /><br />Second, it does not explicitly correlate the mark classes with the base glyph anchor points. The lookup format requires that all base glyphs have the same number of attachment points, which has to equal the number of mark classes which are used in the lookup. Since position statement specifies only one attachment point for a base glyph, the only way to specify several is to use more than one position statement for the same base glyph. However, the allows the user to make errors by not specifying enough attachment points for a base glyph, or associate them with a mark class in a different order than was done for another set of base glyphs. These problems can be overcome by careful use of base and mark class names and attention to statement order, but I would prefer to avoid the need for care altogether.<br /><br />Proposed changes:<br /><br />1) mark statement<br /><br />The mark statement will include a fourth token, which is an arbitrary text label:<br /><br /> mark <glyph|glyphclass> <anchor>  <label>;<br /><br />for example:<br /><br />     mark [acute grave] <anchor 0 0> TOP_MARKS;<br />     mark cedilla <anchor 50 100> BOTTOM_MARKS;<br />     mark hook <anchor 0 200> BOTTOM_MARKS;<br /><br />All mark glyphs that use the same text label will end up in the same mark class. This is somewhat similar to the idea of a class definition, but allows the different glyphs in a mark class to have different anchor values. It also differs in that  more than one statement can reference a specific class, and this has the effect of adding all the glyphs referenced to that mark class.<br /><br />2) position statement<br /><br />The position statement will reference a mark class label name, rather than a glyph or glyph class reference. For example:<br /><br />position [a e u] <anchor NULL> mark BOTTOM_MARKS;<br />position [o] <anchor 250, -2> mark BOTTOM_MARKS;<br />position [a e o u] <anchor 250 300> mark TOP_MARKS;<br /><br />This way, no matter what the order of the position statements, the known index of the mark class can be used to set the index of the associated anchor point for the base glyph.<br /><br />When a position statement is omitted for a given attachment point for a base glyph, such as 'o' in the example above,  makeotf will not emit an error message; it will just assume that the attachment point should be set to some default value, such as <anchor 0 0>.<br /><br />3) scope of mark classes; GDEF table.<br /><br />Since lookups in both the GSUB and GPOS table can use the MarkAttachmentType lookup flag value to skip marks of a given type, all mark class definitions will be global, i.e. will be defined for the scope of both the GPOS and GSUB rules in the feature file. This dos NOT mean that they will be all be defined in each font lookup; only the mark classes referenced in a mark lookup will be defined within the font lookup in the actual font file. It does mean that all mark cl