PDF の emoji は、以前なら飾りの問題に見えました。今は違います。

顧客向けドキュメントでは、emoji が実際の意味を持つことがよくあります。

領収書では ✅ が支払い済み、🎁 が特典、⭐ が評価、🔥 が期間限定オファーを示すことがあります。
配送通知では 📦、🚚、🙏 が状態をすばやく伝えます。
サポート履歴には WhatsApp、LINE、KakaoTalk、WeChat のメッセージが含まれ、emoji が証跡の一部になることがあります。
証明書、クーポン、チケット、会員カードでは 🏆、🎓、🎉、💯 がデザイン要素そのものになることがあります。

これらが消えたり、豆腐文字になったり、PDF を数百 KB も大きくしたりすると、ドキュメントは元の内容を正しく表現できません。大量生成するシステムでは、これは見た目だけでなく、プロダクト、ストレージ、配信、アーカイブ、場合によってはコンプライアンスの問題です。

“emoji 対応” は単純なチェック項目ではありません。PDF 生成器はブラウザや OS のフォントに頼ることも、呼び出し側に emoji フォント設定を求めることも、emoji を画像やベクターに変換することも、カラーフォントデータを埋め込むこともできます。どれも動く可能性はありますが、トレードオフは異なります。

実務上の課題：対応とサイズ

カラー emoji が PDF で難しいのは、通常の白黒グリフではないからです。PDF Association はこの問題をうまく整理しています。OpenType のカラーフォントには複数の競合フォーマットがありますが、それらは従来のアウトラインフォントのように PDF へ自然に入るものではありません。

そのため、レンダラーは表現方法を選びます。

ブラウザや OS のカラーフォントを使う;
カラー emoji フォントを埋め込む、または subset する;
emoji を画像またはベクター artwork に変換する;
あるいはモノクログリフ、欠落グリフ、プレーンテキストへ fallback する。

emoji が 1、2 個なら差は小さいかもしれません。emoji が多い領収書、クーポン、チャットエクスポート、サポートアーカイブでは、差はすぐに大きくなります。

小さな benchmark：50 個の一般的な emoji

2026 年 5 月 20 日、同じ 1 ページ A4 サンプルでローカル smoke test を行いました。

通常テキストだけの版;
本文に 50 個の一般的な emoji を含む版;
Chrome 148 headless print-to-PDF;
同じ 50 emoji set を使った gPdf local generation。

これはすべての文書やすべてのエンジン version に対する universal benchmark ではありません。多数の異なるカラー emoji がある場合にファイルサイズがどう動くかを見るための小さなテストです。

Renderer	Plain PDF	Same page with 50 emoji	Increase	Ratio
Chrome 148 print-to-PDF	31,250 bytes	435,630 bytes	+404,380 bytes	13.94x
gPdf local generation	8,766 bytes	43,466 bytes	+34,700 bytes	4.96x

Chrome の出力には AppleColorEmoji Type 3 subset が埋め込まれていました。emoji を表示する有効な方法ですが、このサンプルではサイズ増加が明確です。

gPdf の出力は完全なカラー emoji フォントを埋め込んでいません。emoji 版がテキスト版より大きいのは当然です。カラー artwork はどこかに入れる必要があります。違いは、出力が文書内で実際に使った emoji artwork に応じて増え、広いブラウザ/OS フォント経路には依存しない点です。

調達時に問うべきなのは「自分のノート PC で笑顔が 1 つ表示されるか」ではありません。

本番の生成環境で、文書に数十種類の emoji が入ったとき何が起きるか？

他の PDF 生成器の emoji 対応

正直な比較は「他社は全部できない」ではありません。成熟した PDF ツールの多くはカラー emoji に対応しています。重要なのは、どう対応し、それが設定、再現性、出力サイズに何を意味するかです。

Puppeteer、Chrome、Chromium 系 API

Puppeteer は Chrome の PDF 出力経路を使います。公式ドキュメントは page.pdf() を print CSS media type でページの PDF を生成する API と説明し、guide ではデフォルトでフォントの読み込みを待つとされています。元の情報源が Web ページなら便利です。

emoji の多い構造化ドキュメントでは、出力がブラウザとフォント環境に依存することがトレードオフになります。今回のローカルサンプルでは Chrome は正しく emoji を表示しましたが、ファイルは 31 KB から 436 KB に増えました。

これは Puppeteer が間違いという意味ではありません。Puppeteer はまずブラウザ自動化ツールです。既存 Web ページをキャプチャするなら適しています。コンパクトで再現性のある領収書、ラベル、チケット、明細、サポート記録を生成する用途では、ブラウザ経路は重くなることがあります。

DocRaptor と Prince

DocRaptor は Prince をラップしています。Prince は強力な HTML-to-PDF エンジンです。入力が本当に HTML/CSS で、複雑な paged media 機能が必要なら非常に良い選択です。

DocRaptor の Pipeline 9 / Prince 14 の告知には、カラー emoji 対応が明記されています。Prince 14 release notes も SVG-in-OpenType、CBLC/CBDT color emoji fonts、Apple sbix、emoji tag sequences を挙げています。したがって「DocRaptor は emoji を描画できない」という主張は正しくありません。

より正確な境界はこうです。DocRaptor/Prince は高品質な HTML-to-PDF 経路です。gPdf は structured JSON-to-PDF 経路です。入力がすでにデータで、emoji の多い構造化文書を作る場合、gPdf は問題を汎用 HTML/CSS レンダラーへ押し込まずに済ませます。

PDFreactor

PDFreactor もカラー emoji をサポートしています。manual ではカラー emoji がデフォルトで使われ、CBDT、SBIX、OpenType-SVG などのカラーフォント形式をサポートすると説明されています。

同じ manual は制限も示しています。OpenType-SVG を使うと PDF サイズが大きくなり、その color-font path では選択やコピーができません。“emoji 対応” を yes/no として扱う前に、この種のトレードオフを理解する必要があります。

iText と pdfHTML

iText は、該当文字を描画できるフォントプログラムがある場合に emoji を生成できます。公式の pdfHTML emoji guide は、emoji-capable font を FontProvider に追加してから変換する流れを示しています。

SDK レベルの制御が必要なチームには強力です。一方で、フォント設定、テスト、デプロイ、長期保守はアプリケーション側の責任になります。

なぜ coverage が重要か

間違ったテストは簡単です。😂 が表示できても、実ユーザーが送る emoji を扱えるとは限りません。

実際には次のようなものが出てきます。

variation selectors;
skin-tone modifiers;
zero-width-joiner sequences;
国旗や tag sequences;
CJK、Arabic、Latin などとの混在;
古い PDF ビューアや企業内 document pipelines。

顧客文書では、一貫性はプロダクトの一部です。サポート履歴がサーバーによって異なる emoji を表示してはいけません。領収書が macOS では status mark、Linux container では box になってはいけません。marketplace が各 merchant に同じ emoji font stack を入れさせるべきでもありません。

gPdf の立場は単純です。生成 PDF でカラー emoji は安定して動くべきであり、顧客に emoji フォントのインストール、ブラウザ runtime の調整、大きな出力ファイルの受け入れを求めるべきではありません。

emoji が特に重要な文書

emoji-heavy PDF は consumer marketing だけではありません。運用システムにも出てきます。

文書タイプ	なぜ重要か
領収書とクーポン	ステータス、特典、評価、プロモーションは顧客体験の一部です。
配送・予約確認	confirmed、packed、shipped、delivered の状態が読み取りやすくなります。
サポート記録	emoji を消すとチャット履歴のニュアンスと証跡が失われます。
コミュニティやソーシャルアーカイブ	emoji は会話の一部です。
証明書や achievement badges	トロフィー、卒業、祝福の記号がデザインの一部になります。
多言語顧客 PDF	emoji は言語をまたいで状態を伝えます。

だからファイルサイズが重要です。1 回の 400 KB 増加は小さく見えます。月 100,000 件の領収書なら、ストレージ、帯域、メール到達率、モバイルダウンロード時間、アーカイブコストになります。チャットエクスポート規模ではさらに大きくなります。

gPdf が合う領域

gPdf は完全なブラウザを目指していませんし、すべての HTML-to-PDF エンジンの代替でもありません。source document が任意の Web ページ、複雑な editorial layout、JavaScript chart を含む dashboard なら、ブラウザか成熟した HTML-to-PDF engine を使うべきです。

gPdf は次のケース向けです。

入力がすでに structured data;
出力が predictable である必要がある;
システムが high volume で動く;
PDF を compact に保ちたい;
同じ payload が環境をまたいで安定した結果を出すべき;
emoji、CJK、barcodes、PDF/A、metadata が product requirements。

この workload では emoji support は退屈であるべきです。状態、感情、顧客言語の cue を文書に入れるために、PDF generation をフォントインストールプロジェクトにする必要はありません。

PDF ベンダーに聞くべきこと

emoji support を評価するときは、スクリーンショット以上を求めます。

50 種類の common emoji を含む PDF を生成できますか？
emoji あり/なしでファイルサイズはどう変わりますか？
output は operating-system fonts に依存しますか？
customer が emoji font を install/register する必要がありますか？
ZWJ sequences、flags、variation selectors はどうなりますか？
runtime upgrade 後も output は stable ですか？
emoji behavior は documented ですか、それとも host environment の副作用ですか？

答えによって、emoji support が本物の product capability なのか、runtime の偶然の結果なのかが分かります。

PDF のカラー emoji：対応状況、ファイルサイズ、実務上の価値