[MPEG-OTSPEC] Feature Variations and Feature Parameters

Skef Iterum skef at skef.org
Thu Jun 12 21:50:34 CEST 2025 

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.

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.

Therefore, if we were to add editorial advice, I think it makes sense to 
say:

 1. For a given feature, any differences between FeatureParam content
    across variations shall be guided by the standard for that feature
    and those parameters.
 2. 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.
 3. "Same content" does not imply "same offset" -- the actual tables can
    be duplicated.

Skef

On 6/5/25 1:19 PM, John Hudson via mpeg-otspec wrote:
>
> 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.
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20250612/5efff394/attachment.htm>

More information about the mpeg-otspec mailing list