빠른 웹 보기: PDF가 다운로드를 마치기 전에 열리는 방식
Spec: ISO 32000-2, Annex FISO 32000-2 Annex F
한눈에 보기
섹션 제목: “한눈에 보기”선형화된 PDF는 첫 페이지와 작은 탐색 색인이 파일의 맨 앞쪽에 오도록 재구성됩니다. 따라서 리더는 나머지 문서가 아직 도착하는 중에도 첫 페이지를 그릴 수 있고, 2페이지부터 146페이지까지를 먼저 읽지 않고도 147페이지로 곧장 건너뛸 수 있습니다.
이것이 바로 대부분의 독자가 친숙한 이름으로 아는 기능입니다. 바로 빠른 웹 보기입니다.
왜 중요한가
섹션 제목: “왜 중요한가”신호가 한 칸뿐인 휴대폰에서 200페이지짜리 보고서를 본다고 상상해 보십시오. 선형화가 없으면, 모든 객체가 어디에 있는지를 알려 주는 마스터 색인이 전통적으로 파일의 뒤쪽에 자리 잡고 있기 때문에, 리더는 무언가를 그리기 전에 파일의 맨 끝을 먼저 필요로 하는 경우가 많습니다. 그래서 첫 페이지를 읽기 위해서만 200페이지가 다운로드되는 동안 스피너를 바라보게 됩니다.
선형화가 있으면, “첫 페이지에 무엇이 있는가”에 대한 답이 회선에서 가장 먼저 나오도록 파일이 배열됩니다. 리더는 1초 만에 첫 페이지를 그리고, 스크롤하거나 건너뛸 때만 나머지를 가져옵니다. 빠른 연결에서는 전혀 알아차리지 못할 수도 있습니다. 느리거나 종량제인 연결에서는, 그것이 사용 가능한 문서와 버려진 탭 사이의 차이입니다.
- 선형화된 파일은 앞쪽에 배치됩니다. 첫 페이지와 힌트 테이블이 본문의 나머지보다 먼저 놓입니다.
- 힌트 테이블은 범위의 지도입니다. 어떤 바이트 범위가 각 페이지와 공유 객체에 속하는지를 리더에게 알려 주므로, 리더는 서버에 그 조각만을 요청할 수 있습니다 — 그런 다음 크로스 레퍼런스 테이블이 각 객체 번호를 그 정확한 오프셋으로 해석합니다.
- 이는 바이트 범위 요청에 의존합니다 — 리더가 전체가 아니라 필요에 따라 파일의 조각을 가져오는 것입니다.
- 바이트는 일반 PDF와 내용이 동일합니다. 선형화는 페이지 자체가 아니라 순서와 색인을 바꿉니다.
- 이는 NextPDF에서 하나의 명시적이고 전환 가능한 단계입니다 — 잘되기를 바라는 플래그가 아니라, 실제 3패스 재구성으로 산출됩니다.
NextPDF가 접근하는 방식
섹션 제목: “NextPDF가 접근하는 방식”모든 것이 정확히 얼마나 큰지 알기 전까지는 페이지를 앞쪽에 배치할 수 없습니다. 힌트 테이블이 바이트 오프셋을 기록하는데, 오프셋은 모든 객체의 길이가 확정되어야만 정확해지기 때문입니다. 그 순환성 — 오프셋은 크기에 의존하고, 크기는 레이아웃에 의존한다 — 이 바로 선형화기가 한 번의 훑기가 아니라 여러 패스로 실행되는 이유입니다.
NextPDF는 결정론적 3패스 재구성으로 이를 해결합니다. 첫 번째 패스는 측정하고, 두 번째는 배치를 결정하고, 세 번째는 이제 알려진 오프셋을 새겨 넣은 실제 바이트를 씁니다.
- MEASURE모든 객체를 한 번 직렬화하여 그 정확한 바이트 길이를 알아낸다. 오프셋은 순환적이며 — 크기에 의존하므로 — 크기를 먼저 고정한다.
- PLACE순서를 결정한다. 즉, 첫 페이지와 그 의존성을 앞쪽에, 그다음 나머지를 둔다. 선형화 매개변수 딕셔너리와 힌트 테이블을 위한 공간을 예약한다.
- FILL최종 바이트를 쓴다. 예약된 각 필드는 MEASURE와 PLACE 이후에 계산된 값 — 첫 페이지 길이, 힌트 테이블 위치, 주 크로스 레퍼런스 오프셋 — 으로 채워지며, 이는 측정된 크기와 선택된 배치에서 도출된다.
출력물은 표준이 규정하는 그대로 선형화 매개변수 딕셔너리를 그 첫 객체로, 그리고 페이지를 색인하는 하나 이상의 힌트 테이블을 담습니다 (Spec: ISO 32000-2, Annex FISO 32000-2 Annex F). 그 힌트 테이블은 전통적인 크로스 레퍼런스 테이블과 나란히 작동합니다 — 힌트 테이블은 리더가 가져와야 할 바이트 범위와 위치를 기록하고, 크로스 레퍼런스 테이블은 각 객체 번호를 그 정확한 바이트 오프셋으로 매핑하는 색인입니다. NextPDF의 선형화기는 고전적인 테이블 형식을 내보내고 그 과정에서 모든 크로스 레퍼런스 스트림을 제거하므로, 일단 조각이 도착하면 리더는 그 테이블에서 곧장 오프셋으로 객체를 해석합니다 (Spec: ISO 32000-2, §7.5.4ISO 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.pdfreport.pdf: no linearization errorsqpdf --check-linearization은 단지 플래그를 찾는 것이 아닙니다. 파일이 주장하는
오프셋을 다시 도출하여 그것이 참인지를 확인합니다. 즉, 첫 페이지 객체가 선형화
딕셔너리가 말하는 그곳에 정말로 있는지, 힌트 테이블이 올바른 바이트를 가리키는지,
그리고 구조가 Annex F에 부합하는지를 확인합니다. 자신의 레이아웃에 대해 거짓말하는
파일은, 언뜻 보기에 선형화된 것처럼 보이더라도 이 검사에서 실패합니다.
흔한 오해
섹션 제목: “흔한 오해”흔한 가정은 선형화가 파일을 압축하거나 전체적으로 다운로드를 더 빠르게 만든다는 것입니다. 둘 다 아닙니다. 선형화된 파일은 추가 힌트 테이블을 담기 때문에 흔히 몇 바이트 더 큽니다. 문서 전체의 총 전송 시간은 본질적으로 변하지 않습니다.
변하는 것은 첫 유용한 픽셀이 언제 나타나는가입니다. 선형화는 총 바이트가 아니라 첫 페이지까지의 시간을 최적화합니다. 이는 압축 기능이 아니라 지연 시간 기능입니다. 첫 페이지를 일찍 스트리밍하는 것과 파일을 빠르게 다운로드하는 것은 다른 목표이며, 선형화는 첫 번째를 위한 것입니다.
두 번째 오해는 어떤 웹 서버든 선형화된 파일을 스트리밍하리라는 것입니다. 리더는 바이트 범위를 가져와야 하는데, 이는 서버가 HTTP 범위 요청을 존중해야 함을 의미합니다. 대부분은 그러하지만, 항상 전체 파일을 반환하는 서버는 빠른 웹 보기를 다시 느린, 파일 전체를 기다리는 일로 되돌려 놓습니다 — 파일은 스트리밍할 준비가 되어 있지만, 전송 계층은 그렇지 않은 것입니다.
한계와 경계
섹션 제목: “한계와 경계”NextPDF는 선형화된 파일을 산출하는 데 대한 완전한 코어 지원을 갖추고 있습니다. 즉, 매개변수 딕셔너리와 힌트 테이블을 내보내고 외부 Annex F 검사를 통과하는 프로덕션 3패스 선형화기입니다.
| Edition | Availability |
|---|---|
| Core | 완전한 지원. NextPDF는 ISO 32000-2 Annex F에 부합하는 프로덕션 3패스 MEASURE → PLACE → FILL 재구성을 통해 선형화된(빠른 웹 보기) 출력을 산출합니다. |
| Pro | Not in this edition |
| Enterprise | Not in this edition |
언급할 가치가 있는 경계가 두 가지 있습니다. 첫째, 선형화는 하나의 개정의 속성입니다. 증분 업데이트 — 서명, 양식 채우기, 편집 — 를 추가하는 순간, 추가된 바이트는 끝으로 가고 파일은 재구성될 때까지 더 이상 엄밀하게 선형화된 상태가 아닙니다. 그것은 결함이 아니라 일반적인 절충입니다. 추가가 서명된 문서에 올바른 동작인 이유는 증분 업데이트를 참조하십시오.
둘째, 엔진은 파일을 제어합니다. 네트워크는 제어하지 않습니다. 빠른 웹 보기는 제공 연결이 바이트 범위 요청을 존중할 때만 그 약속을 이행합니다. 바이트가 완벽하게 선형화되어 있어도 서버가 전체 파일 전송을 고집하면 여전히 하나의 느린 덩어리로 도착할 수 있습니다.
관련 문서
섹션 제목: “관련 문서”- PDF 파일의 해부학 — 선형화가 재배열하는 헤더, 본문, 크로스 레퍼런스 테이블, 트레일러. 무엇이 재정렬되는지를 보려면 이것을 먼저 읽으십시오.
- 메모리와 스트리밍 — 쓰기 측 스트리밍이라는 다른 축. NextPDF가 바이트를 산출하는 동안 메모리를 평평하게 유지하는 방식과, 리더가 그것을 어떻게 스트리밍하는지의 대비.
- 증분 업데이트와 그것이 중요한 이유 — 이후의 편집이 끝에 추가되는 이유와, 그것이 선형화된 파일의 앞쪽 배치 레이아웃에 무엇을 의미하는지.
- 스트림과 필터 — 힌트 테이블이 가리키는 본문 객체 안에 무엇이 들어 있고, 그것들이 어떻게 압축되는지.
용어집
섹션 제목: “용어집”- 선형화 — 리더가 파일 전체가 도착하기 전에 렌더링하고 탐색할 수 있도록 첫 페이지와 탐색 색인을 앞쪽에 배치하는 재구성. 그 결과물에 대한 표준의 이름.
- 빠른 웹 보기 — 선형화된 PDF의 소비자용 이름. 두 용어는 같은 파일을 가리킵니다.
- 힌트 테이블 — 선형화된 파일 안에서 각 페이지와 공유 객체의 바이트 범위와 위치를 기록하여 리더가 어떤 조각을 요청해야 할지 알게 하는 구조. 그런 다음 객체 번호를 그 정확한 바이트 오프셋으로 매핑하는 것은 크로스 레퍼런스 테이블입니다.
- 선형화 매개변수 딕셔너리 — 선형화된 파일의 첫 객체. 필요 시 가져오기를 가능하게 하는 핵심 오프셋(첫 페이지 길이, 힌트 테이블 위치, 주 크로스 레퍼런스 위치)을 선언합니다.
- 바이트 범위 요청 — 파일 전체가 아니라 그 조각에 대한 HTTP 요청. 빠른 웹 보기가 의존하는 전송 메커니즘.
- 첫 페이지까지의 시간 — 리더가 첫 페이지를 보기까지 걸리는 시간. 선형화가 최적화하는 지연 시간으로, 총 다운로드 시간과는 구별됩니다.