gPdf
Блог

В свойствах PDF должен значиться ваш бренд, а не чужой инструмент

Большинство white-label PDF-стеков рендерят страницу под вашим брендом, но негромко вписывают имя стороннего инструмента в поле Producer. Для B2B SaaS, отгружающих PDF от имени клиентов, этот разрыв важен.

gPdf Engineering
#pdf-metadata#white-label#branding#saas

Откройте любой бизнес-критичный PDF — счёт, транспортную накладную, ежемесячную выписку — и посмотрите свойства документа (Cmd+D в Preview на macOS, 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 всплывало как реальная операционная проблема, а не гипотеза:

  • Опросники безопасности по поставщикам. Корпоративные закупки проводят оценку рисков по поставщикам и спрашивают: «перечислите все сторонние инструменты, которые встречаются в документах, отгружаемых нам». ИТ-команда клиента запускает pdfinfo по образцовому документу и находит незнакомое имя рендерера. Никто не злится — но это добавляется в список субпроцессоров, что затем запускает ревью управления поставщиками и отдельный набор комплаенс-проверок.
  • Поиск по DMS / архиву. Система документооборота клиента индексирует PDF по author. Когда у PDF с вашей платформы поле Author пустое, комплаенс-команда клиента не может просто отфильтровать «документы этого поставщика» спустя несколько месяцев — они в итоге добавляют ручные теги, чего им делать не должно бы приходиться.
  • Валидация долгосрочного архива. Система архивирования PDF/A помечает документы, у которых Producer не совпадает с ожидаемым списком поставщиков. Комплаенс-команде приходится вручную вносить «Skia/PDF m120» и «wkhtmltopdf» в whitelist как известные-ОК рендереры — небольшая, но постоянная операционная нагрузка.
  • Аудиты единообразия бренда. Некоторые корпоративные маркетинговые команды аудируют атрибуцию исходящих документов в рамках бренд-управления. Документ, атрибутированный инструменту, о котором бренд-команда никогда не слышала, превращается в замечание.

Ни один из этих кейсов не является критическим инцидентом. Это «бумажные порезы», добавляющие трение в корпоративные продажи, онбординг поставщиков и операционную работу. Они накапливаются на тысячах документов в месяц.

Что на самом деле выставляют наружу свойства файла

Спецификация 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. Это между вами и ними, и обычно это уместно в вашем инженерном блоге, в changelog, в документах по архитектуре безопасности или в списке субпроцессоров (в котором gPdf появляется, если это относится к вашему DPA).

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

В этом нет ничего нечестного. Спецификация PDF определяет Producer как «имя приложения, произведшего исходный PDF». Если вы строите PDF-сервис поверх gPdf, ваше приложение произвело байты, которые отгрузил gPdf. Сказать это в Producer — точно. Честная версия такова:

  • gPdf — инфраструктура рендеринга.
  • Ваша платформа — producer.
  • Ваш клиент — author.

Каждый уровень получает кредит так, как это и подразумевает спецификация PDF.

Сноска про downstream-пайплайны

Если ваш выходной PDF проходит какую-либо стадию постобработки перед тем, как попадёт к получателю — Ghostscript без явных флагов сохранения метаданных, корпоративный инструмент DRM/водяных знаков, «оптимизатор PDF» — некоторые из этих инструментов тихо перепишут Producer на собственное имя и отменят брендированные метаданные, которые вы только что задали. Тестируйте против реального пайплайна, а не только против сырого ответа gPdf.

Заметка о том, чего здесь нет

Чтобы оставаться точным: шесть стандартных полей выше — это то, что gPdf экспонирует сегодня. Этого достаточно для white-labelling свойств документа — а именно об этом и идёт речь в истории про идентичность бренда.

Этого не достаточно, чтобы прятать произвольный бизнес-контекст (UUID заказа, код склада, версию шаблона) внутри PDF для чтения downstream-системами. Это отдельная, дополняющая возможность — пользовательские метаданные XMP + произвольные key-value пары — которую поддерживает спецификация PDF и которую мы трекаем как пункт roadmap. Если вам это нужно сегодня, ID-подобные данные обычно надёжнее живут в базе данных вашей собственной платформы, индексированные по имени PDF-файла или по хешу, чем внутри самого 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, когда будет время.

Где это приземляется в API gPdf

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

Видимая страница — половина бренда. Свойства файла — другая половина. Если ваша платформа отгружает PDF от имени клиентов, обе половины должны нести их имя.