Come funziona la modifica di PDF tramite browser (e perché la privacy è importante)

Ogni volta che caricate un documento su uno strumento PDF basato sul cloud, quel documento si trova su server che non controllate, viene elaborato da software che non potete ispezionare e archiviato da un'azienda con le proprie politiche di conservazione e sicurezza dei dati. Per un breve periodo, l'infrastruttura di qualcun altro custodisce i vostri contratti, dichiarazioni dei redditi, cartelle cliniche o documenti aziendali riservati.

LuraPDF funziona in modo diverso. Tutto avviene nella scheda del browser, sul tuo hardware, con la gestione della memoria del sistema operativo. Questo articolo spiega l'architettura tecnica che rende possibile tutto ciò e i compromessi ingegneristici che ne sono derivati.

Il browser come piattaforma di elaborazione documenti

I browser moderni non sono più semplici renderer HTML. Sono ambienti di esecuzione applicativa completi con:

• Motore JavaScript (V8 in Chrome, SpiderMonkey in Firefox): esegue il codice a una velocità quasi nativa.
• WebAssembly (WASM): esegue codice C/C++ compilato a velocità quasi nativa all'interno di un ambiente sandbox.
• API Canvas: consente la manipolazione delle immagini a livello di pixel.
• API di accesso al file system: consente la lettura di file locali senza caricarli
• Web Workers: esegue i calcoli su thread in background senza bloccare l'interfaccia utente
• ArrayBuffer / Blob: gestisce i dati binari grezzi (come i byte PDF) in memoria

Queste funzionalità, nel loro insieme, consentono di realizzare una pipeline di elaborazione documentale completa che cinque anni fa avrebbe richiesto un server back-end.

Le tre biblioteche principali

LuraPDF si basa su tre librerie open-source fondamentali:

pdf-lib

pdf-lib è una libreria TypeScript per la creazione e la modifica di documenti PDF in qualsiasi ambiente JavaScript. Implementa una parte sostanziale della specifica PDF (ISO 32000), tra cui:

• Creazione, modifica ed eliminazione di pagine
• Incorporamento di font (sia font standard a 14 caratteri che font TTF/OTF personalizzati)
• Incorporamento di immagini (JPEG, PNG)
• Posizionamento delle annotazioni di testo
• Creazione e manipolazione dei campi del modulo
• Metadati del documento (titolo, autore, data di creazione, ecc.)
• Crittografia PDF (AES-128 e AES-256)
• Gestione delle tabelle di riferimento incrociato

Quando LuraPDF unisce i PDF, utilizza pdf-lib per leggere la struttura delle pagine di ciascun documento, normalizzare le risorse condivise e assemblare un nuovo PDF. Quando comprime, ricodifica gli oggetti immagine con fattori di qualità inferiori. Quando crittografa, applica l'algoritmo AES-256 al documento utilizzando l'API Web Crypto.

pdf-lib opera interamente su oggetti ArrayBuffer, ovvero dati binari grezzi nella memoria del browser. Non vengono effettuate chiamate di rete.

pdfjs-dist

PDF.js è il motore di rendering PDF di Mozilla, distribuito come pdfjs-dist su npm. È il motore che alimenta il visualizzatore PDF integrato di Firefox, testato su milioni di PDF reali.

LuraPDF utilizza pdfjs-dist per:

• Rendering della pagina: Conversione delle pagine PDF in Canvas ImageData per la visualizzazione
• Estrazione del testo: Lettura dei flussi di testo dalle pagine PDF
• Metadati della pagina: Recupero delle dimensioni della pagina, dei valori di rotazione e del tipo di contenuto.

Quando vedi il tuo PDF visualizzato nell'interfaccia LuraPDF, ovvero l'anteprima grafica delle pagine, significa che pdfjs-dist sta eseguendo il rendering di ciascuna pagina su un elemento Canvas HTML.

Tesseract.js

Tesseract.js è la versione di Tesseract OCR compilata in WebAssembly. Tesseract è un motore OCR open-source originariamente sviluppato da HP Labs (1985) e attualmente gestito da Google. Utilizza un modello di rete neurale LSTM (Long Short-Term Memory) per il riconoscimento dei caratteri.

Eseguire Tesseract tramite WebAssembly nel browser significa:

• Il file binario WASM da 22 MB viene caricato una sola volta e memorizzato nella cache dal browser.
• L'elaborazione OCR viene eseguita sulla CPU tramite WebAssembly, non sulla GPU.
• L'elaborazione è più lenta rispetto all'OCR cloud (che utilizza cluster GPU) ma produce un output di qualità identica.
• Il contenuto del tuo documento non lascia mai il tuo dispositivo

Per una scansione di 20 pagine: l'OCR del browser richiede circa 30-120 secondi. Un servizio cloud potrebbe impiegarne 2-5. Il compromesso è tra privacy e velocità.

L'architettura: dal file all'output

Ecco cosa succede quando, ad esempio, si comprime un PDF in LuraPDF:

1. Selezione del file: Trascini un PDF nell'area di rilascio. L'API File del browser legge il file in un ArrayBuffer, ovvero byte grezzi nella memoria del browser. Non avviene alcun caricamento.

2. Validazione: Un rapido controllo per verificare che i byte magici %PDF appaiano all'inizio dell'ArrayBuffer.

3. Caricamento: PDFDocument.load() di pdf-lib analizza la tabella dei riferimenti incrociati, legge l'albero degli oggetti e crea una rappresentazione in memoria del documento.

4. Enumerazione delle immagini: La libreria analizza i flussi di contenuto della pagina per trovare gli oggetti immagine XObject (immagini incorporate). Vengono estratti la larghezza, l'altezza, il tipo di compressione e i dati in byte di ciascuna immagine.

5. Ricodifica: Per ogni immagine, i dati dei pixel grezzi vengono disegnati su un elemento HTML Canvas, quindi riesportati con un fattore di qualità JPEG inferiore utilizzando canvas.toBlob('image/jpeg', quality) . L'oggetto immagine originale viene sostituito con la versione codificata più piccola.

6. Serializzazione del documento: il metodo save() di pdf-lib serializza il documento modificato in byte. I flussi di oggetti sono compressi con DEFLATE.

7. Download: I byte vengono incapsulati in un oggetto Blob, viene creato un URL temporaneo dell'oggetto ( URL.createObjectURL(blob) ) e un clic programmatico <a> attiva il meccanismo di download del browser.

Dati totali trasmessi a qualsiasi server esterno: zero byte.

Web Workers: Mantenere l'interfaccia utente reattiva

L'elaborazione dei file PDF richiede un elevato utilizzo della CPU. Eseguirla sul thread JavaScript principale bloccherebbe la scheda del browser: non sarebbe possibile scorrere, cliccare o visualizzare aggiornamenti sullo stato di avanzamento durante l'elaborazione del file.

LuraPDF esegue tutti i calcoli più complessi (OCR, analisi di PDF di grandi dimensioni, ricodifica delle immagini) tramite Web Worker, ovvero thread JavaScript separati che vengono eseguiti in background. Il thread principale gestisce l'interfaccia utente, mostra le barre di avanzamento e comunica con il worker tramite lo scambio di messaggi (postMessage / onmessage).

Quando l'OCR è in esecuzione, viene generato un evento di avanzamento dopo l'elaborazione di ogni pagina. Il worker invia { page: 5, total: 20, confidence: 94 } al thread principale, che aggiorna la barra di avanzamento. L'interfaccia utente rimane interattiva per tutta la durata del processo.

Gestione della memoria

La memoria del browser è limitata. Un PDF di 200 MB caricato in memoria, elaborato e salvato potrebbe richiedere dai 400 ai 600 MB di RAM (byte originali + dati Canvas intermedi + byte di output). Sui sistemi con RAM limitata, questo può causare problemi di memoria.

Strategie utilizzate:

• Elaborazione in streaming delle pagine: Per le operazioni su più pagine, le pagine vengono elaborate e gli elementi Canvas intermedi vengono scartati dopo l'uso.
• URL.revokeObjectURL(): Gli URL blob temporanei vengono revocati dopo il download per consentire il GC
• Terminamento del worker: i Web Worker vengono terminati dopo aver completato il loro compito per recuperare la memoria utilizzata

Per file di dimensioni molto grandi (>100 MB), i browser moderni li gestiscono senza problemi su sistemi con almeno 8 GB di RAM. I sistemi più vecchi o con memoria limitata potrebbero avere difficoltà a gestire file sorgente di dimensioni superiori a 100 MB.

L'architettura della privacy

Il modello di sicurezza è garantito dalla politica di stessa origine e dall'architettura di isolamento del browser:

• Nessuna richiesta HTTP: nessuna chiamata API esterna, nessuna telemetria, nessuna chiamata di analisi durante l'elaborazione dei documenti.
• Esecuzione in ambiente sandbox: i Web Worker non possono effettuare chiamate di rete verso origini esterne.
• Nessuna memorizzazione persistente: i file elaborati non vengono scritti nella memoria del browser (localStorage, IndexedDB o accesso al file system).
• Memoria a livello di scheda: quando chiudi la scheda, tutti gli oggetti ArrayBuffer e Blob ad essa associati vengono eliminati dal garbage collector.

Questa architettura è verificabile: aprite la scheda Rete degli Strumenti per sviluppatori del browser mentre elaborate un file. Vedrete zero richieste durante l'operazione di elaborazione.

Librerie open source: ispezionabili, non scatole nere

Tutte e tre le librerie principali — pdf-lib, pdfjs-dist e Tesseract.js — sono open source con repository pubblici su GitHub. Le implementazioni sono ispezionabili da chiunque. Il codice di elaborazione PDF eseguito in LuraPDF non è una scatola nera proprietaria; è codice pubblico con utenti reali, problemi e contributi.

Questo è importante per la fiducia. Quando un servizio cloud afferma "elaboriamo ed eliminiamo i tuoi file", ti fidi della sua parola. Quando LuraPDF utilizza librerie open source in una sandbox del browser senza chiamate di rete, puoi verificare l'affermazione controllando la scheda di rete.

Compromessi vs. elaborazione cloud

Il modello basato su browser presenta dei compromessi concreti che è bene analizzare onestamente:

Velocità: I servizi cloud dispongono di cluster GPU e infrastrutture dedicate. L'OCR del browser su un documento di grandi dimensioni richiede da 2 a 10 volte più tempo rispetto a un'equivalente soluzione cloud. La compressione è veloce perché utilizza direttamente l'API Canvas.

Limiti di dimensione dei file: Il limite è rappresentato dalla memoria del browser. I file di dimensioni molto grandi (>300 MB) potrebbero raggiungere i limiti di memoria su alcuni sistemi. I servizi cloud non presentano tale limitazione.

Potenza di elaborazione: WASM funziona al 40-80% della velocità nativa del C++. I servizi cloud eseguono codice nativo ottimizzato. Per la maggior parte dei documenti questa differenza è impercettibile; per lavori OCR di oltre 100 pagine è evidente.

Funzionalità: Alcune funzionalità PDF avanzate (verifica di conformità PDF/X, gestione professionale del colore, flussi di lavoro CMYK) richiedono strumenti server specializzati. L'elaborazione tramite browser gestisce il 95% dei casi.

Per le operazioni quotidiane di elaborazione dei documenti (compressione, unione, firma, conversione, oscuramento), il modello basato su browser è sufficientemente veloce, garantisce la privacy per sua natura e non richiede alcun account o abbonamento.

Domande frequenti

LuraPDF raccoglie dati di telemetria o di utilizzo? LuraPDF utilizza Google Analytics per raccogliere statistiche aggregate sulle visualizzazioni di pagina. Le operazioni di elaborazione dei documenti non generano eventi di analisi. Il contenuto dei file non viene mai trasmesso.

Posso confermare che non si verifica alcun caricamento? Sì. Apri gli Strumenti per sviluppatori (F12), fai clic sulla scheda Rete, filtra per "XHR" o "Fetch". Elabora un file. Durante l'elaborazione non si verificano richieste di rete relative al documento.

Perché il riconoscimento ottico dei caratteri (OCR) impiega così tanto tempo rispetto ad altri servizi? Tesseract.js, basato su browser, viene eseguito sulla CPU tramite WebAssembly. I servizi OCR in cloud, invece, vengono eseguiti su cluster GPU che elaborano i caratteri con una velocità di gran lunga superiore. Il compromesso è che il documento non esce mai dal browser.

Cosa succede se chiudo la scheda durante l'elaborazione? L'elaborazione si interrompe immediatamente. La memoria della scheda del browser viene eliminata. Il file originale sul disco rimane invariato.

Il codice è open source? Le librerie di elaborazione principali (pdf-lib, pdfjs-dist, Tesseract.js) sono open source. Il codice dell'interfaccia di LuraPDF non è attualmente open source, ma la pipeline di elaborazione utilizza solo componenti open source.

Il passaggio all'elaborazione dei documenti tramite browser non è una trovata pubblicitaria. Si tratta di una vera e propria scelta architetturale con vantaggi misurabili in termini di privacy e affidabilità, a scapito della velocità nelle operazioni più complesse. Per i documenti che si preferisce non avere sui server di terzi, è il compromesso giusto.