PDF properties-এ আপনার brand দেখানো উচিত, অন্য কারো tool নয়-এর সহচর — সেই পোস্ট PDF metadata-এর পরোয়া করার case তৈরি করেছিল। এটি operating manual: PDF specification-এ প্রতিটি field কীসের জন্য, কে পড়ে, common mistakes, এবং কীভাবে verify করবেন যে আপনার output আসলে যা আপনি ইচ্ছা করেছিলেন তা ship করেছে।

gPdf ছয়টি standard field 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-এর বাকিটা per field একটি section। প্রতিটি 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 সবাই এটি দেখায়)।
যখন PDF inline খোলে তখন browser tab (Content-Disposition: inline)।
Search indexes — Spotlight, Outlook, SharePoint, Google Drive-এর 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 পেজের H1-এর সাথে match করা উচিত। যদি আপনার invoice template-এর শীর্ষ 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 করুন। ছয়টি field-এর মধ্যে এর সবচেয়ে concrete downstream consequences এবং সবচেয়ে ছোট implementation cost আছে — এজন্য এটি নীচে চাপা পড়ার পরিবর্তে position 2-এ বসে।

কোথায় surface হয়:

Screen readers — JAWS, NVDA, VoiceOver সঠিক phoneme set বাছাই করতে এটি ব্যবহার করে। একটি English screen reader language: "de" PDF পড়ে German শব্দগুলি সঠিক উচ্চারণ করবে; tag ছাড়া এটি prosody ভুল করে।
Search engines এবং indexers — কোন locale-এর stemming এবং stopword list apply হবে তা affect করে। একটি language: "zh-Hans" invoice Chinese segmentation-এ indexed হয়; missing tag প্রায়ই English-এ default হয় এবং 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-এর 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-এর 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, prominently “Author” labelled।
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)” দেখায়, যা “এর কোনো মালিক নেই” হিসেবে পড়া হয়।

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-এর name নয়। (Platform-এর name creator-এ belongs করে — নীচে দেখুন।) Consultancy / publishing / legal contexts-এর জন্য যেখানে individuals brand, individuals ঠিক আছে।

`subject` — এটি কী ধরনের 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 যে প্রতিটি invoice generate করে তার exactly "subject": "Invoice" থাকা উচিত।

`creator` vs `producer` — সবচেয়ে বেশি confuse হওয়া জুটি

এখানেই বেশিরভাগ team PDF spec পড়া বন্ধ করে guess করে। Spec precise; দুটি field আলাদা জিনিস 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-এ উভয় field non-empty হতে হবে)।

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 হিসেবে রেখে দেওয়া. বেশিরভাগ team এটি কখনও override করে না, তাই প্রতিটি PDF “Skia/PDF m120” বা “wkhtmltopdf” বলে — B2B-এর জন্য কেন এটি গুরুত্বপূর্ণ তা দেখতে white-label post দেখুন।
❌ উভয়ে একই value রাখা. Acceptable কিন্তু wasteful — দুটি field ঠিক এজন্য 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": "" পাঠানো 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 করতে পারে. gPdf return করার পরে PDFs post-process করে এমন tools — explicit metadata-preservation flags ছাড়া Ghostscript, কিছু enterprise DRM tools, কিছু “PDF optimisers” — Producer-কে তাদের নিজের name-এ overwrite করতে পারে এবং আপনি সবেমাত্র যে branding set করেছেন তা undo করতে পারে। আপনার actual production pipeline-এর বিরুদ্ধে verify করুন, শুধু raw gPdf response নয়।

আপনার metadata verify করুন

উপরের changes implement করার পরে, PDF আসলে যা আপনি intended করেছিলেন তা ship করেছে কিনা তা check করার তিনটি quick উপায়:

Command line (macOS / Linux, poppler-utils দরকার):

$ 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। সব ছয়টি field appear হয়, Title viewer-এর title bar-এ শীর্ষে দেখানো হয়।

macOS Preview: ⌘+I (Get Info)। “PDF” inspector pane একই fields দেখায়।

যদি কোনো field empty, blank, বা আপনি set করেননি এমন একটি tool name নিয়ে show হয়, request body-তে back walk করুন — সবচেয়ে common cause "" (empty string) পাঠানো, যাকে 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 করে তা উপরের ছয়টি field থেকে 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 আপনার নিজের database-এ রাখুন, filename বা content hash দ্বারা keyed।
Wait — XMP custom fields roadmap-এ আছে, এবং যখন তারা ship হবে তখন hidden machine-readable workflow context-এর জন্য সঠিক answer হবে।

“Branded metadata” (ছয়টি standard field, এখন available)-কে “custom business metadata” (XMP custom fields, future)-এর সাথে conflate করা আজ যা possible তা over-promise করার সবচেয়ে সহজ উপায়। নিজের planning-এ এদের আলাদা রাখা উপকারী।

একটি 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-এর জন্য tagged যা পরে Müller-এর DMS-এ এটি pick up করবে। PDF/A-3b profile মানে এই metadata set-ও long-term archival-এর জন্য XMP stream-এ serialise হয়।

file properties-এ কিছুই gPdf, Chromium, বা customer বাছাই করেনি এমন কোনো tool নাম করে না। এটিই exactly point।

সবচেয়ে ছোট সম্ভাব্য upgrade

যদি আপনি ইতিমধ্যে /api/v1/pdf/render-এ POST করছেন এবং আপনার current call-এ settings.metadata নেই, সবচেয়ে ছোট improvement হলো আপনি ইতিমধ্যে যে JSON পাঠাচ্ছেন তাতে তিনটি line যোগ করা:

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

দুটি field, একটি new key। সেকেন্ডের মধ্যে pdfinfo দিয়ে verifiable। একবার এগুলি land করলে, সময় হলে title, language, subject এবং creator পূরণ করুন।

এটি কোথায় land করে

§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 — এটি কী ধরনের document

creator vs producer — সবচেয়ে বেশি confuse হওয়া জুটি

Empty fields, per-token defaults, downstream surprises

আপনার metadata verify করুন

PDF/A archival-এ metadata

gPdf এখনও কী expose করে না

একটি complete example

সবচেয়ে ছোট সম্ভাব্য upgrade

এটি কোথায় land করে

`title` — document কী

`language` — accessibility, search এবং compliance-এর জন্য

`author` — document-এর মালিক কে

`subject` — এটি কী ধরনের document

`creator` vs `producer` — সবচেয়ে বেশি confuse হওয়া জুটি