Fast Web View: PDF เปิดได้ก่อนที่จะดาวน์โหลดเสร็จได้อย่างไร

SpecSpec: ISO 32000-2, Annex FISO 32000-2 Annex F

ภาพรวมโดยสังเขป

PDF ที่ผ่าน linearization ถูกจัดเรียงใหม่เพื่อให้หน้าแรกและดัชนีนำทางขนาดเล็กอยู่ที่ส่วนหน้าสุดของไฟล์ ดังนั้นโปรแกรมอ่านจึงสามารถวาดหน้าแรกได้ในขณะที่ส่วนที่เหลือของเอกสารยังเดินทางมาไม่ถึง และกระโดดตรงไปยังหน้า 147 ได้โดยไม่ต้องอ่านหน้า 2 ถึง 146 ก่อน

นี่คือคุณสมบัติที่ผู้อ่านส่วนใหญ่รู้จักในชื่อที่เป็นกันเอง: Fast Web View

เหตุใดเรื่องนี้จึงสำคัญ

ลองนึกภาพรายงาน 200 หน้าบนโทรศัพท์ที่มีสัญญาณเพียงขีดเดียว หากไม่มี linearization โปรแกรมอ่านมักต้องการส่วนท้ายสุดของไฟล์ก่อนจึงจะวาดอะไรได้เลย เพราะดัชนีหลักที่บอกว่าทุกอ็อบเจกต์อยู่ที่ใดตามปกติจะอยู่ด้านหลัง ดังนั้นคุณจึงต้องนั่งดูวงล้อหมุนขณะที่สองร้อยหน้าดาวน์โหลด เพียงเพื่อจะอ่านหน้าแรก

เมื่อมี linearization ไฟล์จะถูกจัดเรียงให้คำตอบของคำถามที่ว่า “หน้าแรกมีอะไร” เป็นสิ่งแรกที่ออกจากสาย ผู้อ่านวาดหน้าแรกในวินาทีเดียว และดึงส่วนที่เหลือมาเฉพาะเมื่อคุณเลื่อนหรือกระโดดเท่านั้น บนการเชื่อมต่อที่เร็วคุณอาจไม่ทันสังเกต แต่บนการเชื่อมต่อที่ช้าหรือคิดค่าตามปริมาณ มันคือความแตกต่างระหว่างเอกสารที่ใช้ได้กับแท็บที่ถูกทิ้งไป

ฉบับย่อ

• ไฟล์ที่ผ่าน linearization ถูก วางไว้ด้านหน้า: หน้าแรกและ hint table ถูกวางไว้ก่อน ก่อนส่วนเนื้อหาที่เหลือ
• hint table คือแผนที่ของ ช่วงไบต์ มันบอกโปรแกรมอ่านว่าช่วงไบต์ใดเป็นของแต่ละหน้าและของอ็อบเจกต์ที่ใช้ร่วมกัน เพื่อให้โปรแกรมอ่านขอ เฉพาะส่วนที่ต้องการ จากเซิร์ฟเวอร์ได้ — จากนั้น cross-reference table จะแปลงหมายเลขอ็อบเจกต์แต่ละตัวให้เป็นออฟเซ็ตที่แม่นยำ
• สิ่งนี้พึ่งพา byte-range request — โปรแกรมอ่านดึงส่วนต่างๆของไฟล์ตามต้องการ ไม่ใช่ทั้งไฟล์
• ไบต์เป็นเนื้อหาที่เหมือนกับ PDF ปกติทุกประการ linearization เปลี่ยน ลำดับและดัชนี ไม่ใช่ตัวหน้าเอง
• มันเป็นขั้นตอนเดียวที่ชัดเจนและสลับเปิดปิดได้ใน NextPDF — สร้างขึ้นด้วยการสร้างใหม่แบบสามรอบที่แท้จริง ไม่ใช่แฟล็กที่ได้แต่หวังว่าจะดี

NextPDF จัดการเรื่องนี้อย่างไร

คุณไม่สามารถวางหน้าหนึ่งไว้ด้านหน้าได้จนกว่าจะรู้แน่ชัดว่าทุกอย่างมีขนาดเท่าใด เพราะ hint table บันทึกออฟเซ็ตไบต์ และออฟเซ็ตจะถูกต้องก็ต่อเมื่อความยาวของทุกอ็อบเจกต์เป็นค่าสุดท้ายแล้ว ความเป็นวงกลมนั้น — ออฟเซ็ตขึ้นอยู่กับขนาด ขนาดขึ้นอยู่กับเลย์เอาต์ — คือเหตุผลที่ตัว linearizer ทำงานเป็นรอบๆ แทนที่จะกวาดทีเดียว

NextPDF แก้ปัญหานี้ด้วยการสร้างใหม่แบบสามรอบที่กำหนดผลแน่นอน รอบแรกวัดขนาด รอบที่สองตัดสินใจการจัดวาง รอบที่สามเขียนไบต์จริงโดยฝังออฟเซ็ตที่ทราบแล้วเข้าไป

1. MEASURESerialise every object once to learn its exact byte length. Offsets are circular — they depend on sizes — so sizes are pinned first.
2. PLACEDecide the order: first page and its dependencies up front, then the rest. Reserve space for the linearization parameter dictionary and the hint table.
3. FILLWrite the final bytes. Each reserved field is filled with values computed after MEASURE and PLACE — the first-page length, the hint-table location, the main cross-reference offset — derived from the measured sizes and the chosen placement.

The three-pass linearization rebuild. MEASURE sizes every object so lengths are final; PLACE decides the front-loaded order and reserves the hint-table region; FILL writes the real bytes with the now-known offsets, so the first page and the hint table land at the front and the cross-reference data resolves on first fetch.

เอาต์พุตมี linearization parameter dictionary เป็นอ็อบเจกต์แรก และมี hint table หนึ่งตัวหรือมากกว่าที่ทำดัชนีให้กับหน้าต่างๆ ตรงตามที่มาตรฐานกำหนดไว้พอดี (SpecSpec: ISO 32000-2, Annex FISO 32000-2 Annex F) hint table เหล่านั้นทำงาน ควบคู่ไปกับ cross-reference table แบบดั้งเดิม — โดยบันทึกช่วงไบต์และตำแหน่งที่โปรแกรมอ่านต้องดึง ส่วน cross-reference table คือดัชนีที่แปลงหมายเลขอ็อบเจกต์แต่ละตัวให้เป็นออฟเซ็ตไบต์ที่แม่นยำ ตัว linearizer ของ NextPDF ปล่อยตารางในรูปแบบดั้งเดิมและขับ cross-reference stream ใดๆออกไประหว่างทาง ดังนั้นเมื่อส่วนของไฟล์มาถึง ผู้อ่านจะแปลงอ็อบเจกต์ด้วยออฟเซ็ตของมันได้โดยตรงจากตารางนั้น (SpecSpec: ISO 32000-2, §7.5.4ISO 32000-2 §7.5.4)

โมเดลทางความคิดที่เป็นประโยชน์: PDF ปกติคือหนังสือที่มีสารบัญติดอยู่กับปก หลัง PDF ที่ผ่าน linearization ย้ายหน้าสารบัญนั้นมาไว้ด้านหน้า และเพิ่มดัชนีเลขหน้าต่อหน้า เพื่อให้คุณเปิดไปยังหน้าใดก็ได้โดยตรง เนื้อหาบทต่างๆไม่เปลี่ยนแปลง มีเพียงการนำทางเท่านั้นที่ย้าย

ตัวอย่างเชิงปฏิบัติ

linearization เป็นขั้นตอนที่ชัดเจนและสลับเปิดปิดได้ คุณร้องขอมัน เอนจินดำเนินการสร้างใหม่และปล่อยไฟล์แบบ Fast-Web-View ออกมา

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Contracts\OutputDestination;

$document = Document::createStandalone();
$document->setTitle('Annual Report');

for ($page = 1; $page <= 200; $page++) {
    $document->addPage();
    $document->setFont('helvetica', '', 12);
    $document->cell(0, 12, "Page {$page}", newLine: true);
}

// Linearization is requested explicitly — an operability choice, not a default.
// enableLinearization() takes no arguments; it is the on-switch. The engine
// runs the MEASURE -> PLACE -> FILL rebuild and emits a Fast-Web-View file
// with the first page and hint table at the front.
$document->enableLinearization();

$bytes = $document->output(dest: OutputDestination::String);

เนื้อหาของหน้าคือสิ่งที่คุณเขียนไว้ทุกประการ ความแตกต่างอยู่ที่ ลำดับของไฟล์ ของไบต์ที่คุณได้รับ และที่ hint table ซึ่งตอนนี้อยู่ใกล้ด้านบน

คุณตรวจสอบผลลัพธ์ในแบบที่คนแปลกหน้าจะทำ — ด้วยเครื่องมือตรวจสอบภายนอก:

$ qpdf --check-linearization report.pdf
report.pdf: no linearization errors

qpdf --check-linearization ไม่ได้เพียงมองหาแฟล็ก มันคำนวณออฟเซ็ตที่ไฟล์ อ้าง ขึ้นใหม่และยืนยันว่าออฟเซ็ตเหล่านั้นเป็นจริง: ว่าอ็อบเจกต์ของหน้าแรกอยู่ที่ที่ linearization dictionary บอกไว้จริง ว่า hint table ชี้ไปยังไบต์ที่ถูกต้อง และว่าโครงสร้างเป็นไปตาม Annex F ไฟล์ที่โกหกเกี่ยวกับเลย์เอาต์ของตัวเองจะไม่ผ่านการตรวจสอบนี้ แม้จะดูเหมือนผ่าน linearization แล้วเมื่อมองเผินๆก็ตาม

ความเข้าใจผิดที่พบบ่อย

ข้อสันนิษฐานที่พบบ่อยคือ linearization บีบอัดไฟล์หรือทำให้การดาวน์โหลดเร็วขึ้นโดยรวม มันไม่ทำทั้งสองอย่าง ไฟล์ที่ผ่าน linearization มักจะ ใหญ่ขึ้น ไม่กี่ไบต์ เพราะมันบรรจุ hint table เพิ่มเข้ามา เวลาในการถ่ายโอนทั้งเอกสารโดยรวมแทบไม่เปลี่ยนแปลง

สิ่งที่เปลี่ยนไปคือ เมื่อใดที่พิกเซลแรกที่ใช้ประโยชน์ได้ปรากฏขึ้น linearization ปรับให้ดีที่สุดเรื่อง time-to-first-page ไม่ใช่จำนวนไบต์ทั้งหมด มันเป็นคุณสมบัติด้าน latency ไม่ใช่คุณสมบัติด้านการบีบอัด การสตรีมหน้าแรกออกมาแต่เนิ่นๆกับการดาวน์โหลดไฟล์ให้เร็วเป็นเป้าหมายที่ต่างกัน และ linearization ตอบโจทย์ข้อแรก

ความเข้าใจผิดข้อที่สองคือเซิร์ฟเวอร์เว็บใดๆจะสตรีมไฟล์ที่ผ่าน linearization ได้ โปรแกรมอ่านต้องดึงช่วงไบต์ ซึ่งหมายความว่าเซิร์ฟเวอร์ต้องยอมรับ HTTP range request ส่วนใหญ่ยอมรับ แต่เซิร์ฟเวอร์ที่ส่งคืนทั้งไฟล์เสมอจะทำให้ Fast Web View กลับกลายเป็นการรอทั้งไฟล์ที่ช้า — ไฟล์พร้อมจะสตรีมแล้ว แต่การขนส่งไม่พร้อม

Human-factors note:Human-factors note

Linearization is an explicit, switchable step, and that is deliberate. It costs an extra serialisation pass to produce, and it helps most for large documents served over slow links and opened in a browser. For a small invoice generated and emailed as an attachment, it adds work for no benefit. Making it a switch rather than an always-on default lets you spend that cost exactly where a reader feels it — the big public report on a phone — and skip it where they never would.

ขีดจำกัดและขอบเขต

NextPDF รองรับการสร้างไฟล์ที่ผ่าน linearization อย่างเต็มที่ในคอร์: ตัว linearizer แบบสามรอบระดับโปรดักชันที่ปล่อย parameter dictionary และ hint table ออกมา และผ่านการตรวจสอบ Annex F ภายนอก

Fast Web View (linearization) output — edition availability

Edition	Availability
Core	○ Full support. NextPDF produces linearized (Fast Web View) output through a production three-pass MEASURE → PLACE → FILL rebuild, conforming to ISO 32000-2 Annex F.
Pro	○Not in this edition
Enterprise	○Not in this edition

มีขอบเขตสองข้อที่ควรกล่าวถึง ข้อแรก linearization เป็นคุณสมบัติของ รีวิชันเดียว ทันทีที่คุณต่อท้าย incremental update — ลายเซ็น การกรอกฟอร์ม การแก้ไข — ไบต์ที่ต่อท้ายจะไปอยู่ที่ส่วนท้าย และไฟล์จะไม่อยู่ในสภาพ linearized อย่างเคร่งครัดอีกต่อไปจนกว่าจะถูกสร้างใหม่ นั่นเป็นการแลกเปลี่ยนตามปกติ ไม่ใช่ข้อบกพร่อง ดู incremental updates สำหรับเหตุผลว่าทำไมการต่อท้ายจึงเป็นพฤติกรรมที่ถูกต้องสำหรับเอกสารที่มีลายเซ็น

ข้อที่สอง เอนจินควบคุมไฟล์ มันไม่ควบคุมเครือข่าย Fast Web View จะให้ผลตามที่สัญญาไว้ก็ต่อเมื่อการเชื่อมต่อที่ให้บริการยอมรับ byte-range request เท่านั้น ไบต์อาจผ่าน linearization อย่างสมบูรณ์แต่ยังมาถึงเป็นก้อนเดียวที่ช้าได้ หากเซิร์ฟเวอร์ยืนยันที่จะส่งทั้งไฟล์

เอกสารที่เกี่ยวข้อง

• กายวิภาคของไฟล์ PDF — ส่วนหัว เนื้อหา cross-reference table และ trailer ที่ linearization จัดเรียงใหม่ อ่านหน้านี้ก่อนเพื่อเห็นว่าอะไรกำลังถูกจัดลำดับใหม่
• หน่วยความจำและการสตรีม — การสตรีมฝั่งเขียน ซึ่งเป็นแกนที่ต่างออกไป: วิธีที่ NextPDF รักษาหน่วยความจำให้คงที่ขณะ สร้าง ไบต์ เทียบกับวิธีที่ ผู้อ่าน สตรีมไบต์เหล่านั้นเข้ามา
• Incremental update และเหตุผลที่สำคัญ — เหตุใดการแก้ไขในภายหลังจึงต่อท้ายไปที่ส่วนท้าย และนั่นหมายความว่าอย่างไรกับเลย์เอาต์แบบวางด้านหน้าของไฟล์ที่ผ่าน linearization
• สตรีมและฟิลเตอร์ — สิ่งที่อยู่ภายในอ็อบเจกต์เนื้อหาที่ hint table ชี้ไป และวิธีที่อ็อบเจกต์เหล่านั้นถูกบีบอัด

อภิธานศัพท์

• Linearization — การสร้างใหม่ที่วางหน้าแรกและดัชนีนำทางไว้ด้านหน้า เพื่อให้โปรแกรมอ่านเรนเดอร์และนำทางได้ก่อนที่ทั้งไฟล์จะมาถึง ชื่อที่มาตรฐานใช้เรียกผลลัพธ์
• Fast Web View — ชื่อที่หันสู่ผู้บริโภคของ PDF ที่ผ่าน linearization ทั้งสองคำอธิบายไฟล์เดียวกัน
• Hint table — โครงสร้างภายในไฟล์ที่ผ่าน linearization ซึ่งบันทึก ช่วงไบต์และตำแหน่ง ของแต่ละหน้าและของอ็อบเจกต์ที่ใช้ร่วมกัน เพื่อให้โปรแกรมอ่านรู้ว่าจะขอส่วนใด ส่วน cross-reference table คือสิ่งที่แปลงหมายเลขอ็อบเจกต์ให้เป็นออฟเซ็ตไบต์ที่แม่นยำ
• Linearization parameter dictionary — อ็อบเจกต์แรกในไฟล์ที่ผ่าน linearization มันประกาศออฟเซ็ตสำคัญ (ความยาวหน้าแรก ตำแหน่ง hint table ตำแหน่ง cross-reference หลัก) ที่ทำให้การดึงตามต้องการเป็นไปได้
• Byte-range request — คำขอ HTTP สำหรับส่วนหนึ่งของไฟล์แทนที่จะเป็นทั้งไฟล์ กลไกการขนส่งที่ Fast Web View พึ่งพา
• Time-to-first-page — ระยะเวลาจนกว่าผู้อ่านจะเห็นหน้าแรก คือ latency ที่ linearization ปรับให้ดีที่สุด แตกต่างจากเวลาดาวน์โหลดทั้งหมด