Hubbry Logo
OpenTypeOpenTypeMain
Open search
OpenType
Community hub
OpenType
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
OpenType
OpenType
OpenType
View on Wikipedia
from Wikipedia
OpenType
Filename extensions.otf, .otc, .ttf, .ttc
Internet media type
  • font/otf
  • font/sfnt
  • application/font-sfnt (deprecated)
[1]
Type codeOTTO
Uniform Type Identifier (UTI)public.opentype-font
Developed byMicrosoft, Adobe Systems
Latest release
1.9[2]
8 December 2021; 3 years ago (2021-12-08)
Type of formatFont file
Extended fromTrueType, PostScript fonts
StandardISO/IEC 14496-22:2019[3]

OpenType is a format for scalable computer fonts. Derived from TrueType, it retains TrueType's basic structure but adds many intricate data structures for describing typographic behavior. OpenType is a registered trademark of Microsoft Corporation.[4][5]

The specification germinated at Microsoft, with Adobe Systems also contributing by the time of the public announcement in 1996.

Because of wide availability and typographic flexibility, including provisions for handling the diverse behaviors of all the world's writing systems, OpenType fonts are used commonly on major computer platforms.

History

[edit]

OpenType's origins date to Microsoft's attempt to license Apple's advanced typography technology GX Typography in the early 1990s. Those negotiations failed, motivating Microsoft to forge ahead with its own technology, dubbed "TrueType Open" in 1994.[6] Adobe joined Microsoft in those efforts in 1996, adding support for the glyph outline technology used in its Type 1 fonts.

The joint effort intended to supersede both Apple's TrueType and Adobe's PostScript Type 1 font format, and to create a more expressive system that handles fine typography and the complex behavior of many of the world's writing systems. The two companies combined the underlying technologies of both formats and added new extensions intended to address their limitations. The name OpenType was chosen for the joint technology, which they announced later that year.

Open Font Format

[edit]

Adobe and Microsoft continued to develop and refine OpenType over the next decade. Then, in late 2005, OpenType began migrating to an open standard under the International Organization for Standardization (ISO) within the MPEG group, which had previously (in 2003) adopted OpenType 1.4 by reference for MPEG-4.[5][7][8][9] Adoption of the new standard reached formal approval in March 2007 as ISO Standard ISO/IEC 14496-22 (MPEG-4 Part 22) called Open Font Format (OFF, not to be confused with Web Open Font Format),[10] sometimes referred to as "Open Font Format Specification" (OFFS).[5] The initial standard was technically equivalent to OpenType 1.4 specification, with appropriate language changes for ISO.[11] The second edition of the OFF was published in 2009 (ISO/IEC 14496-22:2009) and was declared "technically equivalent" to the "OpenType font format specification".[12][13] Since then, OFF and OpenType specifications have been maintained in sync. OFF is a free, publicly available standard.[14]

By 2001 hundreds of OpenType fonts were on the market. Adobe finished converting their entire font library to OpenType toward the end of 2002. As of early 2005, around 10,000 OpenType fonts had become available, with the Adobe library comprising about a third of the total. By 2006, every major font foundry and many minor ones were developing fonts in OpenType format.[citation needed]

Unicode Variation Sequences

[edit]

Unicode version 3.2 (published in 2002) introduced variation selectors as an encoding mechanism to represent particular glyph forms for characters.[15] Unicode did not, however, specify how text renderers should support these sequences. In late 2007, variation sequences for the Adobe-Japan1 collection were registered in the Unicode Ideographic Database,[16] leading to a real need for an OpenType solution. This resulted in development of the cmap subtable Format 14, which was introduced in OpenType version 1.5.[17]

Color fonts

[edit]
"Color font" redirects here; not to be confused with Text color.

Unicode version 6.0 introduced emoji encoded as characters into Unicode in October 2010.[18] Several companies quickly acted to add support for Unicode emoji in their products. Since Unicode emoji are handled as text, and since color is an essential aspect of the emoji experience, this led to a need to create mechanisms for displaying multicolor glyphs.

Apple, Google and Microsoft independently developed different color-font solutions for use in OS X, iOS, Android and Windows.

  • OpenType and OFF already had support for monochrome bitmap glyph, so Google proposed that OFF be extended to allow for color bitmaps. Apple adopted this approach but declined to participate in extending the ISO standard. As a result, Apple added the sbix table to their TrueType format in OS X 10.7,[19] while Google proposed addition of the CBDT and CBLC tables to OFF.
  • Microsoft adopted a different approach than color bitmaps. Noting existing practice on the Web of layering glyphs of different color on top of one another to create multi-colored elements such as icons, Microsoft proposed a new COLR table to map a glyph into a set of glyphs that are layered, and a CPAL table to define the colors.
  • Adobe and Mozilla proposed adding a new SVG table that can represent multi-color glyphs using Scalable Vector Graphics.

These proposals were all incorporated into the third edition of OFF (ISO/IEC 14496-22:2015).[20] Microsoft added CBDT, CBLC, COLR, CPAL, and SVG tables to OpenType version 1.7,[17] and the sbix table in OpenType version 1.8.[17] Microsoft implemented support for all of the different color formats in Windows 10 version 1607 ("Anniversary Update").[21]

OpenType 1.9 introduced a second version of the COLR table that adds additional graphics capabilities.[17] Google originally proposed the enhanced version and jointly developed it with Microsoft. The enhanced graphic capabilities include support for three types of gradients, affine transformations, compositing and blending modes, and custom re-usable components.[22] These enhancements give the COLR table all of the graphic capabilities of the SVG table except stroking. They also add compositing and blending modes, support for which is considered optional for the SVG table (as these are implemented in SVG as filter effects).[23] In addition, the enhancements to the COLR table are integrated with OpenType Font Variations, which is not possible with the SVG table. The enhanced COLR table is supported in the Chromium browser engine as of version 98.[24]

Collections

[edit]

Since at least version 1.4, the OpenType specification had supported "TrueType Collections", a feature of the format that allows multiple fonts to be stored in a single file. Such a format is useful for distributing an entire typeface (font family) in just one file.

By combining related fonts into a single file, font tables that are identical can be shared, thereby allowing for more efficient storage. Also, individual fonts have a glyph-count limit of 65,535 glyphs, and a Collection file provides a "gap mode" mechanism for overcoming this limit in a single font file. (Each font within the collection still has the 65,535 limit, however.) A TrueType Collection file would typically have a file extension of ".ttc".

However, the specification only described collection files being used in conjunction with glyphs that are represented as TrueType outlines or as bitmaps. The potential existed to provide the same storage and glyph-count benefits to fonts that use CFF-format glyphs (.otf extension). But the specification did not explicitly allow for that.

In 2014, Adobe announced the creation of OpenType Collections (OTCs), a Collection font file that combines fonts that use CFF-format glyphs.[25] This provided significant storage benefits for CJK fonts that Adobe and Google were jointly developing. For example, the Noto fonts CJK OTC is ~10 MB smaller than the sum of the four separate OTFs of which it is composed.[26] The use of a Collection also allowed for combining a very large number of glyphs into a single file, as would be needed for a pan-CJK font.[27]

Explicit support for Collections with CFF-format glyphs was incorporated into the OpenType specification in version 1.8.[17] To reflect this more-inclusive applicability, the term "OpenType Collection" was adopted, superseding "TrueType Collection".

Font Variations

[edit]
See also: Variable fonts

On September 14, 2016, Microsoft announced the release of OpenType version 1.8. This announcement was made together with Adobe, Apple, and Google at the ATypI conference in Warsaw.[28] OpenType version 1.8 introduced "OpenType Font Variations", which adds mechanisms that allow a single font to support many design variations.[29] Fonts that use these mechanisms are commonly referred to as "Variable fonts".

OpenType Font Variations re-introduces techniques that were previously developed by Apple in TrueType GX, and by Adobe in Multiple Master fonts. The common idea of these formats is that a single font includes data to describe multiple variations of a glyph outline (sometimes referred to as "masters"), and that at text-display time, the font rasterizer is able to interpolate or "blend" these variations to derive a continuous range of additional outline variations.[30]

The concept of fully parametric fonts had been explored in a more general way by Donald E. Knuth in the METAFONT system, introduced in 1978.[31] That system and its successors were never widely adopted by professional type designers or commercial software systems.[32] TrueType GX and Multiple Master formats, OpenType Font Variations' direct predecessors, were introduced in the 1990s, but were not widely adopted, either. Adobe later abandoned support for the Multiple Master format.[33] This has led to questions as to whether a re-introduction of similar technology could succeed. By 2016, however, the industry landscape had changed in several respects. In particular, emergence of Web fonts and of mobile devices had created interest in responsive design and in seeking ways to deliver more type variants in a size-efficient format. Also, whereas the 1990s was an era of aggressive competition in font technology, often referred to as "the font wars",[34][35][36] OpenType Font Variations was developed in a collaborative manner involving several major vendors.[37]

Font Variations is integrated into OpenType 1.8 in a comprehensive manner, allowing most previously-existing capabilities to be used in combination with variations. In particular, variations are supported for both TrueType or CFF glyph outlines, for TrueType hinting, and also for the OpenType Layout mechanisms. The only parts of OpenType for which variations are not supported but might potentially be useful are the 'SVG ' table for color glyphs, and the MATH table for layout of mathematical formulas. The 'SVG ' table uses embedded XML documents, and no enhancement for variation of graphic elements within the SVG documents has been proposed. However, enhancement to the COLR table in OpenType 1.9 has provided a vector format for color glyphs with support for variations.[38]

OpenType 1.8 made use of tables originally defined by Apple for TrueType GX (the avar, cvar, fvar and gvar tables). It also introduced several new tables, including a new table for version 2 of the CFF format (CFF2), and other new tables or additions to existing tables to integrate variations into other parts of the font format (the HVAR, MVAR, STAT and VVAR tables; additions to the BASE, GDEF and name tables).[17]

Description

[edit]
  • TrueType outlines use quadratic Bézier curves.
    TrueType outlines use quadratic Bézier curves.
  • CFF outlines use cubic Bézier curves.
    CFF outlines use cubic Bézier curves.

OpenType uses the general sfnt structure of a TrueType font, but it adds several smartfont options that enhance the font's typographic and language support capabilities.

The glyph outline data in an OpenType font may be in one of two formats: either TrueType format outlines in a 'glyf' table, or Compact Font Format (CFF) outlines in a 'CFF ' table. (The table name 'CFF ' is four characters long, ending in a space character.) CFF outline data is based on the PostScript language Type 2 font format. However, the OpenType specification (pre-1.8) does not support the use of PostScript outlines in a TrueType Collection font file. After version 1.8, both formats are supported in the renamed "OpenType Collection".

For many purposes, such as layout, it does not matter what the outline data format is, but for some purposes, such as rasterisation, it is significant. The OpenType standard does not specify the outline data format: rather, it accommodates any of several existing standards. Sometimes terms like "OpenType (PostScript flavor)" (= "Type 1 OpenType", "OpenType CFF") or "OpenType (TrueType flavor)" are used to indicate which outline format a particular OpenType font file contains.

OpenType has several distinctive characteristics:

  • Accommodates the Unicode character encoding (as well as others), so that it can support any writing script (or multiple scripts at once).
  • Accommodates up to 65,536 glyphs.
  • Advanced typographic "layout" features which prescribe positioning and replacement of rendered glyphs. Replacement features include ligatures; positioning features include kerning, mark placement, and baseline specification.
  • Cross-platform font files, which can be used without modification on Mac OS, Microsoft Windows and Unix/Linux systems.
  • If no additional glyphs or extensive typographic features are added, OpenType CFF fonts can be considerably smaller than their Type 1 counterparts.

OpenType support

[edit]

Basic Roman support

[edit]

Virtually all applications and modern operating systems have basic Roman support and work with OpenType fonts just as well as other, older formats. Benefits beyond basic Roman support include extended language support through Unicode, support for complex writing scripts such as Arabic and the Indic languages, and advanced typographic support for Latin script languages such as English.

Windows 3.1 and all subsequent versions of Windows support OpenType TT fonts (.ttf). Windows 2000 and later support OpenType PS fonts (.otf). Adobe Type Manager could add basic Roman support of OpenType PS fonts in Windows 95, 98, or Me.

Extended language support

[edit]

Extended language support via Unicode for both OpenType and TrueType is present in most applications for Microsoft Windows [citation needed] (including Microsoft Office Publisher, most Adobe applications, and Microsoft Office 2003, though not Word 2002), CorelDRAW X3 and newer, and many Mac OS X applications, including Apple's own such as TextEdit, Pages and Keynote. It is also widely supported in free operating systems, such as Linux (e.g. in multiplatform applications like AbiWord, Gnumeric, Calligra Suite, Scribus, OpenOffice.org 3.2 and later versions,[39] etc.).

OpenType support for complex written scripts has so far mainly appeared in Microsoft applications in Microsoft Office, such as Microsoft Word and Microsoft Publisher. Adobe InDesign provides extensive OpenType capability in Japanese but does not directly support Middle Eastern or Indic scripts—though a separate version of InDesign is available that supports Middle Eastern scripts such as Arabic and Hebrew. Undocumented functionality in many Adobe Creative Suite 4 applications, including InDesign, Photoshop and Illustrator, enables Middle Eastern, Indic and other languages, but is not officially supported by Adobe, and requires third-party plug-ins to provide a user interface for the features.

Advanced typography

[edit]

Advanced typographic support for Latin script languages first appeared in Adobe applications such as Adobe InDesign, Adobe Photoshop and Adobe Illustrator. QuarkXPress 6.5 and below were not Unicode compliant. Hence, text in these versions of QuarkXPress that contains anything other than WinANSI or MacRoman characters will not display correctly in an OpenType font (nor in other Unicode font formats, for that matter). However, in QuarkXPress 7, Quark offered support similar to Adobe's. Corel's CorelDRAW introduced support for OpenType typographic features in version X6. Mellel, a Mac OS X-only word processor from Redlers, claims parity in typographic features with InDesign, but also extends the support to right-to-left scripts; so does the Classical Text Editor, a specialized word processor developed at the Austrian Academy of Sciences.

As of 2009, popular word processors for Microsoft Windows did not support advanced OpenType typography features. Advanced typography features are implemented only in high-end desktop publishing software. The text engine from Windows Presentation Foundation, which is a managed code implementation of OpenType, is the first Microsoft Windows API to expose OpenType features to software developers, supporting both OpenType TrueType, and OpenType CFF (Compact Font Format) fonts. It supports advanced typographic features such as ligatures, old-style numerals, swash variants, fractions, superscript and subscript, small capitalization, glyph substitution, multiple baselines, contextual and stylistic alternate character forms, kerning, line-level justification, ruby characters etc.[40] WPF applications automatically gain support for advanced typography features. OpenType ligatures are accessible in Microsoft Office Word 2010.[41]

Windows 7 introduced DirectWrite, a hardware accelerated native DirectX API for text rendering with support for multi-format text, resolution-independent outline fonts, ClearType, advanced OpenType typography features, full Unicode text, layout and language support and low-level glyph rendering APIs.[42]

On Mac OS X, AAT-supporting applications running on Mac OS X 10.4 and later, including TextEdit and Keynote, get considerable OpenType support. Apple's support for OpenType in Mac OS X 10.4 included most advanced typographic features necessary for Latin script languages, such as small caps, old-style figures, and various sorts of ligatures, but it did not yet support contextual alternates, positional forms, nor glyph reordering as handled by Microsoft's Uniscribe library on Windows. Thus, Mac OS X 10.4 did not offer support for Arabic or Indic scripts via OpenType (though such scripts are fully supported by existing AAT fonts). Mac OS X 10.5 has improved support for OpenType and supports Arabic OpenType fonts. Gradually, the OpenType typography support has improved on newer Mac OS X versions (e.g., Mac OS X 10.10 can handle much better long contextual glyph substitutions).

Bitstream Panorama, a line layout and text composition engine from Bitstream Inc., provides complete OpenType support for compact and standard Asian fonts, Arabic, Hebrew, Indic, Thai and over 50 other worldwide languages. The application supports key OpenType tables required for line layout, such as BASE, glyph definition (GDEF), glyph positioning (GPOS), and glyph substitution (GSUB). Panorama also offers complete support for advanced typography features, such as ligatures, swashes, small caps, ornaments, ordinals, superiors, old style, kerning, fractions, etc.

In free software environments such as Linux, OpenType rendering is provided by the FreeType project, included in free implementations of the X Window System such as X.org. Complex text handling is provided either by pango (calling HarfBuzz) or Qt. The XeTeX and LuaTeX systems allow TeX documents to use OpenType fonts, along with most of their typographic features. Linux version of LibreOffice 4.1 and newer supports many OpenType typography features, because it began to use more sophisticated HarfBuzz text shaping library.[43]

OpenType Feature File

[edit]

As a step in the creation of a font, OpenType font properties (other than the outline) can be defined using human-readable text saved in Adobe's OpenType Feature File format.[44][45] OpenType Feature Files typically have a name ending in a .fea extension. These files can be compiled into the binary font container (.ttf or .otf) using Adobe Font Development Kit for OpenType (AFDKO), FontLab, FontForge, Glyphs, DTL OTMaster, RoboFont or FontTools.

Layout tags

[edit]

OpenType Layout tags are 4-byte character strings that identify the scripts, language systems, features and baselines in an OpenType Layout font. Microsoft's Layout tag registry establishes conventions for naming and using these tags. OpenType features are created by using the tags in creating feature scripts that describe how characters are to be manipulated to make the desired feature. These feature scripts can be created and incorporated into OpenType fonts by advanced font editors such as FontLab Studio, AsiaFont Studio, and FontForge.

Operating system and application support for layout tags varies widely.

Script tags

[edit]

Script tags identify the scripts (writing systems) represented in an OpenType font. Each tag corresponds to contiguous character code ranges in Unicode. A script tag can consist of 4 or fewer lowercase letters, such as arab for the Arabic alphabet, cyrl for the Cyrillic script and latn for the Latin alphabet. The math script tag, added by Microsoft for Cambria Math, has been added to the specification.[46][47]

Language system tags

[edit]
Variations in Cyrillic cursive. Letters in same row have the same code point.

Language system tags identify the language systems supported in an OpenType font. Examples include ARA for Arabic, ESP for Spanish, HYE for Armenian, etc. In general, the codes are not the same as ISO 639-2 codes.[48]

These tags can be used to select local variants of letters that share a single Unicode code point.[48][49] For instance, the Serbian and Macedonian Cyrillic alphabet has some language-specific glyphs for certain letters, which are only preferred and are not strictly mandated.[citation needed]

Feature tags

[edit]
Main article: OpenType feature tag list

A list of OpenType features with expanded descriptions is given list of typographic features.

Baseline tags

[edit]

Baseline tags have a specific meaning when used in the horizontal writing direction (used in the 'BASE' table's HorizAxis table), vertical writing direction (used in the 'BASE' table's VertAxis table), or both.

Baseline tags and axes in OpenType fonts
Baseline tag HorizAxis VertAxis
'hang' horizontal line from which the syllabograms seem to hang in the Tibetan script The same line in Tibetan vertical writing mode.
'icfb' Ideographic character face bottom edge baseline. Ideographic character face left edge baseline.
'icft' Ideographic character face top edge baseline. Ideographic character face right edge baseline.
'ideo' Ideographic em-box bottom edge baseline. Ideographic em-box left edge baseline.
'idtp' Ideographic em-box top edge baseline. Ideographic em-box right edge baseline.
'math' The baseline about which mathematical characters are centered. The baseline about which mathematical characters are centered in vertical writing mode.
'romn' The baseline used by simple alphabetic scripts such as Latin, Cyrillic and Greek. The alphabetic baseline for characters rotated 90 degrees clockwise for vertical writing mode.

Math

[edit]

A set of tables that mirrors TeX math font metrics relatively closely was added by Microsoft initially to Cambria Math for supporting their new math editing and rendering engine in Office 2007 and later.[50][51] This extension was added to the ISO standard (ISO/IEC CD 14496-22 3rd edition) in April 2014.[52] Additional (usage) details are available in the Unicode technical report 25[53] and technical note 28.[54] Some of the new technical features (not present in TeX), such as "cut-ins" (which allows kerning of subscripts and superscripts relative to their bases[55]) and stretch stacks[56] have been patented by Microsoft.[57][58][59] Windows 8 supports OpenType math outside MS Office applications via the RichEdit 8.0 component.[60]

Besides Microsoft products, XeTeX and LuaTeX also have some level of support for these tables; support is more limited in XeTeX because it uses the traditional TeX math rendering engine (thus it cannot fully use some of the new features in OpenType math that extend TeX), while LuaTeX takes a more flexible approach by changing some of the internals of TeX's math rendering; in the words of Ulrik Vieth (2009): "More precisely, while XeTeX only provides access to the OpenType parameters as additional \fontdimens, LuaTeX uses an internal data structure based on the combined set of OpenType and TeX parameters, making it possible to supply missing values which are not supported in either OpenType math fonts or traditional TeX math fonts."[56] In 2013, XeTeX also gained support for cut-ins.[61]

The Gecko rendering engine used by the Firefox web browser also supports some OpenType math features in its MathML implementation.[62][63]

As of 2024, the set of fonts that supported OpenType math includes: Asana-Math, Cambria Math, DejaVu Math TeX Gyre, Garamond Math, Latin Modern Math, Libertinus Math, Neo Euler, STIX Math, XITS Math, Fira Math, GFS Neohellenic Math, and four TeX Gyre fonts Bonum Math, Pagella Math, Schola Math, Termes Math.[64] [65] More recently the Latin Modern and TeX Gyre fonts (an "LM-ization" of the standard PostScript fonts[66]) have also gained support for OpenType math.[67][68][69][70] As of 2014 the number of OpenType math fonts is still fairly limited.[71] A more up-to-date list is maintained on Mozilla's web site .[64]

Color

[edit]

Emergence of Unicode emoji created a need for TrueType and OpenType formats to support color glyphs. Apple added a color extension in Mac OS X Lion (and also to iOS 4+). Fonts were extended with colored PNGTooltip Portable Network Graphics images within the sbix table.[72][73][74] Google used a similar extension with embedded color bitmap images contained within a pair of tables, the CBDT and CBLC tables.[75] The Google version is implemented in FreeType 2.5.[76]

In Windows 8.1 Microsoft also added color support to fonts, first implemented in the Segoe UI Emoji font.[73][77][78][79] Microsoft's implementation, however, relies entirely on vector graphics:[73][80] two new OpenType tables were added in Microsoft's implementation: the COLR table allows layered glyphs and the CPAL ("Color Palette") actually defines the colors for the layers. The multi-layer approach allows a backwards compatible implementation as well as varying the rendering depending on the color context surrounding the glyphs.[73] According to Adam Twardoch: "At TypeCon [2013], Greg Hitchcock clarified the envisioned roles of the palettes: first palette is used by default for "dark on light" color situations while second palette is intended for use in "light on dark" situations. Additional palettes should be selectable by the user."[76]

Mozilla and Adobe developed a different vector-based extension by adding embedded SVG documents (supporting color but also animations) into the SVG table. The SVG table also allowed for using color palettes defined in the CPAL table.[81] Support was first implemented in Firefox 26.[75]

Adobe, Mozilla, Google and Microsoft each submitted their color extensions for standardization thorough ISO/IEC 14496-22.[82] The new tables for each of these were then added into OpenType version 1.7.[83] Apple's sbix table was originally supported only in AAT fonts, but it was later added into OpenType version 1.8.[84] Microsoft Windows 10 Anniversary Update was the first OS to support all four color font extensions, and Microsoft Edge was the first browser to do so.[85][86]

In OpenType Version 1.8.3, the specification for the SVG table was revised to be more constrained, providing more clarity for implementations and better interoperability. Apple is supporting the revised specification in Safari 12, iOS 12 and macOS 10.14.[87] The implementation in Microsoft Windows also conforms to this revision.

SING gaiji solution

[edit]

In 2005, Adobe shipped a new technology in their Creative Suite applications bundle that offers a solution for "gaiji" (外字, Japanese for "outside character"). Ideographic writing scripts such as Chinese and Japanese do not have fixed collections of characters. They use thousands of glyphs commonly and tens of thousands less commonly. Not all glyphs ever invented and used in East Asian literature have even been catalogued. A typical font might contain 8,000 to 15,000 of the most commonly used glyphs. From time to time, though, an author needs a glyph not present in the font of choice. Such missing characters are known in Japan as gaiji, and they often disrupt work.

Another aspect of the gaiji problem is that of variant glyphs for certain characters. Often certain characters have been written differently over periods of time. It is not unusual for place names or personal family names to use a historical form of a character. Thus it is possible for an end user using standard fonts to be left unable to spell correctly either their own name or the name of the place where they live.

Several ways to deal with gaiji have been devised. Solutions that treat them as characters usually assign arbitrary Unicode values to them in the Private Use Areas (PUA). Such characters cannot be used outside the environment in which the association of the private Unicode to the glyph shape is known. Documents based on them are not portable. Other installations treat gaiji as graphics. This can be cumbersome because text layout and composition cannot apply to graphics. They cannot be searched for. Often their rendering looks different from surrounding characters because the machinery for rendering graphics usually is different from the machinery for rendering glyphs from fonts.

The SING (Smart INdependent Glyphlets)[88][89] technology that made its debut with Adobe's Creative Suite 2 allows for the creation of glyphs, each packaged as a standalone font, after a fashion. Such a packaged glyph is called a glyphlet. The format, which Adobe has made public, is based on OpenType. The package consists of the glyph outline in TrueType or CFF (PostScript style outlines) form; standard OpenType tables declaring the glyph's metrics and behavior in composition; and metadata, extra information included for identifying the glyphlet, its ownership, and perhaps pronunciation or linguistic categorization. SING glyphlets can be created using Fontlab's SigMaker3 application.

The SING specification states that glyphlets are to travel with the document they are used in. That way documents are portable, leaving no danger of characters in the document that cannot be displayed. Because glyphlets are essentially OpenType fonts, standard font machinery can render them. The SING specification also describes an XML format that includes all the data necessary for reconstituting the glyphlet in binary form. A typical glyphlet might require one to two kilobytes to represent.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

OpenType

View on Grokipedia
from Grokipedia
OpenType is a scalable computer font format developed jointly by Microsoft and Adobe as an extension of Apple's TrueType SFNT structure, enabling advanced typographic controls, cross-platform compatibility between Windows and macOS, and support for up to 65,000 glyphs in a single file. Introduced in 1997 with OpenType 1.0, the format builds on TrueType by incorporating PostScript outlines (in .otf files) alongside TrueType outlines (in .ttf files), allowing font designers to combine base, expert, and additional glyph sets without multiple files. It became an international standard as ISO/IEC 14496-22 in 2007 with version 1.4, and continues to evolve, with version 1.9.1 released in May 2024 incorporating updates to the Open Font Format standard. Contributions from Apple and Monotype have enhanced its capabilities, making it the dominant format for professional typography. Key features include Unicode-based encoding for multilingual support across virtually all writing systems, advanced layout options such as ligatures, , swashes, and optical sizes tailored to text scales (e.g., caption sizes from 6-8 points or display from 25-72 points), and precise control over positioning for complex scripts like or . OpenType fonts are rendered using table-based data structures that applications like or interpret for text layout, ensuring consistent appearance across devices. A significant extension is OpenType Font Variations, introduced as part of the standard to package multiple related font faces (e.g., varying weights or widths) into one efficient file, allowing continuous interpolation along design axes for flexible styling while reducing file sizes compared to traditional families. This innovation, building on earlier technologies like Apple's GX, supports modern web and print workflows by enabling editable text with dynamic adjustments to thickness, spacing, and other attributes.

Overview

Core Description

OpenType is an open standard for scalable computer fonts, jointly developed by Microsoft and Adobe in 1996 to provide a unified, cross-platform solution for font rendering on personal computers and the internet. This format combines elements of previous font technologies to streamline font management and support advanced typographic features, ensuring compatibility across operating systems like Windows and macOS as well as Adobe's PostScript-based products. OpenType fonts typically use the file extension .otf, although they may also employ .ttf for TrueType-based variants, and encapsulate all necessary font data—including glyph outlines, character metrics, information, and layout instructions—within a single file. This single-file simplifies distribution and installation compared to earlier formats that often required multiple files for outlines and metrics. The format builds on the SFNT (Scalable Font) structure originally used by fonts while incorporating support for the Compact Font Format (CFF), a compact representation of Type 1 outlines developed by . By unifying these approaches—TrueType's quadratic Bézier curves for glyph outlines and CFF's cubic Bézier curves—OpenType allows font designers to choose the most suitable outline representation without sacrificing compatibility, effectively superseding the separate and Type 1 ecosystems. In digital typography, OpenType plays a central role by enabling consistent text rendering across diverse devices and applications, from screen displays to high-resolution printing, through its support for scalable outlines and precise control over glyph positioning and substitution. This ensures that fonts maintain visual fidelity regardless of output medium or platform, facilitating broader adoption in , , and multilingual typesetting.

Key Components

OpenType fonts are structured around modular components that define glyph representation, metrics, metadata, and basic positioning. Glyphs serve as the fundamental units, each comprising an outline path that describes its visual form. In fonts using outlines, these paths are constructed from quadratic Bézier curves, connecting on-curve and off-curve points to form contours. Conversely, fonts with Compact Font Format (CFF) outlines employ cubic Bézier curves for more precise curve representation, aligning with heritage. Hinting instructions, stored within the glyph data primarily for outlines, guide the rasterization process by adjusting point positions on a grid, ensuring legible rendering at low resolutions. The font's organization relies on a series of core tables that provide essential data for rendering and management. The 'head' table acts as the font header, specifying global attributes such as the units per em value, which sets the design coordinate system's granularity; this is typically 1000 units for CFF-based fonts and 2048 units—a power of two—for TrueType-based fonts to optimize rasterization. The 'hhea' table delivers horizontal metrics, including the ascender (top extent above baseline), descender (bottom extent), line gap (recommended interline spacing), and maximum advance width, enabling accurate horizontal text alignment and spacing. Complementing this, the 'vhea' table furnishes vertical metrics like advance height and side bearings, tailored for vertical writing systems such as those in Chinese, Japanese, and Korean scripts. Metadata is managed through dedicated tables for identification and control. The 'name' table holds multilingual strings for font attributes, such as family name, (e.g., regular or bold), , and credits, supporting localization across platforms. Basic positioning, particularly to refine inter-glyph spacing for aesthetic pairing, is defined in the 'kern' table for TrueType-based fonts, using either pairwise adjustments or class-based lookups to specify horizontal or vertical offsets. Licensing and platform-specific details reside in the 'OS/2' table, which includes embedding permissions via the fsType field; this uint16 value encodes restrictions like installable embedding (full editing allowed), restricted license (read-only viewing and printing), or editable embedding, ensuring compliance with usage rights. It also contains the vendor ID, a four-character code identifying the font creator, registered through official channels for traceability.

History and Development

Origins and Early Format

OpenType emerged from collaborative efforts between and to unify font technologies in the digital landscape. Development began in 1996, with the companies announcing the format as a successor to existing standards, and the first public specification was released on April 23, 1997. This initiative aimed to streamline font management across platforms by creating a single, extensible format that could encompass both outline technologies prevalent at the time. The format's roots trace back to Apple's , introduced in 1989 as a alternative to font systems, which licensed and integrated into Windows. Complementing this were Adobe's Type 1 fonts, developed in the 1980s as part of the language to deliver high-quality outlines for printing. OpenType addressed the fragmentation between these systems—TrueType's quadratic Bézier curves optimized for screen rendering and Type 1's cubic Bézier curves favored for print precision—by employing the sfnt (Scalable Font) container structure from as a wrapper. This allowed fonts to store either outlines or Adobe's new Compact Font Format (CFF) data, derived from Type 1, within the same file, thereby enabling -level quality in Windows environments without requiring separate PostScript rasterizers. Early adoption faced hurdles, particularly on the Macintosh platform, where Apple's legacy system prioritized native and Type 1 support over the new unified format. Comprehensive OpenType integration on macOS did not occur until the early with the shift to OS X, which began supporting basic features in version 10.4 () and expanded capabilities in subsequent releases, reflecting a gradual transition from earlier font handling limitations.

Evolution of Features

In 2008, with the release of OpenType 1.5, the format integrated support for Unicode Variation Sequences (UVS), enabling contextual glyph selection particularly for ideographic scripts and other characters requiring alternate forms. This enhancement utilized the cmap table's Format 14 subtable, which maps a base Unicode character followed by a variation selector to a specific glyph index, allowing fonts to specify variants like vertical or rotated forms without expanding the Unicode code space. The feature was aligned with Unicode 4.1's introduction of ideographic variation selectors, facilitating richer typographic expression in East Asian typography while maintaining backward compatibility with earlier OpenType implementations. In 2009, with the release of OpenType 1.6, the format extended support for font collections to include OpenType Collections (.otc files) for CFF-based fonts, building on the earlier Collections (.ttc) mechanism. This allowed shared data—such as glyph outlines or metrics—to be stored once, reducing and simplifying management for complex font families, especially those supporting CJK languages with extensive character sets. The .otc structure includes a collection header followed by individual font offsets, enabling efficient loading of subsets like regular and bold variants without duplicating common resources. The .otc format was further recommended and tooled for practical use around 2014. In 2007, OpenType version 1.4 became an as ISO/IEC 14496-22. Microsoft and Adobe initiated a collaboration in 2014 to revive and standardize variable font technology, culminating in the OpenType 1.8 specification released in September 2016. This partnership, involving input from Apple and , introduced the 'fvar' (font variations) table and related structures like 'avvar' (axis variations), permitting continuous of shapes along user-defined design axes such as weight (wght), width (wdth), or optical size (opsz). Variable fonts consolidate what were traditionally multiple static files into one, offering substantial savings in file size—up to 50% for families with many styles—while enabling dynamic adjustments in applications for responsive design and performance optimization. In 2016, OpenType 1.8 further advanced with updates for color fonts, incorporating layered compositions via the COLR (color layers) table and predefined palettes in the CPAL (color palette) table to overcome the limitations of glyph rendering. These tables define s as stacked base shapes with associated color indices from palettes supporting up to 65,536 entries in RGBA format, allowing scalable vector-based multicolored designs without relying on embeds. This addressed longstanding constraints in digital typography, enabling richer like gradients or icons in fonts, with initial implementations in and applications. Specific tag implementations, such as 'CPAL' version 1, facilitate palette selection for consistent rendering across platforms. The MATH table for mathematical typesetting was introduced in OpenType 1.7 (March 2015), providing data for complex expressions including stretchy delimiters and radical signs, with subsequent minor updates in later versions such as 1.9 (December 2021) for improved integration with in educational and scientific applications. WOFF2, standardized in 2014, uses compression to efficiently deliver OpenType fonts on the web, including variable and color variants, achieving up to 30% better compression ratios compared to WOFF. These developments, driven by W3C and ISO collaborations, emphasize cross-platform efficiency and accessibility in modern .

Technical Specifications

Font Tables and Structure

OpenType fonts are structured using the SFNT (Scalable Font) format, which organizes font data into a series of tables accessible via offsets for efficient parsing and rendering. The SFNT wrapper begins with a table directory that lists all tables in the font file, enabling applications to locate specific data without scanning the entire file. This directory includes fields such as the SFNT version (0x00010000 for TrueType-based OpenType fonts or 0x4F54544F for CFF-based ones), the number of tables, and an array of table records, each containing a four-character tag, a checksum, an offset from the start of the file, and the table's length. Offsets use variable-sized types (Offset8, Offset16, Offset24, or Offset32) to reference table locations relative to the file start or parent structures, with a null offset (0x00000000) indicating the absence of optional subtables. The table directory facilitates access to core tables that define essential font properties. The required 'cmap' table provides character-to-glyph mapping, supporting and other encodings to associate input code points with corresponding indices in the font. For outlines, TrueType-based OpenType fonts use the 'glyf' table to store vector paths as quadratic Bézier curves, while CFF-based fonts employ the 'CFF ' table for compact representation of outlines using cubic Bézier curves; exactly one of these outline tables is present depending on the font flavor. Metrics tables handle spacing and positioning: the 'hmtx' table, which is required, contains horizontal advance widths and left side bearings for each , derived from the 'hhea' header; the optional 'vmtx' table provides analogous vertical metrics (advance heights and top side bearings) for scripts requiring vertical typesetting. OpenType supports embedded bitmaps for low-resolution rendering as a fallback when scalable outlines are insufficient. The 'sbix' table stores color and bitmap glyphs in format, allowing high-fidelity display at specific sizes, while the older EBDT/EBLC pair (embedded bitmap data and location) accommodates black-and-white s in a more compact structure, both being optional. Integrity and versioning are managed through the required 'head' table, which includes a font revision number in Version16Dot16 format (e.g., 0x00010000 for version 1.0) and a adjustment field calculated as 0xB1B0AFBA minus the sum of all table checksums (each a uint32 sum of the table's 4-byte units, padded with zeros if necessary). This mechanism ensures the font file's during storage and transmission, with the overall font checksum excluding the 'head' table itself to avoid circular computation. Layout tables like 'GSUB' and 'GPOS' build on this structure for glyph substitution and positioning but are addressed separately.

Layout and Positioning Tags

OpenType employs a tag-based to manage layout and positioning, primarily through the GSUB (Glyph Substitution) and GPOS (Glyph Positioning) tables, supported by the GDEF (Glyph Definition) and BASE tables. These four-character tags—script, language , feature, and baseline—enable layout engines to apply script- and language-specific rules for substitutions, adjustments, and alignments, ensuring accurate rendering of complex text across diverse writing systems. The organizes data hierarchically: scripts contain language systems, which in turn reference features, while baselines and classes provide foundational alignment and categorization. Script tags identify the and establish default layout behaviors, stored as four-byte codes in the ScriptList table of GSUB and GPOS. For instance, 'latn' denotes Latin-based scripts like English and French, applying rules such as left-to-right directionality and alphabetic ordering, while 'arab' specifies scripts with right-to-left progression and contextual shaping. These tags are sorted alphabetically in an array of ScriptRecord structures, allowing the layout engine to select the appropriate script based on the text's properties and apply corresponding substitutions or positioning. A default script, often 'DFLT', serves as a fallback when no specific script matches. Language system tags build upon script tags to accommodate locale-specific variations, also using four-byte codes within the LangSys table of a given script. The 'dflt' tag provides universal rules applicable across the script without language distinctions, whereas 'ENG ' customizes behaviors for English, such as hyphenation patterns or required features. Each LangSysRecord includes offsets to a default language system and an array of feature indices, mandating certain features (via a requiredFeatureIndex, or 0xFFFF if none) to ensure culturally appropriate rendering, like variant numeral forms in different English locales. This hierarchy allows fine-grained control, where the engine first matches the script, then the , before executing features. Feature tags define specific typographic operations, referenced via the FeatureList table and invoked by language systems to trigger lookup tables in GSUB or GPOS. In GSUB, tags like 'liga' enable ligature substitution, replacing sequences such as "fi" with a single ligature glyph for aesthetic improvement. GPOS uses tags such as 'kern' to adjust inter-glyph spacing based on pairwise kerning pairs, reducing optical inconsistencies in letter combinations, and 'mark' to position diacritics above or below base glyphs using anchor points. Each feature contains a FeatureRecord with a tag, offsets to lookup lists, and flags for exclusive or required application; multiple lookups per feature allow chained operations, such as contextual positioning. These mechanisms support over 80 registered feature tags, prioritizing those essential for readability and cultural fidelity. Baseline tags in the BASE table facilitate vertical alignment of glyphs from different scripts or font sizes, using four-byte codes to define reference lines relative to the em square. For example, 'romn' represents the Roman (alphabetic) baseline, typically at Y=0 for Latin and Cyrillic scripts, ensuring consistent text flow in horizontal writing modes. In contrast, 'hang' denotes the hanging baseline for South Asian scripts like Devanagari, often positioned higher (e.g., at Y=1500 design units) to accommodate descenders and matras. The BaseTagList array coordinates these with MinMax and BaseValues tables, providing script-, language-, or feature-specific coordinates for axis-aligned positioning, which is crucial for mixed-script documents like English with Hindi loanwords. The GDEF table complements these tags by classifying glyphs into four categories to optimize lookup processing in GSUB and GPOS. Base glyphs (class 1) are standalone, spacing characters like "A" or "i", serving as anchors for attachments. Ligature glyphs (class 2) represent combined forms such as "ffi", treated as single units for caret placement and mark positioning. Mark glyphs (class 3) include non-spacing elements like acute accents, which attach to bases or ligatures via GPOS mark-to-base or mark-to-ligature lookups. Component glyphs (class 4) form parts of composites, such as segments in Indic conjuncts, and are excluded from certain substitutions to prevent fragmentation. These classes, defined in a ClassDef table, use flags in lookups (e.g., IgnoreBaseGlyphs) to filter operations efficiently, reducing computational overhead in rendering engines.

Typography Capabilities

Language and Script Support

OpenType provides foundational support for basic Roman scripts through the tag 'latn', enabling proportional and fixed-width fonts for Western European languages such as English and French. This is achieved via the Unicode character-to-glyph mapping table (cmap), which assigns glyphs to Latin characters, combined with standard pairs defined in the Glyph Positioning Table (GPOS) using the 'kern' feature for adjustments between adjacent characters. Such support ensures consistent rendering of left-to-right text in applications, with language-specific conventions handled by tags like 'ENG ' for English and 'FRA ' for French in the OpenType Layout tables. Extended language support in OpenType encompasses scripts beyond Latin, including Cyrillic ('cyrl'), Greek ('grek'), and Devanagari ('deva'), all mapped through the Unicode cmap for character encoding. For Cyrillic, this covers languages like Russian ('RUS ') and Belarusian ('BEL '), while Greek support includes Modern Greek ('ELL '), and Devanagari accommodates Hindi ('HIN ') with its Unicode block. Right-to-left (RTL) scripts such as Hebrew ('hebr') and Arabic ('arab') are integrated via script and language system tags, allowing bidirectional text handling in conjunction with the Unicode Bidirectional Algorithm (UBA) for proper reordering of mixed directional runs. Complex script shaping in OpenType relies on the Glyph Substitution Table (GSUB) and GPOS for advanced rendering of non-Roman systems. For Arabic, joining forms are applied through GSUB substitutions based on contextual rules, ensuring cursive connections across words in languages like Arabic ('ARA '). In Indic scripts like Devanagari, reordering of matras and conjuncts occurs via GSUB lookups, which rearrange glyphs to form ligatures and clusters for accurate syllable representation in Hindi and related languages. These mechanisms, tied to specific script tags and their default language systems, enable precise typographic conventions without requiring external processing. For , OpenType supports vertical writing modes primarily through the Vertical Header ('vhea') table, which defines metrics like advance heights and origins for glyphs in scripts such as Han ('hani') used in Chinese, Japanese, and Korean. The Vertical Metrics ('vmtx') table complements this by providing per-glyph vertical spacing, ensuring proper alignment and baseline positioning in vertical layouts, as required for all OpenType fonts intended for such orientation. This setup integrates with the cmap for CJK ideographs, supporting language tags like those for Simplified Chinese or Japanese variants.

Advanced Typographic Features

OpenType provides a range of advanced typographic features that enable fine-tuned substitution and positioning, allowing designers to achieve professional-level effects beyond basic character rendering. These features are implemented through the Substitution (GSUB) and Positioning (GPOS) tables, which support optional enhancements for aesthetic and contextual refinement in fonts. Substitution features in OpenType allow for the replacement of default glyphs with alternates to enhance visual appeal or historical accuracy. The stylistic sets, tagged 'ss01' through 'ss20', offer up to 20 distinct sets of alternate glyphs that can be applied across an entire document or selected elements, such as varying flourishes on capital letters in a font like those seen in Adobe's Minion Pro. The 'hist' feature replaces contemporary glyph forms with historical variants, for instance, substituting the modern looped lowercase 'z' with its 18th-century double-story form in fonts designed for period authenticity. Similarly, the 'swsh' feature introduces alternates, replacing standard characters with decorative, calligraphic versions—such as elongated, flourished initials in script faces like Adobe's Poetica—to add elegance in invitations or book titles. Positioning features further refine layout for specialized numerical and sizing needs. The 'size' feature encodes optical sizing information within the font, specifying the design size (e.g., 12 points for text) and usable range (e.g., 6–24 points), enabling automatic adjustments like slightly bolder strokes for smaller sizes to maintain legibility across print scales. For numerical contexts, 'frac' transforms slashed figures into diagonal fractions, converting "1/2" to a proper ½ glyph with numerator and denominator aligned on a baseline, as implemented in fonts like for recipes or measurements. The 'ordn' feature applies superscript-like ordinal forms to letters following numbers, such as rendering "1st" with a raised 'st' in fonts supporting English conventions, ensuring compact and readable abbreviations in tables or bibliographies. Mark attachment mechanisms handle complex diacritic positioning in non-Latin scripts, using GPOS subtables for precise placement. Mark-to-base attachment positions combining marks relative to base glyphs, essential for scripts like or Hebrew where diacritics such as vowel signs must align accurately with . Mark-to-mark attachment extends this by positioning secondary marks relative to primary ones, critical for tonal languages; in Thai, for example, it stacks tone marks above vowel diacritics on base , while in Vietnamese, it layers multiple accents like the and acute on letters such as 'ê'. These attachments rely on anchor points defined in the font's outline data to ensure vertical and horizontal offsets are script-appropriate. Contextual alternates, via the 'calt' feature, enable dynamic selection based on surrounding characters, improving connectivity and in connected scripts. In cursive Latin fonts, it might select initial, medial, or final forms for letters like 's' in words such as "," while in , it chooses joining variants for fluid script flow, as seen in fonts like Microsoft's Amiri. This feature often chains with script-specific lookups to prioritize language-aware substitutions without manual intervention.

Implementation and Tools

Feature File Specification

The OpenType Feature File, typically with a .fea extension, is a human-readable text format designed to specify typographic layout features for OpenType fonts in a structured, easy-to-parse manner. This format allows font designers to define substitutions and positioning rules that are compiled into the GSUB (Glyph Substitution) and GPOS (Glyph Positioning) tables of the font. The file consists of blocks for declaring languagesystems, features, and lookups, using a syntax that supports glyph classes, contextual rules, and reusable components to promote efficiency and maintainability. As of 2025, the specification (version 1.26, last updated June 2021) remains the standard, with tools like Adobe's AFDKO and Python's fontTools enabling compilation. The core structure relies on keyword-driven blocks. A languagesystem block registers supported script and language combinations, such as languagesystem latn dflt;, which declares the default and for feature application. Glyph classes can be defined using the @ prefix for shorthand, for example, @lowercase = [a-z];, enabling compact rule writing. Features are enclosed in feature blocks tagged with four-letter OpenType identifiers, like feature smcp { sub @lowercase by [A-Z.sc]; } smcp;, which implements substitution. Lookups, defined via lookup blocks, group related rules for reuse across features, such as lookup Uppercase { sub @lowercase by @uppercase; } Uppercase;, allowing modular organization by isolating common operations. For GSUB rules, keywords like substitute (abbreviated as sub) handle glyph replacements, supporting single substitutions (sub a by A;), ligatures (sub f f i by f_f_i;), alternates (sub uni00B7 from [periodcentered.loclCatalan periodcentered];), and contextual forms (sub [space hyphen] sigma' by sigmafinal;). GPOS rules use position (or pos) for adjustments, including single positioning (pos quotedblbase -10;), pairwise kerning (pos A V -50;), mark attachment (pos base @marks <anchor 0 0> <anchor 0 500>;), and cursive connections (pos initial medial <anchor 100 0> <anchor 100 200>;). These keywords facilitate precise control over text shaping, with options like ignore for exclusions and reversesub for backward contextual matching. Specific tags, such as 'liga' for ligatures or 'kern' for kerning, are referenced within these rules to align with OpenType layout standards. Compilation transforms the .fea file into binary font tables using tools from Adobe's Font Development Kit for OpenType (FDK/OT), particularly the makeotf command-line utility, which processes the text alongside glyph outlines and metrics to generate the final OpenType font file. This automatically inserts subtables for efficiency, orders lookups sequentially (with the 'aalt' feature compiled first by aggregating referenced substitutions), and enforces constraints like no script or language exclusions in 'aalt'. Font design software such as integrates this workflow by providing editors for .fea content, automatic generation from glyph data, and direct compilation via embedded AFDKO tools, streamlining feature authoring within the design environment. Modern editors like Glyphs and RoboFont also support .fea files for OpenType feature development. Best practices emphasize modularity through named lookups to avoid redundancy, explicit declaration of all languagesystem entries (including DFLT dflt;) to ensure broad compatibility, and early definition of markClass blocks for mark positioning to prevent scoping issues. For error handling, compilers like makeotf validate glyph names against the font's glyph set, flagging undefined references or syntax errors during build; designers should use consistent naming conventions and test incrementally to catch invalid glyphs or rule conflicts. Additionally, grouping non-contextual rules together aids optimization, as the compiler sorts them internally while preserving contextual order for accurate rendering.

Software and Platform Support

OpenType enjoys broad implementation across major operating systems, enabling advanced in desktop, mobile, and web environments. Support varies by platform, with native integration in core rendering engines that handle glyph substitution (GSUB) and positioning (GPOS) tables for complex script rendering. This ecosystem ensures cross-platform consistency while addressing gaps in older or specialized software. Windows provides native support for OpenType fonts since , treating them as extensions of for seamless compatibility. Advanced OpenType features, such as ligatures, , and stylistic sets, are facilitated by the , introduced in , which offers high-quality text layout and rendering beyond legacy GDI methods. Apple's Core Text framework delivers comprehensive OpenType handling in macOS and , with support for features like GSUB and GPOS introduced in OS X 10.5 () to improve multilingual text rendering, including precise glyph positioning for scripts like and Indic. Further enhancements arrived in later versions, such as improved handling of long contextual glyph substitutions in OS X 10.10 (Yosemite). On and systems, the library serves as the primary OpenType shaping engine, converting text into positioned glyphs for over 100 scripts. It is deeply integrated into desktop environments, including via GTK+ and via Qt, powering text rendering in tools like and web browsers. Web technologies support OpenType through the CSS @font-face rule, typically using WOFF or OTF formats for efficient loading and subsetting. Major engines—Blink in Chrome (since version 4), in (since version 3.5), and in (since version 3.1)—provide robust compatibility, including variable fonts via font-variation-settings since 2018, allowing dynamic weight and width adjustments. Despite this maturity, gaps persist in legacy software; older Adobe applications, such as Creative Suite 6, offer partial OpenType support but may not fully utilize features like optical sizing without updates. Similarly, mobile keyboards on and Android provide basic OpenType font loading but often limit advanced typographic features, such as contextual alternates, due to constraints.

Specialized Extensions

Color Fonts and Variations

OpenType supports several formats for color fonts, enabling glyphs with multicolored elements beyond traditional monochrome outlines. The COLR and CPAL tables, introduced in OpenType 1.8 in 2016, define layered color presentations where a base glyph is composed of multiple paint layers, each referencing other glyphs or solid colors from palettes stored in CPAL. These layers can incorporate via the SVG table or bitmap images, allowing for complex, multicolored designs such as gradients and animations in compatible renderers. For bitmap-based color fonts, the CBDT and CBLC tables provide embedded raster glyph data, supporting formats like for pixel-perfect rendering at specific sizes without scaling artifacts. This approach is particularly efficient for fixed-resolution displays. Separately, Apple's SBIX table embeds layered graphics, typically PNG images, offering multiple resolutions within a single font for high-fidelity color reproduction on Apple platforms. Variable fonts extend OpenType with parametric variations, allowing continuous interpolation between multiple master designs in a single file. The 'fvar' table declares variation axes, such as weight (wght), width (wdth), and slant (slnt), defining the range and default values for each. The 'gvar' table stores per-glyph variation data as delta offsets applied along these axes, enabling smooth transitions in outline points, while the 'avar' table maps normalized axis coordinates to custom curves for non-linear interpolation. This mechanism reduces file sizes compared to static font families by eliminating redundant masters. The MATH table provides specialized data for typesetting mathematical expressions, including glyph metrics for stretchy delimiters, fractions, radicals, and superscripts/subscripts. It defines font-wide constants like script percent scale-down and assembly rules for operators, facilitating precise layout in applications such as equation editors. These extensions find applications in emojis, where color formats like COLR/CPAL or CBDT/CBLC enable vibrant, layered icons in fonts such as Noto Color Emoji; in icon sets for user interfaces, supporting scalable multicolored symbols; and in responsive web typography via variable fonts, which adapt to screen sizes and styles dynamically. However, color fonts often increase file sizes due to embedded image or layer data, potentially impacting performance on resource-constrained devices.

SING Gaiji Mechanism

The SING Gaiji mechanism is an OpenType extension designed to handle gaiji—rare or vendor-specific ideographic characters in Chinese, Japanese, and Korean (CJK) typesetting—by providing a lightweight, portable alternative to embedding full glyphs in fonts, thereby avoiding unnecessary font bloat for infrequently used characters. This approach ensures encoding independence and facilitates document portability in digital publishing workflows, such as those involving and PDF formats. Implementation relies on the 'SING' table within compact, self-contained objects known as glyphlets, which are essentially single-glyph OpenType fonts lacking tables like 'name' and 'OS/2' but including a 'META' table for metadata such as glyph descriptions and licensing information. Each glyphlet maps a specific ID (typically GID+1) to the substitute , which can be dynamically loaded and integrated into base fonts using software libraries like Adobe's SING Library and Tin Library, often activated through Unicode Private Use Area (PUA) codepoints for compatibility, though PUA usage is optional and discouraged in metadata. In practice, glyphlets are embedded directly into documents (e.g., PDF 1.3 or later), preserving portability without requiring installed fonts on the receiving system, and they support vector outlines in CFF or formats. Developed primarily by Systems in collaboration with Japanese font vendors such as Morisawa, the SING mechanism emerged from efforts starting around 2000 to resolve gaiji challenges in , with its formal announcement on April 8, 2004, and integration into CS2 and CS3 around 2005–2007. Tools for creating glyphlets include Adobe's Glyphlet Creation Tool and cvt2sing utility, alongside third-party options like FontLab's SigMaker and Musashi System's SINGEdit, enabling vendors to produce and distribute these mini-fonts for on-demand use. This builds on broader OpenType support for CJK scripts by offering a fallback for non-standard ideographs not covered in standard collections like Adobe-Japan1. Compared to traditional gaiji embedding, which bloats font files with thousands of additional glyphs, SING glyphlets significantly reduce document sizes—often to just a few kilobytes per rare character—while maintaining typographic quality and enabling seamless integration in digital formats like for cross-platform compliance. This efficiency is particularly beneficial for publishing scenarios with sporadic rare character needs, promoting a more modular and scalable approach to CJK font management without compromising on portability or licensing controls.

References

  1. https://learn.microsoft.com/en-us/typography/opentype/
  2. https://www.adobe.com/products/type/opentype.html
  3. https://learn.microsoft.com/en-us/typography/opentype/spec/
  4. https://learn.microsoft.com/en-us/typography/opentype/spec/otff
  5. https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview
  6. https://helpx.adobe.com/photoshop/desktop/text-typography/select-manage-fonts/use-opentype-variable-fonts.html
  7. https://news.microsoft.com/source/1996/05/06/microsoft-and-adobe-systems-to-deliver-universal-font-format-brings-profit-alliance-model-to-microsofts-small-business-web-site/
  8. https://www.daltonmaag.com/resources/font-technology/opentype/index.html
  9. https://www.high-logic.com/font-editor/fontcreator/tutorials/the-difference-between-truetype-and-opentype-fonts
  10. https://learn.microsoft.com/en-us/typography/opentype/spec/ttch01
  11. https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructing_glyphs
  12. https://learn.microsoft.com/en-us/typography/opentype/spec/head
  13. https://learn.microsoft.com/en-us/typography/opentype/spec/hhea
  14. https://learn.microsoft.com/en-us/typography/opentype/spec/vhea
  15. https://learn.microsoft.com/en-us/typography/opentype/spec/name
  16. https://learn.microsoft.com/en-us/typography/opentype/spec/kern
  17. https://learn.microsoft.com/en-us/typography/opentype/spec/os2
  18. https://news.microsoft.com/source/1997/04/23/adobe-systems-and-microsoft-deliver-opentype-font-specification/
  19. https://learn.microsoft.com/en-us/typography/truetype/history
  20. https://learn.microsoft.com/en-us/typography/opentype/otspec182/overview
  21. https://discussions.apple.com/thread/1646793
  22. https://learn.microsoft.com/en-us/typography/opentype/opentypeversions
  23. https://learn.microsoft.com/en-us/typography/opentype/spec/cmap
  24. https://ccjktype.fonts.adobe.com/2014/01/otc.html
  25. https://medium.com/variable-fonts/introducing-opentype-variable-fonts-12ba6cd2369
  26. https://learn.microsoft.com/en-us/typography/opentype/otspec180/changes
  27. https://learn.microsoft.com/en-us/typography/opentype/spec/colr
  28. https://learn.microsoft.com/en-us/typography/opentype/spec/math
  29. https://learn.microsoft.com/en-us/typography/opentype/spec/changes
  30. https://www.w3.org/TR/WOFF2/
  31. https://learn.microsoft.com/en-us/typography/opentype/spec/otff#table-directory
  32. https://learn.microsoft.com/en-us/typography/opentype/spec/otff#offsets
  33. https://learn.microsoft.com/en-us/typography/opentype/spec/otff#required-tables
  34. https://learn.microsoft.com/en-us/typography/opentype/spec/otff#sbix-table
  35. https://learn.microsoft.com/en-us/typography/opentype/spec/otff#head
  36. https://learn.microsoft.com/en-us/typography/opentype/spec/otff#calculating-checksums
  37. https://learn.microsoft.com/en-us/typography/opentype/spec/chapter2
  38. https://learn.microsoft.com/en-us/typography/opentype/spec/gpos
  39. https://learn.microsoft.com/en-us/typography/opentype/spec/gsub
  40. https://learn.microsoft.com/en-us/typography/opentype/spec/base
  41. https://learn.microsoft.com/en-us/typography/opentype/spec/gdef
  42. https://learn.microsoft.com/en-us/typography/opentype/spec/scripttags
  43. https://learn.microsoft.com/en-us/typography/opentype/spec/languagetags
  44. https://learn.microsoft.com/en-us/typography/script-development/standard
  45. https://learn.microsoft.com/en-us/typography/opentype/spec/vmtx
  46. https://learn.microsoft.com/en-us/typography/opentype/spec/ttochap1
  47. https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt
  48. https://learn.microsoft.com/en-us/typography/opentype/spec/features_fj
  49. https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko
  50. https://learn.microsoft.com/en-us/typography/opentype/spec/features_ae
  51. http://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileSpecification.html
  52. https://github.com/adobe-type-tools/afdko
  53. http://help.fontlab.com/fontlab/7/manual/OpenType-Features/
  54. https://www.sketchpad.net/opentype-fonts.htm
  55. https://learn.microsoft.com/en-us/windows/win32/directwrite/introducing-directwrite
  56. https://developer.apple.com/documentation/coretext
  57. https://typographica.org/on-typography/grading-the-new-font-features-in-os-x-leopard/
  58. https://harfbuzz.github.io/
  59. https://github.com/harfbuzz/harfbuzz
  60. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_fonts/WOFF
  61. https://caniuse.com/variable-fonts
  62. https://stackoverflow.com/questions/17643455/use-opentype-font-features-in-android
  63. https://learn.microsoft.com/en-us/typography/opentype/spec/cpal
  64. https://learn.microsoft.com/en-us/typography/opentype/spec/svg
  65. https://learn.microsoft.com/en-us/typography/opentype/spec/cbdt
  66. https://learn.microsoft.com/en-us/typography/opentype/spec/cblc
  67. https://learn.microsoft.com/en-us/typography/opentype/spec/sbix
  68. https://developer.chrome.com/blog/colrv1-fonts
  69. https://blogs.windows.com/windowsdeveloper/2017/06/06/using-color-fonts-beautiful-text-icons/
  70. https://ccjktype.fonts.adobe.com/wp-content/uploads/2017/09/iuc32-lunde-s6t3-wp.pdf
  71. https://atadistance.net/wp-content/uploads/2015/10/tsr-0818_p4-7.pdf
  72. https://fonttools.readthedocs.io/en/latest/ttLib/tables/S_I_N_G_.html
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.