[OTVar] Dependent axes?
Belleve Invis
Posts: 269
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).
0
Comments
-
So far, we have ideas around virtual axes, synthetic axes, and now dependent axes.
What seems clear is that we need some mechanism by which manipulation of design by axes that affect individual parameters can be mapped to axes that affect the visual appearance of the design.0 -
John Hudson said:So far, we have ideas around virtual axes, synthetic axes, and now dependent axes.
What seems clear is that we need some mechanism by which manipulation of design by axes that affect individual parameters can be mapped to axes that affect the visual appearance of the design.0 -
John Hudson said:So far, we have ideas around virtual axes, synthetic axes, and now dependent axes.0
-
I propose a conceptual difference between virtual and synthetic axes (I can't claim to really understand @Belleve Invis dependent axis idea yet, because I'm not strong on the math side and don't know what Lambdas and Let bindings are).
I think of a virtual axis as a involving mapping one or more gvar axes to a gvar-less axis; whereas, the term synthetic axis could also refer to a gvar axis that is synthesised from other axes (so, if I've understood correctly, some of the Amstelvar axes are synthesised from the parametric axes, right?). I reckon there's probably implementational overlap between the two concepts, i.e. it would be possible to make a synthetic virtual axis (which perhaps describes Rob McKaughn's XVAR implementation idea).0 -
Perhaps ytlc is a virtual axis, in that it is a subset of the ytra axis (and in fact really there situation is the opposite: ytra is the sum of the other Y transparent axes) and opsz is a synthetic axis in that it's tracing a path through the design space created by the x and y opaque and transparent axes.1
-
John Hudson said:I propose a conceptual difference between virtual and synthetic axes (I can't claim to really understand @Belleve Invis dependent axis idea yet, because I'm not strong on the math side and don't know what Lambdas and Let bindings are).
I think of a virtual axis as a involving mapping one or more gvar axes to a gvar-less axis; whereas, the term synthetic axis could also refer to a gvar axis that is synthesised from other axes (so, if I've understood correctly, some of the Amstelvar axes are synthesised from the parametric axes, right?). I reckon there's probably implementational overlap between the two concepts, i.e. it would be possible to make a synthetic virtual axis (which perhaps describes Rob McKaughn's XVAR implementation idea).
0 -
An image for explaining this idea:
The current FVAR-GVAR combination is the blue box on the bottom. Dependent Axes is mostly adding two high layers on the top of it: the first is a set of axes, which are exposed to the end user; the second are a (or multiple) sets of functions, which connects the "exposed axes" and "internal axes".“All problems in computer science can be solved by another level of indirection.”
0 -
This sounds like idea of taking the XVAR table proposal and applying it as an implementation for "virtual" ("synthetic"/"meta") axes.1
-
@Peter Constable
Maybe we can combine the ideas: let "XVAR" to include more "result axes"? Or making it lie before "fvar"?
The code below is my idea, represented in C++-like type definitions.class Table_AXES { Uint16 majorVersion; // set to 1 Uint16 minorVersion; // set to 0 Uint16 numberOfFvarAxes; // identical to the axisCount in FVAR Uint16 numberOfDesignAxes; Uint16 numberOfMappers; Vector<numberOfDesignAxes, Offset32<AxisDef>> designAxes; Vector<numberOfMappers, Offset32<Mapper<numberOfFvarAxes>>> mappers; } class AxisDef { Tag axisTag; Fixed minValue; Fixed defaultValue; Fixed maxValue; Uint16 flags; Uint16 axisNameID; } template <Uint16 nFVA> class Mapper { Uint16 formulaVersion; // set to 1 Tag layoutMode; // 'hori' or 'vert' for now Vector<nFVA, Formula<formulaVersion>> formulae; } template <Uint16 formulaVersion> class Formula {} template<> class Formula<1> { Fixed constantTerm; Uint16 numberOfPolymorphicTerms; Vector<numberOfPolymorphicTerms, Format1Term> terms; } class Format1Term { Uint16 numberOfFactors; Vector<numberOfFactors, Format1Factor> factors; } class Format1Factor { Tag designAxisTag; Fixed coefficient; Fixed minValue; Fixed peakValue; Fixed maxValue; }
0 -
I posted https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/issues/22#issuecomment-401493070 which seems related to this discussion.0
-
Idea of dependent axes make a sense, but... I spent a few days trying to decide what is more useful for the customer – single Optical Size axis, or two Contrast and X-Height axes? Ideally (in my mind), would be nice to have all three.For example, Optical Size axis would automatically change Contrast and X-Height axes if they are presented. But there's a problem – What the position an Optical Size axis would show when the user changes one of dependent axes, such as Contrast only?1
-
>But there's a problem – What the position an Optical Size axis would show when the user changes one of dependent axes, such as Contrast only?
This was a question that arose in a work group discussion five years ago, but I think it's a bit of a red herring: the axis settings are inputs in a one-way flow of information in the instance-selection/delta-application algorithm. If three axes are exposed to the user, then there's no feedback loop in the UI; in other words, they are independently settable by the user. The Optical Size axis wouldn't be setting the other axes, but it could be activating deltas that are more directly tied to the other axes.
2 -
This is now shipped in avar20
-
Apparently avar2 is supported in the new macOS 13, Ventura0
-
Thomas Phinney said:Apparently avar2 is supported in the new macOS 13, Ventura1
-
Fair enough. I should just say: we have observed that avar2 seems to be working in the new macOS 13 Ventura (and the latest iOS as well, now)
0 -
A clarification of macOS support.
It was particularly remarkable that macOS 13 Ventura handled the avar2 table, since it was launched the very evening (2023-10-27) after I’d presented avar2 for the first time
Unfortunately, Behdad and I found bugs with it right away, so it unfortunately confused things regarding testing. I’m not sure when exactly things got fixed, but when I upgraded to macOS 13.2.1 (Feb 2023) I was pleased to find it working exactly as my polyfill does. So, if you have 13.2.1, you should see identical results between native and polyfill in this testing tool when playing with axes.
https://lorp.github.io/samsa/src/samsa-avar2.html
To be clear, in this demo font, Weight, Width and Optical Size drive the parametric axes, in a font that takes up dramatically less data than an equivalent “blended” font would occupy.
I don’t know what Apple are doing with avar2. If anyone finds an avar2 font on an Apple system I’d be pleased to hear about it.
In related news, my October avar2 presentation went live yesterday:
https://www.youtube.com/watch?v=j7unMVZOcaw
2
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 793 Font Technology
- 1K Technique and Theory
- 609 Type Business
- 443 Type Design Critiques
- 536 Type Design Software
- 30 Punchcutting
- 135 Lettering and Calligraphy
- 82 Technique and Theory
- 53 Lettering Critiques
- 478 Typography
- 300 History of Typography
- 113 Education
- 65 Resources
- 494 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 161 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports