Summary
The PDF extraction-fallback path for non-native PDF analysis can emit repeated PDF.js warnings during page-image rendering in Node:
UnknownErrorException: Ensure that the standardFontDataUrl API parameter is provided.
The analysis can still succeed, but the fallback renderer is missing the standard-font configuration PDF.js expects.
Expected behavior
When the fallback path renders PDF pages to PNG images, it should provide PDF.js with access to standard font assets so rendering does not emit standardFontDataUrl warnings.
Actual behavior
When fallback image rendering is triggered, PDF.js logs warnings like:
UnknownErrorException: Ensure that the standardFontDataUrl API parameter is provided.
This appears once per rendered page in affected PDFs.
Scope
This is the PDF extraction-fallback renderer path, not the native Anthropic/Google PDF path, and not the separate Codex PDF instructions bug.
Local root-cause finding
The fallback renderer uses pdfjs-dist/legacy/build/pdf.mjs and calls getDocument({ data, disableWorker: true }) before later calling page.render(...), but does not provide standardFontDataUrl.
Local verification
I reproduced the warning locally on the fallback rendering path, then tested two fix shapes:
- no
standardFontDataUrl
standardFontDataUrl via .href
- changed the problem into font-load warnings in this Node runtime path
standardFontDataUrl via .pathname
- eliminated the warning in local verification and in a live post-restart check
Working patch shape:
const standardFontDataUrl = new URL(
"../node_modules/pdfjs-dist/standard_fonts/",
import.meta.url
).pathname;
const pdf = await getDocument({
data: new Uint8Array(buffer),
disableWorker: true,
standardFontDataUrl,
}).promise;
Impact
- noisy gateway logs
- can obscure real warnings/errors
- non-fatal, but a real implementation gap
Suggested fix
Pass standardFontDataUrl in the extraction-fallback renderer and add regression coverage for a fallback-render case that needs standard font assets.
Summary
The PDF extraction-fallback path for non-native PDF analysis can emit repeated PDF.js warnings during page-image rendering in Node:
UnknownErrorException: Ensure that the standardFontDataUrl API parameter is provided.The analysis can still succeed, but the fallback renderer is missing the standard-font configuration PDF.js expects.
Expected behavior
When the fallback path renders PDF pages to PNG images, it should provide PDF.js with access to standard font assets so rendering does not emit
standardFontDataUrlwarnings.Actual behavior
When fallback image rendering is triggered, PDF.js logs warnings like:
UnknownErrorException: Ensure that the standardFontDataUrl API parameter is provided.This appears once per rendered page in affected PDFs.
Scope
This is the PDF extraction-fallback renderer path, not the native Anthropic/Google PDF path, and not the separate Codex PDF instructions bug.
Local root-cause finding
The fallback renderer uses
pdfjs-dist/legacy/build/pdf.mjsand callsgetDocument({ data, disableWorker: true })before later callingpage.render(...), but does not providestandardFontDataUrl.Local verification
I reproduced the warning locally on the fallback rendering path, then tested two fix shapes:
standardFontDataUrlstandardFontDataUrlvia.hrefstandardFontDataUrlvia.pathnameWorking patch shape:
Impact
Suggested fix
Pass
standardFontDataUrlin the extraction-fallback renderer and add regression coverage for a fallback-render case that needs standard font assets.