Herhangi bir iş açısından kritik PDF’yi açın — bir fatura, bir kargo etiketi, aylık bir hesap özeti — ve doküman özelliklerine bakın (macOS Preview’da Cmd+D, Adobe Reader’da Ctrl+D, çoğu masaüstü görüntüleyicide “Dosya → Özellikler”). Sonra Producer alanına bakın.

PDF, headless browser kullanan bir SaaS platformu tarafından oluşturulduysa, sık sık şuna benzer bir şey görürsünüz:

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

Yukarıdaki sayfa SaaS sağlayıcısının markası gibi görünür. Dosya özellikleri, ne sağlayıcı ile ne de SaaS’in adına dokümanı gönderdiği müşteri ile ilgisi olan bir tarayıcı motorunu adlandırır.

Bu yazı, işte bu boşluk üzerine.

Sayfa markalı, dosya değil

White-label PDF üretimi, B2B SaaS için iyi anlaşılmış bir gereksinimdir. Sağlayıcı, müşterinin logo yüklemesine, marka renklerini seçmesine, şablon yapılandırmasına izin verir; dışa aktarılan PDF’ler görsel olarak sağlayıcının değil, müşterinin markası gibi görünür.

Çoğu platform burada durur. Görünür katmanı çözer, dosya özellikleri katmanını rahat bırakırlar. Sonuç: her sayfasında “Acme Logistics” yazan ama biri sağ tıklayıp → Özellikler dediği an kendini “Skia/PDF m120” olarak tanıtan bir doküman.

Tek seferlik bir B2C indirme için — kişisel bir makbuz, bir sinema bileti — dosya özellikleri çoğunlukla kozmetiktir. Bir B2B dokümanı veya herhangi bir regüle B2C çıktısı (tıbbi raporlar, mali tablolar, hukuki açıklamalar, regüle sigorta formları) için dosya özellikleri dokümanın bir parçasıdır. Şuralarda görünürler:

Adobe Reader, Preview, Foxit, her masaüstü PDF görüntüleyici
Doküman yönetim sistemleri (SharePoint, M-Files, NetSuite Files)
E-posta sunucusu PDF önizleyicileri
Arama indeksleri (Spotlight, Outlook, dahili DMS araması)
Arşiv sistemleri (PDF/A uzun vadeli koruma)
Bir pipeline’da pdfinfo veya pdftk dump_data çağıran herhangi bir şey

Sayfasında “Acme” yazan, Producer alanında “Chromium” yazan bir doküman bu sistemlere “Acme adlı biri için Chromium tarafından render edildi” olarak okunur, “Acme tarafından render edildi” olarak değil. Kurumsal tedarik ve uyum için bu ayrım fark edilir.

Bu neden doğrudan kullanıcılar yerine SaaS sağlayıcısı için daha kötü

PDF’yi kendiniz için üretiyorsanız, Producer alanındaki “Chromium” yalnızca sizin probleminizdir.

Bir SaaS sağlayıcısıysanız ve müşterileriniz PDF’leri sizin platformunuz üzerinden üretiyorsa, zincir daha uzundur:

Siz render yığınını seçtiniz.
Müşteriniz sonuçtaki PDF’yi kendi müşterisine gönderiyor.
Son alıcı — bir tedarik ekibi, bir taşıyıcı, bir vergi dairesi, bir finans departmanı — ne sizi ne de müşterinizi adlandıran bir Producer alanı görür. Kullanmaya denk geldiğiniz upstream renderer’ı adlandırır.

Sayfada müşterinizin markası; dosyada tanıdık gelmeyen bir araç adı. Alıcı perspektifinden doküman, sebebini tam adlandıramadıkları biçimde biraz tuhaf görünür. Müşteriniz perspektifinden, white-label vaadi tam olarak yerine getirilmemiştir.

Bu, çoğu platformun az yatırım yaptığı kısımdır, çünkü düzeltme ana sayfadan görünmez. Ama “white-label PDF” özelliğinizin çıktısına tek bir pdfinfo çalıştıran müşteri bunu fark edecektir.

Bu gerçekten ne zaman canınızı yakar

Bunlar, Producer alanının varsayımsal değil gerçek bir operasyonel sorun olarak ortaya çıktığı durumlardır:

Sağlayıcı güvenlik anketleri. Kurumsal tedarik bir vendor risk review yapar ve sorar: “bize gönderdiğiniz doküman çıktılarında görünen tüm üçüncü taraf araçları listeleyin.” Müşterinin IT ekibi örnek bir doküman üzerinde pdfinfo çalıştırır ve tanımadığı bir renderer adı bulur. Kimse kızmaz — ama bu sub-processor listesine eklenir, bu da vendor-management review’i ve ayrı bir uyum kontrol setini tetikler.
DMS / arşiv araması. Müşterinin doküman yönetim sistemi PDF’leri author’a göre indeksler. Sizin platformunuzdan gelen PDF’lerin Author alanı boş olduğunda, müşterinin uyum ekibi aylar sonra “bu sağlayıcıdan dokümanlar” diye kolayca filtreleyemez — manuel etiketler eklemek zorunda kalırlar, ki zorunda olmamalılar.
Uzun vadeli arşiv doğrulaması. Bir PDF/A arşiv sistemi, Producer beklenen sağlayıcı listesiyle eşleşmeyen dokümanları işaretler. Uyum ekibi “Skia/PDF m120” ve “wkhtmltopdf“yi bilinen-OK renderer’lar olarak manuel allow-list’e koymak zorunda — küçük ama süregelen bir operasyonel yük.
Marka tutarlılığı denetimleri. Bazı kurumsal pazarlama ekipleri, dışa giden doküman atfını brand-governance’ın parçası olarak denetler. Marka ekibinin hiç duymadığı bir araca atfedilen bir doküman bir bulgu olur.

Bunların hiçbiri kritik olay değildir. Kurumsal satışa, sağlayıcı onboarding’ine ve operasyonlara sürtünme ekleyen kâğıt kesikleridir. Ayda binlerce dokümanda birikirler.

Dosya özellikleri aslında neyi ifşa eder

PDF spesifikasyonu, neredeyse her görüntüleyicinin yüzeyleştirdiği altı standart metadata alanı ayırır:

Alan	Ne içindir	Sızdıran bir yığın genellikle ne gösterir
`Title`	Doküman başlığı	Otomatik üretilmiş dosya adı veya boş
`Author`	Dokümanı oluşturan kişi veya organizasyon	Boş veya geliştiricinin adı
`Subject`	Dokümanın kısa açıklaması	Boş
`Creator`	Kaynak içeriği üreten uygulama	“Chromium”, “Mozilla/5.0…” veya SaaS sağlayıcısının dahili araç adı
`Producer`	PDF byte’larını üreten uygulama	“Skia/PDF m120”, “wkhtmltopdf 0.12.x”, “iText 7.x.x”
`Language`	BCP-47 dil etiketi	Boş veya yanlış locale

Bunların her biri kısa bir dize. Hiçbiri teknik olarak doldurması zor değil. Varsayılan olarak sızmalarının nedeni, render kütüphanesinin Producer’a kendi adını yazmasıdır (doğru — alan bunun için var), ve çoğu uygulama kodu diğer beşini hiçbir zaman ayarlamaz.

Düzeltme onları ayarlamaktır — kasıtlı olarak, her render’da, dokümanın ne için olduğunu bilen uygulamadan.

“Markalı metadata” pratikte nasıl görünür

İşte gPdf’in ürettiği aynı metadata bloğu. Altı alan, hepsi çağıran tarafından geçersiz kılınabilir:

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

Sonuçtaki PDF üzerinde aynı pdfinfo:

$ 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

Sayfa “Acme Logistics” olarak render edilir — ve dosya özellikleri de “Acme Logistics” der. Sağ tık → Özellikler tamamen Acme’ye ait bir doküman gösterir. Byte’ların edge’de gPdf tarafından ~4 ms’de üretildiği gerçeği, alıcının baktığı hiçbir yerde yüzeye çıkmaz.

Müşteriler gPdf kullandığınızı bilmek istemez mi?

Bu soru yeterince sık geldiği için doğrudan cevaplamaya değer.

Evet — müşterileriniz kesinlikle gPdf üzerine inşa ettiğinizi bilebilir. Bu, sizinle onlar arasındadır ve genellikle mühendislik blogunuzda, changelog’unuzda, güvenlik mimarisi dokümanlarınızda veya sub-processor listenizde (DPA’nızla ilgiliyse gPdf orada görünür) yeri vardır.

Producer alanı bu ilişki hakkında değildir. Müşterinizin dokümanının son alıcısı hakkındadır — bir tedarik memuru, bir taşıyıcı sevk görevlisi, bir vergi dairesi form işleyicisi — renderer seçiminizle ilişkisi olmayan ve bunun ne olduğunu umursamak için sebebi olmayan biri. Onun için, Özellikler diyalogundaki “Skia/PDF m120” gürültüdür; “Acme Billing Platform” sinyaldir.

Bunda dürüst olmayan bir şey de yok. PDF spec’i Producer’ı “orijinal PDF’yi üreten uygulamanın adı” olarak tanımlar. gPdf üzerine bir PDF servisi inşa ediyorsanız, uygulamanız gPdf’in gönderdiği byte’ları üretti. Producer’da bunu söylemek doğrudur. Dürüst versiyon şudur:

gPdf render altyapısıdır.
Platformunuz üreticidir.
Müşteriniz yazardır.

PDF spec’inin amaçladığı yerde her katman hak ettiği krediyi alır.

Downstream pipeline’lar üzerine bir dipnot

Çıktı PDF’iniz alıcıya ulaşmadan önce herhangi bir son-işleme aşamasından geçiyorsa — açık metadata-koruma flag’leri olmadan Ghostscript, bir kurumsal DRM/watermarking aracı, bir “PDF optimizer” — bu araçlardan bazıları sessizce Producer’ı kendi adlarına yeniden yazar ve az önce ayarladığınız markalı metadata’yı geri alır. Yalnızca ham gPdf yanıtına değil, gerçek pipeline’ınıza karşı test edin.

Burada olmayanlar üzerine bir not

Doğru kalmak için: yukarıdaki altı standart alan, gPdf’in bugün yüzeyleştirdikleridir. Doküman özelliklerini white-label’lamak için bu yeterlidir — marka-kimliği hikayesinin amacı budur.

İsteğe bağlı iş bağlamını (sipariş UUID’si, depo kodu, şablon sürümü) downstream sistemlerin okuması için PDF’in içine yerleştirmek için bu yeterli değildir. Bu, ayrı, tamamlayıcı bir yetenektir — XMP custom metadata + isteğe bağlı anahtar-değer çiftleri — PDF spec’i bunu destekler ve biz bunu roadmap maddesi olarak takip ediyoruz. Bugün ihtiyacınız varsa, ID tipi veriler genellikle PDF’in içinde olmaktan daha güvenilir biçimde platformunuzun kendi veritabanında, PDF’in dosya adı veya hash’i ile anahtarlanmış olarak yaşar. Metadata dokümanın kimliği içindir, yapılandırılmış iş verisini bir taşıma katmanı olarak PDF’ler üzerinden taşımak için değil.

Markalı metadata (bugün) ≠ gizli iş-veri akışı (ayrı). Kendi planlamanızda bunları ayrı tutmaya değer.

Mümkün olan en küçük iyileştirme

Eğer zaten /api/v1/pdf/render’a POST atıyorsanız ve mevcut çağrınızda settings.metadata yoksa, en küçük iyileştirme zaten gönderdiğiniz JSON’a eklenmiş üç satırdır:

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

İki alan, bir yeni anahtar. Saniyeler içinde pdfinfo ile doğrulanabilir. Bunlar yerleştikten sonra, zamanınız olduğunda title, language, subject ve creator’ı doldurun.

Bu gPdf API’sinde nerede yer alır

settings.metadata içinde altı satır. Token başına politikalar bu alanları da çıkartabilir veya varsayılan değer atayabilir, böylece multi-tenant bir SaaS, her API çağıranın bunları ayarlamasına güvenmeden müşterilerinin ürettiği her PDF’in doğru atıflanmasını sağlayabilir.

§4.14.2 Metadata API reference’ta — alan-alan referans.
Alan-alan derinlemesine inceleme — title / language / author / subject / creator / producer’ın her birinin ne zaman önemli olduğu, okuyucuların onlarla gerçekte ne yaptığı ve gönderdiğinizi nasıl doğrulayacağınız.

Görünür sayfa markanın yarısıdır. Dosya özellikleri diğer yarısıdır. Platformunuz müşteriler adına PDF gönderiyorsa, her iki yarı da onların adını söylemelidir.