PDF properties में आपका brand दिखे, किसी और का tool नहीं

कोई भी business-critical PDF खोलिए — एक invoice, एक shipping label, एक monthly statement — और document properties देखिए (macOS Preview पर Cmd+D, Adobe Reader में Ctrl+D, अधिकांश desktop viewers में “File → Properties”)। फिर Producer field देखिए।

अगर PDF किसी SaaS platform ने headless browser से generate किया है, तो आपको अक्सर कुछ ऐसा दिखेगा:

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

ऊपर वाला page SaaS vendor के brand जैसा दिखता है। file properties एक browser engine का नाम बताती हैं जिसका न तो vendor से और न ही उस customer से कोई संबंध है जिसकी तरफ़ से SaaS document ship कर रहा है।

यह post उसी gap के बारे में है।

page पर brand है, file पर नहीं

White-label PDF generation B2B SaaS के लिए एक अच्छी तरह से समझी गई requirement है। Vendor customer को logo upload करने, brand colours चुनने, template configure करने देता है; export किए गए PDFs visually customer के brand जैसे दिखते हैं, vendor के नहीं।

ज़्यादातर platforms वहीं रुक जाते हैं। वे दिखाई देने वाली layer solve करते हैं और file-properties layer को अकेला छोड़ देते हैं। नतीजा: एक document जो हर page पर “Acme Logistics” कहता है लेकिन जैसे ही कोई right-click → Properties करता है, ख़ुद को “Skia/PDF m120” बताता है।

एक one-off B2C download के लिए — personal receipt, movie ticket — file properties ज़्यादातर cosmetic हैं। एक B2B document या किसी भी regulated B2C output (medical reports, financial statements, legal disclosures, regulated insurance forms) के लिए, file properties document का हिस्सा हैं। वे यहाँ दिखती हैं:

• Adobe Reader, Preview, Foxit, हर desktop PDF viewer
• Document management systems (SharePoint, M-Files, NetSuite Files)
• Email-server PDF previewers
• Search indexes (Spotlight, Outlook, internal DMS search)
• Archive systems (PDF/A long-term preservation)
• कुछ भी जो pipeline में pdfinfo या pdftk dump_data call करता है

एक document जिसके page पर “Acme” है और जिसका Producer field “Chromium” कहता है, इन systems के लिए “Chromium ने Acme नाम के किसी के लिए render किया” पढ़ा जाता है — “Acme ने render किया” नहीं। Enterprise procurement और compliance के लिए, यह distinction दर्ज होता है।

यह direct users की तुलना में SaaS vendor के लिए बदतर क्यों है

अगर आप अपने लिए PDF generate करते हैं, तो Producer field में “Chromium” केवल आपकी समस्या है।

अगर आप एक SaaS vendor हैं और आपके customers आपके platform से PDFs generate करते हैं, तो chain लंबी है:

• आपने rendering stack चुना।
• आपका customer resulting PDF अपने customer को ship करता है।
• final recipient — एक procurement team, एक carrier, एक tax office, एक finance department — एक Producer field देखता है जो न आपका नाम लेता है, न आपके customer का। यह उस upstream renderer का नाम लेता है जिसे आप इस्तेमाल करते हैं।

page पर आपके customer का brand; file में एक अनजान tool का नाम। recipient के नज़रिये से document थोड़ा अजीब लगता है, और वे इसे ठीक से नाम नहीं दे पाते। आपके customer के नज़रिये से, white-label का वादा पूरा नहीं हुआ।

यह वही हिस्सा है जिसमें ज़्यादातर platforms कम invest करते हैं, क्योंकि fix homepage से दिखाई नहीं देता। लेकिन वह customer जो आपके “white-label PDF” feature के output पर एक pdfinfo चलाएगा, यह notice करेगा।

यह असल में कब चुभता है

ये वो situations हैं जहाँ Producer field hypothetical नहीं, real operational issue बन कर सामने आया:

• Vendor security questionnaires. Enterprise procurement एक vendor risk review चलाता है और पूछता है: “हर third-party tool की list दें जो आप हमें ship करने वाले document outputs में दिखाई देता है।” customer की IT team एक sample document पर pdfinfo चलाती है और एक अनजान renderer name पाती है। कोई नाराज़ नहीं — लेकिन यह sub-processor list में जुड़ जाता है, जो फिर vendor-management review और compliance checks का अलग set trigger करता है।
• DMS / archive search. customer का document management system PDFs को author के आधार पर index करता है। जब आपके platform से PDFs में Author field खाली होता है, customer की compliance team महीनों बाद आसानी से “इस vendor से documents” filter नहीं कर सकती — वे manual tags जोड़ने लगते हैं, जो उनको नहीं करना चाहिए।
• Long-term archive validation. एक PDF/A archive system उन documents को flag करता है जहाँ Producer expected vendor list से match नहीं होता। compliance team को “Skia/PDF m120” और “wkhtmltopdf” को known-OK renderers के रूप में manually allow-list करना पड़ता है — एक छोटा लेकिन चलता रहने वाला operational burden।
• Brand-consistency audits. कुछ enterprise marketing teams outbound document attribution का brand-governance के हिस्से के रूप में audit करती हैं। एक document जो किसी ऐसे tool को attribute हुआ है जिसके बारे में brand team ने कभी सुना ही नहीं, एक finding बन जाता है।

इनमें से कोई भी critical incident नहीं है। ये paper cuts हैं जो enterprise sales, vendor onboarding और operations में friction जोड़ते हैं। ये हर महीने हज़ारों documents में compound होते हैं।

file properties असल में क्या expose करती हैं

PDF specification छह standard metadata fields reserve करता है जो लगभग हर viewer surface करता है:

Field	किसके लिए है	leaky stack आमतौर पर क्या दिखाता है
Title	Document title	Auto-generated filename, या खाली
Author	document बनाने वाला व्यक्ति या organisation	खाली, या developer का नाम
Subject	document का छोटा description	खाली
Creator	वह application जिसने source content produce किया	“Chromium”, “Mozilla/5.0…”, या SaaS vendor का internal tool name
Producer	वह application जिसने PDF bytes produce किए	“Skia/PDF m120”, “wkhtmltopdf 0.12.x”, “iText 7.x.x”
Language	BCP-47 language tag	खाली, या ग़लत locale

इनमें से हर एक एक छोटी string है। इनमें से किसी को भरना technically मुश्किल नहीं है। by default leak होने का कारण यह है कि rendering library Producer में अपना नाम लिखती है (सही — field उसी के लिए है), और ज़्यादातर application code बाक़ी पाँच कभी set नहीं करता।

Fix यह है कि उन्हें set करें — deliberately, हर render पर, उस application से जो जानता है कि document किसके लिए है।

“branded metadata” practice में कैसी दिखती है

यहाँ वही metadata block है जैसा gPdf produce करता है। छह fields, सभी caller द्वारा override किए जा सकते हैं:

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

resulting PDF पर वही 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

page “Acme Logistics” के रूप में render होता है — और file properties भी “Acme Logistics” कहती हैं। right-click → Properties पूरी तरह से Acme से संबंधित एक document दिखाती है। यह तथ्य कि bytes gPdf ने edge पर ~4 ms में produce किए हैं, वहाँ कहीं भी surface नहीं होता जहाँ recipient देखता है।

क्या customers जानना नहीं चाहेंगे कि आप gPdf इस्तेमाल कर रहे हैं?

यह question काफ़ी बार आता है, इसलिए इसका सीधा जवाब देना उचित है।

हाँ — आपके customers बिल्कुल जान सकते हैं कि आप gPdf पर build कर रहे हैं। यह आपके और उनके बीच की बात है, और आमतौर पर इसकी जगह आपके engineering blog, changelog, security architecture documents, या sub-processor list में होती है (जहाँ अगर आपकी DPA के लिए relevant हो तो gPdf दिखता है)।

Producer field उस relationship के बारे में नहीं है। यह आपके customer के document के end recipient के बारे में है — एक procurement clerk, एक carrier dispatcher, एक tax-office form processor — जिसका आपकी renderer choice से कोई relationship नहीं और जिसके लिए कोई reason नहीं कि वह क्या है इसकी परवाह करे। उनके लिए, Properties dialog में “Skia/PDF m120” noise है; “Acme Billing Platform” signal है।

इसमें कुछ dishonest भी नहीं। PDF spec Producer को “the name of the application that produced the original PDF” के रूप में define करता है। अगर आप gPdf पर एक PDF service build करते हैं, तो आपके application ने वे bytes produce किए जो gPdf ने ship किए। Producer में यह कहना सटीक है। ईमानदार version यह है:

• gPdf rendering infrastructure है।
• आपका platform producer है।
• आपका customer author है।

जैसे PDF spec चाहता है, हर layer को उसका हक़ मिलता है।

downstream pipelines पर एक footnote

अगर आपका output PDF recipient तक पहुँचने से पहले किसी post-processing stage से गुज़रता है — explicit metadata-preservation flags के बिना Ghostscript, एक enterprise DRM/watermarking tool, एक “PDF optimiser” — तो उनमें से कुछ tools चुपचाप Producer को अपने नाम पर rewrite कर देंगे और जो branded metadata आपने अभी set किया है उसे undo कर देंगे। अपने actual pipeline पर test करें, सिर्फ़ raw gPdf response पर नहीं।

जो यहाँ नहीं है उस पर एक note

सटीक रहने के लिए: ऊपर के छह standard fields वही हैं जो gPdf आज expose करता है। document properties को white-label करने के लिए यह पर्याप्त है — brand-identity story इसी के बारे में है।

यह downstream systems के पढ़ने के लिए arbitrary business context (order UUID, warehouse code, template version) को PDF के अंदर रखने के लिए पर्याप्त नहीं है। यह एक अलग, complementary capability है — XMP custom metadata + arbitrary key-value pairs — जिसे PDF spec support करता है और जिसे हम एक roadmap item के रूप में track कर रहे हैं। अगर आपको आज इसकी ज़रूरत है, तो ID-style data PDF के filename या hash से keyed आपके platform के अपने database में PDF के अंदर रहने से ज़्यादा reliably रहता है। Metadata document की identity के लिए है, structured business data को transport layer के रूप में PDFs से move करने के लिए नहीं।

Branded metadata (आज) ≠ hidden business-data flow (अलग)। अपनी planning में इन्हें अलग रखना worthwhile है।

सबसे छोटा संभव upgrade

अगर आप पहले से /api/v1/pdf/render पर POST कर रहे हैं और आपके current call में settings.metadata नहीं है, तो सबसे छोटा improvement उस JSON में तीन lines जोड़ना है जो आप पहले से भेज रहे हैं:

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

दो fields, एक new key। pdfinfo से seconds में verifiable। एक बार ये land कर जाएँ, समय मिले तो title, language, subject और creator भर दें।

यह gPdf API में कहाँ आता है

settings.metadata के अंदर छह lines। Per-token policies भी इन fields को strip या default कर सकती हैं ताकि एक multi-tenant SaaS यह enforce कर सके कि उसके customers द्वारा generate किया गया हर PDF सही तरीक़े से attributed हो, बिना हर API caller पर भरोसा किए कि वह उन्हें set करेगा।

• §4.14.2 Metadata, API reference में — field-by-field reference।
• Field-by-field deep dive — title / language / author / subject / creator / producer में से हर एक कब मायने रखता है, readers असल में उनके साथ क्या करते हैं, और जो आपने ship किया है उसे कैसे verify करें।

दिखाई देने वाला page brand का आधा है। file properties दूसरा आधा। अगर आपका platform customers की तरफ़ से PDFs ship करता है, तो दोनों आधे उनका नाम कहने चाहिए।