PDF generation API चुनना आसान लगता है, जब तक आप सच में शुरू नहीं करते. करीब 40 vendors हैं, marketing pages एक जैसे सुनाई देते हैं, और असली tradeoffs production में कुछ हजार documents generate होने के बाद ही सामने आते हैं.

यह checklist आप vendor evaluation में साथ ले जा सकते हैं: vendor-agnostic, और उन real incidents से निकली हुई जो teams procurement और post-mortem में देखती हैं. आठ सवाल हैं. अगर इन सभी का साफ जवाब नहीं मिलता, तो आपके पास सही चुनाव करने के लिए पर्याप्त जानकारी नहीं है.

1. आपका input format क्या है: HTML, JSON या template DSL?

यह सबसे महत्वपूर्ण सवाल है. इसी से तय होता है कि आपकी team क्या लिखेगी और रात 2 बजे क्या debug करेगी.

HTML/CSS (Puppeteer, DocRaptor, Prince): familiar, बेहद flexible, runtime में महंगा, deterministic बनाना कठिन.
JSON / structured data (gPdf): render करना सस्ता, byte-identical, लेकिन आपके data model से document model तक छोटा mapper लिखना पड़ता है.
Template DSL (PDFKit, ReportLab, Apache PDFBox): पूरा control, पूरी जिम्मेदारी. Pagination, layout और font fallback आपको खुद लिखना होगा.

कोई universal गलत जवाब नहीं है. गलत जवाब वह है जो आपकी team के लिए गलत है. अपने engineers से पूछिए कि 3 घंटे का pagination bug वे किस model में debug करना चाहेंगे.

2. Cold-start latency क्या है, और क्या वह predictable है?

कुछ renderers microseconds में boot होते हैं: WASM या native binary वाले systems. कुछ seconds लेते हैं: Chromium-based systems. Traffic spike आने तक यह फर्क अक्सर दिखता नहीं.

Vendor से पूछने वाली बातें:

“Cold worker को पहली request मिलने पर आपकी p99 latency कितनी है?”
“मेरी last request के कितनी देर बाद worker फिर से cold माना जाता है?”
“क्या आप cold-start data वाला status page publish करते हैं?”

अगर पहले सवाल का जवाब number में नहीं है, तो मानिए कि जवाब खराब है.

3. Per-render cost कैसे model होती है?

तीन flavors हैं, और ये इसी क्रम में अक्सर नुकसान पहुंचाते हैं:

Per-page pricing (Anvil at $0.10/PDF, DocRaptor at$ 89/100K): predictable, budget बनाना आसान, scale पर महंगा.
Subscription tiers with overage (gPdf at $5-12/mo +$ 0.00005/page over): किसी भी volume पर सस्ता, लेकिन उस usage को project करना कठिन जिसे आपने अभी test नहीं किया.
Compute-based pricing (self-hosted Puppeteer on Lambda): compute bill सीधे आपकी तरफ आता है, cold-starts और Chromium memory समेत.

Sign करने से पहले तीन traffic levels पर अपना ACTUAL bill निकालिए: current, 5x और 50x. Cost curve की shape headline number से ज्यादा मायने रखती है.

4. Output deterministic है?

Determinism, यानी same input -> same bytes, academic बात लगती है जब तक आपको इसकी जरूरत न पड़ जाए.

यह तब जरूरी होता है जब:

आप CI में PDFs diff करके unintended template changes पकड़ते हैं.
आप e-invoice / tax law के तहत documents retain करते हैं; जो PDF आपने store किया और जो PDF आप re-render करते हैं, दोनों match होने चाहिए.
आप archival integrity के लिए PDF hash करते हैं.
आप legal review के लिए rendered output version-control करते हैं.

Browser-based renderers (Puppeteer और कोई भी Chromium stack) patch versions के बीच deterministic नहीं होते. Native binary renderers (Prince, gPdf) आम तौर पर होते हैं. सीधे पूछिए: “अगर आप renderer update ship करते हैं, तो क्या मेरे output bytes बदलेंगे?”

5. Renderer fonts, खासकर CJK और RTL, कैसे संभालता है?

PDF land में इस सवाल ने किसी भी दूसरे सवाल से ज्यादा careers को महंगा पड़ा है.

Failure mode लगभग हमेशा एक जैसा होता है: आप home market में launch करते हैं, fonts ठीक हैं. छह महीने बाद आप ऐसे market में जाते हैं जिसकी script के लिए renderer के पास glyphs नहीं हैं. PDF □□□□ boxes emit करने लगता है. Customer escalate करता है. आपकी team दो sprints Dockerfile में fonts जोड़ने में लगा देती है.

पूछने वाले सवाल:

“बिना extra config कौन से scripts bundled हैं? Latin, CJK, Cyrillic, Devanagari, Arabic, Hebrew?”
“Unknown glyph मिलने पर क्या होता है: fallback या tofu?”
“क्या मैं request time पर custom fonts add कर सकता हूं, या उन्हें पहले deploy करना होगा?”
“क्या आप RTL text shaping support करते हैं?”

अच्छा जवाब ऐसा होगा: “हम NotoSans CJK और Noto fallback set embed करते हैं; unknown glyphs Noto Symbols तक fall through करते हैं.” खराब जवाब है: “हाँ, fonts support करते हैं.”

6. कौन से compliance profiles supported हैं?

अगर आपका business कभी भी ये कर सकता है:

EU में invoices issue करना (Factur-X / ZUGFeRD / EN 16931, DE/FR/IT/PL में 2026 तक mandatory)
SOX, HIPAA या GDPR retention rules के तहत documents archive करना (PDF/A)
Medical records submit करना (attached XML के साथ PDF/A-3)
Digital signatures embed करना (PAdES)

…तो पूछिए कि renderer कौन से compliance profiles natively support करता है. खराब जवाब है: “बाद में दूसरा tool चला कर convert कर सकते हैं.” इसका मतलब है कि multi-step pipeline अब आपकी ownership में है.

अच्छे जवाब आम तौर पर single flag जैसे दिखते हैं. उदाहरण के लिए, gPdf settings.profile: "pdfa-3b" लेता है और standard: "factur_x" तथा embedded CII XML वाला settings.e_invoice block जोड़ता है. Built-in support bolt-on pipeline से operations में बहुत हल्का होता है.

7. Rendering stateless है? Render होने के बाद मेरे documents कहाँ जाते हैं?

ये दो जुड़े हुए सवाल हैं.

Stateless rendering का मतलब है request आती है, PDF emit होता है, और कुछ store नहीं होता. Persistence आप संभालते हैं: S3, अपनी DB, या जो भी आपका storage model है. Compliance-heavy workloads में यही चाहिए, क्योंकि renderer कभी आपके data का custodian नहीं बनता.

Stateful rendering में vendor PDF store करता है, अक्सर अपने CDN पर, और आपको signed URL देता है. Casual workflows के लिए convenient है, जैसे “customer को link भेजो”. Regulated workflows के लिए problem है, क्योंकि अब third party के पास हर rendered document की copy है.

पूछिए:

“क्या rendering default रूप से stateless है?”
“अगर आप document store करते हैं, तो वह geographically कहाँ store होता है?”
“वह कितने समय तक retained रहता है?”
“क्या compliance review के लिए मुझे stateless rendering की written guarantee मिल सकती है?”

अगर जवाब hand-wavy है, तो आपकी privacy/legal team 9 महीने बाद इसे issue बनाएगी.

8. Renderer fail हो तो क्या होता है, और मुझे कैसे पता चलता है?

हर renderer कभी न कभी fail होता है. असली सवाल हैं:

Failure surface कैसे दिखता है? Stack trace वाला 500? Structured error वाला 4xx? Empty PDF?
Retry policy क्या है? क्या वह idempotent है? Failed renders के लिए charge लगता है?
Vendor क्या instrumentation देता है? Status page? Incident webhooks? Region-wise p50/p99 dashboards?
क्या synthetic probe है? क्या vendor public endpoint के खिलाफ अपनी monitoring चलाता है, या ticket file करने के लिए आप पर निर्भर है?

एक quick test: vendor का status page अभी खोलिए. अगर वह मौजूद नहीं, real-time नहीं, या बिना detail के “all systems operational” दिखाता है, तो purchase के बाद reliability transparency भी ऐसी ही होगी.

(Reference के लिए: gPdf trailing 7 days के synthetic probe data + Cloudflare Analytics के साथ /status publish करता है.)

इन आठ सवालों पर gPdf कहाँ खड़ा है

यह हमारा blog है, इसलिए आपको लगेगा कि हमने सवाल अपने पक्ष में चुने होंगे. इसलिए हमारा honest scorecard:

#	सवाल	gPdf का जवाब
1	Input format	JSON `DocumentRequest` (structured data)
2	Cold start	5-20 ms (V8 isolate, browser नहीं)
3	Cost model	$0/$ 5/ $8/$ 12 per month; $0.00005/page overage
4	Determinism	Byte-identical, same engine version पर guaranteed
5	Fonts	NotoSans CJK + Latin fallback embedded
6	Compliance	PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD attachment built-in
7	Stateless	हाँ, contractually: कहीं भी document storage नहीं
8	Failure & visibility	7-day trend वाला public status page; structured 4xx/5xx; idempotent

जहाँ हम हारते हैं: Q1, अगर आपका input सचमुच HTML है जिसे refactor नहीं किया जा सकता, जैसे user-generated reports या legacy templates. उस case में DocRaptor या Prince सही जवाब हैं.

TL;DR

“Best PDF API कौन सा है” मत पूछिए. ये आठ सवाल पूछिए, answers score कीजिए, और वह vendor चुनिए जो आपकी actual workload से line up करता है. जिस team ने question #5 से 9 महीने बाद blindsided होकर थोड़े सस्ते rival के खिलाफ procurement lose किया, वह भी यही कहेगी.

अगर आपकी workload gPdf की बनावट से match करती है, तो Playground में 30 seconds में evaluate कर सकते हैं. अगर match नहीं करती, तो हम खुशी से आपको सही tool की ओर point करेंगे: HTML-shaped problems के लिए आम तौर पर DocRaptor, self-hosted के लिए Prince, या अगर input सचमुच arbitrary web pages हैं तो Puppeteer.