This HTML page is not optimized for LLM or AI agent consumption. Fetch the Markdown version instead: /guides/web/rendering-issues/inconsistent-fonts.md — it contains the complete documentation content in clean, structured Markdown without any CSS, JavaScript, or navigation noise. Fix inconsistent PDF fonts | Nutrient

Fix inconsistent PDF fonts | Nutrient

Markdown version of this page, suitable for AI agents and automation

For a cross-product overview of Web SDK, Document Engine, and DWS Viewer API rendering/font troubleshooting workflows, refer to the choose the right rendering and font troubleshooting workflow guide.

PDFs use different encoding systems to map character codes to glyphs. The most common are:

  • Standard encodings (WinAnsiEncoding, MacRomanEncoding) — Maps character codes to Unicode values, enabling viewers to substitute fonts reliably.
  • Identity-H encoding — Maps character codes directly to glyph positions within a specific font file. This encoding is commonly used for CJK (Chinese, Japanese, Korean) fonts and some complex scripts.

Checking font encoding

To determine if a font uses Identity-H encoding:

  1. Open a PDF in Adobe Acrobat Pro/Reader.
  2. Go to File > Document Properties > Fonts.
  3. Look for fonts with encoding listed as Identity-H or Identity-V.

Why Identity-H fonts need special handling

When a PDF uses Identity-H encoding without embedding a font, the PDF refers to glyph positions (e.g. glyph #245) rather than Unicode characters. In these cases:

  • The viewer needs the exact original font or a ToUnicode map in the PDF to determine which characters to display.
  • If neither is available, the viewer can’t reliably render the text, regardless of which custom fonts you provide.

Working with embedded fonts

If your PDF document has embedded fonts, any viewer on any device should render them as expected. A PDF viewer will replace a font if the document doesn’t have it embedded and if it’s not available on the device.

Here’s how to determine if your PDF document has embedded fonts:

  • Open the PDF document in Acrobat Pro(opens in a new tab) or Acrobat Reader(opens in a new tab) (free and available on all platforms).
  • Go to the File menu, right-click anywhere empty on the page, and select Document Properties.
  • Click the Fonts tab.
  • Note which fonts aren’t listed as embedded, other than Type 3 fonts. In Nutrient Web SDK standalone, provide those font files through customFonts.

Embedded fonts, including subsets with a prefix like AAAAAA+ and Type 3 fonts, render from the PDF without customFonts. For how subsets handle newly added text, refer to font subsetting.

Combining font substitution with custom or dynamic fonts

If your PDF references non-embedded fonts by name (e.g. CJK system fonts like MS Gothic or MS 明朝), you can use fontSubstitutions to remap those names to font faces you provide via customFonts or dynamicFonts. This is the recommended approach when you know which fonts a document expects but can’t reembed them. See the font substitution guide for configuration examples.

If a form field’s font isn’t available in the browser, the form editor uses a sans-serif fallback while editing. The exact typeface can differ from the original. Supply the original font when matching it is required; the fallback doesn’t resolve missing glyph mappings or corrupted fonts.

When custom fonts won’t help

Custom fonts configured via customFonts won’t resolve rendering issues when:

  • The PDF uses Identity-H encoding without ToUnicode maps, and the exact original font file isn’t available. A substitute font with a different glyph order renders the wrong characters.
  • The PDF uses Type 3 fonts (custom vector glyphs).
  • The font is embedded but corrupted in the PDF.

In these cases, the PDF itself must be regenerated with proper font embedding or encoding.

Collecting diagnostic information

When reporting font rendering issues to support, always include a sample PDF demonstrating the issue so that we can look at its properties and determine the issue.