คู่มือการย้ายระบบ
คู่มือการย้ายระบบ
หัวข้อที่มีชื่อว่า “คู่มือการย้ายระบบ”NextPDF เป็นเอนจิน Portable Document Format (PDF) 2.0 สำหรับ PHP หากคุณสร้าง PDF ด้วยไลบรารีอื่นอยู่แล้ว คู่มือการย้ายระบบจะแมป application programming interface (API) ของไลบรารีนั้นไปยัง NextPDF และบันทึกความแตกต่างเชิงพฤติกรรมที่คุณจะพบ ดัชนีข้ามรีโพนี้บันทึกว่าคู่มือใดย้ายคุณมาจากไลบรารีใด รีโพใดเป็นเจ้าของแต่ละคู่มือ และโมเดลร่วมที่ทุกคู่มือใช้
เนื่องจากหน้านี้เป็นดัชนี จึงไม่กล่าวอ้างเชิงพฤติกรรมใดๆเกี่ยวกับคู่มือใด คู่มือแต่ละฉบับเป็นของรีโพของตนเอง ตัวรวบรวมจะดึงคู่มือเข้ามายังไซต์นี้ และจนกว่าคู่มือจะพร้อม ลิงก์ของคู่มือจะชี้ไปยังตัวยึดตำแหน่ง การกล่าวอ้างเชิงพฤติกรรมทั้งหมดอยู่ในตัวคู่มือเอง โดยมีการทดสอบในรีโพหรือข้อกำหนด ISO 32000-2 / Cascading Style Sheets Working Group (CSS WG) ที่ตรึงไว้รองรับ ไม่ใช่ในหน้านี้
โมเดลการย้ายระบบหนึ่งเดียว
หัวข้อที่มีชื่อว่า “โมเดลการย้ายระบบหนึ่งเดียว”คู่มือการย้ายระบบของ NextPDF ทุกฉบับใช้โมเดลที่ตรงไปตรงมาแบบเดียวกัน อ่านแต่ละคู่มือโดยคำนึงถึงโมเดลนั้น:
- เข้ากันได้ แต่ไม่เหมือนกันในระดับไบต์ NextPDF และไลบรารีที่คุณกำลังเลิกใช้เป็นการนำไปใช้งานที่เป็นอิสระต่อกัน เอกสารที่ย้ายแล้วจะรักษาเจตนาเชิงฟังก์ชัน ไม่ใช่ความเหมือนกันในระดับพิกเซลหรือไบต์ ไม่มีคู่มือใดกล่าวอ้างว่าเป็นการแทนที่แบบ drop-in หรือเข้ากันได้ 100%
- ความครอบคลุมเป็นจำนวนที่วัดได้ ไม่ใช่การยืนยัน เมื่อคู่มือระบุตัวเลขความครอบคลุม เช่น ตัวเลขของอะแดปเตอร์ TCPDF ตัวเลขนั้นเป็นเมตริกความครบถ้วนเชิงฟังก์ชันที่ได้จากเมทริกซ์ในรีโพ ในความหมายของ ISO/IEC 25023 ข้อ 43 ตัวเลขนี้เป็นจำนวนเมธอดที่ครอบคลุมซึ่งวัดได้ ไม่ใช่การรับประกันแบบครอบคลุมทั้งหมด
- แต่ละคู่มือระบุความแตกต่างเชิงพฤติกรรมอย่างเปิดเผย ทุกคู่มือมีตารางความแตกต่างที่ชัดเจนและส่วน “unsupported / no direct equivalent” ความแตกต่างเหล่านี้เป็นคุณสมบัติของเอนจินที่บันทึกไว้ ไม่ใช่ข้อบกพร่อง
- การเปลี่ยนเรนเดอเรอร์ต้องมีการทบทวนใหม่ การย้ายระบบทำให้โค้ดเปลี่ยนแปลงและต้องสร้างเบสไลน์ผลลัพธ์ใหม่ แต่ละคู่มืออธิบายวิธีทดสอบการย้ายระบบ การยอมรับเชิงภาพเป็นรายเอกสาร และยังคงเป็นความรับผิดชอบของผู้ผสานรวม
รูปแบบของการย้ายระบบ
หัวข้อที่มีชื่อว่า “รูปแบบของการย้ายระบบ”คู่มือแบ่งออกเป็นสองรูปแบบ แต่ละรูปแบบบอกคุณว่าโค้ดต้องเปลี่ยนแปลงมากน้อยเพียงใด
- การย้ายระบบแบบเขียน API ใหม่ ไม่มีชิมความเข้ากันได้ ทุกจุดที่เรียกใช้จะถูกเขียนใหม่โดยใช้การแมปคำกริยาและการแมปตัวเลือกของคู่มือ การย้ายระบบจากไลบรารี Hypertext Markup Language (HTML) เป็น PDF (
dompdf,mpdf) ใช้รูปแบบนี้ โดยมุ่งไปยัง Html pipeline ของ NextPDF โดยตรง - การย้ายระบบแบบ drop-in แล้วค่อยย้าย มาพร้อมอะแดปเตอร์ที่เข้ากันได้กับซอร์สเกือบทั้งหมด การย้ายขั้นแรกจึงเป็นเพียงการสลับ dependency เล็กน้อย จากนั้นคุณจะค่อยๆย้ายจุดที่เรียกใช้ไปยัง API สมัยใหม่ แล้วจึงเลิกใช้อะแดปเตอร์ การย้ายระบบ TCPDF ใช้รูปแบบนี้ผ่าน
nextpdf/compat-legacyซึ่งเป็นอะแดปเตอร์
ข้อมูลอ้างอิงคู่มือและรีโพที่เป็นเจ้าของ
หัวข้อที่มีชื่อว่า “ข้อมูลอ้างอิงคู่มือและรีโพที่เป็นเจ้าของ”คู่มือทุกฉบับด้านล่างอยู่ใน docs/public/ ของรีโพที่เป็นเจ้าของ และตัวรวบรวมจะดึงคู่มือเข้ามายังไซต์นี้ รีโพที่เป็นเจ้าของเป็นแหล่งอ้างอิงที่เชื่อถือได้สำหรับการกล่าวอ้างเชิงพฤติกรรมของคู่มือนั้น ดัชนีนี้บันทึกเฉพาะการกำหนดเส้นทางเท่านั้น
| จาก | คู่มือ | รูปแบบ | รีโพที่เป็นเจ้าของ | หน้า |
|---|---|---|---|---|
| Dompdf | Dompdf → Html pipeline ของ NextPDF | เขียน API ใหม่ | nextpdf (core) | คู่มือ Dompdf dompdf (วางแผนไว้ที่ต้นทาง) |
| mPDF | mPDF → NextPDF core | เขียน API ใหม่ | nextpdf (core) | คู่มือ mPDF mpdf (วางแผนไว้ที่ต้นทาง) |
| TCPDF 6.x | TCPDF → NextPDF ผ่านอะแดปเตอร์ compat-legacy | Drop-in แล้วค่อยย้าย | nextpdf-compat-tcpdf รีโพ แพ็กเกจ nextpdf/compat-legacy | คู่มือ TCPDF tcpdf-compat (วางแผนไว้ที่ต้นทาง) |
คู่มือ dompdf และ mpdf อยู่ในรีโพ core เพราะมุ่งไปยัง API ของเอนจิน core และมี examples/ ของ core รองรับ คู่มือ tcpdf-compat อยู่ในรีโพ compat-tcpdf เพราะแพ็กเกจ nextpdf/compat-legacy เป็นเจ้าของพื้นผิวเชิงพฤติกรรมของ TCPDF และการทดสอบอะแดปเตอร์ที่รองรับคู่มือนี้ ดัชนีนี้เป็นของรีโพ docs โดยธรรมชาติ เพราะครอบคลุมหลายรีโพ และไม่กล่าวอ้างเชิงพฤติกรรมใดๆเกี่ยวกับคู่มือฉบับใดฉบับหนึ่ง
แต่ละคู่มือมีไว้สำหรับอะไร
หัวข้อที่มีชื่อว่า “แต่ละคู่มือมีไว้สำหรับอะไร”- Dompdf → NextPDF (
dompdf(วางแผนไว้ที่ต้นทาง)) — สำหรับโค้ดเบสฝั่งเซิร์ฟเวอร์ที่ใช้dompdf/dompdfคู่มือนี้แมปloadHtml/render/outputและคีย์Optionsไปยัง Html pipeline ของ NextPDF และส่งต่อความคาดหวังด้านฟีเจอร์ CSS ไปยังเมทริกซ์การรองรับ CSS แบบ Verified-only ไม่มีชิมคลาส Dompdf คุณต้องเขียนทุกจุดที่เรียกใช้ใหม่ - mPDF → NextPDF (
mpdf(วางแผนไว้ที่ต้นทาง)) — สำหรับโค้ดเบสที่ใช้mpdf/mpdfคู่มือนี้แมปWriteHTML/Output/AddPageและอาร์เรย์การตั้งค่าของคอนสตรักเตอร์ไปยัง API ของ core โดยมีความแตกต่างด้านการจัดการฟอนต์หนึ่งประการ คือ NextPDF แก้ไขฟอนต์ผ่านไดเรกทอรีฟอนต์เดียวร่วมกับการจับคู่ CSS และทำ subset เสมอ ไม่มีชิมคลาส Mpdf - TCPDF → NextPDF (compat-legacy) (
tcpdf-compat(วางแผนไว้ที่ต้นทาง)) — สำหรับโค้ดเบส TCPDF 6.x ที่ต้องการให้การเปลี่ยนแปลงขั้นแรกมีน้อยที่สุด ติดตั้งอะแดปเตอร์ ตรวจสอบพื้นผิวจริงของคุณด้วยโหมด strict เทียบกับเมทริกซ์ความครอบคลุมในรีโพ ย้ายจุดที่เรียกใช้ออกจากอะแดปเตอร์ จากนั้นเพิ่มโครงสร้างแท็กแบบ PDF/Universal Accessibility (PDF/UA-2) ทับลงไป ซึ่งเป็นความสามารถที่ TCPDF ไม่เคยมี อะแดปเตอร์เป็นโครงนั่งร้าน ไม่ใช่ปลายทาง และไม่ใช่การรับประกันแบบ drop-in
วิธีที่ลิงก์ของคู่มือถูกแก้ไขให้ชี้ไป
หัวข้อที่มีชื่อว่า “วิธีที่ลิงก์ของคู่มือถูกแก้ไขให้ชี้ไป”ตัวยึดตำแหน่ง [[…]] แต่ละตัวด้านบนชี้ไปยังหน้าที่อยู่ในรีโพที่เป็นเจ้าของภายใต้ docs/public/migration/ และตัวรวบรวมจะดึงหน้านั้นเข้ามายังไซต์นี้ slug ปลายทางใช้รูปแบบเดียวกัน:
/migration/<source>/โทเค็น <source> เป็นชื่อย่อของไลบรารีที่คุณกำลังย้ายออกมา ซึ่งเป็นหนึ่งใน dompdf, mpdf หรือ tcpdf-compat ตามที่ระบุไว้ในตารางอ้างอิงคู่มือด้านบน จนกว่าหน้าปลายทางจะถูกรวบรวมเข้ามา ลิงก์ของหน้านั้นจะยังคงเป็นตัวยึดตำแหน่งและไม่นำไปยังปลายทาง ดัชนีนี้ไม่กล่าวอ้างเชิงพฤติกรรมใดๆเกี่ยวกับคู่มือปลายทางใดๆ แต่บันทึกเฉพาะการกำหนดเส้นทางและโมเดลการย้ายระบบร่วมเท่านั้น
ดูเพิ่มเติม
หัวข้อที่มีชื่อว่า “ดูเพิ่มเติม”- เมทริกซ์การรองรับ CSS — แหล่งอ้างอิงแบบ Verified-only สำหรับความคาดหวังด้านฟีเจอร์ CSS ในคู่มือ
dompdfและmpdf - ตำราการผสานรวม — ดัชนีข้ามรีโพสำหรับแพ็กเกจการผสานรวมในระบบนิเวศ ตำรานี้ครอบคลุมประเด็นอีกด้านหนึ่ง คือการเชื่อมต่อเข้ากับเอนจิน ไม่ใช่การย้ายมายังเอนจิน