講義ページや参考資料を PDF にして、タブレットで読むことが多い。その中に大きな表が入ったページがあって、画面ではふつうに読めていたのに、印刷したら表の文字が紙に顔を近づけないと読めない大きさになっていた。右側の列も詰まっている。最初はプリンタのせいだと思い、大学の印刷室で別の機械でも刷ってみたが、まったく同じだった。
原因はプリンタではなく、「PDF に保存する」その一手だった。
何が起きているのかを測るために、似た見本を自分で作った。46 行の明細表、列は八つか九つ、中身はすべて架空、表の文字サイズはウェブでよく使われる 13px。単位を先に整理しておく。px は画面上の点、pt は紙の上の点で、A4 の幅は 595pt くらい。この二つは直接くらべられない。同じページを二通りで保存した。ひとつはブラウザの印刷から PDF にする方法、もうひとつは ImgIng（https://imging.ai/）の HTML → PDF で、既定は「ページ本来のサイズに合わせる」。どちらもページ数、ページ寸法、本文の中央値の文字サイズ、実際に選択できる文字数を測った。
処理がどこで走るかも見ておいた。読み込み、フォルダの読み取り、リソースの対応づけ、その場のプレビュー、そして PDF を受け取ったあとの可逆的な最小化は、すべてブラウザのローカルで完結し、この間の送信は 0 件。変換を押したあとだけ、スクリプトを取り除きリソースをすべてインライン化した自己完結の HTML スナップショットを、同一オリジンの ImgIng のエンドポイントへ 1 回の POST で送り、サーバ側の Chromium / Skia が本物の PDF を返す。
結果はこうだった。ブラウザ印刷は 2 ページ、612×792pt、表の文字 6.74pt。ページ本来のサイズに合わせた方は 1 ページ、1080×1536pt、文字 9.75pt。各行に印をつけて、途中で切られた行がないか数えたが、どちらも 0 行。つまり切れたのではなく、全体が縮んでいた。
仕組み自体は素朴だ。ウェブページは横にも縦にも好きなだけ伸びる帯で、紙は伸びない。帯が紙より広いとき、ブラウザは右側を切り落とすのではなく、幅が収まるまでページ全体を縮める。文字もいっしょに縮む。この表は画面上で 1180px 幅、紙の印刷可能な幅は 816px 前後。その比率が 69% であり、13px が 6.74pt になった正体でもある。列が多く横に広い表ほど不利になる。
ページ本来のサイズに合わせる方は縮めない。実際に描画された幅と高さのままの「紙」を作るので、文字は 9.75pt のまま残る。代わりに 1 ページが 1080×1536pt という大きな紙になり、長いページならもっと長くなる。タブレットで読むぶんには快適だが、印刷するならプリンタ側でもう一度縮むことになる。私はいま用途で分けている。画面で読むだけなら本来のサイズ、紙に出すなら印刷経由。ただし次の設定を直してから。
印刷といえば A4 だと思い込んでいたが、違った。この環境のブラウザの既定用紙は Letter、612×792pt で、A4 より短く狭い。A4 で刷る印刷所に Letter の PDF を持っていけば、プリンタ側でさらに縮小するか余白を足すことになり、文字はいっそう小さくなる。保存を押す前に、印刷プレビューの用紙の欄を一度見ておく。この一覧の中でいちばん手間のかからない対処がこれだった。
本当に中身が失われるのは別のケースだ。高さを固定した、それ自体がスクロールする枠の中に表を置いているページがある。管理画面の表はたいていこの形になっている。画面上では 46 行すべてをスクロールして読めるのに、PDF に保存すると、そのとき枠の中に見えていた行しか入らない。同じ表を枠に入れて両方の方法で保存したら、どちらも 8 行だけ。残りの 38 行はファイルに存在せず、どちらの画面にも警告は出ない。
対処は迂回しかない。保存する前に枠の高さを解除して表を伸ばすか、印刷向けのページがないか探す。なぜどちらの経路でも救えないのかは、正直まだ分かっていない。少なくとも特定のツールの出来が悪いという話ではなかった。
最後に、十秒で終わる確認をひとつ。保存した PDF を開いて、本文をマウスでなぞってみる。選択できるなら中身は本物の文字で、検索もコピーもできるし、レポートの付録に引用しても困らない。選択できないなら、そのページは文字が描かれた一枚の画像だ。比較用に、同じページを全面スクリーンショットとして PDF に収めたものも作った。抽出できる文字は 0 文字、サイズは 995,232 バイトで、文字が残っている方の 156,370 バイトの 6.4 倍。同じ 1 ページで、画面で見るかぎり区別はほとんどつかない。