jsPDF ist stark für leichte Browser-Exporte
jsPDF ist beliebt, weil es ein echtes Produktproblem löst: ein PDF im Browser erzeugen, ohne einen Backend-Service zu betreiben. Ein Entwickler kann Text, Linien, Bilder und einfache Tabellen zeichnen und den Download direkt auf derselben Seite auslösen. Für Prototypen, kleine Admin-Oberflächen, lokale Belege und Offline-PWAs passt das gut.
Die Produktfrage lautet, wo diese Browser-Grenze aufhört, die richtige zu sein. Sobald das PDF ein Geschäftsdokument wird, das Kunden scannen, archivieren, per E-Mail weitergeben oder in ein anderes System hochladen, ist es nicht mehr nur “eine Datei zeichnen”. Dann geht es um Font-Management, Barcode-Genauigkeit, mobile Stabilität, deterministische Ausgabe und manchmal PDF/A oder E-Invoice-Pakete.
Gleiches PDF-Ergebnis, andere Produktgrenze
Mit jsPDF ist Ihre Frontend-App der Renderer. Jeder Browser-Tab muss die Bibliothek, eigene Fonts, Zwischenbilder, Barcode-Ausgaben und die finalen PDF-Bytes halten. Die Bibliotheksrechnung bleibt bei null, aber die Produktionsverantwortung liegt auf jedem Nutzergerät.
Mit gPdf sendet Browser oder Backend eine strukturierte DocumentRequest- oder template_id + data-Anfrage. gPdf besitzt Render-Umgebung, gebündelte Fonts, Barcode-Geometrie und binäre PDF-Erzeugung am Edge. Die Anwendung bleibt für Daten und Vorlagenlogik verantwortlich, nicht für die PDF-Engine.
Produktpassung: Offline-Export oder operative Dokumente
Wählen Sie jsPDF, wenn das PDF eine lokale Komfortfunktion ist: ein kleiner Export-Button, ein einfacher Beleg mit lateinischem Text, ein Dashboard-Snapshot oder eine PWA, die ohne Netzwerk weiterarbeiten muss.
Wählen Sie gPdf, wenn das PDF Teil eines operativen Ablaufs ist: Versandlabels, Lageretiketten, Rechnungen, Tickets, Kontoauszüge, Zollformulare und grenzüberschreitende Belege. Diese Dokumente brauchen dieselbe Ausgabe auf allen Geräten, nicht das, was der aktuelle Browser-Tab gerade sicher zusammenbauen kann.
Kostenmodell: freie Bibliothek vs verantwortete Produktionsfläche
jsPDF hat den offensichtlichen Preisvorteil: Die Bibliothek selbst ist Open Source, und Browser-CPU erscheint nicht auf Ihrer Cloud-Rechnung. Für ein kleines internes Feature kann das der günstigste Weg sein.
Die Produktionskosten entstehen um die Bibliothek herum:
- CJK-fähige Font-Dateien oder generierte Base64-Font-Module.
- Barcode-Encoding- und Konvertierungsbibliotheken.
- Browser-spezifische Speicher- und Download-Bugs.
- Druck-QA für Scanner und Thermodrucker.
- Regressionstests über Desktop, iOS Safari, Android WebView und eingebettete Browser.
gPdf macht daraus eine Nutzungsrechnung. Der öffentliche Basic Plan startet bei 5 USD/Monat für 100.000 Seiten; Standard-Mehrverbrauch startet bei 0,00005 USD pro Seite. Das ist ein Anbieterkostenpunkt, entfernt aber die Notwendigkeit, jedes Frontend-Bundle und jedes Nutzergerät wie einen Produktions-PDF-Service zu behandeln.
CJK-Kosten sind nicht nur Dateigröße
Die erste harte Grenze ist CJK-Text: Chinesisch, Japanisch und Koreanisch.
Die integrierten Standard-PDF-Schriften von jsPDF reichen für einfache Ausgaben mit lateinischem Text, decken aber nicht alle Unicode-Glyphen ab. Enthält das Dokument CJK-Text, braucht die Anwendung eine Schrift, die diese Glyphen tatsächlich enthält. Browserseitige Implementierungen paketieren dafür häufig eine TTF-Datei, wandeln sie in ein Base64-JavaScript-Modul um oder laden Font-Daten vor der PDF-Erzeugung.
Diese Kosten werden doppelt bezahlt: zuerst als größerer Frontend-Payload, dann erneut als Browser-Speicher während der PDF-Erzeugung. Auf Mobilgeräten hält derselbe Tab dann Web-App, Font, Barcode-Puffer, Bilder und finale PDF-Bytes gleichzeitig im Speicher.
gPdf hält diese Arbeit serverseitig. Der Browser sendet strukturiertes JSON; der Renderer wählt aus gebündelten Fonts für Latein, Griechisch, Kyrillisch, CJK, Arabisch, Devanagari, Bengali, Thai und Monospace-Text. Eine 2-KB-Bestellung muss nicht zu einem 12-MB-Font-Delivery-Pfad werden.
Barcode-Kosten: Encoding ist leicht, Druckzuverlässigkeit ist schwerer
In Logistik, E-Commerce, Fertigung, Gesundheitswesen, Ticketing und Retail kann der Barcode wichtiger sein als der sichtbare Text. Menschen lesen die Bestellnummer; der Betrieb liest Code 128, GS1-128, QR, DataMatrix oder PDF417.
Mit jsPDF ist Barcode-Erzeugung meist eine separate Produktentscheidung. Teams kombinieren jsPDF mit einem Encoder, rendern den Barcode in SVG, Canvas oder ein Bild und setzen das Ergebnis dann ins PDF. Für einen Coupon-QR-Code oder einen Proof of Concept funktioniert das.
Fragil wird es, wenn der gedruckte Barcode operativ kritisch ist:
- Ein Canvas-Barcode kann mit falscher Auflösung gerastert werden.
- Ein skaliertes Bild kann Balken, Module oder Quiet Zones verwischen.
- Browser, CSS-Transformation oder Exportpfad können die finale physische Größe ändern.
- Unterschiedliche Barcode-Formate benötigen oft unterschiedliche Libraries oder Konvertierungspfade.
- Thermodrucker mit 203 DPI zeigen kleine Größenfehler schnell.
gPdf behandelt Barcodes als Dokumentelemente. Die Anfrage enthält type: "barcode", format, Nutzdaten und physische Maße in Millimetern. Der Renderer schreibt Vektor-Barcode-Geometrie für unterstützte 1D- und 2D-Formate direkt ins PDF, sodass Text, Formen, Tabellen, Bilder und Barcodes in einem Koordinatensystem bleiben.
Studio und Vorlageniteration
jsPDF ist code-first. Eine Layoutänderung bedeutet meist Änderungen an Zeichenbefehlen, Positionen, Font-Registrierung, Bildkonvertierung und Barcode-Platzierung in JavaScript.
gPdf unterstützt denselben API-orientierten Ablauf, ergänzt ihn aber um gPdf Studio als kostenlosen visuellen Designer für das PDF-Layout. Teams können Text, Bilder, Tabellen, Formen, Kopf- und Fußbereiche sowie Barcodes hinzufügen und verschieben und das Design anschließend mit template_id + data verbinden. Das zählt, wenn sich Label-, Rechnungs- oder Belegformate häufig ändern und nicht jeder Beteiligte PDF-Spezialist ist.
Mobile Browser sind der falsche Ort für schwere PDF-Arbeit
Clientseitige PDF-Erzeugung wirkt billig, weil die Serverrechnung null ist. Die Kosten wandern zum Nutzergerät.
Auf dem Desktop kann das akzeptabel sein. In mobilen Browsern kann ein Produktionsdokument den Tab hart belasten: CJK-Font-Daten, Base64-Bilder, Canvas-Puffer, Barcode-Bilder, erzeugte PDF-Bytes und die laufende App konkurrieren gleichzeitig um Speicher. iOS Safari und speicherschwache Android-Geräte sind weniger großzügig als ein Entwickler-Laptop.
Die Verlagerung zu gPdf ändert die Form des Problems. Der Browser baut eine kleine JSON-Anfrage, wartet auf eine binäre Antwort und lädt das fertige PDF herunter. Der Tab des Nutzers muss nicht Font-Manager, Barcode-Renderer, Layout-Engine und binärer PDF-Writer zugleich sein.
Wann jsPDF weiterhin richtig ist
Es gibt gute Gründe, bei jsPDF zu bleiben.
Wenn der Nutzer offline exportieren muss, ist jsPDF die bessere Wahl. Wenn Daten das Gerät überhaupt nicht verlassen dürfen, ist browserseitige Erzeugung die sauberere Datenschutzgrenze. Wenn das Dokument klein ist, nur lateinischen Text enthält und gelegentlich genutzt wird, lohnt sich die operative Komplexität einer API möglicherweise nicht. Für Prototypen und interne Tools ist jsPDF oft der schnellste Weg.
Die Entscheidung ändert sich, wenn die Ausgabe Teil eines operativen Ablaufs ist: ein Versandlabel, das scannen muss; eine Rechnung, die archiviert wird; ein Ticket, das geprüft wird; oder ein grenzüberschreitendes Auftragsdokument, das CJK-Namen korrekt darstellen muss. Dann ist “PDF im Browser erzeugen” weniger wichtig als “dasselbe Produktions-PDF zuverlässig erzeugen”.
Migrationsform
Die Migration ist kein Austausch eines Funktionsaufrufs. Sie verlagert imperative Browser-Zeichnung in eine strukturierte Dokumentanfrage.
- // 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();Der wichtige Wechsel ist die Zuständigkeit. Mit jsPDF besitzt Ihre Web-App den CJK-Font-Pfad, die Barcode-Erzeugung, das Browser-Speicherprofil und das Exportverhalten. Mit gPdf besitzt Ihre Anwendung Daten und Vorlage; der Edge-Renderer besitzt die Dokumentmechanik.
Verwandte PDF-Generierungsszenarien
Teams, die jsPDF und gPdf vergleichen, prüfen meist zuerst, ob die PDF-Erzeugung im Browser bleiben muss oder in eine kontrollierte API wandern kann. Für strukturierte Dokumente sind JSON-to-PDF API, Rechnungs-PDF API, Versandlabel API, GS1 Barcode API und Template PDF API die naheliegenden nächsten Seiten. Wenn Archivierung oder E-Invoicing wichtig sind, lesen Sie zusätzlich PDF/A API und Factur-X API.
FAQ
Ist jsPDF kostenlos?
Die Bibliothek selbst ist Open Source. Die Produktionskosten liegen in der Arbeit darum herum: CJK-Fonts, Barcode-Bibliotheken, Browser-QA, Druck-QA und Support für Geräte, denen der Speicher ausgeht.
Ersetzt gPdf jeden jsPDF-Anwendungsfall?
Nein. Offline-Browser-Export und lokale Dokumente bleiben das natürliche Gebiet von jsPDF. gPdf ist für Produktionsdokumente gedacht, bei denen ein kontrollierter Renderer den API-Aufruf wert ist.
Warum werden Barcode-Kosten separat erwähnt?
Weil ein Barcode auf dem Bildschirm gut aussehen und nach Skalierung, Rasterung oder Thermodruck trotzdem scheitern kann. Operative Dokumente brauchen Scanner-Zuverlässigkeit, nicht nur ein sichtbares Muster.
Siehe auch
- Die gPdf API-Referenz - DocumentRequest, Barcode-Elemente, Font-Fallback und Render-Endpunkte.
- Vektor- vs Raster-Barcodes in PDFs - warum Barcode-Geometrie nach dem Drucken zählt.
- GS1-128-Barcodes mit 0,1 mm Genauigkeit in JSON - labelorientierte Details zur Barcode-Größe.
- PDF/A und Factur-X für Entwickler erklärt - wann Archiv- und E-Invoice-Anforderungen in die PDF-Pipeline kommen.