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
- 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.
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
https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/Spacing_Axis
Its not unlimited - there is a current limit of 64k many axes.
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")
64K axes ought to be enough for anybody
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.
Should axes name carry more semantics? For example, `wght` axis should cause all the glyphs' advance width monotonically increasing along the `wght` value.
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.
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.
ps. Could I register x000 -- x999 for custom parameters?
See the proposal details here:
https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/Height_Axis
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.
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:
The optical axes are:
See the proposal overview here:
Type Network Parametric Axes Proposal Overview
See the proposal details here: https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/blob/master/Proposals/Glyph_Extension_Axis/ProposalSummary.md
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
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.
Why not just insert the kasheeda character with local Width applied to it?
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?
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,
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.
”The Width axis typically affects all horizontal aspects of the glyph proportionally,”
Is that true?
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.