콘텐츠로 이동
getnextpdf.com

빠른 웹 보기: PDF가 다운로드를 마치기 전에 열리는 방식

Spec: ISO 32000-2, Annex F

선형화된 PDF는 첫 페이지와 작은 탐색 색인이 파일의 맨 앞쪽에 오도록 재구성됩니다. 따라서 리더는 나머지 문서가 아직 도착하는 중에도 첫 페이지를 그릴 수 있고, 2페이지부터 146페이지까지를 먼저 읽지 않고도 147페이지로 곧장 건너뛸 수 있습니다.

이것이 바로 대부분의 독자가 친숙한 이름으로 아는 기능입니다. 바로 빠른 웹 보기입니다.

신호가 한 칸뿐인 휴대폰에서 200페이지짜리 보고서를 본다고 상상해 보십시오. 선형화가 없으면, 모든 객체가 어디에 있는지를 알려 주는 마스터 색인이 전통적으로 파일의 뒤쪽에 자리 잡고 있기 때문에, 리더는 무언가를 그리기 전에 파일의 맨 끝을 먼저 필요로 하는 경우가 많습니다. 그래서 첫 페이지를 읽기 위해서만 200페이지가 다운로드되는 동안 스피너를 바라보게 됩니다.

선형화가 있으면, “첫 페이지에 무엇이 있는가”에 대한 답이 회선에서 가장 먼저 나오도록 파일이 배열됩니다. 리더는 1초 만에 첫 페이지를 그리고, 스크롤하거나 건너뛸 때만 나머지를 가져옵니다. 빠른 연결에서는 전혀 알아차리지 못할 수도 있습니다. 느리거나 종량제인 연결에서는, 그것이 사용 가능한 문서와 버려진 탭 사이의 차이입니다.

  • 선형화된 파일은 앞쪽에 배치됩니다. 첫 페이지와 힌트 테이블이 본문의 나머지보다 먼저 놓입니다.
  • 힌트 테이블은 범위의 지도입니다. 어떤 바이트 범위가 각 페이지와 공유 객체에 속하는지를 리더에게 알려 주므로, 리더는 서버에 그 조각만을 요청할 수 있습니다 — 그런 다음 크로스 레퍼런스 테이블이 각 객체 번호를 그 정확한 오프셋으로 해석합니다.
  • 이는 바이트 범위 요청에 의존합니다 — 리더가 전체가 아니라 필요에 따라 파일의 조각을 가져오는 것입니다.
  • 바이트는 일반 PDF와 내용이 동일합니다. 선형화는 페이지 자체가 아니라 순서와 색인을 바꿉니다.
  • 이는 NextPDF에서 하나의 명시적이고 전환 가능한 단계입니다 — 잘되기를 바라는 플래그가 아니라, 실제 3패스 재구성으로 산출됩니다.

모든 것이 정확히 얼마나 큰지 알기 전까지는 페이지를 앞쪽에 배치할 수 없습니다. 힌트 테이블이 바이트 오프셋을 기록하는데, 오프셋은 모든 객체의 길이가 확정되어야만 정확해지기 때문입니다. 그 순환성 — 오프셋은 크기에 의존하고, 크기는 레이아웃에 의존한다 — 이 바로 선형화기가 한 번의 훑기가 아니라 여러 패스로 실행되는 이유입니다.

NextPDF는 결정론적 3패스 재구성으로 이를 해결합니다. 첫 번째 패스는 측정하고, 두 번째는 배치를 결정하고, 세 번째는 이제 알려진 오프셋을 새겨 넣은 실제 바이트를 씁니다.

  1. MEASURE모든 객체를 한 번 직렬화하여 그 정확한 바이트 길이를 알아낸다. 오프셋은 순환적이며 — 크기에 의존하므로 — 크기를 먼저 고정한다.
  2. PLACE순서를 결정한다. 즉, 첫 페이지와 그 의존성을 앞쪽에, 그다음 나머지를 둔다. 선형화 매개변수 딕셔너리와 힌트 테이블을 위한 공간을 예약한다.
  3. FILL최종 바이트를 쓴다. 예약된 각 필드는 MEASURE와 PLACE 이후에 계산된 값 — 첫 페이지 길이, 힌트 테이블 위치, 주 크로스 레퍼런스 오프셋 — 으로 채워지며, 이는 측정된 크기와 선택된 배치에서 도출된다.
3패스 선형화 재구성. MEASURE는 길이가 확정되도록 모든 객체의 크기를 잰다. PLACE는 앞쪽 배치 순서를 결정하고 힌트 테이블 영역을 예약한다. FILL은 이제 알려진 오프셋으로 실제 바이트를 써서, 첫 페이지와 힌트 테이블이 앞쪽에 놓이고 크로스 레퍼런스 데이터가 첫 가져오기에서 해석되도록 한다.

출력물은 표준이 규정하는 그대로 선형화 매개변수 딕셔너리를 그 첫 객체로, 그리고 페이지를 색인하는 하나 이상의 힌트 테이블을 담습니다 (Spec: ISO 32000-2, Annex F). 그 힌트 테이블은 전통적인 크로스 레퍼런스 테이블나란히 작동합니다 — 힌트 테이블은 리더가 가져와야 할 바이트 범위와 위치를 기록하고, 크로스 레퍼런스 테이블은 각 객체 번호를 그 정확한 바이트 오프셋으로 매핑하는 색인입니다. NextPDF의 선형화기는 고전적인 테이블 형식을 내보내고 그 과정에서 모든 크로스 레퍼런스 스트림을 제거하므로, 일단 조각이 도착하면 리더는 그 테이블에서 곧장 오프셋으로 객체를 해석합니다 (Spec: ISO 32000-2, §7.5.4).

유용한 심상 모델 하나. 일반 PDF는 목차가 표지에 붙어 있는 책입니다. 선형화된 PDF는 그 목차 페이지를 앞쪽으로 옮기고 페이지별 페이지 번호 색인을 더하므로, 어떤 페이지로든 곧장 펼칠 수 있습니다. 본문은 변하지 않았습니다. 탐색만 옮겨졌을 뿐입니다.

선형화는 명시적이고 전환 가능한 단계입니다. 그것을 요청하면, 엔진이 재구성을 수행하고 빠른 웹 보기 파일을 내보냅니다.

<?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);

페이지 내용은 정확히 여러분이 작성한 그대로입니다. 차이는 여러분이 받는 바이트의 파일 순서에 있고, 이제 위쪽 가까이에 자리 잡은 힌트 테이블에 있습니다.

결과는 낯선 사람이 그러하듯이 — 외부 검사기로 — 검증합니다.

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

qpdf --check-linearization은 단지 플래그를 찾는 것이 아닙니다. 파일이 주장하는 오프셋을 다시 도출하여 그것이 참인지를 확인합니다. 즉, 첫 페이지 객체가 선형화 딕셔너리가 말하는 그곳에 정말로 있는지, 힌트 테이블이 올바른 바이트를 가리키는지, 그리고 구조가 Annex F에 부합하는지를 확인합니다. 자신의 레이아웃에 대해 거짓말하는 파일은, 언뜻 보기에 선형화된 것처럼 보이더라도 이 검사에서 실패합니다.

흔한 가정은 선형화가 파일을 압축하거나 전체적으로 다운로드를 더 빠르게 만든다는 것입니다. 둘 다 아닙니다. 선형화된 파일은 추가 힌트 테이블을 담기 때문에 흔히 몇 바이트 더 큽니다. 문서 전체의 총 전송 시간은 본질적으로 변하지 않습니다.

변하는 것은 첫 유용한 픽셀이 언제 나타나는가입니다. 선형화는 총 바이트가 아니라 첫 페이지까지의 시간을 최적화합니다. 이는 압축 기능이 아니라 지연 시간 기능입니다. 첫 페이지를 일찍 스트리밍하는 것과 파일을 빠르게 다운로드하는 것은 다른 목표이며, 선형화는 첫 번째를 위한 것입니다.

두 번째 오해는 어떤 웹 서버든 선형화된 파일을 스트리밍하리라는 것입니다. 리더는 바이트 범위를 가져와야 하는데, 이는 서버가 HTTP 범위 요청을 존중해야 함을 의미합니다. 대부분은 그러하지만, 항상 전체 파일을 반환하는 서버는 빠른 웹 보기를 다시 느린, 파일 전체를 기다리는 일로 되돌려 놓습니다 — 파일은 스트리밍할 준비가 되어 있지만, 전송 계층은 그렇지 않은 것입니다.

NextPDF는 선형화된 파일을 산출하는 데 대한 완전한 코어 지원을 갖추고 있습니다. 즉, 매개변수 딕셔너리와 힌트 테이블을 내보내고 외부 Annex F 검사를 통과하는 프로덕션 3패스 선형화기입니다.

Fast Web View (linearization) output — edition availability
EditionAvailability
Core

완전한 지원. NextPDF는 ISO 32000-2 Annex F에 부합하는 프로덕션 3패스 MEASURE → PLACE → FILL 재구성을 통해 선형화된(빠른 웹 보기) 출력을 산출합니다.

ProNot in this edition
EnterpriseNot in this edition

언급할 가치가 있는 경계가 두 가지 있습니다. 첫째, 선형화는 하나의 개정의 속성입니다. 증분 업데이트 — 서명, 양식 채우기, 편집 — 를 추가하는 순간, 추가된 바이트는 끝으로 가고 파일은 재구성될 때까지 더 이상 엄밀하게 선형화된 상태가 아닙니다. 그것은 결함이 아니라 일반적인 절충입니다. 추가가 서명된 문서에 올바른 동작인 이유는 증분 업데이트를 참조하십시오.

둘째, 엔진은 파일을 제어합니다. 네트워크는 제어하지 않습니다. 빠른 웹 보기는 제공 연결이 바이트 범위 요청을 존중할 때만 그 약속을 이행합니다. 바이트가 완벽하게 선형화되어 있어도 서버가 전체 파일 전송을 고집하면 여전히 하나의 느린 덩어리로 도착할 수 있습니다.

  • PDF 파일의 해부학 — 선형화가 재배열하는 헤더, 본문, 크로스 레퍼런스 테이블, 트레일러. 무엇이 재정렬되는지를 보려면 이것을 먼저 읽으십시오.
  • 메모리와 스트리밍 — 쓰기 측 스트리밍이라는 다른 축. NextPDF가 바이트를 산출하는 동안 메모리를 평평하게 유지하는 방식과, 리더가 그것을 어떻게 스트리밍하는지의 대비.
  • 증분 업데이트와 그것이 중요한 이유 — 이후의 편집이 끝에 추가되는 이유와, 그것이 선형화된 파일의 앞쪽 배치 레이아웃에 무엇을 의미하는지.
  • 스트림과 필터 — 힌트 테이블이 가리키는 본문 객체 안에 무엇이 들어 있고, 그것들이 어떻게 압축되는지.
  • 선형화 — 리더가 파일 전체가 도착하기 전에 렌더링하고 탐색할 수 있도록 첫 페이지와 탐색 색인을 앞쪽에 배치하는 재구성. 그 결과물에 대한 표준의 이름.
  • 빠른 웹 보기 — 선형화된 PDF의 소비자용 이름. 두 용어는 같은 파일을 가리킵니다.
  • 힌트 테이블 — 선형화된 파일 안에서 각 페이지와 공유 객체의 바이트 범위와 위치를 기록하여 리더가 어떤 조각을 요청해야 할지 알게 하는 구조. 그런 다음 객체 번호를 그 정확한 바이트 오프셋으로 매핑하는 것은 크로스 레퍼런스 테이블입니다.
  • 선형화 매개변수 딕셔너리 — 선형화된 파일의 첫 객체. 필요 시 가져오기를 가능하게 하는 핵심 오프셋(첫 페이지 길이, 힌트 테이블 위치, 주 크로스 레퍼런스 위치)을 선언합니다.
  • 바이트 범위 요청 — 파일 전체가 아니라 그 조각에 대한 HTTP 요청. 빠른 웹 보기가 의존하는 전송 메커니즘.
  • 첫 페이지까지의 시간 — 리더가 첫 페이지를 보기까지 걸리는 시간. 선형화가 최적화하는 지연 시간으로, 총 다운로드 시간과는 구별됩니다.