Fast Web View: cách một tệp PDF mở ra trước khi tải xong

Spec: ISO 32000-2, Annex F

Tổng quan nhanh

Một tệp PDF đã được linearization được sắp xếp lại sao cho trang đầu tiên cùng một chỉ mục điều hướng nhỏ nằm ngay phía trước nhất của tệp. Nhờ vậy một trình đọc có thể vẽ trang một trong khi phần còn lại của tài liệu vẫn đang về tới, và nhảy thẳng tới trang 147 mà không cần đọc các trang 2 đến 146 trước.

Đây là tính năng mà hầu hết người đọc biết đến bằng cái tên thân thiện của nó: Fast Web View.

Vì sao điều này quan trọng

Hãy hình dung một báo cáo 200 trang trên một chiếc điện thoại chỉ có một vạch sóng. Nếu không có linearization, trình đọc thường cần tới chính phần cuối của tệp trước khi có thể vẽ được bất cứ thứ gì, bởi vì chỉ mục chính cho biết mọi đối tượng nằm ở đâu theo truyền thống lại nằm ở phía sau. Thế là bạn nhìn một biểu tượng quay tròn trong khi hai trăm trang tải về, chỉ để đọc trang đầu tiên.

Với linearization, tệp được sắp xếp sao cho câu trả lời cho câu hỏi “trang một có gì” là thứ đầu tiên về tới từ đường truyền. Trình đọc vẽ trang một trong một giây, và chỉ lấy phần còn lại khi bạn cuộn hay nhảy trang. Trên một kết nối nhanh có thể bạn sẽ không bao giờ để ý. Trên một kết nối chậm hoặc bị tính dung lượng, đó là khác biệt giữa một tài liệu dùng được và một tab bị bỏ dở.

Tóm tắt ngắn gọn

Một tệp đã linearization được đặt phía trước: trang một và một hint table được xếp trước, trước phần thân còn lại.
Hint table là một bản đồ của các dải (range). Nó cho trình đọc biết những dải byte nào thuộc về mỗi trang và về các đối tượng dùng chung, nhờ vậy trình đọc có thể hỏi máy chủ đúng những lát cắt đó — rồi cross-reference table phân giải từng số đối tượng về đúng offset của nó.
Điều này dựa vào byte-range request — việc trình đọc lấy các lát cắt của tệp theo yêu cầu, chứ không phải lấy toàn bộ.
Các byte là nội dung giống hệt một tệp PDF thông thường. Linearization thay đổi thứ tự và chỉ mục, chứ không phải bản thân các trang.
Đó là một bước rõ ràng, bật/tắt được trong NextPDF — được tạo ra bởi một quá trình xây lại ba lượt thực thụ, chứ không phải một cờ chỉ biết hy vọng mọi thứ ổn.

NextPDF tiếp cận điều này như thế nào

Bạn không thể đặt một trang lên phía trước cho tới khi biết chính xác mọi thứ to cỡ nào, bởi vì hint table ghi lại các byte offset và một offset chỉ đúng khi độ dài của mọi đối tượng đã chốt. Tính vòng tròn đó — offset phụ thuộc vào kích thước, kích thước phụ thuộc vào bố cục — là lý do một bộ linearizer chạy theo nhiều lượt thay vì một lượt quét duy nhất.

NextPDF giải quyết nó bằng một quá trình xây lại ba lượt có tính tất định. Lượt thứ nhất đo đạc, lượt thứ hai quyết định vị trí, lượt thứ ba ghi các byte thật với các offset giờ đã biết được nung vào.

MEASURESerialise every object once to learn its exact byte length. Offsets are circular — they depend on sizes — so sizes are pinned first.
PLACEDecide the order: first page and its dependencies up front, then the rest. Reserve space for the linearization parameter dictionary and the hint table.
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.

Đầu ra mang theo một linearization parameter dictionary làm đối tượng đầu tiên của nó và một hoặc nhiều hint table lập chỉ mục cho các trang, đúng như tiêu chuẩn quy định (Spec: ISO 32000-2, Annex F). Các hint table đó làm việc song song với một cross-reference table truyền thống — chúng ghi lại các dải byte và vị trí mà một trình đọc cần lấy, trong khi cross-reference table là chỉ mục ánh xạ từng số đối tượng về đúng byte offset của nó. Bộ linearizer của NextPDF phát ra dạng table cổ điển và loại bỏ mọi cross-reference stream trên đường đi, nhờ vậy một khi một lát cắt về tới, trình đọc phân giải một đối tượng theo offset của nó thẳng từ chính cái table đó (Spec: ISO 32000-2, §7.5.4).

Một mô hình tư duy hữu ích: một tệp PDF thông thường là một cuốn sách có mục lục dán vào bìa sau. Một tệp PDF đã linearization chuyển trang mục lục đó ra phía trước và thêm một chỉ mục số-trang cho từng trang, nhờ vậy bạn có thể mở thẳng tới bất kỳ trang nào. Các chương không đổi. Chỉ phần điều hướng đã dịch chuyển.

Ví dụ thực tế

Linearization là một bước rõ ràng, bật/tắt được. Bạn yêu cầu nó; engine thực hiện quá trình xây lại và phát ra một tệp 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);

Nội dung trang đúng là thứ bạn đã soạn. Khác biệt nằm ở thứ tự trong tệp của các byte bạn nhận được, và ở hint table giờ đây nằm gần phía đầu.

Bạn xác minh kết quả theo cách một người lạ sẽ làm — bằng một bộ kiểm tra bên ngoài:

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

qpdf --check-linearization không chỉ tìm một cờ. Nó tính lại các offset mà tệp tuyên bố và xác nhận chúng đúng: rằng các đối tượng của trang đầu thật sự nằm đúng nơi linearization dictionary nói, rằng hint table trỏ vào đúng byte, và rằng cấu trúc tuân thủ Annex F. Một tệp nói dối về chính bố cục của mình sẽ trượt bài kiểm tra này ngay cả khi thoạt nhìn có vẻ đã linearization.

Hiểu lầm thường gặp

Giả định hay gặp là linearization nén tệp lại hoặc làm cho việc tải về nhanh hơn về tổng thể. Nó không làm cả hai. Một tệp đã linearization thường lớn hơn một vài byte, vì nó mang theo các hint table phụ thêm. Tổng thời gian truyền cho cả tài liệu về cơ bản không đổi.

Cái thay đổi là khi nào điểm ảnh hữu ích đầu tiên xuất hiện. Linearization tối ưu hóa thời-gian-tới-trang-đầu, chứ không phải tổng số byte. Đó là một tính năng về độ trễ, không phải một tính năng nén. Stream sớm trang một và tải tệp về nhanh là hai mục tiêu khác nhau, và linearization phục vụ mục tiêu thứ nhất.

Một hiểu lầm thứ hai là bất kỳ máy chủ web nào cũng sẽ stream một tệp đã linearization. Trình đọc cần lấy các dải byte, nghĩa là máy chủ phải tôn trọng các HTTP range request. Hầu hết đều làm vậy, nhưng một máy chủ luôn trả về toàn bộ tệp sẽ biến Fast Web View trở lại thành một lần chờ cả-tệp chậm chạp — tệp đã sẵn sàng để stream, nhưng tầng vận chuyển thì chưa.

Linearization là một bước rõ ràng, bật/tắt được, và điều đó là có chủ ý. Nó tốn thêm một lượt serialise để tạo ra, và nó giúp ích nhiều nhất cho các tài liệu lớn được phục vụ qua đường truyền chậm và mở trong trình duyệt. Với một hóa đơn nhỏ được tạo ra rồi gửi email kèm tệp đính kèm, nó thêm việc mà chẳng đem lại lợi ích nào. Biến nó thành một công tắc thay vì một mặc định luôn-bật cho phép bạn chi đúng cái chi phí đó vào nơi mà người đọc cảm nhận được — bản báo cáo công khai lớn trên một chiếc điện thoại — và bỏ qua nó ở nơi họ sẽ chẳng bao giờ cảm thấy.

Giới hạn và ranh giới

NextPDF có hỗ trợ core đầy đủ cho việc tạo ra các tệp đã linearization: một bộ linearizer ba lượt cấp production phát ra parameter dictionary cùng các hint table và vượt qua một bài kiểm tra Annex F bên ngoài.

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

Có hai ranh giới đáng được nêu tên. Thứ nhất, linearization là một thuộc tính của một bản sửa đổi. Khoảnh khắc bạn nối thêm một bản cập nhật gia tăng — một chữ ký, một lần điền form, một chỉnh sửa — các byte được nối thêm sẽ nằm ở cuối và tệp không còn được linearization một cách nghiêm ngặt nữa cho tới khi nó được xây lại. Đó là một sự đánh đổi bình thường, không phải một khiếm khuyết; xem cập nhật gia tăng để hiểu vì sao việc nối thêm là hành vi đúng đối với các tài liệu đã ký.

Thứ hai, engine kiểm soát tệp. Nó không kiểm soát mạng. Fast Web View chỉ thực hiện được lời hứa của mình khi kết nối phục vụ tôn trọng các byte-range request; các byte có thể được linearization hoàn hảo mà vẫn về tới như một khối chậm chạp duy nhất nếu máy chủ khăng khăng gửi toàn bộ tệp.

Tài liệu liên quan

The anatomy of a PDF file — phần header, body, cross-reference table và trailer mà linearization sắp xếp lại. Đọc trang này trước để thấy cái gì đang được sắp xếp lại.
Memory and streaming — streaming ở phía ghi, một trục khác: cách NextPDF giữ bộ nhớ phẳng trong khi tạo ra các byte, so với cách một trình đọc stream chúng vào.
Incremental updates and why they matter — vì sao một chỉnh sửa về sau nối thêm vào cuối, và điều đó có ý nghĩa gì đối với bố cục đặt-phía-trước của một tệp đã linearization.
Streams and filters — cái gì nằm bên trong các đối tượng thân mà hint table trỏ vào, và chúng được nén như thế nào.

Bảng thuật ngữ

Linearization — quá trình xây lại đặt trang đầu cùng một chỉ mục điều hướng lên phía trước để một trình đọc có thể hiển thị và điều hướng trước khi cả tệp về tới. Tên mà tiêu chuẩn dùng để gọi kết quả.
Fast Web View — tên hướng tới người dùng của một tệp PDF đã linearization; hai thuật ngữ mô tả cùng một tệp.
Hint table — cấu trúc bên trong một tệp đã linearization ghi lại các dải và vị trí byte của mỗi trang và các đối tượng dùng chung, để một trình đọc biết cần yêu cầu những lát cắt nào; cross-reference table là thứ sau đó ánh xạ một số đối tượng về đúng byte offset của nó.
Linearization parameter dictionary — đối tượng đầu tiên trong một tệp đã linearization; nó khai báo các offset quan trọng (độ dài trang đầu, vị trí hint table, vị trí cross-reference chính) làm cho việc lấy theo yêu cầu trở nên khả thi.
Byte-range request — một HTTP request cho một lát cắt của tệp thay vì toàn bộ; cơ chế vận chuyển mà Fast Web View phụ thuộc vào.
Thời-gian-tới-trang-đầu (time-to-first-page) — bao lâu cho tới khi một người đọc thấy trang một. Độ trễ mà linearization tối ưu hóa, khác với tổng thời gian tải về.