HTMLから作ったPDFで文字が切れて消えるとき｜目視では見つからない溢れを数値で検出する手順
HTMLから作ったPDFで文字が切れて消えるとき｜目視では見つからない溢れを数値で検出する手順
見積書、月次レポート、納品案内、店舗別の実績資料。こうした帳票をHTMLで組んでPDFに書き出す運用は、テンプレートを一度作れば量産できるため、店舗ビジネスの定例業務と非常に相性がいい方法です。
ただし、この方式には固有の事故があります。ページからはみ出した内容が、エラーも警告も出さずに静かに消えるという事故です。しかも、出来上がったPDFを目で見ても気づけません。気づくのはたいてい、資料を渡した相手が「最後の項目が書いてないのですが」と連絡してきたときです。
この記事では、その溢れを人の目ではなく数値で検出する方法と、検出できる状態にしておくためのテンプレート側の設計、そして溢れが見つかったときに直す順番を整理します。
結論：PDFの検品は目視ではなく「数値」で行う
先に正しいやり方を書きます。
PDFを書き出したら、各ページの中身が本文領域の高さに収まっているかを、ブラウザ上で数値として測ってから納品します。 目視確認は数値確認の代わりにはなりません。補助として行うものです。
測り方は単純です。ページ要素の上端から、そのページの最後の子要素の下端までの距離を取り、本文領域の高さの上限と比べます。上限を1pxでも超えていたら、その分は印刷結果から消えています。
document.querySelectorAll(".page").forEach((p, i) => {
const r = p.lastElementChild.getBoundingClientRect();
const pr = p.getBoundingClientRect();
console.log(i + 1, Math.round(r.bottom - pr.top)); // 上限以下ならOK
});上限の求め方は、A4縦であれば「297mm − 上下パディング」です。ブラウザの計算はCSSピクセル基準（96dpi）なので、297mmはおよそ1122pxになります。ここからテンプレートで指定した上下のパディングを引いた値が上限です。実際に運用しているA4テンプレートでは、この上限が1074pxでした。この数値はテンプレートごとに違うので、自分のCSSから必ず計算し直してください。
実行はヘッドレスのChromeで構いません。測定用のスクリプトを差し込んで --dump-dom で吐かせる、あるいはPlaywrightの evaluate() で値を受け取る、どちらでも数値は取れます。PDF化と同じコマンドの流れに組み込めるので、追加の手間は数十行のコードだけです。
なぜ目視では見つからないのか
HTMLでA4の帳票を組むとき、多くの場合こういうCSSを書きます。
.page { width: 210mm; height: 297mm; overflow: hidden; }この overflow: hidden が、目視での発見を不可能にしている正体です。
高さを超えた内容は、警告も出さず、赤い線も引かれず、単に描画されません。ブラウザの表示上も、PDFに書き出したあとも、「そこに何かがあったこと」を示す痕跡が一切残らないということです。
結果、出来上がったPDFを画面で眺めても、下のほうが少し詰まって見える程度にしか感じられません。文章が3行消えていても、見た目は「余白がやや少ないページ」でしかないのです。
実際にこの測定を導入して分かった例を挙げます。A4・4ページ構成の納品用資料を測ったところ、3ページ目の最終要素の下端が1300pxで、上限1074pxを226px超えていました。長さにすると約60mm、A4の縦幅のおよそ2割です。画面上ではまったく異常に見えないページで、実際には2cm以上の内容が消えていたわけです。
この型の不具合が厄介なのは、動作としては最後まで正常に完走する点にあります。スクリプトはエラーを返さず、PDFは正しい枚数で生成され、ファイルサイズも妥当です。壊れているのに、壊れたという信号がどこにも出ません。だからこそ、出す側が能動的に測りにいく以外に見つける手段がありません。
測れる状態にしておくためのテンプレート設計
数値で検出できるかどうかは、テンプレートの書き方に左右されます。設計時点で決めておくべき点が一つあります。
ページ最下部に置くフッターに margin-top: auto を使わないでください。 使う場合は、測定対象を「フッターの一つ上の要素」に変えてください。
理由は、margin-top: auto を使うとフッターが常にページ下端に張り付くためです。この状態では、内容がちょうど収まっているページも、内容が溢れているページも、最終要素の下端は同じ値になります。測定値が上限と一致するのが正常なのか異常なのか、区別がつかなくなるということです。
判定は「上限ぴったり＝収まっている」「上限超え＝溢れている」という読み方で行います。この読み方が成立するテンプレートにしておくことが、検出の前提条件になります。レイアウトの都合でどうしても margin-top: auto を使いたい場合は、フッターを測定から除外し、その直前のコンテンツブロックの下端で判定する設計にしてください。
溢れが見つかったときに直す順番
削る場所には効果の大小があります。順番を間違えると、資料の見栄えを落としたわりに数mmしか回収できません。
- 画像を切り詰める。 効果が桁違いです。実際のケースでは、管理画面のスクリーンショットのうち説明に関係のない下半分を捨てただけで、82mm回収できました。1手で60mmの溢れが解消し、余裕まで生まれています。
- セクションを別ページへ移す。 1ページに詰め込みすぎているだけのことが多く、章の切れ目で分ければ読みやすさも上がります。
- 余白や行間を詰める。 最後の手段です。ここから手をつけると、全ページの密度が上がって読みにくくなるうえ、回収できるのはせいぜい数mmです。
特に、説明用のスクリーンショットは無加工で貼られがちです。必要な部分だけをトリミングして貼るというルールをテンプレート側の運用に入れておくと、そもそも溢れが起きにくくなります。
大量生成では「1枚ずつ目で見る」が成立しない
帳票のHTML化が効くのは、店舗別・月別に何十枚も作るケースです。たとえば18店舗×3種類で54枚、19店舗の実績サマリーで19枚、といった規模になります。
この枚数を毎月人が1枚ずつ確認するのは現実的ではありません。検品も生成と同じスクリプトの中で自動化します。 実運用で機能している検品は次の4点です。
- 数値チェック：全ページの最終要素の下端を測り、上限超えがゼロであることを確認する
- 画像化して確認：全ページを画像に変換して並べ、数値では拾えない崩れ（画像の潰れ、表の折り返し、フォントの置換）を見る
- テキスト照合：PDFからテキストを抽出し、載っているはずの店舗名・数値・キーワードが全件含まれているか突き合わせる
- 対象の一致確認：生成前に、ページのヘッダーに出ている対象月や宛名が、これから作ろうとしている対象と一致しているかを検証する
4つ目は地味ですが重要です。データが月次で更新される仕組みの場合、元データの反映が終わる前に生成を走らせると、中身が前月のままのPDFが正しい枚数で量産されます。 これも「エラーは出ないが間違っている」型なので、生成前に1回照合を挟むだけで防げます。
周辺でつまずきやすい3点
最後に、HTML→PDF運用で実際に時間を取られやすい箇所を挙げておきます。
印刷用CSSが反映されない。 Playwrightなどのヘッドレスブラウザは、既定では画面用のCSSで描画します。印刷用のスタイルを当てるには印刷メディアのエミュレーションを有効にし、背景色や背景画像を出したい場合は背景印刷のオプションも明示的に指定します。ここを省くと、色帯やカードの塗りが飛んで白い紙のような仕上がりになります。
幅が合わない。 縦向き固定の帳票なら、書き出し時に向きを明示します。画面用に組んだコンテンツ幅がA4に収まらない場合は、拡大率で合わせるのが早い解決策です。実運用ではおよそ0.48倍で収めているケースもあります。この場合、縮小後に文字が読めるサイズを保っているかは、実寸で印刷確認するのが確実です。
日本語ファイル名でファイルが見つからない。 日本語を含むファイル名は、濁点や半濁点の表現方法（正規化形式）がツールによって異なります。一覧表示では見えているのに、コピーや検索のコマンドでは「そんなファイルはない」と言われる、という挙動になります。ファイル名の生成・検証・コピーを同じランタイムに寄せると回避できます。またクラウド同期フォルダ上のファイルはプレビュー処理が固まることがあるため、確認用の変換はローカルへコピーしてから行うのが安全です。
納品前チェックリスト
そのまま使える形にまとめます。
- 全ページの最終要素の下端を測り、本文領域の上限を超えていないか確認する
- 全ページを画像化し、崩れ・潰れ・フォント置換がないか見る
- PDFからテキストを抽出し、載っているはずの固有名詞と数値が全件あるか照合する
- ヘッダーの対象月・宛名が、対象と一致しているか確認する
- 資料内にログイン情報やURLを記載した場合は、実際にアクセスして通ることを確かめる
5番目を補足します。納品資料にログイン情報を載せる場面はよくありますが、その情報が間違っていると、受け取った相手は最初の1手で詰まります。 検証にかかるコストはほぼゼロなのに、失われる信用は大きい部分です。ログインページに実際にアクセスして通ることを確認してから資料に載せてください。ただし、ログイン試行回数を制限するセキュリティ設定が入っている環境では、確認は1回で済ませる必要があります。
まとめ
HTMLで帳票を組んでPDF化する運用は、量産と品質の両立という点で非常に有効です。ただし、ページの溢れが無言で内容を削るという性質を持っています。
- PDFの検品は目視ではなく数値で行う。 各ページの最終要素の下端と、本文領域の上限を比較する
- 測れるテンプレートにしておく。 フッターを下端に張り付ける指定は、溢れの判定を不能にする
- 直す順番は、画像を切り詰める→ページを分ける→余白を詰める。 余白から手をつけない
- 大量生成では検品も自動化する。 数値チェック・全ページ画像化・テキスト照合・対象の一致確認の4点
- エラーが出ないことは、正しく出来ていることの証明にはならない
定例で出す資料ほど、一度作った生成の仕組みは長く使われます。最初に検品を組み込んでおけば、以後は毎月その恩恵を受け続けられます。