UFO file format specification 1.0

The Unified Font Object (or UFO) is a file format for font and glyph related data. UFO intends to store all font related data in readable, standardised XML files.

The UFO format is:

*.ufo/

file name description required
metainfo.plist contains format version, save date, etc. yes
fontinfo.plist contains various font info data yes
groups.plist contains glyph group definitions no
kerning.plist contains kerning info no
lib.plist custom data, this is the FontLib no
glyphs/ a folder containing .glif files and a contents.plist file. See Glyph Interchange Format yes

metainfo.plist

A Property List file, with a dictionary at the top level. Currently defined key/value pairs:

field name description
creator fileCreator, a string identifying the software that create the ufo file.
formatVersion the version number of the ufo format as an integer. Currently 1.

fontinfo.plist

A Property List file, with a dictionary at the top level. Tentatively defined key/value pairs:

field name description
ascender ascender value, an integer
capHeight cap height value, an integer
copyright copyright string, a string
createdBy field for the creator for the font, i.e. the foundry
defaultWidth value for default width of missing glyphs, an integer
designer name of the designer, a string
designerURL web address for the designer, a URL
familyName family name of the font, a string
fondID MacOS FOND resource number, an integer
fondName MacOS FOND name, a string
fontName font name, a string
fontStyle the font style code, integer
fullName the full name of the font, a string
parent reference to the parent object (a font usually)
italicAngle the italic angle, integer
license the font license text, a string
licenseURL web address for the license agreement, a URL
menuName one of the menu names, a string
msCharSet flag for windows fonts
note the font note, a string
notice a notice about the font, different from note and copyrright, a string
otFamilyName family name specific for OpenType fonts a string
otStyleName style name specific for OpenType fonts, a string
otMacName Mac name specific for OpenType fonts, a string
selected whether or not the font is selected, a boolean
slantAngle slant angle, different from italic angle, an integer
styleName the style name, a string
trademark the trademark statement, a string
ttUniqueID unique ID for TrueType fonts, an integer
ttVendor Microsoft vendor code, a 4 character string
ttVersion which truetype version
uniqueID unique PostScript ID number, an integer
unitsPerEm units per em, integer
vendorURL web address for the font’s vendor, a URL
versionMajor value for major version
versionMinor value for minor version
weightName the name of the weight, i.e. “Semi Bold”, used in naming stuff.
weightValue value for the weight. FontLab calls Regular 500 (or something like that)
widthName the name of the width, i.e. “Condensed”
year the year in which the font was produced

Version 2 of fontInfo.plist is being sketched out over at [“UFOFontInfo2”].

groups.plist

A Property List file, with a dictionary at the top level. Keys are group names, values are arrays containing glyph name strings. This file is optional.

kerning.plist

A Property List formatted file, with a dictionary at the top level. Keys are “first glyph” glyph names, values are dictionaries that contain “right glyph” glyph names as keys, and the kern value as the value, which may be an integer or a float. Names defined in the groups.plist may also be used in place of glyph names. This file is optional.

lib.plist

This is the FontLib; it’s a Property List formatted file, with a dictionary at the top level. Top-level keys must follow the ReverseDomainName convention. This file is optional.

glyphs/

Folder containing .glif files. Must also contain a contents.plist file. See Glyph Interchange Format.

glyphs/contents.plist

All .glif files for a font files are usually kept together inside a directory.
Such a directory may contain a file named “contents.plist”, which contains
a dictionary that maps glyph names to file names. Those file names must
plain file names, not absolute or relative paths in the file system. Care
must be taken when choosing file names: glyph names are case sensitive, yet
many file systems are not. A simple scheme that appears to work in practice
for Adobe-style glyph names, is to take the glyphs base name, and add an
underscore if the name starts with a cap. Where “base name” means the first
component when split on ”.”. Examples: a.glif, A_.glif, a.alt.glyph,
A_.alt.glyph.