Product-এর সত্যিই PDF SDK দরকার হলে iText চমৎকার
iText একটি mature PDF SDK। Product যদি existing PDF manipulate করে, document sign করে, form fill করে, file merge করে, niche PDF কাজের ধারা implement করে, বা low-level PDF object-এ Java/.NET control চায়, iText প্রায়ই সঠিক ownership level।
Logistics team-এর প্রশ্ন আলাদা: আপনার PDF SDK দরকার, নাকি প্রতিদিন reliable label, invoice, receipt এবং operational document generate করা দরকার? Structured document generation-এ library নেওয়া শুধু প্রথম line item। Service আপনাকেই বানাতে হয়।
একই document family, কিন্তু পণ্যসীমা আলাদা
iText-এ application SDK integration own করে: Java বা .NET service, font setup, barcode configuration, PDF/A setting, deployment, monitoring, capacity planning এবং render failure-এর on-call path।
gPdf-এ application HTTPS-এ JSON বা template_id + data পাঠায়। Renderer, edge deployment, bundled font, barcode primitive, password-protected output, metadata control, PDF/A profile, Factur-X/ZUGFeRD packaging এবং visual design কাজের ধারা service boundary-এর অংশ।
কোন কাজে মানায়: low-level PDF control বনাম generated business document
PDF layer product-এর core হলে iText বেছে নিন: legal-tech archive, e-signature platform, document management system, PDF repair/manipulation tool, বা external API call করতে পারে না এমন embedded Java/.NET system।
Product যদি PDF editor না হয়, gPdf বেছে নিন। Logistics, ecommerce, ERP, fintech, ticketing এবং back-office system সাধারণত structured data থেকে predictable PDF চায়। তখন best product সবচেয়ে programmable SDK নয়; data থেকে finished document-এর shortest reliable path।
ডেভেলপমেন্ট সময়: SDK implementation বনাম API template
“Zero থেকে Zebra ZT411-এ clean scan হওয়া thermal label” path:
iText path — Java; real code build setup, font registration, scan-rate test harness এবং CI pipeline যোগ করে:
PdfWriter writer = new PdfWriter("label.pdf");
PdfDocument pdf = new PdfDocument(writer);
PageSize labelSize = new PageSize(288, 432); // 4×6 in @ 72 dpi
Document doc = new Document(pdf, labelSize);
// Address block, sender block, carton ID, service code…
// (15–25 more lines positioning text and configuring Barcode128 with
// GS1 Application Identifiers, fonts, FNC1 framing, then a JUnit test
// that loads the PDF and validates the barcode renders at 203 dpi)
Barcode128 code = new Barcode128(pdf);
code.setCode("(01)00012345678905(21)SN12345");
code.setCodeType(Barcode128.CODE128);
// … position, sizing, human-readable interpretation line …
doc.close();Typical first-success time: ২–৫ engineering day।
gPdf path — যে কোনো language; নিচে curl:
curl -X POST https://api.gpdf.com/api/v1/pdf/render \
-H "Authorization: Bearer $GPDF_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"pages": [{
"size": "label_4_6_in",
"elements": [
{ "type": "text", "x": 4, "y": 12,
"content": "Acme Distribution Centre\n1200 Logistics Pkwy\nMemphis TN 38116" },
{ "type": "barcode", "format": "gs1_128",
"content": "(01)00012345678905(21)SN12345",
"x": 4, "y": 60, "width": 92, "height": 22,
"barcode_text": { "enabled": true, "position": "bottom" }
}
]
}]
}' -o label.pdfTypical first-success time: প্রায় ৫ মিনিট, JSON sample পড়া এবং একই Zebra ZT411-এ PDF print করা সহ।
ফারাক engineering talent নয়। Product boundary কোথায় বসে সেটাই পার্থক্য। iText-এ team label service বানায়। gPdf-এ label service হলো product যা আপনি call করেন।
Studio এবং template changes
Logistics-এ document spec প্রায়ই আপনার team-এর বাইরে থেকে বদলায়। UPS SSCC encoding rule revise করতে পারে, SF Express check digit যোগ করতে পারে, FedEx নতুন HAZMAT block layout দিতে পারে। Rendering stack-কে এসব absorb করতে হবে।
iText-এর সঙ্গে developer carrier bulletin পড়ে Java/.NET code বদলায়, test চালায়, service build করে, staging ও production deploy করে, তারপর region ধরে rollout করে।
gPdf-এর সঙ্গে template JSON code-এ edit করুন বা gPdf Studio-তে element add/drag করে visually layout adjust করুন। Renderer move করে না; template বদলায়। Carrier change supported barcode format হলে production integration template_id + data থাকতে পারে।
দামের মডেল: license path বনাম infrastructure-style page pricing
iText pricing decision শুধু library cost নয়। iText AGPL path ও commercial licensing path publish করে। AGPL compatible open-source use-এ no-cost হতে পারে, কিন্তু source-disclosure obligation আনে। Commercial licensing সেই constraint সরায়; subscription/OEM option quote-based বা volume-based হতে পারে।
gPdf generation service সরাসরি price করে। Public list price Basic-এ ১,০০,০০০ পৃষ্ঠার জন্য ৫ ডলার/মাস, এবং একই per-page math pricing page ও machine-readable pricing endpoint-এ ব্যবহৃত।
Common logistics volume:
| Monthly volume | gPdf list price | Effective per-1K labels |
|---|---|---|
| ১,০০,০০০ লেবেল | ৫ ডলার | ০.০৫০ ডলার |
| ১০ লক্ষ লেবেল | public per-page math অনুযায়ী ৫০ ডলার | ০.০৫০ ডলার |
| ১ কোটি লেবেল | public per-page math অনুযায়ী ৫০০ ডলার | ০.০৫০ ডলার |
| ১০ কোটি+ labels | Contact for enterprise pricing | — |
List-price সহজ অংশ। কঠিন অংশ বাকি bill: license/compliance path, service runtime, HA footprint, engineering hour, regional deployment, carrier-spec maintenance ও support।
Full TCO breakdown:
→ Shipping label TCO: iText vs gPdf at ১,০০,০০০ → ১০ কোটি পৃষ্ঠা/মাস
Edge generation ও operations cost
iText in-process খুব fast হতে পারে। Operational cost হলো renderer কোথায় থাকে। Europe warehouse যদি US region-এর label service call করে, JVM render fast হলেও user perspective-এ path slow। Multi-region deployment fix করে, কিন্তু deployment, monitoring, capacity ও rollout প্রত্যেক region-এ আপনার দায়িত্ব।
gPdf generation service-কে Cloudflare edge-এ সরায়। Label ও invoice workload-এ value শুধু p50 render time নয়; প্রতিটি warehouse, carrier integration বা regional backend-এর পাশে PDF service চালানোর দরকার সরানো।
Compliance ও document-quality cost
iText-এর deep PDF capability আছে, এমন কাজের ধারাসহ যা gPdf replace করতে চায় না। তাই low-level control দরকার হলে iText strong।
Business-document generation-এ gPdf common output requirement productize করে: CJK font, vector barcode, PDF/A profile, Factur-X/ZUGFeRD packaging, metadata, password-protected output এবং template-driven generation। Cost comparison-এ এগুলোর কতটা আপনার team নিজস্ব service-এ assemble ও test করতে চায়, তা থাকা উচিত।
কখন iText এখনো সঠিক উত্তর
সৎ comparison-এ competitor-ও জেতে। iText ভালো pick যখন:
- আপনি PDF manipulate করেন, শুধু render নয়। Signing, form filling, splitting, page-level edit — gPdf JSON থেকে নতুন PDF render করে।
- Stack Java/.NET first. বাকি service JVM-এ চললে outbound HTTP dependency regression লাগতে পারে।
- Air-gapped বা strictly offline run করেন। কিছু warehouse-floor বা government deployment-এ outbound HTTPS ভুল shape।
- PDF tooling আপনার product. PDF vendor, e-signature platform বা legal-tech archive-এর জন্য SDK own করা সঠিক control level।
- Niche PDF spec coverage দরকার যেমন XFA form, advanced digital-signature handler বা attestation profile।
“Parcel-এ scannable label দরকার এবং মাসে ১০ লক্ষ parcel” হলে gPdf lower-friction path। “Java backend-এ existing legal PDF manipulate করতে হবে” হলে iText।
সংশ্লিষ্ট PDF generation scenario
iText ও gPdf তুলনা করলে প্রশ্নটি সাধারণত SDK বনাম service। যদি লক্ষ্য হয় shipping label PDF generation, GS1 barcode PDF বা JSON to PDF API দিয়ে operational document বানানো, gPdf সরাসরি পথ। আর compliance-heavy output হলে PDF/A API, Factur-X API ও ZUGFeRD API একসঙ্গে দেখুন। Existing PDF signing, splitting বা deep editing দরকার হলে iText-এর SDK boundary এখনো শক্তিশালী।
FAQ
iText কি free?
iText compatible open-source use-এর জন্য AGPL path দেয় এবং AGPL obligation মানতে না পারা বা না চাওয়া team-এর জন্য commercial licensing দেয়।
gPdf কি iText replace করে?
না। gPdf structured new document-এর জন্য PDF generation service। Deep PDF manipulation, signing, form filling, splitting ও low-level SDK control-এ iText stronger।
iText pricing quote-based হলে price compare কেন?
Buyer-এর TCO model দরকার। Comparison-এ license/compliance path, infrastructure, engineering time, support ও regional operation থাকা উচিত, শুধু SDK line item নয়।
মাইগ্রেশনের রূপ
iText থেকে label rendering gPdf-এ আনলে diff roughly এমন:
- // Before: a Java label-rendering service
- PdfWriter writer = new PdfWriter(out);
- PdfDocument pdf = new PdfDocument(writer);
- Document doc = new Document(pdf, new PageSize(288, 432));
- // 20–40 lines wiring fonts, positions, Barcode128 with GS1 AIs
- doc.close();
+ // After: HTTPS POST the structured DocumentRequest from any language
+ const res = await fetch('https://api.gpdf.com/api/v1/pdf/render', {
+ method: 'POST',
+ headers: { Authorization: `Bearer ${KEY}`, 'Content-Type': 'application/json' },
+ body: JSON.stringify(labelDocumentRequest),
+ });
+ const pdf = Buffer.from(await res.arrayBuffer());Cut হয়ে গেলে Java label service order orchestration language থেকে single fetch call হয়ে যায়। JVM label path থেকে সরে যায়; carrier-spec change deploy event থাকে না; on-call rotation label-rendering OOM নিয়ে কম page পায়।
আরও পড়ুন
- Shipping label TCO: iText vs gPdf at ১,০০,০০০ → ১০ কোটি পৃষ্ঠা/মাস — long-form cost math, engineer-months, infra ranges.
- Shipping label API — sample payload, p99 number, Black Friday math.
- JSON Render API reference — endpoint, request shape, security model.
- GS1 barcode API — GS1 format, barcode size এবং PDF-এ human-readable line.