同じ Web ページを 3 回 PDF にしたら、同じページとは思えない 3 つのファイルが出てきました。1 つ目は 2 ページで表のフォントが 6.74pt。2 つ目は 1 ページで 9.75pt。3 つ目は 2 つ目とほぼ同じ見た目なのに、文字が 1 文字も選択できず、容量は 6.4 倍。ページ側は何も触っていません。変えたのは「どの道を通したか」だけです。
先に言葉を 3 つ。ページ送り（改ページ）とは、いくらでも下にスクロールできる Web ページという一枚の布を、決まったサイズの紙の束に裁断する工程のこと。pt はその紙の上の単位で、A4 は 595×842pt、Letter は 612×792pt。px は画面側の単位で、ページの文字サイズはこちらで書かれています。2 つの単位は噛み合わないので必ず換算が入り、事故はたいていそこで起きます。もう 1 つ、選択できる文字とは、PDF 上でドラッグして反転でき、Ctrl+F で検索でき、コピーして取り出せる文字のこと。すべての PDF にあるわけではありません。
測ったもの
サンプルは自作で、中身は全部架空です。存在しない越境倉庫の配送明細、46 行の表、SKU も倉庫名も金額も作り物。実在の企業や実データは一切使っていません。通した 3 つの道は、ブラウザの印刷、図映 ImgIng（https://imging.ai/ ）の「ページの実寸に合わせる」書き出し、そして自分でスクリプトを組んだ「ページ全体をスクリーンショットして PDF に貼る」方式。出来上がった PDF は見た目で判断せず、ページ数・ページサイズ・本文の中央値フォントサイズ・抽出できる文字数をスクリプトで読みました。
1 本目：既定の用紙は思っているものとは限らない
ブラウザ印刷の既定は A4 だと思い込んでいました。この環境では違って、Letter の 612×792pt でした。用紙が決まってしまうと、1180px 幅のレポートを 816px 幅の版面に収めるしかなく、全体が一段縮みます。13px の表の文字は 6.74pt に落ち、ページ数は 2。文字が小さいのは画面のせいではなく、先に紙があって、内容がそこへ押し込まれたからです。
2 本目：紙を先に置かない
2 本目は前提そのものを外します。ページがレンダリングされた寸法が、そのまま PDF のページ寸法になる。同じレポートが 1 ページ、1080×1536pt、表の文字は 9.75pt。文字は選択でき、検索でき、本文中のリンクもそのまま押せました。
誤読される前に釘を刺しておくと、9.75 が 6.74 より大きいことは「こちらの方が鮮明に描けている」という意味ではありません。同じ dpi で並べても、字形の鮮明さに測定できる差は見つけられませんでした。違うのは「紙に収めるために縮める必要があったかどうか」で、これはページサイズの方針であって描画品質ではありません。
3 本目：見た目は同じ、失うものが大きい
スクリーンショット方式は、オンラインの変換ツールが実際によく採っている作りです。同じページで、選択できる文字は 0、容量は 995,232 バイト。2 本目は 2,996 文字が選択でき 156,370 バイトでした。6.4 倍という数字より痛いのは受け取る側で、検索も引用もできず、そこから何かに流し込むこともできません。
どちらの道でも避けられない 2 つ
ここで結論が出たと思ったのですが、2 つの発見に半分ひっくり返されました。
1 つはスクロールコンテナです。管理画面の表は高さを固定して内側にスクロールバーを持たせる書き方が定番ですが、書き出すとコンテナ内で見えていた一画面分しか出てきません。46 行の明細が、どちらの道でも 8 行だけ。残り 38 行は PDF に存在せず、画面には警告も出ません。両方が同じように落とすので、どちらかの優位点にはなりません。ツール側の回避策は今のところ見つかっておらず、書き出す前に表をコンテナから出して高さを伸ばしておく、という運用で凌いでいます。
もう 1 つの方が示唆的でした。同じ長い表に、印刷時だけ効くスタイルを足してみます。用紙は A4、ヘッダーは毎ページ繰り返す、行をページ境界で分断しない。すると 2 本の道の結果が完全に一致しました。どちらも 7 ページの A4、ヘッダーは 7 回繰り返し、項目ごとに一致。つまりページ送りはページ自身の CSS がほぼ決めていて、ツールはそれを実行しているだけ。ページに印刷用スタイルが 1 行もないときに限って、ツール側に「紙に裁つか、実寸で通すか」の選択肢が生まれます。
ブラウザのタブで動くものは全部ローカル、と思われがちなので、そこも書いておきます。図映自身の説明によれば、読み込み、フォルダの読み取り、リソースのマッピング、即時プレビュー、そして PDF を受け取った後の可逆的な最小化は、すべてブラウザ内のローカルで完結し、この区間の送信はゼロ。変換ボタンを押した後にはじめて、スクリプトを取り除きリソースをすべてインライン化した自己完結 HTML スナップショットを、1 回の POST で同一オリジンのエンドポイントへ送り、サーバー側の Chromium / Skia が本物の PDF を返します。これが同社のドキュメント機能で唯一サーバーを経由する部分です。ネットワークパネルを開いて確かめたところ、押す前は非 GET リクエストが 0 件、押した後はちょうど 1 回の POST でした。機密性のあるページなら、まずこの一点を判断してからだと思います。
いまの使い分けはかなり短くなりました。ページに印刷用スタイルがあるなら 2 本の道は一致するので、手近な方でいい。ないうえに表が横に広いなら、実寸で通す方がフォントサイズを守れる。そのどちらを選ぶ前にも、表がスクロールコンテナに閉じ込められていないかを確認する。確認方法は 1 つで足ります。書き出した PDF で、最後の数行にしか出てこない語を検索してみる。見つからなければ、行は落ちています。