PDF가 왜 거의 줄지 않았을까요?
PDF를 압축 도구에 돌렸더니 4.1 MB에서 4.0 MB가 됐습니다. 도구가 고장 난 건가요?
PDF는 서류 캐비닛입니다
실망을 부르는 잘못된 모형은 PDF를 문서를 찍은 사진으로 생각하는 것입니다. PDF는 그런 것이 아닙니다. ISO 32000이 정의하는 PDF는 번호가 매겨진 객체들의 컨테이너입니다. 페이지 트리, 그리기 연산자로 가득한 콘텐츠 스트림, 내장된 폰트 프로그램, 이미지 XObject, 양식 필드, 주석, 목차, 그리고 각 객체가 어디서 시작하는지 알려 주는 상호 참조 표가 들어 있습니다.
이 객체 대부분은 이미 압축되어 있습니다. 콘텐츠 스트림은 대개 Flate로 인코딩되는데, ZIP 파일이 쓰는 것과 같은 알고리즘입니다. 내장된 사진은 대개 DCT 스트림으로 저장되며, 이는 JPEG 데이터를 손대지 않고 그대로 통과시킨 것입니다. 그래서 범용 압축기가 PDF를 들여다볼 때 보게 되는 것은, 하나하나가 이미 한 번씩 압축된 물건들이 담긴 상자입니다.
압축하기 전에 용량이 어디 있는지부터 파악하기
가장 쓸모 있는 진단은 지금 가진 문서가 어떤 종류인지 아는 것입니다. 그것만으로 결과가 거의 완전히 예측되기 때문입니다.
| 문서 종류 | 용량이 있는 곳 | 구조 최적화로 할 수 있는 일 |
|---|---|---|
| 워드프로세서로 만든 텍스트 보고서 | 내장 폰트 프로그램과 작은 콘텐츠 스트림 | 거의 없음. 내용이 이미 조밀함 |
| 스캔한 페이지 | 페이지마다 큰 이미지 한 장 | 이미지를 건드리지 않으면 거의 없음 |
| 프레젠테이션 내보내기 | 내장된 사진과 그러데이션 | 슬라이드마다 같은 이미지가 중복되어 있다면 어느 정도 |
| 설계 도면 | 긴 벡터 콘텐츠 스트림 | 스트림 재인코딩과 미사용 객체 제거로 어느 정도 |
| 첨부가 딸린 양식 | 내장 파일, JavaScript, 주석 딕셔너리 | 부가 요소를 제거할 수 있다면 크게 |
구조 최적화가 실제로 제거하는 것
구조 최적화는 어느 페이지의 모습도 바꾸지 않은 채 문서를 다시 씁니다. 아무것도 더는 참조하지 않는 객체를 버릴 수 있는데, 이런 객체는 문서를 편집하고 증분 저장할 때마다 쌓입니다. 상호 참조 표를 압축하고 작은 객체들을 객체 스트림으로 묶을 수도 있습니다. 문서 메타데이터, 섬네일, 일부 생성 도구가 남겨 놓는 편집 이력도 버릴 수 있습니다.
여러 번 편집하고 다시 저장한 문서라면 이것만으로 큰 소득이 될 수 있습니다. 반면 워드프로세서에서 단 한 번 깔끔하게 내보낸 문서라면 주워 담을 것이 없습니다. 파일이 이미 자기 자신의 가장 작은 형태에 가깝고, 4 MB에서 100 KB가 빠지는 것이 바로 예상해야 할 결과입니다.
텍스트 문서가 잘 줄지 않는 이유
텍스트 PDF에서는 파일의 상당 부분이 대개 내장 폰트입니다. 폰트 프로그램은 글리프 윤곽과 힌팅 명령을 담은 조밀한 바이너리이며, 그 서체가 설치되어 있지 않은 컴퓨터에서도 문서가 똑같이 렌더링되어야 하기 때문에 들어 있습니다. 이를 더 잘게 서브셋하거나 아예 제거하지 않고서는 압축으로 없앨 수 없고, 제거하면 페이지의 모습이 달라집니다.
글자 자체는 아주 작습니다. 100쪽 분량의 산문은 압축하기 전에도 문자 데이터로 수백 KB에 지나지 않습니다. 텍스트 PDF가 크다면 글자가 아니라 폰트를, 그리고 글자 뒤에 숨어 있는 이미지를 살펴보십시오. 머리글마다 반복되는 로고나 배경 워터마크 같은 것들입니다.
스캔 문서가 확 줄어드는 이유
스캔한 페이지는 종이 한 장을 찍은 커다란 사진이며, 흔히 300 DPI 이상으로 촬영됩니다. 300 DPI의 A4 한 쪽은 대략 2480 × 3508픽셀, 즉 900만 개에 가까운 픽셀입니다. 정작 그 페이지가 담은 정보는 수 KB의 글자뿐인데도 말이지요. 스캔 문서가 래스터화 압축에 그토록 극적으로 반응하는 이유가 여기에 있습니다. 렌더링 해상도를 낮추고 페이지 이미지를 다시 인코딩하는 것은 파일에서 실제로 큰 부분을 정면으로 공격하는 일이기 때문입니다.
그리고 바로 그 때문에 이 모드는 파괴적입니다. 페이지가 그림이 되고 나면 검색 가능한 텍스트 레이어, 링크, 양식 필드, 주석, 접근성을 위한 태그 구조, 그리고 전자 서명이 모두 사라집니다. FileSlimmer는 래스터화를 구조 최적화가 실망스러울 때 조용히 대신 실행하는 수단으로 두지 않고, 그 경고를 붙여 명확히 표시한 별도의 모드로 다룹니다.
누구도 숫자를 약속할 수 없는 이유
PDF의 목표 용량은 렌더링 해상도와 이미지 품질을 두고 벌이는 탐색이며, 이 탐색에는 하한이 있습니다. 어떤 해상도 아래로 내려가면 스캔 문서의 글자를 읽을 수 없게 됩니다. 특정 문서가 그 하한 위에서 특정 예산에 도달하는지는 쪽수, 잉크 밀도, 사진 성격 콘텐츠의 양, 스캐너 노이즈에 달려 있습니다. 쪽수가 같은 두 문서가 아주 다른 용량으로 끝날 수 있습니다.
정직한 동작은 하한에서 멈추고 탐색이 어디서 멈췄는지 알려 주는 것이며, FileSlimmer의 PDF 목표 용량 프리셋이 하는 일이 그것입니다. 입력한 숫자를 언제나 맞추는 도구는 그 숫자에 대해 거짓말을 하고 있거나, 거기에 도달하려고 문서를 망가뜨리고 있는 것입니다.
도구를 탓하기 전에
- PDF가 스캔본인지 확인하십시오. 본문 한 줄을 드래그해 보아 아무것도 선택되지 않는다면 모든 페이지가 이미지입니다.
- 쪽수와 용량을 견줘 보십시오. 3쪽짜리 40 MB 파일은 이미지가 많은 것이고, 900쪽짜리 40 MB 파일은 지극히 정상일 수 있습니다.
- 문서가 암호화되어 있는지 확인하십시오. 암호로 보호된 PDF는 잠금이 풀리기 전까지 구조를 아예 손댈 수 없습니다.
- 서명이 되어 있는지 확인하십시오. 서명된 문서를 다시 쓰면 서명이 무효가 되는데, 이는 대개 파일이 큰 것보다 나쁜 결과입니다.
- 실제로 필요한 것이 무엇인지 확인하십시오. 보내야 하는 6쪽만 따로 떼어 내는 편이 90쪽 전체를 압축하는 것보다 나은 경우가 많습니다.
관련 도구
출처
- ISO 32000-2 — Document management, Portable Document Format
- Adobe — PDF 32000-1:2008, the freely published PDF 1.7 specification
- PDF Association — ISO 32000 and the PDF standards family