[OTVar] Next step for variable fonts: process for registering design variation axes

Peter ConstablePeter Constable Posts: 141
edited November 22 in Font Technology
In my talk at ATypI (video here), I mentioned that I was working on creating an open process for people to propose design axes for registration, and for review and discussion of those proposals. That is done and ready for anyone to start participating.

For this process, I have created a project on GitHub: 
https://github.com/Microsoft/OpenTypeDesignVariationAxisTags 

To participate, you'll need a GitHub account. 

The intent of the process is to end up with a set of registered design axes that are useful and that actually get used! In general, I think a smaller set of registered axes that get used will be more helpful for the type industry and for users than to have a lot of registered axes with many that are used infrequently. 

The process is set up in a way that, hopefully, will lead to that result: an axis can't get registered without it getting discussed and unless there are commitments to use it.

Note that you'll always be able to use custom axes (per the OT spec, uppercase tags please!) in variable fonts. So, if you have something you want to use in your fonts but haven't found others that also want to use it, you won't be blocked.

Also note that registered axes don't necessarily have to be intended for use in variable fonts. Static, non-variable fonts can include a STAT table to describe relationships within a family, and design axis tags are used in that table.

For details on the process, follow the link above: it will take you to the README page for the project. And if you have questions, feel free to ask here or to privately contact me or my MS colleagues, Rob McKaughan or Si Daniels.

Comments

  • I forgot to add: good success in getting registered axes that you'll find useful depends on your participation. So, please get involved:

    - Provide review feedback on other's proposals: join the discussion; ask questions; make suggestions for how the proposal can be improved; indicate ways you think a proposed axis could be useful, or not so useful.

    - Give support to proposed axes you think would be particularly useful. If you really think a proposed axis will be useful, then start considering specific projects in which you will put it to use. If you're ready, let the proposer know your intent to make use of the axis. (That's one of the necessary conditions for an axis to be registered.)

    - Submit your own proposal for a new registered axis.

  • May I ask you why it is so important to have "registered design variation axis"? Wouldn't it be better to keep the unlimited idea of many axes? I know that this is just a proposal for the most common ones and it could have many more, but I am pretty sure if we have such a proposal software developers will just support these axis and no others in there apps. A quite similar situation we already have with usWeightClass values. According to OpenType Spec any value between 1 and 1000 should be possible, but actually we endet up with steps of 100, e.g. CSS code. In the past the people maybe thought, why would we need more then 9 different weights, but currently we have font families with way more. So, currently we may think why should we need more then 100 axis, but maybe in the future there will be a need for it.
  • Registration of potentially-useful axes allows for interoperability and greater familiarity. Please see these docs for a bit more discussion on benefits:

    https://www.microsoft.com/typography/otspec/dvaraxisreg.htm (section: "How to register a design-variation axis tag")

    https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/blob/master/BackgroundOnAxes.md

    https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/blob/master/HowProposalsAreEvaluated.md



  • First proposal, for a spacing axis, has been submitted by Frank Blokland. Please see his proposal doc here:

    https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/Spacing_Axis
  • May I ask you why it is so important to have "registered design variation axis"?
    For interoperability, which means, when you set up your typography in Family-A and then realise you want to swap to Family-B, all that set up work doesn't have to be done from scratch - the settings are seamlessly transferable. 
     Wouldn't it be better to keep the unlimited idea of many axes?
    Its not unlimited - there is a current limit of 64k many axes. 
    I know that this is just a proposal for the most common ones and it could have many more, but I am pretty sure if we have such a proposal software developers will just support these axis and no others in there apps.

    The issue of visibility is orthogonal to interoperability. 

    Software developers are slightly less likely to completely ignore the registered axes than if they are unregistered, but I don't think it really makes a difference to them. They either want to support Variations 'invisibly' ("smaller filesizes are enough for us, kthxbye") or provide users only the flagged-as-visible axes ("just a taste") or provide users everything ("whole hog") 
    A quite similar situation we already have with usWeightClass values. According to OpenType Spec any value between 1 and 1000 should be possible, but actually we endet up with steps of 100, e.g. CSS code. In the past the people maybe thought, why would we need more then 9 different weights, but currently we have font families with way more. So, currently we may think why should we need more then 100 axis, but maybe in the future there will be a need for it.
    64K axes ought to be enough for anybody ;)
  • I'd add to what Dave said: 

    Software that supports variable fonts is likely to support whatever axes are in a given font, custom or registered, in terms of exposing in UI and ability to select and use variants. 

    But software is not going to know what a custom axis is doing, and so cannot do anything with it beyond allowing manual selection of an axis value by the author. Even if two fonts have custom axes using the same axis tag, software can't assume there is any connection between them, so if you switch from one to another any setting for custom axes will likely be cleared and need to be redone.
  • @Peter Constable
    Should axes name carry more semantics? For example, `wght` axis should cause all the glyphs' advance width monotonically increasing along the `wght` value.
  •  Wouldn't it be better to keep the unlimited idea of many axes?
    Its not unlimited - there is a current limit of 64k many axes.

    That’s not what Olli meant.

    BTW, the limit for axes is not 64k. It’s 52⁴ = 7311616 (52 letters in combinations of four letters). The 64k limit only applies to axes per font.

  • @Peter Constable
    Should axes name carry more semantics? For example, `wght` axis should cause all the glyphs' advance width monotonically increasing along the `wght` value.
    While unusual, there are typefaces in which the advance width decreases as the weight increases. Yanone Kaffeesatz is one example. In uniwidth typefaces like my own FF Hertz, the advance width doesn’t increase at all.
  • A registered axis potentially could specify semantic details, such as a requirement that all glyphs should or must change uniformly in a particular way. 

    The 'slnt' axis to some extent makes such an assumption, though it's not stated as an explicit requirement. And 'wdth' does state an expectation, though it doesn't enforce a precise metric. For 'wght', though, there is far too much history to impose any new constraint now.
  • Where should a uniwidth toggle go? (Dynamic typography pines for it.)
  • A registered axis potentially could specify semantic details, such as a requirement that all glyphs should or must change uniformly in a particular way. 

    The 'slnt' axis to some extent makes such an assumption, though it's not stated as an explicit requirement. 
    I expect slanted fonts will not slant ALL glyphs; some may be rotated (*) or even remain the same. 
  • A registered axis potentially could specify semantic details, such as a requirement that all glyphs should or must change uniformly in a particular way. 

    The 'slnt' axis to some extent makes such an assumption, though it's not stated as an explicit requirement. And 'wdth' does state an expectation, though it doesn't enforce a precise metric. For 'wght', though, there is far too much history to impose any new constraint now.
    For some axes (like wght or wdth) we can add recommendations to it.
    ps. Could I register x000 -- x999 for custom parameters? :smiley:
  • As with feature tags, custom axis tags are permitted as long as they only use uppercase letters (plus digits and space), while registered axes will use lowercase letters (plus digits and space). I don't think registering x000-x999 makes much sense. Effectively, all-uppercase axes are registered as a pattern for the purpose of custom usage. 
  • I think we can have a `ppem` axis, like `opsz` but for physical pixels. Variation data for this axis may have a lot of intermediate regions to perform pixel alignment, for icon fonts or dense scripts (like ideographs).
  • The second proposal, for a height axis, has been submitted by Renzhi Li (aka Belleve Invis). The proposed height axis is specifically for use in vertical layout, analogous to the width axis for horizontal layout. 

    See the proposal details here:
    https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/Height_Axis
  • And now a third proposal, this also from Renzhi: for a PPEM axis. See the proposal details here:
    https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/PPEM_Axis

    This proposed axis would be pretty different from the kinds of axes (registered or otherwise) than we've seen before, so it will deserve careful consideration and good discussion.
Sign In or Register to comment.