<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I've been getting back to Feature Variations questions (in
relation to the feature file format) recently, and I'm now
wondering whether it would be good to add some editorial advice in
the specification. Note that I'm not making a proposal, I'm aware
that the spec is in an awkward stage for making changes, etc. I'm
just thinking in terms of merit right now, not process or timing.</p>
<p>The current draft adds functionality related to Feature
Variations for <i>lookups</i> but leaves the current system more
or less unchanged. Because that system is based on offsets to
alternative Feature tables, one can use it to adjust (via
conditions)<i> either</i> the set of lookups active for a feature
for different axis positions, <i>or</i> its "parameters". Recall
that the those parameters are specific to a given feature tag,
currently <font face="monospace">size</font>, <font
face="monospace">ssXX</font>, and <font face="monospace">cvXX</font>
(where <font face="monospace">XX</font> are two-digit numbers).</p>
<p>As I recall there is basically no guidance in the spec about
when, or whether, one might adjust feature parameter values at
different axis ranges, or how an implementation should handle such
changes. Wouldn't having at least one of these be a good idea? I
suspect that any such adjustments would have no effect in current
implementations, but I could be wrong. I'm therefore tempted by
the thought of adding guidance that any changes in feature
parameters via the Feature Variations system is strongly
discouraged, at least until someone comes back to "us" with a
solid motivation that we could then describe.</p>
<p>What do people think? Are there cases where this makes sense? Are
they compelling enough that e.g. I should support them in the
feature file grammar?</p>
<p>Skef</p>
</body>
</html>