My test font:
shows how a font axis can be used to gradually trigger different lookups depending on the axis value.
Here, it’s done in the "rvrn" feature, but it’s possible to do with any feature. This means: depending on the user-selected axis location, it’s possible to have different GSUB and GPOS realizations for any given feature.
For example, you might have a "LIGA" axis that controls in detail how many ligatures are enabled when the "liga" feature is active. The axis may also perform some contour modification, but that’s not required.
But there is a big caveat: in the current VF model, each selected variable instance constitutes a new font. This means, the glyph run breaks and no features can interact across the change of the instance. The fvar axes are above features, not on the same level.
It's not difficult to imagine typesetting a series of glyphs and applying a different axis location to each one. But variations don't apply just to glyphs but also to positioning, and different lookups can be triggered depending on the axis location.
If different axis locations can trigger different GSUB and GPOS lookups, and any of the lookups could change the axis locations, then quite possibly, the new axis locations would deactivate the lookups that triggered them.
Or what if a lookup is executed when an axis it at position 300 and the rule says "move the axis location to 200", but then the same lookup at axis location 200 would have a rule "move the axis location to 100"?
Also, OpenType GPOS works so that it can change the x/y position of the glyph origin and the x/y position of the glyph advance width point.
Asking for GSUB to allow mixing instances would mean e.g. if we’re at axis location 300 and if glyph "a" is followed by "b", then move the axis location of glyph "b" to 200.
But let’s say we have a string "abc" and there is GPOS adjustment between "b" and "c" that at axis location 300 changes the origin point and the advance width of "b" somehow, and also changes the origin point and the advance width of "c" somehow — to allow kerning, but also more complex positioning.
Now, when, after GSUB, "b" is at axis location 200 and "c" is at axis location 300, then neiter the GPOS rules for 300 nor those for 200 apply completely. Some things would need to be interpolated — but what? The origin of "b"? The advance width of "b"? The origin of "c"? The advance width of "c"? Both x and y, or only one?
One more example: if after some GSUB processing we end up with "abc" where "a" and "c" are at axis location 300 but "b" is at axis location 200, and we have some more lookups to process — and those lookups define different behaviors when axis locations are <250 and different if >250, and there are contextual substitutions (let's say "c" is substituted by "d" if preceded by "a" and "b" but only if axis location is >250) — what exactly should happen? Is "b" in-context or out-of-context?
Oh, or maybe we then should define additional contextual GSUB lookup types which allow for matching contexts not just for which glyphs they are, but also for what axis locations (and then, logically, what x and y distances) they have.
That would in principally be wonderful — if we could define not just glyph ID-based contexts but also axis location-based and x/y-position-based contexts. But it would be hard.
There are many caveats associated with bidirectional axis-feature interaction. So for now, the interaction is only one way: features can detect at which axis location the font is and apply different lookups depending on that. But it doesn’t go back.
There’s been some conversation about possibly adding a mechanism that would allow more axis-feature interaction, see:
But it’s nowhere near drafted. I think for the time being, OpenType Font Variations will remain “font-level variations”. Introducing inter-glyph-level variations is conceptually much more complicated.
I think many people would agree that in general, something like this is a good idea. But figuring out how to make this work reasonably, writing the spec and implementing it will take time. Positioning is particularly tricky because there is no obvious way to tell what "working reasonably" would mean here.
Variable fonts may have intermediate masters where positioning is very "odd".
Let's say some glyphs are narrow and tight in the axis location 0, then they become wide and loose in axis location 500 and then they become narrow and tight (but in a completely different way) in axis location 1000.
If I put one glyph at location 0 next to another glyph at location 1000, then the kerning between them might come from location 500.
But kerning at location 500 was only designed to work for glyphs at location 500, not between ones glyph from 0 and one from 1000.
This is a hypothetical example but it shows real consideration.
Positioning of glyphs that come from different locations may need to be different than the positioning that happens in the locations between them.
Two Germans will speak German to each other. Two Spanish people will speak Spanish. And two French people will speak French.
France lies between Germany and Spain — but this doesn't mean that the best language in which a German can communicate with a Spanish person is French.
In fact it's not at all clear what the best language should be. I hope my analogy makes sense
An even better example is with colors. You may dress in all things green, all things blue or all things red. But if you put on a green t-shirt and red shoes, it does not automatically mean that your trousers should be blue, even though blue is between red and green on the color spectrum.
Software developers must know exactly how a system will work and must implement it exactly. There is very little room for "maybies".
Implementing a system that will deliver sensible results between different instances of a variable font is difficult, because it's not at all obvious which results would be sensible.