Advanced Typography Tables

These differ between OpenType (originally called TrueType Open) and Apple (GX or Apple Advanced Typography). My support for Apple is minimal as yet. My support for OpenType is not complete.

The GPOS, GSUB and GDEF opentype tables

These two tables are used for positioning and substituting glyphs. The GPOS table can control things like: kerning, accent positioning, cursive joining, etc. The GSUB table can control things like: ligatures, arabic forms, vertical rotation, conversion to small caps, indic glyph rearrangement, etc.

This page assumes basic familiarity with the abilities of the tables, for more information on them read, study and inwardly digest the opentype docs on:

The basic idea of the GPOS and GSUB tables is that each script (or language within a script) has a set of "features" that are available to it. A feature in turn is associated with a lookup which contains data for the feature. An example of a script is 'latn' for latin, 'arab' for arabic, 'hani' for chinese ideographs. Two examples of features are 'kern' which provides kerning information between pairs of glyphs and 'init' which will transform one set of glyphs to another when those glyphs are at the beginning of a word.

PfaEdit does not support the full range of possibilities inherent in these tables.

The GPOS table

PfaEdit will read the following sub tables of the GPOS table:
name Reading support Writing support
1 single adjustment This sub-table allows the font designer to change the metrics of a specific character. The feature tag will provide a context in which the change should occur. For instance the 'tnum' (tabular numbers) feature could change a proportionally spaced digit by adjusting its advance width to be some set value and then centering the digit (by adjusting the left side bearing) within the new width. These can be created with the Element->Char Info->Position command.
2 pair adjustment This sub-table allows the font designer to change the metrics of a specific pair of character. The most common use of this is for kerning where the advance width of the first character is altered depending on which character follows it. But the table is more general than that and could support mark (accent, vowel) positioning over a base character (though that is more efficiently done with the mark to base subtable). 'kern' feature s may be created from the Metrics View. 'vkrn' with Metrics->VKern From HKern.
3 cursive attachment This sub-table allows the font designer to force adjacent characters to join at specific points. It can be used to generate the slanted script style needed for Urdu. Only the 'curs' feature is supported for this sub-table. These may be created with the Points->Add Anchor command
4 mark to base This sub-table allows the font designer to specify how mark characters (accents, vowel signs, etc.) are positioned over base characters. Every character can have an attachment point and the mark's attachment point will be placed on the base's attachment point so the two join properly. See my example in the overview. These may be created with the Points->Add Anchor command
5 mark to ligature This sub-table is very similar to the previous one except that the base character is a ligature and may have several different points at which the same type of accent may be placed. These may be created with the Points->Add Anchor command
6 mark to mark This sub-table is very similar to the previous two except that the base character is itself a mark. This may be used when a character has two accents each of which would normally be placed at the same attachment point on a base character. The second accent will be place relative to the first accent rather than to the base character. These may be created with the Points->Add Anchor command
7 contextual positioning This sub-table allows the font designer to control the positioning of characters when they occur within a specific string (or class of strings). For instance this table could say "when you see a digit followed by the string "th" then raise the "th" into a superscript position" These may be created with the Element->Font Info->Contextual command
8 chaining contextual positioning This is a slightly more complex version of the above, it doesn't really add new capabilities, but it does provide a more logical approach to the issue. These may be created with the Element->Font Info->Contextual command
9 extension positioning This is used to allow for a GPOS table which is bigger than 64k. Its use should be quite invisible to the font designer PfaEdit uses this sub-table when needed.
10+ reserved for future use PfaEdit does not support these sub-tables yet.
(nor does anyone)

PfaEdit also has built into it knowledge on how to provide default values for some features that use these tables. See Element->Default ATT command for that.

PfaEdit will retain the order of features in the GPOS table and when a font is generated the order should be the same as it was before.

The GSUB table

PfaEdit will read the following sub tables of the GSUB table:
name Reading support Writing support
1 single substitution This sub-table allows the font designer to change from one glyph to another, with a context provided by the feature tag. For example many scripts have letters which have a different form at the end of a word than they do within (this is true of every letter in arabic, several in hebrew, lower case sigma in greek, and the long-s/short-s pair in renaissance latin). So the 'fina' feature would map the normal form into the final form, and the word processing program would do a lookup at the end of each word to see if a transformation was needed. These can be created with the Element->Char Info->Substitution command.
2 multiple substitution This sub-table allows the font designer to replace one glyph by a series of others. This is generally used for rather technical layout issues. These can be created with the Element->Char Info->Multiple Substitution command.
3 alternate substitution This sub-table allows the font designer to have a series of "alternates" for each glyph. One common example would be an italic font which had several swash variants for each capital letter. The word processing program would allow the user to choose which variant was appropriate These can be created with the Element->Char Info->Alternate Substitution command.
4 ligature substitution This sub-table allows the font designer to replace a string of characters with another glyph. A common example is a ligature where the string is replaced by the ligature. These can be created with the Element->Char Info->Ligature command.
5 contextual substitution This subtable allows for a string of glyphs to replace another string of glyphs (or class of strings of glyphs) These may be created with the Element->Font Info->Contextual command
6 chaining contextual substitution This is a slightly more complex version of the above, it doesn't really add new capabilities, but it does provide a more logical approach to the issue. These may be created with the Element->Font Info->Contextual command
7 extension positioning This is used to allow for a GSUB table which is bigger than 64k. Its use should be quite invisible to the font designer PfaEdit uses this sub-table when needed.
8 reverse chaining contextual single substitution This allows glyph substitutions to happen in reverse order, and it a varient of the chaining contextual subtable. These may be created with the Element->Font Info->Contextual command
9+ reserved for future use PfaEdit does not support these sub-tables yet.
(nor does anyone)

PfaEdit also has built into it knowledge on how to provide default values for some features that use these tables. See Element->Default ATT command for that.

PfaEdit can produce some of these tables, but the text layout/word processing program used has to look up the tables and do the actual work of rearranging the glyphs.

PfaEdit will retain the order of features in the GSUB table, and the user may adjust it with the Element->Font Info command.

The GDEF table

PfaEdit will read ligature carets out of a GDEF table.

It will generate a GDEF table containing a glyph class definition sub-table (if needed) or a ligature caret sub-table (if needed).

Apple Advanced Typography

As above I do not go deeply into the abilities of these tables, for more information see Apple's docs:

PfaEdit will current read and produce (if Apple mode is set in font generation) the following tables:
Apple tables corresponding vaguely to GDEF
tag name Reading support Writing support
'lcar' ligature caret table PfaEdit will read ligature carets PfaEdit will produce this table if the user has specified ligature carets
'prop' glyph properties table PfaEdit will read this table to figure out which glyphs are hebrew and arabic, and which have 'r2la' substitutions. PfaEdit will generate this table if the font contains some right to left characters.

Apple tables corresponding vaguely to GPOS
tag name Reading support Writing support
'kern' kerning table PfaEdit will read horizontal/vertical kerning pairs and classes. PfaEdit will produce this if the font contains kerning data
'opbd' Optical bounds table PfaEdit will read optical bounds PfaEdit will produce this table if the user has specified right and left bounds as simple positions ('lfbd' and 'rtbd').

PfaEdit has minimal support now for the 'mort' and 'morx' tables (Glyph metamorphosis and extended glyph metamorphosis tables). These correspond vaguely to the GSUB table. Note: Currently only feature type/setting combinations which correspond directly to an open type feature are saved (use File->Preferences to extend PfaEdit's mapping from feature type/setting to opentype tags).
Sub tables of 'mort' or 'morx' currently supported
name Reading support Writing support
0 Indic style rearrangement Not supported Not supported
1 contextual glyph substitution Not supported PfaEdit will generate a cursive connection feature using this subtable type if the font contains 'init', 'medi', 'fina' or 'isol' simple substitutions.

In some cases PfaEdit is able to convert an OpenType Contextual/Chaining substitution table into an Apple contextual glyph substitution table.

2 ligature substitution PfaEdit can read these and stores them as opentype ligatures. PfaEdit will ignore any contextual information. PfaEdit will output this sub-table if the font contains supported ligatures.
4 non-contextual glyph substitution PfaEdit can read these and stores them as opentype simple substitutions PfaEdit will output this sub-table if the font contains supported substitutions.
5 contextual glyph insertion Not supported Not supported

Why do contextual substitutions only sometimes get generated in AAT?

Sadly OpenType and AAT provide disjoint capabilities when it comes to contextual matching. AAT is more capable in some areas, OpenType more capable in others. PfaEdit is able to convert an OpenType contextual substitution into an AAT if PfaEdit can detect that the OpenType substitution does not use capabilies beyond those of AAT. Currently this means:

PfaEdit does not even try to parse an AAT contextual glyph substitution sub-table, too few of these can be expressed in OpenType to make it worth while.

BUG

There is a subtle bug involved in converting a chaining contextual substitution into an Apple contextual glyph substitution. AAT does not have the concept of a backtrack list. This means that the substitution will start with the first character of the backtrack list, which means that any substitutions that may already have happened (to the glyphs on the backtrack list) on an opentype platform will not have happened on a Mac.

Example:

Suppose we have a simple substitution
  { r => r.alt }
and a chaining substitution
  { a r.alt [b] => {b => b.alt}}
(where "a" and "r.alt" are on the backtrack list, and "b" is the match string)
On an opentype platform this will work as expected because by the time the current character becomes "b" and the substitution starts we will already have changed "r" into "r.alt", but on the Mac the substitution will start at glyph "a" and the { r => r.alt } will not yet have executed and the match will fail.

Why can't all contextual/chaining tables be converted?

Well, obviously there are some thing that just aren't present. The concept of contextual positioning is missing from AAT, while Indic rearrangement is missing from OpenType. So let's concentrate on contextual substitutions, which both appear to support. But even here, there is a very basic mismatch in concepts between the way OpenType and Apple specify contextual substitutions. Consider the following contextual sustitution in a glyph list format:
Initial Sequence a b c d
Replace With   B C  

Now in OpenType this means if you find the sequence "abcd" then replace the "b" with "B" and the "c" with "C". But this can't be expressed in an Apple state machine. In OpenType the match is done first, and then the substitutions occur. In a state machine the sustitutions have to be done (almost) concurrently with the match and so must happen whether the final "d" is present or not.

Consider the following table with two glyph strings
Initial Sequence a

b

c

d
Replace With  

B

 
Initial Sequence a

b

c

Replace With  

 C

 

So replace the "b" if the final "d" is present, otherwise replace the "c". Again this cannot be expressed in Apple's state machines.


On the other hand, Apple's state machines can express things that OpenType tables cannot (again I'm restricting myself to contextual substitutions). Consider the case of a swash character at the begining (or end) of a word. Let us say that a word begins when a letter appears at the start of input or following a whitespace character. But OpenType has no way of expressing "start of input" (or end of input) in a contextual/chaining context, whereas Apple's state machines do.

Finally a state machine can match a general regular expression, while OpenType tables can only match fixed length strings. Suppose you were typesetting mathematics and wanted a substitution which would convert an arbetrary digit string following a variable into a subscript (so x23 should become x23). It is easy to write a state machine which will keep substituting as long as it gets more digits, but you'd need an infinite number of OpenType rules to have the same expressive power.

These examples probably seem fairly contrived, and (except for the swash one) they are. But they illustrate the point that the two formats have very different expressive capabilities and it is NOT possible to write a converter which will take any input in one format and produce an equivalent output in the other.

Musings on other 'morx' sub-table types

Some very simple cases of Indic positioning can be expressed with a contextual kerning table (ie. instead of swapping the glyphs in the internal sequence, you could kern them so far that they moved past each other).

Conditional glyph insertion could be done with an OpenType contextual table and a multiple substitution.

Apple and OpenType features

Correspondences between Apple and OpenType features
(that I support)
Apple Feature Setting OpenType Feature Name OpenType Tag
Required Ligatures Required Ligatures rlig
Common Ligatures Standard Ligatures liga
Rare Ligatures Discretionary/Historic Ligs. dlig/hlig
Logo Ligatures MLOG*
Rebus Pictures MREB*
Diphthong Ligatures MDLG*
Square Ligatures MSLG*
Abbrev. Square Ligatures MALG*
Fractions Fractions frac

Contextual Alternatives Cursive connection calt

Vertical Forms Vertical Rotation 2 vrt2
Monospace numbers Tabular numbers tnum
Superscript Superscript sups
Subscript Subscript subs
Proportional Text Proportional Widths pwid
Half-width Text Half Width hwid
Full-width Text Full Width fwid
Traditional Characters Traditional trad
Simplified Characters Simplified smpl
JIS 1978 Characters JIS 1978 Characters jp78
JIS 1983 Characters JIS 1983 Characters jp83
JIS 1990 Characters JIS 1990 Characters jp90

* Tags which are entirely in upper case have been added by me. They do not correspond to any known opentype tag, and are used solely for supporting macintoys. You may adjust this conversion table (by adding your own tags for various mac feature/settings) from the preference dialog.

PfaEdit will retain the order of features in the morx table, and the user may adjust it with the Element->Font Info command. (this is the same list as that used for GSUB table. GSUB features that don't correspond to mac features will be ignored).

What is Unsupported?

PfaEdit does not (yet) support all the advanced typographic features available in either opentype or apple advanced typography.

OpenType

See here for a complete list of supported tables.

Apple Advanced Typography

See here for a complete list of supported tables.

-- Prev -- TOC -- Next --