iText Suite 9.8は、文書の共有や保管、読みやすさに関わるPDF文書づくりを見直す実務担当者に向けて、縦書き、図版表現、脚注、依存関係更新、MarkdownからPDFを作る仕組みなどの更新点を整理します。
目次
文書生成フローで確認したいiText Suite 9.8の位置づけ
文書生成を業務に組み込む担当者にとって、PDF文書の見た目、読みやすさ、運用時の扱いやすさは確認したい項目です。iText Suite 9.8は、2026年秋のリリースとして示され、iText Core 9.8.0ではレイアウトエンジンに2つの追加が入りました。変換や配置の土台を確認する入口になります。 全角数字や縦組みの扱いも含めて、既存テンプレートを見直す際の起点になります。施設や法務文書など、画面だけでなく配布用の文書を扱う場面にも関係します。業務担当者は、まずどの機能が自社の文書フローに関係するかを切り分けられます。
更新点は縦書きだけではありません。SVGは、図やロゴなどのベクター画像を扱う形式として、放射状グラデーション、マスク、高度な線の表現が追加されました。iText Suite本体の外では、MarkdownからPDF/UA-2文書を作る無料のGitHub Actionも公開されています。詳細な機能、改善、修正は、iText Coreと追加製品のリリースノートに整理されています。 そのため、検討時は機能紹介だけで判断せず、利用する追加製品の変更点も合わせて確認する流れが自然です。文書生成の標準化を考える場合、Core側と周辺機能の両方を同じ視点で見る必要があります。
縦書き文書をレイアウトエンジンで扱う
日本語、中国語、韓国語向けの文書では、縦書きの表現が業務文書の品質に関わることがあります。iTextでは、対象市場向けの文書を、回避策や正しい向きの文字画像を差し込む方法ではなく、ネイティブに生成できるようになりました。縦書きは横書きの文字ブロックを回転するだけではないため、レイアウト段階で扱えることが重要です。 文字の向きや段組みを後処理で合わせる前提から、生成処理の中で扱う前提へ移せる点が確認対象になります。複数言語の文書を扱うチームでは、どの文書が縦書き要件を持つかを整理しやすくなります。
縦書きは、独立した文字配置機能として後付けするのではなく、レイアウトエンジンに組み込まれています。そのため、表、フレックスコンテナ、インラインブロックの中で動作し、はみ出し、配置、間隔、文字装飾も考慮されます。生成結果はPDFビューア間で一貫して表示され、縦書きテキストはタグ付けされるため、支援技術でも読める状態を保ちます。 画面表示だけでなく、読み取り支援を前提にした文書でも確認する価値があります。表内の縦書きや装飾付きの縦書きがある場合は、表示と構造の両面で検証項目を作れます。
図版表現と要素変形を確認する
文書には文字だけでなく、ロゴ、図、画面部品のような図版も含まれます。今回のリリースでは、作成されたShowcase PDFに縦書きCJKテキストの例が示されています。SVGでは、現代的なロゴや画面部品に使われる円形の色の混ざり方が、SVG、Kernel、Layoutでサポートされました。さらに、画像の一部を薄く見せたり表示したりする形状も、PDFソフトマスクを使って保持されます。 図版を画像化して貼る前に、ベクター表現として扱える範囲を確認できます。ブランド素材や説明図が多い文書では、文字と図の両方を同じ生成工程で見直す材料になります。
これらの図版関連の変更により、グラフィックをラスタライズする必要が少なくなり、PDFはシャープで拡大縮小しやすく、検索可能な状態を保ちやすくなります。レイアウト要素の回転、拡大縮小、傾きの指定も、Property.TRANSFORMでより分かりやすく表現できます。Javaと.NET向けの選択肢として示されています。 図版の再現性と要素変形を同じ節で確認すると、テンプレート修正時の作業範囲を見積もりやすくなります。文書内の図、表、注記を別々に直すのではなく、生成ルールとして扱える項目を洗い出せます。
脚注の往復と保守更新を運用目線で見る
長い文書や根拠を多く含む文書では、脚注の行き来が読みやすさに影響します。このリリースでは、脚注記号をクリックして注へ移動し、注をクリックして読んでいた位置へ戻れるようになりました。長文、法務、学術、技術文書や、画面上で読む利用者に対する使いやすさの向上として説明されています。 読者が参照箇所から離れても戻れることは、電子文書の確認作業と相性があります。脚注を多用する文書をPDF化する場合、目次や本文だけでなく脚注の動線も検証対象にできます。記載内容そのものを変えず、移動のしやすさを確認する流れになります。
運用面では、新機能だけでなく依存関係や修正の確認も必要です。iText Core 9.8.0では、Bouncy Castleの標準ライブラリとFIPSライブラリ、Jackson Databind、Apache HttpClient、Logbackなどの暗号関連およびユーティリティ依存関係が更新され、暗号化用の初期化ベクトル生成も修正されました。標準14 PDFフォントのテキスト抽出時のフォントキャッシュも復元されています。 セキュリティ更新を取り込む目的でアップグレードが推奨されています。文書の読みやすさを見直す作業と合わせ、実行基盤や抽出処理の変更点も確認できます。
検証項目と文書形式の流れをつなげる
品質確認では、異常な構造を持つファイルや署名関連の検証も見落とせません。フォームXObject間に循環参照を含む不正なファイルでは、スタックオーバーフローが起こる可能性がありました。署名を扱う場合には、Digital Signatures Hubにリソースと例が用意されていると説明されています。 生成した文書だけでなく、外部から受け取るPDFを処理する業務では、こうした入力側の確認も必要です。署名付き文書を扱う担当者は、検証資料を参照しながら、処理対象の文書種別を分けて確認できます。
PDF/A検証では、複数のコンテンツストリームを持つページが正しく扱われるようになり、Unicodeマッピングのない代替グリフの検証もより正確になりました。一方、Markdownは文書を書く方法として使われ、PDFは共有、保管、アクセシビリティ対応の形式として説明されています。 そのため、検証の話題はファイルの正しさだけで終わりません。書いた内容をどの形式で配布し、どの基準で確認するかまでつなげて考えられます。Markdownで管理する文書をPDFにする場合も、変換後の検証項目を工程に含めることができます。
MarkdownからアクセシブルなPDFへつなぐ
Markdownで書いた文書と、配布用のPDF文書との間を埋める仕組みとして、新しいGitHub Actionが説明されています。README、ドキュメント、変更履歴は、変更をプッシュするたびにアクセシブルなPDFとして公開できます。今回のSVG改善により、Markdown内の図も良好にレンダリングされるとされています。 文書をリポジトリで管理しているチームでは、更新とPDF出力を同じ流れに置く発想ができます。手作業の配布用ファイル作成だけに頼らず、変更のタイミングで出力物を確認する工程を組み立てられます。
アクセシブルな文書を作りやすくすることも、この更新の文脈にあります。ApryseはPDF Associationのメンバーとして、Adobe、Foxitとともに、PDF 2.0仕様であるISO 32000-2を無償で利用可能にするスポンサーの1社とされています。文書を扱う担当者は、標準への対応を検討する際、生成機能だけでなく、参照できる仕様の位置づけも確認できます。 アクセシビリティ対応を単発の修正にせず、作成、配布、確認の流れに組み込む観点で見られます。MarkdownからPDFへの変換も、その流れの一部として整理できます。
標準仕様と実装例を確認する
標準仕様の確認では、ISO TS 32001、32002、32003、32004も関連します。これらはハッシュアルゴリズム、電子署名拡張、AES-GCM暗号化、整合性保護を扱う技術仕様として、無償バンドルに含まれます。GitHub Actionのコードはソースリポジトリで確認でき、フィードバックや改善提案も受け付けられています。 仕様と実装の両方を見られることは、導入前の確認作業に役立ちます。標準への対応項目を確認しながら、変換処理そのものの改善余地も把握できます。社内で文書運用ルールを作る場合、参照先を明確にできます。
iText Core 9.8.0のリリースノートには、追加の添付ファイルも用意されています。これはGitHub上のiText Core READMEから生成されたアクセシブルなPDFで、変換結果の例として確認できます。pdfHTMLでは、初期リリースとして直立方向がサポートされ、横倒しや混在方向の縦書きは対象外とされています。 実際の確認では、利用したい表現が対応範囲に入るかを先に見ます。サンプル出力を見ながら、HTMLテンプレートやMarkdown文書のどちらを出力経路にするかを整理できます。
HTMLテンプレート再利用と墨消しの注意点
HTMLテンプレートを使う文書生成では、ブラウザで見た内容とPDF出力の差が課題になります。pdfHTMLの更新により、PDF出力はブラウザで見える内容に近づき、東アジア市場向けにHTMLテンプレートを再利用する道筋がより明確になります。部分的なHTMLをPDF/UAへ変換する場合、言語属性の扱いもより一貫し、空のlang値による問題が起きないようになりました。 既存テンプレートを使い回す場合、見た目とアクセシビリティ情報を同時に確認できます。テンプレート変更時には、縦書き表示だけでなく、言語属性の入力状態も点検できます。
アクセシブルな文書を扱う場合、削除済みに見える情報が構造側に残らないかも確認が必要です。このリリースでは、アクセシブル文書を墨消しする利用者が知るべき顧客報告の問題が修正されました。pdfSweep 5.0.8では、墨消し領域内の代替テキストや置換テキストも削除され、文書構造の上位レベルで定義されたテキストも含まれます。 画面上の削除だけでなく、支援技術が参照する情報も対象に入る点が重要です。機密情報を扱う文書では、可視部分と構造情報の両方を確認する運用にできます。PDFのアクセシビリティ対応と墨消しを別々に扱わず、同じ検証フローへ組み込めます。
確認ポイント
導入前の確認ポイントとして、まず機密情報の扱いを整理します。可視部分と構造上の墨消しが同期されるため、機密内容はタグから復元できないと説明されています。さらに、pdfOCR 5.0.2は、iText Core 9.8.0の依存関係との互換性を維持するためのパッチリリースです。 アクセシブルPDFを墨消しする運用では、この更新が関係します。OCRや周辺製品を併用している場合は、Coreの更新だけでなく、追加製品の互換性も確認対象になります。運用手順では、文書生成、変換、墨消し、読み取りの工程を分けて点検できます。
XFAフォームを扱う場合には、フラット化前にXFA文書を変更する方法に関する記事も参照先として示されています。また、pdfHTMLとstyled-xml-parserでは、CSSの属性セレクター一致を改善する修正が取り込まれました。セレクター値をパターン照合の前に適切にエスケープする内容です。 最後に見るべきことは、利用中の文書形式とテンプレート技術が更新範囲に含まれるかです。PDF生成だけでなく、フォーム、スタイル指定、変換後の確認まで含めて洗い出すと、検証作業を段階化できます。