[MPEG-OTSPEC] "newfeatvar" and the LookupCondition record

[Skef Iterum]

Towards the end of today's meeting Peter raised a potential concern 
about one aspect of the "LookupVariation" proposal for Feature 
Variations. This may well have just been one example of more general 
concerns, but that particular aspect of the spec does serve as a useful 
jumping-off point for explanation of where this proposal, and some of 
the other proposals Adobe has made (condition negations) and promoted 
(conditional VARC), are coming from.

In the vast majority of cases, the glyphs and other properties in a 
variable font vary smoothly and linearly. We generally discuss two 
archetypal cases of non-linear variation that stand in for a larger set: 
Changing the appearance of a dollar sign at different points in 
variation space, and changing the kerning between "T" and "o" so that 
the latter scoots under the former when there is room (or scoots out 
from under it when there isn't room).

For each of these cases there are two approaches to getting the desired 
effect. One involves simulating a non-linear change with an abrupt 
linear change. By putting two "masters" very close to one another in 
design space, values appear to change suddenly. So, if you have one 
master of a "$" glyph with two bars separated by a space, and another 
where those two bars overlap and appear as one bar, you can put those 
close together on an axis and it will appear that the two suddenly 
become one when moving the axis in one direction, and vice versa when 
moving it in the other.

The other approach is to use the Feature Variations mechanism to switch 
between two options, each of which varies in the usual way across the 
designspace. So you make a "$" glyph with one bar and a different glyph 
with two bars and you switch between them by having a substitution that 
is only active in some regions of designspace.

Now, consider this same dichotomy for the "T" and "o" case. If you want 
the kerning to change suddenly you can put two "masters" -- each of 
which is just a kerning value: an integer -- close together in design 
space. So if there is just one axis 200,400,900 wght axis maybe 
something analogous to:

     pos T o (wght=200u:40 wght=400u:45 wght=500u:47 wght=500+u:60 
wght=900u:61);

(Where the "+" indicates that the location on that axis should be one 
F2dot14 unit higher than "500" in user-units.)

However, although this seems to be only rarely noted, you can also use 
Feature Variations to approach this problem -- that mechanism is 
available in GPOS just as much as in GSUB. As with the dollar sign case 
one would "design" two linearly-varying kerning values, one that is 
correct for the "T" and "o" near each other in the less bold regions of 
the axis and the other that is correct in the more bold regions of the 
axis when they are further away.

But now there is an important difference: With the dollar-sign case you 
need a substitution to be present in some regions of designspace and 
absent in others. With the kerning case you need one value to be present 
in some regions of designspace and the other value to be present in others.

That need is where the feature Peter asked about is coming from. As 
currently proposed the LookupCondition record has an offset to a 
trueLookupIndexList (with lookups to add when the condition set is true) 
and an offset to a falseLookupIndexList (with lookups to add when the 
condition set is false). This is in effect an if/else structure. It's 
that way because when Behdad and I were discussing this need that was 
his preference 
<https://github.com/MPEGGroup/OpenFontFormat/issues/53#issuecomment-1673718355> 
and it seemed fine to me. The other way to do it would be to have a 
means of negating a condition set, and then using a separate 
LookupCondition record with the negation. But as we've discussed, 
condition sets aren't versioned so you can't do that with the condition 
set itself, and would therefore need a flag in the LookupCondition 
record to do it. The else is (arguably) cleaner.

Anyway, the more general point is that in making our proposals in this 
space Adobe has been trying to ensure that the functionality of Feature 
Variations is /general/, that the tools you might need are in the box. 
Sometimes you might need to effect a change across a non-rectilinear 
surface of design space, hence /condition values/. Sometimes you might 
want to switch between kerning values rather than playing "master 
games", hence /negated condition sets/ in some form (currently an 
"else"). Much of this thinking has come out of our ongoing work on 
extending the feature file format to directly support variable fonts, 
which I am currently implementing in prototype form. The things you 
might want to do at the feature file level help clarify where and how 
the underlying functionality is lacking.

These things can be frustrating to specify because there are often many 
different ways of meeting the set of needs. Still, we believe that the 
needs are there, and we haven't gone off into the weeds in terms of the 
proposed functionality.

Skef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240319/4e832733/attachment.htm>