QuestPDF ยอดเยี่ยมเมื่อ C# คือขอบเขตผลิตภัณฑ์
QuestPDF ควรถูกเปรียบเทียบอย่างให้เกียรติ มันเป็นไลบรารีสร้าง PDF สมัยใหม่สำหรับนักพัฒนา C# มี fluent API, strong typing, เอกสารละเอียด, Companion App สำหรับ preview และ debug และโมเดลไลเซนส์ที่ชัดเจนมากสำหรับ PDF SDK
คำถามไม่ใช่ “ตัวไหนสร้าง PDF ได้” เพราะทั้งคู่ทำได้ คำถามที่มีประโยชน์คือขอบเขตของ PDF ควรอยู่ตรงไหน: ในแอป .NET ที่เป็นเจ้าของเลย์เอาต์ ไฟล์ และวงจรชีวิตทั้งหมด หรือในบริการโครงสร้างพื้นฐานที่หลายผลิตภัณฑ์และหลายภาษาเรียกใช้
คู่มือเลือกแบบเร็ว
- เลือก QuestPDF เมื่อ C# คือแหล่งอ้างอิงหลักของเอกสาร แอปต้องรันออฟไลน์ หรือคุณต้องทำงานกับ PDF เดิมในเครื่อง
- เลือก gPdf เมื่อ PDF layer เดียวควรให้บริการ Node, Python, Go, .NET, job และระบบแต่ละภูมิภาคผ่าน HTTP API เดียวกัน
- เลือก gPdf เมื่อการเปลี่ยนเลย์เอาต์ควรเป็น revision ของเทมเพลต ไม่ใช่การ rebuild C# และ redeploy service ใหม่
เอกสารตระกูลเดียวกัน แต่โมเดลความเป็นเจ้าของต่างกัน
เมื่อใช้ QuestPDF แอปเป็นเจ้าของการสร้าง PDF นี่เป็นจุดแข็งจริง: C# อยู่ใกล้ domain model, รันและ debug ได้ในเครื่อง และไม่มี call ไปยัง API ภายนอกตอนรันจริง
ข้อแลกเปลี่ยนคือทีมของคุณต้องดูแลพื้นผิว production ที่เหลือด้วย:
- CPU และ memory สำหรับการเรนเดอร์
- การค้นหาฟอนต์และ fallback ในแต่ละสภาพแวดล้อม deploy
- การเชื่อมต่อไลบรารีบาร์โค้ดและ print QA
- package แบบ native และงาน deploy สำหรับ charting หรือ custom graphics integration
- monitoring, retry และการจัดการความล้มเหลว
- การ deploy ตามภูมิภาคเมื่อผู้ใช้หรือคลังสินค้ากระจายทั่วโลก
- rollout ทุกครั้งที่เลย์เอาต์เอกสารเปลี่ยน
เมื่อใช้ gPdf พื้นที่ความรับผิดชอบนั้นย้ายไปอยู่ที่บริการ แอปส่ง DocumentRequest หรือ template_id + data แล้วบริการดูแลตัวเรนเดอร์ runtime บน Edge ฟอนต์ primitive ของบาร์โค้ด output แบบ PDF/A และแพ็กเกจ e-invoice ให้ วิธีนี้ไม่น่าสนใจถ้าคุณต้องการควบคุมทุกอย่างใน C# แต่น่าสนใจมากขึ้นถ้าการสร้าง PDF ควรเป็นชั้นบริการกลางที่ทุก stack เรียกใช้ได้
trade-off 3 ข้อที่ API แบบโฮสต์ต้องตอบตรง ๆ
pitch แบบ “library vs API” จำนวนมากข้ามคำถามแรก ๆ ที่สถาปนิก .NET จะถาม การเปรียบเทียบที่แฟร์ต้องตอบให้ชัด
1. ข้อมูลเอกสารไปที่ไหน หน้านี้พูดถึงใบแจ้งหนี้ ใบแจ้งยอด และ e-invoice เป็นหลัก ซึ่งเป็นเอกสารที่มีชื่อ ที่อยู่ เลขภาษี และยอดเงิน เมื่อใช้ QuestPDF ไฟล์เหล่านั้นถูกสร้างใน process ของคุณและไม่ออกไปไหน public gPdf API ส่งข้อมูลคำขอไปยังตัวเรนเดอร์ แต่ตัวเรนเดอร์ไม่เก็บข้อมูล: request JSON อยู่ใน Cloudflare Workers V8 isolate เฉพาะช่วงเรนเดอร์ (ทั่วไปประมาณ 4 ms) และถูกปล่อยเมื่อ response จบ ไม่ถูกจัดเก็บ บันทึก log สุ่มตัวอย่าง หรือใช้ฝึกโมเดล โดย operational log จำกัดอยู่ที่ HTTP status และระยะเวลา (security, DPA) การเลือกถิ่นที่อยู่ข้อมูล EU / global และ enterprise on-prem / private deployment ช่วยลดหรือปิดช่องเปิดนี้ได้มากขึ้น ถึงอย่างนั้น การเก็บงานสร้างเอกสารไว้ใน process โดยไม่ต้องตั้งค่าเพิ่มก็เป็นเหตุผลที่ถูกต้อง และบางครั้งเป็นเหตุผลตัดสิน สำหรับทีมการเงินหรือภาครัฐที่เลือก QuestPDF
2. รูปแบบความล้มเหลว library ไม่มีผู้ให้บริการรายที่สามให้ล่ม งานสร้างเอกสารจะล้มได้เฉพาะบนโครงสร้างพื้นฐานที่คุณเป็นเจ้าของอยู่แล้ว API แบบโฮสต์เพิ่ม dependency ด้านความพร้อมใช้งานที่คุณควบคุมไม่ได้ วิธีใช้ gPdf ที่ถูกต้องคือปฏิบัติกับ render call เหมือน external call อื่น: timeout, retry, queue และถ้าเป็นไปได้ควรมี fallback แบบลดระดับบริการ ถ้างานสร้างเอกสารอยู่บนเส้นทาง synchronous ที่สำคัญ ให้ชั่งน้ำหนักระหว่าง “ดูแลเอง” กับ “พึ่ง uptime ของผู้ให้บริการ”
3. โปรไฟล์เวลาแฝง in-process generation คือ function call ไม่มี network ส่วน hosted call คือ network round-trip สำหรับ batch และ async job เรื่องนี้มักเป็น noise แต่สำหรับ “ผู้ใช้คลิกแล้ว PDF ต้องขึ้นทันที” in-process ย่อมเร็วกว่าในเชิงโครงสร้าง gPdf Edge PoPs ทำให้ hop สั้น แต่ก็ยังเป็น TLS + round-trip ส่วน QuestPDF คือ method call
สิ่งเหล่านี้ไม่ได้ทำให้ gPdf เป็นตัวเลือกที่ผิด แต่มันบอกว่า gPdf เหมาะเมื่อไร: ทีมที่ยอมให้ข้อมูลเอกสารออกจาก process ได้, กระบวนการทำงานทน network hop ได้ และทีมอยากพึ่ง uptime ของผู้ให้บริการมากกว่าดูแลชุดบริการเรนเดอร์เอง
ไลเซนส์และโมเดลราคา
หน้าไลเซนส์สาธารณะของ QuestPDF ระบุว่า commercial license จำเป็นเฉพาะบริษัทที่มีรายได้รวมต่อปีเกิน 1 ล้านดอลลาร์สหรัฐ Community tier ฟรีสำหรับบุคคล, open-source project, non-profit และบริษัทที่ต่ำกว่า threshold นี้ ภายใต้ MIT terms หน้าเดียวกันระบุ commercial tier แบบถาวร 2 แบบ: Professional 999 ดอลลาร์สหรัฐบวกภาษีท้องถิ่นสำหรับทีมไม่เกิน 10 developers และ Enterprise 2,999 ดอลลาร์สหรัฐบวกภาษีท้องถิ่น ครอบคลุมทั้งองค์กรโดยไม่คิดจำนวน developers ทั้งคู่รวมอัปเดต 1 ปี ใช้ได้ไม่จำกัด project, server และ deployment และไลเซนส์ไม่หมดอายุสำหรับ version ล่าสุดที่ได้รับ
โมเดล enforcement ก็เบาเป็นพิเศษ ตั้ง license ด้วยบรรทัดเดียว: QuestPDF.Settings.License = LicenseType.Community; ไม่มี license key ไม่มี activation server และตามหน้า configuration ของ QuestPDF เอง ไม่มี network call และไม่มีข้อมูลออกจากเครื่อง เป็นระบบอาศัยความซื่อสัตย์: คุณเลือก tier ที่ตัวเองเข้าเงื่อนไข ไม่มีบิลผู้ให้บริการต่อเอกสาร และไลเซนส์แบบชำระเงินรันได้ทุกที่ รวมถึงออฟไลน์เต็มรูปแบบ
gPdf ตั้งราคาบริการเรนเดอร์โดยตรง public Basic plan เริ่มที่ 5 ดอลลาร์สหรัฐ/เดือนสำหรับ 100,000 หน้า โดยส่วนเกินเริ่มที่ 0.00005 ดอลลาร์สหรัฐ/หน้า นี่เป็นบิลผู้ให้บริการ แต่ก็ตัดงานดูแลระบบสร้าง PDF ออกไป: ไม่มี render cluster, ไม่มี deployment path ผ่าน NuGet, ไม่มี warm pool รายภูมิภาค, ไม่มี font package ต่อแอป และไม่มีบริการ PDF ให้ patch
ดังนั้นการเทียบต้นทุนไม่ใช่ “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 คือ 0.05 ดอลลาร์สหรัฐต่อ 1,000 หน้า (50 ดอลลาร์สหรัฐต่อ 1 ล้านหน้า, 500 ดอลลาร์สหรัฐต่อ 10 ล้านหน้า) Enterprise license แบบจ่ายครั้งเดียว 2,999 ดอลลาร์สหรัฐจะคุ้มเท่ากับบิลนี้ใกล้ 60 ล้านหน้า แต่เลขนี้ยังไม่รวม hosting และ engineer-months ของ QuestPDF ซึ่งมักดันจุดคุ้มทุนจริงให้เข้าข้าง gPdf มากขึ้น เว้นแต่คุณมีโครงสร้างพื้นฐานเรนเดอร์ที่ถูกมากอยู่แล้ว หลักจำง่ายคือ ถ้าคุณต้อง build และจัดคนดูแลบริการเรนเดอร์เพื่อใช้ library, gPdf มักชนะด้าน total cost นานก่อนที่บิลต่อหน้าจะไล่ทันค่าไลเซนส์ แต่ถ้า infrastructure นั้นมีอยู่แล้วและแทบไม่มีต้นทุนเพิ่ม ไลเซนส์ถาวรจะชนะเมื่อ scale สูงมาก
กระบวนการพัฒนา: Fluent C# หรือเทมเพลต
Fluent API ของ QuestPDF เหมาะมากเมื่อนักพัฒนาเป็นเจ้าของรูปทรงเอกสาร strong typing, method chain, component C# ที่ใช้ซ้ำได้, refactor ใน IDE และ Companion App ล้วนเข้าท่าเมื่อ PDF เป็นส่วนหนึ่งของ codebase ของแอป
gPdf เหมาะกับกระบวนการอีกแบบ นักพัฒนายังเขียน JSON โดยตรงได้ แต่ระบบจริงมักขยับไปสู่เทมเพลต นักออกแบบ ทีมปฏิบัติการ หรือ engineer ปรับเลย์เอาต์ใน gPdf Studio เลย์เอาต์ที่อนุมัติแล้วกลายเป็นเทมเพลต แล้ว backend เรนเดอร์ต่อด้วย template_id + data
ความต่างนี้สำคัญเมื่อเอกสารเปลี่ยนบ่อย ถ้าเลย์เอาต์ของป้ายขนส่ง ใบแจ้งหนี้ packing slip หรือ statement เปลี่ยน gPdf ทำให้ runtime คงเดิมและขยับเฉพาะเทมเพลตได้ เมื่อใช้ QuestPDF เลย์เอาต์คือโค้ด C# เส้นทางปกติจึงเป็น code change, test, build, deploy และ rollback plan
ไม่มีกระบวนการไหนดีกว่าเสมอ QuestPDF เหมาะกับ C# developer ที่ต้องการ document as code; gPdf เหมาะกับเทมเพลตปฏิบัติการที่ใช้ร่วมกันข้ามระบบ
Compliance: ทั้งสองผลิตภัณฑ์จริงจัง
นี่ไม่ใช่การเปรียบเทียบที่ gPdf ชนะด้วยการบอกว่าคู่แข่งไม่มี compliance feature เอกสารสาธารณะปัจจุบันของ QuestPDF ระบุการรองรับมาตรฐานที่แข็งแรง รวมถึง PDF/A, PDF/UA-1 และ e-invoicing ตาม EN 16931 ผ่านตัวอย่าง ZUGFeRD 2.1 / Factur-X บนมาตรฐาน UN/CEFACT Cross Industry Invoice (CII) ตัวอย่างนั้นตั้ง PdfA = true, ฝัง factur-x.xml ด้วย AddAttachment(), เพิ่ม XMP metadata และตรวจด้วย veraPDF (สำหรับ PDF/A-3b) กับ Mustang Project (สำหรับ ZUGFeRD) เป็น recipe ที่ครบและตรงไปตรงมา และ pipeline ของคุณเป็นเจ้าของทุกขั้น
gPdf แพ็กมาตรฐานเดียวกันเป็น API contract JSON Render เปิด PDF/A 6 profile (1b, 2b, 3b, 4, 2u, 3u) พร้อม PDF/UA-1 ผ่าน settings.profile, Template Render ใช้ document model เดียวกัน และ E-Invoice Render มี endpoint เฉพาะ POST /api/v1/e-invoice/render ที่สร้างแพ็กเกจ Factur-X / ZUGFeRD PDF/A-3b พร้อมฝัง EN 16931 CII XML ความต่างจาก recipe ของ QuestPDF คือบริการทำอะไรแทนคุณ: gPdf ตรวจ PDF/A-3b และ e-invoice ฝั่ง server, รองรับการส่งไฟล์กลับแบบ synchronous inline หรือแบบ polled object และให้ถิ่นที่อยู่ข้อมูล EU หรือ global เป็น request setting แทนขั้นตอนที่คุณต้องประกอบและดูแลเอง QuestPDF เหมาะเมื่อ validation ควรอยู่ใน .NET pipeline ของคุณ; gPdf เหมาะเมื่อมันควรเป็น hosted contract ที่หลายระบบใช้ร่วมกัน
ฟอนต์และบาร์โค้ด: แรงงานเชื่อมต่อคือการเปรียบเทียบจริง
QuestPDF มีโมเดลฟอนต์ที่ดี มัน ship Lato 2.015 เป็นค่าเริ่มต้น โหลดฟอนต์จากระบบและโฟลเดอร์ deploy อัตโนมัติ ให้ register custom font ผ่าน FontManager และรองรับ fallback chain สิ่งนี้ให้การควบคุมกับ developer แต่เอกสารเดียวกันก็พูดตรงถึงข้อควรระวัง: “in most cloud deployments, few or no fonts are available” และแนะนำให้ปิด environment fonts พร้อม register ฟอนต์ที่ต้องใช้เอง พูดอีกแบบคือบน container หรือ serverless target, สภาพแวดล้อมฟอนต์เป็นสิ่งที่คุณต้องวางแผน แพ็ก และทดสอบเอง glyph ที่หายอาจกลายเป็น placeholder character หรือถ้าเปิด CheckIfAllTextGlyphsAreAvailable ก็กลายเป็น exception
gPdf ทำให้ฟอนต์เป็นส่วนหนึ่งของขอบเขตบริการ ตัวเรนเดอร์ bundle ชุด multi-script: Latin, Greek, Cyrillic, Arabic, Hebrew, Bengali, Tamil, Thai, Vietnamese, monospace และ CJK พร้อม fallback แยกตาม script ไปยัง Noto KR / JP / SC การเลือกฟอนต์แบบเงียบใช้ implicit auto selection ส่วนการระบุชัดใช้ prefer หรือ strict ฝั่งที่เรียกไม่ต้อง ship CJK font, register Noto asset ในแอป .NET หรือจูน fallback แยกตามเป้าหมาย deploy เขาส่งข้อมูลมา; renderer ดูแลสภาพแวดล้อมฟอนต์ที่เหมือนกันทุกภูมิภาค
การเปรียบเทียบบาร์โค้ดมีรูปแบบคล้ายกัน เอกสารบาร์โค้ดของ QuestPDF แสดงแนวทางที่ดีด้วย ZXing.Net เรนเดอร์เป็น vector SVG และระบุชัดว่า ZXing.Net ไม่รวมอยู่ใน package ของ 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 การสร้างบาร์โค้ดเป็น schema element ชั้นหนึ่ง request ระบุ format, content, ขนาดจริง และบรรทัดข้อความอ่านด้วยตาแบบ optional และรูปแบบ GS1 เป็น native ดังนั้นตัวระบุแอปพลิเคชัน (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 และทดสอบ output อาจง่ายพอ แต่สำหรับหลายบริการและหลายเทมเพลต โดยเฉพาะงานโลจิสติกส์และค้าปลีกที่ต้องใช้ GS1-128, SSCC, GTIN, GS1 DataMatrix หรือ GS1 QR พร้อมบรรทัด human-readable interpretation การย้ายพฤติกรรมบาร์โค้ดเข้า document API ดูแลง่ายกว่าการต่อ ZXing แบบเดิมซ้ำในทุกบริการ
จุดที่ QuestPDF ชนะชัดเจน
นอกเหนือจากการรันออฟไลน์และการเก็บข้อมูลเอกสารไว้ในขอบเขตระบบของคุณตามที่พูดไปแล้ว หากโค้ด PDF เองเป็นส่วนหนึ่งของผลิตภัณฑ์และทีมต้อง inspect, extend หรือเป็นเจ้าของเส้นทางเรนเดอร์ QuestPDF ยังมี capability 2 ส่วนที่อยู่นอกขอบเขตของ gPdf อย่างชัดเจน:
- การทำงานกับ PDF เดิม QuestPDF โหลดไฟล์เดิมแล้วรวมไฟล์ เลือก/จัดลำดับ/ย้อนลำดับ/กรองหน้า ใส่ overlay แนบไฟล์ ตั้ง XMP metadata ทำ linearization สำหรับส่งผ่านเว็บ และทำได้ทั้งเข้ารหัสและถอดรหัสด้วย 40/128/256-bit security gPdf ใส่รหัสผ่านและจำกัดสิทธิ์ PDF ที่ตัวเองสร้างได้ แต่ไม่เปิด รวมไฟล์ หรือถอดรหัสไฟล์ที่ไม่ได้สร้าง
- กราฟ แผนที่ และ custom graphics QuestPDF เชื่อมต่อ charting library (ScottPlot, LiveCharts, Microcharts), ฝัง Mapbox maps และเปิด SkiaSharp canvas สำหรับวาด 2D ได้ตามต้องการ gPdf วาด vector art ด้วย element
path(SVG path data) หรือฝังกราฟ SVG / PNG ที่สร้าง upstream ได้ แต่ไม่มี charting engine, แผนที่ หรือ canvas ในตัว ดังนั้นถ้า data-driven charting เป็นแกนของเอกสาร tooling นั้นอยู่ฝั่ง QuestPDF
จุดที่ gPdf ชนะชัดเจน
gPdf ชนะเมื่อองค์กรไม่อยากให้ทุกทีมผลิตภัณฑ์ดูแลบริการ PDF ของตัวเอง: stack หลายภาษา กระบวนการระดับโลก และระบบ ERP / OMS / WMS / ecommerce / fintech / ticketing ที่เรนเดอร์เอกสารจากข้อมูลแบบมีโครงสร้าง โดยเทมเพลตเปลี่ยนแยกจากโค้ด ในสภาพแวดล้อมแบบนี้ local library มักเริ่มต้นถูก แต่ค่อย ๆ กลายเป็นชุดระบบกระจาย: หนึ่ง service ต่อภาษา หนึ่งเส้นทาง deploy ต่อภูมิภาค หนึ่งแผนฟอนต์ต่อ container และหนึ่งชุด regression ของบาร์โค้ดต่อทีม gPdf เปลี่ยนชุดระบบนี้เป็น HTTP contract เดียว
serverless ทำให้ขอบเขตชัดที่สุด บน AWS Lambda, Cloud Run หรือ Azure Functions, QuestPDF ยังรันอยู่ใน application ทีมของคุณต้องแพ็ก .NET runtime, ฟอนต์, native dependency และ CPU / memory ให้พอสำหรับ peak PDF work พร้อมรับผิดชอบ cold start เอง gPdf เป็น render service อยู่แล้ว: function POST request เล็ก ๆ template_id + data ไปยัง Edge และได้ PDF bytes กลับมา โดยไม่มี renderer ให้ warm หรือ worker รายภูมิภาคให้ scale
รูปแบบการย้าย
การย้ายจาก QuestPDF ไป gPdf ไม่ใช่การ rewrite ทีละบรรทัด แต่เป็นการเปลี่ยนขอบเขต: โค้ด C# ที่ build PDF กลายเป็น JSON document request หรือเทมเพลตที่ publish แล้ว
Before / after — call สร้างเอกสารใน 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();หลังขอบเขตย้ายแล้ว การเปลี่ยนเลย์เอาต์สามารถเป็น revision ของเทมเพลตแทนการ deploy แอปใหม่ แอปยังเป็นเจ้าของข้อมูลธุรกิจและการตัดสินใจของกระบวนการ; gPdf เป็นเจ้าของการเรนเดอร์
บันทึกเรื่องราคาและแหล่งข้อมูล
ข้อมูล QuestPDF ในหน้านี้ตรวจเมื่อ 2026-06-02 จากแหล่งทางการของ QuestPDF: License and Pricing, License configuration, Features Overview, Companion App features, Barcodes, Font management และ ZUGFeRD example ราคาและหน้า feature เปลี่ยนได้ ทีมจัดซื้อควรตรวจหน้า vendor อีกครั้งก่อนตัดสินใจซื้อ QuestPDF และเครื่องหมายที่เกี่ยวข้องเป็นของเจ้าของแต่ละราย การเปรียบเทียบนี้ไม่ได้รับการรับรองจากพวกเขา
สถานการณ์ PDF ที่เกี่ยวข้อง
ถ้าคุณกำลังเทียบ QuestPDF กับ gPdf จุดอ่านต่อควรขึ้นกับขอบเขตที่ตัดสินใจ: สำหรับทีม .NET ที่อยากเรียก hosted PDF API ให้ดู API แปลง JSON เป็น PDF และ API PDF ใบแจ้งหนี้; สำหรับโลจิสติกส์และค้าปลีก ให้ดู API ป้ายจัดส่ง PDF และ API บาร์โค้ด GS1-128; สำหรับ compliance ให้ดู API PDF/A, API Factur-X และ API ZUGFeRD ถ้าคุณกำลังประเมินว่าจะดูแล render service เองหรือไม่ ให้เริ่มจาก เอกสารอ้างอิง gPdf API
FAQ
gPdf แทน QuestPDF หรือไม่?
ไม่ gPdf แทนความจำเป็นในการดูแล PDF generation service สำหรับเอกสารธุรกิจแบบมีโครงสร้าง QuestPDF ยังเป็น local C# library ที่แข็งแรงเมื่อ PDF ควรถูกสร้างภายใน application
QuestPDF ฟรีไหม?
หน้าไลเซนส์สาธารณะของ QuestPDF ระบุว่า Community tier ฟรีภายใต้ MIT terms สำหรับบุคคล, open-source project, non-profit และบริษัทที่มีรายได้รวมต่อปีต่ำกว่า 1 ล้านดอลลาร์สหรัฐ บริษัทที่เกิน threshold ต้องใช้ไลเซนส์เชิงพาณิชย์แบบถาวร: Professional 999 ดอลลาร์สหรัฐบวกภาษีท้องถิ่นสำหรับนักพัฒนาไม่เกิน 10 คน หรือ Enterprise 2,999 ดอลลาร์สหรัฐบวกภาษีท้องถิ่น ครอบคลุมทั้งองค์กร แต่ละแบบรวมอัปเดต 1 ปี
gPdf สร้างกราฟหรือแผนที่แบบ QuestPDF ได้ไหม?
ไม่ใช่ในฐานะ engine ในตัว QuestPDF เชื่อมต่อ charting library (ScottPlot, LiveCharts, Microcharts), Mapbox maps และ SkiaSharp canvas ที่เรนเดอร์ในเอกสารได้ gPdf ยังวาด vector chart ด้วย element path (รับ SVG path data) และ shape หรือฝัง SVG / PNG จาก charting library ใดก็ได้เป็น image ความต่างคือ QuestPDF คำนวณและเรนเดอร์ chart ใน process ส่วน gPdf ให้คุณสร้างภาพ chart แล้ววางลงในเอกสาร ถ้า data-driven charting หรือแผนที่เป็นศูนย์กลาง QuestPDF เหมาะกว่า
ผลิตภัณฑ์ไหนถูกกว่า?
ขึ้นกับขอบเขต QuestPDF อาจถูกกว่าสำหรับทีม .NET ที่เข้าเงื่อนไข Community terms หรือมี render infrastructure อยู่แล้ว gPdf อาจถูกกว่าเมื่อทางเลือกคือ build, host และ maintain PDF service ข้ามหลาย product หรือหลายภูมิภาค
gPdf เก็บหรือ log document data ของฉันไหม?
ไม่ JSON ที่คุณส่งและ PDF ที่ gPdf คืนกลับไม่ถูกจัดเก็บ แต่ละ request เรนเดอร์ใน Cloudflare Workers V8 isolate เดียว อยู่ใน memory เฉพาะช่วงเรนเดอร์ โดยทั่วไปประมาณ 4 ms และถูกปล่อยเมื่อ response stream จบ gPdf ไม่ retain, log, sample หรือ train บนเนื้อหา DocumentRequest operational log เก็บเฉพาะ HTTP status และระยะเวลา 30 วัน ไม่มี request body ดู security policy, privacy policy และ DPA สำหรับ workload ที่ส่งข้อมูลออกไม่ได้เลย on-prem / private deployment ทำให้ข้อมูลอยู่ในขอบเขตระบบของคุณ
QuestPDF รันโดยไม่มี internet access ได้ไหม?
ได้ หน้า license configuration ของ QuestPDF ระบุว่าไม่มี license key หรือ activation server และการคำนวณเกิดในเครื่อง นี่เป็นเหตุผลที่ชัดที่สุดข้อหนึ่งในการเลือก QuestPDF
gPdf render C# QuestPDF layout ใด ๆ ได้ไหม?
ไม่ได้ gPdf ไม่ execute C# layout code การย้ายหมายถึงการแปลงรูปทรงเอกสารเป็น gPdf JSON request หรือ gPdf template ที่บันทึกไว้