jsPDF is uitstekend voor lichte browserexports
jsPDF is populair omdat het een echt productprobleem oplost: een PDF maken in de browser zonder backendservice. Een ontwikkelaar kan tekst, lijnen, afbeeldingen en eenvoudige tabellen tekenen en daarna vanaf dezelfde pagina een download starten. Voor prototypes, kleine adminschermen, lokale bonnen en offline PWA’s is dat een sterke match.
De productvraag is waar die browsergrens ophoudt de juiste grens te zijn. Zodra de PDF een bedrijfsdocument wordt dat klanten scannen, langdurig bewaren, mailen of indienen bij een ander systeem, is het werk niet langer alleen “een bestand tekenen”. Het wordt fontbeheer, barcodeprecisie, mobiele stabiliteit, deterministische output en soms PDF/A- of e-factuurverpakking.
Dezelfde PDF-output, andere productgrens
Met jsPDF is uw frontendapplicatie de renderengine. Elke browsertab moet de bibliotheek, eventuele eigen fonts, tussenafbeeldingen, barcode-output en de uiteindelijke PDF-bytes vasthouden. Dat houdt de bibliotheekrekening op nul, maar verplaatst de productieverantwoordelijkheid naar elk gebruikersapparaat.
Met gPdf stuurt de browser of backend een gestructureerd DocumentRequest of een template_id + data-verzoek. gPdf beheert de renderomgeving, gebundelde fonts, barcodegeometrie en binaire PDF-generatie aan de edge. De applicatie blijft verantwoordelijk voor data en sjabloonlogica, niet voor de PDF-engine.
Productfit: offline export vs operationele documenten
Kies jsPDF wanneer de PDF een lokale gemaksfunctie is: een kleine exportknop, een eenvoudige bon met Latijnse tekst, een dashboardsnapshot of een PWA die zonder netwerk moet blijven werken.
Kies gPdf wanneer de PDF onderdeel is van een operationele werkwijze: verzendlabels, magazijntags, facturen, tickets, overzichten, douaneformulieren en grensoverschrijdende bonnen. Die documenten hebben dezelfde output op elk apparaat nodig, niet wat de huidige browsertab veilig kan samenstellen.
Kostenmodel: gratis bibliotheek vs productieoppervlak in eigen beheer
De jsPDF-bibliotheek heeft het duidelijke prijsvoordeel: de bibliotheek zelf is open source, en browser-CPU staat niet op uw cloudfactuur. Voor een kleine interne functie kan dat de goedkoopste route zijn.
De productiekosten zitten in het werk rond de bibliotheek:
- CJK-capabele fontbestanden of gegenereerde base64-fontmodules.
- Barcodecodering en conversiebibliotheken.
- Browserspecifieke geheugen- en downloadbugs.
- Print-QA voor scanners en thermische printers.
- Regressietests op desktop, iOS Safari, Android WebView en embedded browsers.
gPdf maakt hiervan een gebruiksrekening. Het publieke Basic-plan begint bij 5 USD/maand voor 100.000 pagina’s, met standaard meerprijs vanaf 0,00005 USD per pagina. Dat zijn leverancierskosten, maar ze halen de noodzaak weg om elke frontendbundel en elk gebruikersapparaat als productieservice voor PDF te laten functioneren.
De CJK-kosten zijn niet alleen bestandsgrootte
De eerste harde grens is CJK-tekst: Chinees, Japans en Koreaans.
De ingebouwde standaard PDF-fonts van jsPDF zijn nuttig voor eenvoudige Latijnse output, maar dekken niet elke Unicode-glyph. Wanneer het document CJK-tekst bevat, heeft de applicatie een font nodig dat die glyphs echt bevat. In de praktijk bundelen browserimplementaties vaak een TTF-bestand, zetten ze dat om in een base64 JavaScript-module of halen ze fontdata op voordat de PDF wordt gegenereerd.
Die kosten worden twee keer betaald: eerst als grotere frontendbundel, daarna opnieuw als browsergeheugen tijdens de generatie. Op mobiel kan dezelfde tab tegelijk de webapp, het font, barcodebuffers, afbeeldingen en de uiteindelijke PDF-bytes vasthouden.
gPdf houdt dat werk aan serverzijde. De browser stuurt gestructureerde JSON; de renderengine kiest uit gebundelde fonts voor Latijn, Grieks, Cyrillisch, CJK, Arabisch, Devanagari, Bengaals, Thai en monospace-tekst. Een ordergegevenspakket van 2 KB hoeft geen fontdeliverypad van 12 MB te worden.
Barcodekosten: coderen is makkelijk, printbetrouwbaarheid is moeilijker
In logistiek, e-commerce, productie, zorg, ticketing en retail kan de barcode belangrijker zijn dan de zichtbare tekst. Een mens leest het ordernummer; de operatie leest Code 128, GS1-128, QR, DataMatrix of PDF417.
Met jsPDF is barcodegeneratie meestal een aparte productkeuze. Teams combineren jsPDF met een encoder, renderen de barcode naar SVG, canvas of een afbeelding en plaatsen dat resultaat in de PDF. Dat werkt voor een coupon-QR of een proof-of-concept.
Het wordt kwetsbaar wanneer de geprinte barcode operationeel kritisch is:
- Een canvasbarcode kan op de verkeerde resolutie worden gerasterd.
- Een geschaalde afbeelding kan balken, modules of quiet zones vervagen.
- Een browser, CSS-transform of exportpad kan de uiteindelijke fysieke grootte wijzigen.
- Verschillende barcodeformaten kunnen verschillende bibliotheken of conversiepaden nodig hebben.
- Thermische printers op 203 DPI maken kleine maatfouten snel zichtbaar.
gPdf behandelt barcodes als documentelementen. Het verzoek geeft type: "barcode", het format, de inhoud en de fysieke maat in millimeters. De renderengine schrijft vectorbarcodegeometrie in de PDF voor ondersteunde 1D- en 2D-formaten, zodat tekst, vormen, tabellen, afbeeldingen en barcodes in één coördinatensysteem blijven.
Studio en sjablooniteratie
jsPDF is codegedreven. Een lay-outwijziging betekent meestal tekencommando’s, posities, fontregistratie, afbeeldingconversie en barcodeplaatsing aanpassen in JavaScript.
gPdf ondersteunt dezelfde API-gedreven werkwijze, maar voegt gPdf Studio toe als gratis visuele ontwerper voor PDF-lay-outs. Teams kunnen tekst, afbeeldingen, tabellen, vormen, kopteksten, voetteksten en barcodes toevoegen en verslepen, en het ontwerp daarna koppelen aan generatie met template_id + data. Dat is belangrijk wanneer een verzendlabel-, factuur- of bonformaat vaak verandert en niet-PDF-specialisten moeten kunnen meewerken aan de lay-out.
Mobiele browsers zijn de verkeerde plek voor zwaar PDF-werk
Client-side PDF-generatie klinkt goedkoop omdat de serverrekening nul is. De kosten verhuizen naar het gebruikersapparaat.
Op desktop kan dat prima zijn. Op mobiele browsers kan een productiedocument de tab zwaar belasten: CJK-fontdata, base64-afbeeldingen, canvasbuffers, barcodeafbeeldingen, gegenereerde PDF-bytes en de draaiende applicatie concurreren tegelijk om geheugen. iOS Safari en Android-toestellen met weinig geheugen zijn minder vergevingsgezind dan een ontwikkellaptop.
Generatie verplaatsen naar gPdf verandert de vorm van het probleem. De browser bouwt een klein JSON-verzoek, wacht op een binaire response en downloadt de afgewerkte PDF. De tab van de gebruiker hoeft niet langer fontmanager, barcode-engine, lay-outengine en binaire PDF-schrijver tegelijk te zijn.
Wanneer jsPDF nog steeds de juiste keuze is
Er zijn goede redenen om jsPDF te houden.
Als de gebruiker offline moet exporteren, past jsPDF beter. Als data helemaal niet van het apparaat mag, is generatie in de browser de schonere privacygrens. Als het document klein is, alleen Latijnse tekst bevat en incidenteel wordt gebruikt, zijn de operationele kosten van een API misschien niet de moeite waard. Voor prototypes en interne tools is jsPDF vaak precies de snelste route.
De beslissing verandert wanneer de output deel is van een operationele werkwijze: een verzendlabel dat moet scannen, een factuur die langdurig bewaard moet worden, een ticket dat moet worden geverifieerd of een grensoverschrijdend orderdocument dat CJK-namen correct moet renderen. Dan is “PDF in de browser genereren” minder belangrijk dan “dezelfde productie-PDF betrouwbaar genereren.”
Migratievorm
De migratie is niet “vervang één functieaanroep”. Het is de overgang van imperatief tekenen in de browser naar een gestructureerd documentverzoek.
- // 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();De belangrijke verschuiving is eigenaarschap. Met jsPDF bezit uw webapp het CJK-fontpad, de barcodegeneratie, het browsergeheugenprofiel en het exportgedrag. Met gPdf bezit uw applicatie data en sjabloon; de edge-renderengine bezit de documentmechanica.
Verwante PDF-generatiescenario’s
Teams die jsPDF en gPdf vergelijken, kijken meestal eerst of de PDF lokaal in de browser moet ontstaan of dat productiebetrouwbaarheid belangrijker is. Voor operationele documenten zijn JSON-naar-PDF-API, factuur-PDF-API, verzendlabel-API en GS1-barcode-API relevant. Voor printkwaliteit van codes zijn ook vector- vs rasterbarcodes in PDF en GS1-128 met 0,1 mm precisie nuttig.
FAQ
Is jsPDF gratis?
De bibliotheek zelf is open source. De productiekost zit in het werk eromheen: CJK-fonts, barcodebibliotheken, browser-QA, print-QA en ondersteuning voor apparaten die zonder geheugen komen te zitten.
Vervangt gPdf elke jsPDF-usecase?
Nee. Offline browserexport en documenten die volledig lokaal moeten blijven, zijn nog steeds het natuurlijke terrein van jsPDF. gPdf is voor productiedocumenten waar een gecontroleerde renderengine de API-aanroep waard is.
Waarom barcodekosten apart noemen?
Omdat een barcode die er op het scherm goed uitziet nog steeds kan falen na schaling, rasterisatie of thermisch printen. Operationele documenten hebben scannerbetrouwbaarheid nodig, niet alleen een zichtbaar patroon.
Zie ook
- gPdf API-referentie - DocumentRequest, barcode-elementen, fontterugval en render-API-routes.
- Vector- vs rasterbarcodes in PDF’s - waarom barcodegeometrie na printen telt.
- GS1-128 met 0,1 mm precisie in JSON - details over barcodeafmetingen voor verzendlabels.
- PDF/A en Factur-X uitgelegd voor engineers - wanneer archief- en e-factuureisen de PDF-werkwijze ingaan.