# Spline Font Database

This page is often grievously out of date. It was a fair approximation to reality on 31 Dec 2004. Even if out of date it should be helpful, but if you really need to know the current format look at sfd.c and see what it parses. Some descriptions of esoteric features are not complete, but I hope they give you enough hints that you can figure the format out (especially after looking it up in sfd.c)

FontForge's sfd files are ASCII files (so they can be copied easily across the internet and so that diffs are somewhat meaningful). They contain a full description of your font.

They are vaguely modeled on bdf files. The first few lines contain general font properties, then there's a section for each character, then a section for each bitmap font.

- Font Header
- Outline Character Data
- Bitmap Fonts
- CID keyed fonts
- Multiple Master fonts
- AutoSave Format

WARNING: It is tempting to cut and paste information from one sfd file to another. This is usually ok, but there are a couple of cases than need to be avoided:

- If you copy a glyph with truetype instructions, those instructions may call subroutines defined in the old font but not the new. Unexpected things may happen when the glyph is grid fit (including system crashes)
- If you copy a substitution (ligature, kern, contextual chaining, ...) item from one font to another, the substitution contains an index into a table of script/languages maintained by the font. Bad things (FontForge crashes) can happen if these tables do not match.

### Font Header

Here is an example of what the first few lines look like (order is largely irrelevant within this section):

>     SplineFontDB: 1.0
>     FontName: Ambrosia
>     FullName: Ambrosia
>     FamilyName: Ambrosia
>     Weight: Medium
>     Copyright: Copyright (C) 1995-2000 by George Williams
>     Comments: This is a funny font.
>     Version: 001.000
>     ItalicAngle: 0
>     UnderlinePosition: -133
>     UnderlineWidth: 20
>     Ascent: 800
>     Descent: 200
>     DisplaySize: -24
>     AntiAlias: 1
>     WinInfo: 64 16 4
>     FitToEm: 1
>     XUID: 3 18 21
>     Encoding: unicode
>     Order2: 1
>     OnlyBitmaps: 0
>     MacStyle: 0
>     TeXData: 1 10485760 0 269484 134742 89828 526385 1048576 89828

The first line just identifies the file as an sfd file. The next few lines give the various different names that postscript allows fonts to have. Then some fairly self-explanatory items (if they don't make sense, look them up in the font info dlg). A few things need some explanation:

TeXData
  These are the TeX font parameters (and some similar info). The first number is 1,2 or 3 and indicates that the font is a text, math or math ext font. The next number is the design pointsize (times (1<<20)). Then follow the font parameters. These values are usually in TeX fix_word format where there is a binary point after the first 20 binary digits (so to get the number divide by (1<<20)).
DisplaySize
  This is the number of pixels per em that will be used by default to display the font in fontviews (it may be changed of course). Negative numbers mean to rasterize the display from the outlines, positive numbers mean to use a prebuilt bitmap font of that size.
AntiAlias
  Whether the fontview should display the font as antialiased or black and white. (AntiAliased looks better, but will be slower)
FitToEm
  Controls whether Fit to Em is checked by default in a fontview that displays this font.
WinInfo
  Has three pieces of data on the default display of windows containing this font. The first datum says that the window should be scrolled so that glyph at encoding 64 should be visible, the second that the window should have 16 character columns horizontally, and the last that there should be 4 character rows vertically.
Encoding
  For normal fonts this will be one of the names (or a close approximation thereto) that appears in the Encoding pulldown list. CID keyed fonts will not have encodings. Instead they'll have something like:

>     Registry: Adobe
>     Ordering: japan1
>     Supplement: 4
>     CIDVersion: 1.2

Some fonts will have some TrueType information in them too (look at the truetype spec for the meanings of these, they usually live in the OS/2 table).

>     FSType: 4
>     PFMFamily: 17
>     TTFWeight: 400
>     TTFWidth: 5
>     Panose: 2 0 5 3 0 0 0 0 0 0
>     LineGap: 252
>     VLineGap: 0

If loaded from a font with an OS/2 table there may also be the following fields (there is no ui to set these fields, but FontForge preserves them)

>     HheadAscent: 892
>     HheadDescent: -200
>     OS2TypoAscent: 892
>     OS2TypoDescent: -200
>     OS2WinAscent: 892
>     OS2WinDescent: -200

These represent different definitions of ascent and descent that are stored in various places in the truetype file (Horizontal header and OS/2 tables).

The MacStyle field (if present) indicates whether the font is bold, italic, condensed, extended, etc.

Some fonts will have Postscript specific information contained in the Private dictionary

>     BeginPrivate: 1
>     BlueValues 23 [-19 0 502 517 750 768]
>     EndPrivate

If the font has any opentype features it will have a list of script language entries:

>     ScriptLang: 3
>      1 latn 1 ROM
>      1 latn 4 DEU  ROM  VIT  dflt
>      3 cyrl 1 dflt grek 1 dflt latn 5 DEU  ROM  TRK  VIT  dflt

The first line says that there are 3 sets of script lang entries and they follow on the next three lines. The next line says that this entry is only active for one script ('latn') and then only if the language is 'ROM '. The next line says the entry is again only active for one script, but that this time any of the four languages 'DEU ', 'ROM ', 'VIT ' or the default language apply to it. And the last line gives an example of an entry that is active for several scripts with several languages.

OpenType features are stored with an index into this list. If a feature has index "0" then that feature is only active for the latin script in the Romanian language. If it has index 2 it will be active for cyrillic, greek and latin scripts. A special script index of 65535 is used to mean that this feature is "Nested", that is it is never activated by itself, but its activation is controlled by a contextual or contextual chaining lookup (which in turn will have its own script language index).

If your font has any kerning classes

>     KernClass: 31 64 2 0
>      1 F
>      41 L Lacute glyph78 Lcommaaccent Ldot Lslash
>      1 P
>     ...
>      6 hyphen
>      5 space
>     ...
>      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -152 -195 -152 -225 0 0 0 0 0 0 0 0 0 0 0 0 0 -145 -145 -130
>      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -130 0 0 0 0 0 0 0 0 0 0 -145 0 -115 0 0 0 0 -65 0 -140 -120 -120
>     ...

The first line says that this Kerning Class has 31 different classes for the first character, and 64 for the second. It is active for entry 2 in the script lang list above. The OpenType flags will be 0. The next line says that the first character class of the first character (numbered 1, class 0 is reserved and never needs to be defined) consists of only one character "F" (the number in front is the string length of the line. It speeds up processing the sfd file but has no semantic content). The next line is for class 2 of the first character, it has more characters in it and a longer string length. After 30 entries we start on the classes for the second character. They look exactly like classes for the first character. After all the second character classes have been defined we have an array of numbers, <char1 class cnt>*<char2 class cnt> of them in fact. This specifies the amount of kerning that should be placed between a characters of the given classes of left and right characters (ie. if char1 was in left class 2 and char2 was in right class 4 then we would index this array with 3*<char2 class cnt> + 4).

The order of opentype features within GPOS/GSUB tables may be stored:

>     TableOrder: GPOS 4
>     	'subs'
>     	'sinf'
>     	'mark'
>     	'kern'
>     TableOrder: GSUB 2
>     	'frac'
>     	'nutf'

If the font contains ttf hinting, then the file may contain unparsed truetype tables (understanding ttf hinting is beyond FontForge's abilities, but it can at least preserve the data):

>     TtfTable: prep 4360
>     5S;o3()It?eJ8r@H[HSJH[H^@!b&BQ*?Vcm@'XSh+1MACZ>Up/\,o1+Ca't2!<ocH+Wn2p"@,t&
>     +Wo+[()Is6G8:u7D/^7,*,KO/(E=N5!=s)LCMjn,:Mp3:DSL&j05dG#cY`hLCN"!<CBO$@s(_ZX
>     ...

The first line says that the 'prep' table is 4360 bytes long. Subsequent lines will provide 4360 bytes of data, packed in Enc85 (which takes binary data and packs it into ASCII without too much expansion. See the PostScript Reference Manual for a description of this packing).

The `LangName` entries represent the TrueType name table: the number represents the language and is followed by a list of strings encoded in UTF-7. The first string corresponds to ID=0 (Copyright), the second to ID=1 (Family), ... trailing empty strings will be omitted. In the American English language (1033) section, if one of these names exactly matches the equivalent postscript item then that name will be omitted (this makes it easier to handle updates, users only have to change the copyright in one place)

>     LangName: 1033 "" "" "Regular" "GWW:Caliban Regular: Version 1.0" "" "Version 1.0"
>     LangName: 1032 "" "" "+A5oDsQ09A78DvQ05A7oDrAAA"

If your font has any anchor classes:

>     AnchorClass: "top" mark 4 7 1 "bottom" mark 4 7 1 "Anchor-2" mark 4 7 1 "Anchor-3" mark 4 7 2 "Anchor-4" mark 4 7 2 "Anchor-5" mark 4 7 3 "Anchor-6" mark 4 7 4

There is an Anchor Class named "top" which has feature tag 'mark', opentype flags 4, a script lang index of 7, and it should be merged with other anchor classes marked with "1". The next class is named "bottom", the next "Anchor-2" and so forth. (Anchor class names are output in UTF7)

Contextual or contextual chaining lookups are also stored in the font header. The are introduced by one of the keywords: "ContextPos", "ContextSub", "ChainPos", "ChainSub" and "ReverseChain", and are ended by "EndFPST". Contextual chaining lookups may check previous glyphs (called backtracking), current glyphs and lookahead glyphs, while Contextual lookups only check for a string of current glyphs. There are four formats:
By coverage tables

>     ChainSub: coverage 0 0 'abvs' 0 0 0 1
>      1 1 0
>       Coverage: 7 uni0C40
>       BCoverage: 8 glyph388
>      1
>       SeqLookup: 0 '0013'
>     EndFPST

This defines a simple context chaining substitution by coverage class. The opentype flags are 0, script/lang index is 0, the feature tag is 'abvs'. There are no classes, no backtracking classes and no lookahead classes defined (it's by coverage table). There is one rule. (For a greater explanation of these cryptic comments see the OpenType specs on contextual lookups).

Then follows the first rule. The first line, "1 1 0", says how many coverage tables there are in the normal list (1), how many in the backtrack list (1) and how many in the lookahead list (0). Then we get the one normal coverage table, which describes a single glyph (uni0C40). Then one backtracking coverage table which also defines one glyph (glyph388). Finally there is one sequence lookup, at normal position 0, we should apply the substitution named '0013'.

That is to say: If we find the glyph stream "glyph388 uni0C40", then it will match this lookup and we should apply substitution '0013' (found elsewhere) to uni0C40.

By classes

>     ChainSub: class 0 0 'calt' 3 3 0 1
>       Class: 52 b o v w b.high o.high v.high w.high r.alt.high r.alt
>       Class: 43 a c d e f g h i j k l m n p q r s t u x y z
>       BClass: 52 b o v w b.high o.high v.high w.high r.alt.high r.alt
>       BClass: 43 a c d e f g h i j k l m n p q r s t u x y z
>      1 1 0
>       ClsList: 2
>       BClsList: 1
>       FClsList:
>      1
>       SeqLookup: 0 'high'
>     EndFPST

This defines a context chaining substitution, by classes. The format of the first line is the same as described above. Here we have three classes for the normal match and three for the backtracking match, and one rule. The next 4 lines define the classes. As with kerning by classes, class 0 does not need to be explicitly defined, it is implicitly defined to be "any glyph not defined in another class". So we define class 1 to be "b,o,v,..." and class 2 to be "a,c,d,e,...". And then we define the backtracking classes (which here happen to be the same as the classes for the normal match, but that isn't always the case).

The one rule says that if we get something in normal class 2 following something in backtracking class 1 (that is, if we get something like "ba" or "oc") then apply substitution 'high'

By glyphs

>     ChainSub: glyph 0 1 'calt' 0 0 0 1
>      String: 1 D
>      BString: 3 c b
>      FString: 1 e
>      1
>       SeqLookup: 0 'rigl'
>     EndFPST

Again we have one rule. That rule says that if we get the sequence of glyphs "c b D e" then we should apply substitution 'rig1' to glyph "D".

And finally by reverse coverage tables

>     ChainSub: revcov 0 0 'foo ' 0 0 0 1
>      1 1 0
>       Coverage: 7 uni0C40
>       BCoverage: 8 glyph388
>      1
>       Replace: 11 uni0C40.alt
>     EndFPST

Which says that when glyph388 precedes uni0C40 then uni0C40 should be replaced by uni0C40.alt

There may be apple state machines. These are introduced by one of the keywords: "MacIndic", "MacContext", "MacInsert" and "MacKern", and they are terminated with "EndASM".

>     MacContext: 2,2 16384 9 5
>       Class: 320 yehhamzaabovearabic beharabic teharabic theharabic jeemarabic haharabic khaharabic seenarabic sheenarabic sadarabic dadarabic taharabic zaharabic ainarabic ghainarabic feharabic qafarabic kafarabic lamarabic meemarabic noonarabic heharabic alefmaksuraarabic yeharabic peharabic tteharabic tcheharabic veharabic gafarabic
>       Class: 227 noonghunnaarabic alefmaddaabovearabic alefhamzaabovearabic wawhamzaabovearabic alefhamzabelowarabic alefarabic tehmarbutaarabic dalarabic thalarabic reharabic zainarabic wawarabic ddalarabic rreharabic jeharabic yehbarreearabic
>       Class: 201 shaddakasraarabic shaddakasratanarabic shaddafathaarabic shaddadammaarabic shaddadammatanarabic fathatanarabic dammatanarabic kasratanarabic fathaarabic dammaarabic kasraarabic shaddaarabic sukunarabic
>       Class: 13 tatweelarabic
>       Class: 17 ttehinitialarabic
>      0 0 ~ ~
>      0 0 ~ ~
>      0 0 ~ ~
>      0 0 ~ ~
>      2 32768 ~ ~
>      ...
>      3 32768 'M002' 'M003'
>      ...
>     EndASM

The state machine begins with a line defining what mac feature,setting invokes it, some mac flags, the number of classes, and number of states in the machine. The first four states on the mac are predefined, so we start with class 4 (yehhamzaabovearabic...). Finally there will be <number of classes>*<number of states> lines describing transitions. We begin with the transition for state 0, class 0, then the transition for state 0, class 1, ...

Each transition contains the next state to go to, a set of flags. There may also be other arguments depending on the type of the state machine.

MacIndic | This format has no additional arguments
MacContext | This format potentially contains the names of two substitutions. One to be applied to the marked glyph, one to be applied to the current glyph (the special substitution "~" means do nothing and is used as a place holder). See above.

MacInsert

This format contains two glyph lists, each preceded by a number indicating how many bytes follow.

>     2 0 0 3 a b
>     0 32768 4 fi q 0

The first line indicates that no characters should be insert at the marked glyph but that "a" and "b" should be insert at the current glyph. The second line indicates that "fi" and "q" should be insert at the marked glyph and no characters at the current glyph. The flags determine whether characters are insert before or after the glyph.

MacKern | This format contains a list of kerning offsets. First is a count field saying how many numbers follow, then a list of numbers which adjust the kerning for glyphs that have previously been pushed on the kerning stack.

The GenTags entry describes a list of feature tags that FontForge has generated itself

>     GenTags: 1 sb'rigl'

This line says that FontForge has generated 1 tag, the generated tag is used for a substitution lookup (sb=>substitution), and the tag is 'rig1'.

There may be a list of Mac Feature/Setting names

>     MacFeat: 0 0 0
>     MacName: 0 0 24 "All Typographic Features"
>     MacSetting: 0
>     MacName: 0 0 12 "All Features"
>     MacFeat: 1 0 0
>     MacName: 0 0 9 "Ligatures"
>     MacSetting: 0
>     MacName: 0 0 18 "Required Ligatures"
>     MacSetting: 2
>     MacName: 0 0 16 "Common Ligatures"
>     MacFeat: 2 1 2

There may be a Grid entry near the top of the font, this specifies the splines to be drawn in the grid layer for the font, see below for a description of the splineset format:

>     Grid
>     678 -168 m 5
>      -40 -168 l 5
>     -678 729 m 1
>      1452 729 l 1
>     -678 525 m 1
>      1452 525 l 1
>     EndSplineSet

### Outline Character Data

Then for non-CID fonts you should find a line like:

>     BeginChars: 285 253

This means that the font has room for 285 characters and that there are a total of 253 defined (usually control characters are not defined). A character looks like:

>     StartChar: exclam
>     Encoding: 33 33
>     Width: 258
>     Flags:
>     HStem: 736 13<39 155>  -14 88<162 180>
>     VStem: 71 84<49 396>
>     Fore
>     195 742 m 0
>      195 738 193 736 189 736 c 0
>      175 736 155 743 155 682 c 0
>      155 661 130 249 130 131 c 0
>      130 100 96 99 96 131 c 0
>      96 149 71 662 71 682 c 0
>      71 731 51 736 37 736 c 0
>      33 736 31 738 31 742 c 0
>      31 748 36 747 38 749 c 1
>      188 749 l 1
>      190 747 195 748 195 742 c 0
>     80 32 m 0
>      81 53 95 75 116 74 c 0
>      137 73 150 53 150 32 c 0
>      150 10 137 -14 115 -14 c 0
>      93 -14 79 10 80 32 c 0
>     EndSplineSet
>     EndChar

The first line names the character, the next line gives the encoding, first in the current font, then in unicode. Then the advance width.

Then a set of flags (there are currently four flags: "H" => the character has been changed since last hinted, "M" the character's hints have been adjusted manually, "W" the width has been set explicitly, and "O" => the character was open when last saved).

Then horizontal and vertical (postscript) stem hints (set of several two number pairs, the first number in the pair is the location of the stem, the next number is the width of the stem, the numbers in brokets (<>) indicate where the hint is valid).

For fonts with vertical metrics there may also be a

>     VWidth: 1000

specifying the vertical advance width.

The entry `Fore` starts the foreground splines, they are encoded as postscript commands with moveto abbreviated to m, curveto to c and lineto to l (lower case el). The digit after after the letter is a set of flags whose bits have the following meanings:

mask | meaning
--- | ---
0x3 | indicates whether the point is curve (0), corner (1) or tangent (2).
0x4 | point selected
0x8 | point has default next control point
0x10 | pont has default prev control point
0x20 | point is to be rounded in x (truetype hinting. doesn't really work)
0x40 | point is to be rounded in y (truetype hinting. doesn't really work)
0x80 | point was interpolated between two control points (when read from a ttf file) and so has no point number of its own

Splines for a truetype font will have two additional numbers after the flags. These are the truetype point numbers for the point itself and for the subsequent control point. If the value is -1 then this point has no number.

Splines for a font with hint substitution will have a hint mask after any point before which hint substitution occurs,

>     459 422 m 1xc0
>      339 442 l 1xa0
>      312 243 l 1

So the first two points have hint masks "xc0" and "xa0", these masks may be (almost) arbitrarily long, depending on the number of hints in the glyph. "xc0" means that the first two hints are active (0x80 & 0x40) while "xa0" means that the first and third are (0x80 and 0x20).

A set of splines in the background is similar, it will be introduced by a `Back` entry.

While a background image is stored in the following horrible format:

>     StartChar: A
>     ...
>     Image: 167 301 0 21 2 1 23 753 2.53892 2.53892
>     J:N0SYd"0-qu?]szzz!!#7`s7cQozzz!!!!(s8Viozzzz"98E!zzzz!!3-"rVuouzzz!!!'"
>     s8N'!zzz!!!!$s8W,7zzzz"98E$huE`WzJ+s!Dz!"],0s6p!g!!!!"s8W-!n,NFg!!!Q0s8Vio
>     z5QCc`s82is!!!!`s8W,gz!WW3"s8W&uzJ,fQKp](9o!!iQ(s8W-!z!<<*!s7cQo!!",@s8W-!
>     ...
>     EndImage
>     EndChar

Where the numbers on the image line mean respectively: width (of image in pixels), height, image type (0=>mono, 1=>indexed, 2=>true), bytes per line, number of color entries in the color table, the index in the color table of the transparent color (or for true color images the transparent color itself), the x and y coordinates of the upper left corner of the image, the x and y scale factors to convert image pixels into character units. Then follows a bunch of binary data encoded using Adobe's Encode85 filter (See the PostScript Reference manual for a description). These data contain all the colors in the color table followed by a dump of the image pixel data.

Bitmap data will be compressed by run length encoding. I'm not going to go into that in detail, if you want to understand it I suggest you look at the file sfd.c and search for image2rle to see how it is done. The image is compressed using rle and then output as above, only now there is one more parameter on the "Image:" line which gives the number of bytes to be read from the data stream.

A character need not contain any splines:

>     StartChar: semicolon
>     Encoding: 59 59
>     Width: 264
>     Flags:
>     HStem:
>     VStem:
>     Ref: 44 N 1 0 0 1 0 0
>     Ref: 46 N 1 0 0 1 0 414
>     EndChar

Above is one with just references to other characters (a semi-colon is drawn here by drawing a comma and stacking a period on top of it). The first number is the local encoding of the character being refered to, the N says the reference is not selected, the remaining 6 numbers are a postscript transformation matrix, the one for comma (44) is the identity matrix, while the one for period (46) just translates it vertically 414 units.

A postscript glyph may also contain countermasks:

>     StartChar: m
>     Encoding: 109 109 77
>     Width: 785
>     HStem: 0 18<28 224 292 488 566 752> 445 27<280 296 542 558>
>     VStem: 98 56<45 376> 362 56<45 378> 626 56<45 378>
>     CounterMasks: 1 38
>     ...
>     EndChar

The CounterMasks line in this example declares one counter group (first argument). The "38" (and any other values following it) is a bitmask, given in hex, that describes a group. The size of the bitmask is always a multiple of eight (i.e. always an even number of hex digits). The highest-order bit in the mask specifies whether the first stem hint is present (1) or absent (0) in the counter group. The second-highest-order bit does the same for the second hint, and so on. Any extra low-order bits not corresponding to any hint are ignored. (I know, starting from the high bit instead of the low bit seems strange, but that was Adobe's design decision.) Here, the third (0x20), fourth (0x10) and fifth (0x08) stem hints (i.e. the three vertical stems) are in the group, yielding a counter mask of 0x38. If we were to add four more VStem hints to the glyph, making nine hints in all, then the mask would have to be given as 0x3800 (because two bytes are needed to accommodate nine bits).

If a font has been loaded from a truetype file it may containing hinting information (FontForge does not attempt to understand truetype hints, just to preserve them)

>     TtfInstrs: 107
>     5Xtqo&gTLA(_S)TQj!Kq"UP8<!<rr:&$QcW!"K,K&kWe?(^pl]#mUY<!s\f7"U>G:!%\s-3WRec
>     $pP.r$uZOWNsl$t"H>'?EW%CM&Cer:&f3P>eEnad5<Qq=rQYuk3AE2g>q7E*
>     EndTtf

This is 107 bytes of Enc85 encoded binary data.

If the character contains Anchor Points these will be included:

>     AnchorPoint: "bottom" 780 -60 basechar 0
>     AnchorPoint: "top" 803 1487 basechar 0

the point names the anchor class it belongs to (in UTF-7), its location, what type of point it is (basechar, mark, baselig, basemark, entry, exit), and for ligatures a number indicating which ligature component it refers to.

If the user has set the glyph class

>     GlyphClass: 2

Where the number is 1 more than the 'GDEF' glyph class it represents. (so the 2 above means a base glyph (class 1)).

If the character is the first in any kern pairs (not a pair defined by a kern class, however)

>     KernsSLIF: 114 -100 1 0 117 -92 1 0 101 -123 1 0 97 -107 1 0 111 -107 1 0

Where each kern pair is represented by 4 numbers. The first is the encoding of the second character (using the current encoding for the font), the next is the horizontal kerning amount, then the script lang index, and finally the open type flags. Then we start over with the next kernpair.

Data that are to go into other GPOS, GSUB or GDEF sub-tables are stored like this:

>     Position: 12 0 'sinf' dx=0 dy=-900 dh=0 dv=0
>     Ligature: 12 0 'frac' one slash four
>     Substitution: 12 3 'smcp' agrave.sc
>     AlternateSubs: 12 0 'swsh' glyph490 A.swash
>     MultipleSubs: 12 0 'ccmp' a grave
>     Ligature: 12 4 'liga' f f
>     LCarets: 0 0 '    ' 1 650

In most of these lines the first two numbers provide a script lang index and a set of opentype flags (except for LCarets where they are ignored). This is followed by an opentype tag (also ignored for ligature carets). A simple position change is expressed by the amount of movement of the glyph and of the glyph's advance width. A ligature contains the names of the characters that make it up. A simple substitution contains the name of the character that it will become. An alternate sub contains the list of characters that the user may choose from. A multiple substitution contains the characters the current glyph is to be decomposed into. A ligature caret contains a count of the number of carets defined, and the a list of the locations of those carets.

A glyph may have an arbitrary comment associated with it, this will be output in UTF-7

>     Comment: Hi

or a color

>     Colour: ff0000

#### Outline character extensions for multilayered fonts (type3)

(these are only supported if FontForge has been configured for multi-layered editing)

Instead of having a single "Fore"ground layer, multilayered fonts have (potentially) several layers, each one introduced by a Layer line which specifies things like filling and stroking info for this layer, within each layer are a splineset, a list of references and a list of images (any or all may be omitted). The syntax for these is the same as in the normal case above.

>     LayerCount: 3
>     Layer: 1  1 1 1  #fffffffe 1  #fffffffe 1 40 round round [1 0 0 1] []
>     SplineSet
>     ...
>     EndSplineSet
>     Layer: 2  1 0 1  #00ff00 1  #0000ff 1 19 miter butt [0.5 0 0 1] [10 5]
>     SplineSet
>     ...
>     EndSplineSet

The LayerCount line gives the number of layers in the glyph (the background layer is layer 0, so this number is one more than the number of layers that will actually be specified -- the background layer is still specified the way it was before, but is included in this count). This line is not required, if omitted (or wrong) FontForge will figure that out.

The Layer line contains too much information. First is a number saying which layer, next are three booleans, the first specifies whether to fill the splineset (or use an imagemask for images), the second whether to stroke the splineset, the third is currently pretty much meaningless. Next follows the RGB value of the fill color (the special value of #fffffffe means the the color is inherited), then the opacity (the special value -1 means inherited), then the stroke color and opacity. Then the stroke width (again -1 means inherited), the linejoin type (miter, round, bevel, inherited), the linecap type (butt, round,square,inherited), the transformation matrix to be applied to the pen and finally the dash array.

Any SplineSet, Ref, Images between this Layer and the next (or the end of the character) are part of this layer.

### Bitmap Fonts

After all the outline characters have been described there is an EndChars entry and then follow any bitmap fonts:

>     EndChars
>     BitmapFont: 12 285 10 2 1
>     BDFChar: 32 3 0 0 0 0
>     z
>     BDFChar: 33 3 0 1 0 9
>     ^d(.M5X7S"!'gMa

The bitmap font line contains the following numbers: the pixelsize of the font, the number of potential characters in the font, the ascent and the descent of the font and the depth of font (number of bits in a pixel). This is followed by a list of bitmap characters, the bitmap character line contains the following numbers: the encoding (local), the width, the minimum x value, the minimum y value, the maximum x value and the maximum y value. This is followed by another set of binary data encoded as above there will be (ymax-ymin+1)* ((xmax-xmin+8)/8) (unencoded) bytes, there is no color table here (the high order bit comes first in the image, set bits should be colored black, clear bits transparent).

A bitmap font is ended by:

>     EndBitmapFont
>     BitmapFont: 17 285 14 3 1
>     BDFChar: 0 17 0 0 0 0
>     z
>     ...
>     EndBitmapFont
>     EndSplineFont

### CID keyed fonts

A CID font is saved slighlty differently. It begins with the normal font header which contains the information in the top level CID font dictionary. As mentioned above this will include special keys that specify the CID charset (registry, ordering, supplement). It will also include:

>     CIDVersion: 2.0
>     BeginSubFonts: 5 8318

The `CIDVersion` is self-explanatory. The `BeginSubFonts` line says that there are 5 subfonts the largest of which contains slots for 8318 characters (again some of these may not be defined). This will be followed by a list of the subfonts (dumped out just like normal fonts) and their characters. Only the top level font will contain any bitmap characters, anchor classes, etc.

### Multiple Master fonts

Multiple master fonts start with a different style of file header, and are followed by a set of sub fonts. If the mm font has 4 instances then there will be 5 subfonts (one for each instance, and one for the blended font). The font header looks like:

>     SplineFontDB: 1.0
>     MMCounts: 4 2 0 0
>     MMAxis: Weight Width
>     MMPositions: 0 0 1 0 0 1 1 1
>     MMWeights: 0.31502 0.13499 0.38499 0.16499
>     MMAxisMap: 0 2 0=>50 1=>1450
>     MMAxisMap: 1 2 0=>50 1=>1450
>     MMCDV:
>     {
>     1 index 1 2 index sub mul 3 1 roll
>     1 2 index sub 1 index mul 3 1 roll
>     1 index 1 index mul 3 1 roll
>     pop pop
>     0 1 1 3 {index add} for 1 exch sub 4 1 roll
>     }
>     EndMMSubroutine
>     MMNDV:
>     {
>     exch 50 sub 1400 div
>     exch 50 sub 1400 div
>     }
>     EndMMSubroutine
>     BeginMMFonts: 5 0

The "MMCounts" line gives the number of instances (4) and the number of axes (2) in this font also whether it is an apple distortable font (0) and if so the number of named styles (0) in that font. The "MMAxis" line gives the names of the axes. The MMPositions line is an array of real numbers (with instance_count*axis_count elements) describing the coordinates of each instance along each axis. The MMWeights line provides the weights (blends) of the instance fonts to which, when interpolated, yield the default font. There will be one AxisMap line for each axis, it provides the mapping from design space to normalized space. The first line

>     MMAxisMap: 0 2 0=>50 1=>1450

says that axis 0 has two mapping points. One is at normalized position 0 and corresponds to design position 50, the other is at normalized position 1 and corresponds to design position 1450. There are two subroutines stored here, both are simple postscript. The first is the /NormalizeDesignVector routine and the second is the /ConvertDesignVector routine.

Finally we have the actual instance fonts.

Fonts with information for Apple's '*var' tables ('fvar', 'gvar', 'avar' and 'cvar') have a slightly different format:

>     MMCounts: 8 2 1 10
>     MMAxis: Weight Width
>     MMPositions: 1 0 -1 0 0 1 0 -1 -1 -1 1 -1 1 1 -1 1
>     MMWeights: 0 0 0 0 0 0 0 0
>     MMAxisMap: 0 3 -1=>0.479996 0=>1 1=>3.2
>     MacName: 0 0 6 "Weight"
>     MacName: 0 1 15 "Type de graisse"
>     ...
>     MMAxisMap: 1 3 -1=>0.619995 0=>1 1=>1.3
>     MacName: 0 0 5 "Width"
>     MacName: 0 1 7 "Largeur"
>     ...
>     MMNamedInstance: 0  3.2 1
>     MacName: 0 0 5 "Black"
>     MacName: 0 1 9 "Tr\217s gras"
>     ...

In Adobe's format coordinates range between [0,1], while in Apple's format they range [-1,1]. Adobe generally specifies 2 instances per axis (at the extrema) while Apple expects 3 (the extrema and the default setting at 0). So a two axis font for Adobe will normally contain 4 instances and a default version, while one for Apple will contain 8 instances and a default version. The MMWeights field is irrelevant for Apple. Each axis has a set of names, for that axis translated into various languages. Finally Apple allows certain points in design space to be given names, here the point Weight=3.2, Width=1 is named "Black" or "Trés gras".

## Autosave Format

Error recovery files are saved in ~/.FontForge/autosave, they have quite random looking names and end in .asfd. They look very similar to .sfd files above.

If an asfd file starts with a line:

>     Base: /home/gww/myfonts/fontforge/Ambrosia.sfd

Then it is assumed to be a list of changes applied to that file (which may be an sfd file or a font file). If it does not start with a "`Base:`" line then it is assumed to be a new font. The next line contains the encoding, as above. The next line is a `BeginChars` line. The number given on the line is not the number of characters in the file, but is the maximum number that could appear in the font. Then follows a list of all changed characters in the font (in the format described above).

Bitmaps are not preserved. Grid changes are not preserved.

-- Prev -- TOC -- Next --