You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We may be exploring additional ideas at the same time as phase 2, and syntax that other implementations support could be part of that. Beyond that we can't offer any real commitments at this time.
Reading through the documentation, the spirit of these extensions seems to be allowing a channel for data stored outside of the feature files. We sometimes get feedback weighing in the opposite direction. There was discussion of duplicating information from designspace files in feature files so that they would continue to be more or less self-contained, although that idea was ultimately rejected. If there's no standard "storage" for the information being pulled in, such extensions would make feature files less portable between stacks. We would have to think about that, and get input from the developers of other tools about these questions.
There are two kinds of tokens. The manually defined numbers per master. But also the ones querying glyph data (e.g. anchors or sidebearings). That is useful when writing complex contextual rules and still being able to visually place anchor in each master. The second kind doesn’t need any additional storage.
Is there any interest in adding support for tokens or placeholders in fea code? Glyphs has support for this: https://handbook.glyphsapp.com/layout/tokens/ ?
The text was updated successfully, but these errors were encountered: