Behdad Esfahbod

Humm. You are correct I'm afraid :(.

IMO the coordinates should be in design space. Which would be weird given that the "design space" concept mainly exists in .designspace documents and elsewhere, but not in OpenType /...

> IMO the coordinates should be in design space. The rationale is that if the user changes the avar mappings, the variable values here should NOT change! So the current...

We can define that for a .fea file that is not associated with any design-space, the values are in normalized coordinates.

It just makes it much harder to write them by hand, if that's a supported scenario.

> [adobe-type-tools/afdko#1350 (comment)](https://github.com/adobe-type-tools/afdko/pull/1350#discussion_r636008312) specifically says user coords. Yeah, but as per https://github.com/harfbuzz/boring-expansion-spec/issues/94#issuecomment-1604770895 I think that's just wrong.

> > > [adobe-type-tools/afdko#1350 (comment)](https://github.com/adobe-type-tools/afdko/pull/1350#discussion_r636008312) specifically says user coords. > > > > > > Yeah, but as per [#94 (comment)](https://github.com/harfbuzz/boring-expansion-spec/issues/94#issuecomment-1604770895) I think that's just wrong. > > Under avar2...

> 1. design units > 2. design _and_ normalized with explicit indication of which > > I'm currently not aware of any person or tool that particularly benefits from option...

> Maybe I am missing something, but are we essentially discussing how to use arbitrary surfaces as the boundaries in design spaces where features are triggered? Not really. We're discussing...

Currently with the proposed syntax, .fea would need input from the fvar table to be compiled, since we would need to know the axis indices. One way to resolve that,...