As saw the axes proposal from Type Network, it worth saying that, if the fvar can support dependent axes, it would help solving some complex situations (like building a composite font from two VFs with different avar, or providing controls of non-orthogonal concepts).
Given that axes in fvar are almost Lambdas, the concept of dependent axes are Let-bindings. More precisely, a dependent axis is a "variable quantity" on the space of exposed axes, and could be used by the rest parts of the font (like gvar). For example, a user may define a dependent axis "stem width" in a font with one exposed axis "weight":
>> stem-width = F(weight) << // where F is a segmentwise linear function within range [-1, 1], represented in delta-tuples
then in the rest parts of the font, they would think that the font is two-dimensional, with first axis being "Weight" and second being "Stem width".
If dependent axes are present then the entire avar table is needless (since we can add the "adjusted" axes as individual dependent axes, while the original axes are still usable).
Given that axes in fvar are almost Lambdas, the concept of dependent axes are Let-bindings. More precisely, a dependent axis is a "variable quantity" on the space of exposed axes, and could be used by the rest parts of the font (like gvar). For example, a user may define a dependent axis "stem width" in a font with one exposed axis "weight":
>> stem-width = F(weight) << // where F is a segmentwise linear function within range [-1, 1], represented in delta-tuples
then in the rest parts of the font, they would think that the font is two-dimensional, with first axis being "Weight" and second being "Stem width".
If dependent axes are present then the entire avar table is needless (since we can add the "adjusted" axes as individual dependent axes, while the original axes are still usable).