From skef at skef.org Thu Jun 5 01:11:03 2025 From: skef at skef.org (Skef Iterum) Date: Wed, 4 Jun 2025 16:11:03 -0700 Subject: [MPEG-OTSPEC] Feature Variations and Feature Parameters Message-ID: <32b3bb50-1f0d-4624-9f74-72b1790717c9@skef.org> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at tiro.ca Thu Jun 5 22:19:39 2025 From: john at tiro.ca (John Hudson) Date: Thu, 5 Jun 2025 13:19:39 -0700 Subject: [MPEG-OTSPEC] Feature Variations and Feature Parameters In-Reply-To: <32b3bb50-1f0d-4624-9f74-72b1790717c9@skef.org> References: <32b3bb50-1f0d-4624-9f74-72b1790717c9@skef.org> Message-ID: 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: