# Non standard extensions used FontForge in True/Open Type

## Non standard feature tags

Internal

- `' REQ'` -- tag used for required features

For TeX

- `ITLC` -- Italic correction
  I have proposed this as an extension to OpenType. There was some discussion of it, but I believe the idea died.
- `TCHL` -- TeX Charlist
- `TEXL` -- TeX Extension List

## Non standard tables.

- 'PfEd' the FontForge extensions table
- 'TeX ' the TeX metrics table
- 'BDF ' the BDF properties table

- (standard tables)

## 'PfEd' -- the FontForge extensions table

(the name is 'PfEd' for historical reasons)

> The table begins with a table header containing a version number and a count of sub-tables

> uint32 | version | currently 0x00010000
> uint32 | count |

> This is followed by a table of contents, there will be count replications of the following structure (ie. a tag and offset for each sub-table

> uint32 | tag |
> uint32 | offset | from start of 'PfEd' table

> The format of the subtable depends on the sub-table's tag. There are currently 3 tags supported, these are

> - 'colr' -- per glyph color sub-table (stores the color that appears in the font view)
> - 'cmnt' -- per glyph comment sub-table (stores the comment that appears in the Char Info dialog for the character)
> - 'fcmt' -- the font comment sub-table (stores the comment that appears in the Font Info dialog)

### 'colr' -- the per-glyph color sub-table

> The sub-table header begins with a version number, and a count of ranges

> uint16 | version | 0
> uint16 | count | of ranges

> After this will be <count> instances of the following structure

> uint16 | starting glyph index |
> uint16 | ending glyph index |
> uint32 | color | expressed as a 24bit rgb value

### 'cmnt' -- the per-glyph comment sub-table

> The sub-table header begins with a version number, and a count of ranges

> uint16 | version | 0
> uint16 | count | of ranges

> After this will be <count> instances of the following structure

> uint16 | starting glyph index |
> uint16 | ending glyph index |
> uint32 | offset | from the start of this sub-table

> The offset points to an array of offsets (<end>-<start>+1+1) elements in the array, so one element for each glyph index mentioned in the range structure above, with one left over which allows readers to compute the the length of the last string.

> uint32 | offset | from start of table
> | ... |

> And each of these offsets points to a unicode (UCS2) string. The strings are assumed to be consecutive, so the length of each may be calculated by subtracting its offset from the offset to the next string.

### 'fcmt' -- the font comment sub-table

> The sub-table header begins with a version number, and a count of ranges

> uint16 | version | 0
> uint16 | length | number of characters in the string

> And this is followed by <length> Unicode (UCS2) characters. Currently these unicode characters will always contain ASCII values, but that may change some day.

## 'TeX ' -- the TeX metrics table

> The table begins with a table header containing a version number and a count of sub-tables

> uint32 | version | currently 0x00010000
> uint32 | count |

> This is followed by a table of contents, there will be count replications of the following structure (ie. a tag and offset for each sub-table

> uint32 | tag |
> uint32 | offset | from start of 'PfEd' table

> The format of the subtable depends on the sub-table's tag. There are currently 3 tags supported, these are

> - 'ftpm' -- the font parameter table
> - 'htdp' -- per glyph height/depth sub-table (stores TeX's idea of the height and depth of glyphs (should correct for optical overshoot))
> - 'sbsp' -- per glyph sub/super-script sub-table

### 'htdp' -- the per-glyph color sub-table

> The sub-table header begins with a version number, and a count of glyphs

> uint16 | version | 0
> uint16 | count | of glyphs

> After this will be <count> instances of the following structure

> uint16 | height | in em-units
> uint16 | depth |

I store these values in em-units rather than in the fix_word of a tfm file because em-units make more sense in a sfnt and take up less space.

### 'sbsp' -- the per-glyph sub/super-script sub-table

> This sub-table has essentially the same format as the previous one. The sub-table header begins with a version number, and a count of glyphs

> uint16 | version | 0
> uint16 | count | of glyphs

> After this will be <count> instances of the following structure

> uint16 | subscript offset | in em-units
> uint16 | superscript offset |

I store these values in em-units rather than in the fix_word of a tfm file because em-units make more sense in a sfnt and take up less space.

### 'ftpm' -- the font parameter (font dimensions) sub-table

> The sub-table header begins with a version number, and a count of parameters

> uint16 | version | 0
> uint16 | count | number of parameters in the font

> And this is followed by <count> instances of the following structure:

> uint32 | tag | parameter name
> int32 | value |

> I store these values as fix_words and not as em-units because their meaning is not constrained by the spec and the `Slant` parameter (at the least) can not be converted to em-units.

> I have defined the following 4-letter parameter tags

> Tag | Meaning | traditional font parameter number in tfm file (font dimension number)
> --- | --- | ---
> Slnt | Slant | 1
> Spac | Space | 2
> Stre | Stretch | 3
> Shnk | Shrink | 4
> XHgt | XHeight | 5
> Quad | Quad | 6
> ExSp | Extra Space | 7 (in text fonts)
> MtSp | Math Space | 7 (in math and math extension fonts)
> Num1 | Num1 | 8 (in math fonts)
> Num2 | Num2 | 9
> Num3 | Num2 | 10
> Dnm1 | Denom1 | 11
> Dnm2 | Denom2 | 12
> Sup1 | Sup1 | 13
> Sup2 | Sup2 | 14
> Sup3 | Sup3 | 15
> Sub1 | Sub1 | 16
> Sub2 | Sub2 | 17
> SpDp | Sup Drop | 18
> SbDp | Sub Drop | 19
> Dlm1 | Delim 1 | 20
> Dlm2 | Delim 2 | 21
> AxHt | Axis height | 22
> RlTk | Default Rule Thickness | 8 (in math extension fonts)
> BOS1 | Big Op Spacing1 | 9
> BOS2 | Big Op Spacing2 | 10
> BOS3 | Big Op Spacing3 | 11
> BOS4 | Big Op Spacing4 | 12
> BOS5 | Big Op Spacing5 | 13

## 'BDF ' -- the BDF properties table

> The table begins with a table header containing a version number and a count of strikes

> uint16 | version | currently 0x0001
> uint16 | strike-count |
> uint32 | offset to string table | (from start of BDF table)

> This is followed by an entry for each strike identifying how many properties that strike has.

> uint16 | ppem |
> uint16 | property-count |

> Then there will be the properties, first there with be property-count[1] properties from the first strike, then property-count[2] properties for the second, etc. Each property looks like:

> uint32 | name | offset into the string table of the property's name
> uint16 | type | 0=>string 1=>atom 2=>int 3=>uint 0x10 may be ored into one of the above types to indicate a real property
> uint32 | value | For strings and atoms, this is an offset into the string table for integers it is the value itself

> The string table is a series of ASCII bytes. Each string is NUL terminated.