0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

納品用マニュアルPDFを72dpiに落とすとキャプチャの文字が読めない — 実効DPIから選び直した話

0
Posted at

個人で受託開発をしていると、成果物の一つとして製品マニュアルの PDF を納品することがあります。写真や画面キャプチャを原寸のまま貼ったせいで 20 MB 近くになり、「メールで送れないので小さくしてほしい」と戻ってくる、というのがよくある流れです。これまでは毎回なんとなく一番小さい設定を選んでいましたが、一度きちんと比べてみたところ、その選び方だと画面キャプチャの小さい文字が読めなくなることが分かりました。この記事では、手元で再現できる形で確認手順と結果をまとめます。

検証用のマニュアル

お客様のファイルは使っていません。普段の納品物に近い構成で、自分で架空のマニュアルを作りました。

  • 架空ブランド「LEAF CO」、A4 で 8 ページ、本文は中国語
  • 各ページに写真 1 枚、管理画面のキャプチャ 1 枚(2880×1800 の PNG、数値はサンプル)、段落、ベクターの棒グラフ
  • 写真は Wikimedia Commons の CC0 画像をトリミング・色調整し、4032×3024 に拡大したもの
  • ファイルサイズは 19,458,294 バイト

手順 1:何が重いのかを見る

最初に PDF の中身をストリームの種類ごとに集計しました。画像ストリームが 19,308,166 バイトで全体の 99.23%、フォントは 128,406 バイト(0.66%)、ページの描画命令はわずか 9,662 バイトでした。つまりこのファイルを軽くするには画像を小さくするしかなく、文字やグラフの側をいじってもほとんど意味がありません。

参考までに、文字だけの 10 ページの PDF(フォントが 85%)も試しましたが、どのプリセットでも 4.8% しか減りませんでした。フォントのサブセット化は行わないツールなので、フォントが大半を占めるファイルでは効果が小さい、ということだと理解しています。ただしサンプルは 1 つだけです。

手順 2:画像の実効 DPI を計算する

実効 DPI は「画像のピクセル数 ÷ ページ上の表示サイズ(インチ)」で、縦横それぞれ計算します。写真は 4032 px がページ上で幅 9 cm(約 3.54 インチ)なので 1138 dpi、キャプチャは 2880 px が幅 17 cm なので 430 dpi でした。画面で見るだけなら明らかに過剰で、ここが容量の正体です。

手順 3:プリセットごとに出力して比べる

圧縮には imging.ai の PDF 圧縮を使いました。ブラウザ内で処理され、DevTools の Network タブを見ても処理中に GET 以外のリクエストは 0 件でした。プリセットは埋め込み画像の DPI 上限で、「画面・メール 72dpi」「電子書籍 150dpi」「印刷 300dpi」「ロスレス」の 4 つです。

画質の比較は、元ファイルと出力をどちらも 150 dpi でページ画像にレンダリングし、ページごとに PSNR を計算して平均しました。テキストはページから抽出して元ファイルと 1 文字ずつ比較しています。

プリセット 出力バイト数(画面表示) 元比 写真 / キャプチャの解像度 PSNR 平均
画面・メール 72dpi 352,318(344 KB) 1.81% 255×191 / 482×301・256 色 31.27 dB
電子書籍 150dpi 864,614(844 KB) 4.44% 531×399 / 1005×628 41.29 dB
印刷 300dpi 3,722,437(3.55 MB) 19.13% 1063×797 / 変更なし 54.74 dB
ロスレス 19,451,034(18.55 MB) 99.96% 変更なし 差分なし

ページ数はすべて 8 のまま、抽出したテキスト 3,357 文字もすべて一致しました。印刷プリセットでキャプチャに手が入らなかったのは、430 dpi が印刷プリセットのしきい値を下回っていたためです。

同じマニュアルのキャプチャ内の表を 150 dpi で描画した部分比較。赤枠が画面・メール 72dpi で、文字が判読できません。サンプルは自作の架空マニュアル(本文は中国語)です

電子書籍プリセットを選んだ画面。赤枠はプリセットのボタンと結果カード(18.56 MB → 844 KB)。右下の判定欄に写真ごとの 1138 dpi → 531×399 が出ています。サンプルは自作の架空マニュアルです

手順 4:macOS 標準の方法とも比べる

プレビューの書き出しで選べる Quartz フィルタ「ファイルサイズを減少」と同じシステムのフィルタファイルを、スクリプトから直接適用しました。プレビューの画面から手作業で書き出した結果とバイト単位で同じかどうかは確認していません。

結果は 1,432,231 バイトで、電子書籍プリセットより 66% 大きく、PSNR 平均は 38.00 dB でした。写真もキャプチャもまとめて 144 dpi の JPEG に変換されています。また、PDFKit でそのまま保存し直しただけのファイルは 20,040,400 バイトで、元より 3% 大きくなりました。

結論:用途で選ぶ

私は次のように決めました。

  • 画面で読む・メールで送る・共有ドライブに置く:電子書籍 150dpi
  • 印刷する:印刷 300dpi(72dpi だと写真が幅 255 px で 9 cm に載ることになり、印刷は試していませんが計算上足りません)
  • 画面・メール 72dpi:小さい文字がない、写真だけの冊子に限る

最後に単位の注意です。ツールの画面は 1 MB = 1024 KB で表示するので元ファイルは 18.56 MB、Finder では約 19.5 MB と表示されます。容量制限を言われたときは両方の数え方で確認しておくと安全です。そして、どのプリセットでも、出力を開いて一番細かい表のページを拡大して見てから送るようにしています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?