Otwórz dowolny PDF kluczowy dla biznesu — fakturę, etykietę wysyłkową, miesięczny wyciąg — i zajrzyj we właściwości dokumentu (Cmd+D w Podglądzie na macOS, Ctrl+D w Adobe Reader, „Plik → Właściwości“ w większości przeglądarek desktopowych). Następnie spójrz na pole Producer.

Jeśli PDF został wygenerowany przez platformę SaaS za pomocą headless browsera, często zobaczysz coś takiego:

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

Strona powyżej wygląda jak marka dostawcy SaaS. Właściwości pliku natomiast nazywają silnik przeglądarki, który nie ma nic wspólnego z tym dostawcą — ani z klientem, w imieniu którego SaaS wysyła dokument.

I właśnie o tej różnicy jest ten wpis.

Strona jest oznakowana, plik nie

Generowanie PDF pod własną marką to dobrze rozumiany wymóg dla B2B SaaS. Dostawca pozwala klientowi wgrać logo, wybrać kolory marki, skonfigurować szablon; eksportowane PDF-y wizualnie wyglądają jak marka klienta, a nie dostawcy.

Większość platform na tym poprzestaje. Rozwiązują warstwę widoczną i zostawiają warstwę właściwości pliku w spokoju. Wynik: dokument, który na każdej stronie mówi „Acme Logistics“, ale w momencie, gdy ktoś kliknie prawym → Właściwości, identyfikuje się jako „Skia/PDF m120“.

Dla jednorazowego pobrania B2C — osobistego paragonu, biletu do kina — właściwości pliku są w zasadzie kosmetyczne. Dla dokumentu B2B lub dowolnego regulowanego outputu B2C (raportów medycznych, sprawozdań finansowych, komunikatów prawnych, regulowanych formularzy ubezpieczeniowych) właściwości pliku są częścią dokumentu. Pojawiają się w:

Adobe Reader, Preview, Foxit, każdej desktopowej przeglądarce PDF
Systemach zarządzania dokumentami (SharePoint, M-Files, NetSuite Files)
Podglądach PDF serwerów pocztowych
Indeksach wyszukiwania (Spotlight, Outlook, wewnętrzne wyszukiwanie DMS)
Systemach archiwizacji (PDF/A do długoterminowego przechowywania)
Wszystkim, co wywołuje pdfinfo lub pdftk dump_data w potoku przetwarzania

Dokument, którego strona mówi „Acme“, a pole Producer mówi „Chromium“, czytany jest przez te systemy jako „wyrenderowany przez Chromium dla kogoś o nazwie Acme“ — a nie „wyrenderowany przez Acme“. Dla zakupów korporacyjnych i oceny zgodności ta różnica jest zauważalna.

Dlaczego to gorsze dla dostawcy SaaS niż dla bezpośredniego użytkownika

Jeśli generujesz PDF dla siebie, „Chromium“ w polu Producer to wyłącznie Twój problem.

Jeśli jesteś dostawcą SaaS, a Twoi klienci generują PDF-y przez Twoją platformę, łańcuch jest dłuższy:

Ty wybrałeś stos renderujący.
Twój klient wysyła powstały PDF swojemu klientowi.
Końcowy odbiorca — zespół zakupów, przewoźnik, instytucja podatkowa, dział finansowy — widzi pole Producer, które nie nazywa ani Ciebie, ani Twojego klienta. Nazywa wcześniejszy silnik generowania PDF, którego akurat używasz.

Marka Twojego klienta na stronie; nieznana nazwa narzędzia w pliku. Z perspektywy odbiorcy dokument wygląda lekko nie tak, czego nie potrafi do końca nazwać. Z perspektywy Twojego klienta obietnica dokumentów pod własną marką nie została w pełni zrealizowana.

To ta część, w którą większość platform inwestuje za mało, bo poprawki nie widać ze strony głównej. Ale klient, który raz uruchomi pdfinfo na wyjściu Twojej funkcji PDF pod własną marką, to zauważy.

Kiedy to naprawdę boli

Oto sytuacje, w których pole Producer pojawiło się jako realny problem operacyjny, a nie hipoteza:

Ankiety bezpieczeństwa dostawców. Zakupy korporacyjne robią przegląd ryzyka dostawcy i pytają: „wymień wszystkie zewnętrzne narzędzia, które pojawiają się w dokumentach, jakie nam wysyłacie“. Zespół IT klienta uruchamia pdfinfo na przykładowym dokumencie i znajduje nieznaną nazwę generatora. Nikt się nie złości — ale trafia ona na listę sub-procesorów, co uruchamia przegląd zarządzania dostawcami i osobny zestaw kontroli zgodności.
Wyszukiwanie w DMS / archiwum. System zarządzania dokumentami klienta indeksuje PDF-y po author. Gdy PDF-y z Twojej platformy mają puste pole Author, zespół ds. zgodności klienta nie może łatwo odfiltrować „dokumentów od tego dostawcy“ wiele miesięcy później — kończą na dodawaniu ręcznych tagów, czego nie powinni musieć robić.
Walidacja długoterminowego archiwum. System archiwizacji PDF/A flaguje dokumenty, w których Producer nie zgadza się z oczekiwaną listą dostawców. Zespół ds. zgodności musi ręcznie dopisywać „Skia/PDF m120“ i „wkhtmltopdf“ jako znane i akceptowane generatory — niewielkie, ale stałe obciążenie operacyjne.
Audyty spójności marki. Niektóre korporacyjne zespoły marketingowe audytują atrybucję wychodzących dokumentów jako część ładu nad marką. Dokument przypisany do narzędzia, o którym zespół marki nigdy nie słyszał, staje się ustaleniem.

Żadne z tych zdarzeń nie jest krytycznym incydentem. To „papierowe skaleczenia“, które dodają tarcia sprzedaży enterprise, onboardingowi dostawców i operacji. Kumulują się przy tysiącach dokumentów miesięcznie.

Co właściwie ujawniają właściwości pliku

Specyfikacja PDF rezerwuje sześć standardowych pól metadanych, które wyświetla prawie każda przeglądarka:

Pole	Do czego służy	Co zwykle pokazuje stos, który „przecieka“
`Title`	Tytuł dokumentu	Autogenerowana nazwa pliku lub puste
`Author`	Osoba lub organizacja, która stworzyła dokument	Puste lub nazwisko dewelopera
`Subject`	Krótki opis dokumentu	Puste
`Creator`	Aplikacja, która wytworzyła treść źródłową	„Chromium“, „Mozilla/5.0…“ lub wewnętrzna nazwa narzędzia dostawcy SaaS
`Producer`	Aplikacja, która wytworzyła bajty PDF	„Skia/PDF m120“, „wkhtmltopdf 0.12.x“, „iText 7.x.x“
`Language`	Etykieta językowa BCP-47	Puste lub błędny locale

Każde z nich to krótki ciąg znaków. Żadne nie jest technicznie trudne do wypełnienia. Powód, dla którego przeciekają domyślnie, jest taki, że biblioteka renderująca wpisuje swoją nazwę w Producer (poprawnie — pole jest właśnie po to), a większość kodu aplikacji nigdy nie ustawia pozostałych pięciu.

Rozwiązaniem jest ustawienie ich — świadomie, przy każdym renderze, z poziomu aplikacji, która wie, do czego dokument służy.

Jak wyglądają „oznakowane metadane“ w praktyce

Oto ten sam blok metadanych w wersji, jaką produkuje gPdf. Sześć pól, wszystkie nadpisywalne przez wywołującego:

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

Ten sam pdfinfo na wynikowym PDF-ie:

$ 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

Strona renderuje się jako „Acme Logistics“ — i właściwości pliku też mówią „Acme Logistics“. Kliknięcie prawym → Właściwości pokazuje dokument, który w pełni należy do Acme. Fakt, że bajty zostały wyprodukowane przez gPdf na edge w ~4 ms, nie pojawia się nigdzie, gdzie odbiorca patrzy.

Czy klienci nie będą chcieli wiedzieć, że używasz gPdf?

To pytanie pojawia się dostatecznie często, żeby odpowiedzieć na nie wprost.

Tak — Twoi klienci jak najbardziej mogą wiedzieć, że budujesz na gPdf. To sprawa między Wami i zwykle ma swoje miejsce na Twoim blogu inżynierskim, w changelogu, w dokumentach architektury bezpieczeństwa lub na liście sub-procesorów (gdzie gPdf pojawia się, jeśli ma to znaczenie dla Twojego DPA).

Pole Producer nie jest o tej relacji. Jest o końcowym odbiorcy dokumentu Twojego klienta — referencie zakupów, dyspozytorze przewoźnika, pracowniku instytucji podatkowej — który nie ma żadnej relacji z Twoim wyborem silnika PDF i żadnego powodu, by się tym przejmować. Dla takiej osoby „Skia/PDF m120“ w oknie Właściwości to szum; „Acme Billing Platform“ to sygnał.

Nie ma w tym też nic nieuczciwego. Specyfikacja PDF definiuje Producer jako „nazwę aplikacji, która wytworzyła oryginalny PDF“. Jeśli budujesz usługę PDF na gPdf, to Twoja aplikacja wytworzyła bajty, które gPdf wysłał. Wpisanie tego w Producer jest poprawne. Uczciwa wersja brzmi tak:

gPdf to infrastruktura renderująca.
Twoja platforma jest producerem.
Twój klient jest authorem.

Każda warstwa dostaje uznanie tak, jak zamierza to specyfikacja PDF.

Przypis o dalszych etapach przetwarzania

Jeśli Twój wyjściowy PDF przechodzi przez jakikolwiek etap obróbki po renderze, zanim dotrze do odbiorcy — Ghostscript bez jawnych flag zachowania metadanych, korporacyjne narzędzie DRM/znaków wodnych, „optymalizator PDF“ — niektóre z tych narzędzi po cichu przepiszą Producer na własną nazwę i cofną oznakowane metadane, które właśnie ustawiłeś. Testuj wobec rzeczywistego potoku produkcyjnego, a nie tylko surowej odpowiedzi gPdf.

Notka o tym, czego tutaj nie ma

Żeby zachować precyzję: sześć standardowych pól powyżej to to, co gPdf eksponuje dziś. To wystarczy, by właściwości dokumentu działały pod własną marką — o czym właśnie traktuje historia o tożsamości marki.

To nie wystarczy, żeby ukrywać dowolny kontekst biznesowy (UUID zamówienia, kod magazynu, wersję szablonu) wewnątrz PDF-a do odczytu przez dalsze systemy. To osobna, komplementarna funkcjonalność — niestandardowe metadane XMP + dowolne pary klucz-wartość — którą specyfikacja PDF obsługuje i którą trzymamy jako pozycję na roadmapie. Jeśli potrzebujesz tego dziś, dane typu identyfikator zwykle żyją pewniej w bazie danych Twojej platformy, indeksowane po nazwie pliku PDF lub hashu, niż wewnątrz samego PDF-a. Metadane są od tożsamości dokumentu, a nie od przenoszenia ustrukturyzowanych danych biznesowych przez PDF-y jako warstwę transportową.

Oznakowane metadane (dziś) ≠ ukryty przepływ danych biznesowych (osobno). Warto trzymać te dwie rzeczy oddzielnie we własnym planowaniu.

Najmniejsza możliwa poprawa

Jeśli już wysyłasz POST na /api/v1/pdf/render, a Twoje obecne wywołanie nie ma settings.metadata, najmniejszą poprawą są trzy linie dodane do JSON-a, który już wysyłasz:

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

Dwa pola, jeden nowy klucz. Weryfikowalne pdfinfo w sekundy. Gdy to wjedzie, uzupełnij title, language, subject i creator w wolnej chwili.

Gdzie to ląduje w API gPdf

Sześć linii w settings.metadata. Polityki na poziomie tokenu mogą również usuwać lub domyślnie wypełniać te pola, tak by multi-tenant SaaS mógł wymusić, że każdy PDF generowany przez jego klientów jest poprawnie atrybutowany, bez ufania, że każdy wywołujący API to ustawi.

§4.14.2 Metadata w referencji API — referencja pole po polu.
Zanurzenie pole po polu — kiedy każde z title / language / author / subject / creator / producer ma znaczenie, co czytelnicy z nimi rzeczywiście robią i jak zweryfikować to, co wysłałeś.

Widoczna strona to połowa marki. Właściwości pliku to druga połowa. Jeśli Twoja platforma wysyła PDF-y w imieniu klientów, obie połowy powinny nosić ich nazwę.