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-редактором. Логистика, ecommerce, ERP, fintech, ticketing и back-office-системы обычно нуждаются в предсказуемых 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 может быть бесплатным для совместимого open-source использования, но несет обязательства по раскрытию исходного кода. Коммерческие лицензии освобождают команды от этих AGPL-ограничений, а подписку и OEM-варианты iText описывает как зависящие от запроса или объема.

gPdf оценивает сам сервис генерации. Публичная цена начинается с 5 USD/мес. за 100 000 страниц на Basic, с той же опубликованной формулой за страницу на странице цен и в машиночитаемых ценовых эндпоинтах.

Для объемов, о которых чаще всего спрашивают логистические команды:

Колонка публичной цены — простая часть. Сложнее остальной счет: лицензия и путь соблюдения требований, среда выполнения сервиса, отказоустойчивый контур, инженерные часы, региональное развертывание, поддержка спецификаций перевозчиков и поддержка.

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

→ TCO транспортных этикеток: iText vs gPdf при 100 000 → 100 млн страниц в месяц

Edge-генерация и операционные расходы

iText может быть очень быстрым внутри процесса. Операционные расходы зависят от того, где живет рендерер. Если склад в Европе вызывает сервис этикеток в одном американском регионе, сама этикетка может быстро отрендериться внутри JVM, но для пользователя все равно ощущаться медленной. Развертывание в нескольких регионах решает это, но тогда команда владеет развертыванием, мониторингом, емкостью и выкаткой в каждом регионе.

gPdf переносит сервис генерации на Cloudflare edge. Для транспортных этикеток и счетов продуктовая ценность не только во времени рендера p50; она в том, что не нужно запускать PDF-сервис рядом с каждым складом, каждой интеграцией перевозчика или каждым региональным бэкендом.

Требования соответствия и стоимость качества документа

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

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

Когда iText все еще правильный ответ

Сравнение, будто конкурент никогда не выигрывает, — маркетинговый шум. iText остается лучшим выбором, когда:

• Вы редактируете PDF, а не только рендерите новые. Подписи, заполнение форм, разделение, правки страниц — gPdf рендерит новые PDF из JSON и не входит в эти процессы.
• Ваш стек Java/.NET-first. Если остальные сервисы работают на 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-путь для совместимого open-source использования и коммерческие лицензии для команд, которые не могут или не хотят выполнять AGPL-обязательства.

gPdf заменяет iText?

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

Зачем сравнивать цену, если iText работает по индивидуальным предложениям?

Потому что покупателям все равно нужна TCO-модель. Сравнение должно включать лицензионный путь, соблюдение требований, инфраструктуру, инженерное время, поддержку и региональные операции, а не только строку SDK в счете.

Форма миграции

Для команд, которые переносят рендер этикеток с iText на gPdf, diff выглядит примерно так:

- // 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 транспортных этикеток — данные этикеток, ограничения и edge-генерация.
• JSON Render API reference — эндпоинты, форма запроса и модель безопасности.
• GS1-128 barcodes at 0.1 mm precision in JSON — подробный разбор геометрии штрихкодов.