Adobe Font Development Kit for OpenType

MakeOTF is a command-line tool used to compile OpenType® fonts from source files and high-level OpenType layout feature descriptions. It is a compiler for font data, not a font editor.

Required Source Files

To build a font, MakeOTF typically requires the following files:

• font: A source font file (e.g., font.pfa or cidfont.ps). It can be Type 1, CID, TrueType, or OpenType/CFF. Only glyph outlines are extracted from this file.
• features: A text file containing OpenType layout feature rule definitions and overrides for OpenType table fields.
• FontMenuNameDB: A text file providing Windows and Mac menu names for the font.
• GlyphOrderAndAliasDB: A text file that establishes glyph ID order, allows for glyph name aliasing (mapping development names to final OpenType names), and provides Unicode® values.

Optional Files

• fontinfo: An optional file containing keywords that trigger specific MakeOTF options.

otfautohint is a Python-based port of the original C-based "Automatic Coloring" code (formerly known as psautohint). It is used for automatic hinting of OpenType fonts.

Key Characteristics

• Performance: Because it is written in Python, it is significantly slower than the original C version when hinting a single glyph. However, it uses the multiprocessing module to hint different glyphs in parallel across multiple CPU cores by default. On an 8-core machine, it is typically slightly faster than the C version.
• Compatibility: It supports hinting variable CFF-based fonts and directly hinting built CFF2 fonts.
• Behavioral Changes: Users migrating from psautohint should expect differences in results due to improved algorithms and a different encoding in UFO glif files. This is intended to be a one-time change.
• Memory Usage: It uses more memory than the C version, but it manages this by unpacking glyphs just before hinting and updating them immediately after to lower the peak memory footprint.

OpenType feature files can include anonymous (or abbreviated anon) tagged blocks of data. These blocks are used to pass custom or unsupported table information back to the implementation software. The parser does not attempt to parse the content inside these blocks; it simply extracts the data and the associated tag for the client.

Syntax Requirements:

• Use the keyword anonymous or anon followed by a <tag>.
• The block starts with an opening brace {.
• Crucial: The closing brace, the tag, and the semicolon must all reside on the same line (e.g., } <tag>;) to signal the end of the block to the parser.
• The include directive is not recognized inside an anonymous block; therefore, the entire block must be contained within a single file.

Data Extraction: The client receives the data starting from the first line after the opening brace up to (and including) the newline character immediately preceding the closing line.

# Using the 'anonymous' keyword
anon sbit {
    /* sbit table specifications */
    72  % dpi
    sizes {
        10, 12, 14 source {
            oall "Generic/JGeneric"
        }
    }
} sbit;

A <valuerecord> is used in positioning rules to adjust metrics (x/y placement and x/y advance). There are several formats:

• Format A (Simple): A single <metric>. Represents an x advance adjustment (or y advance in vkrn, vpal, vhal, or valt features). Example: -3.
• Format B (Variable): (<metric> <location>:<metric> <location>:<metric> ...). A bare metric is for the default instance. Example: (-3 wght=200u:-5 wght=900u:-2).
• Format C (Four-part): <<(v)metric> <(v)metric> <(v)metric> <(v)metric>>. Order is: x placement, y placement, x advance, y advance. Example: <-80 0 -160 0>.
• Format D (Combined): (<<metric> <metric> <metric> <metric>> <location>:<<metric> <metric> <metric> <metric>> ...). Combines B and C for multiple locations.
• Format G (Named): <name>. Uses a name defined via valueRecordDef and must be enclosed in angle brackets.

# Format A
-3

# Format B
(-3 wght=200u:-5 wght=900u:-2)

# Format C
<-80 0 -160 0>

# Format D
(<-80 0 -160 0> wght=200u:<-80 0 -140 0> @ExtraBlack:<-80 0 -180 0>)

# Format G
<KERN_POS_1>

The OpenType Layout engine performs substitutions (GSUB) and positionings (GPOS) using a specific algorithm. A critical concept for feature file authors is that each lookup corresponds to one "pass" over the glyph run.

Each lookup takes the accumulated result of all previous lookups in the LookupList as its input. This means the order in which lookups appear in your feature file directly affects the state of the glyph run for subsequent lookups.

The Layout Algorithm Summary

1. Language System Check: All glyphs in the run must belong to the same language system.
2. Feature Assembly: All features (including required features) for the language system are assembled.
3. Lookup Assembly: All lookups in those features are assembled in LookupList order, removing duplicates.
4. Lookup Execution: For each lookup, the engine iterates through the glyph run. If a lookup is applied and the lookupflag does not indicate the glyph should be ignored, the engine checks the lookup's subtables.
5. Subtable Matching: If a subtable's target context (input sequence, backtrack, and lookahead) is matched, the substitution or positioning is performed.
6. Contextual Lookups: For (chain) contextual lookups, the engine follows the Subst/PosLookupRecord order defined in the subtable.
7. Sequence Advancement: After a match, the engine moves to the glyph following the matched input sequence.