<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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. </p>
<p>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:</p>
<p> pos T o (wght=200u:40 wght=400u:45 wght=500u:47 wght=500+u:60
wght=900u:61);</p>
<p>(Where the "+" indicates that the location on that axis should be
one F2dot14 unit higher than "500" in user-units.) </p>
<p>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.</p>
<p>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.</p>
<p>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 <a
href="https://github.com/MPEGGroup/OpenFontFormat/issues/53#issuecomment-1673718355">that
was his preference</a> 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. <br>
</p>
<p>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 <i>general</i>, 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 <i>condition
values</i>. Sometimes you might want to switch between kerning
values rather than playing "master games", hence <i>negated
condition sets</i> 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. <br>
</p>
<p>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. <br>
</p>
<p>Skef<br>
</p>
</body>
</html>