-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for font variation settings #13
Comments
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 |
As discussed at the Burlingame TPAC f2f, this might reasonably be done using |
The Working Group just discussed
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 |
OK that is reasonable. |
@nigelmegitt can we close this, or should we proceed to define extensions on |
This is a useful addition still; it is substantive but not structural, so I would consider moving it to a future iteration of TTML2. |
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). |
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. |
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. |
In that case we should define this new vocabulary in a separate "advanced text styling" module (that's not a name, just a description). |
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 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 |
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:
The default setting varies by font, but many fonts offer both options.
The text was updated successfully, but these errors were encountered: