The User Data Folder and Customizable Data Files

FontLab's editable data files let you tailor naming, encoding, character ranges, and glyph-generation behavior without modifying the application bundle. Keep overrides deliberate and documented, because they can affect automatic operations across many fonts.

Understanding the User Data Folder

FontLab uses several data locations, from local/user-specific resources toward shared and bundled defaults:

Location Main role
Local data folder Automatically written recovery and session data, including Sketchboard state.
User data folder Your primary customization files, scripts, and additional packages.
Shared user data folder Resources shared by FontLab applications for the current user.
Shared app data folder Machine-wide shared resources.
App data folder The installed application's bundled defaults.

Resource lookup generally gives more specific overrides precedence over bundled data. Do not assume every file is merged across all locations: a matching override can replace the default resource rather than add a few entries to it.

Use Preferences > General > Open user data folder to locate the effective folder. This is more reliable than copying a version-specific path from another installation.

On macOS, the default user data folder is ~/Library/Application Support/FontLab/FontLab 9/. On Windows, it is the Documents folder’s FontLab\FontLab 9 subfolder. A configured User data folder can replace that default.

Recovery and Sketchboard data use the fixed FontLab 9 application-data directory: under ~/Library/Application Support/FontLab/ on macOS or %LOCALAPPDATA%\FontLab\ on Windows. Shared resource searches can also include the platform’s shared-user and machine-wide locations, such as /Library/Application Support/FontLab/ or C:\ProgramData\Fontlab\.

Relocate customization data

FontLab does not automatically transfer the existing files when you relocate the User data folder. Open the current folder, copy the required customization files and subfolders to the new location, then set that path in Preferences > General and restart. Reopen the effective folder and test a known naming or construction case to confirm that the intended resources are active.

Local recovery/autosave remains separate from a relocated customization folder. A shared or network folder should not be assumed to contain the only recovery copy of current work.

A team can share controlled customization resources, but coordinate changes so one person's edit does not silently change another person's glyph generation or naming. Scripts can read the configured path through flPreferences().dataPath; recall The Python API and Libraries. The Scripts subfolder supplies the script library from Python Scripting. Python packages use a version-qualified python/<version>/site-packages search location; verify the actual path in FontLab’s Python environment.

Do not edit bundled resources in place. Updates can replace them, and a modified application installation makes the project harder to reproduce.

Customizable Data Files

File User-data location Controls
uranges.dat Data/ Unicode-range definitions used by relevant selection/display tools.
.cpg files Codepage/ Legacy byte-to-Unicode codepage definitions.
.enc files Encoding/ Named, ordered glyph sets used by Encoding views.
alias.dat Data/ Glyph-generation and automatic-construction rules.
standard.nam or another active .nam Selected through naming preferences Glyph-name and Unicode mapping conventions.

Start from an appropriate supplied file, preserve its required identification/header syntax, and edit a copy in the customization location. Restart FontLab after adding .enc or .cpg resources or changing the active standard.nam mapping, then test a small known case before using the override broadly.

Encoding and naming workflows

An .enc file lists glyph names in a deliberate order. Use distinct encoding names and clear %%GROUP: labels. FontLab’s exporter writes -1 in the numeric header position, as shown in Saving and Reusing Filters; preserve an exported header rather than interpreting repeated -1 values as duplicate names. Export ordering follows the applicable font-view order, so arrange the source before writing the file.

The encoding export can derive its group label from family naming. Prefer editing the file's group header when only the menu grouping should change; if you temporarily change a font's Family name for that workflow, restore its real identity before saving or exporting the font.

Two parallel encodings can support a controlled rename between naming conventions. Their corresponding positions must refer to the same glyph identities. Review the full mapping, retain the original source, and use the custom rename-by-encoding route deliberately; a mismatched order can rename the wrong glyphs.

The active .nam file has a broader role in name/Unicode interpretation. Changing it is an expert customization, not a local caption edit. Check name generation, Unicode assignment, and dependent constructions afterward.

Construction and coverage resources

alias.dat supplies construction rules used by glyph generation and auto layers. Keep the recipe syntax valid and preserve any default rules still needed when replacing the resource. An override is not guaranteed to merge every unchanged rule from the bundled file automatically.

uranges.dat and .cpg affect how FontLab groups or interprets character coverage. They do not add outlines to a font or prove that its language support is complete.

Keep these files with the project's dependency documentation when their behavior is required for handoff. Record which version is active, how it differs from the default, and which representative glyphs or mappings should be checked after an update.

Encoding filters and saved lists are taught in Font Filters and Saving and Reusing Filters. Recipe syntax belongs to Using Recipes for Composite Building; alias.dat is its customizable file source. The standard.nam mapping was introduced in Managing Glyph Names and Codepoints.