[MPEG-OTSPEC] Feature Variations and Feature Parameters

[John Hudson]

Talking this through...

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.

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’.

So, to Feature Variations applied to feature parameters...

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).

I am going to ignore the size 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.😛

I am trying to think of a circumstance in which there would be a 
compelling need for an ssXX 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 ssXX feature is 
/disabled/ 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 ss01 feature that substitutes the more complex 
double-storey g form; however, that form becomes too dense past some 
location in the intersection of wght and wdth 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.

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]’?

JH




On 2025-06-04 16:11, Skef Iterum via mpeg-otspec wrote:
>
> 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.
>
> The current draft adds functionality related to Feature Variations for 
> /lookups/ 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)/either/ the set of lookups 
> active for a feature for different axis positions, /or/ its 
> "parameters". Recall that the those parameters are specific to a given 
> feature tag, currently size, ssXX, and cvXX (where XX are two-digit 
> numbers).
>
> 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.
>
> 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?
>
> Skef
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

-- 

John Hudson
Tiro Typeworks Ltdwww.tiro.com

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20250605/f8ebb722/attachment-0001.htm>