Emoji у PDF раніше виглядали як декоративна дрібниця. Тепер це не так.

У документах для клієнтів emoji часто несуть реальну інформацію:

Чек може використовувати ✅ для оплачено, 🎁 для бонусу, ⭐ для оцінки або 🔥 для обмеженої пропозиції.
Повідомлення про доставку може використовувати 📦, 🚚 і 🙏 як швидкі сигнали статусу.
Запис customer support може містити повідомлення WhatsApp, LINE, KakaoTalk або WeChat, де emoji є частиною доказу.
Сертифікат, купон, квиток або loyalty card можуть використовувати 🏆, 🎓, 🎉 або 💯 як частину дизайну.

Якщо ці emoji зникають, стають порожніми квадратами або збільшують PDF на сотні KB, документ уже не відображає початковий зміст точно. У системах з великим обсягом це стає проблемою продукту, storage, bandwidth, email delivery, архівування і іноді compliance.

“Підтримка emoji” не є одним checkbox. PDF generator може покладатися на fonts браузера або OS, вимагати від клієнта налаштування emoji font, конвертувати emoji в image/vector artwork або embed дані color font. Усі шляхи можуть працювати, але tradeoff різний.

Практична проблема: підтримка проти розміру

Кольорові emoji складні для PDF, бо це не звичайні чорно-білі glyphs. PDF Association добре пояснює проблему: OpenType color fonts мають кілька конкуруючих форматів, але ці формати не є native для PDF так само просто, як традиційні outline fonts.

Тому renderer має вибрати представлення:

використовувати color fonts браузера або OS;
embed або subset дані emoji font;
перетворити emoji на image або vector artwork;
або fallback до monochrome glyphs, missing-glyph boxes чи plain text.

Для одного-двох emoji різниця може бути малою. У receipt, coupon, chat export або support archive з багатьма emoji вона швидко стає помітною.

Малий benchmark: 50 поширених emoji

20 травня 2026 року ми виконали локальний smoke test з тією самою A4-сторінкою:

одна версія тільки з plain text;
одна версія з 50 поширеними emoji у body;
Chrome 148 headless print-to-PDF;
gPdf local generation з тим самим 50 emoji set.

Це не universal benchmark для кожного document або кожної engine version. Це простий тест, який показує file-size behavior, коли є багато різних color 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 output embed AppleColorEmoji Type 3 subsets. Це валідний спосіб зробити emoji видимими, але impact на file size у цій пробі очевидний.

gPdf output не embed повний color emoji font. Версія з emoji більша за plain text, як і має бути: color artwork треба десь представити. Різниця в тому, що output росте з emoji artwork, реально використаним у документі, а не з широким browser/OS font path.

Закупівельне питання не “чи видно один smiley на моєму laptop?”, а:

Що відбувається, коли документ містить десятки різних emoji, а PDF генерується у реальних production systems?

Як інші PDF generators працюють з emoji

Чесне порівняння не означає “інші не можуть”. Багато зрілих PDF tools підтримують color emoji. Важливо, як саме вони це роблять і що це означає для setup, determinism та output size.

Puppeteer, Chrome і Chromium-based APIs

Puppeteer використовує PDF output path Chrome. Документація описує page.pdf() як генерацію PDF сторінки з print media type, а guide зазначає, що за замовчуванням він чекає завантаження fonts. Це корисно, якщо source of truth уже web page.

Для structured documents з багатьма emoji tradeoff полягає у залежності output від browser/font environment. У нашій локальній пробі Chrome правильно показав emoji, але file виріс з 31 KB до 436 KB.

Це не означає, що Puppeteer неправильний. Це передусім browser automation tool. Для capture існуючої web page він підходить. Для compact, repeatable receipts, labels, tickets, statements або support records browser path може бути важким.

DocRaptor і Prince

DocRaptor wrap Prince, а Prince є сильним HTML-to-PDF engine. Він особливо підходить, коли input справді HTML/CSS і документ потребує складних paged-media features.

Оголошення DocRaptor Pipeline 9 / Prince 14 явно перелічує color emoji support. Prince 14 release notes також перелічують SVG-in-OpenType, CBLC/CBDT color emoji fonts, Apple sbix і emoji tag sequences. Тож правильний claim не “DocRaptor не render emoji”.

Точніша межа така: DocRaptor/Prince це high-quality HTML-to-PDF path; gPdf це structured JSON-to-PDF path. Для emoji-heavy structured documents, коли input уже є data, gPdf не проштовхує задачу через general HTML/CSS renderer.

PDFreactor

PDFreactor також підтримує color emoji. Manual каже, що color emojis використовуються за замовчуванням і підтримуються CBDT, SBIX та OpenType-SVG.

Той самий manual вказує обмеження: larger PDF size при OpenType-SVG і no selection/copying у цьому color-font path. Це саме той tradeoff, який команда має розуміти до того, як сприймати “emoji support” як yes/no feature.

iText і pdfHTML

iText може генерувати emoji, коли документ має font program, здатний намалювати ці characters. Official pdfHTML emoji guide показує очікуваний pattern: додати emoji-capable font до FontProvider, а потім виконати conversion.

Це потужно для команд, які хочуть SDK-level control. Але font setup, testing, deployment і long-term maintenance залишаються відповідальністю application team.

Чому coverage важливий

Легко протестувати не те. Якщо renderer показує 😂, це не означає, що він обробить emoji, які реально надсилають користувачі.

Реальне використання включає:

variation selectors;
skin-tone modifiers;
zero-width-joiner sequences;
country flags і tag sequences;
emoji, змішані з CJK, Arabic, Latin та іншими scripts;
старі PDF viewers і enterprise document pipelines.

У customer documents consistency є частиною product. Support transcript не має показувати різні emoji залежно від server. Receipt не має показувати status mark на macOS і box у Linux container. Marketplace не має вимагати, щоб кожен merchant встановлював той самий emoji font stack.

Позиція gPdf проста: color emoji мають працювати в generated PDFs без вимоги до customer install emoji fonts, tune browser runtime або accept large output files як default.

Де emoji найважливіші

Emoji-heavy PDFs не обмежуються consumer marketing. Вони з’являються і в операційних системах.

Document type	Чому emoji важливі
Receipts and vouchers	Status, reward, rating і promotion є частиною customer experience.
Delivery and booking confirmations	confirmed, packed, shipped, delivered легше швидко прочитати.
Customer-support records	Chat export втрачає tone і evidence, якщо emoji видалені.
Community and social archives	Emoji є частиною розмови.
Certificates and achievement badges	Trophy, graduation і celebration symbols можуть бути частиною design.
Multilingual customer PDFs	Emoji можуть переносити status cue між мовами.

Тому file size важливий. Одноразові +400 KB здаються малими. При 100,000 receipts на місяць це storage, bandwidth, email deliverability, mobile download time і archive cost. На scale chat export ефект ще більший.

Де підходить gPdf

gPdf не намагається бути повним browser або replacement для кожного HTML-to-PDF engine. Якщо source document це довільна web page, складний editorial layout або dashboard з JavaScript charts, використовуйте browser або зрілий HTML-to-PDF engine.

gPdf створений для іншого випадку:

input уже structured data;
output має бути predictable;
system працює high volume;
PDF має залишатися compact;
той самий payload має давати consistent output між environments;
emoji, CJK, barcodes, PDF/A і metadata є product requirements.

Для цього workload emoji support має бути непомітним. Ви маєте додавати status, sentiment і customer-language cues у документ без перетворення PDF generation на проект встановлення fonts.

Що питати у PDF vendor

Оцінюючи emoji support, просіть більше ніж screenshot:

Чи можете generate PDF з 50 distinct common emoji?
Який file size з цими emoji і без них?
Чи output залежить від operating-system fonts?
Чи customer має install/register emoji font?
Що відбувається з ZWJ sequences, flags і variation selectors?
Чи output лишається stable після runtime upgrades?
Emoji behavior documented, чи це side effect host environment?

Відповіді покажуть, чи emoji support є real product capability, чи випадковим результатом runtime.

Кольорові emoji у PDF: підтримка, розмір файлу і практична цінність