# pdf.js — da dove viene, e perché proprio questa build

`pdf.js` e `pdf.worker.js` sono **codice di terze parti, vendorizzato verbatim**. Gli
altri tre file di questa cartella (`pdfjs_env.js`, `pdfjs_dom.js`,
`pdf_convert_native.js`) sono **nostri**.

| | |
|---|---|
| **Progetto** | **pdf.js** — `github.com/mozilla/pdf.js` |
| **Versione** | **3.11.174** (build `ce8716743`) |
| **Licenza** | Apache-2.0 (l'intestazione è dentro i file stessi) |
| **Copiati da** | il repo macOS `svgeditor@a2a033b7`, `SVGEditorMac/SVG Editor Mac/Method-Draw-master/drawmac/js/lib/` |
| **Data del vendoring** | 2026-08-31 |
| **Modifiche nostre** | **nessuna**. Zero righe toccate. |

    sha256(pdf.js)         d83766f20a4c31fbce5a29d98789cdfbef781b147441da45be1d1079e8e0f81c
    sha256(pdf.worker.js)  e3f005b22146f290af16ac0dc16ab45f0df898173de1cc539d6e4092832da9d8

⛔ Non si scarica da npm e non si aggiorna da solo: **la fonte è il repo macOS**. Questa
lane esiste perché il convertitore sia LO STESSO dei due lati, quindi i byte di pdf.js
devono venire da dove viene quello del Mac. Il giorno in cui il Mac aggiorna pdf.js, si
ricopia da lì e si aggiornano gli sha qui sopra.

## Perché la build moderna e non `pdf.legacy.js`

`pdfconvert.html` del Mac carica i gemelli **`.legacy.js`**, cioè la trascrizione ES5
della stessa identica versione, che sta nella stessa cartella dello stesso repo. Su
QuickJS quella build **non parte**, ed è stato misurato prima di scegliere:

1. `pdf.worker.legacy.js:4461` — `URLSearchParams is not defined`. Aggiunto uno shim, il
   muro successivo è `4469`, dove un polyfill core-js fa `uncurryThis(URLSearchParams
   .prototype.append)`: pretende l'implementazione completa, multi-valore, del web.
2. Aggiunta anche quella, il muro dopo è `pdf.worker.legacy.js:55467` —
   `cannot read property 'prototype' of undefined`, un'altra classe di browser che
   core-js si aspetta di poter riscrivere.

Non è un problema di pdf.js: è che **il legacy si porta dietro core-js**, e core-js
esiste per rattoppare browser vecchi, non motori JS nudi. La build moderna non ha
polyfill e QuickJS-ng 0.10.1 parla ES2023: carica al primo colpo.

Il *convertitore* — `SVGGraphics` e tutto ciò che sta sotto — è lo stesso codice nelle
due build (è la stessa sorgente, compilata due volte da Mozilla). L'SVG che ne esce è
quindi lo stesso, e la fedeltà col Mac resta per costruzione.

## Perché `pdf.worker.js` va caricato PRIMA di `pdf.js`

Valutato nello stesso contesto, `pdf.worker.js` definisce `globalThis.pdfjsWorker`.
`pdf.js:4537` lo cerca esattamente lì come *main-thread worker message handler*: trovandolo
usa quello e non tenta né di creare un `Worker` (che non esiste) né di caricarsi lo script
da solo con un `<script>` (che non esiste). È la stessa via del "fake worker" su cui gira
anche il Mac, dove una WKWebView su `file://` non può creare un Worker vero.

## Cosa NON è vendorizzato

`pdf.worker.legacy.js`, `pdf.legacy.js`, il viewer, le CMap e i font standard di pdf.js.
Le CMap servirebbero per i PDF con font CJK non incorporati; quel giorno si vendorizza
`cmaps/` e si passa `cMapUrl`/`cMapPacked` a `getDocument`.
