-
Notifications
You must be signed in to change notification settings - Fork 475
[feaLib etc.] Support for FeatureVariations? #713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I strongly do not want to see different branches of the feature file syntax appear. I also strongly support community contributions and comments, and the general idea that the fea syntax is common property, not an Adobe only playground, and that makeotf does not have to lead the way: as long as we all agree on the direction; others may well have the time to implement extensions first. |
Thanks @readroberts , that's exactly what I imagined your response would be. :) I've just posted an alternative FEA syntax extension proposal for FeatureVariations (rvrn etc.) which I actually like. I believe it's "in the spirit" of the previous FEA constructs: As I've explained in the other thread, I think FeatureVariations are the one thing that would require a syntax extension. The other aspects can be done via "blending" of separate per-master FEA files, at least for the most common cases, as |
We have some code for now, thanks to Just #1240 I need to hook it up to varLib. |
Fixed by #1314 |
I've opened a discussion about support for FeatureVariations and a more general support for OTVar in the Adobe FEA syntax over at adobe-type-tools/afdko#153
I have some questions:
makeOTF and feaLib are now two significant active implementations of FEA, while the FontForge one can probably be considered dead.
In the past, Adobe did define the changes to the FEA syntax and implemented them. But with OTVar, it seems that @readroberts is open for more community-driven effort to figure out whether FEA needs to be extended, and if so, how, to support variations -- also because the best way would be if both makeOTF and feaLib implementers agree on the common way.
The FEA spec is published under the Apache 2 license, so in theory it could diverge, but we surely don't want that:
http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html
The text was updated successfully, but these errors were encountered: