Ürün PDF SDK gerektiriyorsa iText mükemmeldir
iText olgun bir PDF SDK’dır. Bu önemlidir. Ürününüz mevcut PDF’leri manipüle ediyor, belge imzalıyor, form dolduruyor, dosya birleştiriyor, niş PDF workflow’ları uyguluyor veya düşük seviye PDF objeleri üzerinde derin Java/.NET kontrolü istiyorsa iText çoğu zaman doğru sahiplik seviyesidir.
Lojistik ekipleri için ürün sorusu farklıdır: PDF SDK mı gerekiyor, yoksa her gün güvenilir şekilde üretilen etiketler, faturalar, makbuzlar ve operasyonel belgeler mi? Yapılandırılmış belge üretiminde library satın almak veya benimsemek yalnızca ilk kalemdir. Etrafındaki servisi hâlâ siz kurarsınız.
Aynı belge ailesi, farklı ürün sınırı
iText ile uygulama SDK entegrasyonunu sahiplenir. Bu genellikle Java veya .NET servisleri, font setup’ı, barkod yapılandırması, PDF/A ayarları, deployment, monitoring, capacity planning ve render hataları için on-call yolu demektir.
gPdf ile uygulama HTTPS üzerinden JSON veya template_id + data gönderir. Renderer, edge deployment, bundled fontlar, barkod primitive’leri, parola korumalı output, metadata kontrolleri, PDF/A profilleri, Factur-X/ZUGFeRD packaging ve görsel tasarım akışı servis sınırının parçasıdır.
Ürün uyumu: düşük seviye PDF kontrolü vs üretilen iş belgeleri
PDF katmanı ürünün çekirdeğiyse iText seçin: legal-tech arşivleri, e-signature platformları, doküman yönetim sistemleri, PDF repair/manipulation tool’ları veya harici API çağıramayan embedded Java/.NET sistemleri.
Ürününüz PDF editor değilse gPdf seçin. Lojistik, ecommerce, ERP, fintech, ticketing ve back-office sistemleri genellikle structured data’dan öngörülebilir PDF ister. Bu durumlarda en iyi ürün çoğu zaman en programlanabilir SDK değil, veriden tamamlanmış belgeye giden en kısa güvenilir yoldur.
Geliştirme süresi: SDK implementasyonu vs API şablonu
“Zebra ZT411 üzerinde gerçekten scan eden thermal etiket’a sıfırdan ulaşma” için tipik ölçüm:
iText yolu — Java; sadeleştirilmiş örnek. Gerçek kod build setup, font registration, scan-rate test harness ve bunu çalıştıran CI pipeline ekler:
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();Tipik ilk başarı süresi: 2–5 mühendislik günü.
gPdf yolu — herhangi bir dil; aşağıdaki örnek 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.pdfTipik ilk başarı süresi: yaklaşık 5 dakika, JSON örneğini okumak ve PDF’i aynı Zebra ZT411’de print etmek dahil.
Fark mühendislik yeteneği değildir. Ürün sınırının nerede durduğudur. iText ile ekip etiket servisini kurar. gPdf ile etiket servisi çağırdığınız üründür.
Studio ve şablon değişiklikleri
Lojistik, belge spec’inin ekip dışından değiştiği alanlardan biridir. UPS SSCC encoding rule değiştirir. SF Express check digit ekler. FedEx yeni HAZMAT block layout yayınlar. Seçtiğiniz render stack bu değişikliği absorbe etmelidir.
iText ile: geliştirici carrier bulletin okur, Java/.NET kodunu değiştirir, unit ve integration testleri çalıştırır, servisi build eder, staging’e deploy eder, production’a deploy eder ve region’lar boyunca rollout yapar. Rollout penceresinde depolar hâlâ eski formatı basabilir.
gPdf ile: şablon JSON’unu kodda değiştirin veya gPdf Studio ile eleman ekleyip sürükleyerek layout’u görsel olarak ayarlayın. Renderer hareket etmez; yalnızca şablon değişir. Carrier değişikliği gPdf’in zaten desteklediği barkod formatındaysa production integration template_id + data olarak kalabilir.
Fiyat modeli: lisans yolu vs altyapı tarzı sayfa fiyatı
iText fiyatlandırma kararı yalnızca “library maliyeti” değildir. iText AGPL yolu ve ticari lisans yolları yayınlar. AGPL yolu uyumlu open-source kullanım için ücretsiz olabilir, ancak source-disclosure yükümlülükleri taşır. Ticari lisans ekipleri bu AGPL kısıtlarından çıkarır; iText subscription ve OEM seçeneklerini teklife bağlı veya volume-based olarak açıklar.
gPdf üretim servisini doğrudan fiyatlar. Public liste fiyatı Basic’te 100.000 sayfa için 5 ABD doları/ay’dan başlar; fiyatlandırma sayfası ve machine-readable fiyatlandırma endpoint’leri aynı yayınlanmış sayfa hesabını kullanır.
Lojistik ekiplerinin en sık sorduğu volume’ler:
| Aylık volume | gPdf liste fiyatı | 1.000 etiket başına efektif |
|---|---|---|
| 100.000 etiket | 5 ABD doları | 0,050 ABD doları |
| 1 milyon etiket | Public sayfa hesabıyla 50 ABD doları | 0,050 ABD doları |
| 10 milyon etiket | Public sayfa hesabıyla 500 ABD doları | 0,050 ABD doları |
| 100 milyon+ etiket | Enterprise fiyatlandırma için iletişime geçin | — |
Liste fiyatı kolonu kolay kısımdır. Zor olan faturanın geri kalanıdır: lisans/uyumluluk yolu, servis runtime’ı, HA footprint, mühendislik saatleri, regional deployment, carrier-spec bakımı ve support.
Tam TCO breakdown — volume tier başına engineer-month tahminleri, altyapı maliyet aralıkları ve SDK tabanlı servisin volume arttıkça operasyon maliyetini nasıl emdiği — uzun analizde:
→ Gönderi etiketi TCO: 100.000 -> 100 milyon sayfa/ay ölçeğinde iText vs gPdf
Edge’de üretim ve operasyon maliyeti
iText in-process son derece hızlı olabilir. Operasyon maliyeti renderer’ın nerede yaşadığıdır. Avrupa’daki depo tek bir ABD region’ındaki etiket servisini çağırıyorsa etiket render JVM içinde hızlı olabilir ama kullanıcı açısından hâlâ yavaş hissedilir. Multi-region deployment bunu düzeltir; ancak ekip her region’da deployment, monitoring, kapasite ve rollout’u sahiplenir.
gPdf üretim servisini Cloudflare edge’e taşır. Etiket ve fatura workload’larında ürün değeri yalnızca p50 render süresi değildir; her depo, carrier entegrasyonu veya regional backend yanında PDF servisi çalıştırma ihtiyacını kaldırmaktır.
Uyumluluk ve belge kalitesi maliyeti
iText derin PDF capability’lerine sahiptir; gPdf’in yerine geçmeye çalışmadığı workflow’lar da buna dahildir. Bu yüzden düşük seviye kontrol isteyen ekipler için iText güçlüdür.
İş belgesi üretimi için gPdf yaygın output gereksinimlerini ürünleştirir: CJK fontları, vektör barkodlar, PDF/A profilleri, Factur-X/ZUGFeRD packaging, metadata, parola korumalı output ve şablon odaklı üretim. Maliyet karşılaştırması, ekibinizin bunların ne kadarını kendi servisi içinde birleştirip test etmek istediğini içermelidir.
iText ne zaman hâlâ doğru cevaptır
Rakibin hiç kazanmadığını varsayan karşılaştırma pazarlama metnidir. iText aşağıdaki durumlarda daha iyi seçim olarak kalır:
- PDF’leri manipüle ediyorsunuz, sadece render etmiyorsunuz. İmzalama, form doldurma, bölme, page-level edit — gPdf JSON’dan yeni PDF render eder ve bu workflow’ların dışında kalır.
- Stack Java/.NET first. Services JVM üzerinde çalışıyorsa ve outbound HTTP dependency regression gibi görünüyorsa iText her şeyi in-process tutar.
- Air-gapped veya tamamen offline çalışıyorsunuz. Outbound HTTPS bazı depo sahası veya kamu deployment’ları için yanlış şekildir. iText JVM çalışan her yerde çalışır.
- PDF tooling ürününüzdür. PDF vendor, e-signature platform veya legal-tech arşiviyseniz SDK’ye sahip olmak doğru kontrol seviyesidir.
- Niche PDF spec coverage gerekiyor: XFA forms, advanced digital-signature handlers, attestation profiles.
“Paket üzerinde taranabilir etiket gerekiyor ve ayda bir milyon paketim var” için gPdf daha düşük sürtünmeli yoldur. “Java backend içinde mevcut bir legal PDF’i manipüle etmem gerekiyor” için cevap iText’tir.
İlgili PDF üretim senaryoları
iText’i operasyonel belgeler için değerlendiriyorsanız kargo etiketi API, PDF içinde GS1 barkod, JSON to PDF API, PDF/A API, Factur-X API ve ZUGFeRD PDF sayfaları da aynı kararın parçasıdır.
FAQ
iText ücretsiz mi?
iText uyumlu open-source kullanım için AGPL yolu, AGPL yükümlülüklerine uymayan veya uymak istemeyen ekipler için ticari lisans sunar.
gPdf iText’in yerine geçer mi?
Hayır. gPdf yapılandırılmış yeni belgeler için PDF üretim servisidir. iText derin PDF işleme, imzalama, form doldurma, bölme ve düşük seviye SDK kontrolü için daha güçlü kalır.
iText fiyatlandırma teklife bağlı ise neden price karşılaştırılıyor?
Çünkü alıcılar hâlâ TCO modeline ihtiyaç duyar. Karşılaştırma yalnızca SDK satır kalemini değil lisans/uyumluluk yolunu, altyapıyı, mühendislik zamanını, support’u ve bölgesel operasyonları içermelidir.
Geçiş şekli
Etiket render’ını iText’ten gPdf’e taşıyan ekipler için diff kabaca şöyledir:
- // 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());Geçiş tamamlandığında Java etiket servisi, order orchestration yapan herhangi bir dilden tek bir fetch call’a iner. JVM etiket yolundan çıkar; carrier-spec değişiklikleri deployment event’i olmaktan çıkar; on-call rotasyonu etiket-render OOM’ları için page almayı bırakır.
Ayrıca bakın
- Gönderi etiketi TCO: 100.000 -> 100 milyon sayfa/ay ölçeğinde iText vs gPdf — uzun maliyet hesabı, engineer-month tahminleri, altyapı aralıkları.
- Kargo etiketi API — payload örnekleri, p99 sayıları, Black Friday hesabı.
- JSON Render API referansı — endpoint’ler, request shape, security model.
- PDF içinde GS1 barkod — label odaklı barkod boyutlandırma detayları.