gPdf vs QuestPDF: .NET 문서 생성 선택 기준

C#이 제품 경계라면 QuestPDF는 좋은 선택입니다

QuestPDF는 정중하게 비교할 가치가 있는 제품입니다. C# 개발자를 위한 현대적인 PDF 생성 라이브러리이고, Fluent API, 강한 타입, 넓은 문서, 미리보기와 디버깅을 위한 Companion App, 그리고 PDF SDK 중에서는 보기 드물게 명확한 라이선스 모델을 갖추고 있습니다.

질문은 “어느 쪽이 PDF를 만들 수 있는가“가 아닙니다. 둘 다 만들 수 있습니다. 유용한 질문은 PDF 경계를 어디에 둘 것인가입니다. 레이아웃, 바이트, 생명주기를 소유하는 .NET 애플리케이션 안에 둘 것인지, 아니면 여러 제품과 언어가 호출하는 인프라 서비스로 둘 것인지입니다.

빠른 선택 가이드

• C#이 문서의 단일 기준이고 앱이 오프라인으로 돌아가야 하거나 기존 PDF에 대한 로컬 작업이 필요하면 QuestPDF를 고르세요.
• 하나의 PDF 계층을 Node, Python, Go, .NET, 작업 큐, 리전별 시스템이 같은 HTTP API로 호출해야 한다면 gPdf를 고르세요.
• 레이아웃 변경이 C# 재빌드와 서비스 재배포가 아니라 템플릿 수정이어야 한다면 gPdf를 고르세요.

같은 문서군, 다른 소유 모델

QuestPDF에서는 애플리케이션이 PDF 생성을 직접 맡습니다. 이것은 진짜 장점입니다. C#이 도메인 모델 가까이에 있고, 로컬에서 실행하고 디버깅할 수 있으며, 실행 중 외부 API를 호출하지 않습니다.

대신 운영 표면의 나머지도 팀이 소유합니다.

• 렌더링을 위한 CPU와 메모리.
• 각 배포 환경의 폰트 검색과 대체 폰트 처리.
• 바코드 라이브러리 연동과 인쇄 품질 확인.
• 차트나 사용자 지정 그래픽 연동을 위한 네이티브 패키지와 배포 고려사항.
• 모니터링, 재시도, 장애 처리.
• 사용자나 창고가 전 세계에 있을 때의 리전별 배포.
• 문서 레이아웃이 바뀔 때마다 필요한 롤아웃.

gPdf에서는 그 표면이 바깥으로 이동합니다. 애플리케이션은 DocumentRequest 또는 template_id + data를 보내고, 서비스가 Edge 렌더링, Edge 실행 환경, 폰트, 바코드 기본 요소, PDF/A 출력, 전자 인보이스 패키징을 담당합니다. 모든 세부를 C# 안에 두고 싶다면 덜 매력적입니다. PDF 생성이 어떤 스택에서도 호출 가능한 유틸리티 계층이어야 한다면 더 매력적입니다.

호스팅 API가 솔직하게 답해야 할 세 가지 트레이드오프

대부분의 “라이브러리 vs API” 설명은 .NET 아키텍트가 가장 먼저 묻는 세 가지 질문을 건너뜁니다. 공정한 비교라면 이 질문에 정면으로 답해야 합니다.

1. 문서 데이터가 어디로 가는가. 이 페이지는 주로 인보이스, 명세서, 전자 인보이스를 다룹니다. 이름, 주소, 세금 식별자, 금액이 들어간 문서입니다. QuestPDF에서는 이 바이트가 프로세스 안에서 만들어지고 밖으로 나가지 않습니다. gPdf 공개 API는 요청 데이터를 Edge 렌더링 서비스로 전송하지만 해당 서비스는 무보관입니다. 요청 JSON은 렌더링 동안만 Cloudflare Workers V8 isolate에 있고(일반적으로 약 4 ms), 응답이 끝나면 해제됩니다. 저장, 로깅, 샘플링, 학습에 쓰이지 않으며 운영 로그는 HTTP 상태와 소요 시간으로 제한됩니다(security, DPA). EU / 글로벌 데이터 레지던시 선택과 Enterprise 온프레미스 / 전용 배포로 노출을 더 줄이거나 닫을 수 있습니다. 그래도 별도 준비 없이 생성을 프로세스 안에 두는 것은 금융권이나 공공 부문 팀이 QuestPDF를 고르는 정당하고 때로는 결정적인 이유입니다.

2. 장애 모드. 라이브러리에는 다운될 제3자가 없습니다. 생성은 이미 자신이 운영하는 인프라 안에서만 실패합니다. 호스팅 API는 직접 제어하지 않는 가용성 의존성을 추가합니다. gPdf를 도입하는 올바른 방식은 렌더링 호출을 다른 외부 호출처럼 다루는 것입니다. 타임아웃, 재시도, 큐, 가능하면 저하 모드 대체 처리까지 포함해야 합니다. 문서 생성이 중요한 동기 경로에 있다면 “직접 운영“과 “벤더 가동 시간에 의존” 중 무엇을 감수할지 따져야 합니다.

3. 지연 시간 프로필. 프로세스 내부 생성은 네트워크 없는 함수 호출입니다. 호스팅 호출은 네트워크 왕복입니다. 배치와 비동기 작업에서는 잡음에 가까울 수 있습니다. 하지만 “사용자가 클릭하면 PDF가 바로 떠야 하는” 흐름에서는 프로세스 내부 호출이 구조적으로 더 빠릅니다. gPdf의 Edge PoP는 홉을 줄이지만 TLS와 왕복은 남아 있습니다. QuestPDF는 메서드 호출입니다.

이 세 가지가 gPdf를 틀린 선택으로 만들지는 않습니다. 오히려 gPdf가 맞는 조건을 정의합니다. 문서 데이터가 프로세스 밖으로 나갈 수 있고, 흐름이 네트워크 홉을 받아들일 수 있으며, 렌더링 플릿을 직접 운영하기보다 벤더 가동 시간에 의존하려는 팀입니다.

라이선스와 가격 모델

QuestPDF의 공개 라이선스 페이지는 연간 총매출 100만 달러를 넘는 회사에만 상용 라이선스가 필요하다고 설명합니다. Community tier는 조건을 만족하는 개인, 오픈소스 프로젝트, 비영리단체, 그리고 그 매출 기준 아래의 회사에 MIT 조건으로 무료입니다. 같은 공개 페이지에는 두 가지 영구 상용 티어가 올라와 있습니다. Professional은 개발자 최대 10명에 999달러 + 현지 세금, Enterprise는 개발자 수를 세지 않고 조직 전체를 커버하며 2,999달러 + 현지 세금입니다. 둘 다 1년 업데이트와 프로젝트, 서버, 배포 수 무제한을 포함하며, 받은 마지막 버전의 라이선스는 만료되지 않습니다.

집행 모델도 매우 가볍습니다. 라이선스는 QuestPDF.Settings.License = LicenseType.Community; 한 줄로 설정합니다. 라이선스 키도 활성화 서버도 없고, QuestPDF 설정 페이지에 따르면 네트워크 호출도, 기계 밖으로 데이터가 나가는 일도 없습니다. 자신에게 맞는 티어를 직접 선택하는 신뢰 기반 모델입니다. 문서당 벤더 청구서는 없고, 유료 라이선스는 완전 오프라인을 포함해 어디서나 실행됩니다.

gPdf는 렌더링 서비스 자체에 가격을 붙입니다. 공개 Basic 플랜은 월 5달러에 10만 페이지부터 시작하고, 초과분은 페이지당 0.00005달러부터입니다. 벤더 청구서는 생기지만 PDF 생성을 운영하는 별도 프로젝트가 사라집니다. 렌더링 클러스터, NuGet 배포 경로, 리전별 워밍 풀, 앱별 폰트 패키지, 패치해야 할 PDF 서비스가 없습니다.

따라서 비용 비교는 “999달러 vs 5달러“가 아닙니다. 라이선스는 작은 줄입니다. 실제 비교는 이렇습니다.

QuestPDF total = license (one-time) + your hosting + your engineer-time + on-call
gPdf total     = page bill (infrastructure, fonts, scaling, and Edge included)

공개 페이지 단가 기준으로 gPdf 초과 사용은 1,000페이지당 0.05달러입니다(100만 페이지는 50달러, 1,000만 페이지는 500달러). 일회성 2,999달러 Enterprise 라이선스는 이 페이지 청구액만 놓고 봐도 약 6,000만 페이지 근처에서야 손익분기점에 닿습니다. 이 계산은 QuestPDF의 호스팅과 엔지니어 투입을 제외합니다. 이미 렌더링 인프라를 아주 싸게 운영하고 있는 경우가 아니라면 실제 교차점은 더 gPdf 쪽으로 밀립니다. 경험칙은 간단합니다. 라이브러리를 쓰기 위해 렌더링 서비스를 만들고 운영 인력을 붙여야 한다면 페이지 청구액이 라이선스를 따라잡기 훨씬 전부터 총비용에서 gPdf가 이기는 경우가 많습니다. 반대로 그 인프라가 이미 있고 거의 공짜에 가깝다면 대규모에서는 영구 라이선스가 유리합니다.

개발 흐름: Fluent C#과 템플릿

QuestPDF의 Fluent API는 개발자가 문서 형태를 소유할 때 잘 맞습니다. 강한 타입, 메서드 체인, 재사용 가능한 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, 그리고 UN/CEFACT Cross Industry Invoice (CII) 표준 기반 ZUGFeRD 2.1 / Factur-X 예제를 포함한 강한 표준 지원을 보여 줍니다. 그 예제는 PdfA = true를 설정하고, factur-x.xml를 AddAttachment()로 첨부하고, XMP 메타데이터로 문서를 확장한 뒤 veraPDF(PDF/A-3b)와 Mustang Project(ZUGFeRD)로 결과를 검증합니다. 완성도 있고 솔직한 레시피입니다. 그리고 파이프라인의 모든 단계는 당신이 관리합니다.

gPdf는 같은 표준을 안정적인 API 인터페이스로 제공합니다. JSON Render는 settings.profile을 통해 6개 PDF/A 프로필(1b, 2b, 3b, 4, 2u, 3u)과 PDF/UA-1을 제공합니다. Template Render는 같은 문서 모델을 재사용합니다. E-Invoice Render는 전용 POST /api/v1/e-invoice/render 엔드포인트를 제공해 EN 16931 CII XML이 임베드된 Factur-X / ZUGFeRD PDF/A-3b 패키지를 생성합니다. QuestPDF 레시피와의 차이는 서비스가 대신 해 주는 일입니다. gPdf는 PDF/A-3b와 전자 인보이스 검증을 서버 측에서 실행하고, 동기 인라인 또는 폴링 객체 전달을 지원하며, EU 또는 글로벌 데이터 레지던시를 직접 조립하는 단계가 아니라 요청 설정으로 제공합니다. 검증이 자체 .NET 파이프라인 안에 있어야 한다면 QuestPDF, 여러 시스템이 공유하는 호스팅 인터페이스여야 한다면 gPdf입니다.

폰트와 바코드: 실제 비교 대상은 연동과 운영 부담입니다

QuestPDF에는 강한 폰트 모델이 있습니다. 기본으로 Lato 2.015를 제공하고, 시스템 및 배포 디렉터리 폰트를 자동 로드하며, FontManager로 사용자 지정 폰트를 등록하고 대체 폰트 체인도 지원합니다. 개발자에게 제어권을 주는 방식입니다. 하지만 같은 문서는 함정도 솔직히 말합니다. 대부분의 클라우드 배포에는 사용할 수 있는 폰트가 거의 없거나 전혀 없어 예상치 못한 결과가 날 수 있고, 환경 폰트를 끄고 필요한 폰트를 명시적으로 등록하라고 권합니다. 즉 컨테이너나 서버리스 대상에서는 폰트 환경을 계획하고, 배포하고, 테스트하는 책임이 팀에 있습니다. 누락된 글리프는 대체 문자로 보이거나, CheckIfAllTextGlyphsAreAvailable를 켜면 예외가 됩니다.

gPdf는 폰트를 서비스 경계의 일부로 둡니다. Edge 렌더링 서비스는 라틴, 그리스, 키릴, 아랍, 히브리, 벵골, 타밀, 태국, 베트남 문자와 고정폭 텍스트, 그리고 Noto KR / JP / SC로 스크립트별 대체 폰트가 있는 CJK까지 다중 스크립트 세트를 번들합니다. 암시적 자동 선택으로 조용한 폰트 선택을 처리하고, 명시적 선택은 prefer 또는 strict로 처리합니다. 호출자는 CJK 폰트를 배포하거나, .NET 앱에 Noto 자산을 등록하거나, 배포 대상마다 대체 폰트를 조정하지 않습니다. 데이터를 보내면 서비스가 모든 리전에서 같은 폰트 환경을 유지합니다.

바코드 비교도 비슷합니다. 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에서는 바코드 생성이 일급 gPdf schema 요소입니다. 요청이 형식, 내용, 물리 크기, 선택적 사람이 읽는 라인을 선언합니다. GS1 형식이 기본 제공되므로 응용 식별자(AI)는 그대로 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와 사람이 읽는 해석 라인이 필요한 물류와 리테일 워크로드라면, 같은 ZXing 연결을 모든 서비스에서 반복 구현하기보다 바코드 동작을 문서 API로 밀어내는 쪽이 유지보수하기 쉽습니다.

QuestPDF가 명확히 이기는 영역

오프라인으로 실행되고 문서 데이터를 내부 경계 안에 둘 수 있다는 점은 이미 다뤘습니다. 또 PDF 코드 자체가 제품의 일부이고, 팀이 렌더링 경로를 검사하고, 확장하고, 소유해야 한다면 QuestPDF가 강합니다. 여기에 gPdf 범위 밖에 있는 두 기능 영역이 있습니다.

• 기존 PDF에 대한 작업. QuestPDF는 기존 파일을 열어 병합하고, 페이지를 선택 / 재정렬 / 역순 / 필터링하고, 오버레이를 적용하고, 첨부를 추가하고, XMP 메타데이터를 설정하고, 웹 전달용으로 선형화하며, 40/128/256비트 보안으로 암호화와 복호화를 모두 수행할 수 있습니다. gPdf는 자신이 생성한 PDF에 비밀번호 보호와 권한 제어를 적용할 수 있지만, 자신이 만들지 않은 파일을 열거나 병합하거나 복호화하지 않습니다.
• 차트, 지도, 사용자 지정 그래픽. QuestPDF는 차트 라이브러리(ScottPlot, LiveCharts, Microcharts), Mapbox 지도, 임의의 2D 드로잉을 위한 SkiaSharp canvas를 통합합니다. gPdf는 path 요소(SVG 경로 데이터)로 벡터 아트를 그리거나 상위 시스템에서 만든 SVG / PNG 차트를 삽입할 수 있지만, 내장 차트 엔진, 지도, canvas는 없습니다. 데이터 기반 차트가 문서의 중심이면 그 도구는 QuestPDF 쪽에 있습니다.

gPdf가 명확히 이기는 영역

gPdf는 모든 제품 팀이 각자의 PDF 서비스를 직접 운영하고 싶지 않은 조직에서 강합니다. 여러 언어를 쓰는 스택, 글로벌 업무 흐름, ERP / OMS / WMS / 이커머스 / 핀테크 / 티켓팅 시스템이 구조화 데이터에서 문서를 렌더링하고, 템플릿이 코드와 독립적으로 바뀌는 환경입니다. 이런 환경에서는 로컬 라이브러리가 처음에는 싸게 보이다가 플릿이 됩니다. 언어별 서비스, 리전별 배포 경로, 컨테이너별 폰트 계획, 팀별 바코드 회귀가 생깁니다. gPdf는 그 플릿을 하나의 안정적인 HTTP 인터페이스로 바꿉니다.

서버리스에서는 경계가 더 선명합니다. AWS Lambda, Cloud Run, Azure Functions에서도 QuestPDF는 애플리케이션 안에서 실행됩니다. 팀은 .NET 실행 환경, 폰트, 네이티브 의존성, 최대 PDF 작업을 감당할 CPU / 메모리를 패키징하고 콜드 스타트를 책임집니다. gPdf는 이미 렌더링 서비스입니다. 함수는 작은 template_id + data 요청을 Edge에 POST하고 PDF 바이트를 돌려받습니다. 데워 둘 렌더링 구성 요소도, 리전별로 확장할 작업자도 없습니다.

마이그레이션 형태

QuestPDF에서 gPdf로의 이전은 한 줄씩 옮기는 작업이 아닙니다. 경계 변경입니다. PDF를 만드는 C# 코드가 JSON 문서 요청 또는 게시된 템플릿으로 바뀝니다.

- // 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는 PDF 생성을 담당합니다.

가격과 출처에 대한 참고

이 페이지의 QuestPDF 정보는 2026-06-02에 공식 QuestPDF 출처에서 확인했습니다. License and Pricing, License configuration, Features Overview, Companion App features, Barcodes, Font management, ZUGFeRD example입니다. 가격과 기능 페이지는 바뀔 수 있으므로 조달팀은 구매 결정 전에 벤더 페이지를 다시 확인해야 합니다. QuestPDF와 관련 표장은 각 소유자에게 있으며, 이 비교는 그들의 보증을 받은 것이 아닙니다.

관련 PDF 생성 시나리오

QuestPDF와 gPdf를 비교하는 팀은 보통 .NET 안에서 렌더링을 소유할지, 여러 서비스가 공유하는 PDF API로 옮길지를 함께 검토합니다. 구조화된 문서 계층을 API로 두려면 JSON-PDF 변환 API와 템플릿 PDF API를 보세요. 구체적인 업무는 인보이스 PDF API, 배송 라벨 PDF API, GS1 바코드 API가 기준이 됩니다. 보관과 전자 인보이스가 중요하면 PDF/A API, Factur-X API, ZUGFeRD API도 함께 비교하세요.

FAQ

gPdf가 QuestPDF를 대체하나요?

아니요. gPdf는 구조화된 업무 문서를 위한 PDF 생성 서비스를 직접 운영해야 하는 필요를 대체합니다. PDF가 애플리케이션 안에서 생성되어야 할 때 QuestPDF는 여전히 강한 로컬 C# 라이브러리입니다.

QuestPDF는 무료인가요?

QuestPDF 공개 라이선스 페이지에 따르면 Community tier는 조건을 만족하는 개인, 오픈소스 프로젝트, 비영리단체, 연간 총매출 100만 달러 미만 회사에 MIT 조건으로 무료입니다. 그 기준을 넘는 회사는 영구 상용 라이선스가 필요합니다. Professional은 개발자 최대 10명에 999달러 + 현지 세금, Enterprise는 조직 전체에 2,999달러 + 현지 세금이며 각각 1년 업데이트를 포함합니다.

gPdf도 QuestPDF처럼 차트나 지도를 생성할 수 있나요?

내장 엔진으로는 아닙니다. QuestPDF는 차트 라이브러리(ScottPlot, LiveCharts, Microcharts), Mapbox 지도, 문서 안에서 렌더링되는 SkiaSharp canvas를 통합합니다. gPdf도 SVG 경로 데이터를 받는 path 요소와 도형으로 벡터 차트를 그리거나, 임의의 차트 라이브러리가 만든 SVG / PNG를 image로 삽입할 수 있습니다. 차이는 QuestPDF가 차트를 프로세스 내부에서 계산하고 렌더링하는 반면, gPdf에서는 차트 아트를 만들고 gPdf가 그것을 배치한다는 점입니다. 데이터 기반 차트나 지도가 문서의 중심이면 QuestPDF가 더 맞습니다.

어느 제품이 더 저렴한가요?

경계에 따라 다릅니다. QuestPDF는 Community 조건 대상이거나 렌더링 인프라를 이미 운영하는 .NET 팀에 더 저렴할 수 있습니다. gPdf는 대안이 제품이나 리전을 가로지르는 PDF 서비스를 만들고, 호스팅하고, 유지보수하는 것이라면 더 저렴할 수 있습니다.

gPdf는 문서 데이터를 저장하거나 로그로 남기나요?

아니요. 사용자가 보낸 JSON과 gPdf가 반환하는 PDF는 저장되지 않습니다. 각 요청은 단일 Cloudflare Workers V8 isolate 안에서 렌더링되고, 렌더링 동안만 메모리에 있습니다. 일반적으로 약 4 ms이며 응답 스트림이 끝나면 해제됩니다. gPdf는 DocumentRequest 내용을 보관, 로깅, 샘플링, 학습하지 않습니다. 운영 로그는 30일 동안 HTTP 상태와 소요 시간만 보관하며 요청 본문을 포함하지 않습니다. security policy, privacy policy, DPA를 참고하세요. 데이터를 전혀 전송할 수 없는 워크로드에는 온프레미스 / 전용 배포가 내부 경계 안에 유지하는 방식입니다.

QuestPDF는 인터넷 연결 없이 실행할 수 있나요?

네. QuestPDF 라이선스 설정 페이지는 라이선스 키나 활성화 서버가 없고 계산이 로컬에서 수행된다고 설명합니다. QuestPDF를 선택하는 가장 명확한 이유 중 하나입니다.

gPdf가 임의의 C# QuestPDF 레이아웃을 그대로 렌더링할 수 있나요?

아니요. gPdf는 C# 레이아웃 코드를 실행하지 않습니다. 이전은 문서 형태를 gPdf JSON 요청 또는 저장된 gPdf 템플릿으로 변환하는 일입니다.