mozilla/pdf.js · error · FormatError

Unknown data type of ${type}

Error message

Unknown data type of ${type}

What it means

Thrown by CFFCompiler.compileDict when a dictionary entry's declared type is none of num, sid, offset, array, or delta. The type comes from the dictionary layout table, so an unknown type means the layout table is corrupt or was extended without updating the compile switch.

Source

Thrown at src/core/cff_parser.js:1834

            // deal with figuring out the length of the offset when it gets
            // replaced later on by the compiler.
            const name = dict.keyToNameMap[key];
            // Some offsets have the offset and the length, so just record the
            // position of the first one.
            if (!offsetTracker.isTracking(name)) {
              offsetTracker.track(name, out.length);
            }
            out.push(0x1d, 0, 0, 0, 0);
            break;
          case "array":
          case "delta":
            out.push(...this.encodeNumber(value));
            for (let k = 1, kk = values.length; k < kk; ++k) {
              out.push(...this.encodeNumber(values[k]));
            }
            break;
          default:
            throw new FormatError(`Unknown data type of ${type}`);
        }
      }
      out.push(...dict.opcodes[key]);
    }
    return out;
  }

  compileStringIndex(strings) {
    const stringIndex = new CFFIndex();
    for (const string of strings) {
      stringIndex.add(stringToBytes(string));
    }
    return this.compileIndex(stringIndex);
  }

  compileCharStrings(charStrings) {
    const charStringsIndex = new CFFIndex();
    for (let i = 0; i < charStrings.count; i++) {

View on GitHub (pinned to 5903d58d58)

Solutions

1. Add a matching case in the compileDict switch for any new type you introduce in a layout table.
2. Audit layout-table type strings against the compileDict switch cases.
3. Report to pdf.js if triggered with unmodified code — it indicates an internal bug.

Example fix

// before
// layout table: [opcode, 'Op', 'boolnum', default]  // 'boolnum' unhandled -> throws

// after
// layout table: [opcode, 'Op', 'num', default]  // use a handled type
// or add a case in compileDict:
//   case 'boolnum':
//     out.push(...this.encodeNumber(value ? 1 : 0));
//     break;

// Ensure layout-table types are all handled by compileDict.
const HANDLED_TYPES = new Set(['num', 'sid', 'offset', 'array', 'delta']);
function validateLayoutTypes(layout) {
  const unknown = [];
  for (const entry of layout) {
    const types = Array.isArray(entry[2]) ? entry[2] : [entry[2]];
    for (const t of types) {
      if (!HANDLED_TYPES.has(t)) unknown.push({ name: entry[1], type: t });
    }
  }
  if (unknown.length) throw new Error('Unhandled layout types: ' + JSON.stringify(unknown));
}

function isHandledCFFType(type) {
  return ['num', 'sid', 'offset', 'array', 'delta'].includes(type);
}

try {
  this.compileDict(dict, tracker);
} catch (e) {
  // Unknown data type in layout table; internal mismatch.
  throw new Error('compileDict hit an unhandled layout type');
}

When it happens

Trigger: Internal: compileDict reads `type = dict.types[key]` for a value present in dict.values, and the type string is not handled by the switch default branch. Indicates a layout-table/switch mismatch in pdf.js internals.

Common situations: A pdf.js patch that adds a new operator type to a layout table but forgets to add a case in compileDict; a fork that introduces custom types; corruption of the in-memory types map.

Related errors

• Already tracking location of ${key}
• Not tracking location of ${key}
• writing to an offset that is not empty
• There must be a private dictionary.
• Invalid dictionary name "${name}"

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