[feaLib.variableScalar] fix value_at_location() method

[justvanrossum]

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.

[behdad]

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.

[justvanrossum]

I also don't quite like it, but given that fvar is all that's guaranteed to available during compile time, I can understand it.

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 :)

[behdad]

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...

[behdad]

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.