This page is often grievously out of date. It was a fair approximation to reality on 24 Feb 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)
PfaEdit'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.
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:
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 explaination:
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 PfaEdit 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 PfaEdit'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 explaination 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 implicitily 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 PfaEdit has generated itself
GenTags: 1 sb'rigl'
This line says that PfaEdit 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
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) arbetrarily 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 accomodate nine bits).
If a font has been loaded from a truetype file it may containing hinting information (PfaEdit 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: "botom" 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 arbetrary comment associated with it, this will be output in UTF-7
Comment: Hi
or a color
Colour: ff0000
(these are only supported if PfaEdit 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] 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) PfaEdit 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) and finally the transformation matrix to be applied to the pen.
Any SplineSet, Ref, Images between this Layer and the next (or the end of the character) are part of this layer.
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
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-explanitory. 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 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
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. 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.
Error recovery files are saved in ~/.PfaEdit/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/pfaedit/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.