Open davelab6 opened 5 days ago
Is this about:
?
We should first rule out that this is not just a compiler distilling to avar2. I'll think about that.
Here is a simple example of "multi-layer avar" (hmm, how many layers is this? fences or fenceposts?), using subscript digits to indicate the axis layer number:
xxUC, xxLC, xxFI mean uppercase, lowercase, figures respectively.
(I prefer the 'control' metaphor to the 'blend' metaphor, since that’s the direction inputs turn into outputs when the font is in use.)
During the avar2 design process, @behdad wondered if to allow more than 1 mapping layer. I confess I resisted it because of complexity, and I don’t think a spec concept emerged. However I think if we allow axisIndexMap to contain n axisCount records, where n* is the number of layers, we’re good :) Discussing with @behdad.
However I think if we allow axisIndexMap to contain n * axisCount records, where n is the number of layers, we’re good :) Discussing with @behdad.
The number of entries in axisIndexMap
isn't part of the API of that structure. Let's not jump to a design yet, before we settle on the need and scope.
We should first rule out that this is not just a compiler distilling to avar2. I'll think about that.
I'm convinced myself that distilling it to avar2 will explode the number of tents. So, I'm happy to work on a avar3 to address that. It looks like we just need to add a numLayers
item, and the rest can be deduced.
SGTM
I'm convinced myself that distilling it to avar2 will explode the number of tents.
How is a high number of tents an actual problem?
It is useful to be able to develop 'atomic' parametric axes (like XOPQ, XTRA) and then mid level 'molecule' virtual axes (that combine them in specific proportions) that are then used to blend top level 'user' axes (weight, width, opsz).
I request this based on discussions with @dberlow and @lorp