Can FontForge Parse Complex Adobe Feature Files?

FontForge provides native support for importing Adobe Feature File (AFDKO .fea) syntax to define OpenType layout rules, but it cannot parse complex feature files reliably without errors. While it handles basic substitutions, simple kerning, and common ligature structures well, advanced syntax frequently triggers parser errors, produces corrupted OpenType tables, or results in silently dropped rules.

Why FontForge Struggles with Complex Syntax

FontForge relies on an internal, legacy C-based parser rather than the modern reference implementations maintained by Adobe or the Python fontTools library. Because the Adobe Feature File specification has evolved over time, FontForge’s internal parser has fallen behind modern typographic standards.

When encountering complex syntax, FontForge typically fails in several key areas:

  • Chained Contextual Substitutions: Complex contextual chaining rules involving multiple lookups, lookahead, or backtracking contexts often confuse the parser, leading to syntax error alerts or misinterpreted target glyphs.
  • Complex GPOS (Positioning) Rules: Advanced positioning rules—such as intricate mark-to-mark, mark-to-ligature, and cursive attachment lookups—frequently fail to compile correctly or trigger invalid offset errors.
  • Variable Font Directives: Modern feature syntax supporting variable font conditions (such as condition statements and variation-specific kerning) is largely unsupported by FontForge's standard feature parser.
  • Inline and Named Lookups: While standard named lookups are partially supported, nesting inline lookup blocks inside substitution rules often breaks the parsing routine.
  • Large File Handling and Nested Includes: Feature files using multiple, nested include() statements often lead to memory issues, incorrect relative path resolution, or complete application crashes.

Silent Failures and Data Integrity

A critical issue when using FontForge with complex .fea files is the risk of silent failure. Instead of halting with an explicit syntax error, FontForge may skip unsupported statements entirely. When the font is generated, the resulting OpenType layout tables (GSUB and GPOS) will lack the intended typographic behavior, making troubleshooting difficult.

To build fonts with complex OpenType features without errors, developers and type designers typically avoid relying on FontForge’s built-in feature parser:

  1. Use fontTools.feaLib: This Python library is the current industry standard for parsing and compiling .fea files into binary OpenType tables.
  2. Post-Processing Workflow: Design the glyph outlines, metrics, and basic metadata inside FontForge, export the font as an unhinted binary (.otf or .ttf), and then merge the complex .fea file into the font using AFDKO's makeotf or a fontTools build script.