The CommonType project is work-in-progress. Its immediate aim is to provide publicly accessible documentation of the common font format that is based on the “SFNT container” developed by Apple in the TrueType® format, and later refined in the OpenType® format and the ISO Open Font Format (OFF) standard.
Currently, SFNT-based fonts are specified in several places:
However, over the last two decades, many people in the font technology world expressed concerns about the quality of the specifications. The SFNT-housed fonts “work”, but the way they work in various environments is often the result of developers reading the specs and then relying on a lot of fragmented knowledge that is not easily accessible. The CommonType Containers wiki article attempts to give a high-level overview.
In June 2020, @simoncozens forked AOTS and @twardoch tweeted:
While I’ve enjoyed being part of a few ad-hoc groups over the past few years, at the same time it has worried me that they’ve increasingly been “ad-hoc”. When working with font makers & font tool makers, I know that a lot of energy goes into working around problems introed by OS makers and end-user app makers, and I know these problems are often because there is no real font format spec.
To which @davelab6 replied:
We will make one
So, here we go!
In 2002, Eric Muller at Adobe created the Annotated OpenType specification (AOTS). It included the text of the OpenType specification, “(approximately) that of the 1.4 specification, but some parts [were] absent” (current version of the OpenType spec is 1.8.3). AOTS also included annotations witten by Eric, as well as Java tools for manipulating OpenType font files. In 2016, Adobe published AOTS on Github under the Apache 2 license.
The Java code in the AOTS project is of limited use today (2020). Instead:
However, we have recognized that the AOTS project includes a liberally licensed version of the text of the OpenType® font format specification, though not the up-to-date version.
Clean up house, remodel, then extend it, and live while doing it!
— @twardoch
The CommonType project provides a publicly accessible rendition of the AOTS text, and aims to improve and extend it. We are using the term “CommonType” as a working name, as we do not guarantee that the content of the project will fully match OpenType, TrueType or OFF.
We want CommonType to be open: liberally licensed, open source and based on open and transparent procedures.
Here are some goals that we have. This is work in progress, these goals may change.
First, we consider the CommonType content as documentation (docs): we document the existing world: we document the SFNT-based font formats (OpenType, TrueType, OFF), we document the real-life behavior of implementations, and, as much as possible, we document the texts that affect that behavior, i.e. the the “normative specs” of these formats. At this point we avoid using the terms specification (spec) or standard. We use these terms conservatively, when it’s appropriate. We consider using these terms more when a portion of the CommonType docs becomes formalized.
Provide a liberally licensed rendition of the documentation (text) that describes SFNT-based font formats (OpenType, TrueType, OFF). The documentation should use easily-reusable text formats such as Markdown. Makers of fonts and of tools that work with fonts should be able to create non-normative texts based on the current documentation: quote from the text, translate it, summarize it, annotate it.
The CommonType documentation should describe all aspects of the SFNT-based font formats (OpenType, TrueType, OFF) that the normative “specifications” or “standards” of these formats describe.
Identify weak language and logic in the existing documentation, for example ambiguous terminology or contradictory statements.
Improve the editorial quality of the documentation. Formalize the language, improve writing clarity, remove inaccurate legacy language outdated by later revisions, unify terminology, remove logical contradictions.
Create a platform where interested parties can annotate and comment the spec.
Bring in real-life knowledge about existing implementations and their quirks.
Slim down, not just add. Get rid of legacy baggage. Deprecate unneeded stuff or move it to archival content. Examples: kern
table, the MacOS classic name
.
Create transparent procedures for working on the documentation.
Use CommonType as a platform for discussion about future font formats. Provide a platform for proposing functional additions/extensions to the documentation, and for drafting proposals that extend the SFNT-housed font formats.
Devise a plan for a comprehensive overhaul of the documentation: split the text if needed into a mandatory formal portion (clear specification of the format), and more freeform annexes, annotations, recommendations for font developers and for implementers of software that uses fonts.
Give some implementers the chance to implement CommonType in addition to or as an alternative to the other formats. Create versioned profiles of the spec so that implementers can actually build tests and implement towards realistic goals. Work with developers on conformance suites. Conceptual analogy: PDF/X or PDF/A formats, which are stricter subsets of PDF.
Provide opportunities to submit the additions/extensions to the more formally-driven bodies (OpenType, ISO OFF), so the owners of these specs can adopt the work of the CommonType community.
docs
folder contains a Markdown representation of the text.source
folder contains the AOTS sourcesCommonType is currently a personal project of select individuals who have an interest in font technology:
CommonType is not currently backed or endorsed by any organization or company. We are looking forward to your comments and discussion.