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

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

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

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

“Підтримка emoji” не зводиться до одного checkbox. Генератор PDF може покладатися на шрифти браузера або ОС, вимагати від клієнта налаштування emoji-шрифту, конвертувати emoji в зображення чи векторну графіку або вбудовувати дані кольорового шрифту. Усі шляхи можуть працювати, але tradeoff різний.

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

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

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

використовувати кольорові шрифти браузера або ОС;
вбудовувати або subset-ити дані emoji-шрифту;
перетворити emoji на зображення або векторну графіку;
або 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-ить повний кольоровий emoji-шрифт. Версія з emoji більша за plain text, як і має бути: кольорову графіку треба десь представити. Різниця в тому, що output росте з emoji-графікою, реально використаною в документі, а не з широким browser/OS font path.

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

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

Як інші генератори PDF працюють з 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 уже вебсторінка.

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

Це не означає, що Puppeteer неправильний. Це передусім browser automation tool. Для capture наявної вебсторінки він підходить. Для 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 явно перелічує підтримку кольорових emoji. 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 це структурований 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” як 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-шрифт stack.

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

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

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

Document type	Чому emoji важливі
Receipts and vouchers	Status, reward, rating і promotion є частиною клієнтського досвіду.
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 не намагається бути повним браузером або заміною для кожного HTML-to-PDF engine. Якщо джерельний документ — це довільна вебсторінка, складний редакційний макет або dashboard з JavaScript-графіками, використовуйте browser або зрілий HTML-to-PDF engine.

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

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

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

Що питати у постачальника PDF

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

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

Відповіді покажуть, чи підтримка emoji є реальною продуктовою можливістю, чи випадковим результатом runtime.

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