markClass FEA parsing bug

[Georg Mayr-Duffner]

Posted by Adam Twardoch at http://sourceforge.net/mailarchive/forum.php?thread_name=CAEozd0x0GLyo_v1YzFa3k2M7_zN3o4m6cBuXeEu6eJMrdGo2HQ%40mail.gmail.com&forum_name=fontforge-devel

Given the following FEA definition:

languagesystem latn dflt;

lookup mark1 {
     markClass [acute] <anchor 0 0> @acute;
     pos base [a] <anchor 260 0> mark @acute;
} mark1;

lookup mark2 {
     markClass grave <anchor 0 0> @grave;
     pos base a <anchor 260 0> mark @grave;
} mark2;

feature mark {
     lookup mark1;
     lookup mark2;
} mark;

when trying to import the FEA, FontForge will give the following error: Expected '[' in glyph class definition on line 9 of feature.fea

The FEA spec: http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#4.f clearly states:

A mark glyph class name is defined differently than a regular glyph class. The mark class definition is built up by a one or more of statements in the form:

markClass <glyph|glyphclass> <anchor> <mark glyph class name>;

This means that the markClass statement can assign a class (as in line 4 of my example, [acute]) or a glyph (as in line 9 of my example, grave) to a mark class. Adobe makeotf correctly processes both definitions, while FontForge only allows the first one.

Best, Adam

[Barry Schwartz]

It is likely we will drop feature file syntax altogether and replace it with a simpler Scheme-based syntax. Then feature files could be supported by a translator to Scheme syntax, though Adobe’s ‘spec’ is an unprofessional hack job that isn’t really worth the effort. (A real spec would have what’s called a BNF grammar.)

[Georg Mayr-Duffner]

I don’t mind how it’s represented internally* as long as input is interpreted correctly and the output is valid both in fonts and generated feature files.

*It wouldn’ŧ make sense to me to care about that as I’m not able to code and thus have little to say about such problems (yes, I’m just a dumb user ;)

[Khaled Hosny]

Fix reading anchors from feature files

markClass accepts a single glyph or a glyph class.

Fixes #35

→ <<cset b68c86e9fd83>>

[Khaled Hosny]

In the meantime I fixed this in the other issue. it does not mean our feature file code is not horrible (it is) nor that feature files are any good (I have to use a preprocessor to make them a bit usable).

[Barry Schwartz]

FontForge’s feature files already are not completely Adobe-compatible, by design. In particular, they handle aalt very differently. So I have little compulsion to keep either input or output in Adobe’s syntax, rather than having the user write a bunch of nested parentheses instead. :) Fortunately, if I am going to rewrite the feature file parser, it will be in Guile anyway, and so we would likely have input from Adobe-like syntax, even if not output anymore.

But I can do only so much at once, and it is much less than an employable programmer can do. For now we use the existing code. :)

(I am currently rewriting at least part of the SVG input code, rather than this.)