The Export Process
Export turns the editable source into a specific deliverable. Choose the content and technical policy deliberately, then inspect the files that were actually written.
Export Prerequisites
Carry the family-level QA from Organizing and Auditing Families through to the chosen output. Save the native source first and complete the metadata checks in Completing Font Metadata. Validate the intended character set using Encoding and Codepage views, not only a sample of visible glyphs. Review names, style links, dimensions, public version, authorship/license metadata and hinting policy.
Resolve relevant FontAudit findings (see Font Audit) and feature-compilation errors. Check anchors, kerning, components, and live constructions at representative locations. A warning can identify something to assess; the absence of warnings does not establish design quality.
For Instances output, verify the enabled instance list, locations, and names from Defining and Generating Instances. For a family, check glyph coverage and shared metadata across the selected members. Do not generate an explicit kern feature merely as a ritual prerequisite when the normal visual-kerning export route is intended.
Check the relationship between the source and each intended delivery. A static master, a generated instance, and a variable font can need different coverage or conversion choices. Inspect representative accented glyphs, ligatures, marks, and composite constructions at the locations that will be exported. Confirm that intended hints are present or that the profile deliberately generates them, using the PostScript and TrueType workflows already taught.
Keep a record of which source, profile, and content selection produced the release candidate. This makes a failed target test traceable to a specific build rather than to whichever file happens to be installed. The purpose of the prerequisite pass is to expose omissions before output conversion makes the editable relationships harder to inspect.
The Export Dialog
Choose File > Export Font As…. Select an active profile, or enable multiple profiles when the release requires several output types. If several fonts are open, confirm exactly which fonts are checked.
For single-style output, choose the source content:
| Choice | What it produces |
|---|---|
| Current layer | The selected layer/master's design for the static output. |
| Instances | Calculated static fonts at the enabled predefined locations. |
| Masters | Separate outputs from the selected master designs. |
Independent masters need not form a working interpolation model merely to export separately. A variable profile, by contrast, requires an appropriate compatible designspace and handles the variation source as a whole.
The Instances tab makes the intended static outputs explicit. Check the selected profile, enabled instances, destination, and existing-file policy before Export.
Inspect filenames before committing the export. The com.fontlab.masterFilename metadata can influence a master’s filename; otherwise the usual master-file fallback combines the VFC/VFJ source basename and master name. Masters output also supports development handoff as well as independent-style delivery. A file's name is not a substitute for checking its internal family/style identity.
Choose the destination: the source location or a custom folder, with optional family/profile subfolders. Then choose conflict handling. Overwrite replaces matching output, Skip leaves it alone, and rename or trash choices preserve/displace the existing file according to the dialog's policy. Use a clean release destination when ambiguity about an old file would complicate verification.
Click Export, review the completion notification and Output panel, and use the reported Finder/Explorer destination link when shown. Confirm that each intended font/profile combination produced its expected file before testing it.
Test an exported installation
For supported OpenType/variable profiles, Install fonts until FontLab quits makes the export temporarily available to other applications. It is the target-testing bridge from Proofing Environments, not a permanent release installer.
Applications can cache fonts. Reopening a document or restarting the target application may be necessary after another export. Verify the tested version rather than assuming an unchanged appearance means the new file was loaded.
Compiling Font Binaries
Export compilation brings the source’s different kinds of data into the forms the destination can use. The selected profile determines which conversions and generation steps run:
Before export, compile the layout document you intend to use. The last successful Compile features in Features or Compile in Lookups selects the source for normal previews and exported layout tables. A debugger run or an import between the panels does not change that choice. Applicable kerning and mark-generation settings still participate in the output. See Authoring OpenType Layout.
| Authored source | What the output receives |
|---|---|
| Last successfully compiled Features or Lookups document | Compiled GSUB substitutions and GPOS positioning, together with applicable generated layout data. |
| Visual kerning and classes | A GPOS kern feature; a separate legacy kern table when requested and supported. |
| Attachment anchors | mark and mkmk positioning when the generation policy calls for it. Named editing anchors become compiled attachment relationships and coordinates. |
| PostScript hints and TrueType programs | Hint data appropriate to the output, according to the preserve, generate, convert, or omit choices. Visual TT instructions must become native instructions for production TrueType output. |
| Auto layers, live filters, and strokes | Resolved drawing geometry. The delivered font uses the result rather than an editable FontLab recipe or filter control; suitable component structure may remain where the format supports it. |
| Contours and component placements | The target curve geometry and permitted composite structure, with configured rounding, cleanup, and overlap handling. |
| Font Info and family identity | Name records and fields in tables such as OS/2, head, and meta: style-link attributes, dimensions, embedding and coverage declarations, version, authorship, and supported descriptive data. |
Variation and color data also need representations supported by the chosen output. Inspect the generated font rather than assuming that every source setting has a direct counterpart in every format.
TrueType glyf output can retain suitable composites. CFF does not retain the same TrueType composite representation, so that content must be resolved appropriately. A source element reference or editable filter is not a production-format object simply because its appearance survives.
These operations follow the chosen settings. Mark features are not guaranteed merely because anchors exist, and custom positioning may be rebuilt if the profile requests generation.
Some unsupported source data is omitted; some conversions issue warnings or fail. Read the Output panel and export notifications, then use the reported destination to inspect the files. Zone conflicts, duplicate master locations, or compilation errors should not be dismissed as ordinary confirmation messages.
Reopening an export reconstructs an editable model from what was written. It can recover supported outlines, components, layout data, and native hints, but is not guaranteed to recreate the original source organization or every authored detail. Keep the native project and compare the delivered binary's behavior separately.
Export-profile controls are taught in Export Profiles, font/curve output in OpenType, Variable, and Web Fonts, and color output in Color Fonts. On reopening, Preferences > Open Fonts governs reconstruction; see Authoring OpenType Layout for layout, The TrueType Hinting Model and Workspace for native hints, and Coordinate Precision for fractional coordinates.