こんにちは。プロダクトのフロントエンドを預かる身として、日々「画面いっぱいに広がるリッチなUI」と格闘していることだろう。しかし、どんなにモダンでイケてるSaaSを作ろうとも、ビジネスの現場では避けて通れない「悪魔の要件」が必ずやってくる。
そう、「PDF出力」と「帳票印刷」だ。
「え、スクリーンと同じ見た目で出せばいいんでしょ？」なんて軽く考えて実装した結果、ユーザーから「改ページ位置が変なところで途切れている」「右端が切れて2ページ目にいはみ出している」「A4の縦なのに横向きでしか印刷できない！」というクレームの嵐を食らい、深夜に涙を流した経験はないだろうか。
安心してほしい。君のコードやCSSの書き方が悪いわけではない。単に、ブラウザが「スクリーン（画面）」を描画するときの頭と、「プリンター」に紙パケットを流すときの頭を切り替えるメカニズムを、知らなかっただけなのだ。
今日は、フロントエンド・スペシャリストとして、Webブラウザのレンダリングエンジンの裏側で何が起きているのか、そしてプロとしてどうやってその暴れ馬を手懐けるのかを、徹底的に解説しよう。
—
1. ブラウザの裏側：なぜ印刷と画面表示はここまで違うのか？
まず、ブラウザのレンダリングパイプラインの基本を思い出してほしい。
HTMLがパースされてDOMツリーができ、CSSがパースされてCSSOMツリーができ、それらが合体してレンダーツリー（Render Tree）が構築される。そしてレイアウト（Reflow）、ペイント、コンポジットという流れだ。
ここで重要なのは、「画面用のレンダーツリー」と「印刷用のレンダーツリー」は全く別物として構築されるという点だ。
メディアクエリ `@media print` の真実
CSSで `@media print` を定義した瞬間、ブラウザのスタイル計算エンジンは、通常のスクリーン用プロパティとは別に、印刷用のプロパティセットを評価し始める。
裏側で何が起きているかというと、ブラウザ（BlinkやGeckoなど）のレイアウトエンジンは、無限に続くスクロール可能なキャンバスではなく、「物理的な紙のサイズ（A4やLetterなど）」という絶対的な制約を持つ仮想的なカンバスへとレンダーツリーを流し込み直す。これが俗にいう「ページネーション（Pagination）」のプロセスだ。
画面表示では `overflow: auto` でスクロールさせれば済んでいたものが、印刷の世界では「紙の高さ」というハードリミットに達した瞬間、エンジンは強制的にレイアウトを次のページへ「切り裂く（Split）」必要に迫られる。このとき、要素の途中で容赦なくテキストが真っ二つに分断される。これが、あの無残な「途切れた帳票」の正体だ。
—
2. ページ分割（Pagination）のコントロールと実務の知見
プリンターのインクと紙を無駄にしないために、フロントエンドエンジニアが制御しなければならないのは以下の3点だ。
1. どこでページを強制改行するか (`break-before`, `break-after`, `break-inside`)
2. 要素がページの境界線で真っ二体に割れるのをどう防ぐか (`break-inside: avoid`)
3. 紙のサイズや余白、ヘッダー・フッターをどう定義するか (`@page`)
かつては `page-break-before` や `page-break-inside` という古いプロパティが使われていたが、現在のモダンブラウザでは CSS Fragmentation Module Level 3 に基づく `break-` プロパティ（`break-before`, `break-after`, `break-inside`）が標準だ。これを使わない手はない。
—
3. 実践：コピペで使える「完璧な帳票印刷用CSS」
百聞は一見にしかずだ。実際のプロジェクトでそのまま使える、堅牢なCSSテンプレートを共有しよう。インボイス制度対応の請求書や、月次レポートの印刷画面などを想定してほしい。
/ ==========================================================================
印刷専用スタイルシート (Print Stylesheet)
========================================================================== /
@media print {
/ 1. ページ全体の基本設定：余白や用紙サイズの指定 /
@page {
size: A4 portrait; / A4縦サイズを指定。横なら landscape /
margin: 15mm; / ブラウザデフォルトのヘッダー・フッター（URLや日付）を消す効果もある /
}
/ 2. 画面不要なUI要素の完全排除 /
/ ナビゲーション、サイドバー、ボタン類、モーダルなどは印刷から除外する /
header,
footer,
nav,
.no-print,
button,
.sidebar {
display: none !important;
}
/ 3. 印刷用コンテナの幅を最適化 /
body {
background-color: #ffffff !important;
color: #000000 !important;
font-size: 12pt; / 画面用より少し小さめの印刷に適したフォントサイズ /
line-height: 1.5;
margin: 0;
padding: 0;
}
.print-container {
width: 100% !important;
max-width: none !important;
margin: 0 !important;
padding: 0 !important;
box-shadow: none !important;
}
/ 4. ページ分割（Pagination）の制御：悲劇を防ぐ防波堤 /
/ 請求書の明細行の途中でページが分断されるのを防ぐ /
.invoice-item,
.card,
.section-box {
break-inside: avoid;
page-break-inside: avoid; / 旧ブラウザのフォールバック /
}
/ 見出しが孤立して次のページに送られ、内容だけが前のページに残る「孤児（Orphan）」を防ぐ /
h1, h2, h3, h4 {
break-after: avoid;
page-break-after: avoid;
}
/ 重要なセクションの前に必ず新しいページを開始する（例：明細のあとの確認サマリーなど） /
.page-break-before {
break-before: page;
page-break-before: always;
}
/ 5. テーブルのヘッダー行の継承 /
/ ページを跨いだ際、次のページにも表のヘッダー（th）を自動複製させる /
table {
width: 100%;
border-collapse: collapse;
table-layout: fixed;
}
tr {
break-inside: avoid;
page-break-inside: avoid;
}
thead {
display: table-header-group; / これによりページが変ってもtheadが毎ページ上部に描画される /
}
tfoot {
display: table-footer-group;
}
/ 6. リンクURLの強制表示（アクセシビリティ配慮） /
/ 印刷物ではリンクをクリックできないため、hrefの値をテキストとして後ろに添える /
a[href^=”http”]:after {
content: ” (” attr(href) “)”;
font-size: 90%;
color: #555;
}
}
—
4. プロとして知っておくべき「ハマりどころ」とTips
このコードを当てれば大抵の案件は美しく片付くが、ブラウザの巣窟にはまだいくつかの罠が潜んでいる。現場の知見として共有しておこう。
① `@page` でのヘッダー・フッター（ページ番号）の制御
CSSだけで動的に「Page X of Y」のようなページ番号を完璧に振るのは、実はまだすべてのブラウザで完全には標準化されていない（Chromium系では `@page` のカウンターが徐々にサポートされつつあるが、実務ではブラウザの印刷ダイアログの「ヘッダーとフッター」のチェックボックスに依存せざるを得ないことが多い）。
もし厳密なページ番号が必要な場合は、フロントエンド側で印刷用の総ページ数を計算してHTMLを動的に生成する、というアプローチをとる必要がある。
② フレックスボックス（Flexbox）とグリッド（Grid）の罠
古いブラウザや特定のエンジンバージョンでは、`display: flex` や `display: grid` の内部にある要素のページ分割（`break-inside: avoid`）がうまく機能しないバグが散見される。
もし印刷レイアウトが崩れて仕方がない場合は、印刷用エリアだけは伝統的な `display: block` や `display: table` にフォールバックさせるという割り切りも、プロとしての重要な判断だ。
③ グラデーションや背景色の消滅
デフォルトでは、ほとんどのブラウザの印刷ダイアログにおいて「背景の色と画像」の印刷はオフ（インク節約のため）になっている。
これを強制的に有効化したい場合は、CSSに以下の一行を仕込んでおこう。
- {
-webkit-print-color-adjust: exact;
print-color-adjust: exact;
}
※ただし、これを使うとユーザーのプリンターのインクを大量に消費するため、デザイン側としっかり合意を取っておくこと。
—
まとめ
印刷用レンダリングの仕組みは、一見すると泥臭く、ブラウザごとの細かい挙動の違いに悩まされるレガシーな領域に見えるかもしれない。しかし、裏側で「画面のレンダーツリー」と「紙のレンダーツリー」がどう構築され、ページネーションという物理制約とどう向き合っているのかを理解していれば、恐れるに足りない。
「画面だけでなく、紙の上でも完璧な美しさを保つ」。
そんな細部へのこだわりを貫く姿勢こそが、君をただのコーダーから「信頼されるシニアフロントエンドエンジニア」へと引き上げてくれるはずだ。
次の帳票実装のタスクが来たら、ぜひこの知識を思い出してドヤ顔で綺麗に解決してほしい。健闘を祈る！
コメント