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
correctionTCHL
-- TeX Charlist
TEXL
-- TeX Extension
List
Non standard file formats
(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
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
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.
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.
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
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.
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.
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
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 propertyuint32 value For strings and atoms, this is an offset into the string table
for integers it is the value itselfThe string table is a series of ASCII bytes. Each string is NUL terminated.
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).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.
uint32 version currently 0x00000001 int64 FontForge's own timestamp (the date of the sources for fontforge) int64 creation date of this font Not the creation date of the tt/ot file,
but the date the sfd file was created.
(not always accurate).int64 last modification date of this font Not the modification date of the file,
but the time a glyph, etc. was last
changed in the font database.
(not always accurate)