PDF内部構造の解剖と最適化アルゴリズム：ファイルサイズ削減の計算論的アプローチ

「PDFのファイルサイズを小さくする」という作業は、一見すると画像の解像度を下げる単純な操作に思われがちです。しかし、実際には**PDF内部構造（pdf internal structure）**に対する深い構造解析と、pdf compression techniqueに基づく再構成プロセスです。

本稿では、ISO 32000規格に基づくPDFファイルの物理構造をコンピュータサイエンスの視点から解説し、現代のpdf optimization algorithmがどのようにして無駄なデータを排除し、論理的にreduce pdf size logicを実現しているかを述べます。

Squishyfileの開発チームとして、私たちはこれらのアルゴリズムをWASM（WebAssembly）上で実装し、ブラウザ内完結型のクライアントサイド処理を実現しました。その技術的背景を含め、エンジニアリングの観点から本質を解き明かします。

PDFファイルの物理構造：4つの構成要素

PDFファイルは、単なる「見た目のデータ」の寄せ集めではありません。厳密な構造を持つバイナリフォーマットであり、以下の4つのセクションで構成されています。

1. Header（ファイルヘッダー）

ファイル先頭に位置し、%PDF-x.xというシグネチャでPDFバージョンを宣言します。例えば%PDF-1.4や%PDF-2.0です。このバージョン情報は、後続のBodyセクションで使用されるオブジェクト構文や暗号化方式の解釈基準を決定します。

2. Body（オブジェクト本体）

PDFの中核となるセクションです。ここでは、文書に含まれる全ての要素が**間接オブジェクト（Indirect Objects）**として管理されます。

Dictionary（辞書型オブジェクト）：<< /Type /Page /Parent 2 0 R >>のように、キーと値のペアで属性を定義します。ページ設定、フォント情報、画像リソースなどがここに格納されます。
Stream（ストリーム型オブジェクト）：stream〜endstreamで囲まれた領域です。実際の画像バイナリ（JPEG、PNG相当）、フォントデータ、ページコンテンツ（描画命令列）など、大容量データが格納されます。
Array（配列型オブジェクト）：[ 0 1 2 3 ]のように、複数の値を順序付けて保持します。例えばMediaBox（ページサイズ）の座標指定などに使用されます。

3. Cross-Reference Table（XRefテーブル）

PDFのランダムアクセス性を支える重要なインデックス構造です。各オブジェクトのファイル内オフセット（バイト位置）を記録しており、文書の先頭から末尾まで順に読み込む必要がありません。これにより、ページ単位の高速レンダリングが可能になります。

4. Trailer（トレイラー）

ファイル末尾に位置し、startxrefキーワードと共に、XRefテーブルの開始バイト位置を示します。最後に%%EOFマーカーでファイルが終了します。

なぜPDFファイルは「肥大化」するのか

PDFが予想以上に重くなる原因は、単なる画像の多さだけではありません。以下の構造的な要因が複合的に作用します。

インクリメンタルアップデートの蓄積

PDFは「上書き保存」ではなく「追記保存（Incremental Update）」を基本としています。編集・注釈を加えるたびに、変更されたオブジェクトと新しいXRefテーブルがファイル末尾に追加されます。古いオブジェクトは論理的に「無効」になりますが、物理的にはファイル内に残り続けます。結果として、編集履歴そのものがファイルの脂肪となり蓄積していきます。

未圧縮ストリームの存在

PDF仕様では、ストリームオブジェクトはFlateDecode（後述）などのフィルタで圧縮することが推奨されていますが、古いソフトウェアや特定のワークフローで生成されたPDFでは、ストリームが無圧縮（Raw）のまま埋め込まれている場合があります。これは構造的な無駄です。

メタデータと非参照オブジェクトの残存

文書情報（作成者名、ソフトウェア名、タイムスタンプなど）の過剰な付与、またはXRefテーブルから参照されていない**孤立オブジェクト（Orphan Objects）**が残存しているケースも少なくありません。これらは人間の目には見えませんが、ファイルサイズに直接寄与します。

画像とフォントの最適化アルゴリズム

Image Downsampling：解像度削減の数学

PDFに埋め込まれた高解像度画像（300 DPI以上のスキャン文書など）は、ファイルサイズの主要因となります。Image Downsamplingは、ピクセル密度を下げる処理ですが、単なる間引きではありません。

現代のPDF最適化エンジンでは、以下の補間アルゴリズムが用いられます。

Bilinear Interpolation（双線形補間）：周囲4ピクセルの加重平均を取る方法です。処理速度が速く、比較的滑らかな縮小結果を得られます。テキストや図表が主体の文書に適しています。
Bicubic Interpolation（双三次補間）：周囲16ピクセルを参照したより高度な補間法です。画像のエッジや階調表現が豊かな写真文書において、Bilinearより高品質な縮小結果を提供します。

適切なアルゴリズムの選択は、文書の用途（印刷用か閲覧用か）によって変わります。エンジニアリングの観点からは、DPIの再計算とピクセルグリッドの再サンプリングという数値解析処理であると言えます。

Font Subsetting：フォントの部分埋め込み

PDFにフォントを完全埋め込み（Full Embedding）すると、例えば10MB以上のTrueTypeフォントファイル全体が文書に内包されます。しかし、実際に文書内で使用されている文字（グリフ）は、全体のごく一部です。

Font Subsettingは、文書内で実際に参照されているグリフ（Glyph）とそのCMap（文字コード→グリフIDの対応表）のみを抽出し、新たなサブセットフォントを構築する技術です。

CMap解析：文書内のテキスト描画命令（Tjオペレータなど）を走査し、使用されている文字コードを特定します。
グリフ抽出：フォントプログラムから該当グリフのアウトラインデータ（Bezier曲線データ）のみを抽出します。
新フォント生成：抽出したグリフと最小限のメトリクス情報から、新たなフォントファイルを再構成します。

この処理により、10MBのフォントが数KB〜数十KBにまで削減されることもあります。これは単なる圧縮ではなく、**意味論的なデータの再構築（Semantic Reconstruction）**です。

FlateDecodeとガーベージコレクション：ストリームとオブジェクトの浄化

FlateDecode：zlib/Deflateによる可逆圧縮

PDF仕様において、ストリームオブジェクトの標準的な可逆圧縮方式はFlateDecodeです。これは、広く知られたzlibライブラリのDeflateアルゴリズム（LZ77 + Huffman符号化）をベースとしています。

FlateDecodeの圧縮プロセスは以下のように動作します。

LZ77辞書圧縮：入力データ内の繰り返しパターンを、過去の出現位置と一致長の参照で置き換えます。
Huffman符号化：出現頻度の高いシンボルに短いビット列、低いシンボルに長いビット列を割り当て、エントロピー符号化を実現します。

PDF最適化ツールは、未圧縮または低効率なストリームを検出し、FlateDecodeフィルタを再適用することで、構造的な冗長性を排除します。特に、ページコンテンツストリーム（描画命令列）はテキストベースのため、FlateDecodeによる圧縮率が非常に高くなります。

Garbage Collection：孤立オブジェクトの論理的削除

前述の通り、PDFのインクリメンタルアップデートにより、XRefテーブルから参照されていない「死んだオブジェクト」がファイル内に残存します。最適化エンジンは以下のプロセスを実行します。

XRefテーブルの完全走査：ファイル内で有効な全オブジェクトの参照関係をグラフ構造として構築します。
到達可能性解析（Reachability Analysis）：Trailerから辿れるオブジェクトのみを「生存オブジェクト」と判定します。
孤立オブジェクトの排除：到達不能となったOrphan Objectsをファイルから物理的に削除します。
XRefテーブルの再構築：連続した新しいオブジェクト配置に基づき、XRefテーブルとTrailerを再生成します。

この一連の処理は、プログラミング言語における**ガーベージコレクション（GC）**と概念的に同一です。PDFファイルに対してメモリ管理のような論理的操作を施し、ファイル全体を再構成するのです。

最適化の本質：データの再構築である

以上の技術を総合すると、PDFのファイルサイズ削減は「画像を小さくする」という視覚的な操作ではなく、以下のような計算論的プロセスであることが明らかになります。

構造解析：Header、Body、XRef、Trailerの4セクションを厳密にパースする。
セマンティック分析：使用されているフォントグリフ、画像リソース、メタデータを特定する。
数学的最適化：DPIの再計算、補間アルゴリズムの適用、FlateDecodeによるエントロピー削減。
論理的浄化：到達不能オブジェクトの排除とXRefの再構築。
物理的再構成：最適化されたオブジェクト群を新たな線形配置で書き出す。

このプロセスは、ファイルフォーマットに対する深い知識と、アルゴリズム設計能力を必要とします。

Squishyfileでは、これらの全ての処理を**WASM（WebAssembly）**モジュールとしてブラウザ上に実装しています。ファイルをサーバーにアップロードすることなく、ユーザーのデバイス内で上記の構造解析・再構成を完結させることで、セキュリティと効率性を両立しています。

まとめ

PDFの最適化は、一見単純な「圧縮」に見えますが、実際にはファイルフォーマットの内部構造に対する構造工学です。

PDF内部構造（Header, Body, XRef, Trailer）の厳密な理解
FlateDecodeに代表される可逆圧縮アルゴリズムの適用
Image Downsamplingにおける数学的補間処理
Font Subsettingによる意味論的リソース削減
Garbage Collectionによる論理的データ浄化

これらが統合されてこそ、真のreduce pdf size logicが成立します。私たちがSquishyfileで追求しているのは、「見た目を損なわずに、内部の論理構造を数学的に再構成する」というエンジニアリングの到達点です。

機密文書の取り扱いや業務効率化において、PDF最適化技術の理解はツール選択の重要な指針となるでしょう。