fea-rs

Parsing and compiling Adobe OpenType feature files.

status: We should be able to compile most inputs. Some generated tables may not be optimal, but should be correct. Obscure syntax may not be supported. Please report bugs.

quickstart

To use this tool to compile OpenType features from a UFO file:

$ cargo run PATH_TO_FONT.ufo -o my_generated_font.ttf

Alternatively, you can provide a path to a FEA file directly, in which case you will also need to pass a path to a file containing the glyph order: one glyph per line, in utf-8.

$ cargo run features.fea --glyph-order glyph_order.txt -o my_font.ttf

testing

This crate uses a number of testing strategies, although all the tests can be run with cargo test.

In addition to unit tests, we have a custom property-testing system for testing parsing and compilation. This involves data that is stored in the test-data directory. These tests work by taking some input, producing some output, and then comparing that output to an expected output that is included in the test data. There are three different formats for this:

• parse tests: These ensure that we generate the expected AST or errors for various inputs. See test-data/parse-tests/README.md for an overview.
• compile tests: These ensure that we generate the expected TTX output or errors for a various inputs. See test-data/compile-tests/README.md for an overview.
• fonttools tests: Very similar to the compile tests, but instead of being cases that we define ourselves, we reuse the property tests from fonttools feaLib. This ensures that we generate equivalent output to feaLib.

architecture sketch

The overall design of this crate is heavily inspired by the design of rust analyzer. At a very high level, given some source, we:

• lex the source file into raw tokens (src/parse/lexer.rs)
• parse these tokens into an abstract syntax tree (src/parse/parser.rs)
• validate this tree, ensuring that it conforms with the specification (src/compile/validate.rs)
• compile the validated tree into OpenType tables (src/compile/compile_ctx.rs)

Parsing

Parsing is broken up into a lexing and then a parsing step. Lexing identifies tokens (numbers, strings, identifiers, symbols, keywords) but has no knowledge of the syntax of the FEA language. Parsing takes a stream of tokens, and builds a syntax tree out of them.

The parser is "error recovering": when parsing fails, the parser skips tokens until it finds something that might begin a valid statement in the current context, and then tries again. Errors are collected, and reported at the end.

AST

The AST design is adapted from the AST in rowan, part of rust analyzer. The basic idea is that when constructing an AST node, we ensure that certain things are true about that node's contents. We can then use the type of that node (assigned by us) to cast that node into a concrete type which knows how to interpret that node's contents.

Validation

After building the AST, we perform a validation pass. This checks that statements in the tree comply with the spec: for instance, it checks if a referenced name exists, or if a given statement is allowed in a particular table block. Validation is also 'error recovering'; if something fails to validate we will continue to check the rest of the tree, and report all errors at the end.

If validation succeeds, then compilation should always succeed.

Compilation

After validation, we do a final compilation pass, which walks the tree and assembles the various tables and lookups. This uses fontations to generate tables, which can then be added to a font.

Some general design concepts:

• in a given 'stage', collect errors as they are encountered and report them at the end. For instance during parsing we will continue parsing after an error has occurred, and report all parse errors once parsing is complete.