<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Talking this through...<br>
</p>
<p>In general, there is ‘basically no guidance’ on how to implement
feature parameters, and some existing capabilities of feature
parameters within the font format already break in the wild. To
their credit, Adobe have tried to implement feature parameter
support in apps, e.g. making sylistic set feature names visible in
OTL menus in InDesign. But the implementation is simplistic and
doesn’t take into account the functional capabilities of feature
parameters within the OTL script-langsys-feature hierarchy, within
which a feature parameter might be different for the same feature
in different langsys entries and different script entries. If a
font is built in such a way, only feature parameters that are the
same across all scripts and langsys entries are displayed in the
Adobe OTL menu. That might be a reasonable solution if a text
selection contains more than one script segmented run or
differently tagged language content, but it looks like Adobe is
simply not parsing the feature parameters data beyond a simple
expectation.</p>
<p>I describe that not to point to Adobe doing it wrong, but to what
happens when the specification goes no further than saying ‘Here’s
some data that software makers might do something with’.</p>
<p>So, to Feature Variations applied to feature parameters...</p>
<p>We have a potential functionality that it isn’t clear a) how it
might be useful, and b) how it should be implemented in display of
feature parameters (especially bearing in mind text selection
conditions such as more than one variation location being active
with a text selection to which a stylistic set feature might be
applied).</p>
<p>I am going to ignore the <font face="monospace">size </font>feature,
because I am not aware of any environments that expose feature
parameters for this feature, and also because I think it is a
silly hack of a feature that should never have been registered.😛</p>
<p>I am trying to think of a circumstance in which there would be a
compelling need for an <font face="monospace">ssXX</font> feature
to have different feature parameters in different areas of the
variable design space. The implication would be that some
significant difference exists between the substituted glyphs in
one part of the design space vs another, such that it no longer
makes sense for the same label to be applied in an OTL menu. The
most likely use I can think of is actually that an <font
face="monospace">ssXX</font> feature is <i>disabled</i> for
part of the design space. Consider, for example, a design in which
the default lowercase g is the simple form with descending hook,
but there is an <font face="monospace">ss01</font> feature that
substitutes the more complex double-storey g form; however, that
form becomes too dense past some location in the intersection of <font
face="monospace">wght</font> and <font face="monospace">wdth</font>
variation axes. So in that region of the design space, Feature
Variations point to a lookup that map the default forms to
themselves and effectively disable the stylistic substitution
feature. The feature still exists, though, and it doesn’t make
sense to have a feature parameter label that says something like
‘Double-storey g’, since in that part of the design space that
isn’t what it produces.</p>
<p>Question: is it possible for Feature Variations applied to
feature parameters to produce a null result, i.e. no feature
parameter for a given design space location? Or is the assumption
that, in my hypothetical example, one would need a feature
parameter label that says something like ‘[Retain default]’?</p>
<p>JH<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2025-06-04 16:11, Skef Iterum via
mpeg-otspec wrote:<br>
</div>
<blockquote type="cite"
cite="mid:32b3bb50-1f0d-4624-9f74-72b1790717c9@skef.org">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
mpeg-otspec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>
<a class="moz-txt-link-freetext" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
John Hudson
Tiro Typeworks Ltd <a class="moz-txt-link-abbreviated" href="http://www.tiro.com">www.tiro.com</a>
Tiro Typeworks is physically located on islands
in the Salish Sea, on the traditional territory
of the Snuneymuxw and Penelakut First Nations.
__________
EMAIL HOUR
In the interests of productivity, I am only dealing
with email towards the end of the day, typically
between 4PM and 5PM. If you need to contact me more
urgently, please use other means.</pre>
</body>
</html>