OpenType Font

The font wars and the birth of OpenType

By 1995, the font landscape was a mess. Adobe controlled PostScript Type 1, the professional standard, and charged licensing fees that Apple and Microsoft resented. Apple had retaliated in 1989 by creating TrueType, then licensed it to Microsoft. Windows 3.1 shipped with TrueType in 1992, bringing scalable fonts to the mass market. But now two incompatible font technologies divided the industry: Type 1 for print professionals and TrueType for everyone else.

Microsoft's answer was OpenType, announced in 1996. The concept was straightforward — put both outline technologies (Adobe's cubic Bezier curves and Apple's quadratic splines) into a single container format, the same sfnt structure that TrueType already used. Adobe joined as co-developer in 1997, bringing CFF (Compact Font Format) as the PostScript outline representation. The .otf extension identifies fonts using CFF outlines, while .ttf identifies those using TrueType outlines. Both are OpenType; the difference is purely in how glyph shapes are mathematically described.

The turning point came in 2000 when Adobe converted its entire Type Library — thousands of professional fonts — from Type 1 to OpenType. Overnight, OTF became the format of professional typography. ISO standardization followed in 2005 as ISO/IEC 14496-22, part of the MPEG-4 family.

Inside the SFNT container

An OTF file is a collection of binary tables packed into the SFNT (Scalable Font) container. The file begins with a 12-byte header: the 4-byte OTTO magic, a 2-byte table count, and three 2-byte binary search optimization values (searchRange, entrySelector, rangeShift). Following the header is the table directory — an array of 16-byte records, one per table, each containing a 4-character ASCII tag, a 32-bit checksum, a 32-bit offset from the file start, and a 32-bit length.

The required tables form the skeleton of every OTF file. The cmap table maps Unicode code points to glyph indices — without it, the font cannot associate characters with their visual forms. The head table stores fundamental metrics: unitsPerEm (typically 1000 for CFF fonts, 2048 for TrueType), creation and modification dates, and the font's bounding box. The hhea and hmtx tables define horizontal layout: ascent, descent, line gap, and per-glyph advance widths. The name table holds human-readable strings — font family name, designer, copyright, license URL — encoded for multiple platforms and languages. The OS/2 table provides Windows-specific metrics: weight class, width class, Panose classification, Unicode range coverage bits, and vertical metrics. The post table maps glyph indices to PostScript glyph names.

For CFF-based OTF files, the CFF table (or CFF2 in variable fonts) contains the actual glyph outlines as cubic Bezier curves encoded in a compact charstring format. CFF uses subroutine sharing to compress repeated outline segments — a significant space savings for fonts with large glyph counts.

Cubic Bezier vs quadratic splines

The fundamental technical difference between OTF and TTF is the mathematics of their curves. CFF outlines in OTF files use cubic Bezier curves (third-degree polynomials), defined by four control points: a start point, two off-curve control handles, and an end point. TrueType outlines use quadratic B-splines (second-degree polynomials), with only one off-curve control point between two on-curve points.

Cubic curves can represent a wider range of shapes with fewer control points. A typical letter 'S' might require 12 control points in CFF but 20 or more in TrueType to achieve the same fidelity. This means CFF-based OTF files are often slightly smaller than their TrueType equivalents. The trade-off is that quadratic splines are computationally cheaper to rasterize — a consideration that mattered in the 1990s but is irrelevant on modern hardware.

Conversion between the two formats is mathematically possible but not lossless in the cubic-to-quadratic direction. A cubic curve can only be approximated by a series of quadratic segments. Converting OTF to TTF introduces infinitesimal rounding errors that may be visible at extreme magnifications but are invisible in normal typographic use.

OpenType Layout: GSUB and GPOS

OpenType's most powerful capability is its layout engine, expressed through two tables: GSUB (Glyph Substitution) and GPOS (Glyph Positioning). These tables encode rules that the text shaping engine applies to transform a sequence of Unicode characters into a sequence of positioned glyphs.

GSUB handles replacements. Standard ligatures (liga) combine character sequences into single glyphs — 'f' + 'i' becomes the fi ligature. Small capitals (smcp) replace lowercase letters with proportionally designed small cap forms. Contextual alternates (calt) select different glyph variants based on surrounding characters — a feature that handwriting fonts use to vary letter shapes naturally. Stylistic sets (ss01 through ss20) group alternate designs that can be activated as a unit.

GPOS handles spatial adjustments. Kerning (kern) tightens or loosens spacing between specific letter pairs — 'AV', 'To', 'We' all need kerning for professional appearance. Mark positioning (mark) places combining diacritical marks precisely above or below base characters. Mark-to-mark (mkmk) stacks multiple diacritics — essential for Vietnamese and Arabic with vowel marks.

For Arabic script, these tables are not optional luxuries — they are essential for correct rendering. Arabic letters take four distinct forms (initial, medial, final, isolated) depending on their position in a word, selected by init, medi, fina, and isol GSUB features. The rlig feature handles required ligatures like lam-alef. The curs GPOS feature manages cursive attachment between connected glyphs. Without these features, Arabic text is illegible.

Variable fonts

OpenType 1.8, released in September 2016, introduced variable fonts — arguably the most significant advancement in font technology since OpenType itself. A variable font contains multiple design variations along named axes within a single file.

The fvar table defines the axes of variation: wght (weight: light to bold), wdth (width: condensed to extended), slnt (slant), opsz (optical size), and any number of custom axes. Each axis has a minimum, default, and maximum value. The gvar table (for TrueType outlines) or CFF2 blend operators (for PostScript outlines) store per-glyph variation deltas that the rasterizer interpolates based on the chosen axis values.

A traditional font family might distribute 18 separate files: 9 weights times 2 (upright + italic). A single variable font replaces all 18 — and offers every intermediate value in between. Google Fonts reports that variable fonts reduce total transfer size by 44% on average compared to serving four static weights. A single variable weight axis in a font like Inter saves approximately 200 KB versus downloading Regular and Bold as separate WOFF2 files.

Color fonts

OpenType supports four color font technologies. COLR/CPAL defines colored glyph layers with palettes — COLRv0 (basic layering) shipped in 2013, COLRv1 (2021) added gradients, compositing modes, and transformations. SVG embeds Scalable Vector Graphics per glyph, used by some emoji fonts. CBDT/CBLC stores pre-rasterized color bitmaps at multiple sizes — used by Android Noto Color Emoji. sbix is Apple's bitmap color format used by Apple Color Emoji.

COLRv1 is emerging as the preferred color font technology because it stays within the OpenType outline paradigm while supporting complex visual effects. Google Chrome and Firefox fully support COLRv1 as of 2022.

Web delivery: OTF to WOFF2

While browsers can render OTF files served via @font-face, raw OTF is inefficient for web delivery. WOFF (Web Open Font Format, 2010) wraps OTF/TTF with zlib compression and metadata. WOFF2 (W3C Recommendation, 2018) replaces zlib with Brotli compression, achieving 20-30% better compression than WOFF1. A 200 KB OTF file typically compresses to 140-160 KB as WOFF2.

The CSS @font-face rule with format('woff2') is the standard approach. Google Fonts exclusively serves WOFF2 in 2026, with a CSS API that returns @font-face declarations optimized for each browser. The unicode-range descriptor enables subsetting — downloading only the character ranges actually used on the page, which is particularly valuable for CJK fonts that can exceed 10 MB uncompressed.

Font security

Fonts are parsed by OS-level text rendering engines that run with elevated privileges, making them a recurring target for exploits. Windows Adobe Type Manager (atmfd.dll) has been the subject of multiple critical CVEs, including CVE-2020-1020 (remote code execution via malformed CFF data) and CVE-2015-2426 (buffer overflow). The TrueType hinting engine's bytecode interpreter was exploited by the Duqu malware in 2011 (CVE-2011-3402), one of the most sophisticated state-level attacks ever documented.

Modern operating systems have hardened their font parsers significantly. Windows 10+ processes untrusted fonts in an AppContainer sandbox. Chrome and Firefox parse web fonts in sandboxed renderer processes. But the attack surface remains — HarfBuzz, FreeType, and CoreText each process billions of font files daily, and any parsing bug in these engines has wide-reaching consequences.