mozilla/pdf.js · warning · Error

Type3 font load error: ${reason}

Error message

Type3 font load error: ${reason}

What it means

Raised internally when loadType3Data fails for a Type3 font whose CharProcs cannot be evaluated. Crucially, this throw happens inside translateFont's .then() and is caught by the chained .catch(), which resolves the loadFont promise with an ErrorFont fallback instead of rejecting. The API caller therefore never observes a thrown error; the symptom is missing/blank glyphs rendered with the fallback font and a console warning ('loadFont - translateFont failed').

Source

Thrown at src/core/evaluator.js:1395

    }

    // Keep track of each font we translated so the caller can
    // load them asynchronously before calling display on a page.
    font.loadedName = `${this.idFactory.getDocId()}_${fontID}`;

    this.translateFont(preEvaluatedFont)
      .then(async translatedFont => {
        const translated = new TranslatedFont({
          loadedName: font.loadedName,
          font: translatedFont,
          dict: font,
        });

        if (translatedFont.isType3Font) {
          try {
            await translated.loadType3Data(this, resources, task, seenRefs);
          } catch (reason) {
            throw new Error(`Type3 font load error: ${reason}`);
          }
        }
        resolve(translated);
      })
      .catch(reason => {
        // TODO reject?
        warn(`loadFont - translateFont failed: "${reason}".`);

        resolve(
          new TranslatedFont({
            loadedName: font.loadedName,
            font: new ErrorFont(reason?.message),
            dict: font,
          })
        );
      });
    return promise;
  }

View on GitHub (pinned to 5903d58d58)

Solutions

  1. Treat it as non-fatal: it already falls back to ErrorFont, so rendering continues; rely on ignoreErrors for surrounding operators if needed.
  2. Inspect the font dictionary's CharProcs and Resources entries to confirm required XObject/ColorSpace/Font sub-resources are present and valid.
  3. Upgrade PDF.js, since Type3 evaluation changes over time.
  4. Re-embed the font as a standard/CFF/TrueType font in the source document to avoid Type3 entirely.
Defensive patterns

Strategy: fallback

Try / catch

// No catch needed: PDF.js already resolves loadFont with an ErrorFont fallback.
// Detect the fallback instead and surface a UI hint if you care about glyph fidelity.
const fontIds = await page.getOperatorList?.(); // fonts are loaded internally
// If glyphs render blank, the Type3 font fell back; treat as cosmetic, not fatal.

Prevention

When it happens

Trigger: A page uses a Type3 font whose CharProcs stream references undefined operators, missing or invalid resources, unreadable images, or itself recursively; loadType3Data (which re-evaluates each glyph's operator list) then throws.

Common situations: Specialty/scientific PDFs, LaTeX/TeX-derived Type3 fonts, or PDFs from generators that emit incomplete Type3 font resource dictionaries. Often seen together with errors in image or colorspace parsing of the glyph procs.

Related errors


AI-assisted analysis of mozilla/pdf.js@5903d58d58 (2026-08-13). Data as JSON: /api/errors/a8ccbdd037b187a0. Report an issue: GitHub.