軽量なブラウザーエクスポートではjsPDFは優れています
jsPDFが人気なのは、実際の製品課題を解くからです。バックエンドサービスを動かさず、ブラウザー内でPDFを作れます。開発者は文字、線、画像、簡単な表を描き、同じページからダウンロードを開始できます。プロトタイプ、小さな管理画面、ローカル領収書、オフラインPWAには強い選択肢です。
製品上の問いは、そのブラウザー境界がどこで限界になるかです。PDFが顧客に読み取られ、保管され、メール送信され、別システムへ提出される業務文書になると、作業は単なる「ファイルを描く」ことではなくなります。フォント管理、バーコード精度、モバイル安定性、再現性のある出力、ときにはPDF/Aや電子インボイスパッケージが必要になります。
同じPDF出力、違うプロダクトの担い方
jsPDFでは、フロントエンドアプリケーションがレンダラーです。すべてのブラウザータブが、ライブラリ、カスタムフォント、中間画像、バーコード出力、最終PDFバイト列を抱えます。ライブラリ費用はゼロに保てますが、本番責任は各ユーザー端末へ移ります。
gPdfでは、ブラウザーまたはバックエンドが構造化された DocumentRequest または template_id + data を送ります。gPdfはエッジでレンダー環境、同梱フォント、バーコード形状、PDFバイト列生成を担います。アプリケーションはデータとテンプレートロジックに集中し、PDFエンジンを持ちません。
向いている用途: オフラインエクスポートか業務文書か
PDFがローカルの便利機能ならjsPDFを選びます。小さなエクスポートボタン、シンプルなラテン文字だけの領収書、ダッシュボードのスナップショット、ネットワークなしで動き続ける必要のあるPWAなどです。
PDFが業務フローの一部ならgPdfを選びます。配送ラベル、倉庫タグ、請求書PDF、チケット、明細書、通関フォーム、越境領収書です。こうした文書には、今開いているブラウザータブが安全に組み立てられる範囲ではなく、端末をまたいで同じ出力が必要です。
コストモデル: 無料ライブラリか本番運用責任か
jsPDFライブラリには明らかな価格上の利点があります。ライブラリ自体はオープンソースで、ブラウザーCPUはクラウド請求書の明細項目になりません。小さな社内機能では、これが最安経路になることがあります。
本番コストは、ライブラリの周りに現れます。
- CJK対応フォントファイル、または生成済みbase64フォントモジュール。
- バーコードのエンコードと変換ライブラリ。
- ブラウザー固有のメモリ問題やダウンロード不具合。
- スキャナーと感熱プリンター向けの印刷QA。
- デスクトップ、iOS Safari、Android WebView、組み込みブラウザーをまたぐ回帰テスト。
gPdfはこれを利用量の請求に変えます。公開Basicプランは月5米ドルで10万ページから始まり、標準の超過は1ページ0.00005米ドルからです。これはベンダーコストですが、すべてのフロントエンドバンドルとすべてのユーザー端末を本番PDFサービスのように振る舞わせる必要を取り除きます。
CJKのコストはファイルサイズだけではありません
最初に厳しくなるのはCJKテキスト、つまり中国語、日本語、韓国語です。
jsPDFの組み込み標準PDFフォントはシンプルなラテン文字出力には有用ですが、すべてのUnicodeグリフをカバーしません。文書にCJKテキストが含まれる場合、アプリケーションにはそれらのグリフを実際に含むフォントが必要です。実装上は、TTFファイルを同梱する、base64のJavaScriptモジュールへ変換する、PDF生成前にフォントデータを取得する、といった形になりがちです。
このコストは2回払われます。まずフロントエンドの配信量が大きくなり、次にPDF生成中のブラウザーメモリが増えます。モバイルでは、同じタブがWebアプリ、フォント、バーコードバッファ、画像、最終PDFバイト列を同時に抱えることがあります。
gPdfはその作業をサーバー側に保ちます。ブラウザーは構造化JSONを送ります。レンダラーはラテン文字、ギリシャ文字、キリル文字、CJK、アラビア文字、デーヴァナーガリー、ベンガル文字、タイ文字、等幅テキストをカバーする同梱フォントから選びます。2 KBの注文データを、12 MBのフォント配信経路に変える必要はありません。
バーコードのコスト: エンコードは簡単でも印刷信頼性は難しい
物流、EC、製造、医療、チケット、小売の作業フローでは、バーコードが見える文字より重要な場合があります。人は注文番号を読み、業務はCode 128、GS1-128、QR、DataMatrix、PDF417を読みます。
jsPDFでは、バーコード生成は通常別の製品判断になります。チームはjsPDFに別のエンコーダーを組み合わせ、バーコードをSVG、canvas、画像へ描画し、それをPDFへ配置します。クーポンのQRコードや概念実証なら十分動きます。
印刷後のバーコードが業務上重要になると、壊れやすくなります。
- canvasバーコードが間違った解像度でラスタライズされる。
- 拡大縮小した画像でバー、モジュール、クワイエットゾーンがぼやける。
- ブラウザー、CSS transform、エクスポート経路が最終的な物理サイズを変える。
- 形式ごとに別ライブラリや別変換経路が必要になる。
- 203 DPIの感熱プリンターは、小さな寸法ミスをすぐに露出します。
gPdfではバーコードを文書要素として扱います。リクエストに type: "barcode"、format、バーコード内容、ミリメートル単位の物理サイズを書きます。対応する1D / 2D形式では、レンダラーがPDF内にベクターのバーコード形状を出力するため、テキスト、図形、表、画像、バーコードが同じ座標系に収まります。
Studioとテンプレート反復
jsPDFはコード中心です。レイアウト変更は通常、JavaScriptの描画命令、座標、フォント登録、画像変換、バーコード配置を編集することになります。
gPdfは同じAPI中心の作業フローを支えつつ、PDFレイアウト用の無料ビジュアルデザイナーとして gPdf Studio を追加します。チームはテキスト、画像、表、図形、ヘッダー、フッター、バーコードを追加・ドラッグし、そのデザインを template_id + data 生成に接続できます。ラベル、請求書PDF、領収書の形式が頻繁に変わり、PDF専門家でない人もレイアウトに関わる場合に重要です。
重いPDF作業をモバイルブラウザーに置くべきではありません
クライアントサイドPDF生成は、サーバー請求がゼロなので安く見えます。そのコストはユーザー端末に移ります。
デスクトップでは問題ないことがあります。モバイルブラウザーでは、本番文書はタブに強い負荷をかけます。CJKフォントデータ、base64画像、canvasバッファ、バーコード画像、生成済みPDFバイト列、実行中のアプリケーションが同時にメモリを奪い合います。iOS Safariや低メモリAndroid端末は、開発者のノートPCほど寛容ではありません。
生成をgPdfへ移すと問題の形が変わります。ブラウザーは小さなJSONリクエストを組み立て、バイナリレスポンスを待ち、完成PDFをダウンロードします。ユーザーのタブは、フォントマネージャー、バーコードレンダラー、レイアウトエンジン、バイナリPDFライターである必要がなくなります。
それでもjsPDFが正しい場合
jsPDFを使い続ける強い理由はあります。
ユーザーがオフラインでエクスポートしなければならないなら、jsPDFのほうが合います。データを端末から一切出せないなら、ブラウザー側生成のほうがプライバシー境界としてきれいです。文書が小さく、ラテン文字のみで、たまに使うだけなら、APIを導入する運用コストに見合わないかもしれません。プロトタイプや社内ツールでは、jsPDFがまさに最速経路であることが多いです。
判断が変わるのは、出力が業務フローの一部になったときです。スキャンされる配送ラベル、保管される請求書PDF、検証されるチケット、CJK氏名を正しく描画しなければならない越境注文文書。その時点で重要なのは「ブラウザーでPDFを生成する」ことではなく、「同じ本番PDFを高い信頼性で生成する」ことです。
移行の形
移行は「1つの関数呼び出しを置き換える」ことではありません。命令型のブラウザー描画から、構造化文書リクエストへ移ることです。
- // 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();重要なのは責任境界です。jsPDFでは、WebアプリがCJKフォント経路、バーコード生成経路、ブラウザーメモリ特性、エクスポート挙動を担います。gPdfでは、アプリケーションがデータとテンプレートを管理し、エッジレンダラーが文書生成の仕組みを担います。
関連するPDF生成シナリオ
jsPDFとgPdfを比較するチームは、ブラウザー内生成を続けるべきか、フォント・バーコード・出力環境をAPI側に寄せるべきかを見ています。CJKテキストやモバイル安定性が課題なら JSON-to-PDF API を、スキャン精度が重要なら GS1バーコードAPI と 配送ラベルAPI を確認してください。請求書やチケットのような業務文書では、請求書PDF生成 と テンプレートPDF API も関連します。
FAQ
jsPDFは無料ですか？
ライブラリ自体はオープンソースです。本番コストは周辺作業にあります。CJKフォント、バーコードライブラリ、ブラウザー品質確認、印刷品質確認、メモリ不足になる端末への対応です。
gPdfはすべてのjsPDF用途を置き換えますか？
いいえ。オフラインのブラウザーエクスポートとローカル専用文書は、引き続きjsPDFの自然な領域です。gPdfは、制御されたレンダラーにAPI呼び出しの価値がある本番文書向けです。
なぜバーコードのコストを別に扱うのですか？
画面上で問題なく見えるバーコードでも、拡大縮小、ラスタライズ、感熱印刷後に失敗することがあるからです。業務文書に必要なのは、見える模様ではなくスキャナーで読める信頼性です。
関連ページ
- gPdf APIリファレンス - DocumentRequest、バーコード要素、フォントフォールバック、レンダーエンドポイント。
- PDF内のベクターバーコードとラスター画像バーコード - 印刷後のバーコード形状が重要な理由。
- JSONで0.1 mm精度のGS1-128バーコードを生成する - ラベル向けバーコード寸法の詳細。
- エンジニア向けPDF/AとFactur-X解説 - アーカイブと電子インボイス要件がPDFパイプラインに入るタイミング。