「PDF形式、2MB以下」という条件の提出フォームに、スキャンした書類を出す場面を想定して手順を確かめました。大学4年で、コンテストやインターンの応募でこの手の上限にちょくちょく当たります。圧縮すること自体より、圧縮したあと本当に上限内なのか、文字が読めるのか、の2点で迷ったので、その確認手順をまとめます。
実験には自分の書類ではなく、スクリプトで作った架空の「協力意向登録表」を使いました。中身は中国語の文章で、4ページとも300 dpiのカラー画像として描画し、ベージュの地色・ノイズ・1度未満の傾きを加えてスマホでスキャンしたように見せています。ファイルサイズは8,948,995バイトです。
手順1：スキャンPDFかどうかを見分ける
スキャンPDFは、各ページが1枚の画像になっているPDFです。テキストレイヤー（選択・コピー・検索ができる本物の文字の層）がないので、文字をドラッグしても選択できません。WordなどからエクスポートしたPDFにはテキストレイヤーがあります。いちばん簡単な見分け方は、ビューアで Ctrl+F を押して、確実に書いてある語を検索することです。ヒットしなければスキャンPDFと考えてよく、その場合はファイルの中身のほとんどが画像なので、圧縮が効きます。
手順2：150 dpi のプリセットを選ぶ
DPIは1インチあたりに並ぶピクセル数で、A4を300 dpiにすると1ページ2480×3508ピクセルになります。画面で書類を読むだけならここまでは要りません。
今回はブラウザ内で処理する ImgIng（https://imging.ai/）のPDF圧縮を使いました。個人情報の入った書類を外部サーバーに送りたくなかったからです。F12 の Network タブを開いたまま圧縮と保存をしましたが、ファイルを送信するリクエストは出ていませんでした。プリセットは「画面・メール 72dpi」「電子書籍 150dpi」「印刷 300dpi」「ロスレス」の4つで、結果は次のとおりです。
| プリセット | 結果 | 備考 |
|---|---|---|
| 画面・メール 72dpi | 347 KB | 文字の輪郭がにじむ |
| 電子書籍 150dpi | 1,927,707 バイト（表示 1.84 MB） | 78.5% 削減、文字はくっきり |
| 印刷 300dpi | 8.46 MB | 0.8% しか減らない |
| ロスレス | ほぼ変化なし | 画素を変更しない |
印刷プリセットでほとんど減らないのは、元のスキャンがすでに300 dpiで、それ以上下げる対象がないためです。
手順3：バイト数で上限と比べる
画面に出る 1.84 MB は 1 MB = 1024 KB で換算した値で、1000 で換算すると 1.93 MB になります。提出フォームの「2MB」が 2,000,000 バイトなのか 2,097,152 バイトなのかは、たいてい書かれていませんし、特定のフォームがどちらで判定しているかは私には確認できていません。そこでファイル情報のバイト数を見て、厳しいほうの 2,000,000 と比べるようにしました。1,927,707 バイトはどちらの基準でも下回っています。
手順4：拡大していちばん小さい文字を読む
サイズが収まっても、読めなければ意味がありません。同じ段落を各結果から切り出して並べると、72dpi の版は文字の縁がにじみ、読めなくはないものの目が疲れます。150dpi の版は線がはっきりしています。私はビューアで200%前後に拡大し、日付や番号のようないちばん小さい文字が読めるかを最後に確認しています。
比較用に、macOS 標準の Quartz フィルタ「ファイルサイズを減らす」（プレビューの書き出しで選べるもの）も試しました。ただし同じシステムのフィルタファイルを直接適用しただけで、プレビューアプリの画面から手作業で書き出して照合したわけではありません。結果は 2,905,274 バイトで、2MB を超えたままでした。
テキスト中心のPDFの場合
10ページの文字だけのPDF（137,782 バイト）も試したところ、4つのプリセットすべてが 131,156 バイトで、削減は 4.8% でした。このファイルはフォントが全体の 85% を占めており、このツールはフォントのサブセット化（使っていない字形を削ること）をしないため、削れる部分がほとんどありません。サンプル1件だけの結果なので、テキストPDF全般がこうだとは言えません。上限を超えている場合は、元の文書側で画像やページを見直す方向になりそうですが、そちらは今回試していないので数字は出せません。