wezterm/wezterm · error

Failed to get font data

Error message

Failed to get font data

What it means

In the Windows GDI locator, extract_raw_font_data calls GetFontData twice: once for the 'ttcf' table (TrueType Collection) and once for the whole file. If both calls return 0 or GDI_ERROR, the HFONT has no byte stream GDI can expose, and the function bails. GetFontData only works for TrueType/OpenType fonts backed by a readable file; it fails for Type 1, vector, bitmap (.FON/.FNT) and some cloud-streamed fonts.

Source

Thrown at wezterm-font/src/locator/gdi.rs:58

        let ttc_size = GetFontData(hdc, ttc_table, 0, std::ptr::null_mut(), 0);

        let data = if ttc_size > 0 && ttc_size != GDI_ERROR {
            let mut data = vec![0u8; ttc_size as usize];
            GetFontData(hdc, ttc_table, 0, data.as_mut_ptr() as *mut _, ttc_size);

            Ok(data)
        } else {
            // Otherwise: presumably a regular ttf

            let size = GetFontData(hdc, 0, 0, std::ptr::null_mut(), 0);
            match size {
                _ if size > 0 && size != GDI_ERROR => {
                    let mut data = vec![0u8; size as usize];
                    GetFontData(hdc, 0, 0, data.as_mut_ptr() as *mut _, size);
                    Ok(data)
                }
                _ => Err(anyhow::anyhow!("Failed to get font data")),
            }
        };
        DeleteDC(hdc);
        let data = data?;

        Ok(FontDataSource::Memory {
            data: Arc::new(data.into_boxed_slice()),
            name: name.to_string(),
        })
    }
}

fn extract_font_data(
    font: HFONT,
    attr: &FontAttributes,
    pixel_size: u16,
) -> anyhow::Result<ParsedFont> {
    let source = extract_raw_font_data(font, &attr.family)?;

View on GitHub (pinned to 9c04f79f86)

Solutions

1. Identify the failing family from the adjacent log line and remove or reinstall that font as a proper TTF/OTF (right-click -> Install on the .ttf file)
2. Replace legacy .FON/Type-1 fonts with modern equivalents (e.g. Cascadia Mono, JetBrains Mono)
3. If the font is optional, point wezterm at a known-good TTF via font_dirs + wezterm.font in wezterm.lua so discovery of the broken font does not matter

# before pointing wezterm at a font, confirm GDI can expose its data
powershell "(Get-Item 'C:\Windows\Fonts\MYFONT.TTF').Length"  # must be a real TTF/OTF/TTC file, not a .FON/.PFM stub

When it happens

Trigger: GdiFontLocator processes an installed system font whose data GDI cannot read: legacy bitmap/vector fonts, Type-1 .PFB fonts, fonts stubbed by cloud/subscription font services, or a corrupted font file. The error names the family in surrounding logs and that font is skipped from discovery.

Common situations: Windows boxes with old bitmap fonts (e.g. legacy terminal/FON fonts) or enterprise font-management agents installed. The rest of wezterm keeps working; the message appears during startup font enumeration and users hit it when the skipped font was the one they configured.

Related errors

• No font matching {:?} in {:?}
• failed to create symlink {} -> {}: {err:#}
• invalid encoding for command line argument {:?}
• shared memory is not NUL terminated!

AI-assisted analysis of wezterm/wezterm@9c04f79f86 (2026-08-16). Data as JSON: /api/errors/e0ced2ef84fe8938. Report an issue: GitHub.