A beta for OpenType 1.9 has been published for two-week public review. This version introduces a significant enhancement in OpenType: a second version of the COLR table (version 1) for color fonts. The new COLR version provide support for gradients and other capabilities in vector colour fonts; the capabilities are very similar to those in SVG Native but can be used in applications that do not have or (for whatever reasons) cannot add support SVG. The new COLR version also provides greater integration with font variations—something that is not supported at all with OT-SVG.
The COLR enhancements were designed jointly with Google, who have been implementing support in the FontTools project, the Skia and Freetype libraries, and in Chrome. It can be tested already in the Chrome Canary builds by browsing to chrome://flags/#colr-v1-fonts to enable the feature. Sample fonts using COLR v1 (with OT-SVG equivalents for comparison) are available at https://github.com/googlefonts/color-fonts.
OpenType 1.9 also addresses a number of feedback items that have been reported on the OpenType spec. Among the more significant technical improvements are clarifications of several items related to TrueType outlines and the TrueType hinting language.
The landing page for the beta is at https://docs.microsoft.com/typography/opentype/otspec190/ot190beta. The public review period will end November 26, and the new version will be published shortly after that.
Particular thanks are due to Behdad Esfahbod, Dominik Röttsches, Rod Sheeter, Cosimo Lupo and Dave Crossland for their contribution to and support of the work on COLR v1; to Greg Hitchcock for several contributions including many details regarding TrueType; and to John Hudson, Laurence Penney, any many others who reported issues or contributed valuable input that went into this version.
Comments
I'd find it interesting if you (someone) were to try to convert some of your OT-SVG fonts to COLR v1 format, both to see how they compare (e.g., COLR v1 ought to provide size savings), but also to see what SVG capabilities were used that aren't supported (yet) in COLR. I'm pretty sure there are several that could be implemented using COLR v1 formats (Big Party, Broshk-Lime, DigitaltS-Fruits...), and some even COLR v0 (e.g., UseYourImagination—I particularly like that one). Some might be a challenge (not clear what SVG caps were used for Digico-Beryl), and quite interesting to attempt (Digiac—a variation axis might be used for animation).
It does not lead to an intuitive experience for the user who will be confused as to why the very condensed style is at wdth 37 or 43 or something like that, and the very extended at wdth 172 or wherever it lands in percentage of the normal width.
In the case of a very large family of widths like our GT Flexa, we went with the following setup:
(wdth axis value — subfamily name)
0 — X Compressed
50 — Compressed
75 — Condensed
100 — Standard
125 — Extended
150 — Expanded
200 — X Expanded
This also roughly reflects how the design changes across the wdth axis, thus leading to good and fluid-feeling animations between the widths, while still offering a system that can be understood by the user.
I am taking it that Thierry is suggesting that each typeface can use its own definition for how condensed is “condensed” and so on. Basically, this is the old status quo of every font family having its own definitions of what labels mean.
I think fundamentally, there are two options for how any system can be designed, and they have different advantages.
Thierry’s approach means that fonts can each map width variation to the axis values in different ways, but the labels and values for the standard instances are the same.
The spec approach means that the values used by fonts are potentially much more compatible across fonts. Set two different fonts at 80 width and you will get roughly the same amount of condensed-ness relative to the regular. Also true if you have width set to 80 and change fonts.
Unlike Thierry, I see a great deal of value in this, and I am not immediately seeing value in their proposal. But then I have been using the existing system for some years now.
With ‘potentially’ and ‘more’ being key words in that sentence.
There remains nothing that defines the relationship of the width of the two regular designs, and hence no possibility of real compatibility in terms of something useful like set width.
The wdth axis says something about the width of the shapes themselves but nothing about the metrics of those shapes. In fact – extended styles are usually spaced tighter than normal styles because they're more tailored to headline usage.
There was no way to define a scale for wdth that allowed for certain comparison between unrelated fonts _and_ also integrate with the "Width" axis that was already widely used in implementations (GDI, CSS, ...).
Btw, the wdth axis is not something that has been touched for OT 1.9, so is not in scope for the OT 1.9 beta feedback.
I made my first attempts to convert my SVG-OT fonts to COLRv1 and I am wondering why COLRv1 defines linear Gradients with three points p0,p1,p2
https://github.com/googlefonts/nanoemoji
Measured across a pangram of English alphabet letters, the figures are as follows:
(Axis value — Subfamily name — Average pangram width compared to average pangram width of Standard Regular style)
0 — X Compressed — 38.8%
50 — Compressed — 74.0%
75 — Condensed — 87.6%
100 — Standard — 100%
125 — Extended — 122%
150 — Expanded — 143.9%
200 — X Expanded — 188.6%
One big problem I have with the explanations given above is that they all break apart across different weights. Between the Regular and the Black weight of GT Flexa, there’s up to 19.2% variation in width difference: the X Compressed Black is 58.0% of the Standard Black, but only there’s only a 38.8% difference in the Regular weights. In X Expanded, the variation is still a noticeable 4.7% from the Regular to the Black weight.
Additionally, even the supposedly normative Standard’s width of course varies quite a lot. If Standard Regular’s width is 100%, Standard Black is 109.5%.
You really can’t really use this metric to pick the right styles across large families anyway, or the solve justification across the whole range of a large design space. The variation within such families is huge, and will be huge across families as well.
Meanwhile, humans can obviously work much better with a system of clean, round numbers that follow a type design-driven logic instead of a math-driven logic. Developers who have to pick the Extended Regular weight can use
in GT Flexa’s system. In the supposed spec version, this would be
Sure, that works okay. But then you want the Expanded instead and it turns into
vs
I’m not saying GT Flexa’s systems is without flaws, and of course there’s downsides to a less machine-driven approach.
But we offer large families as a foundry, and I also develop websites with those large families myself, I can certainly speak to the user-unfriendliness of the spec system. Speaking of in-app usage, trying to select 75% in a slider UI instead of 87.6% is also clearly easier.
You really should not use 0 as a wdth value. The OT spec is clear about that:
"Valid numeric range: Values must be strictly greater than zero."
Fonts with OS2.usWidthClass set to 0 or with a wdth variable axis using 0 as a minimum are non-conformant, will break inter-operability, potentially mess up some layout algorithms, and make wdth even more imperfect than it already is. Font vendors really shouldn't do that.
If you want a very small value, use 1, but not 0.