Abra qualquer PDF crítico para o negócio — uma fatura, uma etiqueta de envio, um extrato mensal — e olhe as propriedades do documento (Cmd+D no Preview do macOS, Ctrl+D no Adobe Reader, “Arquivo → Propriedades” na maioria dos visualizadores de desktop). Em seguida, observe o campo Producer.

Se o PDF foi gerado por uma plataforma SaaS usando um navegador headless, você verá com frequência algo como:

$ pdfinfo invoice.pdf
Title:           invoice-20260318.pdf
Subject:
Author:
Creator:         Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (...) Chrome/120.0.0.0
Producer:        Skia/PDF m120
Language:

A página acima tem a cara do fornecedor SaaS. As propriedades do arquivo nomeiam um motor de navegador que não tem nada a ver com esse fornecedor — nem com o cliente em nome de quem o SaaS está entregando o documento.

É dessa diferença que trata este post.

A página tem marca, o arquivo não

A geração de PDF white-label é um requisito bem entendido para SaaS B2B. O fornecedor permite que o cliente envie um logo, escolha as cores da marca, configure um template; os PDFs exportados ficam visualmente parecidos com a marca do cliente, não com a do fornecedor.

A maioria das plataformas para por aí. Resolvem a camada visível e deixam a camada de propriedades do arquivo intocada. Resultado: um documento que diz “Acme Logistics” em cada página, mas que se identifica como “Skia/PDF m120” no instante em que alguém clica com o botão direito → Propriedades.

Para um download B2C pontual — um recibo pessoal, um ingresso de cinema — as propriedades do arquivo são em grande parte cosméticas. Para um documento B2B, ou qualquer saída B2C regulada (laudos médicos, demonstrações financeiras, divulgações legais, formulários de seguros regulados), as propriedades do arquivo fazem parte do documento. Elas aparecem em:

Adobe Reader, Preview, Foxit, qualquer visualizador de PDF de desktop
Sistemas de gestão documental (SharePoint, M-Files, NetSuite Files)
Pré-visualizadores de PDF dos servidores de e-mail
Índices de busca (Spotlight, Outlook, busca interna do DMS)
Sistemas de arquivamento (PDF/A para preservação de longo prazo)
Qualquer coisa que invoca pdfinfo ou pdftk dump_data em um pipeline

Um documento cuja página diz “Acme” e cujo campo Producer diz “Chromium” é lido por esses sistemas como “renderizado por Chromium para alguém chamado Acme” — e não “renderizado pela Acme”. Para compras corporativas e compliance, essa distinção faz diferença.

Por que isso é pior para o fornecedor SaaS do que para usuários diretos

Se você gera um PDF para si mesmo, “Chromium” no campo Producer é problema só seu.

Se você é um fornecedor SaaS e seus clientes geram PDFs pela sua plataforma, a cadeia é mais longa:

Você escolheu o stack de renderização.
Seu cliente entrega o PDF resultante ao cliente dele.
O destinatário final — um time de compras, uma transportadora, uma repartição fiscal, um departamento financeiro — vê um campo Producer que não nomeia nem você nem o seu cliente. Ele nomeia o renderizador upstream que você usa.

A marca do seu cliente na página; um nome de ferramenta desconhecido no arquivo. Da perspectiva do destinatário, o documento parece levemente fora do esperado, sem que ele saiba dizer o porquê. Da perspectiva do seu cliente, a promessa de white-label não foi cumprida por inteiro.

Essa é a parte em que a maioria das plataformas investe pouco, porque a correção não aparece na página inicial. Mas o cliente que rodar um único pdfinfo na saída do seu recurso “PDF white-label” vai notar.

Quando isso realmente incomoda

Estas são situações em que o campo Producer apareceu como um problema operacional real, não hipotético:

Questionários de segurança de fornecedores. Compras corporativas realizam uma revisão de risco de fornecedor e perguntam: “liste todas as ferramentas de terceiros que aparecem nos documentos que vocês nos enviam”. O time de TI do cliente roda pdfinfo em um documento de amostra e encontra um nome de renderizador desconhecido. Ninguém fica bravo — mas isso entra na lista de sub-processadores, que então dispara revisão de gestão de fornecedores e um conjunto separado de controles de compliance.
Busca em DMS / arquivo. O sistema de gestão documental do cliente indexa PDFs por author. Quando os PDFs da sua plataforma têm o campo Author vazio, o time de compliance do cliente não consegue filtrar facilmente “documentos deste fornecedor” meses depois — acaba adicionando tags manuais, o que não deveria precisar.
Validação de arquivo de longo prazo. Um sistema de arquivamento PDF/A sinaliza documentos cujo Producer não bate com a lista esperada de fornecedores. O time de compliance precisa autorizar manualmente “Skia/PDF m120” e “wkhtmltopdf” como renderizadores conhecidos — um peso operacional pequeno, mas contínuo.
Auditorias de consistência de marca. Alguns times de marketing corporativo auditam a atribuição de documentos enviados como parte da governança de marca. Um documento atribuído a uma ferramenta que o time de marca nunca ouviu falar vira uma observação.

Nenhum desses é um incidente crítico. São arranhões que adicionam fricção à venda corporativa, ao onboarding de fornecedores e à operação. Eles se acumulam ao longo de milhares de documentos por mês.

O que as propriedades do arquivo realmente expõem

A especificação PDF reserva seis campos padrão de metadados que praticamente todo visualizador exibe:

Campo	Para que serve	O que um stack que vaza costuma mostrar
`Title`	Título do documento	Nome de arquivo autogerado, ou vazio
`Author`	A pessoa ou organização que criou o documento	Vazio, ou o nome do desenvolvedor
`Subject`	Descrição curta do documento	Vazio
`Creator`	A aplicação que produziu o conteúdo de origem	“Chromium”, “Mozilla/5.0…” ou o nome interno da ferramenta do fornecedor SaaS
`Producer`	A aplicação que produziu os bytes do PDF	“Skia/PDF m120”, “wkhtmltopdf 0.12.x”, “iText 7.x.x”
`Language`	Tag de idioma BCP-47	Vazio, ou locale errado

Cada um deles é uma string curta. Nenhum é tecnicamente difícil de preencher. A razão pela qual eles vazam por padrão é que a biblioteca de renderização escreve o próprio nome em Producer (corretamente — é para isso que o campo serve), e a maioria do código de aplicação nunca define os outros cinco.

A solução é defini-los — deliberadamente, em cada render, a partir da aplicação que sabe para que o documento serve.

Como ficam os “metadados com marca” na prática

Aqui está o mesmo bloco de metadados como o gPdf o produz. Seis campos, todos sobrescrevíveis pelo chamador:

{
  "settings": {
    "metadata": {
      "title":    "Invoice INV-2026-3401",
      "language": "en",
      "author":   "Acme Logistics, Inc.",
      "subject":  "Monthly invoice — 2026-03",
      "creator":  "Acme Billing Platform v7.2",
      "producer": "Acme Billing Platform"
    }
  }
}

O mesmo pdfinfo contra o PDF resultante:

$ pdfinfo invoice.pdf
Title:           Invoice INV-2026-3401
Subject:         Monthly invoice — 2026-03
Author:          Acme Logistics, Inc.
Creator:         Acme Billing Platform v7.2
Producer:        Acme Billing Platform
Language:        en

A página é renderizada como “Acme Logistics” — e as propriedades do arquivo também dizem “Acme Logistics”. Clique com o botão direito → Propriedades mostra um documento que pertence inteiramente à Acme. O fato de os bytes terem sido produzidos pelo gPdf na borda em ~4 ms não aparece em lugar nenhum onde o destinatário olhe.

Os clientes não vão querer saber que você usa o gPdf?

Essa pergunta surge com frequência suficiente para merecer uma resposta direta.

Sim — seus clientes podem perfeitamente saber que você usa o gPdf. Isso é entre você e eles, e normalmente vai no seu blog de engenharia, no seu changelog, nos seus documentos de arquitetura de segurança ou na sua lista de sub-processadores (onde o gPdf aparece se for relevante para o seu DPA).

O campo Producer não trata dessa relação. Ele trata do destinatário final do documento do seu cliente — um auxiliar de compras, um despachante de transportadora, um analista da receita — que não tem nenhuma relação com a sua escolha de renderizador e nenhum motivo para se importar com qual é. Para essa pessoa, “Skia/PDF m120” na caixa de Propriedades é ruído; “Acme Billing Platform” é sinal.

Também não há nada de desonesto nisso. A especificação PDF define Producer como “o nome da aplicação que produziu o PDF original”. Se você constrói um serviço de PDF em cima do gPdf, a sua aplicação produziu os bytes que o gPdf entregou. Dizer isso em Producer é correto. A versão honesta é:

gPdf é a infraestrutura de renderização.
A sua plataforma é o produtor.
O seu cliente é o autor.

Cada camada recebe o crédito que a especificação PDF pretende.

Uma nota de rodapé sobre pipelines downstream

Se o seu PDF de saída passa por alguma etapa de pós-processamento antes de chegar ao destinatário — Ghostscript sem flags explícitas de preservação de metadados, uma ferramenta corporativa de DRM/marca-d’água, um “otimizador de PDF” — algumas dessas ferramentas vão reescrever silenciosamente o Producer com o próprio nome e desfazer os metadados com marca que você acabou de definir. Teste contra o seu pipeline real, não apenas contra a resposta crua do gPdf.

Uma nota sobre o que não está aqui

Para sermos precisos: os seis campos padrão acima são o que o gPdf expõe hoje. Isso basta para fazer white-label das propriedades do documento — que é do que trata a história de identidade de marca.

Não basta para guardar contexto de negócio arbitrário (UUID de pedido, código de depósito, versão de template) dentro do PDF para sistemas downstream lerem. Essa é uma capacidade separada e complementar — metadados XMP customizados + pares chave-valor arbitrários — que a especificação PDF suporta e que estamos acompanhando como item de roadmap. Se você precisa disso hoje, dados do tipo identificador costumam viver de forma mais confiável no banco de dados da sua própria plataforma, indexados pelo nome do arquivo PDF ou por um hash, do que dentro do próprio PDF. Metadados são para a identidade do documento, não para transportar dados de negócio estruturados através de PDFs como camada de transporte.

Metadados com marca (hoje) ≠ fluxo de dados de negócio oculto (separado). Vale a pena mantê-los separados no seu próprio planejamento.

A menor melhoria possível

Se você já faz POST em /api/v1/pdf/render e a sua chamada atual não tem settings.metadata, a menor melhoria são três linhas adicionadas ao JSON que você já envia:

 {
   "pages": [...],
   "settings": {
+    "metadata": {
+      "author":   "Your customer's organisation",
+      "producer": "Your platform"
+    }
   }
 }

Dois campos, uma nova chave. Verificável com pdfinfo em segundos. Depois que isso entrar, preencha title, language, subject e creator quando tiver tempo.

Onde isso aparece na API do gPdf

Seis linhas dentro de settings.metadata. Políticas por token também podem remover ou definir valores padrão para esses campos, de forma que um SaaS multi-tenant possa exigir que todo PDF gerado pelos seus clientes seja corretamente atribuído sem precisar confiar que todo chamador de API vá defini-los.

§4.14.2 Metadata na referência da API — a referência campo a campo.
Mergulho campo a campo — quando cada um de title / language / author / subject / creator / producer importa, o que os leitores realmente fazem com eles e como verificar o que você entregou.

A página visível é metade da marca. As propriedades do arquivo são a outra metade. Se a sua plataforma entrega PDFs em nome dos clientes, as duas metades deveriam levar o nome deles.