Enabling Typography

This is an updated version of an article originally written in April 2014 as a contribution to discussions around shaping engines and text layout. This led to the first of what became a series of meetings of an ad hoc working group collaborating on improvements to the OpenType specification between 2014 and 2019. This new version of the article has been updated to include OTL features registered since 2014 in relevant tables, a number of small textual additions or revisions, and a replacement of the original concluding section on topographical features.

When the OpenType font format and Layout model were introduced by Microsoft and Adobe in the second half of the 1990s, there was a perceptible difference in the priorities of the two companies: respectively, complex script shaping and typographic design support. This found expression in the initial set of OpenType Layout (OTL) features registered by each company, and in the priorities adopted in the implementation of OTL in each’s software. So, for example, Microsoft registered features and implemented support for Arabic and Indic script shaping, but was slow to implement support for typographic features for European scripts, such as ligatures and smallcaps, while Adobe registered and supported features for many typographic refinements for European and East Asian scripts, but was slow to enable complex script shaping or even some kinds of OTL lookup types.

In this paper—which is intended to provoke discussion and action, not to provide a fully realised solution to all issues—, I will attempt to suggest a path towards better integration of script and language shaping with full typographic sophistication, via a general model of OpenType Layout. Such a model is complicated in some aspects by the existing feature set, which has been registered and supported in an ad hoc manner without a unified guiding principle such as this general model seeks, belatedly, to apply. It is easy to conceive of entirely fresh sets of features and layout behaviours based on a strict set of architectural principles—e.g. by making a systematic distinction between required, default and discretionary settings for any feature—but that is not what this paper seeks to do. For better or for worse, we have an existing set of features, significant investment in their implementation, and existing documents in need of ongoing support. It is from this position that I begin.

In its broadest sense, I understand typography to be the articulation of text through the design and arrangement of type. This means that typography is concerned with all aspects of text, from the shape of individual characters and their immediate interaction within words, up to the design of whole documents, publication series, or dynamic text presentation systems. In this paper, I am primarily concerned with what is sometimes referred to as microtypography.¹ At this level, typography is concerned primarily with the relationships of visually adjacent typeforms; note, however, that due to required reordering, the presence of combining marks, or the nature of the shapes involved, these may not be sequentially adjacent in either the encoded character string or the glyph run). It is this level of typography that is—or should be—directly addressable via OpenType Layout, either automatically in the case of required or default features, or as directed by the typographer.

The results of typography are integrated: all the parts contributing together to the reader’s experience of the text. The process of typography, though, is disintegrated. Not only does the process of displaying text involve multiple, more-or-less distinct stages, but in today’s digital typography these stages are handled by several different technologies, with collective responsibility for the results shared by operating systems, layout engines, applications and fonts.² Optimally, these technologies work together and support each other; when this fails, though, they may actively work against each other, leading to attempts to work around limitations or bugs in one part of the system elsewhere. This, predictably, results in incompatibilities, requiring yet further workarounds.

OpenType Layout, it has to be said, is not a tidy technology. It requires that three separate pieces of software, often made by three separate entities, work seamlessly together, and that they do so without any formal specification beyond that of the font format. There has never been documentation that tells a shaping engine or application developer how to implement OTL or how, through that implementation, to enable typography. Instead, there is a mix of script-specific shaping documentation for some complex writing systems, and the de facto behaviour norms established by particular shaping engine implementations and fonts, reverse-engineered by other parties with an eye on compatible outcomes rather than identical procedures. One result of this is that problems in particular layout engines or fonts will proliferate without correction to others, especially if they are seen as de facto standards. Another result is that software developers responsible for supporting specific writing systems, referring to the particular and partial script shaping documentation, will tend to ignore those aspects of OTL beyond that documentation, overlooking the fact that script and language shaping is not an end in itself: it is preparation for typography.

The initial implementation of OTL for Indic writing systems—still affecting some environments and feature sets—presents an unfortunate example of both these results. Focus on the orthographic cluster as the necessary unit of script and language shaping resulted in failure to enable interaction between the clusters: interaction that is necessary to crucial aspects of micro-typography including substitution of appropriate contextual forms and spacing adjustments to avoid gaps or collisions between adjacent shapes. The failure of Microsoft’s original Uniscribe layout engine to apply cross-cluster lookups resulted in other shaping engine makers including the same limitation in their own software, or put them under pressure to make their software compatible with the outcomes of Uniscribe, even if their own outcomes are typographically preferable.

In order to enable typography to a consistent level for all scripts and languages, a number of things are desirable. Perhaps most challenging, a typographic mentality needs to be inculcated in all areas of software development affecting the display of text, such that program managers, developers and testers recognise that the purpose of OpenType Layout is typography. The existing implementations of OTL, especially at the script-specific layout engine level, need to be reviewed and behaviour that limits or prevents typography needs to be identified and fixed, even if this means changes to behaviour that might affect backwards compatibility.³ And a more systematic and better documented approach to future OTL implementation needs to be adopted, especially for newly supported scripts and languages so that problems that have afflicted development so far are not repeated.

I believe all of these initiatives, and others, would benefit from greater collaboration between interested parties, including through standards organisations and open-sourcing of key components. There was a period, during the early years of OpenType, and during development of core support for major writing systems and languages in operating systems and applications, when it made sense for companies to treat text processing and display as an area of competition. I believe that time has past. The focus of new text processing is increasingly on minority and historical scripts and languages, for which competitive business cases will be harder and harder to make. The inconsistencies and incompatibilities in levels of support and behaviours that have resulted from two decades of competition in this area are sources of frustration to users and, it must be said, to font developers.

The specification of a general model for OpenType Layout, applicable to all writing systems, would have been made easier by consistent categorisation of each registered feature with regard to its role in orthographic shaping and typographic layout (and hence what limitations might apply to the feature with regard to orthographic units of a given writing system). Instead, some features apply to orthographic unit shaping for some writing systems and to typographic layout for others. This is notably the case for the features that applying joining behaviour—<isol> <init> <medi> <fina>—, which not only have varying roles for different writing systems but also apply to varying elements of the text.

This being the case, some special exceptions to a general categorisation of existing features is unavoidable. With which caveat in mind, I propose the following as a general model for applying features to text:

1. Default glyph pre-processing. This stage directly modifies the outcome of character-to-glyph mapping from the font cmap table. This may involve language-specific preferred glyph substitutions triggered by the OT language system tag⁴ and implemented in the <locl> or character set specific layout feature. It may involve composition or decomposition of cmap-output default glyph representations into more convenient glyphs for subsequent processing, using the <ccmp> layout feature.⁵ Since 2016, default glyph pre-processing also includes initial design space substitutions in variable fonts (subsequent design space substitutions may be applied at any stage of the OTL glyph processing). Note that while <locl> substitutions are unlikely to be contextual, it should not be presumed that they will never be, and <ccmp> substitutions are very likely to be contextual if they, for instance, perform decompositions of precomposed diacritic glyphs only in the context of following combining marks. I believe this stage is probably the most logical place to also handle mirrored form substitutions for bidirectional text.
2. Orthographic unit shaping. This applies particularly to complex scripts requiring interaction between character string analysis and specific glyph substitution features. In some cases this interaction may be iterative, involving reordering of output from features within the glyph run, and then application of additional features. This is the core work of script shaping, in preparation for the application of typographic features. This stage broadly corresponds to what Microsoft’s script specifications refer to variously as ​‘Basic shaping forms’ and ​‘Language based forms’, but with the difference that it seeks to limit the features involved to those that must be applied to analysed units of writing systems and never involve interaction between those units. The unit in question will vary depending on the writing system: e.g. orthographic syllables or ​‘clusters’ for Brahmi-derived scripts, or letter groups defined by character joining behaviours for scripts such as Arabic. This kind of shaping is, obviously, most important when application of individual features results in outcomes that require glyph re-ordering by the shaping engine within the orthographic unit, when clearly defining the beginning and end of the unit is essential to correct outcomes. Individual features in this stage must be applied sequentially and typically in a specific order. Note that although lookups for these features should not include inter-unit contextual triggers, and any such should be ignored, intra-unit context strings may occur and should be respected (examples of the latter would be varying <pref> and <blwf> shaping of Telugu ‑ra depending on preceding letter(s), or disabling some Malayalam ligatures in the <akhn> feature depending on position within longer conjunct sequences). After orthographic unit shaping is completed, all restrictions particular to the length of the unit should be relaxed and no longer applied to subsequent features.
3. Typographic presentation. For ease of discussion, I am separating this stage into two parts, but it is important to note that features applied in this stage should be considered to apply simultaneously; that is, the order of substitutions, their outcomes and interactions should be governed by the order of associated lookups in the font. This order may involve standard and discretionary feature lookups being staggered, such that the outcomes of some standard features may be affected by the application of discretionary features.
   1. Standard typographic presentation. For some writing systems, this includes what Microsoft’s Indic specifications call ​‘Mandatory presentation forms’, but it also inherits substitution features that some of Microsoft’s specifications classify with ​‘Basic shaping forms’, but which do not fit in the proposed orthographic unit shaping stage because they may involve inter-unit interaction. The purpose of this stage is to arrive at a typical standard of text presentation according to the typographic norms of the writing system, the nature of the individual typeface design, and the capability of the individual font. This means that this stage involves both required layout features that must always be applied, such as <rlig>, and default or standard features that should be applied but that the user may opt to turn off, such as <liga>. It should be obvious by now, I hope, that no restriction should be placed on the extent of interactions between glyphs in these features.⁶
   2. Discretionary typographic presentation. All these features are presumed to be inactive by default, and need to be turned on by the user for selected text (this might be through an application UI, or via feature tagging of text as in the case of CSS).
4. Positioning. Although not formally required, it typically makes sense for positioning feature lookups to be ordered in a font according to lookup type, which can also be arrived at by thinking of a progression from positioning of connecting base forms, to non-connecting base forms, to marks relative to base forms, to marks relative to marks. Presuming the font maker has succeeded in getting the GPOS table to compile without overruns—not always the easiest thing—, software should apply the lookups as ordered in the font. Since many aspects of positioning are concerned with resolving relationships of visual adjacency, it is particularly important that restrictions not be placed on inter-unit interaction or context length during this stage. For many writing systems, it is necessary to affect contextual kerning or adjustments to mark positioning based on visually but not sequentially adjacent glyphs. This is only possible if lookup contexts are tracked across orthographic unit boundaries.

One thing that should be immediately apparent from this model is that it is progressive: features set up conditions for subsequent features. The process of OpenType Layout is not complete until the full progression of stages and their relevant features has been gone through and the desired typographic result achieved.

The tables that follow attempt to categorise and group the current set of registered OTL feature tags according to this model. This should be considered preliminary work, subject to review; critically, this is not a description of any specific shaping engine, although the Universal Shaping Engine model is close to what is described here. Although some features are grouped together as ​‘Positioning’, based on typical implementation, some of these could be implemented used glyph substitutions rather than GPOS lookups. Similarly, some typically GSUB features potentially have GPOS implementations.

The fourth column in the tables indicates recommended default state of the feature:
1/​0 = on by default and cannot be turned off;
1/​1 = on by default, but can be turned off;
0/​1 = off by default but can be turned on.

Especially observant readers will have noticed that two registered features are not included in these tables: <aalt> Access All Alternates, and <size> Optical Size. The <aalt> feature is an access mechanism for presenting glyph variants in a user interface, so is not expected to be applied to text as part of layout. The <size> feature is a frankly ill-considered hijacking of GPOS data structure to record the size range for which a given type design is intended. If it were implemented at all within the context of text layout, it would occupy a stage 0 (zero) affecting the selection of a particular font within a family before OpenType Layout proper is applied. Other, methods for size-specific design selection are available—notably the variable opsz axis and associated STAT table addition to the OT format—, and the <size> feature may be best deprecated.

The original version of this paper concluded with a discussion of four features—<isol> <init> <medi> and <fina>—that were then described in the registry as being applied based on a character’s position in a word, and which I hence labeled ​‘topographic’ features. That conclusion is preserved below as an appendix to this updated paper. It was superseded by revisions I proposed to the description of those features in the registry, which now accurately reflect how those features are applied by shaping engines: not topographically, but based on Unicode joining properties, i.e. applied according to the properties of adjacent characters, not on position within a word.

So, how best now to conclude this paper? Nearly eleven years after it was first published, there have been improvements in the enabling of typography for many scripts in many kinds of software, but these seem piecemeal and incidental, rather than representing the application of a general model equally to all writing systems. Notably, Adobe’s main Creative Cloud applications now use the HarfBuzz shaping engine for complex scripts, greatly extending the quantity of languages in which texts can be composed and also improving consistency of typographic results with other software using HarfBuzz. Microsoft and Apple continue to employ their own shaping engines in Direct Write and Core Text environments, respectively, and inconsistencies persist for some writing systems, frustrating both font makers and users. Remarkably, almost thirty years after the launch of OpenType and forty years after the beginning of the Unicode project, some new software continues to be brought to market that fails to support non-European typography or even basic shaping of complex scripts, despite the availability of system or open-source libraries.

There is still no formal implementation specification for OpenType Layout. Likewise, we still lack a common, public algorithm for the crucial pre-shaping steps of script itemisation and run segmentation. Post-shaping, we have no standardised mechanisms for application of glyph processing in the context of line-breaking and justification. It seems to me that development of these things would be a good way to celebrate the upcoming 30th anniversary of the font format, and to fulfill the promise of enabling typography for all the world’s writing cultures.

John Hudson, 10 February 2025

_​_​_​_​_​_​_​_​_​_​

This is the concluding section of the original version of this paper, which was made substantially redundant in part as an outcome of this paper. It is preserved here for historical interest, and as an example of how systematic review of the workings of text processing can usefully lead to clarification of the formal specification for that processing. The layout features discussed here are now—with the legacy exception of word-initial Bengali vowel signs—defined in terms of application of Unicode character joining properties. This removes the ambiguity between joining and topographical behaviour, the latter currently addressable only at the contextual lookup level within other features.

I’m going to conclude by considering a notable special case among the OTL features: the <isol> <init> <medi> and <fina> topographical features⁷ that substitute appropriate glyph variants based on location. In addition to these, there are three specifically Syriac topographical features used in orthographic unit shaping for that script, and several of the Indic orthographic unit shaping features are also of a topographical nature but not relevant to this discussion. The existence of script-specific topographical features for Syriac, though used in concert with the generic set, indicates a decision that could have been made in the design of OpenType Layout that would have avoided ambiguity about the role and application of the topographical features. It would have been possible to define a set of such features specifically for orthographic unit shaping of scripts with inherent joining behaviours defined in Unicode, such as Syriac, Arabic, Mongolian, etc., and for this to be separate from typographic presentation of topographical glyph variants that are a design element of particular typefaces rather than an aspect of a writing system. Instead, we currently have a set of features that are used for orthographic shaping for some writing systems and for typographic presentation for others, and which, more confusingly, apply to different topographies depending on the writing system (lettergroups in the case of joining scripts, words in the case of others, and presumably phrases if applied to a script such as Thai that does not visually break individual words).

There are a number of options for how topographical substitutions could be handled, moving forwards. One option is simply to continue to live with this dual use, but to better define the expected behaviour and proper application of the feature for various writing systems. The goal in that case would be to make clear that in a typographic presentation context these features may apply to any writing system, and will be appropriate to particular styles or individual typeface designs. The features may be used, for instance, for the Latin writing system in cursive ​‘script’ style typefaces; while the <init> feature is currently spec’d by Microsoft for ​‘mandatory presentation forms’ in the Bengali writing system, <fina> or other topographic substitutions would be appropriate to some letters in some styles of Bengali type.

The limitation of this option is that it enforces a distinction at the feature level between different topographies for different writing systems, which in effect means that word-level topographies—as distinct from lettergroup topographies—are not accessible to writing systems with standardised joining behaviours defined in Unicode. So, for example, application of the existing features to the Arabic writing system is based on joining behaviour analysis and hence lettergroup topography, meaning that there is no way to specifically address and substitute initial or final word glyphs in Arabic typeface designs.

This suggests another option, which is to register a new set of specifically typographic presentation features for word-topographic substitutions, to be applied after orthographic unit shaping and independently of substitutions determined by joining behaviour. Once this is considered, features for other topographies suggest themselves: first glyph on line, for example, or even page or text block topographies enabling, for instance, taller display glyphs on the top line and deeper ones on the bottom line, as seen in many manuscript traditions. This begins to move the discussion in the direction of new features and alternative layout models, so seems a good place to end this paper.