QuestPDF сильний, коли C# є межею продукту
QuestPDF заслуговує на поважне порівняння. Це сучасна бібліотека генерації PDF для C# розробників, із fluent API, строгою типізацією, великою документацією, Companion App для попереднього перегляду й налагодження та моделлю ліцензування, яка незвично прозора для PDF SDK.
Питання не в тому, “хто може створити PDF?” Обидва можуть. Корисне питання — де має жити PDF-межа: всередині .NET-застосунку, який володіє макетом, байтами й життєвим циклом, чи як інфраструктурний сервіс, який викликають кілька продуктів і мов.
Швидкий орієнтир для вибору
- Обирайте QuestPDF, коли C# є джерелом істини для документа, застосунок має працювати автономно або потрібні локальні операції з наявними PDF.
- Обирайте gPdf, коли один PDF-шар має обслуговувати Node, Python, Go, .NET, фонові задачі й регіональні системи через той самий HTTP API.
- Обирайте gPdf, коли зміни макета мають бути ревізіями шаблону, а не перебудовою C# коду й повторним розгортанням сервісу.
Та сама сім’я документів, інша модель володіння
З QuestPDF застосунок володіє генерацією PDF — це справжня перевага: C# залишається поруч із доменною моделлю, усе запускається й налагоджується локально, без виклику зовнішнього API під час виконання.
Компроміс у тому, що ваша команда також володіє рештою бойового контуру:
- CPU і пам’яттю для рендера.
- Пошуком шрифтів і підстановкою в кожному середовищі розгортання.
- Інтеграцією бібліотеки штрихкодів і перевіркою друку.
- Нативними пакетами й питаннями розгортання для графіків або власної графіки.
- Моніторингом, повторними спробами й обробкою відмов.
- Регіональним розгортанням, якщо користувачі або склади глобальні.
- Викатками щоразу, коли змінюється макет документа.
З gPdf цей контур виноситься назовні: застосунок надсилає DocumentRequest або template_id + data, а сервіс володіє рендерером, середовищем виконання на edge, шрифтами, примітивами штрихкодів, PDF/A-виводом і пакуванням електронних рахунків. Це менш привабливо, якщо ви хочете тримати кожну деталь у C#, і привабливіше, якщо генерація PDF має бути службовим шаром, доступним із будь-якого стеку.
Три компроміси, на які хостинговий API має відповідати чесно
Більшість подач у стилі “бібліотека проти API” пропускають три питання, які .NET-архітектор ставить першими. Чесне порівняння проговорює їх прямо.
1. Куди йдуть дані документа. Ця сторінка здебільшого про рахунки, виписки й електронні рахунки — документи з іменами, адресами, податковими ідентифікаторами та сумами. У QuestPDF ці байти створюються всередині вашого процесу й не виходять назовні. Публічний API gPdf передає тіло запиту в рендерер, але рендерер нічого не зберігає: JSON запиту перебуває в ізоляті Cloudflare Workers V8 лише під час рендера (зазвичай близько 4 мс) і звільняється після завершення відповіді — не зберігається, не логується, не відбирається для вибірок і не використовується для навчання моделей; операційні журнали обмежені HTTP-статусом і тривалістю (security, DPA). Вибір резидентності даних в ЄС або глобально та локальне / приватне розгортання Enterprise додатково звужують або закривають зовнішню межу. Водночас генерація всередині процесу без додаткової підготовки — легітимна, іноді вирішальна причина, чому фінансова або державна команда обирає QuestPDF.
2. Режим відмови. У бібліотеки немає третьої сторони, яка може впасти; генерація може зламатися лише на інфраструктурі, якою ви вже володієте. Хостинговий API додає залежність від доступності постачальника, яку ви не контролюєте. Правильний спосіб впроваджувати gPdf — ставитися до викликів рендера як до будь-якого зовнішнього виклику: тайм-аут, повторна спроба, черга і, бажано, резервний режим із деградацією. Якщо генерація документів стоїть на критичному синхронному шляху, потрібно зважити “експлуатувати самому” проти “залежати від доступності постачальника.”
3. Профіль затримки. Генерація всередині процесу — це виклик функції без мережі. Хостинговий виклик — це мережевий обмін. Для пакетних і асинхронних задач це шум. Для сценарію “користувач натискає, PDF має з’явитися зараз” підхід усередині процесу структурно швидший; edge PoP gPdf роблять перехід малим, але це все одно TLS плюс мережевий обмін, тоді як QuestPDF — виклик методу.
Це не робить gPdf неправильним вибором; це визначає, коли він правильний: для команд, чиї дані документа можуть вийти з процесу, чиї процеси витримують мережевий перехід і які радше покладуться на доступність постачальника, ніж самі експлуатуватимуть парк рендерерів.
Ліцензування й модель ціни
Публічна сторінка ліцензування QuestPDF каже, що комерційна ліцензія потрібна лише компаніям із річним валовим доходом понад 1 млн USD. Рівень Community безкоштовний для відповідних фізичних осіб, проєктів з відкритим кодом, неприбуткових організацій і компаній нижче цього порогу, на умовах MIT. Та сама публічна сторінка вказує два постійні комерційні рівні: Professional за 999 USD плюс місцевий податок для команд до 10 розробників і Enterprise за 2 999 USD плюс місцевий податок для всієї організації без підрахунку розробників. Обидва включають один рік оновлень і необмежену кількість проєктів, серверів та розгортань, а ліцензія не спливає для останньої отриманої версії.
Модель застосування також незвично легка. Ліцензія задається одним рядком — QuestPDF.Settings.License = LicenseType.Community; — без ключа ліцензії, сервера активації і, за власною сторінкою конфігурації QuestPDF, без мережевих викликів та без виходу даних із машини. Це модель довіри: ви самі обираєте рівень, на який маєте право. Немає рахунку постачальника за документ, а платна ліцензія працює будь-де, включно з повністю автономним середовищем.
gPdf прямо тарифікує сервіс рендера. Публічний Basic починається з 5 USD/міс. за 100 000 сторінок, а перевищення ліміту — від 0,00005 USD за сторінку. Це рахунок постачальника, але він також прибирає окремий проєкт з експлуатації генерації PDF: без кластера рендера, без шляху розгортання через NuGet, без регіонального теплого пулу, без пакета шрифтів для кожного застосунку і без PDF-сервісу, який потрібно латати.
Тому порівняння вартості — це не “999 USD проти 5 USD”; ліцензія є малим рядком. Реальне порівняння таке:
Загальна вартість QuestPDF = ліцензія (разова) + ваш хостинг + час інженерів + чергування
Загальна вартість gPdf = рахунок за сторінки (інфраструктура, шрифти, масштабування й edge включені)За публічною математикою за сторінку перевищення ліміту gPdf коштує 0,05 USD за 1 000 сторінок (50 USD за 1 млн, 500 USD за 10 млн). Разова Enterprise-ліцензія за 2 999 USD лише “зрівнюється” з цим рахунком приблизно біля 60 млн сторінок — і ця математика ігнорує хостинг QuestPDF та інженерні місяці, які зсувають реальну точку перетину ще далі на користь gPdf, якщо ви вже не експлуатуєте цю інфраструктуру дуже дешево. Практичне правило: якщо заради бібліотеки довелося б будувати й укомплектовувати сервіс рендера, gPdf зазвичай виграє за повною вартістю задовго до того, як рахунок за сторінки наздожене ліцензію; якщо ця інфраструктура вже існує й майже безкоштовна для вас, постійна ліцензія виграє на масштабі.
Процес розробки: Fluent C# проти шаблонів
Fluent API QuestPDF добре підходить, коли розробники володіють формою документа. Строга типізація, ланцюжки методів, повторно використовувані C# компоненти, рефакторинг в IDE і Companion App логічні, якщо PDF є частиною кодової бази застосунку.
gPdf підходить іншому процесу. Розробники все ще можуть писати JSON напряму, але бойові системи зазвичай рухаються до шаблонів. Дизайнер, оператор або інженер коригує макет у gPdf Studio. Затверджений макет стає шаблоном, а бекенд продовжує рендерити через template_id + data.
Ця різниця важлива, коли документ часто змінюється. Якщо змінюється транспортна етикетка, рахунок, пакувальний лист або макет виписки, gPdf може залишити середовище виконання стабільним і змінити лише шаблон. У QuestPDF макет — це C# код, тому нормальний шлях: зміна коду, тест, збірка, розгортання і план відкату.
Жоден процес не є універсально кращим: QuestPDF оптимізує для C# розробників, які хочуть документ як код; gPdf — для операційних шаблонів, спільних між системами.
Відповідність: обидва продукти серйозні
Це не порівняння, де gPdf виграє заявою, що конкурент не має функцій відповідності. Поточні публічні матеріали QuestPDF перелічують сильну підтримку стандартів, зокрема PDF/A, PDF/UA-1 і EN 16931 для електронних рахунків через приклад ZUGFeRD 2.1 / Factur-X на базі UN/CEFACT Cross Industry Invoice (CII). Цей приклад встановлює PdfA = true, вбудовує дані factur-x.xml через AddAttachment(), розширює документ XMP-метаданими й валідовує результат через veraPDF (для PDF/A-3b) та Mustang Project (для ZUGFeRD). Це повний, чесний рецепт — і ваш пайплайн володіє кожним його кроком.
gPdf пакує ті самі стандарти як API-контракт. JSON Render відкриває шість профілів PDF/A (1b, 2b, 3b, 4, 2u, 3u) плюс PDF/UA-1 через settings.profile, Template Render повторно використовує ту саму модель документа, а E-Invoice Render дає окремий ендпоінт POST /api/v1/e-invoice/render, який створює пакети Factur-X / ZUGFeRD PDF/A-3b із вбудованим EN 16931 CII XML. Відмінність від рецепта QuestPDF у тому, що сервіс робить за вас: gPdf виконує PDF/A-3b і серверну валідацію електронного рахунку, підтримує синхронну доставку одразу у відповіді або доставку об’єкта через опитування і пропонує резидентність даних в ЄС або глобально як налаштування запиту, а не як кроки, які ви збираєте й експлуатуєте. QuestPDF підходить, коли валідація має жити всередині вашого .NET-пайплайну; gPdf — коли це має бути хостинговий контракт, спільний для багатьох систем.
Шрифти й штрихкоди: реальне питання в інтеграційних зусиллях
QuestPDF має сильну модель шрифтів. Він постачає Lato 2.015 за замовчуванням, автоматично завантажує системні шрифти й шрифти з каталогу розгортання, дозволяє реєструвати власні шрифти через FontManager і підтримує ланцюжки підстановки. Це дає розробникам контроль. Але та сама документація чесно описує пастку: у більшості хмарних розгортань доступно мало шрифтів або їх немає, що може дати неочікуваний результат; вона радить вимикати шрифти середовища й явно реєструвати потрібні. Іншими словами, у контейнері або безсерверному середовищі шрифтове оточення — ваша зона планування, доставки й тестування; відсутній гліф стане символом-заглушкою або, якщо ввімкнути CheckIfAllTextGlyphsAreAvailable, винятком.
gPdf робить шрифти частиною межі сервісу. Рендерер має набір для кількох писемностей — Latin, Greek, Cyrillic, Arabic, Hebrew, Bengali, Tamil, Thai, Vietnamese, monospace і CJK із підстановкою за писемністю на Noto KR / JP / SC. Він розв’язує неявний вибір шрифту через автоматичний підбір, а явний вибір — через prefer або strict. Викликачі не відправляють CJK-шрифт, не реєструють Noto-ресурси в .NET-застосунку і не налаштовують підстановку для кожної цілі розгортання. Вони надсилають дані; рендерер володіє шрифтовим оточенням, однаковим у кожному регіоні.
Порівняння штрихкодів має схожу форму. Документація QuestPDF щодо штрихкодів показує добрий підхід із ZXing.Net, що рендериться як векторний SVG, і прямо зазначає, що ZXing.Net не входить до пакета QuestPDF — його встановлюють із NuGet і підключають:
// QuestPDF: add the separate ZXing.Net package, encode, render to SVG, embed.
// dotnet add package ZXing.Net
var writer = new ZXing.BarcodeWriterSvg {
Format = ZXing.BarcodeFormat.CODE_128,
Options = new ZXing.Common.EncodingOptions { Width = 320, Height = 80 }
};
string svg = writer.Write("INV-2026-001").Content;
container.Svg(svg);
// GS1-128 with Application Identifiers and FNC1 framing is hand-wired on top.У gPdf генерація штрихкоду — повноцінний елемент схеми. Запит оголошує формат, вміст, фізичний розмір і необов’язковий читабельний рядок; формати GS1 нативні, тому ідентифікатори застосування йдуть прямо в content:
{
"type": "barcode",
"format": "gs1_128",
"content": "(01)00012345678905(21)SN12345",
"x": 12, "y": 60, "width": 80, "height": 18,
"barcode_text": { "enabled": true, "position": "bottom" }
}Для одного .NET-застосунку встановити ZXing.Net і протестувати результат може бути легко. Для багатьох сервісів і шаблонів — особливо логістичних і роздрібних навантажень, де потрібні GS1-128, SSCC, GTIN, GS1 DataMatrix або GS1 QR з читабельним рядком інтерпретації — простіше тримати поведінку штрихкодів у документному API, ніж повторювати підключення ZXing у кожному сервісі.
Де QuestPDF явно виграє
Крім автономної роботи, утримання даних документа всередині вашого периметра і сценаріїв, де PDF-код сам є частиною продукту, QuestPDF має дві групи можливостей, які прямо поза межами gPdf:
- Операції з наявними PDF. QuestPDF може завантажувати наявні файли й об’єднувати їх, вибирати / змінювати порядок / розгортати / фільтрувати сторінки, накладати шари, додавати вкладення, задавати XMP-метадані, лінеаризувати для веб-доставки, а також шифрувати і розшифровувати із безпекою 40/128/256-bit. gPdf може захищати паролем і обмежувати дозволи PDF, які він генерує, але не відкриває, не об’єднує й не розшифровує файли, створені не ним.
- Графіки, карти й власна графіка. QuestPDF інтегрує бібліотеки графіків (ScottPlot, LiveCharts, Microcharts), вбудовує карти Mapbox і відкриває SkiaSharp canvas для довільного 2D-малювання. gPdf може малювати векторну графіку через елемент
path(дані SVG-шляху) або вбудовувати SVG / PNG графік, створений вище за процесом, але не має вбудованого рушія графіків, карт або canvas — тому якщо графіки на основі даних є центральними для документа, інструментарій залишається з QuestPDF.
Де gPdf явно виграє
gPdf виграє, коли організація не хоче, щоб кожна продуктова команда володіла власним PDF-сервісом: стеки з кількома мовами, глобальні процеси та ERP / OMS / WMS / ecommerce / fintech / ticketing системи, які рендерять документи зі структурованих даних, із шаблонами, що змінюються незалежно від коду. У таких середовищах локальна бібліотека часто починається дешево, а потім стає парком: один сервіс на мову, один шлях розгортання на регіон, один план шрифтів на контейнер, один набір регресій штрихкодів на команду. gPdf перетворює цей парк на один HTTP-контракт.
Безсерверне середовище робить межу найочевиднішою. На AWS Lambda, Cloud Run або Azure Functions QuestPDF усе одно працює всередині застосунку — ваша команда пакує .NET-середовище виконання, шрифти, нативні залежності й достатньо CPU / пам’яті для пікової PDF-роботи, а також відповідає за холодні старти. gPdf уже є сервісом рендера: функція надсилає невеликий запит template_id + data на edge і отримує PDF-байти назад, без рендерера, який треба прогрівати, і без регіонального воркера, який треба масштабувати.
Як виглядає міграція
Міграція з QuestPDF на gPdf — не переписування рядок у рядок. Це зміна межі: C# код, який будує PDF, стає або JSON-запитом документа, або опублікованим шаблоном.
До / після — C# виклик побудови документа зводиться до одного HTTP POST (натисніть, щоб розгорнути)
- // Before: generate the PDF inside a .NET application.
- Document.Create(container =>
- {
- container.Page(page =>
- {
- page.Size(PageSizes.A4);
- page.Margin(30);
- page.Header().Text("Invoice").FontSize(24).SemiBold();
- page.Content().Column(column =>
- {
- column.Item().Text($"Invoice number: {invoice.Number}");
- column.Item().Text($"Total: {invoice.Total:C}");
- });
- });
- })
- .GeneratePdf("invoice.pdf");
+
+ // After: render through the shared gPdf template from C#.
+ using System.Net.Http.Headers;
+ using System.Net.Http.Json;
+
+ using var client = new HttpClient();
+ client.DefaultRequestHeaders.Authorization =
+ new AuthenticationHeaderValue("Bearer", key);
+
+ var response = await client.PostAsJsonAsync(
+ "https://api.gpdf.com/api/v1/template-render",
+ new {
+ template_id = "invoice-v2",
+ data = new {
+ invoice_number = invoice.Number,
+ total = invoice.Total,
+ currency = invoice.Currency
+ }
+ });
+
+ response.EnsureSuccessStatusCode();
+ byte[] pdfBytes = await response.Content.ReadAsByteArrayAsync();Після перенесення цієї межі зміни макета можуть стати ревізіями шаблону замість розгортань застосунку. Застосунок і далі володіє бізнес-даними та рішеннями процесу; gPdf володіє рендерингом.
Примітка про ціни та джерела
Інформацію про QuestPDF на цій сторінці перевірено 2026-06-02 за офіційними джерелами QuestPDF: License and Pricing, License configuration, Features Overview, Companion App features, Barcodes, Font management і ZUGFeRD example. Сторінки з цінами й функціями можуть змінюватися; командам закупівель варто повторно перевірити сторінку постачальника перед рішенням про купівлю. QuestPDF і пов’язані знаки належать відповідним власникам, це порівняння не схвалене ними.
Пов’язані сценарії генерації PDF
Команди, що порівнюють QuestPDF і gPdf, часто розглядають кілька близьких задач: API JSON у PDF для спільного HTTP-контракту, API PDF рахунків і API-довідку для .NET для бекенд-інтеграції, API PDF/A, Factur-X API і ZUGFeRD API для вимог відповідності, а також API штрихкодів GS1 і API PDF транспортних етикеток для етикеток та логістики.
FAQ
Чи замінює gPdf QuestPDF?
Ні. gPdf замінює потребу експлуатувати сервіс генерації PDF для структурованих бізнес-документів. QuestPDF залишається сильною локальною C# бібліотекою, коли PDF має генеруватися всередині застосунку.
Чи безкоштовний QuestPDF?
Публічна сторінка ліцензування QuestPDF каже, що рівень Community безкоштовний за умовами MIT для відповідних фізичних осіб, проєктів з відкритим кодом, неприбуткових організацій і компаній із річним валовим доходом нижче 1 млн USD. Компаніям вище цього порогу потрібна постійна комерційна ліцензія: Professional за 999 USD плюс місцеві податки для команд до 10 розробників або Enterprise за 2 999 USD плюс місцеві податки на всю організацію, кожен варіант включає один рік оновлень.
Чи може gPdf генерувати графіки або карти як QuestPDF?
Не як вбудований рушій. QuestPDF інтегрує бібліотеки графіків (ScottPlot, LiveCharts, Microcharts), карти Mapbox і SkiaSharp canvas, що рендеряться в документі. gPdf все ще може малювати векторні графіки через елемент path (який приймає дані SVG-шляху) і фігури або вбудовувати SVG / PNG, створений будь-якою бібліотекою графіків, як image. Різниця в тому, що QuestPDF обчислює й рендерить графік усередині процесу, а з gPdf ви створюєте зображення графіка, і gPdf розміщує його. Якщо графіки або карти на основі даних є центральними для документа, QuestPDF підходить краще.
Який продукт дешевший?
Залежить від межі. QuestPDF може бути дешевшим для .NET-команд, які підпадають під умови Community або вже експлуатують інфраструктуру рендера. gPdf може бути дешевшим, коли альтернатива — будувати, хостити й підтримувати PDF-сервіс для кількох продуктів або регіонів.
Чи зберігає або логує gPdf дані моїх документів?
Ні. JSON, який ви надсилаєте, і PDF, який повертає gPdf, не зберігаються. Кожен запит рендериться всередині одного ізоляту Cloudflare Workers V8, тримається в пам’яті лише під час рендера — зазвичай близько 4 мс — і звільняється після завершення потоку відповіді; gPdf не зберігає, не логує, не відбирає для вибірок і не навчається на вмісті DocumentRequest. Операційні журнали зберігають лише HTTP-статус і тривалість протягом 30 днів і не містять тіл запитів. Див. security policy, privacy policy і DPA. Для навантажень, які взагалі не можуть передавати дані назовні, локальне / приватне розгортання тримає їх усередині вашого периметра.
Чи може QuestPDF працювати без доступу до інтернету?
Так. Сторінка конфігурації ліцензії QuestPDF каже, що ключ ліцензії й сервер активації не потрібні, а обчислення виконуються локально. Це одна з найчіткіших причин обрати QuestPDF.
Чи може gPdf рендерити довільні C# макети QuestPDF?
Ні. gPdf не виконує C# код макета. Міграція означає переведення форми документа в JSON-запит gPdf або збережений шаблон gPdf.