PDF properties-এ আপনার brand দেখানো উচিত, অন্য কারো tool নয়

যেকোনো business-critical PDF খুলুন — একটি invoice, একটি shipping label, একটি monthly statement — এবং document properties দেখুন (macOS Preview-এ Cmd+D, Adobe Reader-এ Ctrl+D, বেশিরভাগ desktop viewer-এ “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:

উপরের পেজটি SaaS vendor-এর brand-এর মতো দেখায়। file properties একটি browser engine-এর নাম বলছে যার vendor-এর সাথে বা যে customer-এর পক্ষ থেকে SaaS document ship করছে তার সাথে কোনো সম্পর্ক নেই।

এই পোস্ট সেই gap সম্পর্কেই।

পেজ branded, file নয়

White-label PDF generation B2B SaaS-এর জন্য একটি সুপরিচিত requirement। vendor customer-কে logo upload করতে, brand colours বাছতে, template configure করতে দেয়; export করা PDF visually customer-এর brand-এর মতো দেখায়, vendor-এর নয়।

বেশিরভাগ platform সেখানেই থামে। তারা visible layer-টি solve করে এবং file-properties layer একা ছেড়ে দেয়। ফলাফল: একটি document যা প্রতিটি পেজে “Acme Logistics” বলে কিন্তু কেউ right-click → Properties করার মুহূর্তে নিজেকে “Skia/PDF m120” হিসেবে identify করে।

একটি 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 যার পেজে “Acme” এবং যার Producer field-এ “Chromium” বলা হয়, এই systems-এ “Acme নামের কারো জন্য Chromium দ্বারা rendered” হিসেবে পড়া হয় — “Acme দ্বারা rendered” নয়। Enterprise procurement এবং compliance-এর জন্য, এই পার্থক্য নজরে আসে।

কেন এটি SaaS vendor-এর জন্য direct users-এর চেয়ে খারাপ

যদি আপনি নিজের জন্য একটি PDF generate করেন, Producer field-এ “Chromium” শুধু আপনার সমস্যা।

যদি আপনি একটি SaaS vendor হন এবং আপনার customer-রা আপনার platform-এর মাধ্যমে PDF generate করেন, chain দীর্ঘতর:

• আপনি rendering stack বাছলেন।
• আপনার customer resulting PDF তাদের customer-কে ship করছেন।
• final recipient — একটি procurement team, একটি carrier, একটি tax office, একটি finance department — একটি Producer field দেখেন যা আপনাকেও নাম করে না, আপনার customer-কেও না। এটি সেই upstream renderer-এর নাম করে যা আপনি ব্যবহার করছেন।

পেজে আপনার customer-এর brand; file-এ একটি অপরিচিত tool-এর নাম। recipient-এর দৃষ্টিকোণ থেকে document একটু অদ্ভুত লাগে যা তারা ঠিক নাম দিতে পারে না। আপনার customer-এর দৃষ্টিকোণ থেকে, white-label-এর প্রতিশ্রুতি পুরোপুরি পালন হলো না।

এই অংশটিতেই বেশিরভাগ platform কম invest করে, কারণ fix homepage থেকে দেখা যায় না। কিন্তু যে customer আপনার “white-label PDF” feature-এর output-এ একটি pdfinfo চালাবেন, তিনি লক্ষ্য করবেন।

এটি আসলে কখন কামড়ায়

এগুলি সেই পরিস্থিতি যেখানে Producer field একটি hypothetical নয়, real operational issue হিসেবে দেখা দিয়েছে:

• Vendor security questionnaires. Enterprise procurement একটি vendor risk review চালায় এবং জিজ্ঞাসা করে: “আমাদের কাছে আপনি যে document outputs ship করেন তাতে appear করা প্রতিটি third-party tool list করুন।” 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 author দ্বারা PDFs 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 team brand-governance-এর অংশ হিসেবে outbound document attribution audit করে। যে document brand team কখনও শোনেনি এমন একটি tool-এর কাছে attributed হয়, তা একটি finding হয়ে ওঠে।

এর কোনোটিই critical incident নয়। এগুলি paper cuts যা enterprise sales, vendor onboarding এবং operations-এ friction যোগ করে। এগুলি মাসে হাজার হাজার document জুড়ে compound হয়।

file properties আসলে কী expose করে

PDF specification ছয়টি standard metadata field সংরক্ষণ করে যা প্রায় প্রতিটি 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 পূরণ করা কঠিন নয়। default-এ leak হওয়ার কারণ হলো rendering library Producer-এ তার নিজস্ব নাম লেখে (সঠিক — field এর জন্যই আছে), এবং বেশিরভাগ application code বাকি পাঁচটি কখনও set করে না।

Fix হলো সেগুলি set করা — deliberately, প্রতিটি render-এ, সেই application থেকে যা জানে document কিসের জন্য।

“branded metadata” practice-এ কেমন দেখায়

এই হলো একই metadata block যেমন gPdf produce করে। ছয়টি field, সবগুলি caller দ্বারা overridable:

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

পেজ “Acme Logistics” হিসেবে render হয় — এবং file properties-ও “Acme Logistics” বলে। right-click → Properties একটি সম্পূর্ণ Acme-এর অধিকারে থাকা document দেখায়। এই বাস্তব যে bytes-গুলি gPdf edge-এ ~4 ms-এ produce করেছিল, recipient যেখানে দেখে কোথাও surface হয় না।

customer-রা কি জানতে চাইবেন না যে আপনি gPdf ব্যবহার করছেন?

এই প্রশ্ন যথেষ্ট প্রায়শই আসে যে সরাসরি উত্তর দেওয়া উচিত।

হ্যাঁ — আপনার customer-রা অবশ্যই জানতে পারেন যে আপনি gPdf-এর উপরে build করছেন। এটি আপনার এবং তাদের মধ্যে, এবং সাধারণত এটি আপনার engineering blog, changelog, security architecture documents, বা sub-processor list-এ থাকে (যেখানে আপনার DPA-এর সাথে relevant হলে gPdf appear করে)।

Producer field সেই সম্পর্কের বিষয় নয়। এটি আপনার customer-এর document-এর end recipient সম্পর্কে — একটি procurement clerk, একটি carrier dispatcher, একটি tax-office form processor — যার আপনার renderer choice-এর সাথে কোনো relationship নেই এবং সেটি কী তার পরোয়া করার কোনো কারণ নেই। তাদের জন্য, Properties dialog-এ “Skia/PDF m120” হলো noise; “Acme Billing Platform” হলো signal।

এতে কিছু অসৎও নেই। 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 credit পায়।

downstream pipelines-এর উপর একটি footnote

যদি আপনার output PDF recipient-এর কাছে পৌঁছানোর আগে কোনো post-processing stage-এর মধ্য দিয়ে যায় — explicit metadata-preservation flags ছাড়া Ghostscript, একটি enterprise DRM/watermarking tool, একটি “PDF optimiser” — সেগুলির কিছু tool চুপিচুপি Producer-কে তাদের নিজের নামে rewrite করবে এবং আপনি যে branded metadata সবেমাত্র set করেছেন তা undo করবে। আপনার actual pipeline-এর বিরুদ্ধে test করুন, শুধু raw gPdf response-এর বিরুদ্ধে নয়।

যা এখানে নেই তার উপর একটি note

সঠিক থাকার জন্য: উপরের ছয়টি standard field হলো যা gPdf আজ expose করে। document properties-কে white-label করার জন্য এটি যথেষ্ট — brand-identity story সেই সম্পর্কেই।

downstream systems পড়ার জন্য PDF-এর ভিতরে arbitrary business context (order UUID, warehouse code, template version) stash করার জন্য এটি যথেষ্ট নয়। এটি একটি আলাদা, complementary capability — XMP custom metadata + arbitrary key-value pairs — যা PDF spec support করে এবং যা আমরা একটি roadmap item হিসেবে track করছি। যদি আপনার আজকে এটি প্রয়োজন হয়, ID-style data সাধারণত PDF-এর ভিতরে থাকার চেয়ে আপনার platform-এর নিজস্ব database-এ, PDF-এর filename বা একটি hash দ্বারা keyed, বেশি reliably বাঁচে। Metadata document-এর identity-এর জন্য, structured business data-কে একটি transport layer হিসেবে PDF-এর মাধ্যমে move করার জন্য নয়।

Branded metadata (আজ) ≠ hidden business-data flow (আলাদা)। নিজের planning-এ এদের আলাদা রাখা উপকারী।

সবচেয়ে ছোট সম্ভাব্য 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 পূরণ করুন।

এটি gPdf API-তে কোথায় land করে

settings.metadata-এর ভিতরে ছয়টি line। Per-token policies এই fields-গুলিকে strip বা default-ও করতে পারে যাতে একটি multi-tenant SaaS enforce করতে পারে যে তার customer-দের 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 করবেন।

দৃশ্যমান পেজ brand-এর অর্ধেক। file properties অপর অর্ধেক। যদি আপনার platform customer-দের পক্ষ থেকে PDF ship করে, উভয় অর্ধেকেরই তাদের নাম বলা উচিত।