Add support for font variation settings

[nigelmegitt]

Raising this as a placeholder for a possible future requirement, maybe on TTML2 or a future version. I have had recent internal feedback from BBC that we may need this feature.

Adding support for font variation settings, i.e. directing the presentation processor to set particular OpenType/TrueType font variation settings can be helpful. The specific example that has arisen is whether to use proportional or tabular variations for numbers. This is the tnum setting.

The choice of tabular/proportional affects readability in different ways in different circumstances:

• If using TTML to present something with numbers that change over time, in the same overall position, like a clock or a countdown timer, using tabular numbers prevents the inline position of individual digits from wobbling around as the number changes;
• however if presenting a static number as part of text to be read, using proportional numbers is considered easier on the eye by some viewers (research evidence for this claim needs investigating: a quick search suggests the evidence is thin or contrary to this position by the way, i.e. it might make no difference to readability at all).

The default setting varies by font, but many fonts offer both options.

[svgeesus]

Relevant spec for CSS is https://www.w3.org/TR/css-fonts-4/#font-feature-variation-resolution and also https://www.w3.org/TR/css-fonts-3/#font-rend-props

[nigelmegitt]

As discussed at the Burlingame TPAC f2f, this might reasonably be done using tts:fontVariant, which might in turn be extended to allow any of the font variation settings available to be tunnelled through to the text layout and glyph rendering layer(s).

[css-meeting-bot]

The Working Group just discussed Add support for font variation settings ttml2#399, and agreed to the following resolutions:

• RESOLUTION: WG recognises this may be a useful feature but defers to a future version.

The full IRC log of that discussion

<nigel> Topic: Add support for font variation settings ttml2#399
<nigel> RESOLUTION: WG recognises this may be a useful feature but defers to a future version.
<nigel> github: https://github.com/w3c/ttml2/issues/399

[nigelmegitt]

OK that is reasonable.

[skynavga]

@nigelmegitt can we close this, or should we proceed to define extensions on tts:fontVariant?

[nigelmegitt]

This is a useful addition still; it is substantive but not structural, so I would consider moving it to a future iteration of TTML2.

[skynavga]

This would not be a candidate for a future edition of TTML2 since it would require modifying the TTML2 schemas. However, we can consider this for addition to a TTML3 core specification (since it would entail modifying the value space of an existing style property, and not be a candidate for an external module).

[nigelmegitt]

When did we decide that a schema modification would block addition to TTML2?

If we need a new version number for the spec and the changes are not structural, but incremental as in this case, I would say that warrants a minor version number update rather than a major one, e.g. TTML2.1. But I wouldn't be averse to including it in _n_th Edition either.

[skynavga]

This was decided when the group first developed TTML1 1st Edition, and we agreed that any substantive addition of functionality, particularly any addition that required a schema modification, constituted a trigger for a new major Version, while increments of Edition were for Bug fixes (possibly even minor schema changes) within a given Version. So, at least for TTML, new elements/attributes have to go into a new Major Version and bug fixes to elements/attributes can go into a new Minor Version (i.e., Edition).

I'm not sure if you were yet in the WG when we adopted this policy, but it has been the working policy at least since 2006. This is why I originally objected to IMSC 1.1 adding new functionality as it violated the standing policy that applied to TTML.

[nigelmegitt]

In that case we should define this new vocabulary in a separate "advanced text styling" module (that's not a name, just a description).

[skynavga]

I agree. If we can define new functionality in external modules, then we can avoid changes to the core specifications. The only problem comes when we want to make (non-bug fix) changes to element content models or attribute value spaces. For example, adding a new element to the Block.class or Inline.class vocabulary groups requires a schema change. So we could only do this in a new major version with a new schema (for that version).

Note, however, that a newly defined module could specify new elements or attribute types and publish a new schema module for those new types.

A new major version schema could add such elements and attributes to its existing element and attribute group definitions such that the new module's functionality is formally included in the new major version.

An older major version implementation could also be retrofitted to recognize the new elements and attributes using the new schema module to provide validation support. Other implementations of the older major version would prune those unrecognized elements and attributes, so they would not be visible to an older validating processor (and, therefore, should not produce a validation error as such).

As an example of such an implementation, the TTT tools allow the user to specify multiple additional schema modules on the command line in order to validate elements/attributes that were not in the original published schemas. However, I have not tested this functionality for the case that the additional schema module declares its definitions in the same namespace as a built-in schema. We originally added this mechanism to support validating SMPTE-TT extensions.

One of the reasons that schema changes drive a new major version is because tools like JAXB [1], which is commonly used to deserialize (unmarshal) schema based XML content (like TTML), generates Java code based on the schema definitions, essentially baking the schema into compiled code. TTT uses JAXB to deserialize TTML into a concrete infoset representation that adheres to JAXB. We have maintained a JAXB binding file [2] in the ttml2 repository for many years now.

[1] https://en.wikipedia.org/wiki/Java_Architecture_for_XML_Binding [2] https://github.com/w3c/ttml2/blob/master/spec/xsd/ttml2-bindings.xjb