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

Peter Constable

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.

Peter Constable

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.

Olli Meier

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.

Peter Constable

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

Peter Constable

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

Dave Crossland

Olli Meier said:

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

Peter Constable

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.

Belleve Invis

@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.

Jens Kutilek

Dave Crossland said:

Olli Meier said:

 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.

Jens Kutilek

Belleve Invis said:

@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.

Peter Constable

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.

Hrant Հրանդ Փափազեան Papazian

Where should a uniwidth toggle go? (Dynamic typography pines for it.)

Dave Crossland

Peter Constable said:

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. 

Belleve Invis

Peter Constable said:

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?

Adam Twardoch

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. 

Belleve Invis

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).

Peter Constable

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

Peter Constable

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.

Peter Constable

A fourth proposal — this is really eleven proposals wrapped together.

Type Network has submitted a proposal for a system of 8 parametric axes, along with three optical axes. Use this thread for general discussion of the proposal overall. Please create separate issues for specific details or discussion of specific axes within this proposal.

The parametric axes are:

• X Opaque, X Transparent, Y Opaque, Y Transparent
• Y Transparent Ascender, Y Transparent Descender, Y Transparent Uppercase, Y Transparent Lowercase

The optical axes are:

• Grade
• Per-Mille Weight
• Per-Mille Width

See the proposal overview here:
Type Network Parametric Axes Proposal Overview

Peter Constable

Another axis proposal has been submitted, for a "glyph-extension" axis. The proposed axis is intended for changing the width of specific glyphs, e.g. for use in justification.

See the proposal details here: https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/blob/master/Proposals/Glyph_Extension_Axis/ProposalSummary.md

Hrant Հրանդ Փափազեան Papazian

To me Grade is legacy logic; having two flavors of weight variance made great practical sense in the discrete era, but in the continuous era it's counter-intuitive. Much more elegant would be to avoid coupling width and weight, by having a uniwidth toggle to replace the half-measure of grades. If you'd like gain compensation as well, that would be its own axis, not tied in to a necessarily inflexible combination of weight and static spacing.

Concerning the most recent proposal:
— Why not just use the Width axis locally? (Maybe I'm missing something.)
— What happens when there's more than one axis that "should take effect once all other axes have been applied"? I guess we need a Taarof* value attached to each such axis to resolve the order... Just kidding! I hope.

* http://www.bbc.com/travel/story/20161104-the-persian-art-of-etiquette

John Hudson

Why not just use the Width axis locally? (Maybe I'm missing something.)

The Width axis typically affects all horizontal aspects of the glyph proportionally, while the Extension axis (I'd prefer the name Elongation) will often only affect the horizontal length of part of the glyph. Arabic kashida style elongation is the obvious example, in which the stroke that connects to the next glyph is elongated while the constitutive letter shape is not widened.

I think it makes sense to separate the two behaviours, in anticipation of fonts that have both Width variation in terms of condensed or widened forms and Extension variation for justification purposes.

Hrant Հրանդ Փափազեան Papazian

OK.
Why not just insert the kasheeda character with local Width applied to it?

Dave Crossland

Hrant H. Papazian said:

OK.
Why not just insert the kasheeda character with local Width applied to it?

Because that would make changes to the x opaque shape of the glyph; such elongation is intended to only change the x transparency.

Peter Constable

Kashida glyph insertion can only work if there is a completely-flat stroke to be elongated. That's a significant constraint.

Hrant Հրանդ Փափազեան Papazian

@Peter Constable Good point.

John Hudson said:

I think it makes sense to separate the two behaviours, in anticipation of fonts that have both Width variation in terms of condensed or widened forms and Extension variation for justification purposes.

I wonder though whether the widening of an Arabic letter should come via its horizontal connector anyway, making the distinction moot. I guess that might be too prescriptive however.

There's also the complexity of letters that don't connect... Is it OK if applying an attribute sometimes makes no change?

John Hudson

Hrant,

The GEXT axis proposal envisions being applicable to both joining and non-joining glyphs. If that is the case, in an Arabic font I would anticipate a GSUB trigger in the GEXT axis design space that substitutes a flexible form of an isolated or final letter which can then adjust in width. [I've already queried whether it makes sense for joining and non-joining letter elongation to be handled in a single axis, or perhaps should be split across separate axes so that they are independently applicable.]
_____

Peter, 

Kashida glyph insertion can only work if there is a completely-flat stroke to be elongated. That's a significant constraint.

Yes, but that constraint exists because there is no post-justification shaping of the tatweel* or, indeed, of any of the text around it. That issue doesn't go away if the elongations are applied via the GEXT axis rather than via tatweel insertion, because GEXT outcomes may have GSUB and GPOS implications.


* I use the term tatweel to distinguish the mechanism — inherited from metal type — of inserting an elongating join piece, vs. kashida as an elongation of the letter glyph.

Deleted Account

John:
”The Width axis typically affects all horizontal aspects of the glyph proportionally,”

Is that true?

John Hudson

I mean it is typical for an optical width adjustment of a glyph to affect all the x-direction aspects, both transparent and opaque. If you take a normal width Latin letter and expand the width optically, you are typically affecting the sidebearing distance-from-stem, the stem weights, and the counter width.



This differs from the kinds of variation envisioned for the GEXT axes, which could apply to only elongate or contract part of the glyph shape.

Regardless of how individual designs are implemented, the point is that wdth and gext may involve independent variation.

Deleted Account

Thanks John. There are two important points here, so I will eloborate on the repo.

Belleve Invis

The current definition of `wdth` may have a big problem on dealing with rotated glyphs...