Introducing OpenType Variable Fonts
Version 1.8 of the OpenType font format specification introduces an extensive new technology, affecting almost every area of the format. An OpenType variable font is one in which the equivalent of multiple individual fonts can be compactly packaged within a single font file. This is done by defining variations within the font, which constitute a single- or multi-axis design space within which many font instances can be interpolated. A variable font is a single font file that behaves like multiple fonts.
There are numerous benefits to this technology. A variable font is a single binary with greatly-reduced comparable file size and, hence, smaller disc footprint and webfont bandwidth. This means more efficient packaging of embedded fonts, and faster delivery and loading of webfonts. The potential for dynamic selection of custom instances within the variations design space — or design-variations space, to use its technical name — opens exciting prospects for fine tuning the typographic palette, and for new kinds of responsive typography that can adapt to best present dynamic content to a reader’s device, screen orientation, or even reading distance.
The technology behind variable fonts is officially called OpenType Font Variations. It has been jointly developed by Microsoft, Google, Apple, and Adobe, in an unprecedented collaborative effort also involving technical experts from font foundries and font tool developers. In addition to specifying the font format additions and revisions, the working group has also committed to the goal of interoperable implementation, defining expected behaviours and test suites for software displaying variable fonts. This should be welcome news to font developers and users, who have often struggled with incompatible implementations of earlier aspects of OpenType that were left to the interpretation of individual software companies.
OpenType Font Variations builds on the model established in Apple’s TrueType GX variations in the mid-1990s, but has fully integrated that model into all aspects of the OpenType format, including OpenType Layout, and is available to both TrueType and Compact Font Format (CFF) flavours of OpenType. This has meant not only the addition of numerous tables to the format, but also revision of many existing tables; these changes are summarised in an appendix to this article, which is intended as an introduction and technological summary, primarily for font makers and font tool developers. The full technical specification for OpenType Font Variations is incorporated into the OpenType specification version 1.8.
The basics
An OpenType variable font contains one or more axes that each provide particular variation between different extremes of a typeface design. The format also allows for the possibility of intermediate designs, for the whole glyph set or for individual glyphs, to provide finer control over the design as it changes across the variations design space. In addition, there are mechanisms that allow for radical glyph shape changes to be substituted for discrete areas of the resulting design space. Most font makers will already be familiar with interpolation between design masters as part of their workflows for creating complex font families with ranges of weights, widths or optical sizes. One of the goals of the working group creating the Font Variations technology was to ensure that such workflows and existing design sources could be easily adapted to producing the new variable fonts.
However, unlike master-based interpolation technologies such as Adobe’s earlier multiple master format, an OpenType variable font contains only a single set of glyph outlines, and the other extremes or intermediate shapes are defined as deltas from those outlines. So, for example, a font may contain a set of glyph outlines that correspond to the regular weight and width of a typeface, and the lighter, heavier, narrower, and extended designs will be expressed in the font data as movements of outline nodes relative to that outline. This allows for a compact expression of the design space, and also means that some corner extremes may also be interpolated, rather than requiring a master at every extreme (the font maker can decide, of course, to use a corner master rather than relying on interpolation).
Within the design space created by the axes of variation in a font, the font maker can define specific positions as named instances. A named instance appears to users as if it were a separate font, e.g. a Light or Bold weight of a typeface, and can be utilised in documents exactly as if it were an individual non-variable font. Because these named instances are defined as coordinate positions within the design space, and not as masters, there is a great deal of freedom for the font maker in deciding how to arrange and name instances, and in fine-tuning the interpolation of the named instances. Any position within the design space can be a named instance (although there are some recommendations involving transitions to intermediate masters or shape substitution ranges), and the single set of outlines stored in the font may or may not correspond to one of the named instances, depending on backwards compatibility commitments or lack thereof.
The architectural distinction between a font development source based on master designs and a variable font containing only a single set of outlines has important implications that font makers and font tool developers should understand. It means that a variable font may cover all or any portion of the design space defined by the source masters. This is potentially very useful, especially for making custom ‘slices’ of that design space for specific clients and customers, e.g. yet more compact fonts that contain only the axes the client needs (only a weight axis, for example, omitting other axes such as width or optical size), or versions of a font with customised named instances. Hence, font tool developers should beware of making assumptions about relationships between source masters and the packaging of variations in a variable font, and should provide maximum flexibility to font makers.
Compatibility
Because OpenType Font Variations is a new technology, it requires substantial updates to font handling infrastructure in operating systems and/or applications, and has very limited backwards compatibility; this also differs between the TrueType and CFF flavours.
In TrueType variable fonts, a minimal level of backwards compatibility is provided in that the set of default outlines — the default instance — in a variable font’s ‘glyf’ table will display as if it were a simple individual font. In order to ensure compatibility between this default instance displayed on older software and a corresponding instance in the variations design space, the outline set should be an appropriate named instance. [This fall-back behaviour will need to be carefully communicated to users, who might otherwise wonder why they are seeing multiple named instances in newer environment but only a single font in older ones. It is anticipated that some font customers will, for some time, need both variable and non-variable versions of fonts, for deployment in newer and older environments.]
Adobe, which remains responsible for the CFF specification, decided that maintaining such compatibility would overly restrict CFF font architecture while not providing significant benefit to customers. Instead, Adobe has defined a wholly new version, CFF 2, and a corresponding ‘CFF2’ font table. Hence, there is no backwards compatibility for a CFF 2 font with older software. Unlike the original CFF, the new version cannot be used as a stand-alone font program, but is intended only for use within an OpenType font. As such, it no longer contains data that can be stored elsewhere in OpenType tables (for instance, glyph names, which are now stored in or omitted from the ‘post’ table depending on table format selection by the font maker), and excludes any data that is not required in the context of an OpenType font. This, along with optimisations in the new CFF 2 Charstrings, contribute to further reductions in file size. [Note that while CFF 2 has been designed to enable variable fonts, it is also possible to make a non-variable font with a ‘CFF2’ table, but the same absence of backwards compatibility will apply. It is also theoretically possible to make a single font that contains both a ‘CFF2’ and older ‘CFF ’ table.]
The core technology
At the core of OpenType Font Variations are tables that define the design space and how it is presented to users. Some of these tables have been directly adapted from Apple’s TrueType GX architecture, but have been revised and enhanced. One outcome of this approach is that some aspects of Apple’s GX showcase font Skia, designed by Matthew Carter, work with only slight modification on platforms that support OpenType variable fonts.
The Font Variations ‘fvar’ table describes the axes of variation used in the font: how many axes there are, what parameters apply to the variations, and how these are presented to application software. The ‘fvar’ table also stores named instance information. So, for example, an ‘fvar’ table might define a weight axis between the lightest weight of a design and its heaviest weight (with the default outline set stored in the font being somewhere between the two), and may also define a number of named instances along that axis, e.g. Ultra Light, Light, Semi Light, Regular, Semi Bold, etc.. Note that these named instances may be defined anywhere along this axis, and do not need to correspond to axis extremes or to the default outline set. In a multi-axis font, the axes intersect at the default outline set, and the named instances may be defined at any position within the resulting multi-dimensional design space. There is no practical limit on the number of axes of variation that a variable font may include (the architectural limit, as with so much in the OpenType format, is 64k); there is, of course, a sanity limit for type designers, since each additional axis multiplies the complexity of the design space. Overly-complex variable fonts can also be confusing to end users, who may struggle to understand how to make effective use of the possibilities.
Five more-or-less common axes of variation have registered axis tags in the OpenType Font Variations specification — Weight <wght>, Width <wdth>, Optical size <opsz>, Italic <ital>, and Slant <slnt> — and these have some assumed behaviours. Font makers can also define custom axes with their own four-character tags and localisable names stored as strings in the ‘name’ table. Additional common axis tags may be registered in future, if these emerge as font makers engage with the technology.
Each additional axis in a font will increase the complexity of the design space. This diagram illustrates the design space of a three-axis variable font with weight, width, and optical size axes. The red a glyph in the middle of the design space represents the set of outlines stored in the font, and each green glyph represents the deltas at the extremes of the three axes, which are indicated by the solid red lines. Note that the design space is normalised, such that the distance between the outline set and extremes of the axes are all the same, even if the outlines do not represent a halfway point between the design extremes. The orange glyphs represent the corner positions derived from the axes. The instances at these positions may be interpolated from the deltas of the extremes, or may be stored as additional sets of deltas, i.e. be derived from separate masters in the design source.
[Typeface: Kepler, an Adobe Original designed by Robert Slimbach.]
In the same way that the corners of the design space may be either interpolated or controlled by a set of stored deltas, any position within the design space may be controlled in this way. Any point along an axis may be derived from an intermediate design master, to better control the interpolation between the extremes, and any position within the multi-dimensional space around the axes may also be derived from such a master and stored as an intermediate delta set. This provides a great deal of flexibility to the font maker in deciding what regions of the space to control with a fixed design and which to allow to be interpolated.
It isn’t necessary for an axis to affect all the glyphs in a font, nor for an axis to express a wide range of variation. So a multi-axis font does not always imply a massively complex design space. The font maker can set the behaviour of transitions along an axis to be gradual or sudden, effectively enabling an axis to work as a toggle between variations, or a series of discrete changes without intermediary variations. It is also possible to create an axis that affects only a single glyph, e.g. an axis that adjusts the length of the tail of an uppercase Q, or that affects only a subset of glyphs with particular features, e.g. an axis that shortens or lengthens ascenders.
In TrueType flavour fonts, the default instance outline set is stored in the standard Glyph ‘glyf’ table, just as in a non-variable TTF (this is what enables minimal backwards compatibility for this flavour). The variation data that describe how the TrueType outlines change across the design space are stored in the Glyph Variations ‘gvar’ table.
In CFF flavour fonts, both the default instance outline set and the glyph variations data are stored in the new ‘CFF2’ table. The variations model is the same in both flavours, but the data is stored in different ways.
Additional variations-specific tables — some required in a variable font, some optional — provide control of variation in font and glyph metrics, and also enable the font maker to modify how a design varies along a particular axis, e.g. to apply optical size interpolation more rapidly across smaller type sizes and more slowly at larger sizes. For a summary of all the new and revised tables related to font variations, see the appendix to this article.
OpenType Layout for variable fonts
For many font makers and users, the glyph substitution and positioning capabilities of OpenType Layout are the most distinctive and important aspect of the OpenType format. Integration of variable font technology in the OpenType Layout tables allows font makers to provide interaction between variation design space and glyph substitution and positioning features.
It will be immediately obvious to font makers that, if glyph shapes are changing across variations design space, then their spacing is also changing, and all data in the Glyph Positioning ‘GPOS’ table will need to undergo corresponding adjustment. This means that kerning pair-adjustments, mark anchor attachments, cursive connection attachments, and other GPOS lookup types all need to interact with variations. This is done by referencing the new item variation store in the Glyph Definition ‘GDEF’ table, which stores design grid X and Y deltas for coordinates in a similar way to how glyph outline deltas are stored elsewhere in the font. The variable font stores default GPOS lookup coordinates for the default instance outline set, and Item Variation Store deltas to adjusted coordinates for the axis extremes and any other delta sets in the design space. Within the ‘GPOS’ table itself, indices to the GDEF item variation store are specified in a variant of the existing (but little-used) GPOS device table format, which enables ppem size-specific adjustments to positioning lookups in non-variable fonts. From a font tool perspective, much of this should be invisible to the font maker, who will remain responsible for defining appropriate GPOS lookups for the design masters.
While adjustments to glyph positioning are likely to be required in any variable font — except perhaps some monospaced fonts — , glyph substitution interaction with variations is more likely to be at the discretion of the font maker and reflect the nature of the particular typeface design. The new FeatureVariations table in the Glyph Substitution ‘GSUB’ table can be used to associate alternate GSUB lookups with regions in the variations design space. For instance, a variable font may employ different ligature substitutions at different ranges along a width axis, or disable graphically complex swash variant form substitutions for the heavier instances on a weight axis. Another interesting case is stroke reduction in East Asian (CJK) fonts, in which substituting size-specific variations on an optical size axis provides an OpenType flavour-independent means to improve legibility without relying on TrueType hinting methods that have been used in some previous fonts.
In addition to the FeatureVariations table, which can provide variations-dependent behaviour for any GSUB feature, a new OpenType Layout feature has been defined for use in variable fonts: Required Variation Alternates <rvrn>. This feature provides a relatively simple mechanism within OpenType Layout to achieve similar functionality to inserting a delta set for a particular glyph or collection of glyphs into the variations design space. The feature is designed to set up initial glyph forms — based on the variations instance or region selected — for subsequent processing, so is expected to be processed by shaping engines at the very beginning of OpenType Layout, before even the Localized Forms <locl> feature. The <rvrn> feature has some restrictions applied to it that other features do not: a) it is required to be used in combination with a FeatureVariations table (see preceding paragraph), and b) should only contain one-to-one (GSUB Lookup Type 1) substitutions (any other lookup type in the feature will be ignored).
Font makers should realise that there may sometimes be more than one way to achieve a particular outcome when making a variable font. The best option — whether, for instance, to insert an intermediate delta set into a region of the design space or to use the <rvrn> feature to access variant glyphs for that region using a GSUB FeatureVariations table — may depend on the nature of the design and how sources have been made, on font production tools and their capabilities, or simply on the font maker’s preference or comfort with different aspects of OpenType Font Variations.
Hinting for variable fonts
Despite increases in screen resolution and advances in various kinds of anti-aliased rendering, font-level optimisation of outline rasterisation — ‘hinting’ — remains important for some environments and for many users.
The relatively simple CFF hinting model remains as it has, largely unchanged, since PostScript Type 1 fonts. Font makers are responsible for defining vertical alignment ‘blue’ zones, and horizontal and vertical stem hints and standard values. Typically, these will be defined in the source for each design master, but written as deltas in the variable font by production tools. In variable fonts, glyph and font level hinting data are stored in the ‘CFF2’ table along with the default outlines, with deltas and interpolation working as with glyph shapes. A further enhancement of the hinting data included in CFF 2 enables different alignment zones and standard stem values to be applied to glyph subsets. So, for instance, a multiscript font may have different values for the various writing systems covered.
TrueType has a more explicit hinting model, based around the TrueType instruction set, which provides greater control to the font maker in affecting display of fonts in various environments. In recent years, increases in screen resolutions and changes in anti-aliasing rendering styles has enabled a ‘light’ form of TrueType hinting, focused on control of vertical alignment zones and horizontal stem distance, density, and positioning. For many font makers, this represents a shift to something more like the PostScript hinting model, but still with access to more explicit instructions, e.g. to adjust vertical positions at discrete pixels-per-em (ppem) sizes, and to the higher-level programming functions of the TrueType hinting model.
TrueType variable fonts deliver a significant development benefit: the functional equivalent of many fonts, but only one set of outlines to be hinted. Alignment zones and standard stem values or other distances related to the default instance outlines are stored, as with non-variable fonts, in the Control Value ‘cvt ’ table, while deltas to these values are stored in the new CVT Variations ‘cvar’ table. As with other aspects of variations, the ‘cvar’ data interacts with the Font Variations data in the ‘fvar’ table. This model enables a set of stem hints linked to CVT values on glyphs in the outline set be adjusted to deltas and to interpolated instances.
In some cases, font makers may wish to apply specific hinting behaviour to an instance or region in the design space beyond what is possible with deltas and interpolation of CVT values. For example, in a graphically complex glyph, legibility might be improved by moving some element up or down at a particular ppem size in a certain region along one or more of the variation axes; or, a font maker might decide that heavier weights would benefit by a specific CVT stem value rendering slightly heavier at some ppem sizes to better distinguish from medium weight instances. To support this, a new GETVARIATION instruction has been added to the TrueType hinting instruction set. This instruction reports the coordinates in the variations design space for the current instance, allowing conditional hinting to be applied.
Data in the new Metrics Variations ‘MVAR’ table can be used to adjust the ppem sizes at which settings in the Grid-fitting and Scan-conversion Procedure ‘gasp’ table are applied across design-variation space, e.g. changing the size at which y-direction anti-aliasing turns on for variations along a weight axis.
The font family reconsidered
The OpenType ‘name’ table is a confused and confusing collection of font, family, weight, and other style identifiers. In the twenty years since OpenType was first invented, it has only grown more confusing, with the addition of new name IDs for specific platforms and style-mapping models. The concatenation of style names in fonts follow no fixed pattern among font makers, and may reach to ludicrous lengths. What one font maker calls ‘Acme UltraBlack Condensed Display Roman’ another may call ‘Acme Roman Super Black Display Condensed’.
The development of OpenType Font Variations — in which named instances on custom design axes could easily introduce new kinds of name constructions — provides an opportunity to radically change the approach to font style identification. The Style Attribute ‘STAT’ table identifies font styles not by name IDs, but by a set of attribute values. The ‘STAT’ table is required for variable fonts, but is also recommended for all new non-variable fonts. Font tools should be able to generate much ‘name’ table data automatically from style attributes in the new table, insulating font makers from decisions about ‘name’ table IDs and improving consistency in those IDs.
The ‘STAT’ table treats the axes of variable fonts and kinds of style variation across a family of fonts in the same way, requiring an axis record for each. So, for instance, both the weight axis in a variable font and the weight variant fonts in a non-variable family will be recorded as having a weight axis. Relevant axis records will also be shared across members of a family, e.g. roman and italic, whether built as variable fonts or not. Font makers may exercise some control over style ordering in application font menus or dynamic name concatenation — depending on software implementations — in the ordering of axis records in the ‘STAT’ table.
Details of specific style variants — whether variable font instances or separate non-variable fonts — are stored in axis value tables, the formats of which are tailored to different data types. The handling of style definitions as collections of discrete attributes enables software to identify the relationships of instances or family members along specific design axes; for instance, optical size relationships independent of the weight, width, or other axes. This means software can refer to the attributes that pertain to particular functions, such as finding a matching optical size design in a different weight or in an italic companion font.
The ‘STAT’ table includes a provision for adding new styles to a family at a later date, without needing to update the axis records in the earlier fonts. This is the charmingly named OlderSiblingFontAttribute flag, which provides information regarding the ‘normal’ state of a new axis, which is presumed to be the state of the earlier font vis-a-vis that axis. For example, if new condensed and/or expanded fonts introduce a width axis to a family that previously only had a weight axis, this flag can be used to indicate that the older fonts are the normal width state of the design.
Conclusion. Why now?
The idea of fonts containing interpolable design space and named or dynamic instances is not new. OpenType variable fonts build directly on the technology introduced to TrueType by Apple in the QuickDraw GX graphics environment. Of similar vintage, Adobe’s multiple master format approached similar concepts in a different way. Both those earlier technologies failed to take-off in the 1990s, for a variety of reasons, and font makers — who have a long collective memory for such things — might sceptically ask what is different this time?
Like so much else driving change in the font business, a big part of the answer is webfonts, and the need for more compact and faster ways to deliver dynamic fonts for the Web. Variable fonts also have the potential to enable new kinds of typography for electronic documents, responsive to things like device orientation or even viewing distance. Compact and faster fonts also provide significant advantages for embedding fonts in devices, especially for East Asian (CJK) and other fonts with very large glyph sets and character coverage. The smaller device and disc footprint of variable fonts has been a major factor in encouraging support for the technology in software companies.
The way in which the new technology has been developed is also very different from the situation in the 1990s. OpenType Font Variations has been designed collaboratively, with input from the makers of the four major platforms for digital text and typography. While earlier font interpolation technologies emerged from the font format wars of the early 1990s, and were developed and championed by individual, competing software companies, OpenType variable fonts are the product of a new collegiality aimed not only at defining a common standard but also interoperable implementations.
The four major software companies that have contributed to the technology all have restrictions on public statements about unreleased products, limiting what may be said in this article regarding their commitments and the status of work on variable font infrastructure. That said, a summary of the state of play at the time of writing is possible:
The Windows engineering team at Microsoft is working on implementing support for OpenType Font Variations for release in 2017, and the TrueType rasteriser in the recent Windows 10 Anniversary edition has already been updated to support variable fonts. Applications such as the Edge and Chrome browsers that use DirectWrite are already able to select some named instances in fonts with weight and width axes. More complete support will be available in Windows Insider preview builds in coming months. Work is also being done to add variable font hinting and previewing to the VTT tool. Members of the Edge team are working with industry partners on a formal proposal for support of variable fonts in Cascading Style Sheets (CSS) for the Web.
Google has been working on variable fonts technology for two years, including independent implementations of Apple’s TrueType GX. Their open source font production pipeline already supports building OpenType variable fonts, and they are actively engaged in bringing the technology to the Noto fonts project, Google Chrome, the Google Fonts webfont platform, and other products.
Apple, characteristically, are least forthcoming about future plans, but they have a head start on variable font support in their TrueType GX infrastructure, and have played an active role in bringing the technology to OpenType.
Adobe, in addition to developing the CFF 2 specification, are updating the CFF rasteriser that they contributed to the open source FreeType project in 2013. They also expect to release an updated version of their AFDKO tools for building variable fonts with OpenType Layout tables by the end of September 2016, along with a sample font. No details about support for variable fonts in Adobe’s application suite can be released at this time.
Font tool makers have been actively engaged with the working group, and have had an opportunity to review the draft specification in advance of publication. It will be important for tools to provide font makers with intuitive ways to navigate the potentially complex design space of variable fonts with multiple axes, intermediate delta sets, and axis variation. As discussed previously, maintaining flexibility in the relationship of design masters and the arrangement of variations in a font will enable font makers to tailor fonts to the needs of customer.
OpenType variable fonts present great opportunity and challenge for font makers. Type designers are bound to find innovative ways to use the technology, as they have other aspects of OpenType and of earlier variations technology such as TrueType GX and multiple master. This time, we may be cautiously optimistic that the technology will live up to its promise, as a widely supported and interoperable standard that provides benefit to users and opens the door to new forms of typographic expression.
John Hudson, 14 September 2016
Links
This introductory article cannot provide insight into all aspects of the OpenType variable fonts technology. For more detail, refer to the specification and additional articles as they become available. These links will be updated periodically.
The OpenType Font Format specification version 1.8
OpenType Font Variations Overview
Change log for version 1.8 of the OpenType specification
A delta version of the OpenType specification highlighting changes
OpenType variable fonts discussion on TypeDrawers
Members of the OpenType Font Variations working group are partnering with the TypeDrawers online typography forum to provide a centralised platform for discussion of the technology. Threads in the TypeDrawers Font Technology forum with the subject line tag [OTVar] will be monitored by members of the working group ready to answer questions about the technology. If you are new to TypeDrawers, please familiarise yourself with their real-name and other policies.
Announcements from the working group industry partners
Adobe • Google • Microsoft
Axis-Praxis variable font playground
Acknowledgements
I am indebted to Bianca Berning (Dalton Maag), Tim Brown (Adobe), Peter Constable and Rob McKaughan (Microsoft), and Thomas Phinney (FontLab) for reviewing drafts of this article and providing excellent feedback, and to my fellow members of the OpenType Font Variations working group for answering my many questions. I think they will all agree that, among the many people who contributed to the project, Peter Constable deserves to be singled out for his shepherding of the process and for his marathon labours on so much of the specification.
Thanks to Marchel Verschuren for his assistance in preparing the illustration of the multi-axis design space.
Trademarks
OpenType is a registered trademark of Microsoft Corporation.
PostScript is a registered trademark of Adobe Systems Incorporated.
TrueType is a registered trademark of Apple Inc.
Appendix: table summary
This appendix covers only those tables, new or revised in version 1.8 of the OpenType Font Format specification, that relate directly to the Font Variations technology. It does not include non-variations additions or revisions to the spec, such as the ‘SVG ’ table or other colour font technologies, nor the new ‘meta’ and ‘MERG’ tables. For an overview of all updates to the OpenType specification, see the change log.
New variable font tables in OpenType 1.8
avar
Axis Variations table (optional)
Used to modify aspects of how a design varies for different instances along a particular design-variation axis.
CFF2
Compact Font Format Version 2 table (required for CFF variable fonts)
Extensive table containing all CFF 2 outline data, delta sets and other glyph variations data.
cvar
CVT Variations table (TrueType only)
Hinting table providing variations to control value alignment zones and distances for variations delta sets.
fvar
Font Variations table (required for variable fonts)
Provides global definition of variations in a font, including the axes of variation and range of each, and named instance coordinates.
gvar
Glyph Variations table (required for TrueType variable fonts)
Stores all the variation data that describes how outlines in the ‘glyf’ table are change across the variation design space. [Note that for CFF variable fonts, the equivalent data is stored in the ‘CFF2’ table.]
HVAR
Horizontal Metrics Variation table (optional but recommended for TrueType variable fonts; required for CFF variable fonts with any variation in horizontal glyph metrics)
Stores variation data for horizontal advance widths in the ‘hmtx’ table. [Note that the data is used in different ways in TrueType and CFF flavour fonts.]
MVAR
Metrics Variations table (optional, but very likely to be needed)
Provides variations data for font-level metrics in the ‘OS/2’, ‘hhea’, ‘vhea’, and ‘post’ tables, plus ‘gasp’ table settings for TrueType rendering.
STAT
Style Attributes table (required for variable fonts; recommended for all new non-variable fonts)
Defines distinguishing attributes of a font style variant, allowing software to understand relationships between instances in a variable font or between fonts in a non-variable family.
VVAR
Vertical Metrics Variation table (optional but recommended for TrueType variable fonts; required for CFF variable fonts with any variation in vertical glyph metrics)
Stores variation data for vertical glyph metrics values in the ‘vmtx’ table. [Note that the data is used in different ways in TrueType and CFF flavour fonts.]
Tables updated with variable font functionality in OpenType 1.8
BASE
Baseline table (optional)
Added section on baseline table variation adjustments for variable fonts, and a new item variation store table. [This aspect of Font Variations technology is not covered in this introductory article; in brief, such adjustments are stored directly in the BASE table using the new item variation store.]
gasp
Grid-fitting and Scan-conversion Procedure table (recommended for TrueType fonts)
Added note regarding corresponding ‘MVAR’ table variations data for some ‘gasp’ settings.
GDEF
Glyph Definition table (optional; required if font contains ‘GPOS’ or ‘JSTF’ variations data)
Added section on Font Variations integration, and a new item variation store table to contain data referenced in e.g. GPOS lookups with variation adjustments.
GPOS
Glyph Positioning table (optional)
Added section on Font Variations integration, including distinction between variable and non-variable font use of device table adjustment fields.
GSUB
Glyph Substitution table (optional)
Added section on Font Variations integration, and new FeatureVariations table.
head
Font Header table (required)
Minor update to note dependencies and restrictions for variable fonts.
hhea
Horizontal Header table (required)
Added note regarding corresponding ‘MVAR’ table variations data for some ‘hhea’ metrics.
JSTF
Justification table (optional)
Added section on Font Variations integration. [This aspect of Font Variations technology is not covered in this introductory article. Twenty years on, we’re still awaiting any implementation of JSTF support for iterative text justification.]
name
Naming table (required)
Added name ID 25 ‘Variations PostScript Name Prefix’. If present, this name can be used as the family prefix in automatic generation of PostScript font names for generated instances in the design space. [This introductory article does not deal with Adobe’s new PostScript Name Generation for Variation Fonts algorithm. See Adobe Technical Note #5902 for details.]
OS/2
OS/2 and Windows Metrics table (required)
Updated to note variable font dependencies, and note added regarding corresponding ‘MVAR’ table variations data for some ‘OS/2’ metrics.
post
PostScript table (required)
Updated to note dependencies and restrictions for variable fonts.
