OpenPDF

PDFの新規生成だけでなく、既存PDFの編集・暗号化・テキスト/画像処理までJava APIで扱う

公式READMEは、PDFの新規作成、既存PDFへのページ追加・削除や内容変更、テキストとフォント、画像・グラフィックス、表、暗号化、ページレイアウト、テキスト抽出を主要機能として挙げています。帳票出力だけでなく、既存文書の加工やサーバー側PDF処理をJavaコードへ組み込めるライブラリです。

出典：[2]

HTML→PDF、PDF→画像、Kotlin支援を別モジュールとして持ち、用途ごとに依存を分けられる

openpdf-htmlはFlying Saucer由来のHTML/CSS→PDF変換、openpdf-rendererはPDFページの画像化やSwing/JavaFX等での表示、openpdf-kotlinはKotlinからPDFを作りやすくするモジュールです。親POMではcore、html、renderer、Kotlin、fonts、toolbox等を別Maven moduleとして管理しており、単一の巨大APIではなく必要な機能を分けて採用できます。

出典：[2][3]

PDF 2.0、Brotli stream、署名系依存など、PDF仕様と実運用の機能を継続的に更新する

READMEはPDF 2.0（ISO 32000-2）対応を掲げ、Brotliで圧縮されたPDF streamの読み書きにも対応しています。3.0.5のリリースではBrotli対応に加え、暗号化・署名処理の更新やrenderer統合も含まれています。電子署名ではBouncy Castleが推奨依存として案内されており、生成・表示だけでなく文書セキュリティまで扱える範囲があります。

出典：[2][5]

Java/JVMの業務システムで、帳票・請求書・レポート・既存PDF加工をアプリ内部へ組み込みたい場合に

JavaやKotlinで動くバックエンドからPDFを直接生成したいシステム、HTMLテンプレートをPDF帳票へ変換したいサービス、既存PDFの結合・編集・暗号化・プレビューを自前アプリへ組み込みたい場合に向きます。iText 2/4系の古いコードを持つシステムでは、OpenPDFへの移行経路が用意されている点も比較材料になります。

OpenPDF 3.0はJava 21+と`org.openpdf`へのpackage移行が前提。旧版からの更新は単純なversion bumpではない

READMEでは2.1.x以降がJava 21+、2.0.xがJava 17+、1.4.xがJava 11+、1.3.xがJava 8+と整理されています。さらにOpenPDF 3.0ではJava package名がcom.lowagieからorg.openpdfへ変更されています。長期運用中のJVMアプリでは、JDK更新、import変更、依存moduleの差、iText互換コードの動作確認を含む移行計画が必要です。

最新安定版は2026年5月22日公開の3.0.5で、masterの親POMは3.0.6-SNAPSHOTです。本番依存ではREADMEやmasterのsnapshot値ではなく、Maven Central/正式releaseのversionを固定して評価する方が安全です。

出典：[2][3][5]

PDF/HTML入力はsandbox化されない。外部URL・file path・font・巨大PDFをアプリ側で検証する

Security PolicyはOpenPDFをsandboxed/hardened環境ではないと明記し、file path、image source、font名、HTML等を入力検証なしで処理すると説明しています。攻撃者が入力を制御できる場合、local file access、file URL経由のnetwork access、path traversal、SSRF、危険なbase64、巨大・不正PDFによるmemory exhaustionが問題になり得ます。

特にHTML→PDFや外部画像を扱うサービスでは、HTML sanitizer、URL/pathのallowlist、font制限、upload size制限、必要に応じたcontainer/sandbox実行をアプリ側で実装する必要があります。またcoreはMPL-2.0 OR LGPL-2.1+のdual licenseですが、openpdf-htmlとopenpdf-rendererはLGPL-2.1のみとREADMEに記載されているため、配布形態に応じて利用moduleごとのlicense確認が必要です。

出典：[4][2][3]