Non standard extensions used FontForge in True/Open Type¶

Non standard feature tags¶

Internal

' REQ' – tag used for required features

For TeX

I no longer use these. MS has come up with a MATH table which can contain all the TeX information.

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

(standard tables)

Non standard file formats

Bitmap only sfnt for MS Windows

‘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)

‘flog’ – the font log sub-table (looks just like the ‘fcmt’ subtable)

‘cvtc’ – the cvt comments subtable

‘GPOS’ – Save lookup, lookup subtable and anchor class names of GPOS lookups

‘GSUB’ – Save lookup and lookup subtable names of GSUB lookups

‘guid’ – Save guideline locations

‘layr’ – Save background and spiro layers

‘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/1

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 length of the last string.

uint32

offset

from start of table

…

And each of these offsets points to a unicode (UCS2 for version 0, UTF-8 for version 1) 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 (and FONTLOG) sub-table¶

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

uint16

version

0/1

uint16

length

number of characters in the string

In version 0 this is followed by <length> Unicode (UCS2) characters. In version 1 it is followed by <length> bytes in utf8 encoding.

‘cvtc’ – the cvt comments sub-table¶

The sub-table header begins with a version number, and a count of cvt entries which might have comments

uint16

version

0

uint16

count

number of entries in the cvt comments array

which might be smaller than the number of entries in the cvt array itself if we want to save space

uint16

offset[count]

offsets to the start of utf8-encoded, NUL terminated strings. Or 0 if this cvt entry has no comment

‘GPOS/GSUB’ – lookup names¶

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

uint16

version

0

uint16

count

of lookups in this table

Then there will be an array of count elements (one for each lookup, ordered as the lookups are in the GPOS or GSUB table)

uint16

offset

to lookup name

uint16

offset

to lookup subtable structure

These offsets are based on the start of the subtable. The name offset points to a NUL terminated UTF-8 encoded string. The subtable offset points to the following structure:

uint16

count

of lookup subtables in this lookup

Then there will be an array of count elements (one for each subtable, ordered as the subtables are in the lookup of the GPOS or GSUB table)

uint16

offset

to lookup subtable name

uint16

offset

to anchor class structure

These offsets are also based on the start of the subtable. The name offset points to a NUL terminated UTF-8 encoded string. The anchor offset may be 0 if this subtable doesn’t have any anchor classes, otherwise it points to the following structure:

uint16

count

of anchor classes in this lookupsubtable

Then there will be an array of count elements (one for each anchor class)

uint16

offset

to anchor class name

‘guid’ – guidelines¶

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

uint16

version

1

uint16

vcount

number of vertical guidelines

uint16

hcount

number of horizontal guidelines

uint16

mbz

At some point this may contain info on diagonal guidelines. For now it is undefined

uint16

offset

To a full description of the guideline layer

I provide the guidelines in two formats. Either may be omitted. The first format simply describes the horizontal and vertical lines used as guidelines. The second format provides a full description of all contours (curved, straight, horizontal or diagonal) which fontforge uses. I provide both since most apps seem to have a simpler guideline layer than ff does.

This table is followed by two arrays, one for vertical guidelines, one for horizontal guides. Both arrays have the same element type (except that the position is for a different coordinate in the horizontal/vertical cases)

int16

position

x location of vertical guides, y location of horizontal ones

uint16

offset

to name, a NUL terminated utf8 string. (offset may be 0 if guideline is unnamed).

The offset to the guideline layer points to a variable length structure which is also used in the ‘layr’ subtable

‘glyph-layer’ – Data structure representing all the contours of a layer of a glyph “””””

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

uint16

count

of contours

uint16

count

of references (not present in version 0 layers)

uint16

mbz

reserved for a count of images

This is followed by an array of structures describing each contour

uint16

offset

to start of contour data

uint16

offset

to a name for the contour, a utf8, NUL terminated string (or 0 if the contour is unnamed)

All offsets from the start of the glyph-layer structure.

This is followed by an array of structures describing each reference

fixed16.16

transform[6]

A PostScript transformation matrix where each member is a signed 4 byte integers which should be divided by 32768.0 to allow for non-integral values

uint16

gid

The Glyph ID of the glyph being referred to

Contour data live in a variable length block. It’s basic idea is that it is a list of <command>, <data> pairs. Each command is a byte which consists of two parts, a verb which specifies what happens (and how many items of data are needed) and a modifier which specifies how each data item is represented. The verbs are postscript-like drawing operations: moveto, lineto, curveto, (and quadratic curveto), close path, etc. There are also separate verbs for specifying spiro control points – these are just the standard spiro type bytes (‘v’, ‘o’, ‘c’, ‘[’ and ‘]’), no modifier is applied to the spiro commands, their data are always 2 coordinates in fixed notation.

The low order two bits of the command (except for the spiro and close commands) specify the data format:

0

signed byte data for values -128 to 127

1

signed short data for values -32768 to 32767

2

A signed 4 byte integer which should be divided by 256.0 for non-integral coordinates (or for big ones)

3

Undefined and erroneous for now

Each command will start at the current point and draw to the point specified by its data. The data are relative to the last point specified (except for moveto, which is absolute, there being on previous point).

The verb may be one of the following:

0

MoveTo, takes 2 coordinates (x,y). This must begin each contour and may not appear elsewhere within it

4

LineTo, also takes 2 coordinates

8

HLineTo, draws a horizontal line, so only the new x coordinate need be specified.

12

VLineTo, draws a vertical line, so only the new y coordinate need be specified.

16

QCurveTo, takes one off-curve control point and one on-curve point, 4 coordinates total, to draw a quadratic bezier spline

20

QImplicit, only specifies the control point. The on-curve point will be the average of the control point specified here, and the one specified in the next QCurveTo or Q*Implicit command.

24

QHImplicit, Same as above, except only the x coordinate of the new control point is specified

28

QVImplicit, Same as above except only the y coordinate of the new control point is specified.

32

CurveTo, takes two off-curve control point and one on-curve point, 6 coordinates total, to draw a cubic bezier spline

36

VHCurveTo, The first control point is vertical from the current point, so only its y coordinate is specified. The final point is horizontal from the last control point so only its x coordinate is specified. 4 coordinates total y1, x2,y2, x3.

40

HVCurveTo, Reverse of the above x1, x2,y2, y3

44

Close, No data. Closes (and ends) the current contour. Will draw a line from the start point to the end point if needed.

45

End, No data. Ends the current contour, but leaves it open.

These are basically the drawing operators in the type1 charstrings. If my terse descriptions make no sense look there for a more complete description.

examples

suppose we want to draw a box (0,0)->(0,200)->(200,200)->(200,0)->(0,0). Then the glyph-layer would look like:

Header

one contour

(ushort) 1

Header

no images

(ushort) 0

First Contour

offset to data

(ushort) 8

The number of bytes from the start of the glyph-layer to the Contour Data

First Contour

no name

(ushort) 0

Contour Data

Move To 0,0

(byte)0, (byte)0, (byte)0

Both coordinates are <127 and can fit in a byte, so the modifier is 0. The command is also 0, and the coordinates are each 0

Contour Data

VLine To [0,]200

(byte)(12+1) (short)200

Vertical motion => VLineTo. Only the new y value need be specified. Is relative to the last position, but that was 0

Contour Data

HLine To 200[,200]

(byte)(8+1) (short)200

Horizontal motion => HLineTo. Only the new x value need be specified. Is relative to the last position, but that was 0

Contour Data

VLine To [200,]0

(byte)(12+1) (short)-200

Vertical motion => HLineTo. Only the new y value need be specified. We move from 200 to 0, so the relative change is -200

Contour Data

Close

(byte)44

We can draw the final line by closing the path

‘layr’ – Background layer data¶

uint16

version

1

uint16

count

number of layers in this sub-table

This is followed by an array of structures describing each layer

uint16

typeflag

Low order byte is the type

2=>quadratic splines, 3=>cubic splines, 1=>spiros, other values not defined

High order byte are the flags

0x100 => foreground layer

uint16

offset

to the name of this layer, a utf8, NUL terminated string

uint32

offset

to the data for this layer

The layer data is a block of ranges specifying which glyphs (by GID) have data for this layer. (the type field is present so that applications can ignore layers which they do not support).

uint16

count

of ranges

This is followed by an array of structures one for each range:

uint16

start

first GID in the range

uint16

last

last GID in the range

uint32

offset

to an array of offsets, one for each GID in the range. The offsets in this array may be 0. These offsets in turn point to a glyph-layer structure

All offsets are relative to the start of the ‘layr’ subtable.

‘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 height/depth 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