Porównania

gPdf vs jsPDF: PDF w przeglądarce czy API na edge

jsPDF dobrze sprawdza się przy szybkich PDF-ach w przeglądarce, ale fonty CJK, dokładność kodów kreskowych, pamięć mobilna i wymogi zgodności zmieniają architekturę.

W skrócie

jsPDF jest praktycznym wyborem do lekkich PDF-ów generowanych w przeglądarce, prototypów, paragonów i eksportów offline. Kompromis pojawia się wtedy, gdy dokumenty produkcyjne potrzebują tekstu CJK, kodów kreskowych gotowych do skanowania, stabilności mobilnej albo wyników zgodnych z wymaganiami archiwizacji i e-fakturowania. gPdf przenosi fonty, kody kreskowe, układ i generowanie PDF do kontrolowanego API na edge, więc przeglądarka wysyła dane i odbiera gotowy PDF.

Obok siebie

Kryterium gPdf jsPDF Przewaga
Gdzie działa generowanie
Siłą jsPDF jest działanie po stronie klienta; ta sama cecha przenosi CPU i pamięć na każde urządzenie użytkownika.
Izolaty V8 Cloudflare Workers na edge Karta przeglądarki użytkownika gPdf
Obsługa fontów CJK
Standardowe fonty PDF w jsPDF nie pokrywają UTF-8/CJK; zespół musi załadować lub spakować odpowiednie dane TTF.
Wbudowany mechanizm rezerwowy dla chińskiego uproszczonego, japońskiego i koreańskiego Wymaga własnego fontu zawierającego potrzebne glify gPdf
Obciążenie interfejsu webowego dla CJK Brak zasobu fontu CJK w pakiecie aplikacji webowej Często wielomegabajtowe pliki fontów albo wygenerowane moduły base64 gPdf
Model kodów kreskowych Natywny element `barcode` dla formatów 1D i 2D Zwykle osobna biblioteka kodów kreskowych, SVG/canvas albo ścieżka obrazów gPdf
Dokładność druku kodów
Dla etykiet wysyłkowych, magazynowych i biletów skanery oceniają geometrię wydruku, strefy ciszy i rozmiar modułu, nie tylko wygląd na ekranie.
Wektorowe paski i moduły bezpośrednio w PDF Zależy od tego, jak przeglądarka konwertuje i skaluje kod do PDF gPdf
Stabilność w przeglądarkach mobilnych Generowanie jest wykonywane poza kartą przeglądarki PDF, fonty, obrazy i kody zużywają pamięć klienta gPdf
Wsparcie offline Wymaga dostępu sieciowego do API Może działać w pełni offline w PWA albo lokalnej aplikacji jsPDF
PDF/A i e-fakturowanie Profile PDF/A oraz punkt końcowy Factur-X/ZUGFeRD Nie jest naturalnym wyborem dla archiwizacji ani hybrydowych e-faktur gPdf
Cena katalogowa Plan Basic 5 USD/miesiąc obejmuje 100 000 stron; nadwyżka od 0,00005 USD za stronę Biblioteka open source; brak rachunku od dostawcy za samą bibliotekę jsPDF
Koszt odpowiedzialności produkcyjnej API obejmuje fonty, kody kreskowe, środowisko wyjściowe i aktualizacje Aplikacja webowa utrzymuje pakowanie fontów, konwersję kodów, pamięć mobilną i QA przeglądarek gPdf
Najlepszy domyślny przypadek Ustrukturyzowane dokumenty produkcyjne: etykiety wysyłkowe, faktury, paragony, bilety, wyciągi Małe eksporty z przeglądarki, prototypy, dokumenty offline i proste PDF-y z tekstem łacińskim Remis

Co kiedy wybrać

Wybierz gPdf, gdy
  • Dokumenty zawierają tekst chiński, japoński lub koreański, a nie chcecie wysyłać dużych zasobów fontów do każdej przeglądarki.
  • Generujecie etykiety wysyłkowe albo bilety krytyczne dla skanowania: Code 128, GS1-128, QR, DataMatrix, PDF417 lub inne kody.
  • Użytkownicy często pracują w przeglądarkach mobilnych, a generowanie PDF nie powinno konkurować z aplikacją o pamięć.
  • Potrzebujecie PDF/A, Factur-X, ZUGFeRD albo jednego kontrolowanego generatora dla wyjść wrażliwych na audyt.
  • Ten sam proces PDF musi być wywoływalny z interfejsu webowego, usług serwerowych, zadań i integracji.
Wybierz jsPDF, gdy
  • Potrzebujecie w pełni offline eksportu z przeglądarki lub PWA bez wywołania serwera.
  • PDF jest mały, zawiera tylko tekst łaciński i jest generowany sporadycznie przez jednego użytkownika.
  • Prototypujecie i chcecie jak najszybciej rysować tekst, linie i obrazy w JavaScript.
  • Dane nie mogą opuścić urządzenia użytkownika nawet na krótkotrwałe żądanie generowania.
  • Akceptujecie własne utrzymanie pakowania fontów, kodowania i skalowania kodów kreskowych oraz skrajnych przypadków pamięci przeglądarki.
Możliwości

gPdf to API JSON do PDF działające na edge, zbudowane dla wysokowolumenowych faktur, dokumentów, etykiet wysyłkowych, kodów kreskowych, PDF/A i e-faktur. Renderowanie PDF w milisekundach na globalnej infrastrukturze edge — zoptymalizowane pod przewidywalne generowanie dokumentów klasy przemysłowej. Cennik na poziomie infrastruktury, wystarczająco niski, by zastąpić budowę i utrzymanie własnej infrastruktury PDF.

Możliwości

jsPDF świetnie nadaje się do lekkich eksportów z przeglądarki

jsPDF jest popularny, bo rozwiązuje realny problem produktowy: pozwala utworzyć PDF w przeglądarce bez uruchamiania usługi po stronie serwera. Programista może narysować tekst, linie, obrazy i proste tabele, a potem wywołać pobranie z tej samej strony. Dla prototypów, małych paneli administracyjnych, lokalnych paragonów i PWA działających offline to mocne dopasowanie.

Pytanie produktowe brzmi: gdzie ta granica przeglądarki przestaje być właściwa. Gdy PDF staje się dokumentem biznesowym, który klient skanuje, archiwizuje, wysyła mailem albo składa w innym systemie, praca nie polega już tylko na “narysowaniu pliku”. Dochodzi zarządzanie fontami, dokładność kodów kreskowych, stabilność mobilna, deterministyczny wynik i czasem PDF/A albo pakiet e-faktury.

Ten sam PDF, inna granica produktu

W jsPDF aplikacja webowa jest generatorem. Każda karta przeglądarki musi utrzymać bibliotekę, własne fonty, obrazy pośrednie, wynik kodów kreskowych i końcowe bajty PDF. Rachunek za bibliotekę pozostaje zerowy, ale odpowiedzialność produkcyjna przechodzi na urządzenie użytkownika.

W gPdf przeglądarka albo usługa serwerowa wysyła ustrukturyzowany DocumentRequest albo żądanie template_id + data. gPdf odpowiada za środowisko generowania, wbudowane fonty, geometrię kodów kreskowych i binarne generowanie PDF na edge. Aplikacja utrzymuje dane i logikę szablonu, nie silnik PDF.

Dopasowanie produktu: eksport offline vs dokumenty operacyjne

Wybierzcie jsPDF, gdy PDF jest lokalną funkcją wygody: mały przycisk eksportu, prosty paragon z tekstem łacińskim, zrzut panelu albo PWA, które musi działać bez sieci.

Wybierzcie gPdf, gdy PDF jest częścią procesu operacyjnego: etykiety wysyłkowe, oznaczenia magazynowe, faktury, bilety, zestawienia, formularze celne i paragony transgraniczne. Takie dokumenty potrzebują tego samego wyniku na każdym urządzeniu, a nie tego, co aktualna karta przeglądarki akurat bezpiecznie złoży.

Model kosztu: darmowa biblioteka vs posiadana powierzchnia produkcyjna

jsPDF ma oczywistą przewagę ceny: sama biblioteka jest open source, a CPU przeglądarki nie pojawia się jako pozycja na rachunku chmurowym. Dla małej funkcji wewnętrznej to może być najtańsza droga.

Koszt produkcyjny pojawia się wokół biblioteki:

  • Pliki fontów obsługujące CJK albo wygenerowane moduły base64.
  • Biblioteki kodowania i konwersji kodów kreskowych.
  • Błędy pamięci i pobierania zależne od przeglądarki.
  • QA wydruku dla skanerów i drukarek termicznych.
  • Testy regresji na komputerach, iOS Safari, Android WebView i przeglądarkach wbudowanych.

gPdf zamienia to na rachunek za użycie. Publiczny plan Basic zaczyna się od 5 USD/miesiąc za 100 000 stron, ze standardową nadwyżką od 0,00005 USD za stronę. To jest koszt dostawcy, ale eliminuje potrzebę sprawiania, żeby każdy pakiet interfejsu webowego i każde urządzenie użytkownika zachowywały się jak produkcyjna usługa PDF.

Koszt CJK to nie tylko rozmiar pliku

Pierwsza twarda granica to tekst CJK: chiński, japoński i koreański.

Wbudowane standardowe fonty PDF w jsPDF są użyteczne dla prostego tekstu łacińskiego, ale nie pokrywają wszystkich glifów Unicode. Gdy dokument zawiera CJK, aplikacja potrzebuje fontu, który rzeczywiście zawiera te znaki. W praktyce implementacje po stronie przeglądarki często pakują TTF, konwertują go do modułu JavaScript base64 albo pobierają dane fontu przed wygenerowaniem PDF.

Ten koszt płaci się dwa razy: najpierw jako większy pakiet interfejsu webowego, potem jako pamięć przeglądarki podczas generowania. Na urządzeniach mobilnych ta sama karta może jednocześnie trzymać aplikację webową, font, bufory kodów kreskowych, obrazy i końcowe bajty PDF.

gPdf trzyma tę pracę po stronie usługi. Przeglądarka wysyła ustrukturyzowany JSON; generator wybiera z wbudowanych fontów obsługujących tekst łaciński, grecki, cyrylicę, CJK, arabski, Devanagari, bengalski, tajski i monospace. Dane zamówienia o rozmiarze 2 KB nie muszą zmieniać się w ścieżkę dostarczania fontu 12 MB.

Koszt kodów kreskowych: kodowanie jest łatwe, niezawodny druk trudniejszy

W logistyce, e-commerce, produkcji, ochronie zdrowia, ticketingu i handlu detalicznym kod kreskowy bywa ważniejszy niż widoczny tekst. Człowiek czyta numer zamówienia; operacja czyta Code 128, GS1-128, QR, DataMatrix albo PDF417.

W jsPDF kod kreskowy jest zwykle osobną decyzją produktową. Zespoły łączą jsPDF z innym enkoderem, generują kod do SVG, canvas albo obrazu, a potem wkładają wynik do PDF. To działa dla kuponu QR albo prototypu.

Robi się kruche, gdy wydrukowany kod jest operacyjnie krytyczny:

  • Kod z canvas może zostać zrasteryzowany w złej rozdzielczości.
  • Skalowany obraz może rozmyć paski, moduły albo strefy ciszy.
  • Przeglądarka, transformacja CSS albo ścieżka eksportu może zmienić ostateczny rozmiar fizyczny.
  • Różne formaty kodów mogą wymagać różnych bibliotek albo konwersji.
  • Drukarki termiczne 203 DPI szybko pokazują drobne błędy rozmiaru.

gPdf traktuje kod kreskowy jako element dokumentu. Żądanie podaje type: "barcode", format, dane i fizyczny rozmiar w milimetrach. Generator emituje wektorową geometrię kodu w PDF dla obsługiwanych formatów 1D i 2D, więc tekst, kształty, tabele, obrazy i kody pozostają w jednym układzie współrzędnych.

Studio i iterowanie szablonu

jsPDF zaczyna się od kodu. Zmiana układu zwykle oznacza edycję poleceń rysowania, pozycji, rejestracji fontów, konwersji obrazów i rozmieszczenia kodów kreskowych w JavaScript.

gPdf wspiera ten sam proces oparty na API, ale dodaje gPdf Studio jako darmowy wizualny projektant układu PDF. Zespół może dodawać i przeciągać tekst, obrazy, tabele, kształty, nagłówki, stopki i kody kreskowe, a następnie podłączyć projekt do generowania template_id + data. To ma znaczenie, gdy format etykiety wysyłkowej, faktury albo paragonu często się zmienia i w układ muszą wejść osoby, które nie są specjalistami od PDF.

Przeglądarka mobilna to złe miejsce na ciężką pracę PDF

Generowanie PDF po stronie klienta brzmi tanio, bo rachunek serwera wynosi zero. Koszt przechodzi na urządzenie użytkownika.

Na komputerze to może być w porządku. Na urządzeniach mobilnych dokument produkcyjny potrafi mocno obciążyć kartę: dane fontu CJK, obrazy base64, bufory canvas, obrazy kodów kreskowych, wygenerowane bajty PDF i działająca aplikacja konkurują o pamięć w tym samym czasie. iOS Safari i urządzenia Android z małą pamięcią są mniej wyrozumiałe niż laptop programisty.

Przeniesienie generowania do gPdf zmienia kształt problemu. Przeglądarka buduje małe żądanie JSON, czeka na odpowiedź binarną i pobiera gotowy PDF. Karta użytkownika nie musi być jednocześnie menedżerem fontów, generatorem kodów, silnikiem układu i binarnym zapisywaczem PDF.

Kiedy jsPDF nadal jest właściwym wyborem

Są mocne powody, żeby pozostać przy jsPDF.

Jeśli użytkownik musi eksportować offline, jsPDF pasuje lepiej. Jeśli dane w ogóle nie mogą opuścić urządzenia, generowanie w przeglądarce jest czystszą granicą prywatności. Jeśli dokument jest mały, zawiera tylko tekst łaciński i jest używany sporadycznie, koszt wprowadzenia API może się nie zwrócić. Przy prototypach i narzędziach wewnętrznych jsPDF często jest po prostu najszybszą drogą.

Decyzja zmienia się, gdy wyjście jest częścią procesu operacyjnego: etykieta wysyłkowa musi się skanować, faktura musi się archiwizować, bilet musi się weryfikować, a dokument zamówienia transgranicznego musi poprawnie generować nazwy CJK. Wtedy mniej ważne jest “wygenerować PDF w przeglądarce”, a ważniejsze “wygenerować ten sam produkcyjny PDF niezawodnie”.

Kształt migracji

Migracja nie jest “zamianą jednego wywołania funkcji”. To przejście z imperatywnego rysowania w przeglądarce do ustrukturyzowanego żądania dokumentu.

- // 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();

Najważniejsza zmiana dotyczy odpowiedzialności. W jsPDF aplikacja webowa posiada ścieżkę fontów CJK, generowanie kodów kreskowych, profil pamięci przeglądarki i zachowanie eksportu. W gPdf aplikacja posiada dane i szablon; generator edge posiada mechanikę dokumentu.

Powiązane scenariusze generowania PDF

Zespoły porównujące jsPDF i gPdf zwykle sprawdzają najpierw, czy PDF musi powstać lokalnie w przeglądarce, czy ważniejsza jest powtarzalność produkcyjna. Przy dokumentach operacyjnych warto zobaczyć API JSON do PDF, API PDF faktur, API etykiet wysyłkowych i API kodów kreskowych GS1. Dla jakości kodów po wydruku pomocne są też artykuły o kodach wektorowych i rastrowych w PDF oraz GS1-128 z precyzją 0,1 mm.

FAQ

Czy jsPDF jest darmowy?

Sama biblioteka jest open source. Koszt produkcyjny to praca dookoła: fonty CJK, biblioteki kodów kreskowych, QA przeglądarek, QA druku i wsparcie urządzeń, którym kończy się pamięć.

Czy gPdf zastępuje każdy przypadek jsPDF?

Nie. Eksport offline w przeglądarce i dokumenty wyłącznie lokalne są naturalnym obszarem jsPDF. gPdf jest dla dokumentów produkcyjnych, w których kontrolowany generator jest wart wywołania API.

Dlaczego osobno mówić o koszcie kodów kreskowych?

Bo kod kreskowy, który wygląda dobrze na ekranie, nadal może zawieść po skalowaniu, rasteryzacji albo druku termicznym. Dokumenty operacyjne potrzebują niezawodności skanera, nie tylko widocznego wzoru.

Zobacz też