gPdf vs iText для транспортних етикеток

iText чудовий, коли продукту потрібен PDF SDK

iText — зрілий PDF SDK. Це має значення. Якщо продукт змінює наявні PDF, підписує документи, заповнює форми, об’єднує файли, реалізує нішеві PDF-процеси або потребує глибокого Java/.NET-контролю над низькорівневими PDF-об’єктами, iText часто дає правильний рівень володіння.

Для логістичних команд питання інше: вам потрібен PDF SDK чи щоденна надійна генерація етикеток, рахунків, квитанцій і операційних документів? Для генерації структурованих документів купівля або прийняття бібліотеки — лише перший рядок. Сервіс навколо неї все одно потрібно побудувати.

Та сама сім’я документів, інша межа продукту

З iText застосунок володіє інтеграцією SDK. Зазвичай це Java або .NET-сервіси, налаштування шрифтів, конфігурація штрихкодів, параметри PDF/A, розгортання, моніторинг, планування потужності й шлях чергування для відмов рендера.

З gPdf застосунок надсилає JSON або template_id + data через HTTPS. Рендерер, розгортання на edge, вбудовані шрифти, примітиви штрихкодів, вивід із паролем, керування метаданими, профілі PDF/A, пакування Factur-X/ZUGFeRD і візуальний процес дизайну входять у межу сервісу.

Відповідність продукту: низькорівневий контроль PDF проти згенерованих бізнес-документів

Обирайте iText, коли PDF-шар є ядром продукту: legal-tech-архіви, платформи електронного підпису, системи керування документами, інструменти ремонту або маніпуляції PDF чи вбудовані Java/.NET-системи, які не можуть викликати зовнішній API.

Обирайте gPdf, коли продукт не є PDF-редактором. Логістика, електронна комерція, ERP, фінтех, квиткові сервіси й бекофісні системи зазвичай потребують передбачуваних PDF зі структурованих даних. У таких випадках найкращий продукт часто не найпрограмованіший SDK, а найкоротший надійний шлях від даних до готового документа.

Час розробки: реалізація SDK проти API-шаблону

Типова оцінка “з нуля до термоетикетки, яка реально сканується на Zebra ZT411”:

Шлях iText — Java; спрощено, реальний код додає налаштування збірки, реєстрацію шрифтів, стенд перевірки сканування і 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();

Типовий час до першого успішного результату (від mvn init до етикетки, що чисто сканується): 2–5 інженерних днів.

Шлях gPdf — будь-яка мова; приклад нижче через 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

Типовий час до першого успішного результату: близько 5 хвилин, включно з читанням JSON-прикладу та друком PDF на тій самій Zebra ZT411.

Різниця не в таланті інженерів. Вона в тому, де проходить межа продукту. З iText ваша команда будує сервіс етикеток. З gPdf сервіс етикеток — це продукт, який ви викликаєте.

Studio і зміни шаблонів

Логістика — рідкісна сфера, де специфікація документа змінюється ззовні вашої команди. UPS оновлює правило кодування SSCC. SF Express додає контрольну цифру. FedEx публікує новий HAZMAT-блок. Будь-який вибраний стек рендера має це поглинути.

З iText: розробник читає бюлетень перевізника, змінює Java/.NET-код, запускає модульні та інтеграційні тести, збирає сервіс, розгортає в staging, потім у бойовому контурі й викочує зміни регіонами. Під час вікна викатки склади можуть усе ще друкувати старий формат.

З gPdf: редагуєте JSON-шаблон у коді або використовуєте gPdf Studio, щоб візуально налаштувати макет додаванням і перетягуванням елементів. Сам рендерер не рухається; змінюється тільки шаблон. Якщо зміна перевізника стосується формату штрихкоду, який gPdf уже підтримує, бойова інтеграція може лишитися template_id + data.

Модель ціни: шлях ліцензії проти інфраструктурної ціни за сторінку

Цінове рішення iText — це не лише “вартість бібліотеки”. iText публікує AGPL-шлях і комерційні ліцензійні шляхи. AGPL може бути безкоштовним для сумісного використання з відкритим кодом, але має зобов’язання розкриття джерельного коду. Комерційна ліцензія звільняє команди від цих AGPL-обмежень, а iText описує підписку й OEM-варіанти як такі, що залежать від комерційної пропозиції або обсягу.

gPdf напряму тарифікує сервіс генерації. Публічна ціна починається з 5 USD/міс. за 100 000 сторінок у Basic, з тією самою опублікованою посторінковою математикою на сторінці цін і в машинозчитуваних цінових ендпоінтах.

Для обсягів, про які найчастіше питають логістичні команди:

Колонка публічної ціни — легка частина. Складніше все інше в рахунку: ліцензія або шлях відповідності, середовище виконання сервісу, відмовостійкий контур, інженерні години, регіональне розгортання, підтримка специфікацій перевізників і супровід.

Повний TCO-розбір — з оцінками інженерних місяців за рівнями обсягу, діапазонами інфраструктурних витрат і кривою того, як SDK-сервіс поглинає операційну вартість зі зростанням обсягу — у розгорнутому аналізі:

→ TCO транспортних етикеток: iText vs gPdf при 100 000 -> 100 млн сторінок на місяць

Генерація на edge та операційна вартість

iText може бути надзвичайно швидким усередині процесу. Операційна вартість у тому, де живе рендерер. Якщо склад у Європі викликає сервіс етикеток в одному регіоні США, рендер у JVM може бути швидким, але з погляду користувача все ще повільним. Мультирегіональне розгортання це виправляє, але тоді команда володіє розгортанням, моніторингом, потужністю і викаткою в кожному регіоні.

gPdf переносить сервіс генерації на edge Cloudflare. Для етикеток і рахунків цінність продукту не лише в p50 рендера; вона в тому, щоб не запускати PDF-сервіс поруч із кожним складом, інтеграцією перевізника або регіональним бекендом.

Відповідність вимогам і вартість якості документа

iText має глибокі PDF-можливості, включно з процесами, які gPdf не намагається замінити. Саме тому iText сильний для команд, яким потрібен низькорівневий контроль.

Для генерації бізнес-документів gPdf продуктово закриває типові вимоги до виводу: CJK-шрифти, векторні штрихкоди, профілі PDF/A, пакування Factur-X/ZUGFeRD, метадані, PDF із паролем і генерація через шаблони. Порівняння вартості має включати те, скільки з цього ваша команда хоче збирати й тестувати всередині власного сервісу.

Коли iText усе ще правильна відповідь

Порівняння, де конкурент ніколи не виграє, — маркетинговий шум. iText лишається кращим вибором, коли:

• Ви маніпулюєте PDF, а не лише рендерите їх. Підписання, заповнення форм, розділення, правки на рівні сторінок — gPdf рендерить нові PDF з JSON і не входить у ці процеси.
• Ваш стек передусім Java/.NET. Якщо решта сервісів працює на JVM і зовнішня HTTP-залежність здається регресією, iText тримає все всередині процесу.
• Ви працюєте в ізольованому від мережі або суворо офлайн-середовищі. Вихідний HTTPS є неправильною формою для деяких складських або державних розгортань. iText працює всюди, де є JVM.
• PDF-інструментарій є вашим продуктом. Якщо ви PDF-постачальник, платформа електронного підпису або legal-tech-архів, володіння SDK є правильним рівнем контролю. gPdf створений для команд, чий продукт — логістика, рахунки або комерція, а не самі PDF.
• Потрібне нішеве покриття PDF-специфікацій (XFA-форми, розширені обробники цифрових підписів, профілі атестації), яке gPdf не постачає.

Для “мені потрібна етикетка, що сканується, на посилці, і в мене мільйон посилок на місяць” gPdf — шлях із меншим тертям. Для “мені потрібно змінювати наявний юридичний PDF усередині Java-бекенду” — iText.

Пов’язані сценарії генерації PDF

Команди, які порівнюють iText і gPdf, зазвичай розділяють два питання: чи потрібно володіти PDF SDK, чи потрібно надійно генерувати нові документи з даних. Для етикеток краще почати з API транспортних етикеток і GS1-128 у JSON. Для рахунків і вимог відповідності корисні API для PDF рахунків, API PDF/A і API Factur-X. Якщо команда шукає легшу заміну SDK-сервісу, відправна точка — API JSON у PDF.

FAQ

iText безкоштовний?

iText має AGPL-шлях для сумісного використання з відкритим кодом і комерційне ліцензування для команд, які не можуть або не хочуть виконувати AGPL-зобов’язання.

gPdf замінює iText?

Ні. gPdf — сервіс генерації PDF для нових структурованих документів. iText лишається сильнішим для глибокої роботи з PDF, підписання, заповнення форм, розділення й низькорівневого SDK-контролю.

Навіщо порівнювати ціну, якщо iText продається за індивідуальною пропозицією?

Бо покупцям усе одно потрібна модель TCO. Порівняння має включати ліцензію або шлях відповідності, інфраструктуру, інженерний час, підтримку й регіональні операції, а не тільки рядок SDK.

Форма міграції

Для команд, які переносять рендер етикеток з iText на gPdf, форма зміни приблизно така:

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

Після переходу Java-сервіс етикеток стискається до одного fetch-виклику з тієї мови, яка вже оркеструє замовлення. JVM зникає зі шляху етикеток; зміни специфікацій перевізників перестають бути подією розгортання; чергування перестає отримувати сповіщення через OOM у рендері етикеток.

Див. також

• TCO транспортних етикеток: iText vs gPdf при 100 000 -> 100 млн сторінок на місяць — розгорнута математика вартості, інженерні місяці, діапазони інфраструктури.
• API транспортних етикеток — приклади тіл запиту, p99-числа, математика Black Friday.
• Довідник JSON Render API — ендпоінти, форма запиту, модель безпеки.
• Штрихкоди GS1-128 з точністю 0,1 мм у JSON — глибокий розбір геометрії штрихкодів.