큰 PDF로 연결되는 링크를 클릭하면 빈 화면이 나타납니다. 로딩 표시가 돌고, 몇 메가바이트가 도착한 뒤에야 첫 페이지가 나타납니다. 파일도 문제없었고 네트워크도 문제없었습니다. 단지 문서가 뷰어로 하여금 무엇이든 그리기 전에 전체 파일을 기다리게 만드는 순서로 작성되었을 뿐입니다. 이것이 선형화가 해결하는 문제이며, 이는 크기 문제가 아니라 구조적 수정입니다. 즉, 동일한 바이트를 첫 페이지를 렌더링하는 데 필요한 부분이 앞쪽에 위치하도록 재배열하는 것입니다.
이 글에서는 Spire.PDF for JavaScript를 사용하여 브라우저에서 PDF를 선형화합니다. 이 라이브러리는 WebAssembly에서 실행되며 가상 파일 시스템(VFS)을 통해 문서를 처리하므로, 파일을 원격 최적화 서비스로 보내지 않고도 사용자의 컴퓨터에서 구조를 변경할 수 있습니다.
설치 방법은 React 프로젝트에 Spire.PDF for JavaScript 통합하기에 나와 있습니다. 아래 예제는 패키지가 설치되고 WebAssembly 모듈이 초기화되었음을 전제로 합니다.
빠른 웹 보기(fast web view)의 실제 의미
PDF는 컨테이너이며, 그 객체들은 이를 생성한 프로그램이 작성한 순서대로 저장됩니다. 반면 뷰어는 무언가를 그리기 전에 특정한 소수의 객체 집합, 즉 문서 카탈로그, 페이지 트리, 그리고 첫 페이지를 뒷받침하는 객체들이 필요합니다. 만약 그 객체들이 커다란 포함 이미지 뒤인 파일 끝부분에 있다면, 뷰어는 그곳에 도달할 때까지 계속 다운로드하는 수밖에 없습니다.
빠른 웹 보기는 선형화된 PDF를 소비자에게 알리는 이름입니다. 즉 내부 배치가 첫 페이지의 객체들을 앞쪽에 두어, HTTP 바이트 범위 요청을 지원하는 클라이언트가 그 바이트만 요청해 첫 페이지를 즉시 렌더링하고 나머지는 백그라운드에서 가져올 수 있게 한 파일입니다. 독자는 빈 화면을 바라보는 대신 다운로드가 계속되는 동안 콘텐츠를 보게 됩니다.
실질적인 결과는 크기가 동일한 두 파일이라도 열 때 완전히 다르게 느껴질 수 있다는 것입니다. 같은 페이지 수, 같은 이미지, 같은 텍스트이지만 첫 화면이 그려지기까지 걸리는 시간이 다릅니다.
선형화가 파일을 재배열하는 방식
선형화는 파일의 내용은 건드리지 않고 배치 방식만 다시 작성합니다.
- 첫 페이지가 의존하는 객체들이 파일의 시작 부분으로 이동합니다.
- 클라이언트가 문서 전체를 읽기 전에 배치를 파악할 수 있도록 선형화 사전(linearization dictionary)이 시작 부분 근처에 기록됩니다.
- 힌트 테이블(hint table)이 각 페이지의 객체가 어디에 있는지 기록하며, 이를 통해 리더가 바이트 범위 요청으로 임의의 페이지로 건너뛸 수 있습니다.
- 상호 참조 정보가 파일 끝이 아니라 이른 시점에 읽을 수 있는 위치에 배치됩니다.
독자가 실제로 보는 모든 것 — 텍스트, 이미지, 글꼴, 벡터 아트, 링크, 주석, 책갈피, 메타데이터 — 은 변경 없이 그대로 유지됩니다. 페이지 위의 글자는 같은 위치에 있는 같은 글자입니다. 바뀐 것은 내용이 아니라 바이트 순서입니다. 그래서 선형화된 문서는 눈으로 보아서는 알아볼 수 없습니다. 원본과 결과물을 나란히 열어 보면 구별할 수 없는데, 차이는 오직 조각들을 언제 읽을 수 있는지에만 나타나기 때문입니다.
브라우저에서 문서 선형화하기
사용 방법은 라이브러리의 다른 변환기와 같습니다. 입력 파일을 PdfToLinearizedPdfConverter에 넘긴 다음 ToLinearizedPdf를 호출하여 재구성된 문서를 작성합니다.
function App() {
const convertToLinearized = async () => {
// Get the Spire.PDF WASM module
const pdfModule = window.wasmModule?.spirepdf;
// Check whether the module is ready
if (!pdfModule) {
alert('Spire.PDF is not ready yet');
return;
}
// Load the PDF file to be converted into the VFS
const inputFileName = 'Business_Data_Overview.pdf';
await window.spire.FetchFileToVFS(inputFileName, "", `${process.env.PUBLIC_URL}/data/`);
// Define the output file name
const outputFileName = 'LinearizedDocument.pdf';
// Construct the linearization converter from the input file and write out the linearized document
const converter = new pdfModule.PdfToLinearizedPdfConverter({ filePath: inputFileName });
converter.ToLinearizedPdf({ filePath: outputFileName });
converter.Dispose();
// Read the generated file from the VFS and trigger the download
const fileArray = window.dotnetRuntime.Module.FS.readFile(outputFileName);
const blob = new Blob([fileArray], { type: 'application/pdf' });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = outputFileName;
a.click();
URL.revokeObjectURL(url);
};
return (
<div style={{ textAlign: 'center', height: '300px' }}>
<h1>Linearize a PDF</h1>
<button onClick={convertToLinearized}>
Start Converting
</button>
</div>
);
}
export default App;
ToLinearizedPdf는 새 파일을 작성하므로 입력 파일은 VFS에 그대로 남아 있어 원본과 비교할 수 있습니다. 이 호출은 문서 내용에 따라 달라지는 것이 없습니다. 보고서, 설명서, 스캔한 아카이브 모두 동일한 두 멤버를 거쳐 처리됩니다.
선형화된 문서는 페이지상으로 전혀 달라 보이지 않으며, 변경 사항은 파일 구조 내부에 있습니다
선형화와 압축
이 두 작업은 둘 다 "PDF 최적화"라고 설명되기 때문에 흔히 혼동되지만, 서로 다른 질문에 답합니다.
| 압축 | 선형화 | |
|---|---|---|
| 변경하는 것 | 중복을 제거하여 파일이 더 적은 바이트를 담도록 함 | 바이트 순서를 재배열하여 유용한 바이트가 먼저 도착하도록 함 |
| 목표 | 더 작은 다운로드 | 더 빠른 첫 페이지 |
| 파일 크기에 미치는 영향 | 작업의 핵심 목적 | 거의 또는 전혀 없음. 바이트는 동일한 바이트임 |
| 모양에 미치는 영향 | 이미지 품질을 희생하는 경우에만 | 전혀 없음 |
| 일반적인 사용 시점 | 업로드 제한이나 첨부 파일 용량 제한이 있을 때 | 열람용으로 게시되는 긴 문서일 때 |
파일에 두 작업이 모두 필요할 수 있으며, 순서가 중요합니다. 압축은 문서를 다시 작성하고, PDF를 다시 작성하는 모든 작업은 선형화된 배치를 없애 버립니다. 따라서 둘 다 원한다면 먼저 압축하고 마지막에 선형화하여, 선형화된 구조가 파일의 최종 상태가 되도록 하십시오.
선형화가 가치 있는 경우
선형화는 특정 상황에서 효과를 발휘합니다. 즉, 다운로드가 눈에 띌 만큼 큰 문서를 범위 요청을 지원하는 뷰어로 HTTP를 통해 전송하는 경우입니다.
- 사이트에서 제공되는 설명서, 카탈로그, 긴 보고서. 가장 전형적인 사례로, 수십 메가바이트에 달하며 링크로 열리고 독자는 곧바로 특정 장으로 건너뛰기를 원합니다.
- 느린 연결의 모바일 독자. 첫 페이지가 요청한 첫 바이트들로부터 나타나므로, 전체 다운로드 시간이 줄지 않아도 체감 로딩 시간은 줄어듭니다.
- 독자가 보통 중간부터 보는 문서. 바이트 범위 요청을 사용하면 클라이언트가 뒤쪽 페이지를 먼저 가져올 수 있는데, 이는 선형화된 파일이 지닌 힌트 테이블이 있어야만 가능합니다.
그렇지 않은 경우에는 이 작업이 가치가 없습니다. 로컬 디스크에서 여는 파일은 HTTP로 가져오지 않으므로 활용할 범위 요청이 없습니다. 짧은 문서는 차이를 느끼기도 전에 이미 렌더링이 끝납니다. 그리고 내부 인쇄 워크플로는 스트리밍도, 건너뛰기도 하지 않습니다. 순서대로 전체 문서를 한 번에 원합니다.
출력이 선형화되었는지 확인하기
보이는 페이지가 동일하기 때문에 "제대로 보인다"는 것은 아무것도 증명하지 못합니다. 변경 사항은 파일 안에 있으므로 확인하려면 파일을 읽어야 합니다.
선형화된 PDF는 바이트 시작 부분 근처에 선형화 사전을 포함하며, 그 표시는 일반 텍스트이므로 출력의 처음 몇백 바이트만으로도 확인할 수 있습니다. 입력과 출력 모두 VFS에 있으므로 비교는 파일을 몇 번 읽는 것으로 끝납니다.
// Read the head of the file and look for the linearization marker
const bytes = window.dotnetRuntime.Module.FS.readFile(outputFileName);
const head = new TextDecoder('latin1').decode(bytes.slice(0, 1024));
const linearized = head.includes('/Linearized');
이는 파이프라인에 유용한 안전장치가 됩니다. 문서를 변환한 다음, 파일을 넘기기 전에 해당 표시가 있는지 확인하는 것입니다. 만약 없다면 선형화 이후에 하위 단계의 무언가가 파일을 다시 작성한 것입니다. 압축 작업을 포함한 모든 재저장은 선형화된 배치를 없앤다는 점을 기억하십시오.
일반적인 문제
첫 페이지가 여전히 표시되는 데 시간이 걸립니다. 파일이 어떻게 전달되는지 확인하십시오. 선형화는 클라이언트가 파일의 일부를 요청할 수 있을 때, 즉 범위 지원과 함께 HTTP로 제공될 때만 도움이 됩니다. 파일 전체를 한 번에 가져오거나 문서가 짧다면, 이 작업으로는 보이는 상황을 바꿀 수 없습니다.
출력에 텍스트 한 줄이 추가로 표시됩니다.
라이선스가 없는 빌드는 변환 호출마다 한 번씩 문서에 Evaluation Warning : The document was created with Spire.PDF for JavaScript.를 덧붙입니다. 임시 30일 라이선스를 사용하면 기능 제한과 함께 이 문구도 사라집니다. 발급받으려면 영업팀에 문의하십시오.
파일 크기가 줄지 않았습니다. 보통 줄지 않습니다. 선형화는 기존 바이트의 순서를 바꿀 뿐, 어떤 바이트도 제거하지 않습니다. 크기가 문제라면 그것은 압축 작업이지 선형화 작업이 아닙니다.
첫 클릭에 아무 일도 일어나지 않습니다.
WebAssembly 모듈은 비동기적으로 로드됩니다. 샘플에서는 if (!pdfModule) return;이 이를 방어하지만, 실제 UI에서는 경고창을 띄우는 대신 모듈이 준비될 때까지 컨트롤을 비활성화하십시오.
FAQ
PDF를 선형화하면 내용이나 품질이 바뀌나요? 아니요. 텍스트, 이미지, 글꼴, 서식, 링크, 메타데이터는 모두 그대로 유지되며 내부 바이트 순서만 바뀝니다. 페이지는 동일하게 보이고 동일하게 동작합니다.
선형화는 PDF 압축과 같은 것인가요? 아니요. 압축은 중복을 제거하여 더 적은 바이트를 만들어 내고, 선형화는 이미 가진 바이트를 재배열하여 첫 페이지를 더 빨리 읽을 수 있게 합니다. 하나는 다운로드 크기를, 다른 하나는 첫 렌더링까지의 시간을 목표로 합니다.
로컬 디스크에서 파일을 열 때도 도움이 되나요? 거의 없습니다. 이점은 바이트 범위 요청을 사용하는 HTTP 스트리밍에서 나오므로, 로컬 경로에서 연 문서는 얻을 것이 없습니다.
선형화된 파일은 계속 선형화 상태로 유지되나요? 무언가가 파일을 다시 작성하기 전까지만 그렇습니다. 압축 작업, 편집, 병합 등 문서를 재저장하는 모든 도구는 선형화된 배치를 없애므로, 선형화는 파이프라인의 마지막 단계여야 합니다.
암호화되었거나 암호로 보호된 파일에도 작동하나요? 암호화는 배치와는 별개의 문제입니다. 먼저 문서를 복호화한 다음, 이미 읽을 수 있는 파일에 변환기를 적용하십시오.
여러 파일을 한 번에 변환할 수 있나요? 예. 변환기는 파일 하나씩 처리하는 작업이므로, 일괄 처리는 반복문이 됩니다. 즉 동일한 두 멤버를 사용하되 입력마다 서로 다른 출력 이름을 지정하면 됩니다.