Emoji em PDF já foi tratado como detalhe visual. Hoje não é.

Em documentos enviados ao cliente, emoji muitas vezes carrega informação:

Um recibo pode usar ✅ para pago, 🎁 para recompensa, ⭐ para avaliação ou 🔥 para promoção limitada.
Um aviso de entrega pode usar 📦, 🚚 e 🙏 como sinais rápidos de status.
Um registro de suporte pode conter mensagens de WhatsApp, LINE, KakaoTalk ou WeChat em que o emoji faz parte da evidência.
Certificados, cupons, ingressos e cartões de fidelidade podem usar 🏆, 🎓, 🎉 ou 💯 como parte da identidade visual.

Se esses emoji somem, viram quadrados vazios ou aumentam o PDF em centenas de KB, o documento deixa de representar o conteúdo original com fidelidade. Em sistemas de alto volume, isso vira problema de produto, armazenamento, envio, arquivamento e, às vezes, compliance.

O ponto difícil é que “suporta emoji” não é uma única opção. Um gerador de PDF pode depender das fontes do navegador ou do sistema operacional, exigir que o cliente configure uma fonte emoji, transformar emoji em imagens/vetores ou incorporar dados de fontes coloridas. Todos esses caminhos podem funcionar, mas os custos são diferentes.

O problema prático: suporte versus tamanho

Emoji colorido é difícil em PDF porque não é um glifo comum em preto e branco. A PDF Association resume bem: existem vários formatos concorrentes de fontes OpenType coloridas, mas esses formatos não são nativos de PDF da mesma forma simples que fontes vetoriais tradicionais.

Por isso, o mecanismo precisa escolher uma representação:

usar fontes coloridas do navegador ou do sistema operacional;
incorporar ou subconfigurar dados de uma fonte emoji;
converter emoji em imagem ou arte vetorial;
ou cair para glifos monocromáticos, caixas de caractere ausente ou texto simples.

Com um ou dois emoji, a diferença pode passar despercebida. Em recibos, cupons, exportações de chat ou arquivos de suporte com muitos emoji, ela aparece rápido.

Um teste pequeno: 50 emoji comuns

Em 20 de maio de 2026, rodamos um smoke test local com a mesma página A4:

uma versão só com texto;
outra com 50 emoji comuns no corpo;
Chrome 148 headless print-to-PDF;
geração local no gPdf com o mesmo conjunto de 50 emoji.

Não é um benchmark universal para todos os documentos ou versões de motor. É uma forma simples de expor o comportamento de tamanho quando muitos emoji coloridos diferentes aparecem.

Gerador	PDF sem emoji	Mesma página com 50 emoji	Aumento	Razão
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

O Chrome incorporou subconjuntos AppleColorEmoji Type 3. É uma forma válida de tornar os emoji visíveis, mas o impacto no tamanho fica claro nessa amostra.

O gPdf não incorporou uma fonte completa de emoji colorido. A versão com emoji é maior que a de texto puro, como deveria ser: arte colorida precisa estar representada no arquivo. A diferença é que o crescimento acompanha os emoji usados no documento, não uma rota ampla baseada no navegador ou no sistema operacional.

A pergunta de compra não é “um sorriso aparece no meu notebook?”, e sim:

O que acontece quando o documento contém dezenas de emoji distintos e é gerado nos sistemas reais de produção?

Como outros geradores de PDF lidam com emoji

A comparação honesta não é “os outros não conseguem”. Várias ferramentas maduras suportam emoji colorido. O que importa é como suportam, e o que isso significa para configuração, determinismo e tamanho de saída.

Puppeteer, Chrome e APIs baseadas em Chromium

Puppeteer usa o caminho de PDF do Chrome. A documentação descreve page.pdf() como geração de um PDF da página com o media type print, e o guia informa que, por padrão, ele espera as fontes carregarem. Isso é útil quando a fonte da verdade já é uma página web.

Para documentos estruturados com muitos emoji, o custo é depender do ambiente de navegador e fontes. Na nossa amostra local, o Chrome renderizou os emoji corretamente, mas o arquivo foi de 31 KB para 436 KB.

Isso não torna o Puppeteer errado. Ele é, antes de tudo, uma ferramenta de automação de navegador. Para capturar uma página existente, faz sentido. Para recibos, etiquetas, tickets, demonstrativos ou registros de suporte compactos e repetíveis, o caminho do navegador pode ser pesado.

DocRaptor e Prince

DocRaptor empacota Prince, e Prince é um motor HTML-to-PDF forte. Ele é excelente quando a entrada é realmente HTML/CSS e o documento precisa de recursos avançados de paged media.

O anúncio do Pipeline 9 / Prince 14 da DocRaptor lista explicitamente suporte a emoji colorido. As notas do Prince 14 também mencionam SVG-in-OpenType, fontes CBLC/CBDT, Apple sbix e emoji tag sequences. Portanto, a afirmação correta não é “DocRaptor não renderiza emoji”.

A fronteira útil é mais estreita: DocRaptor/Prince é um caminho HTML-to-PDF de alta qualidade; gPdf é um caminho JSON-to-PDF estruturado. Para documentos estruturados com muitos emoji, quando a entrada já existe como dados, o gPdf evita empurrar o problema para um renderizador HTML/CSS geral.

PDFreactor

PDFreactor também suporta emoji colorido. O manual diz que emoji coloridos são usados por padrão e que formatos como CBDT, SBIX e OpenType-SVG são suportados.

O mesmo manual registra limitações: tamanho maior do PDF ao usar OpenType-SVG e ausência de seleção ou cópia nesse caminho. Esse é exatamente o tipo de tradeoff que uma equipe deve entender antes de tratar “suporte a emoji” como sim ou não.

iText e pdfHTML

iText pode gerar emoji quando o documento tem uma fonte capaz de desenhar esses caracteres. O guia oficial de pdfHTML mostra o padrão: adicionar uma fonte com emoji ao FontProvider e executar a conversão.

Isso é poderoso para quem quer controle em nível de SDK. Também significa que configuração de fontes, testes, deploy e manutenção ficam com a equipe da aplicação.

Por que a cobertura importa

É fácil testar a coisa errada. Se um motor mostra 😂, isso não significa que ele lida com os emoji que os usuários realmente enviam.

O uso real inclui:

variation selectors;
modificadores de tom de pele;
sequências com zero-width joiner;
bandeiras e tag sequences;
emoji misturados com CJK, árabe, latim e outras escritas;
leitores PDF antigos e pipelines documentais corporativos.

Em documentos de cliente, consistência faz parte do produto. Um histórico de suporte não deveria mostrar emoji diferentes conforme o servidor. Um recibo não deveria exibir um status no macOS e uma caixa em um contêiner Linux. Um marketplace não deveria exigir que cada lojista instale a mesma pilha de fontes emoji.

A posição do gPdf é simples: emoji colorido deve funcionar em PDFs gerados sem pedir ao cliente que instale fontes, ajuste um navegador ou aceite arquivos grandes como padrão.

Onde emoji mais importa

PDFs com muitos emoji não aparecem só em marketing de consumo. Eles também estão em sistemas operacionais.

Tipo de documento	Por que importa
Recibos e cupons	Status, recompensa, avaliação e promoção fazem parte da experiência.
Confirmações de entrega e reserva	Estados como confirmado, separado, enviado e entregue ficam fáceis de ler.
Registros de suporte	Exportações de chat perdem tom e evidência se emoji são removidos.
Arquivos sociais e comunitários	Emoji faz parte da conversa.
Certificados e badges	Troféus, formaturas e celebrações podem fazer parte do design.
PDFs multilíngues	Emoji pode comunicar status atravessando idiomas.

Por isso o tamanho importa. Um aumento de 400 KB uma vez parece pequeno. Com 100,000 recibos por mês, vira armazenamento, banda, entregabilidade de email, tempo de download no celular e custo de arquivo. Em exportações de chat, o impacto cresce ainda mais.

Onde o gPdf se encaixa

gPdf não tenta ser um navegador completo nem substituir todos os motores HTML-to-PDF. Se o documento-fonte é uma página web arbitrária, uma diagramação editorial complexa ou um dashboard com gráficos JavaScript, use um navegador ou um motor HTML-to-PDF maduro.

gPdf foi feito para outro caso:

a entrada já é dado estruturado;
a saída precisa ser previsível;
o sistema gera alto volume;
o PDF deve ficar compacto;
o mesmo payload deve gerar o mesmo resultado entre ambientes;
emoji, CJK, códigos de barras, PDF/A e metadata são requisitos de produto.

Nesse workload, suporte a emoji deve ser algo sem drama. Você deve conseguir incluir status, sentimento e pistas da linguagem do cliente sem transformar geração de PDF em projeto de instalação de fontes.

O que perguntar a qualquer fornecedor de PDF

Ao avaliar emoji, peça mais que uma captura:

Vocês geram um PDF com 50 emoji comuns distintos?
Qual é o tamanho com e sem esses emoji?
A saída depende de fontes do sistema operacional?
O cliente precisa instalar ou registrar uma fonte emoji?
O que acontece com ZWJ, bandeiras e variation selectors?
A saída continua estável após upgrades de runtime?
O comportamento é documentado ou é só efeito do ambiente?

As respostas mostram se emoji é uma capacidade real do produto ou um efeito acidental do runtime.

Emoji colorido em PDFs: suporte, tamanho do arquivo e valor real