<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>After absorbing this and chatting with some other people I've
arrived at a more concrete, if still tentative, idea of what
editorial advice would make sense. This is still completely
separate from the question of when it would make sense to add such
advice, relative to all of the processes we're subject to.</p>
<p>The FeatureParam mechanism is both analogous and closely related
to the layout feature mechanism, in that it is extensible. And
although the specification (of course) encourages official
registration, and therefore standardization, of new features --
presumably along with any associated feature parameters -- it
would hardly be shocking for there to be some non-standardized
features, possibly even with their own FeatureParams, either for
proprietary use or during periods of experimental development. The
specification shouldn't encourage this, exactly, but I think it's
reasonable to "provide" for it. <br>
</p>
<p>Therefore, if we were to add editorial advice, I think it makes
sense to say:</p>
<ol>
<li>For a given feature, any differences between FeatureParam
content across variations shall be guided by the standard for
that feature and those parameters.</li>
<li>If that standard does not discuss feature variations, then it
is strongly recommended (or whatever other appropriate
recommendationesque language is appropriate) that FeatureParam
content stay the same across all variations.</li>
<li>"Same content" does not imply "same offset" -- the actual
tables can be duplicated.</li>
</ol>
<p>Skef</p>
<div class="moz-cite-prefix">On 6/5/25 1:19 PM, John Hudson via
mpeg-otspec wrote:<br>
</div>
<blockquote type="cite"
cite="mid:acd9a5f1-3f33-4691-a499-091baa73bf6f@tiro.ca">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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 moz-txt-link-freetext"
href="mailto:mpeg-otspec@lists.aau.at" moz-do-not-send="true">mpeg-otspec@lists.aau.at</a>
<a class="moz-txt-link-freetext"
href="https://lists.aau.at/mailman/listinfo/mpeg-otspec"
moz-do-not-send="true">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" moz-do-not-send="true">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>
<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>
</body>
</html>