This GitHub repository is used for discussion and review of proposals for registration of OpenType design-variation axis tags.

For background on OpenType variable fonts and design-variation axes, see Background on Design Variation Axes.

OpenType supports custom or “foundry-defined” axes, allowing any font developer to create a font with whatever axes they wish (provided the syntactic requirements for a custom tag are met). So, why bother going through the process to register an axis? The short answer is that it can provide better experiences for end users and create opportunities for font and application developers.

While a font family design can be varied in any number of arbitrary ways, there are some kinds of variation that can seem useful and interesting to many different foundries. With custom axes, different foundries could create families with the same kinds of design variants, but because they have each identified the same variants in different ways, applications have no way to interact with particular variants, and users have inconsistent experiences.

A registered axis provides two key benefits over custom axes:

• It fosters conventionality and familiarity.
• It facilitates interoperability.

Conventionality and familiarity: If different font developers independently decide to incorporate the same kind of design variation into their fonts, but refer to that variation in different ways, use different names for common instances, and use different scales, then usability is hindered: experience from using one font or family of fonts provides less benefit in relation to other fonts. Users can't anticipate that a behavior in one case will be in any way similar to other cases unless they happen to try them. But users can't even go looking for new fonts with a particular design variation if they can't even predict how to refer to it. This is the situation with custom axes: they don't provide any familiarity beyond a single font vendor. In contrast, a registered axis provides a basis for creating familiarity across fonts coming from any vendor. This increases usability of fonts for end users: if they want fonts with a particular characteristic, they can more easily find them. If they acquire fonts described as having a particular characteristic, they can more easily anticipate the results they will get in use. For example, by having optical size as a registered axis, many different font vendors can create fonts that incorporate this type of design variation, more users will gain familiarity and learn the benefits, and they will be more likely to seek this feature in new font acquisitions.

Interoperability: Interoperability means that certain relationships exist between different fonts, and that applications can utilize those relationships, or utilize characteristics of fonts that are implied. For example, consider font substitution behaviors: if certain text has been formatted with an italic font, but a different font must be substituted when content is viewed in some context, then the result will be best if another italic font is used (other things being equal). By having a conventionally-defined property of “italic”, an application can determine when the preferre font is italic, which alternate fonts are italic, and make the best choice. As another example, consider the optical size axis: by specifying the numeric scale to correspond to text size in points, that makes it possible for applications to create mechanisms to automatically choose an optical-size font variant.

The process described here will be used for registration of new axes for addition to the OpenType spec.

The goals of the process are to ensure that:

• There is consensus that a registered axis will be beneficial for use in fonts and text-layout applications, and there is commitment or, at least, reasonable expectation that the axis will be used by multiple vendors.
• A proposed axis is appropriate for use as a design variation axis and doesn't duplicate other registered axes, and there is a valid reason for treating this as a registered axis rather than as a custom axis.
• The proposed axis has a well-formed axis tag, and there is adequate and clear documentation of how the axis is meant to be used.

For more details, see How Proposals Are Evaluated, and the Proposal Summary form template. See also information provided in OpenType Design-Variation Axis Tag Registry.

Anyone is welcome to submit a proposal. You must have a GitHub account to do so. Also, your actual identity must be reasonably clear to other participants.

Before submitting a proposal, it may be helpful to get some preliminary feedback on your idea from other peers. This can be done in various ways, including discussion on TypeDrawers or the OpenType email list. You can also use the Issue mechanism for this repository: please apply the “new axis idea” label to your issue.

Note that, if a proposal is eventually adopted, it may undergo changes during the review process. Changes may come from the proposer, if they make refinements, but changes may also potentially arise from the community as a consensus emerges for a particular understanding of an axis, its behavior and its merits.

Also, please make sure you read the Contributing section below.

To submit a proposal, use this process:

1. Create a fork of this repository in your own account. (For details on creating and working with forks in GitHub, see Fork a Repo.)
2. Within that fork, create a new copy of the Proposal Summary form in a new sub-folder of the Proposals folder. The sub-folder name must be unique and should be a short name that can be used to refer to your proposal. If you are submitting an alternative to another proposal with the same name, then append your ID or the name of the vendor you represent. (Please use _ or - as delimiters, not spaces.)
3. Edit the new Proposal Summary with details for your proposal, and add any supporting files in the same folder.
4. Create a pull request to have your changes pulled into the upstream repository (the base fork of the repository). Your pull request will be checked to make sure the submission is well formed and in scope.

Note: It's recommended that you sync your fork with the upstream repo and resolve any merge conflicts within your fork prior to creating the pull request to merge changes from your fork back into the upstream repo. See the suggested workflow in Suggested Process for Submitting Changes using Git.

When a pull request for a new axis proposal is accepted, a label will be created in the repository using the short axis name. This label should be used for any future issues or pull requests related to this proposal.

To submit a combined proposal involving a group of multiple, inter-dependent axes, you should create a sub-folder under the Proposals folder for the combined proposal. You could provide a single Proposal Summary form, but there must be a separate Proposed Axis Details section for each axis. Alternatively, you can provide an overview file (Overview.md) with separate Proposal Summary forms for each axis, with a distinguishing qualifier—a short name or proposed axis tag—appended to the file name. (For example, “ProposalSummary_Grade.md”.)

In addition to the Proposal Summary form, a proposal should include other supporting files to help clarify the way the axis is meant to work or how it might be used. These might provide additional background information or demonstrations of usage. In particular, it is strongly recommended that demo fonts and specimens be provided: these are particularly useful to help others understand the intent and merits of a proposed axis. A video that demonstrates how a design changes across an axis range can also be very helpful. Supporting files can be submitted into the repo, or an “Other Supporting Files” page with pointers to external sites can be used. These can be provided at the same time the Proposal Summary is first submitted, or at any time later.

Every proposal for a new registered axis must be available for review and discussion for a period of at least one month before the axis will be registered. In addition to this minimum time period, there must be actual discussion and evaluation by independent contributors. It is essential to establish there is broad consensus on merits, and intent among separate vendors to use and support the new axis. The review period is intended for building and establishing this consensus. The proposal submitter should monitor activity and respond to questions or concerns.

For general information on evaluation criteria, see How Proposals Are Evaluated.

Feedback can be provided using the Issues mechanism, or by submitting a new pull request with proposed changes to the proposal contents. Any pull request generated by the proposal submitter will be approved by adminstrators if the proposal remains well formed and in scope. A pull request with changes to a proposal that is generated by parties other than the original submitter will need to be approved by the submitter.

When a new axis proposal is submitted, a label will be created in the repository using the short axis name. This label should be used for all subsequent issues or pull requests pertaining to that proposal.

The ultimate goal of registered axes is that they be used, not just that they appear in the registry. Therefore, in order for a proposed axis to be registered, there must be broad consensus on the proposal: that the proposal itself is mature, that the axis has merits, that it will get used.

Consensus does not require unanimous agreement. It does require broad agreement that any serious objections have been addressed. A consensus very often requires some willingness to make compromises to converge on something that most parties can accept.

A particular requirement for a mature proposal is that the draft description of the axis for publication in the Registry is complete and clear.

For details on how merits of a proposed axis will be evaluated, see How Proposals Are Evaluated. Consensus on merits will be established by seeing that questions are answered and the proposal is sufficiently clear, and that any significant objections have at least been responded to, if not addressed.

Beyond agreement in principle on merits, it is also necessary to establish that the proposed axis will be used. For any proposed axis, there must be at least three separate foundries that each indicate intent to use the axis in three or more separate font families or variable fonts. If the intended usage for an axis is primarily to have selection of axis values be controlled via programmatic interaction rather than direct user manipulation, then additionally there must be a statement of intent to implement support for the axis from at least two major platform vendors or three independent layout library owners. In some cases, it may be requested that at least two of the foundry or software supporters of a proposal provide demo independent implementations in order to confirm that there is a common understanding of how the proposed axis is expected to behave and be used.

Microsoft, as custodians of the OpenType specification, will be the final judge that a proposal is mature, and that there is broad consensus and industry support. This decision will be made in consultation with and on the recommendation of a panel of independent advisors. The role of panel members will be primarily to confirm that important issues have been considered, that the proposal is mature, and that there is broad consensus. Individual panel members may have particular opinions on a proposal, but are expected to separate their role in evaluating the merits of a proposal from the role of evaluating consensus.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repositories using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.