<HTML>
<HEAD>
<!-- Created with AOLpress/2.0 -->
<!-- AP: Created on: 30-Jun-2003 -->
<!-- AP: Last modified: 16-Sep-2008 -->
<TITLE>Non standard extensions used by FontForge in True/Open Type</TITLE>
<LINK REL="icon" href="fftype16.png">
<LINK REL="stylesheet" TYPE="text/css" HREF="FontForge.css">
</HEAD>
<BODY>
<DIV id="in">
<H1 ALIGN=Center>
Non standard extensions used FontForge in True/Open Type
</H1>
<H2>
Non standard feature tags
</H2>
<P>
Internal
<UL>
<LI>
<CODE>' REQ'</CODE> -- tag used for required features
</UL>
<P>
For TeX<BR>
I no longer use these. MS has come up with a MATH table which can contain
all the TeX information.
<UL>
<LI>
<CODE>ITLC</CODE> -- <A HREF="PfaEdit-TeX.html#Italic">Italic
correction</A><BR>
I have proposed this as an extension to OpenType. There was some discussion
of it, but I believe the idea died.
<LI>
<CODE>TCHL</CODE> -- <A HREF="PfaEdit-TeX.html#charlist">TeX Charlist</A>
<LI>
<CODE>TEXL</CODE> -- <A HREF="PfaEdit-TeX.html#extension">TeX Extension
List</A>
</UL>
<H2>
Non standard tables.
</H2>
<UL>
<LI>
<A HREF="non-standard.html#PfEd">'PfEd' the FontForge extensions table</A>
<LI>
<A HREF="#TeX">'TeX ' the TeX metrics table</A>
<LI>
<A HREF="#BDF">'BDF ' the BDF properties table</A>
<LI>
<A HREF="#FFTM">'FFTM' the FontForge time stamp table</A>
<HR>
<LI>
(<A HREF="TrueOpenTables.html">standard tables</A>)
</UL>
<P>
Non standard file formats
<UL>
<LI>
<A HREF="bitmaponlysfnt.html#MS">Bitmap only sfnt for MS Windows</A>
</UL>
<H2>
'<A NAME="PfEd">PfEd</A>' -- the FontForge extensions table
</H2>
<P>
(the name is 'PfEd' for historical reasons)
<BLOCKQUOTE>
The table begins with a table header containing a version number and a count
of sub-tables
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>version</TD>
<TD>currently 0x00010000</TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>count</TD>
<TD></TD>
</TR>
</TABLE>
<P>
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
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>tag</TD>
<TD></TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>offset</TD>
<TD>from start of 'PfEd' table</TD>
</TR>
</TABLE>
<P>
The format of the subtable depends on the sub-table's tag. There are currently
3 tags supported, these are
<UL>
<LI>
'<A HREF="#colr">colr</A>' -- per glyph color sub-table (stores the color
that appears in the font view)
<LI>
'<A HREF="non-standard.html#cmnt">cmnt</A>' -- per glyph comment sub-table
(stores the comment that appears in the Char Info dialog for the character)
<LI>
'<A HREF="non-standard.html#fcmt">fcmt</A>' -- the font comment sub-table
(stores the comment that appears in the Font Info dialog)
<LI>
'<A HREF="#fcmt">flog</A>' -- the font log sub-table (looks just like the
'fcmt' subtable)
<LI>
'<A HREF="#cvtc">cvtc</A>' -- the cvt comments subtable
<LI>
'<A HREF="#GPOS">GPOS</A>' -- Save lookup, lookup subtable and anchor class
names of GPOS lookups
<LI>
'<A HREF="#GPOS">GSUB</A>' -- Save lookup and lookup subtable names of GSUB
lookups
<LI>
'<A HREF="non-standard.html#guid">guid</A>' -- Save guideline locations
<LI>
'<A HREF="#layr">layr</A>' -- Save background and spiro layers
</UL>
</BLOCKQUOTE>
<H3>
'<A NAME="colr">colr</A>' -- the per-glyph color sub-table
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of ranges
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of ranges</TD>
</TR>
</TABLE>
<P>
After this will be <count> instances of the following structure
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>starting glyph index</TD>
<TD></TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>ending glyph index</TD>
<TD></TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>color</TD>
<TD>expressed as a 24bit rgb value</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<H3>
'<A NAME="cmnt">cmnt</A>' -- the per-glyph comment sub-table
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of ranges
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0/1</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of ranges</TD>
</TR>
</TABLE>
<P>
After this will be <count> instances of the following structure
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>starting glyph index</TD>
<TD></TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>ending glyph index</TD>
<TD></TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>offset</TD>
<TD>from the start of this sub-table</TD>
</TR>
</TABLE>
<P>
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.
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>offset</TD>
<TD>from start of table</TD>
</TR>
<TR>
<TD></TD>
<TD>...</TD>
<TD></TD>
</TR>
</TABLE>
<P>
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.
</BLOCKQUOTE>
<H3>
'<A NAME="fcmt">fcmt</A>' -- the font comment (and FONTLOG) sub-table
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of ranges
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0/1</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>length</TD>
<TD>number of characters in the string</TD>
</TR>
</TABLE>
<P>
In version 0 this is followed by <length> Unicode (UCS2) characters.
In version 1 it is followed by <length> bytes in utf8 encoding.
</BLOCKQUOTE>
<H3>
'<A NAME="cvtc">cvtc</A>' -- the cvt comments sub-table
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of cvt entries
which might have comments
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>number of entries in the cvt comments array<BR>
which might be smaller than the number of entries in the cvt array itself
if we want to save space</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>offset[count]</TD>
<TD>offsets to the start of utf8-encoded, NUL terminated strings. Or 0 if
this cvt entry has no comment</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<H3>
'<A NAME="GPOS">GPOS/GSUB</A>' -- lookup names
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of ranges
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of lookups in this table</TD>
</TR>
</TABLE>
<P>
Then there will be an array of count elements (one for each lookup, ordered
as the lookups are in the GPOS or GSUB table)
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to lookup name</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to lookup subtable structure</TD>
</TR>
</TABLE>
<P>
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:
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of lookup subtables in this lookup</TD>
</TR>
</TABLE>
<P>
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)
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to lookup subtable name</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to anchor class structure</TD>
</TR>
</TABLE>
<P>
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:
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of anchor classes in this lookupsubtable</TD>
</TR>
</TABLE>
<P>
Then there will be an array of count elements (one for each anchor class)
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to anchor class name</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<H3>
'<A NAME="guid">guid</A>' -- guidelines
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of ranges
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>1</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>vcount</TD>
<TD>number of vertical guidelines</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>hcount</TD>
<TD>number of horizontal guidelines</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>mbz</TD>
<TD>At some point this may contain info on diagonal guidelines. For now it
is undefined</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>To a full description of the guideline layer</TD>
</TR>
</TABLE>
<P>
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.
<P>
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)
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>int16</TD>
<TD>position</TD>
<TD>x location of vertical guides, y location of horizontal ones</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to name, a NUL terminated utf8 string. (offset may be 0 if guideline
is unnamed).</TD>
</TR>
</TABLE>
<P>
The offset to the guideline layer points to a variable length structure which
is also used in the <A HREF="#layr">'layr' subtable</A>
</BLOCKQUOTE>
<H4>
'<A NAME="glyph-layer">glyph-layer</A>' -- Data structure representing all
the contours of a layer of a glyph
</H4>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of ranges
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of contours</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of references (not present in version 0 layers)</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>mbz</TD>
<TD>reserved for a count of images</TD>
</TR>
</TABLE>
<P>
This is followed by an array of structures describing each contour
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to start of contour data</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to a name for the contour, a utf8, NUL terminated string (or 0 if the
contour is unnamed)</TD>
</TR>
</TABLE>
<P>
All offsets from the start of the glyph-layer structure.
<P>
This is followed by an array of structures describing each reference
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>fixed16.16</TD>
<TD>transform[6]</TD>
<TD>A PostScript transformaton matrix where each member is a signed 4 byte
integers which should be divided by 32768.0 to allow for non-integral values</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>gid</TD>
<TD>The Glyph ID of the glyph being referred to</TD>
</TR>
</TABLE>
<P>
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.
<P>
The low order two bits of the command (except for the spiro and close commands)
specify the data format:
<TABLE>
<TR>
<TD>0</TD>
<TD>signed byte data for values -128 to 127</TD>
</TR>
<TR>
<TD>1</TD>
<TD>signed short data for values -32768 to 32767</TD>
</TR>
<TR>
<TD>2</TD>
<TD>A signed 4 byte integer which should be divided by 256.0 for non-integral
coordinates (or for big ones)</TD>
</TR>
<TR>
<TD>3</TD>
<TD>Undefined and erroneous for now</TD>
</TR>
</TABLE>
<P>
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).
<P>
The verb may be one of the following:
<TABLE>
<TR>
<TD>0</TD>
<TD>MoveTo, takes 2 coordinates (x,y). This must begin each contour and may
not appear elsewhere within it</TD>
</TR>
<TR>
<TD>4</TD>
<TD>LineTo, also takes 2 coordinates</TD>
</TR>
<TR>
<TD>8</TD>
<TD>HLineTo, draws a horizontal line, so only the new x coordinate need be
specified.</TD>
</TR>
<TR>
<TD>12</TD>
<TD>VLineTo, draws a vertical line, so only the new y coordinate need be
specified.</TD>
</TR>
<TR>
<TD>16</TD>
<TD>QCurveTo, takes one off-curve control point and one on-curve point, 4
coordinates total, to draw a quadratic bezier spline</TD>
</TR>
<TR>
<TD>20</TD>
<TD>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.</TD>
</TR>
<TR>
<TD>24</TD>
<TD>QHImplicit, Same as above, except only the x coordinate of the new control
point is specified</TD>
</TR>
<TR>
<TD>28</TD>
<TD>QVImplicit, Same as above except only the y coordinate of the new control
point is specified.</TD>
</TR>
<TR>
<TD>32</TD>
<TD>CurveTo, takes two off-curve control point and one on-curve point, 6
coordinates total, to draw a cubic bezier spline</TD>
</TR>
<TR>
<TD>36</TD>
<TD>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.</TD>
</TR>
<TR>
<TD>40</TD>
<TD>HVCurveTo, Reverse of the above x1, x2,y2, y3</TD>
</TR>
<TR>
<TD>44</TD>
<TD>Close, No data. Closes (and ends) the current contour. Will draw a line
from the start point to the end point if needed.</TD>
</TR>
<TR>
<TD>45</TD>
<TD>End, No data. Ends the current contour, but leaves it open.</TD>
</TR>
</TABLE>
<P>
These are basically the drawing operators in the type1 charstrings. If my
terse descriptions make no sense look there for a more complete description.
<H5>
examples
</H5>
<P>
suppose we want to draw a box
(0,0)->(0,200)->(200,200)->(200,0)->(0,0). Then the glyph-layer
would look like:
<TABLE>
<TR>
<TD>Header</TD>
<TD>one contour</TD>
<TD>(ushort) 1</TD>
</TR>
<TR>
<TD>Header</TD>
<TD>no images</TD>
<TD>(ushort) 0</TD>
</TR>
<TR>
<TD>First Contour</TD>
<TD>offset to data</TD>
<TD>(ushort) 8</TD>
<TD>The number of bytes from the start of the glyph-layer to the Contour
Data</TD>
</TR>
<TR>
<TD>First Contour</TD>
<TD>no name</TD>
<TD>(ushort) 0</TD>
</TR>
<TR>
<TD>Contour Data</TD>
<TD>Move To 0,0</TD>
<TD>(byte)0, (byte)0, (byte)0</TD>
<TD>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</TD>
</TR>
<TR>
<TD>Contour Data</TD>
<TD>VLine To [0,]200</TD>
<TD>(byte)(12+1) (short)200</TD>
<TD>Vertical motion => VLineTo. Only the new y value need be specified.
Is relative to the last position, but that was 0</TD>
</TR>
<TR>
<TD>Contour Data</TD>
<TD>HLine To 200[,200]</TD>
<TD>(byte)(8+1) (short)200</TD>
<TD>Horizontal motion => HLineTo. Only the new x value need be specified.
Is relative to the last position, but that was 0</TD>
</TR>
<TR>
<TD>Contour Data</TD>
<TD>VLine To [200,]0</TD>
<TD>(byte)(12+1) (short)-200</TD>
<TD>Vertical motion => HLineTo. Only the new y value need be specified.
We move from 200 to 0, so the relative change is -200</TD>
</TR>
<TR>
<TD>Contour Data</TD>
<TD>Close</TD>
<TD>(byte)44</TD>
<TD>We can draw the final line by closing the path</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<H3>
'<A NAME="layr">layr</A>' -- Background layer data
</H3>
<BLOCKQUOTE>
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>1</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>number of layers in this sub-table</TD>
</TR>
</TABLE>
<P>
This is followed by an array of structures describing each layer
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>typeflag</TD>
<TD>Low order byte is the type<BR>
2=>quadratic splines, 3=>cubic splines, 1=>spiros, other values
not defined<BR>
High order byte are the flags<BR>
0x100 => foreground layer</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>offset</TD>
<TD>to the name of this layer, a utf8, NUL terminated string</TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>offset</TD>
<TD>to the data for this layer</TD>
</TR>
</TABLE>
<P>
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).
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of ranges</TD>
</TR>
</TABLE>
<P>
This is followed by an array of structures one for each range:
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>start</TD>
<TD>first GID in the range</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>last</TD>
<TD>last GID in the range</TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>offset</TD>
<TD>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
<A HREF="#glyph-layer">glyph-layer structure</A></TD>
</TR>
</TABLE>
<P>
All offsets are relative to the start of the 'layr' subtable.
</BLOCKQUOTE>
<H2>
'<A NAME="TeX">TeX </A>' -- the TeX metrics table
</H2>
<BLOCKQUOTE>
The table begins with a table header containing a version number and a count
of sub-tables
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>version</TD>
<TD>currently 0x00010000</TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>count</TD>
<TD></TD>
</TR>
</TABLE>
<P>
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
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>tag</TD>
<TD></TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>offset</TD>
<TD>from start of 'PfEd' table</TD>
</TR>
</TABLE>
<P>
The format of the subtable depends on the sub-table's tag. There are currently
3 tags supported, these are
<UL>
<LI>
'<A HREF="#ftpm">ftpm</A>' -- the font parameter table
<LI>
'<A HREF="#htdp">htdp</A>' -- per glyph height/depth sub-table (stores TeX's
idea of the height and depth of glyphs (should correct for optical overshoot))
<LI>
'<A HREF="#sbsp">sbsp</A>' -- per glyph sub/super-script sub-table
</UL>
</BLOCKQUOTE>
<H3>
'<A NAME="htdp">htdp</A>' -- the per-glyph height/depth sub-table
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of glyphs
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of glyphs</TD>
</TR>
</TABLE>
<P>
After this will be <count> instances of the following structure
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>height</TD>
<TD>in em-units</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>depth</TD>
<TD></TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<P>
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.
<H3>
'<A NAME="sbsp">sbsp</A>' -- the per-glyph sub/super-script sub-table
</H3>
<BLOCKQUOTE>
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
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>of glyphs</TD>
</TR>
</TABLE>
<P>
After this will be <count> instances of the following structure
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>subscript offset</TD>
<TD>in em-units</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>superscript offset</TD>
<TD></TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<P>
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.
<H3>
'<A NAME="ftpm">ftpm</A>' -- the font parameter (font dimensions) sub-table
</H3>
<BLOCKQUOTE>
The sub-table header begins with a version number, and a count of parameters
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>0</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>count</TD>
<TD>number of parameters in the font</TD>
</TR>
</TABLE>
<P>
And this is followed by <count> instances of the following structure:
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>tag</TD>
<TD>parameter name</TD>
</TR>
<TR>
<TD>int32</TD>
<TD>value</TD>
<TD></TD>
</TR>
</TABLE>
<P>
I store these values as fix_words and <EM>not</EM> as em-units because their
meaning is not constrained by the spec and the <CODE>Slant</CODE> parameter
(at the least) can not be converted to em-units.
<P>
I have defined the following 4-letter parameter tags
<TABLE BORDER CELLPADDING="2">
<TR>
<TH>Tag</TH>
<TH>Meaning</TH>
<TH>traditional font parameter number in tfm file (font dimension number)</TH>
</TR>
<TR>
<TD>Slnt</TD>
<TD>Slant</TD>
<TD>1</TD>
</TR>
<TR>
<TD>Spac</TD>
<TD>Space</TD>
<TD>2</TD>
</TR>
<TR>
<TD>Stre</TD>
<TD>Stretch</TD>
<TD>3</TD>
</TR>
<TR>
<TD>Shnk</TD>
<TD>Shrink</TD>
<TD>4</TD>
</TR>
<TR>
<TD>XHgt</TD>
<TD>XHeight</TD>
<TD>5</TD>
</TR>
<TR>
<TD>Quad</TD>
<TD>Quad</TD>
<TD>6</TD>
</TR>
<TR>
<TD>ExSp</TD>
<TD>Extra Space</TD>
<TD>7 (in text fonts)</TD>
</TR>
<TR>
<TD>MtSp</TD>
<TD>Math Space</TD>
<TD>7 (in math and math extension fonts)</TD>
</TR>
<TR>
<TD>Num1</TD>
<TD>Num1</TD>
<TD>8 (in math fonts)</TD>
</TR>
<TR>
<TD>Num2</TD>
<TD>Num2</TD>
<TD>9</TD>
</TR>
<TR>
<TD>Num3</TD>
<TD>Num2</TD>
<TD>10</TD>
</TR>
<TR>
<TD>Dnm1</TD>
<TD>Denom1</TD>
<TD>11</TD>
</TR>
<TR>
<TD>Dnm2</TD>
<TD>Denom2</TD>
<TD>12</TD>
</TR>
<TR>
<TD>Sup1</TD>
<TD>Sup1</TD>
<TD>13</TD>
</TR>
<TR>
<TD>Sup2</TD>
<TD>Sup2</TD>
<TD>14</TD>
</TR>
<TR>
<TD>Sup3</TD>
<TD>Sup3</TD>
<TD>15</TD>
</TR>
<TR>
<TD>Sub1</TD>
<TD>Sub1</TD>
<TD>16</TD>
</TR>
<TR>
<TD>Sub2</TD>
<TD>Sub2</TD>
<TD>17</TD>
</TR>
<TR>
<TD>SpDp</TD>
<TD>Sup Drop</TD>
<TD>18</TD>
</TR>
<TR>
<TD>SbDp</TD>
<TD>Sub Drop</TD>
<TD>19</TD>
</TR>
<TR>
<TD>Dlm1</TD>
<TD>Delim 1</TD>
<TD>20</TD>
</TR>
<TR>
<TD>Dlm2</TD>
<TD>Delim 2</TD>
<TD>21</TD>
</TR>
<TR>
<TD>AxHt</TD>
<TD>Axis height</TD>
<TD>22</TD>
</TR>
<TR>
<TD>RlTk</TD>
<TD>Default Rule Thickness</TD>
<TD>8 (in math extension fonts)</TD>
</TR>
<TR>
<TD>BOS1</TD>
<TD>Big Op Spacing1</TD>
<TD>9</TD>
</TR>
<TR>
<TD>BOS2</TD>
<TD>Big Op Spacing2</TD>
<TD>10</TD>
</TR>
<TR>
<TD>BOS3</TD>
<TD>Big Op Spacing3</TD>
<TD>11</TD>
</TR>
<TR>
<TD>BOS4</TD>
<TD>Big Op Spacing4</TD>
<TD>12</TD>
</TR>
<TR>
<TD>BOS5</TD>
<TD>Big Op Spacing5</TD>
<TD>13</TD>
</TR>
</TABLE>
<P>
</BLOCKQUOTE>
<H2>
'<A NAME="BDF">BDF </A>' -- the BDF properties table
</H2>
<BLOCKQUOTE>
The table begins with a table header containing a version number and a count
of strikes
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>version</TD>
<TD>currently 0x0001</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>strike-count</TD>
<TD></TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>offset to string table</TD>
<TD>(from start of BDF table)</TD>
</TR>
</TABLE>
<P>
This is followed by an entry for each strike identifying how many properties
that strike has.
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint16</TD>
<TD>ppem</TD>
<TD></TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>property-count</TD>
<TD></TD>
</TR>
</TABLE>
<P>
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:
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>name</TD>
<TD>offset into the string table of the property's name</TD>
</TR>
<TR>
<TD>uint16</TD>
<TD>type</TD>
<TD>0=>string<BR>
1=>atom<BR>
2=>int<BR>
3=>uint<BR>
0x10 may be ored into one of the above types to indicate a real property</TD>
</TR>
<TR>
<TD>uint32</TD>
<TD>value</TD>
<TD>For strings and atoms, this is an offset into the string table<BR>
for integers it is the value itself</TD>
</TR>
</TABLE>
<P>
The string table is a series of ASCII bytes. Each string is NUL terminated.
</BLOCKQUOTE>
<H2>
'<A NAME="FFTM">FFTM</A>' the FontForge time stamp table
</H2>
<BLOCKQUOTE>
The table begins with a table header containing a version number and is followed
by a series of timestamps (same format as the timestamps in the head table
-- 64 bit times, seconds since 00:00:00, 1-Jan-1904).
<P>
I don't think this is a duplication of the information in the 'head' table.
Neither the Apple nor OpenType spec is clear: Does head.creationtime refer
to the creation time of the truetype/opentype file, or of the font itself.
After examining various fonts of Apple's, it appears that the 'head' entries
contain the dates for the font file and not the font. The times in this table
are specifically the creation time of the font (the sfd file), while the
times in the 'head' table contain the creation time of the truetype or opentype
font file.
<TABLE CELLPADDING="2" BGCOLOR="#8080ff">
<TR>
<TD>uint32</TD>
<TD>version</TD>
<TD>currently 0x00000001</TD>
</TR>
<TR>
<TD>int64</TD>
<TD>FontForge's own timestamp</TD>
<TD>(the date of the sources for fontforge)</TD>
</TR>
<TR>
<TD>int64</TD>
<TD>creation date of this font</TD>
<TD>Not the creation date of the tt/ot file,<BR>
but the date the sfd file was created.<BR>
(not always accurate).</TD>
</TR>
<TR>
<TD>int64</TD>
<TD>last modification date of this font</TD>
<TD>Not the modification date of the file,<BR>
but the time a glyph, etc. was last<BR>
changed in the font database.<BR>
(not always accurate)</TD>
</TR>
</TABLE>
<P>
</BLOCKQUOTE>
</DIV>
</BODY></HTML>
