-
Notifications
You must be signed in to change notification settings - Fork 475
[feaLib.va 8000 riableScalar] fix value_at_location() method #3491
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
Conversation
Tangent: It really sucks that Adobe people decided to add user-space variable values to the .fea format, since those can't work with avar2. |
I also don't quite like it, but given that I'm also not quite sure what the fundamental problem is: these coords get normalized without applying any avar, and that allows us to express everything that's needed, even if the coords aren't in designspace coords. These coordinates are effectively source coordinates, even if they are expressed in user coordinates. Not sure I'm expressing myself very clearly :) |
Well if avar is not applied, then the "user" values mentioned in the .fea file won't actually match the observed user value coordinates. Eg. you say "switch to this other shape at wght=700" but then avar maps wght=700 somewhere different from what the .fea compiler does... |
But the fundamental issue is that with avar2, any point in the user space can be mapped to a point in the normalized space. But the same is not necessarily true about an orthogonal plane. That is to say, there might not be a simple formulation of 'wght >= 700' if eg. the font is a parametric design. |
Any thoughts on this PR, @simoncozens, @anthrotype? |
Thanks! |
to be fair, the variable scalar proposal came from @simoncozens, who also implemented it in fonttools, not from "Adobe people", and it's not even officially in the FEA spec (adobe-type-tools/afdko#153, adobe-type-tools/afdko#1350). |
VariableScalar's value_at_location() method is untested and unused, but I find it useful (if only for playing and testing) and found that it's broken. I fixed it, but that makes an assumption about the intended call signature: I assume the intention was to feed it a location dict in user coordinates.