เลือก integration

ใช้หน้านี้เพื่อจับคู่กรณีการใช้งานของคุณกับ integration ที่รองรับ คำแนะนำแต่ละรายการอ้างอิงเฉพาะคำอธิบายใน composer.json ของแพ็กเกจและวัตถุประสงค์ที่ระบุไว้เท่านั้น โดยข้อมูลทั้งสองส่วนอ่านโดยตรงจาก source repository เมื่อ integration สองตัวมีขอบเขตทับซ้อนกัน หน้านี้จะระบุปัจจัยที่ทำให้แตกต่างกัน เพื่อให้เลือกได้อย่างมั่นใจ

ค้นหาแถวที่ตรงกับสถานการณ์ของคุณ แล้วเริ่มจากจุดนั้น

เริ่มต้นที่นี่: คุณมีอะไรอยู่?

คุณมี …	ใช้	เหตุผล (วัตถุประสงค์ที่ตรวจสอบยืนยันแล้ว)
แอปพลิเคชัน Laravel 12	`nextpdf/laravel`	integration สำหรับเฟรมเวิร์ก Laravel: service provider, facade และ helper สำหรับ response แบบ Portable Document Format (PDF)
แอปพลิเคชัน Symfony 7	`nextpdf/symfony`	บันเดิล Symfony: บริการ dependency injection (DI) และ helper สำหรับ response แบบ PDF
แอปพลิเคชัน CodeIgniter 4	`nextpdf/codeigniter`	บริการ CodeIgniter 4, library wrapper และ helper สำหรับ response แบบ PDF
แอป PHP ที่ไม่ใช้เฟรมเวิร์ก	`nextpdf/core` โดยตรง	ไม่จำเป็นต้องมี integration สำหรับเฟรมเวิร์ก เนื่องจากเอนจินเป็น library ปกติ
HTML ที่ต้องใช้เอนจิน Cascading Style Sheets (CSS) ของเบราว์เซอร์ และสามารถรัน Chrome ได้	`nextpdf/artisan`	ตัวเรนเดอร์ผ่าน Chrome DevTools Protocol (CDP) สำหรับ HTML ที่ต้องใช้เค้าโครง CSS ระดับเบราว์เซอร์
เอกสาร Office ที่ต้องแปลง เช่น DOCX, XLSX หรือ ODT	`nextpdf/gotenberg`	การแปลง Office เป็น PDF ผ่าน microservice ของ Gotenberg
งานเรนเดอร์ที่ไม่ต้องมีกระบวนการเบราว์เซอร์ให้ดูแล	`nextpdf/cloudflare`	การเรนเดอร์แบบ serverless ผ่าน Cloudflare Browser Rendering API บน edge
โค้ดที่เขียนโดยอ้างอิง library PDF รุ่นเดิม	`nextpdf/compat-legacy`	เลเยอร์ความเข้ากันได้สำหรับ library PDF รุ่นเดิม ช่วยเรียกใช้ NextPDF ได้โดยไม่ต้องเขียน call site ใหม่
รันไทม์ที่ยังติดอยู่กับ PHP 8.1 / 7.4	`nextpdf/backport-builder`	ไปป์ไลน์ดาวน์เกรดด้วย Rector สำหรับสร้างเป้าหมาย 8.1 / 7.4 ของเอนจิน
ผู้เรียกจากระยะไกล ภาษาอื่น หรือระบบปัญญาประดิษฐ์ (AI)	`nextpdf/server`	NextPDF Connect: ส่วนติดต่อแบบ Representational State Transfer (REST), gRPC และ Model Context Protocol สำหรับการเรียกใช้งานจากระยะไกล

เมื่อ integration สองตัวอาจเหมาะสมทั้งคู่

การเรนเดอร์ HTML เป็น PDF: Artisan เทียบกับ Gotenberg เทียบกับ Cloudflare เทียบกับ core

บริดจ์ตัวเรนเดอร์ทั้งสามตัวแปลงมาร์กอัปเป็น PDF ความแตกต่างอยู่ที่วิธีทำงาน ไม่ใช่คุณภาพ ให้ใช้ความแตกต่างด้านการทำงานเหล่านี้เป็นปัจจัยในการตัดสินใจ

nextpdf/artisan ขับเคลื่อน Chrome แบบ headless ผ่าน Chrome DevTools Protocol ตัวเลือกนี้ต้องมีกระบวนการ Chrome ที่แอปพลิเคชันเข้าถึงได้ เลือกตัวเลือกนี้เมื่อคุณดูแลกระบวนการดังกล่าวได้ และเอกสารต้องใช้เอนจิน CSS ของเบราว์เซอร์
nextpdf/gotenberg เรียก microservice ของ Gotenberg นอกกระบวนการผ่าน HTTP เลือกตัวเลือกนี้เมื่อการเรนเดอร์ต้องแยกเป็นบริการของตัวเอง หรือเมื่ออินพุตเป็นเอกสาร Office Gotenberg เป็นเพียงตัวเดียวในสามตัวที่มีวัตถุประสงค์ที่ระบุไว้ครอบคลุมการแปลง Office เป็น PDF
nextpdf/cloudflare เรียก Cloudflare Browser Rendering API เลือกตัวเลือกนี้เมื่อคุณต้องการการเรนเดอร์แบบ edge/serverless โดยไม่ต้องรันหรือแพตช์กระบวนการเบราว์เซอร์เอง
ไปป์ไลน์ HTML ของ core NextPDF แบบในกระบวนการ ไม่ต้องพึ่งสิ่งใดข้างต้น ใช้บริดจ์ตัวเรนเดอร์เฉพาะเมื่อไปป์ไลน์แบบในกระบวนการไม่สามารถให้ความเที่ยงตรงของเค้าโครงหรือการแยกกระบวนการตามที่เอกสารต้องการได้ บริดจ์ตั้งใจส่งต่อขั้นตอนนั้นออกไปภายนอก ซึ่งไม่ใช่เส้นทางค่าเริ่มต้น

บริดจ์ HTTP ทั้งสองตัว (nextpdf/gotenberg, nextpdf/cloudflare) ต้องใช้ HTTP client แบบ PSR-18 ที่โฮสต์จัดหาให้ เรซิพีของบริดจ์เหล่านี้ถือว่าความล้มเหลวระดับการรับส่งข้อมูลและสถานะ HTTP ที่ไม่สำเร็จเป็นผลลัพธ์คนละประเภท

การแปลงเอกสาร Office

nextpdf/gotenberg เป็น integration ที่คำอธิบายซึ่งตรวจสอบยืนยันแล้วใน composer.json ระบุถึงการแปลง Office เป็น PDF บริดจ์ตัวเรนเดอร์อื่นอธิบายถึงการเรนเดอร์ HTML ไม่ใช่อินพุต Office หากต้นทางเป็น DOCX/XLSX/ODT ให้ใช้ integration นี้

การย้ายออกจาก library PDF รุ่นเดิม

ตามวัตถุประสงค์ที่ระบุไว้ nextpdf/compat-legacy เป็นเลเยอร์ความเข้ากันได้สำหรับ codebase ที่เขียนโดยอ้างอิง library PDF รุ่นเดิม เลเยอร์นี้ช่วยให้ call site ที่มีอยู่เข้าถึง NextPDF ได้ก่อนที่จะเขียนใหม่ ให้ถือว่าเลเยอร์นี้เป็นตัวช่วยในการย้ายระบบที่มีแผนจะถอดออก ไม่ใช่ dependency ของรันไทม์แบบถาวร โค้ดใหม่ควรเรียก nextpdf/core (หรือ integration ของเฟรมเวิร์กที่เกี่ยวข้อง) โดยตรง

การรันบน PHP 8.1 หรือ 7.4

แพ็กเกจทุกตัวในระบบนิเวศประกาศข้อกำหนด PHP >=8.4 <9.0 nextpdf/backport-builder มีไว้สำหรับข้อจำกัดนี้โดยเฉพาะ: วัตถุประสงค์ที่ระบุไว้คือไปป์ไลน์ดาวน์เกรด Rector ที่สร้างอาร์ทิแฟกต์สำหรับ PHP 8.1+ (และเป้าหมาย 7.4) เครื่องมือนี้ใช้สำหรับการบิลด์ ไม่ใช่ dependency ของรันไทม์สำหรับแอปพลิเคชันของคุณ รันตัวบิลเดอร์เพื่อสร้างเอนจินที่ backport แล้ว จากนั้นจึงดีพลอยเอนจินนั้น

ผู้เรียกที่ไม่ใช่ PHP หรือเอเจนต์ AI

nextpdf/server (NextPDF Connect) เปิดให้เข้าถึงเอนจินผ่าน REST API, บริการ gRPC และ Model Context Protocol เลือกตัวเลือกนี้เมื่อผู้เรียกอยู่ระยะไกล เขียนด้วยภาษาอื่น หรือเป็นระบบ AI ที่เรียกใช้ tool endpoint แทนที่จะเป็น library ของ PHP แอปพลิเคชัน PHP ที่อยู่ในกระบวนการเดียวกันควรใช้ nextpdf/core หรือ integration ของเฟรมเวิร์ก แทนการเพิ่ม network hop

การใช้ integration มากกว่าหนึ่งตัวร่วมกัน

integration ของเฟรมเวิร์กและบริดจ์ตัวเรนเดอร์ทำงานคนละเลเยอร์ จึงติดตั้งร่วมกันได้ integration ของเฟรมเวิร์กจัดการ container wiring และ response แบบ HTTP ส่วนบริดจ์ตัวเรนเดอร์จัดการแบ็กเอนด์การเรนเดอร์ เมื่อ resolve ชุด dependency ที่ใช้ร่วมกัน ให้ตรวจสอบว่าแต่ละแพ็กเกจยอมรับเวอร์ชันของ nextpdf/core ใดบ้าง ข้อจำกัดของ core ในดัชนีคุกบุ๊ก integration คือแหล่งข้อมูลอ้างอิงที่ถูกต้อง เรซิพีสำหรับแต่ละชุดการใช้งานร่วมกันอยู่ใน repository ที่เกี่ยวข้องและมีลิงก์จากดัชนีนั้น

ดูเพิ่มเติม

คุกบุ๊ก integration — ข้อมูลอ้างอิงของแพ็กเกจและข้อจำกัดของ core พร้อมดัชนีลิงก์เรซิพี
หลักปฏิบัติของเรซิพี — สัญญาที่เรซิพีซึ่งรันได้ทุกตัวปฏิบัติตาม