PDF 상호 참조 테이블의 기능과 라이브러리에 따라 달라지는 이유
모든 PDF 파일에는 개체 번호를 파일 내의 바이트 오프셋에 매핑하는 상호 참조 테이블이 포함되어 있습니다. 독자가 PDF를 열면 전체 파일을 순차적으로 스캔하지 않고 먼저 이 테이블을 읽어 페이지, 글꼴, 이미지 및 메타데이터를 찾습니다. PDF 표준 사양은 두 가지 상호 참조 테이블 형식, 즉 PDF 1.0의 원래 ASCII 기반 형식과 PDF 1.5에 도입된 압축된 상호 참조 스트림을 정의합니다. 이 두 형식은 동일한 목적으로 사용되지만 바이너리 수준에서는 구조적으로 서로 호환되지 않습니다.
형식 간의 차이는 실제적인 결과를 가져옵니다.
이 단일 단계로 대부분의 병합 실패를 방지할 수 있습니다.
서로 다른 PDF 생성 라이브러리는 기본적으로 서로 다른 형식을 사용하며 이것이 대부분의 병합 시간 충돌의 근본 원인입니다. LibreOffice 및 이전 버전의 Microsoft Office와 같은 Office 제품군에서 사용되는 것과 같이 최대 호환성을 목표로 하는 라이브러리는 작성된 모든 PDF 리더에서 구문 분석할 수 있기 때문에 원래 ASCII 테이블 형식을 사용하는 경향이 있습니다. iText, Adobe SDK, Apple Quartz 등 파일 크기 효율성에 중점을 둔 라이브러리는 기본적으로 파일 오버헤드를 30~50% 줄이는 압축된 상호 참조 스트림을 사용합니다. 다양한 테이블 형식을 사용하는 파일에 대해 Merge PDF 작업을 수행할 때 병합 도구는 근본적으로 다른 데이터 구조를 모든 독자가 오류 없이 구문 분석할 수 있는 단일 통합 테이블로 조정해야 합니다.
각 라이브러리가 대상으로 하는 PDF 사양 버전도 매우 중요합니다. PDF 1.4를 대상으로 하는 라이브러리는 PDF 1.5에 도입된 압축된 상호 참조 스트림을 생성할 수 없습니다. 병합 도구가 ASCII 테이블이 포함된 하나의 PDF 1.4 파일과 압축된 스트림이 포함된 PDF 1.7 파일 하나를 수신하는 경우 도구는 이전 파일의 테이블 형식을 업그레이드하여 PDF 버전 선언을 변경하거나 최신 형식을 다운그레이드해야 하며 이로 인해 스트림 전용 필드에 저장된 정보가 손실될 수 있습니다. 잘못 선택하면 헤더에 명시된 PDF 버전이 내부 구조와 일치하지 않는 파일이 생성될 수 있으며, 버전 감지를 사용하여 테이블 해석 방법을 결정하는 파서를 혼란스럽게 할 수 있습니다. 일부 독자는 헤더 버전을 신뢰하고 ASCII 테이블에서 스트림 구문 분석을 시도하여 구문 분석 오류를 생성하는 반면, 다른 독자는 실제 테이블 형식을 검사하고 올바르게 렌더링합니다.
병합된 PDF에 상호 참조 테이블 문제가 있음을 나타냄
상호 참조 손상은 숙련된 PDF 사용자가 신속하게 식별할 수 있는 일련의 인식 가능한 증상을 생성합니다. 가장 눈에 띄는 징후는 한 뷰어에서는 올바르게 열리지만 다른 뷰어에서는 오류나 빈 페이지를 표시하는 병합된 PDF입니다. 이러한 불일치는 시청자마다 구조적 오류에 대한 허용 수준이 극적으로 다르기 때문에 발생합니다. Adobe Acrobat은 가장 관대하며 손상된 상호 참조 테이블을 경험적으로 즉석에서 재구축하려고 시도하며 종종 문서를 렌더링할 만큼 충분히 성공합니다. Chrome의 PDFium 및 Firefox의 PDF.js와 같은 브라우저 기반 뷰어는 Acrobat이 자동으로 수정하는 테이블 불일치가 발생할 경우 파일 렌더링을 전혀 거부하는 훨씬 더 엄격한 파서입니다.
페이지 수준 증상은 다음 진단 단서입니다. 특정 페이지 개체에 대한 상호 참조 항목이 잘못된 바이트 오프셋을 가리키는 경우 뷰어는 올바른 페이지 콘텐츠 스트림을 찾을 수 없으며 빈 흰색 페이지를 렌더링하거나 다른 페이지의 콘텐츠를 반복합니다. 사용자는 특정 페이지에서 이미지가 누락되거나 빈 회색 직사각형으로 대체되는 것을 확인할 수도 있습니다. 이러한 이미지 오류는 이미지 스트림이 병합된 파일의 새 위치로 이동할 때 다시 계산되지 않은 교차 참조 테이블의 XObject 항목에 해당합니다. 왜곡되어 나타나거나 특정 페이지에서 잘못된 글꼴을 사용하는 텍스트는 잘못된 바이트 오프셋이 있는 글꼴 설명자 항목을 나타내므로 뷰어는 문자를 다르게 매핑하는 기본 글꼴을 대체하게 됩니다.
눈에 덜 띄지만 똑같이 중요한 신호는 빠른 시각적 검사를 통과했지만 공식적인 PDF 버전 제어 유효성 검사 또는 실행 전 검사에 실패한 파일입니다. 인쇄소와 규제 기관은 제출된 모든 파일에 대해 자동화된 PDF/A 또는 PDF/X 유효성 검사를 실행합니다. 상호 참조 테이블 오류는 화면에 눈에 띄는 렌더링 문제를 일으키지 않더라도 이러한 유효성 검사에 실패하고 사람이 보기 전에 파일이 거부되게 만듭니다. 법원에 법적 문서를 제출하거나 규제 기관에 재무 보고서를 제출하는 조직의 경우 실행 전 거부는 법적 마감일을 놓치고 실제 재정적 결과를 초래하는 재제출 벌금을 의미할 수 있습니다.
상호 참조 테이블 형식 및 병합 동작
| 형식 | 도입 | 구조 | 호환성 | 병합 위험 |
|---|---|---|---|---|
| ASCII 상호 참조 테이블 | PDF 1.0 | 사람이 읽을 수 있는 바이트 오프셋이 있는 일반 텍스트 | 최고; 모든 독자가 그것을 지지한다 | 낮은; 간단하게 다시 계산할 수 있습니다. |
| 상호 참조 스트림 | PDF 1.5 | 가변 너비 필드가 있는 압축 바이너리 | 현대 독자에게는 높음; 2010년 이전에는 실패할 수 있음 | 중간; 필드 너비는 정확한 재계산이 필요합니다. |
| 하이브리드(두 테이블 모두) | PDF 1.5+ | 레거시 폴백을 위한 스트림 및 ASCII 트레일러 | 좋은; 최신 독자는 스트림, 레거시 폴백을 사용합니다. | 높은; 둘 다 일관성을 유지해야 함 |
다른 PDF 라이브러리에서 상호 참조 테이블을 처리하는 방법
| 라이브러리/도구 | 기본 테이블 | 증분 저장 | 병합 동작 |
|---|---|---|---|
| LibreOffice / OpenOffice 내보내기 | ASCII 테이블 | 아니요; 항상 새 테이블 전체를 작성합니다. | 플랫 ASCII 테이블; 쉬운 병합, 더 큰 파일 |
| 리포트랩(파이썬) | ASCII 테이블 | 아니요 | 간단한 구조; 자동화된 병합에 적합 |
| iText / iTextSharp | 스트림(PDF 1.5+) | 예; 증분 저장을 지원합니다 | 형식을 조정하려면 올바른 API 호출이 필요합니다. |
| 새우(루비) | ASCII 테이블만 해당 | 아니요 | 간단한 병합 친화적; 제한된 기능 |
| Microsoft PDF로 인쇄 | 상호 참조 스트림 | 아니요 | 라이브러리 출력과 다른 구조를 생성할 수 있습니다. |
| 애플 쿼츠(macOS/iOS) | 상호 참조 스트림 | 예 | macOS 관련 메타데이터를 전달할 수 있음 |
병합 일괄 처리에 포함된 각 파일의 소스 라이브러리를 알면 호환성 문제가 발생하기 전에 예측할 수 있습니다. ASCII 테이블을 사용하는 ReportLab 및 Prawn의 파일은 상호 참조 충돌 위험을 최소화하면서 함께 병합됩니다. ReportLab 파일을 압축된 스트림을 사용하는 iText 파일과 결합하려면 두 형식을 모두 이해하고 이를 하나의 일관된 표현으로 정규화할 수 있는 병합 도구가 필요합니다. 가장 신뢰할 수 있는 병합 도구는 병합을 시작하기 전에 각 입력 파일의 상호 참조 형식을 검사하고 모든 입력을 데이터 손실 없이 변환할 수 있는 통합 출력 형식을 선택합니다.
테이블 형식이 충돌하는 PDF를 병합하기 위한 안전한 작업 흐름
다양한 소스의 PDF에 대한 체계적인 병합 작업 흐름은 병합이 시작되기 전에 모든 입력 파일의 상호 참조 테이블 형식을 검사하는 것으로 시작됩니다. 시간이 지남에 따라 상호 참조 오류가 발생합니다. 대부분의 PDF 메타데이터 뷰어 및 명령줄 검사 도구는 파일이 ASCII 테이블, 압축 스트림 또는 하이브리드 접근 방식을 사용하는지 여부를 보고할 수 있습니다. 모든 입력 파일이 동일한 테이블 형식을 공유하는 경우 병합 작업은 구조적 위험이 낮고 직접 진행할 수 있습니다. 입력 집합에 따라 형식이 다른 경우 병합하기 전에 균일한 기준선을 만들기 위해 추가 준비 단계가 필요합니다.
형식 충돌이 있는 경우 가장 안전한 병합 전 단계는 모든 입력 파일을 공통 형식으로 정규화하는 것입니다. 명시적 형식 다운그레이드를 지원하는 PDF 최적화 도구를 사용하여 압축 스트림을 사용하는 파일을 ASCII 테이블로 변환합니다. 이러한 정규화는 각 파일의 크기를 일시적으로 20~40% 증가시키지만 병합 작업에 대해 완전히 균일한 기준선을 만듭니다. 병합이 성공적으로 완료된 후 파일 크기가 문제인 경우 통합 ASCII 테이블을 최종 출력의 압축된 스트림으로 다시 변환하는 병합 후 최적화 단계를 실행하세요. 정규화 후 병합 후 다시 최적화하는 이 2단계 접근 방식은 처리 시간을 추가하지만 가장 일반적인 상호 참조 테이블 손상 원인을 제거합니다.
정규화된 입력을 사용하여 병합을 수행한 후 두 개 이상의 서로 다른 PDF 뷰어를 사용하여 출력의 유효성을 검사합니다. 그 중 하나는 VeraPDF와 같은 엄격한 유효성 검사기 또는 Adobe Acrobat Pro에 내장된 프리플라이트 검사기여야 합니다. 관용적인 데스크톱 뷰어와 엄격한 표준 검사기 모두에서 오류 없이 열리는 파일은 모든 리더 소프트웨어, 운영 체제 및 내장된 보기 컨텍스트에서 올바르게 작동할 확률이 높습니다. 중요 업무용 병합 문서의 경우 브라우저 엔진이 상호 참조 테이블 불일치에 가장 민감하므로 브라우저 기반 뷰어를 사용하여 세 번째 유효성 검사 패스를 추가합니다.
WukongPDF의 병합 엔진을 포함하여 상호 참조 조정을 잘 처리하는 도구는 병합 프로세스 자체에서 테이블 형식 감지 및 정규화를 자동화합니다. 두 테이블 형식을 모두 이해하는 병합 도구를 한 번 통과하면 수동 정규화 단계가 제거되고 첫 번째 시도에서 유효성 검사를 통과하는 병합 파일이 생성되므로 다단계 수동 조정 워크플로의 시간과 불확실성이 절약됩니다.
반복적인 병합 작업 흐름에서 상호 참조 충돌 방지
여러 소스의 PDF를 정기적으로 병합하는 조직은 전체 문서 도구 체인에서 PDF 생성 설정을 표준화함으로써 상당한 이점을 얻습니다. 동일한 상호 참조 테이블 형식, 동일한 대상 PDF 버전 및 동일한 색상 공간 처리를 사용하도록 조직의 모든 PDF 내보내기 도구를 구성합니다. 이러한 표준화 노력에는 구성 시간의 초기 투자가 필요하지만 병합된 문서의 상호 참조 충돌과 관련된 문제 해결 오버헤드를 제거함으로써 그 자체로 여러 배의 비용을 지불합니다. 모든 입력 파일이 동일한 테이블 형식을 사용하면 병합 작업이 결정적이고 안정적이 됩니다.
외부 파트너 및 클라이언트로부터 파일을 받을 때 일반적으로 발생하는 모든 소스 도구에서 PDF 생성 설정을 제어할 수 없는 경우 문서 처리 워크플로에서 필수 병합 전 정규화 단계를 설정하세요. 병합 작업이 허용되기 전에 일괄 처리 도구를 사용하여 들어오는 모든 PDF를 균일한 형식으로 변환합니다. 이 정규화 단계에서는 파일당 몇 초의 처리 시간이 추가되지만 다운스트림 렌더링 문제를 디버깅하는 데 몇 시간이 걸리지 않습니다. PDF를 처리하는 모든 팀원이 모든 병합 배치에 걸쳐 일관되게 동일한 변환 매개변수를 적용할 수 있도록 표준 운영 절차에 정확한 정규화 설정을 문서화합니다.