PDF圧縮のテスト：方法、ファイルサイズ、機能

テストしたことと、していないこと

このサイトのPDF圧縮ツールで使用している圧縮コードを、変更せずそのままテストしました。ただし、測定ではブラウザー内ではなく、Node.jsから直接呼び出して実行しました。これにより、各処理の入力、設定、保存された結果を正確に記録できます。

• 圧縮モジュール：WebAssembly版のQPDF 12.2.0、ラッパーのバージョンは0.3.0です。ラッパーのビルドスクリプトではQPDF 12.2.0が指定されており、インストール済みモジュールにバージョンを問い合わせた結果も12.2.0でした。
• 環境：Windows 11、ビルド26200、x64上のNode.js 24.18.1。
• 対象範囲：合成した入力ファイル三種類、九回の圧縮処理、および処理を拒否することを確認するための署名プレースホルダー入りテストファイル一つ。
• 事後検証：保存された十二個のPDF、計24ページについて、それぞれ構造検査とレンダリングしたページの表示確認を実施しました。

今回の測定に含まれないもの：

• 処理時間。時間は測定していません。
• 個々のブラウザーや、実際のスマートフォンおよびタブレットでの動作。
• 実際の写真、スキャン、大容量ファイル、利用者の文書。
• 他の圧縮ソフトやオンラインサービス。
• お手持ちのファイルで期待できる平均的な削減量。

テストファイル、設定、ダウンロード

このテストでは、自作したPDFだけを使用しています。顧客の文書、実際に撮影された写真、実在する人物の署名は含まれていません。画像入りファイルに含まれる画像も生成したものです。色のグラデーションを伴うテクスチャーで、写真でもスキャン画像でもありません。

• テキストファイル、3,029 バイト：二ページにテキスト、入力済みのフォームフィールド一つ、リンク一つ、ページの回転、構造ツリー内のマーク一つを含みます。
• 画像入りファイル、1,359,079 バイト：同じ構成要素に加え、640 × 800 ピクセルの生成画像を含みます。画像を含まないテキストファイルはわずか3,029 バイトなので、このファイルサイズの大部分は画像によるものです。
• 最適化済みのテキストファイル、2,721 バイト：これ以上サイズを削減できないケースとして使用します。
• 署名プレースホルダー入りファイル、3,139 バイト：署名の構造だけを含み、実際のデジタル署名は含みません。このファイルで、圧縮ツールが署名付きファイルの処理を拒否するかを確認します。

すべての処理で同じ初期条件を使用

• 各処理は、変更されていない元のバイト列から開始します。一回の処理で複数回の試行が必要な場合も、各試行は直前の結果ではなく、元のファイルからやり直します。
• すべての結果に、二ページ全体が含まれています。ページの削除、ZIP形式での格納、画像のピクセル数を減らす縮小、ページ全体の画像化は一切行っていません。この条件をそろえることで初めて、モード間でバイト数を比較できます。
• 各結果は、それぞれ別のファイル名で保存しました。入力と出力について、バイト数とSHA-256チェックサムを記録しています。チェックサムはファイルの指紋に相当し、たった一バイトでも変わるとチェックサムも変わります。
• 各処理について、モード、指定されている場合は目標サイズ、実際に使用したJPEGの品質を記録しています。

三つのモードが技術的に行うこと

記録と表では、モード名をlossless、balanced、smallとしています。ツール内では、losslessは「ロスレス最適化」、balancedは「バランス重視」、smallは「サイズが小さいファイル」という名称です。「ロスレス最適化」は、オブジェクトや圧縮されたデータストリームなど、ファイルの構造だけを最適化します。「バランス重視」は、それに加えて対象となる画像を品質レベル80のJPEGに再エンコードします。目標サイズを達成できなかった場合は、70で再試行します。「サイズが小さいファイル」はレベル65から開始し、目標を達成できなければ50、次に40で試行します。目標サイズを指定していて、元のファイルまたは構造を最適化したファイルがすでに目標を満たしている場合、非可逆のJPEG再エンコードを試す必要はありません。最後に、確認したファイルのうち最も小さいものを採用します。元のファイルより小さいものがなければ、元のファイルを維持します。したがって、一定の削減量を保証するものではありません。

QPDF 12.2のドキュメントによると、この処理でQPDFが画像の解像度を下げることはありません。ただし、JPEGへの再エンコードによって目に見える画像の乱れが生じることがあり、QPDFは再エンコードした画像データが小さくなる場合に限って採用します。画質への影響については、ガイド品質を損なわずにPDFを圧縮で説明しています。

確認用のファイルとチェックサム

次の表には、すべてのテストファイルと結果ファイルへのリンクを掲載しています。ダウンロード後、お好みのチェックサム確認ツールでSHA-256チェックサムを照合してください。一致すれば、測定に使用したファイルとまったく同じファイルです。英語の記録ファイルreproducibility-manifest.jsonには、すべての処理で使用した正確な呼び出し内容と設定が含まれています。

結果：ファイルサイズをありのままに提示

このテストから、お手持ちのPDFがどの程度小さくなるかを予測することはできません。結果はファイルの内容によって変わります。三種類のテストファイルだけでも、その幅が見られます。小さなテキストファイルはlosslessモードで10.17 パーセント小さくなりましたが、画像入りファイルは同じモードでわずか0.02 パーセントでした。画像入りファイルで86.78 パーセントの削減が得られたのは、JPEGへの再エンコードを行ってからです。表には、ほとんど削減できなかったものも含め、九回すべての処理を掲載しています。

削減率は常に実際のバイト数から計算しています。削減したバイト数を元のサイズで割った値です。balancedでの処理では、1,359,079 バイトのうち1,179,371 バイトを削減したため、86.78 パーセントとなります。お手持ちのファイルについては、圧縮率の計算ツールで計算できます。

JPEGの品質は、削減率を表すパーセントではありません

80、65、40などの値はJPEGエンコーダーの設定であり、サイズの削減率を示すパーセントではありません。今回、品質レベル80では86.78 パーセント、レベル65では90.75 パーセント削減できました。別のファイルでは、同じレベルでも結果が大きく異なることがあります。

削減できないケースも含める理由

最大の削減量だけを示すテストでは、重要なケースが見えなくなります。これ以上削減できない場合は、どうなるのでしょうか。2,721 バイトの最適化済みテキストファイルでは、losslessモードでそれより小さいファイルは得られませんでした。そのため、圧縮ツールは元のファイルを維持しました。出力は2,721 バイト、削減量は0 バイトで、入力と出力のSHA-256チェックサムは同一です。これにより、このケースでは効果のない書き換え済みファイルが渡されないことを、実際の圧縮モジュールで確認できました。その場合の対処法は、ガイドPDFのサイズが小さくならないで紹介しています。

目標サイズを達成した場合、達成できなかった場合、すでに満たしていた場合

• 目標250,000 バイト：レベル65での最初の試行で、すでに125,710 バイトになりました。これで目標を達成し、結果は目標を指定しなかった処理とバイト単位で完全に一致しています。
• 目標128 バイト：画像を含む二ページに対しては、現実的でないほど小さい目標です。最後のレベル40でも、74,707 バイトまでしか小さくなりませんでした。圧縮ツールは目標未達と表示しますが、ファイル自体は出力します。このテストファイルでは、保存された74,707 バイトの結果ファイルに両ページが含まれており、後述の機能検証にも合格しました。このとき、画像データには非可逆の再エンコードが行われています。この処理結果だけでは、他のすべてのファイルでも全内容が維持されることを証明できません。
• 目標1,359,079 バイト、つまり元のサイズとまったく同じ値：目標はすでに達成済みと判定されました。実行されたのは、構造に対するロスレス最適化だけです。結果は1,358,764 バイトで、losslessでの処理と同じサイズでした。画像はJPEGに再エンコードされていません。記録された呼び出し内容にJPEGの設定が含まれていないためです。

同じサイズでもチェックサムは異なることがあります

balancedでの処理を繰り返すと、再び正確に179,708 バイトになりましたが、SHA-256チェックサムは異なりました。また、目標がすでに満たされていた処理もlosslessでの処理と同じサイズですが、チェックサムは別の値です。考えられる理由の一つは、PDFの書き込み時に、新しい文書識別子などが生成されることです。一方、smallで目標を指定しなかった処理と、目標250,000 バイトを指定した処理は、バイト単位で完全に一致しました。つまり、チェックサムは特定の保存済みファイルを識別するものです。ブラウザー内での処理も含め、同じ処理を繰り返しても、サイズが同じだからといって必ずしもバイト単位で同一のファイルが得られるわけではありません。

表示と機能を別々に検証

ファイルが小さくなっただけでは、テキスト、フォーム、リンクが維持されているかどうかは分かりません。プレビューが正常に見えるだけでも、その証明にはなりません。そのため、保存されたファイルを、互いに独立した二つのライブラリーで検証しました。pdf-libは保存済みファイルの内部構造を読み取り、PDF.js 6.4.299はページをレンダリングしてテキストと注釈を読み取ります。この検証では、隔離されたChromiumのバージョン151.0.7922.34のインスタンス内でPDF.jsを実行しました。完成したファイルに対するこの検証は、Windows 11上のNode.jsで測定した圧縮処理とは別のものです。ブラウザー内やモバイル端末での圧縮は測定しておらず、この検証から他のPDFソフトの動作について判断することもできません。各検証にはそれぞれ独自の方法があり、結果が当てはまるのは、これらのテストファイルに限られます。

フォームフィールドについての補足です。この値はPDF.jsの通常のテキスト抽出では確実に現れるわけではないため、注釈を通じて読み取りました。したがって、圧縮済みPDFで入力済みのフォームの値を検索して見つからなくても、その値が失われたとは限りません。

balancedとsmallでは、目標がすでに満たされていたsmallでの処理を除き、画像を非可逆のJPEGとして再エンコードしました。その際、テキストと線のデコード済みコンテンツ命令は変わりませんでしたが、テクスチャーの画像データは変わりました。画像入りファイルから得られた結果をレンダリングしたページでは、画像の位置と表示範囲、およびページの回転は元のファイルと同じでした。ファイルを自分で確認する際には、次の点に注意してください。生成画像は元のファイルの時点ですでに複数行のテキストに重なっています。この重なりはテストファイル自体のもので、圧縮による損傷ではありません。結果にもそのまま残っています。これによって、すべての行の読みやすさを判断したり、品質を採点したりできるわけではありません。また、テクスチャーと色のグラデーションを含む生成画像だけでは、写真、スキャン画像、スキャン内の小さな文字が同じ品質レベルでどう変化するかはほとんど分かりません。関連する内容は、ガイドスキャンしたPDFを圧縮をご覧ください。

署名プレースホルダーで確認できるのは、圧縮ツールが署名構造を持つファイルを認識し、処理しないことだけです。圧縮コード上では、暗号化されたファイルと認証済みファイルも処理を拒否します。このテストは実際の署名の有効性を確認するものではなく、保護を回避するものでもありません。詳しくは、ガイド署名やフォームを含むPDFを圧縮をご覧ください。

限界と、自分で確認する方法

このツールはPDF24やAdobeより優れていますか？

このページでは、その問いには答えていません。他のソフトやオンラインサービスで、同じファイルを処理するテストは行っていません。そのため、品質、速度、価格について比較評価する根拠はありません。パーセント表示やスライダーのあるランキングも、このような比較の代わりにはなりません。公平に比較するには、同じ完全な入力ファイル、同じページ、記録された設定、正確なバイト数を用意し、すべての結果に同じ機能検証を行う必要があります。

お手持ちのPDFを確認する方法

1. 元のファイルを変更せずにコピーして保管してください。
2. PDF圧縮ツールを開き、ファイルを選択してください。画像の細部が重要な場合は、ロスレスモードから始めてください。
3. ファイルのプロパティなどで、元のファイルと結果の正確なサイズをバイト単位で記録し、圧縮率の計算ツールで削減量を計算してください。
4. 次の試行も毎回、すでに圧縮した結果ではなく、元のファイルから始めてください。ファイルを上書きしないように、結果は毎回新しいファイル名で保存してください。
5. 保存したファイルを、受信者も使用するプログラムで開いてください。すべてのページを確認し、文書内にあると分かっている単語を検索し、フォームの値とリンクを確認してください。また、画像や小さな文字を元のサイズで確認してください。
6. PDFにデジタル署名が付いている場合、暗号化されている場合、または認証済みの場合は、このツールで圧縮せず、発行者に手順を確認してください。