Відкрийте будь-який бізнес-критичний PDF — рахунок, транспортну етикетку, місячну виписку — і подивіться на властивості документа (Cmd+D у macOS Preview, Ctrl+D в Adobe Reader, «Файл → Властивості» у більшості настільних переглядачів). Тепер подивіться на поле Producer.

Якщо PDF згенеровано SaaS-платформою через headless-браузер, ви часто побачите щось на кшталт:

$ 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:

Сторінка вище виглядає у брендингу SaaS-вендора. Властивості файлу називають рушій браузера, який не має жодного відношення ні до вендора, ні до клієнта, від імені якого SaaS відправляє документ.

Саме про цю прогалину цей допис.

Сторінка брендована, файл — ні

White-label генерація PDF — добре зрозуміла вимога для B2B SaaS. Вендор дозволяє клієнту завантажити лого, обрати кольори бренду, налаштувати шаблон; експортовані PDF візуально виглядають як бренд клієнта, а не вендора.

Більшість платформ на цьому зупиняється. Вони вирішують видимий шар і залишають шар властивостей файлу як є. Результат: документ, який на кожній сторінці каже «Acme Logistics», але ідентифікує себе як «Skia/PDF m120», щойно хтось клацне правою кнопкою → Властивості.

Для одноразового B2C-завантаження — особистого чека, квитка в кіно — властивості файлу здебільшого косметичні. Для B2B-документа чи будь-якого регульованого B2C-виходу (медичні висновки, фінансова звітність, юридичні розкриття, регульовані страхові форми) властивості файлу — частина документа. Вони з’являються в:

Adobe Reader, Preview, Foxit, кожному настільному PDF-переглядачі
системах керування документами (SharePoint, M-Files, NetSuite Files)
переглядачах PDF поштових серверів
пошукових індексах (Spotlight, Outlook, внутрішній пошук DMS)
архівних системах (PDF/A довготривале зберігання)
усьому, що викликає pdfinfo чи pdftk dump_data у пайплайні

Документ, на сторінці якого «Acme», а в полі Producer — «Chromium», для цих систем читається як «зрендерено Chromium для когось на ім’я Acme», а не «зрендерено Acme». Для корпоративних закупівель і комплаєнсу ця різниця помітна.

Чому це гірше для SaaS-вендора, ніж для прямих користувачів

Якщо ви генеруєте PDF для себе, «Chromium» у полі Producer — ваша власна проблема.

Якщо ж ви SaaS-вендор і ваші клієнти генерують PDF через вашу платформу, ланцюг довший:

Ви обрали стек рендерингу.
Ваш клієнт відправляє отриманий PDF своєму клієнту.
Кінцевий одержувач — відділ закупівель, перевізник, податкова служба, фінансовий відділ — бачить поле Producer, у якому не названо ні вас, ні вашого клієнта. У ньому названо upstream-рендерер, який ви випадково використовуєте.

Бренд вашого клієнта на сторінці; невідома назва інструмента у файлі. З погляду одержувача документ виглядає трохи дивно, і він не може чітко сформулювати чому. З погляду вашого клієнта — обіцянка white-label виконана не до кінця.

Це та частина, у яку більшість платформ недоінвестує, бо виправлення непомітне з головної сторінки. Але клієнт, який запустить один-єдиний pdfinfo на виході вашої «white-label PDF»-функції, помітить.

Коли це реально кусає

Це ситуації, де поле Producer виявлялося реальною операційною проблемою, а не гіпотетичною:

Анкети безпеки вендорів. Корпоративний відділ закупівель проводить vendor risk review і запитує: «перерахуйте всі сторонні інструменти, що з’являються у вихідних документах, які ви нам відправляєте.» IT-команда клієнта запускає pdfinfo на зразковому документі і знаходить незнайому назву рендерера. Ніхто не злиться — але це додається до списку sub-processor’ів, що далі тригерить vendor-management review і окремий набір комплаєнс-перевірок.
Пошук у DMS / архіві. Система керування документами клієнта індексує PDF за author. Коли в PDF з вашої платформи поле Author порожнє, комплаєнс-команда клієнта не може через місяці легко відфільтрувати «документи від цього вендора» — вони змушені додавати ручні теги, чого робити не мали б.
Валідація довгострокового архіву. Архівна система PDF/A позначає документи, де Producer не збігається з очікуваним списком вендорів. Комплаєнс-команда мусить вручну вносити «Skia/PDF m120» і «wkhtmltopdf» до allow-list як відомі-OK рендерери — невеликий, але постійний операційний тягар.
Аудити консистентності бренду. Деякі корпоративні маркетингові команди аудитують атрибуцію вихідних документів як частину brand-governance. Документ, приписаний інструменту, про який бренд-команда ніколи не чула, стає знахідкою.

Жодне з цього не є критичним інцидентом. Це порізи папером, що додають тертя до корпоративних продажів, онбордингу вендорів та операцій. Вони накопичуються через тисячі документів на місяць.

Що насправді розкривають властивості файлу

Специфікація PDF резервує шість стандартних полів метаданих, які майже кожен переглядач виставляє назовні:

Поле	Для чого воно	Що зазвичай показує діркавий стек
`Title`	Назва документа	Автогенероване ім’я файлу або порожнє
`Author`	Особа або організація, що створила документ	Порожнє або ім’я розробника
`Subject`	Короткий опис документа	Порожнє
`Creator`	Застосунок, що створив вихідний контент	«Chromium», «Mozilla/5.0…» або внутрішня назва інструмента SaaS-вендора
`Producer`	Застосунок, що створив байти PDF	«Skia/PDF m120», «wkhtmltopdf 0.12.x», «iText 7.x.x»
`Language`	BCP-47 мовний тег	Порожнє або неправильна локаль

Кожне з них — один короткий рядок. Жодне з них технічно не складно заповнити. Причина, чому вони протікають за замовчуванням, у тому, що рендерна бібліотека вписує свою назву в Producer (правильно — для цього поле й існує), а більшість коду застосунку ніколи не задає решту п’ять.

Виправлення — задати їх свідомо, на кожному рендері, із застосунку, який знає, для чого цей документ.

Як виглядають «брендовані метадані» на практиці

Ось той самий блок метаданих, як його видає gPdf. Шість полів, усі можна перевизначити викликачем:

{
  "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"
    }
  }
}

Той самий pdfinfo на отриманому PDF:

$ 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

Сторінка рендериться як «Acme Logistics» — і властивості файлу теж кажуть «Acme Logistics». Правий клік → Властивості показує документ, що повністю належить Acme. Той факт, що байти створено gPdf на edge за ~4 мс, ніде не випливає там, куди дивиться одержувач.

А чи не захочуть клієнти знати, що ви використовуєте gPdf?

Це питання виникає достатньо часто, щоб відповісти на нього прямо.

Так — ваші клієнти цілком можуть знати, що ви побудовані на gPdf. Це питання між вами і ними, і зазвичай йому місце у вашому інженерному блозі, чейнджлозі, документах архітектури безпеки чи списку sub-processor’ів (де gPdf з’являється, якщо релевантно вашому DPA).

Поле Producer не про ці стосунки. Воно про кінцевого одержувача документа вашого клієнта — клерка із закупівель, диспетчера перевізника, обробника форм у податковій — у якого немає стосунків із вашим вибором рендерера і немає причин дбати про те, який він. Для нього «Skia/PDF m120» у діалозі Властивостей — шум; «Acme Billing Platform» — сигнал.

Тут також немає нічого нечесного. Специфікація PDF визначає Producer як «назву застосунку, який створив оригінальний PDF.» Якщо ви будуєте PDF-сервіс поверх gPdf, ваш застосунок створив байти, які gPdf відправив. Зазначити це в Producer — точно. Чесна версія така:

gPdf — інфраструктура рендерингу.
Ваша платформа — продюсер.
Ваш клієнт — автор.

Кожен шар отримує визнання там, де його задумує специфікація PDF.

Виноска про подальший пайплайни

Якщо ваш вихідний PDF проходить через будь-який етап постобробки перш ніж дійти до одержувача — Ghostscript без явних прапорців збереження метаданих, корпоративний DRM/інструмент водяних знаків, «PDF-оптимізатор» — деякі з цих інструментів тихо перепишуть Producer на свою назву і скасують щойно задані вами брендовані метадані. Тестуйте на справжньому пайплайні, а не лише на сирій відповіді gPdf.

Зауваження про те, чого тут немає

Щоб залишатися точними: шість стандартних полів вище — це те, що gPdf виставляє сьогодні. Цього достатньо для white-labelling властивостей документа — про що й історія brand-identity.

Цього не достатньо, щоб ховати довільний бізнес-контекст (UUID замовлення, код складу, версія шаблону) усередині PDF для прочитання подальших системами. Це окрема, комплементарна можливість — XMP custom metadata + довільні ключ-значення — яку специфікація PDF підтримує і яку ми відстежуємо як roadmap-пункт. Якщо вона потрібна вам сьогодні, ID-подібні дані зазвичай надійніше живуть у власній БД платформи, ключем за іменем файлу чи хешем, ніж усередині самого PDF. Метадані — для ідентичності документа, не для переміщення структурованих бізнес-даних через PDF як транспортний рівень.

Брендовані метадані (сьогодні) ≠ прихований потік бізнес-даних (окремо). Варто тримати їх роздільно у власному плануванні.

Найменше можливе покращення

Якщо ви вже робите POST на /api/v1/pdf/render і ваш поточний виклик не має settings.metadata, найменше покращення — три рядки, додані до JSON, який ви вже надсилаєте:

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

Два поля, один новий ключ. Перевіряється pdfinfo за секунди. Коли ці зміни приживуться, заповніть title, language, subject і creator, коли матимете час.

Де це знаходиться в gPdf API

Шість рядків усередині settings.metadata. Політики на рівні токена також можуть викреслювати ці поля чи задавати їм значення за замовчуванням, щоб multi-tenant SaaS міг забезпечити правильну атрибуцію кожного PDF, який генерують його клієнти, не довіряючи кожному API-викликачу задавати їх.

§4.14.2 Metadata в API reference — поле-за-полем довідник.
Поле-за-полем глибокий розбір — коли кожне з title / language / author / subject / creator / producer має значення, що читачі реально з ними роблять і як перевірити те, що ви відправили.

Видима сторінка — половина бренду. Властивості файлу — інша половина. Якщо ваша платформа відправляє PDF від імені клієнтів, обидві половини мають говорити їхнє ім’я.