PDF가 텍스트와 이미지를 저장하는 방법 (내부 구조)

모든 PDF 파일은 동일한 네 부분 배치를 가집니다:

1. 헤더 — 한 줄, 예: %PDF-1.7, 버전을 선언.
2. 본문 — 번호가 매겨진 간접 객체의 시퀀스. 모든 것이 여기에 있습니다: 페이지, 글꼴, 이미지, 메타데이터.
3. 교차 참조 테이블 (xref) — 각 객체의 바이트 오프셋, 리더가 전체 파일을 스캔하지 않고도 찾을 수 있도록.
4. Trailer — 루트 객체(문서 카탈로그)를 가리키고, xref 위치 및 선택적 암호화 정보를 담습니다. 리더는 먼저 trailer를 읽고, 루트로 건너뜁니다.

trailer-우선 설계가 PDF가 전체 파일을 로드하지 않고 일정 시간에 읽을 수 있는 이유입니다 — 큰 문서 및 스트리밍 리더에 중요합니다.

본문의 각 객체는 번호가 매겨져 있으며 다음과 같습니다:

3 0 obj
<< /Type /Page /MediaBox [0 0 612 792] /Contents 4 0 R /Resources << /Font << /F1 5 0 R >> >> >>
endobj

3 0 obj는 "이것은 객체 3, 세대 0"이라고 말합니다. << ... >> 안의 본문은 사전입니다 — 키/값 쌍의 목록. 값은 숫자, 문자열, 이름(/로 시작), 배열, 다른 사전 또는 4 0 R("객체 4를 보러 가라") 같은 참조일 수 있습니다. 이것이 페이지가 콘텐츠 스트림과 글꼴을 내장하지 않고 가리키는 방법입니다.

세대 번호는 일반적으로 0입니다. 증분 업데이트가 객체를 삭제하고 다시 쓸 때 증가합니다 — 파일 전체를 다시 쓰지 않고 끝에 수정을 추가하여 PDF를 편집할 수 있게 하는 기능입니다. 대부분의 현대 writer는 전체 파일을 다시 쓰므로 세대는 0으로 유지됩니다.

페이지의 콘텐츠는 콘텐츠 스트림에 있습니다 — 값이 PDF 그리기 연산자를 포함하는 바이트 스트림(종종 Flate로 압축)인 객체. 텍스트는 BT(텍스트 시작), Tf(글꼴 및 크기 설정), Td(위치 이동), Tj(텍스트 표시) 및 ET(텍스트 종료) 같은 연산자로 그려집니다. 간단한 "Hello"는 대략 다음과 같습니다:

BT
/F1 24 Tf
100 700 Td
(Hello) Tj
ET

문자열 (Hello)은 글꼴의 인코딩을 사용합니다. 단순 라틴 텍스트의 경우, 종종 WinAnsiEncoding 또는 글꼴의 내장 인코딩입니다. Unicode 텍스트의 경우, 문자열은 16비트로 인코딩된 바이트 문자열이며 글꼴에는 리더가 복사-붙여넣기 및 검색을 위해 실제 코드 포인트를 복구할 수 있는/ToUnicode 매핑이 있습니다. PDF에 보이는 텍스트가 있지만 복사-붙여넣기가 깨져 있으면,/ToUnicode 매핑이 누락되거나 잘못된 것입니다 — 일반적인 내보내기 버그.

텍스트는 HTML이나 단락으로 저장되지 않습니다. "단락"이라는 의미론적 객체가 없습니다. 줄, 줄 바꿈 및 위치 지정은 모두 명시적 그리기 명령입니다. 이것이 PDF를 다른 페이지 너비로 재배치하기 어려운 이유입니다: 리더가 그리기 명령에서 레이아웃을 역설계해야 합니다.

PDF의 글꼴 객체는 두 부분입니다: 글꼴의 이름을 지정하고 데이터를 가리키는 글꼴 사전, 및 스트림으로 내장된 글꼴 프로그램 자체(Type 1, TrueType 또는 OpenType). PDF 사양은 문서가 어디서나 동일하게 렌더링되도록 글꼴을 내장하라고 요구하지만 — 강제하지 않으므로, 일부 PDF는 글꼴이 없는 기기에서 대체 글꼴을 사용합니다.

서브셋팅은 문서에서 실제로 사용된 글리프만 내장합니다. 단일 제목에 사용된 250KB 글꼴이 8KB 서브셋이 됩니다. 대부분의 현대 내보내기 도구는 기본적으로 서브셋팅을 합니다. 오래된 내보내기 도구 또는 일부 "PDF로 인쇄" 경로는 때로 전체 글꼴을 내장하여 파일이 부풀어지는 일반적인 원인이 됩니다. 자세한 내용은파일 크기 가이드를 참조하세요.

이미지는 XObject(외부 객체)로 저장됩니다 — 너비, 높이, 색상 공간, 성분당 비트 및 필터를 설명하는 사전과 함께 raw 또는 압축 픽셀 데이터 스트림. 페이지의 콘텐츠 스트림은 Do 연산자로 이미지를 그립니다.

PDF는 여러 이미지 필터(압축)를 지원합니다:

• DCTDecode — JPEG. 손실, 사진에 적합. 이미지가 풍부한 PDF에서 가장 일반적인 크기 원인.
• FlateDecode — zlib/deflate. 비손실, 선화 및 색상이 적은 이미지에 적합.
• JPXDecode — JPEG2000. 고품질에서 JPEG보다 나은 압축, 하지만 느리고 보편적으로 지원되지 않음.
• JBIG2Decode — 비트onal(1비트) 스캔된 텍스트용. 스캔된 페이지를 크게 줄일 수 있음.
• CCITTFaxDecode — 비트onal 이미지용 고전 팩스 압축.

이미지가 풍부한 PDF는 주로 압축된 이미지 스트림의 시퀀스입니다. 이러한 스트림을 더 공격적인 JPEG 품질로 다시 인코딩하는 것이 스캔된 문서에서 가장 중요한 단일 크기 레버입니다.

xref 테이블은 각 간접 객체의 바이트 오프셋을 나열합니다. 리더는 파일을 열고, trailer(파일 끝에서 알려진 오프셋에 있음)를 읽고, xref를 찾아 전체 파일을 분석하지 않고도 임의의 객체로 직접 건너뛰는 데 사용합니다. 이것이 PDF를 직접 접근 가능하게 만듭니다.

PDF 1.5는 xref 테이블 자체를 압축하는 교차 참조 스트림을 추가했습니다. 객체 스트림(많은 작은 객체를 압축 스트림에 패키징)과 결합하여, 이것이 현대 PDF를 1.4 동등물보다 작게 만드는 구조적 압축입니다. 실제로 무엇을 하는지는 압축 설명을 참조하세요.

trailer는 /Root(문서 카탈로그, 페이지 트리를 나열) 및 /Info사전(Title, Author, CreationDate — 메타데이터)도 가리키며, 파일이 암호화된 경우 선택적으로/Encrypt 사전을 가리킵니다.

값이 바이너리 데이터(콘텐츠 스트림, 이미지, 내장 글꼴)인 모든 객체는 스트림입니다: 사전 다음에stream, raw 바이트 및 endstream. 사전의 /Filter 항목은 리더에게 바이트를 디코딩하는 방법을 알려줍니다 — zlib용 FlateDecode, JPEG용 DCTDecode 등. 여러 필터를 체인할 수 있으며, 예: 디코딩된 후 서브샘플링되는 이미지.

이것이 "PDF 압축"이 단일 작업이 아닌 이유입니다. 각 스트림은 자체 필터로 독립적으로 압축됩니다. 객체 스트림으로 다시 저장하는 압축 도구는 구조적 오버헤드를 줄이고; 더 공격적인 JPEG 품질로 이미지를 다시 인코딩하는 것은 이미지 스트림을 줄입니다. 이들은 독립적인 레버입니다.

IXPDF 같은 도구가 PDF를 병합, 분할 또는 회전할 때, xref를 분석하고, 페이지 트리를 순회하며, 페이지 객체를 복사 또는 재배열하고 xref와 trailer를 다시 씁니다. 콘텐츠 스트림(텍스트 및 이미지)은 바이트 단위로 복사됩니다 — 재인코딩 없음, 품질 손실 없음. 이것이 구조적 작업이 빠르고 비손실인 이유입니다: 객체 참조를 재배열할 뿐, 페이지를 다시 렌더링하지 않습니다.

압축은 예외입니다: 객체 스트림으로 구조를 다시 직렬화합니다. 그 경우에도, 사용자가 명시적으로 재인코딩을 요청하지 않는 한 이미지 및 글꼴 스트림은 있는 그대로 복사됩니다.

이 모든 것은 Web Worker를 통해 브라우저에서 일어납니다 — 파일이 로컬에서 분석, 수정 및 다시 직렬화됩니다. 귀하의 PDF는 기기를 떠나지 않습니다.