gPdf vs iText dla etykiet wysyłkowych

iText jest świetny, gdy produkt potrzebuje PDF SDK

iText to dojrzały PDF SDK. To ma znaczenie. Jeśli produkt manipuluje istniejącymi PDF-ami, podpisuje dokumenty, wypełnia formularze, scala pliki, implementuje niszowe procesy PDF albo wymaga głębokiej kontroli Java/.NET nad obiektami PDF niskiego poziomu, iText często daje właściwy poziom własności.

Dla zespołów logistycznych pytanie produktowe jest inne: czy potrzebujecie PDF SDK, czy niezawodnie generowanych etykiet wysyłkowych, faktur, paragonów i dokumentów operacyjnych każdego dnia? Przy ustrukturyzowanym generowaniu dokumentów biblioteka jest tylko pierwszą pozycją kosztu. Usługę wokół niej nadal trzeba zbudować.

Ta sama rodzina dokumentów, inna granica produktu

Z iText aplikacja posiada integrację SDK. Zwykle oznacza to usługi Java albo .NET, konfigurację fontów, konfigurację kodów kreskowych, ustawienia PDF/A, wdrożenie, monitoring, planowanie pojemności i ścieżkę dyżuru dla błędów generowania.

Z gPdf aplikacja wysyła JSON albo template_id + data przez HTTPS. Warstwa generowania, wdrożenie edge, wbudowane fonty, prymitywy kodów kreskowych, wyjście chronione hasłem, kontrola metadanych, profile PDF/A, pakietowanie Factur-X/ZUGFeRD i wizualny proces projektowania należą do granicy usługi.

Dopasowanie produktu: kontrola PDF niskiego poziomu vs generowane dokumenty biznesowe

Wybierzcie iText, gdy warstwa PDF jest rdzeniem produktu: archiwa legal-tech, platformy podpisu elektronicznego, systemy zarządzania dokumentami, narzędzia naprawy lub manipulacji PDF albo wbudowane systemy Java/.NET, które nie mogą wołać zewnętrznego API.

Wybierzcie gPdf, gdy produkt nie jest edytorem PDF. Logistyka, e-commerce, ERP, fintech, ticketing i systemy back-office zwykle potrzebują przewidywalnych PDF-ów z danych. W takich przypadkach najlepszym produktem często nie jest najbardziej programowalne SDK, tylko najkrótsza niezawodna ścieżka od danych do gotowego dokumentu.

Czas wdrożenia: implementacja SDK vs szablon API

Typowy pomiar od zera do termicznej etykiety wysyłkowej, która rzeczywiście skanuje się na Zebra ZT411:

Ścieżka iText — Java; uproszczona, realny kod dodaje konfigurację buildu, rejestrację fontów, zestaw testów skanowalności i pipeline CI:

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();

Typowy czas do pierwszego działającego wyniku, od mvn init do etykiety wysyłkowej skanującej się bez problemu: 2–5 dni inżynierskich.

Ścieżka gPdf — dowolny język; poniżej 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.pdf

Typowy czas do pierwszego działającego wyniku: około 5 minut, razem z przeczytaniem przykładowego JSON i wydrukiem PDF na tej samej Zebra ZT411.

Różnica nie wynika z talentu inżynierskiego. Wynika z tego, gdzie leży granica produktu. Z iText Państwa zespół buduje usługę etykiet wysyłkowych. Z gPdf usługa etykiet wysyłkowych jest produktem, który wywołujecie.

Studio i zmiany szablonu

Logistyka to domena, w której specyfikacja dokumentu potrafi zmienić się poza Państwa zespołem. UPS aktualizuje regułę SSCC. SF Express dodaje cyfrę kontrolną. FedEx publikuje nowy układ bloku HAZMAT. Wybrany stos generowania musi przyjąć tę zmianę.

Z iText: programista czyta biuletyn przewoźnika, zmienia kod Java/.NET, uruchamia testy jednostkowe i integracyjne, buduje usługę, wdraża staging, potem produkcję i regiony. W oknie wdrożenia magazyny mogą nadal drukować stary format.

Z gPdf: edytujecie szablon JSON w kodzie albo używacie gPdf Studio, żeby wizualnie dopasować układ przez dodawanie i przeciąganie elementów. Sam generator się nie zmienia; zmienia się tylko szablon. Jeśli zmiana przewoźnika dotyczy formatu kodu kreskowego, który gPdf już obsługuje, integracja produkcyjna może pozostać template_id + data.

Model ceny: ścieżka licencji vs infrastrukturalna cena za stronę

Decyzja cenowa iText to nie tylko “koszt biblioteki”. iText publikuje ścieżkę AGPL i ścieżki licencji komercyjnych. AGPL może być bezkosztowe dla zgodnego użycia open source, ale niesie obowiązki ujawniania źródła. Licencja komercyjna uwalnia zespoły od tych ograniczeń, a iText opisuje subskrypcje i opcje OEM jako wyceniane indywidualnie albo zależne od wolumenu.

gPdf wycenia bezpośrednio usługę generowania. Publiczna cena zaczyna się od 5 USD/miesiąc za 100 000 stron w Basic, z tą samą opublikowaną matematyką za stronę na stronie cennika i w maszynowo czytelnych punktach końcowych cennika.

Najczęściej pytane wolumeny logistyczne:

Kolumna ceny katalogowej jest łatwa. Trudniejsza jest reszta rachunku: ścieżka licencji i zgodności, środowisko uruchomieniowe usługi, ślad HA, godziny inżynierskie, wdrożenie regionalne, utrzymanie specyfikacji przewoźników i wsparcie.

Pełne TCO — z szacunkami miesięcy inżynierskich dla kolejnych progów wolumenu, zakresami kosztów infrastruktury i krzywą kosztów usługi opartej na SDK wraz ze wzrostem skali — znajduje się w dłuższej analizie:

→ TCO etykiet wysyłkowych: iText vs gPdf przy 100 000 → 100 mln stron miesięcznie

Generowanie na edge i koszt operacyjny

iText potrafi być ekstremalnie szybki w procesie aplikacji. Koszt operacyjny zależy od tego, gdzie działa generator. Jeśli magazyn w Europie woła usługę etykiet wysyłkowych w jednym regionie USA, generowanie w JVM może być szybkie, ale z perspektywy użytkownika opóźnienie sieci nadal zostaje. Wdrożenie wieloregionowe to naprawia, ale wtedy zespół posiada wdrożenie, monitoring, pojemność i wdrażanie w każdym regionie.

gPdf przenosi usługę generowania na edge Cloudflare. Dla etykiet wysyłkowych i faktur wartością nie jest tylko czas p50 generowania; wartością jest brak potrzeby prowadzenia usługi PDF obok każdego magazynu, integracji przewoźnika albo regionalnego backendu.

Zgodność i koszt jakości dokumentu

iText ma głębokie możliwości PDF, w tym procesy, których gPdf nie próbuje zastępować. Właśnie dlatego iText jest mocny dla zespołów potrzebujących kontroli niskiego poziomu.

Dla generowania dokumentów biznesowych gPdf produktowo obejmuje typowe wymagania wyjścia: fonty CJK, wektorowe kody kreskowe, profile PDF/A, pakietowanie Factur-X/ZUGFeRD, metadane, wyjście chronione hasłem i generowanie sterowane szablonem. Porównanie kosztu powinno uwzględniać, ile z tego Państwa zespół chce samodzielnie złożyć i testować we własnej usłudze.

Kiedy iText nadal jest właściwą odpowiedzią

Porównanie, które udaje, że konkurent nigdy nie wygrywa, jest marketingową watą. iText pozostaje lepszy, gdy:

• Manipulujecie PDF-ami, a nie tylko je generujecie. Podpisy, wypełnianie formularzy, dzielenie, edycja na poziomie stron — gPdf generuje nowe PDF-y z JSON i nie wchodzi w te procesy.
• Stos jest Java/.NET-first. Jeśli reszta usług działa w JVM, a wychodząca zależność HTTP wygląda jak regres, iText zostaje w procesie.
• Działacie w środowisku odizolowanym od sieci albo offline. Wychodzące HTTPS jest złym kształtem dla części wdrożeń magazynowych lub rządowych. iText działa wszędzie tam, gdzie działa JVM.
• Narzędzia PDF są produktem. Dostawca PDF, platforma podpisu elektronicznego albo archiwum legal-tech powinny posiadać SDK. gPdf jest dla zespołów, których produktem jest logistyka, fakturowanie albo handel, nie same PDF-y.
• Potrzebujecie niszowego pokrycia specyfikacji PDF (formularze XFA, zaawansowana obsługa podpisu cyfrowego, profile atestacji), którego gPdf nie dostarcza.

Dla “potrzebuję skanowalnej etykiety na paczce i mam milion paczek miesięcznie” gPdf jest ścieżką z mniejszym tarciem. Dla “muszę manipulować istniejącym prawnym PDF-em w backendzie Java” właściwy jest iText.

Powiązane scenariusze generowania PDF

Zespoły porównujące iText i gPdf zwykle rozdzielają dwa pytania: czy trzeba posiadać SDK PDF, czy wystarczy niezawodnie generować nowe dokumenty z danych. Dla etykiet wysyłkowych warto sprawdzić API etykiet wysyłkowych i kody GS1-128 w JSON. Dla faktur i zgodności pomocne są API PDF faktur, API PDF/A i API Factur-X. Dla zespołów szukających alternatywy dla ciężkiej usługi SDK punktem wyjścia jest API JSON do PDF.

FAQ

Czy iText jest darmowy?

iText ma ścieżkę AGPL dla zgodnego open source i licencje komercyjne dla zespołów, które nie mogą albo nie chcą spełniać obowiązków AGPL.

Czy gPdf zastępuje iText?

Nie. gPdf jest usługą generowania PDF dla nowych, ustrukturyzowanych dokumentów. iText pozostaje mocniejszy w głębokiej manipulacji PDF, podpisywaniu, wypełnianiu formularzy, dzieleniu dokumentów i kontroli SDK niskiego poziomu.

Po co porównywać cenę, jeśli iText jest wyceniany indywidualnie?

Bo kupujący nadal potrzebują modelu TCO. Porównanie powinno obejmować ścieżkę licencji i zgodności, infrastrukturę, czas inżynierski, wsparcie i operacje regionalne, nie tylko pozycję SDK.

Kształt migracji

Dla zespołów przenoszących renderowanie etykiet wysyłkowych z iText do gPdf diff wygląda mniej więcej tak:

- // 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());

Po migracji usługa etykiet wysyłkowych w Javie zwija się do pojedynczego wywołania fetch z języka, który już orkiestruje zamówienia. JVM znika ze ścieżki etykiety wysyłkowej; zmiany specyfikacji przewoźników przestają być zdarzeniem wdrożeniowym; dyżur przestaje dostawać alerty OOM generatora.

Zobacz też

• TCO etykiet wysyłkowych: iText vs gPdf przy 100 000 → 100 mln stron miesięcznie — dłuższa matematyka kosztów, miesiące inżynierskie i zakresy infrastruktury.
• API etykiet wysyłkowych — przykładowe dane żądania, wartości p99 i matematyka szczytów sprzedażowych.
• Referencja JSON Render API — punkty końcowe, kształt żądania i model bezpieczeństwa.
• Kody kreskowe GS1-128 z precyzją 0,1 mm w JSON — szczegółowy opis geometrii kodu kreskowego.