What causes "BinaryCMapReader.process - unknown type: ${type}" in mozilla/pdf.js?

Upgrade PDF.js to a version whose BinaryCMapReader recognises the record types in your CMap files.

mozilla/pdf.js · error · Error

BinaryCMapReader.process - unknown type: ${type}

Error message

BinaryCMapReader.process - unknown type: ${type}

What it means

Thrown by BinaryCMapReader.process() (binary_cmap.js:312) in the default case of the record-type switch. The record type is the top 3 bits of the header byte (b >> 5); types 0-5 are valid record kinds (codespacerange, notdefrange, cidchar, cidrange, bfchar, bfrange) and 7 is metadata. Type 6 (or any value produced by a misaligned stream) is unknown.

Source

Thrown at src/core/binary_cmap.js:312

            incHex(end, ucs2DataSize);
            if (!sequence) {
              stream.readHexNumber(start, ucs2DataSize);
              addHex(start, end, ucs2DataSize);
            } else {
              start.set(end);
            }
            stream.readHexNumber(end, ucs2DataSize);
            addHex(end, start, ucs2DataSize);
            stream.readHex(charCode, dataSize);
            cMap.mapBfRange(
              hexToInt(start, ucs2DataSize),
              hexToInt(end, ucs2DataSize),
              hexToStr(charCode, dataSize)
            );
          }
          break;
        default:
          throw new Error(`BinaryCMapReader.process - unknown type: ${type}`);
      }
    }

    if (useCMap) {
      return extend(useCMap);
    }
    return cMap;
  }
}

export { BinaryCMapReader };

View on GitHub (pinned to 5903d58d58)

Solutions

Upgrade PDF.js to a version whose BinaryCMapReader recognises the record types in your CMap files.
Replace the CMap file with one from the official matching release distribution.
Verify the bytes at cMapUrl are a genuine bcmap and not a text CMap or HTTP error body.
If only one CMap is affected, identify which CMap (check the network request for the failing font) and replace just that file.

Defensive patterns

Strategy: fallback

Validate before calling

// You cannot pre-validate record types without reimplementing the reader;
// instead, keep your reader and CMaps in sync.
// Confirm pdfjs-dist and the cmaps dir share one release version.
import { version } from 'pdfjs-dist';
console.assert(typeof version === 'string', 'pdfjs version present');

Try / catch

try {
  await page.render({ canvasContext, viewport }).promise;
} catch (err) {
  if (/unknown type/i.test(err?.message)) {
    console.warn('CMap record type unsupported by this pdfjs build; update or replace the CMap', err);
  } else throw err;
}

Prevention

Upgrade pdfjs-dist together with its CMap set so record types are recognised.
Replace suspect CMap files with originals from the official release.
Confirm the resource at cMapUrl is a genuine bcmap, not text or an error body.
Track which CMap fails (inspect network requests) and replace just that file.

When it happens

Trigger: A record header byte decodes to type === 6, or the stream is misaligned so a data byte is read as a header, yielding an unrecognized type. Triggered when the bcmap format is newer than the reader supports, the file is corrupt, or earlier mis-parsing shifted the read offset.

Common situations: A .bcmap produced by a newer/different tool than the reader understands; corrupt or partially-overwritten CMap file; wrong resource served at the cMapUrl; read offset desynced by an earlier malformed record.

Related errors

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