This release of the Adobe Font Development Kit for OpenType (AFDKO) contains a set of tools used to make OpenType fonts by adding the OpenType-specific data to a TrueType or Type1 font. It does not offer tools for designing or editing glyphs. These command-line programs will allow you to build an OpenType font from an existing font, verify the contents of the font, and proof the font on screen or on paper. The AFDKO also contains useful technical documentation and some example font source material. Note! Although the FDK directory tree contains a number of Python scripts, none of them can be used by double-clicking on them; they can only be called by typing commands into a command-line window.
See the file "Read_Me_First.html" in the FDK main directory for installation instructions.
Once the AFDKO is installed, all the command-line programs can be run by entering the command name in a Terminal window (OSX, Windows, Linux), along with the necessary option text. All command-line tools provide usage and help text with the options -u and -h. There is a separate user documentation file only for the makeotf tool. Using a command-line window may seem alarming if you are not used to it, but it is actually quite easy to learn a useful set of commands. Please read the FDK documentation "CommandLineHowTo.pdf", sub-titled "The Joys of Command Line", for pointers on how to get started.
The tools fall into several different functional groups.
This program is the Adobe auto-hinter. It can be applied to both OpenType/CFF and Type 1 fonts. Works with Type 1 and OpenType/CFF fonts only. It uses Just von Rossum's fontTools Python package for accessing and changing the font data.
This is a variant of 'tx' that will scale fonts to a different em-square size, or snap-shot a Type 1 MM font to a single-master Type 1 font, while using hinting to keep stems aligned. It can be used alone, but is most often called from the 'makeInstances' script.
This program will build an OpenType/CFF font from a feature file that defines the OpenType layout rules, and overrides for default values, and a font file: a Type 1 font, TrueType font, 'detype1' text version of a Type 1 font, or UFO font and It also requires some other meta-data files. It will also build an OpenType/TTF font from a TrueType source font file.
This script will generate Type 1 fonts from an MM Type 1 font, using a tab-delimited file to set values in the instances. It offers several advantages over using tx or FontLab alone.
This program will merge glyphs from one font into another, optionally copying a subset from the source fonts, and changing the names of the glyphs. It can also be used to subset and change the glyph names in a font. By using the same font more than once as a source with different mapping files, glyphs can be duplicated under other names. It can also convert a named-keyed font to a CID-keyed font.
This tool will rotate and translate glyphs in a font, including the hints. However, hints will be discarded if the rotation is not a multiple of 90 degrees.
This allows you to cut and past the entire binary block of a font table from one font to another. You do this by first using it on a source font with the "-x" option to copy a table from the source font to a separate file, and then using it with the "-a" option to add that table to a target font. It can also be used to simply delete a table, and to fix the font table checksums.
This program provides reports which help in selecting the global hint data and alignment zones for Type 1 hinting. You should look at the reports from this tool in order to select the most common stem widths, and then use a program such as FontLab or Robofont to set the values in the font. This should be done before hinting the font. Works with Type 1 and OpenType/CFF fonts only.
This PERL script program takes in the report from stemHist, and recommends a set of values to use for the Type 1 font standard stem arrays. This is not as good as choosing the most relevant values yourself, but better than not providing any values. This script depends on having the Perl interpreter installed, which is not installed by default on Windows. You can get the Perl interpreter from: http://www.perl.com.
This tool can dump all or a few tables from an OpenType font to a human-readable text XML file, and can compile this XML file back to full OpenType font. It is an ideal tool for making simple changes of a few values. Used with care, it can also be used to make extensive changes. This is tool is provided by Just von Rossum as part of the fontTools library. It is provided here for convenience, in a form that does not require an installed Python interpreter.
This tool can be used to convert most font formats to CFF or Type 1 fonts. TrueType fonts will lose their hinting in the process. It cannot convert from PostScript to TrueType, and cannot rasterize TrueType fonts. When used to convert from a Type 1 or CFF font, it undoes subroutinization, so that each glyph contains all the drawing operators, rather than referring to subroutines for common path elements. However, it does have an option to apply subroutinization to the output font.
These two programs will respectively compile and decompile a Type 1 font from a plain-text representation that is easy to edit. This is good for fixing individual fields. It is also good for copying a specific path element to many glyphs.
This program can report data from an OpenType font in a variety of ways. All tables can be shown as a text report of the low-level structure of the table. Most tables can be shown with a report in a more human-readable format. Some tables, including the GPOS and GSUB layout tables can be shown graphically, by outputting a PostScript file that can be sent to a printer, or viewed in Mac OSX Preview, Adobe Acrobat or Adobe InDesign.
This tool has two modes that are useful for proofing. With the "-bc" option, it will rasterize a glyph to the command-line window, using ASCII characters. This is surprisingly useful when you want a quick look at a glyph. With the "-pdf" option, it will write a pdf file which shows the glyphs in the font, either 320 per page or 1 per page.
The XML format output offers a useful report for most of the data in an OpenType font.
Make a pdf file showing all the glyphs in the font. Shows one glyph per page. Shows the nodes and control points.
Make a pdf file showing all the glyphs in the font. Format favored by CJK developers; shows a large filled outline, useful glyph metrics, and a larger outline with the nodes marked.
Make a pdf file showing all the glyphs in the font. This fills a page with many glyphs, and shows just the filled outlines at a small point size, with some info around each glyph. Works with OpenType fonts and Type 1 fonts.
Make a pdf file showing all the glyphs in in a list fonts. The glyphs are shown in glyph ID order, with a fixed spacing of one em, with the glyphs from one font in one line, so that all glyphs with the same glyph name from different fonts should be in a single column. This is used to visually confirm that that charsets are the same, and that glyph shapes are similar. It is useful for catching cases where a place-holder glyph outline was pasted in for a glyph name, but never corrected to the correct shape. The fonts are sorted first by length of character set, then by alphabetic order of the character sets, then by PostScript name.
Shows one glyph per page. Shows hints and alignment zones.
Shows a waterfall of point sizes for all glyphs in the font. This is used to evaluate hinting. In order to allow hinting to be seen, the font is embedded in the PDF, and glyphs are referenced by char code. Does not yet work with TrueType and CID-keyed fonts.
Note that the tools ending in "plot" are all simply small command-file scripts that call a single Python script with different options. The "-h" option for all these scripts will produce the same list of all the options supported by the single Python script. You can customize the PDF proofs by providing additional options. Look at the command files; these can by edited to supply additional options to the main script. This was completed shortly before the FDK was released, and has seen little use. It will improve over time. It uses the OpenSource Python package "Pickle" to create the PDF documents, and Just von Rossum's fontTools Python package for accessing the font data.
The auto-hinting program will report at length about hinting issues. Some of these you can ignore, such as reports about near misses when a stem could be controlled by a hint-zone but is just a little too wide or too narrow. By adjusting either the stem widths or the hint-zones according to these reports, you can include more stems in the set that are controlled by hints, but you can also reasonably decide that is not worth the effort. However, many complaints do need fixing, such not having nodes at vertical or horizontal extremes of a curve.
This tool will check the quality of the glyph outline data, and should always be used. It is very good at detecting serious problems, such as overlap and incorrect path direction. It is overly enthusiastic about finding a number of smaller issues, but is right often enough to be worth checking all the error messages. It can also fix the problems it finds, but you should always check any glyphs that it changed - the fixes are not always better than the original problem. It uses Just von Rossum's fontTools Python package for accessing and changing the font data.
The tool examines all the fonts in a directory and runs many quality checks. It is the only tool which checks consistency and compares data across a family of fonts, as well as in a single font. It will point out any errors in naming within a style-linked group. Every time the Adobe Type Department finds a bug in the Adobe OpenType fonts, we try to put a check in here. It is not a complete validation tool, but it does represents several years of experience of mistakes made by typographers.
This tool will report collisions between kern pairs, or, with the option -a, will report any collisions between any pair of glyphs. It will also report when rules in one GPOS table kern feature mask rules in a different subtable of the same lookup.
NOTE! the time needed is related to the square of the number of glyphs. This script will run in a few minutes for a font with 300 glyphs, but can take more than an hour for a font with 3000 glyphs.
This tool does a low-level comparison of two OpenType font files. It is most useful for quickly checking if two fonts are identical, or in which tables they differ.
The best way to see in detail how two fonts differ is to use the ttx tool to dump XML files, and then compare them with a good difference editor, such as BBEdit on the Mac, or UltraEdit on the PC. This tool was developed by Just von Rossum of LettError, and is available under OpenSource licensing from: http://sourceforge.net/projects/fonttools/
This tool is used to test if two fonts are functionally the same. It sorts and modifies the output from the ttx and tx tools to build a normalized text dump that eliminates differences due to issues such as OTL table record order, glyph order and subroutinzation differences. It writes one file for each table in the font. A good difference editor, such as BBEdit on the Mac, or UltraEdit on the PC, can then be used to compare the output files from two different fonts. It is particularly useful in comparing older and newer versions of the same font.
This tool has a couple of modes that are good for testing. It will show only data about the font program with in a font file, either CFF or TrueType. The "-dump" option is good for looking at a text report of the CFF font global and glyph data. The "-bc" option takes additional option that outputs a hash of the rasterized glyphs to a file. This good for finding if hinting has changed in a font; if the hash files for a set of glyphs are the same between two fonts, then the glyphs rasterized identically at the specified point size. You can use this to judge if fonts are functionally equivalent, even if the outlines are not exactly the same. Finally, converting any font to CFF will yield error reports if the font data is not syntactically correct, and if any glyphs are not hinted.
Inside the AFDKO are the following components:
For questions about use of the FDK tools, please try first the FontLab forums at http://forum.fontlab.com/. FontLab and the AFDKO share a common code base for creating GPOS and GSUB layout features, and many issues will be the same. AFDKO issues are specifically covered in the forum http://forum.fontlab. com/adobe/afdko/. An alternative forum for the AFDKO is the Google Groups mailing list UAFDKOML.
There is also a public forum to which general OpenType questions are often posted. Note that this is not for discussion of the AFKO tools; it is intended only for general issues related to the development and use of OpenType fonts. To subscribe to this list, send an e-mail to: opentype-migration-sub@ indx.co.uk
OpenType is a trademark of the Microsoft Corporation. Macintosh is a trademark of Apple Computer Inc. Adobe, the Adobe logo, Adobe Type Manager, PostScript, Adobe InDesign are trademarks of Adobe Systems Inc.