PDF File Format

PDF 파일 포맷은 크게 Header, Body, Cross-reference Table, File Trailer로 총 4가지 영역으로 구분된다. 각각의 역할은 아래와 같다. Header : 총 8바이트로, PDF의 시그니처와 PDF 문서의 버전 정보를 포함한다. Body : 실제 문서의 정보들을 포함하는 오브젝트들로 구성되고, 이 오브젝트들은 트리 형태로 링크되어있다. Cross-reference Table : 각 오브젝트들을 참조할 때 사용되는 테이블로, 오브젝트의 사용 여부와 번호 등이 저장된다. File Trailer : File Body에 존재하는 오브젝트 중 루트 오브젝트가 무엇인지, Cross-reference Table이 어디에 있는지 기재된다.

File Body

startxref : Cross-reference table의 시작위치(xref offset위치) 를 확인
/Root 시작점의 1번째 서브섹션의 offset(17)을 확인
offset 17을 가면 1 0 obj값이 존재 그 이후부터는 page 단위의 2 0 object ID값을 바탕으로 object를 검색해서 확인가능
2번째 0값은(1 0) 생성 수를 의미, object값이 업데이트 될 경우 해당 숫자는 변경될 수 있다. 변경될 경우 Cross-reference의 2번째 인자값도 같이 변경되어야한다. => offset의 HxD Hex Editor 확인가능

Cross-reference table

Cross-reference Table은 Body에 존재하는 오브젝트들의 위치값과 사용 여부를 기록한다.

xref 0 55

0000000000 65535 f 0000081775 00000 n %1 0000001178 00000 n %2

0 55

오브젝트의 시작 번호, 두번째 숫자는 서브섹션 개수를 의미

오브젝트의 사용 여부는 “f”(free entry) 또는 “n”(in-use entry)으로 표기 0000000000 65535 f nnnnnnnnnn ggggg f eol

nnnnnnnnnn 은 다음 사용되지 않는 오브젝트 수이다. ggggg 는 5 바이트 생성 숫자이다. f 는 이 엔트리가 사용되지 않는 빈 엔트리임을 나타낸다. eol 은 2 글자의 end-of-line 조합을 의미한다.

설명

테이블에서 첫 엔트리(오브젝트 수가 0)는 항상 빈 엔트리
65,535 라는 생성 숫자가짐
링크드 리스트에서 마지막 엔터리는 다시 이 첫번째 엔트리(오브젝트 수=0)와 연결

0000081775 00000 n nnnnnnnnnn ggggg n eol

nnnnnnnnnn 은 은 10 바이트의 해당 간접 오브젝트의 위치 오프셋이다 ggggg 는 5 바이트의 오브젝트 생성 숫자이다. n 은 현재 이 엔트리는 사용되고 있음을 나타낸다. eol 은 2 글자의 end- of- line 조합을 의미한다

File Trailer

Trailer는 파일의 끝에 위치하여 Root 오브젝트의 위치와 Cross-reference Table의 위치를 표시한다. Adobe Systems에서 배포한 문서를 보면, 맨 앞의 헤더를 읽은 후 파일의 끝의 Trailer를 확인하도록 포맷이 설계되어 있다. “trailer”라는 지시어로 시작하여 “%EOF”로 끝난다.

예제 : trailer << => << ~ >> 현재 오브젝트의 속성을 표기 /Size 55 => Cross-reference Table의 항목수(xref 2번째 인자와 동일) /Root 54 0 R => 오브젝트를 참조한다는 의미(R : reference 연결) /Info 53 0 R => document 정보(저자, 타이틀, 생성등등)

startxref 82029 : Cross-reference start offset %%EOF

문서구조

문서 catalog (Document catalog) 문서 오브젝트 계층도에서 루트는 catalog dictionary 인데, PDF 파일 트레일러에서 /Root 엔트리에 의해 그 위치를 찾을 수 있다. /Type 엔트리 : (필수) 값으로는 name 오브젝트 가지며 반드시 /Catalog 값이어야 한다. /Pages 엔트리 : (필수) 값으로는 간접 dictionary 오브젝트 참조 값을 가지며 문서 페이지 트리들의 루트 페이지 트리를 가르켜야 한다.
페이지트리 문서의 페이지들은 문서 내 페이지 순서를 정의하는 페이지 트리라고 알려진 구조를 통해 접근된다.
```
     < 페이지 트리 노드 >                       < 페이지 오브젝트라 불리는 잎(leaf) 노드 >
```

/Type 엔트리 : (필수) 값으로는 Name 오브젝트를 가지고, /Page 값을 반드시 가져야 한다.

/Parent 엔트리 : (필수) 값으로는 간접 dictionary 오브젝트 참조값를 가지고, 해당 페이지 트리의 아버지 페이지 트리 값을 가진다. 루트일 경우 이 엔트리는 없어도 된다.

/Kids 엔트리 : (필수) 값으로는 array 오브젝트를 가지고, array 는 해당 페이지 트리의 직접적인 자식에 대한 참조 값을 가진다. 자식은 곧바로 페이지 오브젝트일 수도 있고, 또 다른 페이지 트리 일 수 있다.

/Count 엔트리 : (필수) 값으로는 Integer 오브젝트를 가지고, 해당 페이지 트리 하위에 있는 페이지 오브젝트의 수를 가진다.

페이지 오브젝트 페이지 오브젝트는 문서의 각 페이지에 대한 특성을 명시한다. 페이지 오브젝트의 엔트리 중 몇몇은 부모 페이지 트리들로부터 물려 받을 수도 있다. 다음은 전체적인 페이지 트리 구조 예를 보여준다. 보면 페이지 1 과 2 는 부모로부터 /Rotate 엔트리 특성을 물려받아 /Rotate 가 90 인 값을 갖는다.

PDF Data Type

Comments Comments는 PDF에서 주석을 의미하는 것으로, “%” 구분자로 시작하여 End-of-Line으로 끝난다. 이 Comments는 지시어 사이, 파일의 처음 또는 끝 등에 존재할 수 있다.
Boolean Boolean은 PDF의 오브젝트 내에서 참(“true”)과 거짓(“false”)을 나타낸다.
Numeric Numeric은 PDF에서 숫자를 표현 할 때 사용된다. 크게 Integer objects와 Real objects로 구분되며, 각각의 예는 아래 그림과 같다.
Literal String Literal String은 PDF에서 문자열을 나타낼 때 사용된다. “(“로 문자열의 시작을, “)”로 문자열의 끝을 알린다.

Literal String 내에서는 개별적인 “(“, “)” 또는 “\”를 허용하지 않는다. 위의 그림을 보면 알 수 있겠지만 Literal String 내의 “(“, “)”는 쌍으로 이루어져 있을 때에는 특별한 처리 없이 문자열로 인식된다.

개별적인 “(“ 또는 “)” 혹은 특수한 문자들은 “\”를 이용해 시퀀스 문자로 표현할 수 있다.

Hexadecimal Strings Hexadecimal String은 “<”와 “>” 안의 0-9, A-F로 이루어진 2바이트의 데이터가 하나의 Hex data로 인식된다. 이 문자열 안의 White-space는 무시된다.
Name PDF에서 Name은 “/” 이후의 문자열로, 0x21에서 0x7E까지의 문자로 구성된다. 이 자료형 내에서 “#”은 이후 2바이트의 문자가 하나의 Hex 값으로 취급하는데, 아래의 표를 보면 이해가 쉬울 것이다.
Array Array는 PDF에서 “[“로 시작하여 “]”로 끝나는 배열을 의미한다. 배열 내 각 요소들은 Array를 포함한 Name, String, Number, Dictionary 등 PDF의 모든 자료형을 가질 수 있다. 요소가 없는 빈 Array도 존재한다.
Dictionary Dictionary는 “<<”와 “>>” 내에서 Key-Value의 쌍으로 구성된다. Key는 반드시 자료형이 Name이어야 하고, Value는 Dictionary를 포함 한 모든 자료형을 가질 수 있다. 요소가 없는 빈 Dictionary도 존재한다.
Indirect Indirect는 “n1 n2 R”과 같이 표현되며 Referencing 하는 오브젝트를 표현한다.
Stream Stream은 오브젝트 내에서 “stream” 키워드와 “endstream” 키워드 사이에 존재한다.

Stream은 해당 오브젝트의 Dictionary에서 몇 가지의 속성을 지시하는데, 기본적으로 /Length로 Stream의 길이를 나타내주어야 한다.

MediaBox/CropBox/BleedBox/TrimBox/ArtBox

영역에 대한 배경 정보

PDF 문서를 인쇄하는데는 5개의 영역(박스)이 역할을 합니다. 이는 미디어 박스(MediaBox), 트림 박스(TrimBox), 화선물림재단 영역(BleedBox), 크롭 박스(CropBox) 및 아트 박스(ArtBox)라고 합니다. 여기서는 PDF 문서를 설정하거나 수정할 수 있습니다. 반복적으로 발생하는 문제는 영역이 없는 PDF 파일(예: 트림 표시 포함, 여백 없음), 잘못 설정된 영역(예: 너무 큰 미디어 박스) 또는 한 문서 내의 통일되지 않은 영역 등이 있습니다. 형상 조절을 사용하여 PDF 문서의 이러한 영역을 설정하거나 수정할 수 있습니다.

미디어 박스(MediaBox)

미디어 박스에는 페이지에 표시되거나 페이지의 가장자리를 돌출하는 텍스트 및 이미지를 포함하여 페이지의 모든 객체를 포함합니다. 미디어 박스는 물리학적 미디어 한계를 기술적으로 보여주고 정의하여, 그 위에 페이지가 인쇄되도록 합니다. 그것은 완성된 페이지 옆에 특히 트림 표시를 할 공간, 색상줄무늬를 가질 수 있습니다. 미디어 박스 밖에 있는 내용을 PDF 파일의 중요한 내용을 변경하지 않고 제거할 수 있는데 그 이유는 Adobe® Acrobat®에서 PDF 파일 작성시 미디어 박스 밖의 객체를 무시하기 때문입니다. The media box is allways [0,0,page width, page height].

크롭 박스(CropBox)

화면상에 보이는 페이지 크기, Acrobat에서 알려주는 페이지 크기는 MediaBox 크기가 아니라 CropBox 크기임 화면상에 표시되는 박스는 페이지 내용이 표시되고 인쇄될 때, 페이지 내용이 재단되는 범위를 정의합니다. 다른 영역과는 달리 이 영역은 물리적 페이지 외형 또는 의도되는 용도와 관련하여 정의된 의미가 없습니다. 이는 페이지 내용의 절단만을 지정할 뿐입니다. 다른 추가적인 정보 (예: JDF 또는 PJTF 작업에 터잡기 지시 지정됨)가 없다면 크롭 박스는 페이지 내용이 출력 미디어에 어떤 식으로 배치되는지 결정합니다.

화선물림재단 영역(BleedBox)

화선물림재단 영역에서는 트림 박스(TrimBox) 둘레의 확장된 영역을 표시하여 이 영역에서는 재단 영역이 있을 경우 전체 페이지 내용이 재단됩니다. 화선물림재단을 요구하는 문서는 또한 화선물림재단 영역을 필요로 합니다. 재단 물림 상자는 항상 트림 상자(TrimBox)보다는 크고 미디어 상자(MediaBox)보다는 작습니다. 화선물림재단 범위에서 프레스 표시, 접지 표시와 재단 표시, 정보 텍스트는 인쇄된 페이지 위에 배치될 수 있습니다.

트림 박스(TrimBox)

트림 박스는 인쇄와 재단 후 문서의 최종적 크기를 나타냅니다. 인쇄소의 인쇄를 위해 작성된 문서는 트림 박스를 요구합니다. 트림 박스는 재단 물림 상자(BleedBox) 및 미디어 상자(MediaBox)보다 작아야 합니다.

아트 박스(ArtBox)

PDF 내용이 예컨대, DTP 프로그램 사용에서 배치될 때, 위치될 수 있는 아트 박스는 페이지의 범위(예: 그래픽 파일)를 표현합니다. 아트 상자는 재단 물림 상자(BleedBox)보다 작아야 합니다.

Filter(압축형태)

FlateDecode : zlib / deflate 압축 방식을 사용하여 인코딩 된 데이터의 압축을 풀고 원본 텍스트 또는 이진 데이터를 재생합니다. Resources /XObject << /x7 7 0 R /x10 10 0 R >>

external object resource name을 뜻한다.

x7 7 과 동일해야하는것인가?

Image

7 0 obj << /Length 12 0 R /Filter /FlateDecode /Type /XObject /Subtype /Image : type XObject SubType : /Width 170 /Height 182 /ColorSpace /DeviceRGB /Interpolate true : anti-aliasing 할지여부 /BitsPerComponent 8 : 이미지의 픽셀 당 비트 수

Font

5 0 obj << /Type /Font /Subtype /Type0 /BaseFont /OEHHEY+HCRDotum /Encoding /Identity-H /DescendantFonts [ 30 0 R] : CIDFont dictionary array /ToUnicode 27 0 R

CIDFont dictionary entries

30 0 obj << /Type /Font /Subtype /CIDFontType2 /BaseFont /OEHHEY+HCRDotum /CIDSystemInfo << /Registry (Adobe) : 문자 집합의 발행자를 식별하는 문자열 /Ordering (Identity) : 문자집한의 유니크한 이름 /Supplement 0 : 원본 문자집합 모음의 보유 번호

/FontDescriptor 29 0 R /W [0 [ 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 970 ]]

endobj

/W : CIDFont에있는 글리프의 너비에 대한 설명입니다. 배열의 요소에는 연속적인 CID에 대한 개별 너비 또는 CID 범위에 대한 하나의 너비를 지정할 수있는 가변 형식이 있습니다.

Font Descriptor

29 0 obj << /Type /FontDescriptor /FontName /OEHHEY+HCRDotum (BaseFont와 동일) /FontFamily (HCR Dotum) /Flags 4 /FontBBox [ -1283 -426 3268 1082 ] /ItalicAngle 90 /Ascent 1070 : 기준 위 /Descent -230 : 기준선 아래 /CapHeight 1082 /StemV 80 /StemH 80 /FontFile2 25 0 R

endobj

Font Types

일반적인 개요형식

Type 1

이것은 프린터 용 Postscript 언어와 함께 Adobe에서 작성한 원래 개요 형식이었습니다. 글리프 개요는 Postscript의 단순화 된 버전을 사용하여 설명됩니다.

트루 타입 Apple과 Microsoft가 운영 체제 용으로 만든 폰트 형식 중 가장 잘 알려져 있습니다. 글리프 개요는이 글꼴 형식에 고유 한 특수 언어를 사용하여 설명됩니다.

OpenType 유형 1과 트루 타입 글꼴에는 각각 장점이 있지만 업계에서는 “글꼴 전쟁”에 질려서 OpenType이 탄생했습니다. OpenType은 다른 형식의 장점을 최대한으로 결합하여 글리프 외곽선 옵션을 유형 1 또는 트루 타입으로 설명합니다.

PDF 전용글꼴

Type 0 :

type 0 글꼴은 단일 CIDfont를 가리킨다.

복합 글꼴 또는 CIDFont라고도하는 Type 0 글꼴은 하나 이상의 다른 글꼴에서 글리프 설명을 가져 와서 아말감이나 복합체를 만들어서 만듭니다. 이것은 원래 중국어 / 일본어 / 한국어 (CJK)로 영어 / 라틴 문자가없고 한 글꼴 만 사용하는 글꼴로 작업 할 때 필요했습니다. 실제로 여러 글꼴에서 글리프를 혼합하는 데 사용되지는 않지만 유니 코드 글꼴에 사용되는 방법, 특히 2 바이트 데이터를 처리하는 경우에는 여전히 사용됩니다.

Type 2:

CIDFont의 glyph 설명을 포함하고 TrueType폰트 포멧

Type 3 :

원래 비트 맵 글꼴을 임베드하는 방법으로 제공되는 Type 3 글꼴은 실제로 각 글리프가 표준 컨텐트 스트림에 의해 정의되는 PDF 사전입니다. 이렇게하면 래스터 기반 글리프뿐만 아니라 모든 / 모든 PDF 그래픽 연산자를 사용하여 글리프를 정의 할 수 있습니다. 매우 강력 할 수 있지만 오늘날 대부분의 PDF 생성 시스템에는 사용되지 않습니다.

출처 :

홍승아블로그

pdf