jsPDF è eccellente per esportazioni leggere nel browser
jsPDF è popolare perché risolve un problema reale di prodotto: creare un PDF dentro il browser senza avviare un servizio server. Uno sviluppatore può disegnare testo, linee, immagini e tabelle semplici, poi avviare il download dalla stessa pagina. Per prototipi, piccoli pannelli amministrativi, ricevute locali e PWA offline, è un adattamento forte.
La domanda di prodotto è dove quel confine del browser smette di essere quello giusto. Quando il PDF diventa un documento aziendale che i clienti scansionano, archiviano, inviano via email o caricano in un altro sistema, il lavoro non è più solo “disegnare un file”. Diventa gestione font, precisione dei codici a barre, stabilità su mobile, output deterministico e talvolta pacchetto PDF/A o fattura elettronica.
Stesso output PDF, confine di prodotto diverso
Con jsPDF, la vostra applicazione web è il generatore. Ogni scheda del browser deve tenere in memoria la libreria, eventuali font personalizzati, immagini intermedie, output dei codici a barre e byte finali del PDF. Questo mantiene a zero il costo della libreria, ma sposta la responsabilità di produzione su ogni dispositivo utente.
Con gPdf, il browser o il servizio server invia una richiesta strutturata DocumentRequest o template_id + data. gPdf possiede l’ambiente di generazione, i font inclusi, la geometria dei codici a barre e la generazione binaria PDF sull’edge. L’applicazione resta responsabile dei dati e della logica del modello, non del motore PDF.
Adattamento di prodotto: esportazione offline vs documenti operativi
Scegliete jsPDF quando il PDF è una funzione di comodità locale: un piccolo pulsante di esportazione, una ricevuta semplice solo latina, un’istantanea di un pannello o una PWA che deve continuare a funzionare senza rete.
Scegliete gPdf quando il PDF fa parte di un processo operativo: etichette di spedizione, cartellini di magazzino, fatture, ticket, estratti conto, documenti doganali e ricevute transfrontaliere. Questi documenti hanno bisogno dello stesso output su tutti i dispositivi, non di ciò che la scheda corrente del browser riesce ad assemblare in sicurezza.
Modello di costo: libreria gratuita vs superficie produttiva posseduta
jsPDF ha il vantaggio di prezzo più evidente: la libreria è open source e la CPU del browser non compare come voce nella fattura cloud. Per una piccola funzione interna, può essere il percorso più economico.
Il costo di produzione appare nel lavoro intorno alla libreria:
- File font con copertura CJK o moduli font Base64 generati.
- Librerie di codifica e conversione dei codici a barre.
- Bug specifici di browser su memoria e download.
- QA di stampa per scanner e stampanti termiche.
- Test di regressione su desktop, iOS Safari, Android WebView e browser incorporati.
gPdf trasforma quel lavoro in una fattura d’uso. Il piano Basic pubblico parte da 5 USD/mese per 100.000 pagine, con eccedenza standard da 0,00005 USD per pagina. È un costo fornitore, ma rimuove la necessità di far comportare ogni pacchetto dell’app web e ogni dispositivo utente come un servizio PDF di produzione.
Il costo CJK non è solo dimensione del file
Il primo confine duro è il testo CJK: cinese, giapponese e coreano.
I font PDF standard integrati in jsPDF sono utili per output latino semplice, ma non coprono ogni glifo Unicode. Quando il documento contiene testo CJK, l’applicazione ha bisogno di un font che contenga davvero quei glifi. In pratica, le implementazioni lato browser spesso impacchettano un file TTF, lo convertono in un modulo JavaScript Base64 o recuperano dati font prima di generare il PDF.
Questo costo viene pagato due volte: prima come carico più grande per l’app web, poi di nuovo come memoria del browser durante la generazione. Su mobile, la stessa scheda può tenere insieme app web, font, buffer dei codici a barre, immagini e byte finali del PDF.
gPdf mantiene quel lavoro lato servizio. Il browser invia JSON strutturato; il generatore sceglie tra font inclusi che coprono latino, greco, cirillico, CJK, arabo, devanagari, bengalese, thai e testo monospace. Dati d’ordine da 2 KB non devono diventare un percorso di consegna font da 12 MB.
Codici a barre: codificare è facile, stampare in modo affidabile è più difficile
Per logistica, e-commerce, produzione, sanità, ticketing e retail, il codice a barre può essere più importante del testo visibile. Un essere umano legge il numero d’ordine; l’operazione legge Code 128, GS1-128, QR, DataMatrix o PDF417.
Con jsPDF, la generazione dei codici a barre è di solito una decisione di prodotto separata. I team combinano jsPDF con un altro encoder, generano il codice a barre in SVG, Canvas o immagine, poi inseriscono quel risultato nel PDF. Funziona per un QR coupon o una prova di concetto.
Diventa fragile quando il codice a barre stampato è critico per l’operazione:
- Un codice a barre su Canvas può essere rasterizzato alla risoluzione sbagliata.
- Un’immagine scalata può sfocare barre, moduli o quiet zone.
- Un browser, una trasformazione CSS o un percorso di esportazione può cambiare la dimensione fisica finale.
- Formati diversi possono richiedere librerie o percorsi di conversione diversi.
- Le stampanti termiche a 203 DPI espongono rapidamente piccoli errori di dimensionamento.
gPdf tratta i codici a barre come elementi del documento. La richiesta specifica type: "barcode", format, carico utile e dimensione fisica in millimetri. Il generatore emette geometria vettoriale dei codici a barre dentro il PDF per i formati 1D e 2D supportati, così testo, forme, tabelle, immagini e codici a barre restano in un unico sistema di coordinate.
Studio e iterazione dei modelli
jsPDF parte dal codice. Una modifica di impaginazione di solito significa cambiare comandi di disegno, posizioni, registrazione font, conversione immagini e posizionamento dei codici a barre in JavaScript.
gPdf supporta lo stesso processo guidato dall’API, ma aggiunge gPdf Studio come designer visivo gratuito per l’impaginazione PDF. I team possono aggiungere e trascinare testo, immagini, tabelle, forme, intestazioni, piè di pagina e codici a barre, poi collegare il design alla generazione template_id + data. Questo conta quando il formato di un’etichetta, fattura o ricevuta cambia spesso e persone non specialiste PDF devono partecipare alla progettazione.
I browser mobili sono il posto sbagliato per lavoro PDF pesante
La generazione PDF lato client sembra economica perché la fattura server è zero. Il costo si sposta sul dispositivo utente.
Su desktop può andare bene. Nei browser mobili, un documento di produzione può mettere sotto pressione la scheda: dati font CJK, immagini Base64, buffer Canvas, immagini dei codici a barre, byte PDF generati e applicazione in esecuzione competono tutti per la memoria nello stesso momento. iOS Safari e dispositivi Android con poca memoria sono meno indulgenti del laptop di uno sviluppatore.
Spostare la generazione su gPdf cambia la forma del problema. Il browser costruisce una piccola richiesta JSON, aspetta una risposta binaria e scarica il PDF finito. La scheda dell’utente non deve più essere insieme gestore font, generatore di codici a barre, motore di impaginazione e scrittore binario PDF.
Quando jsPDF resta la scelta giusta
Ci sono ottime ragioni per tenere jsPDF.
Se l’utente deve esportare mentre è offline, jsPDF è la scelta migliore. Se i dati non possono lasciare il dispositivo in nessun caso, la generazione nel browser è il confine privacy più pulito. Se il documento è piccolo, solo latino e usato occasionalmente, il costo operativo di introdurre un’API può non valere la pena. Per prototipi e strumenti interni, jsPDF è spesso esattamente il percorso più veloce.
La decisione cambia quando l’output fa parte di un processo operativo: un’etichetta di spedizione che deve essere letta dallo scanner, una fattura da archiviare, un ticket da verificare o un documento d’ordine transfrontaliero che deve rendere correttamente nomi CJK. A quel punto, “generare un PDF nel browser” conta meno di “generare lo stesso PDF di produzione in modo affidabile”.
Forma della migrazione
La migrazione non è “sostituire una chiamata di funzione”. È passare dal disegno imperativo nel browser a una richiesta strutturata di documento.
- // Before: browser-side drawing with jsPDF plus extra font/barcode setup.
- import { jsPDF } from "jspdf";
- import JsBarcode from "jsbarcode";
-
- const doc = new jsPDF({ unit: "mm", format: [100, 150] });
- // Load a CJK-capable TTF and register it before drawing CJK text.
- doc.addFileToVFS("NotoSansCJK-Regular.ttf", base64Font);
- doc.addFont("NotoSansCJK-Regular.ttf", "NotoSansCJK", "normal");
- doc.setFont("NotoSansCJK");
- doc.text("跨境订单 / Cross-border order", 6, 10);
-
- // Generate a barcode separately, then place it into the PDF.
- JsBarcode(canvas, "PDN0003507278", { format: "CODE128" });
- doc.addImage(canvas.toDataURL("image/png"), "PNG", 6, 72, 72, 20);
- doc.save("label.pdf");
+
+ // After: send one structured DocumentRequest to gPdf.
+ const res = await fetch("https://api.gpdf.com/api/v1/pdf/render", {
+ method: "POST",
+ headers: {
+ Authorization: `Bearer ${KEY}`,
+ "Content-Type": "application/json"
+ },
+ body: JSON.stringify({
+ settings: {
+ defaults: {
+ text: {
+ font_family: "NotoSans-Regular",
+ font_mode: "prefer",
+ font_size: 9,
+ color: "#111827"
+ }
+ }
+ },
+ pages: [{
+ width: 100,
+ height: 150,
+ elements: [
+ {
+ type: "text",
+ x: 6,
+ y: 8,
+ content: "跨境订单 / Cross-border order",
+ style: { width: 88, font_size: 12, font_weight: "bold" }
+ },
+ {
+ type: "barcode",
+ x: 6,
+ y: 70,
+ width: 72,
+ height: 18,
+ format: "code128",
+ content: "PDN0003507278",
+ barcode_text: { enabled: true, position: "bottom", offset: 1 }
+ },
+ {
+ type: "barcode",
+ x: 80,
+ y: 8,
+ width: 14,
+ height: 14,
+ format: "qrcode",
+ content: "https://track.example/PDN0003507278",
+ barcode_text: { enabled: false, position: "bottom" }
+ }
+ ]
+ }]
+ })
+ });
+ const pdf = await res.arrayBuffer();Il cambiamento importante è la proprietà. Con jsPDF, la vostra app web assume il percorso dei font CJK, il percorso di generazione dei codici a barre, il profilo memoria del browser e il comportamento di esportazione. Con gPdf, l’applicazione assume dati e modello; il generatore sull’edge assume la meccanica del documento.
Scenari correlati di generazione PDF
I team che confrontano jsPDF e gPdf stanno di solito decidendo se lasciare il PDF nel browser o spostare la generazione su un servizio controllato. Se il tema è la memoria mobile o il testo CJK, partite dal riferimento API JSON Render. Se il tema sono scanner e stampanti termiche, leggete codici a barre vettoriali vs raster nei PDF e GS1-128 a 0,1 mm in JSON. Per requisiti di archivio e fattura elettronica, la lettura giusta è PDF/A e Factur-X spiegati agli ingegneri.
FAQ
jsPDF è gratuito?
La libreria in sé è open source. Il costo di produzione è il lavoro circostante: font CJK, librerie per codici a barre, QA browser, QA di stampa e supporto per dispositivi che esauriscono la memoria.
gPdf sostituisce ogni caso d’uso di jsPDF?
No. Esportazioni browser offline e documenti solo locali restano il territorio naturale di jsPDF. gPdf è per documenti di produzione in cui un generatore controllato vale la chiamata API.
Perché citare separatamente il costo dei codici a barre?
Perché un codice a barre che sembra corretto a schermo può comunque fallire dopo scalatura, rasterizzazione o stampa termica. I documenti operativi richiedono affidabilità allo scanner, non solo un motivo visibile.
Vedi anche
- Riferimento API gPdf —
DocumentRequest, elementibarcode, sostituzione font e forma della generazione. - Codici a barre vettoriali vs raster nei PDF — perché la geometria conta dopo la stampa.
- GS1-128 a 0,1 mm di precisione in JSON — dettagli di dimensionamento per etichette.
- PDF/A e Factur-X spiegati agli ingegneri — quando requisiti di archivio e fattura elettronica entrano nel percorso PDF.