jsPDF sangat baik untuk ekspor browser ringan
jsPDF populer karena menyelesaikan masalah produk yang nyata: membuat PDF di dalam browser tanpa menjalankan layanan backend. Developer dapat menggambar teks, garis, gambar, dan tabel sederhana, lalu memicu download dari halaman yang sama. Untuk prototipe, layar admin kecil, struk lokal, dan PWA offline, ini cocok.
Pertanyaannya adalah kapan batas browser itu berhenti menjadi batas yang tepat. Begitu PDF menjadi dokumen bisnis yang dipindai pelanggan, diarsipkan, dikirim email, atau diserahkan ke sistem lain, pekerjaannya tidak lagi sekadar “menggambar file”. Ia menjadi manajemen font, akurasi barcode, stabilitas mobile, output deterministik, dan kadang paket PDF/A atau e-invoice.
Sama-sama PDF, batas produknya berbeda
Dengan jsPDF, aplikasi frontend Anda adalah renderer. Setiap tab browser harus menampung library, font custom, gambar sementara, output barcode, dan byte PDF final. Tagihan library memang nol, tetapi tanggung jawab produksi berpindah ke setiap perangkat pengguna.
Dengan gPdf, browser atau backend mengirim request DocumentRequest terstruktur atau template_id + data. gPdf memiliki lingkungan render, font bawaan, geometri barcode, dan pembuatan binary PDF di edge. Aplikasi tetap bertanggung jawab atas data dan logika template, bukan engine PDF.
Kesesuaian produk: ekspor offline vs dokumen operasional
Pilih jsPDF ketika PDF adalah fitur kenyamanan lokal: tombol ekspor kecil, struk Latin sederhana, snapshot dashboard, atau PWA yang harus tetap bekerja tanpa koneksi jaringan.
Pilih gPdf ketika PDF menjadi bagian dari alur operasional: label pengiriman, tag gudang, faktur, tiket, statement, formulir kepabeanan, dan tanda terima lintas negara. Dokumen seperti ini membutuhkan output yang sama di semua perangkat, bukan apa pun yang bisa dirakit dengan aman oleh tab browser saat itu.
Model biaya: library gratis vs permukaan produksi yang dimiliki sendiri
Keunggulan harga jsPDF jelas: library-nya open source, dan CPU browser tidak muncul sebagai baris biaya di tagihan cloud Anda. Untuk fitur internal kecil, ini bisa menjadi jalur paling murah.
Biaya produksi muncul di pekerjaan di sekeliling library:
- File font yang mendukung CJK atau modul font base64 yang dihasilkan.
- Library encoding dan konversi barcode.
- Bug memori dan download yang spesifik browser.
- QA cetak untuk scanner dan printer termal.
- Regression test di desktop, iOS Safari, Android WebView, dan embedded browser.
gPdf mengubahnya menjadi tagihan penggunaan. Paket Basic publik mulai dari US5/bulan untuk 100.000 halaman, dengan overage standar mulai US0,00005/halaman. Itu biaya vendor, tetapi menghapus kebutuhan membuat setiap bundle frontend dan setiap perangkat pengguna berperilaku seperti layanan PDF produksi.
Biaya CJK bukan hanya ukuran file
Titik keras pertama adalah teks CJK: Chinese, Japanese, dan Korean.
Font PDF standar bawaan jsPDF berguna untuk output Latin sederhana, tetapi tidak mencakup semua glyph Unicode. Ketika dokumen berisi teks CJK, aplikasi membutuhkan font yang benar-benar memuat glyph tersebut. Dalam praktik browser-side, tim sering memaketkan file TTF, mengubahnya menjadi modul JavaScript base64, atau mengambil data font sebelum membuat PDF.
Biaya itu dibayar dua kali: pertama sebagai payload frontend yang lebih besar, lalu sebagai memori browser saat PDF sedang dibuat. Di mobile, tab yang sama bisa menampung web app, font, buffer barcode, gambar, dan byte PDF final secara bersamaan.
gPdf menaruh pekerjaan itu di sisi server. Browser mengirim JSON terstruktur; renderer memilih dari font bawaan yang mencakup Latin, Greek, Cyrillic, CJK, Arabic, Devanagari, Bengali, Thai, dan monospace. Payload order 2 KB tidak perlu berubah menjadi jalur distribusi font 12 MB.
Barcode: encoding mudah, reliabilitas cetak lebih sulit
Dalam logistik, ecommerce, manufaktur, kesehatan, ticketing, dan retail, barcode sering lebih penting daripada teks yang terlihat. Manusia membaca nomor order; scanner gudang membaca Code 128, GS1-128, QR, DataMatrix, atau PDF417.
Dengan jsPDF, pembuatan barcode biasanya menjadi keputusan produk terpisah. Tim menggabungkan jsPDF dengan encoder lain, merender barcode ke SVG, canvas, atau gambar, lalu menaruh hasilnya ke dalam PDF. Ini cukup untuk QR kupon atau proof of concept.
Ia menjadi rapuh ketika barcode cetak menjadi bagian operasional yang kritis:
- Canvas bisa diraster pada resolusi yang salah.
- Gambar yang diskalakan bisa mengaburkan bars, modules, atau quiet zones.
- Browser, CSS transform, atau export path dapat mengubah ukuran fisik akhir.
- Format barcode yang berbeda dapat membutuhkan library atau jalur konversi yang berbeda.
- Printer thermal 203 DPI cepat memperlihatkan kesalahan ukuran kecil.
gPdf memperlakukan barcode sebagai elemen dokumen. Request menyebut type: "barcode", format, payload, dan ukuran fisik dalam milimeter. Renderer memancarkan geometri barcode vektor di dalam PDF untuk format 1D dan 2D yang didukung, sehingga teks, bentuk, tabel, gambar, dan barcode tetap berada dalam satu sistem koordinat.
Studio dan iterasi template
jsPDF bersifat code-first. Perubahan layout biasanya berarti mengubah perintah gambar, posisi, registrasi font, konversi gambar, dan penempatan barcode di JavaScript.
gPdf tetap mendukung alur API-first, tetapi menambahkan gPdf Studio sebagai desainer visual gratis untuk layout PDF. Tim dapat menambah dan menggeser teks, gambar, tabel, bentuk, header, footer, dan barcode, lalu menghubungkan desain ke pembuatan berbasis template_id + data. Ini penting ketika format label, faktur, atau tanda terima sering berubah dan orang yang bukan spesialis PDF perlu ikut mengatur layout.
Mobile browser bukan tempat ideal untuk PDF berat
Pembuatan PDF di sisi klien terlihat murah karena tagihan server nol. Biayanya hanya pindah ke perangkat pengguna.
Di desktop, itu mungkin tidak masalah. Di browser mobile, dokumen produksi bisa menekan tab cukup keras: data font CJK, gambar base64, buffer canvas, gambar barcode, byte PDF yang dihasilkan, dan aplikasi yang sedang berjalan semuanya berebut memori pada saat yang sama. iOS Safari dan perangkat Android dengan memori rendah jauh lebih tidak memaafkan dibanding laptop developer.
Memindahkan pembuatan PDF ke gPdf mengubah bentuk masalahnya. Browser membuat request JSON kecil, menunggu respons binary, lalu mengunduh PDF final. Tab pengguna tidak perlu lagi menjadi manajer font, renderer barcode, layout engine, dan penulis binary PDF sekaligus.
Kapan jsPDF tetap tepat
Ada alasan kuat untuk tetap memakai jsPDF.
Jika pengguna harus mengekspor dokumen saat offline, jsPDF lebih cocok. Jika data sama sekali tidak boleh keluar dari perangkat, pembuatan di sisi browser adalah batas privasi yang lebih bersih. Jika dokumen kecil, hanya teks Latin, dan digunakan sesekali, biaya operasional memperkenalkan API mungkin tidak sepadan. Untuk prototipe dan tool internal, jsPDF sering memang jalur tercepat.
Keputusan berubah ketika output menjadi bagian dari alur operasional: label pengiriman yang harus terpindai, faktur yang harus diarsipkan, tiket yang harus diverifikasi, atau dokumen order lintas negara yang harus merender nama CJK dengan benar. Pada titik itu, “membuat PDF di browser” kalah penting dibanding “menghasilkan PDF produksi yang sama secara andal.”
Bentuk migrasi
Migrasi bukan “mengganti satu function call”. Ini perpindahan dari gambar imperatif di browser ke request dokumen terstruktur.
- // 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();Perpindahan pentingnya ada pada kepemilikan. Dengan jsPDF, web app Anda memiliki jalur font CJK, jalur pembuatan barcode, profil memori browser, dan perilaku ekspor. Dengan gPdf, aplikasi memiliki data dan template; renderer edge memiliki mekanik dokumen.
Skenario pembuatan PDF terkait
Jika Anda sedang menilai apakah PDF sebaiknya dibuat di browser atau di layanan terkontrol, lihat juga JSON to PDF API, API faktur PDF, API label pengiriman, barcode GS1 di PDF, PDF/A API, Factur-X API, serta artikel tentang barcode vektor vs raster di PDF dan PDF/A + Factur-X untuk engineer.
FAQ
Apakah jsPDF gratis?
Library-nya open source. Biaya produksi ada di pekerjaan sekelilingnya: font CJK, library barcode, QA browser, QA cetak, dan dukungan perangkat yang kehabisan memori.
Apakah gPdf menggantikan semua use case jsPDF?
Tidak. Ekspor browser offline dan dokumen lokal tetap wilayah alami jsPDF. gPdf cocok untuk dokumen produksi ketika renderer terkontrol sepadan dengan satu panggilan API.
Mengapa biaya barcode dibahas terpisah?
Barcode yang terlihat benar di layar masih bisa gagal setelah scaling, rasterization, atau cetak termal. Dokumen operasional membutuhkan reliabilitas scanner, bukan sekadar pola yang terlihat.
Lihat juga
- Referensi API gPdf - DocumentRequest, elemen barcode, fallback font, dan endpoint render.
- Vector vs raster barcodes di PDF - mengapa geometri setelah cetak penting.
- GS1-128 presisi 0,1 mm di JSON - detail sizing untuk label.
- PDF/A dan Factur-X untuk engineer - kapan kebutuhan arsip dan e-invoice muncul.