PDF properties में आपका brand दिखना चाहिए, किसी और का tool नहीं का साथी — उस post ने PDF metadata की परवाह करने का case बनाया। यह operating manual है: PDF specification में हर field किसके लिए है, कौन पढ़ता है, common mistakes, और कैसे verify करें कि आपका output ने वही ship किया जो आप चाहते थे।

gPdf छह standard fields expose करता है जो PDF spec document-level metadata के लिए define करता है। वे DocumentRequest JSON में settings.metadata के नीचे रहते हैं। हर field optional है — अगर आप एक set नहीं करते, तो gPdf या तो token के default_metadata (Enterprise policy feature) पर या एक system default पर fall back करता है।

{
  "settings": {
    "metadata": {
      "title":    "...",
      "language": "...",
      "author":   "...",
      "subject":  "...",
      "creator":  "...",
      "producer": "..."
    }
  }
}

बाक़ी post एक section per field है। हर section उसी shape का है: field क्या है, कहाँ surface होता है, common mistakes, rule of thumb। order है पहले → दूसरे → … → आख़िर में क्या भरें।

`title` — document क्या है

PDF spec इसे “document title” describe करता है।

कहाँ surface होता है:

PDF viewers में title bar (Adobe Reader, Preview, Foxit, Chromium PDF viewer सभी इसे show करते हैं)।
जब PDF inline खुलता है तो browser tab (Content-Disposition: inline)।
Search indexes — Spotlight, Outlook, SharePoint, Google Drive’s full-text indexer सभी title पढ़ते हैं और इसे heavily weight करते हैं।

Common mistakes:

❌ Title को filename के बराबर set करना. invoice-20260318.pdf filename है। title कुछ ऐसा होना चाहिए जो एक इंसान पढ़े, जैसे Invoice INV-2026-3401। Filename और title अलग concerns हैं; filename filesystems के लिए है, title viewers और search के लिए है।
❌ Title खाली छोड़ना. Viewers filename पर fall back करते हैं। नतीजा auto-generated और machine-emitted लगता है।
❌ Title में brand जोड़ना. Acme Logistics — Invoice INV-2026-3401 title bar को clutter करता है। brand author में belongs करता है, title में नहीं।

Rule of thumb: title rendered page के H1 से match होना चाहिए। अगर आपके invoice template की top line “Invoice INV-2026-3401” है, तो वही title है।

`language` — accessibility, search और compliance के लिए

language एक BCP-47 language tag है: en, de, zh-Hans, pt-BR, ar-SA। हर document के लिए set करें। छह fields में से इसके सबसे concrete downstream consequences हैं और implementation cost सबसे छोटा — इसलिए यह नीचे दबे होने के बजाय position 2 पर बैठता है।

कहाँ surface होता है:

Screen readers — JAWS, NVDA, VoiceOver इसका इस्तेमाल सही phoneme set चुनने के लिए करते हैं। एक English screen reader language: "de" PDF पढ़ते हुए German words सही pronounce करेगा; tag के बिना यह prosody ग़लत करेगा।
Search engines और indexers — affect करता है कि किस locale की stemming और stopword list apply होगी। एक language: "zh-Hans" invoice Chinese segmentation में index होती है; missing tag अक्सर default English हो जाता है और index unusable हो जाता है।
PDF/A compliance — PDF/A-2a और PDF/A-3a (accessibility profiles) language tag require करते हैं। इसके बिना, veraPDF validation fail करता है।

Common mistakes:

❌ Unset छोड़ना. “recipient की locale” पर default करें, “platform’s default” पर नहीं। ज़्यादातर leaky stacks field को लिखते ही नहीं; नतीजा screen readers जो mispronounce करते हैं और search indexes जो mis-stem करते हैं।
❌ एक non-BCP-47 string इस्तेमाल करना जैसे "english" या "EN-US". PDF spec RFC 5646 tags expect करता है: en, en-US, de, pt-BR।
❌ Platform’s default hard-code करना (e.g. हमेशा "en") document की actual content language की परवाह किए बिना। "en" tag वाली एक Portuguese invoice untagged document से बदतर है — यह actively indexer को mislead करती है।

Rule of thumb: tag actual content language से match होना चाहिए। Brazil में एक customer जो Portuguese में invoice receive कर रहा है, उसके लिए "language": "pt-BR" set करें, "en" नहीं। Multilingual documents के लिए, dominant language pick करें और बाक़ी के लिए individual content elements पर Lang attribute इस्तेमाल करें — यह document-level language field से परे एक tagged-PDF accessibility feature है।

`author` — document का मालिक कौन है

PDF spec में, author “the name of the person or organisation that created the document” है। recipients को ship होने वाले business PDFs के लिए, जवाब लगभग हमेशा organisation है — लेकिन सही shape genuinely context के अनुसार बदलती है।

कहाँ surface होता है:

हर PDF viewer में Properties dialog, “Author” labelled prominently।
DMS / archive indexers, अक्सर filter के रूप में इस्तेमाल।
PDF/A XMP metadata stream, जहाँ यह long-term archives में carry होता है।

Common mistakes:

❌ "author": "[email protected]" — operator के email को हर PDF में accidentally leak करता है, हर search index में चला जाता है, एक long-term PII issue बन जाता है।
❌ "author": "PDF Generator Service" — internal tool name; recipient के लिए कुछ नहीं means करता।
❌ खाली — Preview और ज़्यादातर viewers properties dialog में literally “(no author)” दिखाते हैं, जो “इसका कोई owner नहीं” पढ़ा जाता है।

Shapes जो काम करती हैं:

✅ "author": "Acme Logistics, Inc." — straightforward organisation।
✅ "author": "Acme Logistics — Billing" — organisation + department, specific desk को route होने वाले documents के लिए।
✅ "author": "Bridge Capital Partners — Fund III" — finance/legal में useful जहाँ attribution एक specific entity को होती है।
✅ "author": "Maria López, RICS Surveyor" — single-author publishing (reports, valuations, legal opinions) के लिए जहाँ individual ही editorial attribution है।

Rule of thumb: author वह entity है जिसे recipient document के साथ associate करे। एक multi-tenant SaaS में जहाँ platform customers की तरफ़ से PDFs generate करता है, author customer का organisation name होना चाहिए, platform का नहीं। (Platform का नाम creator में belongs करता है — नीचे देखें।) Consultancy / publishing / legal contexts में जहाँ individuals brand हैं, individuals ठीक हैं।

`subject` — यह कौनसा type का document है

subject short-description-of-the-document है। Viewers इसे prominently surface नहीं करते — ज़्यादातर users इसे कभी नहीं देखेंगे जब तक वे Properties dialog न खोलें। लेकिन document management systems, archive systems, और rules-based email/file routing इसका इस्तेमाल करते हैं।

कहाँ surface होता है:

Properties dialog, secondary position।
DMS routing rules, archive bucketing logic।
XMP metadata stream (PDF/A)।

Common mistakes:

❌ "subject": "Invoice for Acme on 2026-03-18 for $4,532.10" — यह document-instance description है, type नहीं। यह title में belongs करता है।
❌ खाली — downstream systems के लिए एक free routing hook गँवा देते हैं।
❌ Classes inconsistently mix करना ("Invoice" vs "Invoice/2026-03" vs "Monthly invoice") — DMS filters moving target पर bucket नहीं कर सकते।

Shapes जो काम करती हैं:

✅ "subject": "Invoice"
✅ "subject": "Monthly account statement"
✅ "subject": "Shipping label — 4×6 thermal"
✅ "subject": "Q3 2026 board pack"

Rule of thumb: सही granularity document class है, document instance नहीं। हज़ारों incoming PDFs वाला एक DMS subject पर route कर सकता है अगर आप उसे consistent vocabulary दें। अपने platform के लिए classes का एक finite set pick करें और कभी deviate न करें — आपके platform द्वारा generate की गई हर invoice में exactly "subject": "Invoice" होना चाहिए।

`creator` vs `producer` — सबसे ज़्यादा confuse होने वाला जोड़ा

यहीं ज़्यादातर teams PDF spec पढ़ना बंद कर देती हैं और guess करती हैं। Spec precise है; दोनों fields अलग चीज़ें mean करते हैं।

creator — वह application जिसने source content produce किया (वह upstream system जिसने decide किया कि document को क्या कहना चाहिए)।
producer — वह application जिसने PDF bytes produce किए (वह rendering engine जिसने उस content को एक PDF file में बदला)।

gPdf जैसे एक JSON-to-PDF API से invoices generate करने वाले एक SaaS billing platform के लिए:

creator = SaaS billing platform अपने version के साथ। यही वह application है जिसने decide किया कि यह Acme के लिए $4,532.10 की invoice होनी चाहिए।
producer = renderer। By default यह “gPdf” है। लेकिन क्योंकि rendering layer infrastructure है जो SaaS ने चुनी, SaaS legitimately producer को अपने platform name पर set कर सकता है — उसके platform ने, real sense में, gPdf को infrastructure के रूप में delegate करके PDF bytes produce किए।

{
  "creator":  "Acme Billing Platform v7.2",
  "producer": "Acme Billing Platform"
}

कहाँ surface होते हैं:

Properties dialog, दोनों labelled।
pdfinfo output, side by side।
PDF/A XMP stream (PDF/A में दोनों fields का non-empty होना required है)।

Common mistakes:

❌ creator एक Chromium / Mozilla user-agent string पर set करना. तब होता है जब एक headless-browser PDF stack User-Agent को automatically creator में pass करता है। यह browser version है, source-of-truth system नहीं। Override करें।
❌ producer को default renderer name के रूप में छोड़ना. ज़्यादातर teams इसे कभी override नहीं करतीं, तो हर PDF “Skia/PDF m120” या “wkhtmltopdf” कहता है — B2B के लिए यह क्यों मायने रखता है, यह जानने के लिए white-label post देखें।
❌ दोनों में same value रखना. Acceptable लेकिन wasteful — दोनों fields ठीक इसलिए exist करते हैं ताकि एक viewer “source app” को “render engine” से tell कर सके। उनका इस्तेमाल करें।

Rule of thumb: creator आपका application name with version है (e.g. "Acme Billing Platform v7.2"); producer आपके application का brand या platform name without version है (e.g. "Acme Billing Platform")। दोनों ऐसे values होने चाहिए जिन्हें recipient recognise करे।

Empty fields, per-token defaults, downstream surprises

Ship करने से पहले जानने योग्य तीन implementation details:

Empty या whitespace-only strings को not provided treat किया जाता है. "title": "" send करना title omit करने जैसा ही है — यह PDF में empty string नहीं लिखता, यह fallback chain (token default → system default) walk करता है। सबसे common “मैंने set किया, इसने नहीं लिया” bug report का कारण यही है।
Token policies metadata fields को strip या default कर सकती हैं. gPdf इस्तेमाल करने वाला एक multi-tenant SaaS हर API token पर एक default_metadata set कर सकता है ताकि उस token द्वारा generate की गई हर PDF customer का author और producer carry करे, बिना हर developer पर भरोसा किए कि वह उन्हें हर request पर set करेगा। Token-level default “हर Acme PDF Acme कहना चाहिए” के लिए सही enforcement layer है।
Downstream pipelines आपके metadata को rewrite कर सकती हैं. वे tools जो gPdf के return करने के बाद PDFs post-process करते हैं — explicit metadata-preservation flags के बिना Ghostscript, कुछ enterprise DRM tools, कुछ “PDF optimisers” — Producer को अपने नाम से overwrite कर सकते हैं और जो branding आपने अभी set की उसे undo कर सकते हैं। अपने actual production pipeline के विरुद्ध verify करें, सिर्फ़ raw gPdf response नहीं।

अपना metadata verify करें

ऊपर के changes implement करने के बाद, PDF ने actually वही ship किया जो आप चाहते थे, यह check करने के तीन quick तरीक़े:

Command line (macOS / Linux, poppler-utils required):

$ pdfinfo your-output.pdf | head -10
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

Acrobat / Adobe Reader: File → Properties → Description tab। सभी छह fields appear होते हैं, Title viewer के title bar में सबसे ऊपर shown होता है।

macOS Preview: ⌘+I (Get Info)। “PDF” inspector pane same fields दिखाता है।

अगर कोई field empty, blank, या एक tool name के साथ show होता है जो आपने set नहीं किया, तो request body से वापस walk करें — सबसे common cause "" (empty string) send करना है, जिसे API “not provided” treat करता है और fallback chain को एक default value तक walk करता है। दूसरा most-common cause एक downstream pipeline (Ghostscript, DRM, optimiser) है जो gPdf के return करने के बाद field को overwrite कर रही है; production के विरुद्ध test करें, सिर्फ़ raw render response नहीं।

PDF/A archival में metadata

अगर आप settings.profile: "pdfa-2b" (या -2a, -3a, -3b) के साथ long-term archival के लिए render कर रहे हैं, तो metadata optional नहीं रह जाता और load-bearing बन जाता है:

एक PDF/A-conformant file में producer field empty नहीं हो सकता — कम-से-कम system default ship होता है।
language accessibility profiles (PDF/A-2a, PDF/A-3a) के लिए required है। इसके बिना, veraPDF validation outright fail करता है।
PDF/A जो XMP metadata stream require करता है वह ऊपर के छह fields से automatically generate होता है; आपको ख़ुद construct करने की ज़रूरत नहीं है।
title, author, subject, creator, producer और language सभी XMP stream में ride करते हैं, ताकि एक downstream archive का metadata indexer (Preservica, Archivematica) document body को re-parse किए बिना उनसे अपना catalog build कर सके।

एक archival document के लिए, branded metadata सिर्फ़ brand polish नहीं है — यह artefact की durability का हिस्सा है। German customs office, Brazilian tax authority, या कोई भी long-term archive जो आपका PDF दस साल में खोलेगा, वह देखेगा जो उन fields में था जिस दिन आपने render किया। उन्हें render time पर deliberately set करना ही एकमात्र मौक़ा है जो आपको मिलता है।

gPdf अभी क्या expose नहीं करता

आज के surface के बारे में honest रहने के लिए: PDF spec Keywords (free-form search terms) और एक XMP metadata stream भी define करता है जो arbitrary custom key-value pairs support करता है। gPdf current API में इनमें से किसी को भी expose नहीं करता।

अगर आपको PDF के अंदर arbitrary business data stash करनी है (order UUID, warehouse code, template version), तो आज के workarounds:

subject को एक structured short string पर set करें जिसे downstream systems parse करते हैं।
Business data को अपनी own database में रखें, filename या content hash से keyed।
Wait — XMP custom fields roadmap पर हैं, और जब वे ship करेंगे तो hidden machine-readable workflow context के लिए सही answer होंगे।

“Branded metadata” (छह standard fields, अभी available) को “custom business metadata” (XMP custom fields, future) के साथ conflate करना आज जो possible है उसे over-promise करने का सबसे आसान तरीक़ा है। अपनी planning में इन्हें अलग रखना worthwhile है।

एक complete example

एक SaaS billing platform (Acme Billing Platform) जो एक German customer (Müller Versand GmbH) के लिए एक invoice generate कर रही है, PDF/A के रूप में archive होने के लिए ready:

{
  "settings": {
    "profile": "pdfa-3b",
    "metadata": {
      "title":    "Rechnung RE-2026-0412",
      "language": "de",
      "author":   "Müller Versand GmbH",
      "subject":  "Monatsrechnung — März 2026",
      "creator":  "Acme Billing Platform v7.2",
      "producer": "Acme Billing Platform"
    }
  }
}

resulting PDF पर pdfinfo:

$ pdfinfo invoice-2026-0412.pdf | head -10
Title:           Rechnung RE-2026-0412
Subject:         Monatsrechnung — März 2026
Author:          Müller Versand GmbH
Creator:         Acme Billing Platform v7.2
Producer:        Acme Billing Platform
Language:        de

Title German में, author Müller Versand के रूप में (customer की GmbH entity, document का recipient), creator Acme Billing Platform के रूप में (editorial system जिसने decide किया page पर क्या रखना है), producer Acme Billing Platform के brand के रूप में, language German screen reader के लिए और German full-text indexer के लिए सही tag, जो बाद में इसे Müller के DMS में pick करेगा। PDF/A-3b profile का मतलब है कि यह metadata set भी long-term archival के लिए XMP stream में serialise हो जाता है।

file properties में कुछ भी gPdf, Chromium, या कोई tool नाम नहीं लेता जो customer ने नहीं चुना। यही exactly point है।

सबसे छोटा संभव 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 भर दें।

यह कहाँ आता है

§4.14.2 Metadata — इन fields के लिए API reference।
PDF white-labelling (companion post) — why और B2B SaaS case।
PDF/A and Factur-X explained for engineers — relevant अगर आपकी metadata story में long-term archival है।

title — document क्या है

language — accessibility, search और compliance के लिए

author — document का मालिक कौन है

subject — यह कौनसा type का document है

creator vs producer — सबसे ज़्यादा confuse होने वाला जोड़ा

Empty fields, per-token defaults, downstream surprises

अपना metadata verify करें

PDF/A archival में metadata

gPdf अभी क्या expose नहीं करता

एक complete example

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

यह कहाँ आता है

`title` — document क्या है

`language` — accessibility, search और compliance के लिए

`author` — document का मालिक कौन है

`subject` — यह कौनसा type का document है

`creator` vs `producer` — सबसे ज़्यादा confuse होने वाला जोड़ा