PDF File Format
The PDF file format is broadly divided into four areas: the Header, the Body, the Cross-reference Table, and the File Trailer. The role of each is described below. Header: A total of 8 bytes, containing the PDF signature and the version information of the PDF document. Body: Composed of objects that contain the actual document information, and these objects are linked together in a tree structure. Cross-reference Table: A table used when referencing each object, storing information such as whether an object is in use and its number. File Trailer: Records which of the objects in the File Body is the root object, and where the Cross-reference Table is located.
File Body
- startxref: Identifies the starting position of the Cross-reference table (the xref offset position).
- Check the offset (17) of the first subsection of the /Root starting point.
- Going to offset 17, the value
1 0 objexists; from there on, objects can be searched and identified based on the page-level2 0object ID values. - The second
0value (in1 0) means the generation count. When an object value is updated, that number may change. When it changes, the second argument value of the Cross-reference must also change accordingly. => The offset can be verified with the HxD Hex Editor.
Cross-reference table
- The Cross-reference Table records the position values of the objects in the Body and whether they are in use.
xref 0 55
0000000000 65535 f 0000081775 00000 n %1 0000001178 00000 n %2
0 55
- The first number is the starting object number, and the second number means the number of subsections.
Whether an object is in use is indicated by "f" (free entry) or "n" (in-use entry). 0000000000 65535 f nnnnnnnnnn ggggg f eol
nnnnnnnnnn is the number of the next free object. ggggg is the 5-byte generation number. f indicates that this entry is a free, unused entry. eol means a 2-character end-of-line combination.
Description
- The first entry in the table (object number 0) is always a free entry.
- It has a generation number of 65,535.
- In the linked list, the last entry links back to this first entry (object number = 0).
0000081775 00000 n nnnnnnnnnn ggggg n eol
nnnnnnnnnn is the 10-byte position offset of the corresponding indirect object. ggggg is the 5-byte object generation number. n indicates that this entry is currently in use. eol means a 2-character end-of-line combination.
File Trailer
The Trailer is located at the end of the file and indicates the position of the Root object and the position of the Cross-reference Table. According to the documentation released by Adobe Systems, the format is designed so that after reading the header at the very front, you then check the Trailer at the end of the file. It starts with the "trailer" keyword and ends with "%EOF".
Example: trailer << => << ~ >> indicates the attributes of the current object /Size 55 => The number of entries in the Cross-reference Table (same as the second argument of xref) /Root 54 0 R => Means it references an object (R: reference link) /Info 53 0 R => Document information (author, title, creation, etc.)
startxref 82029: Cross-reference start offset %%EOF
Document Structure
-
Document catalog In the document object hierarchy, the root is the catalog dictionary, whose location can be found via the /Root entry in the PDF file trailer. /Type entry: (required) Its value is a name object and must be the value /Catalog. /Pages entry: (required) Its value is an indirect dictionary object reference and must point to the root page tree of the document's page trees.
-
Page tree The pages of a document are accessed through a structure known as the page tree, which defines the order of the pages within the document.
< page tree node > < leaf node called a page object >
/Type entry: (required) Its value is a Name object and must have the value /Page.
/Parent entry: (required) Its value is an indirect dictionary object reference and holds the parent page tree of the corresponding page tree. This entry is not required for the root.
/Kids entry: (required) Its value is an array object, and the array holds references to the direct children of the corresponding page tree. A child may be a page object directly, or it may be another page tree.
/Count entry: (required) Its value is an Integer object and holds the number of page objects under the corresponding page tree.
- Page object A page object specifies the characteristics for each page of the document. Some of the entries of a page object may be inherited from parent page trees. The following shows an example of the overall page tree structure. As you can see, pages 1 and 2 inherit the /Rotate entry characteristic from their parent and have a /Rotate value of 90.
PDF Data Type
-
Comments Comments denote annotations in PDF; they start with the "%" delimiter and end at End-of-Line. These Comments may appear between keywords, at the beginning or end of a file, and so on.
-
Boolean Boolean represents true ("true") and false ("false") within a PDF object.
-
Numeric Numeric is used to represent numbers in PDF. It is broadly divided into Integer objects and Real objects, with examples of each shown in the figure below.
-
Literal String Literal String is used to represent a string in PDF. "(" marks the start of the string, and ")" marks the end of the string.
Within a Literal String, individual "(", ")", or "" are not allowed. As you can see from the figure above, when "(" and ")" within a Literal String form matched pairs, they are recognized as part of the string without any special handling.
Individual "(" or ")", or special characters, can be expressed as escape sequences using "".
-
Hexadecimal Strings A Hexadecimal String consists of 2-byte data made up of 0-9 and A-F within "<" and ">", each recognized as a single Hex data unit. White-space within this string is ignored.
-
Name In PDF, a Name is a string following "/", composed of characters from 0x21 to 0x7E. Within this data type, "#" causes the following 2 bytes of characters to be treated as a single Hex value; the table below makes this easy to understand.
-
Array An Array in PDF is an array that starts with "[" and ends with "]". Each element within the array can hold any PDF data type, including Name, String, Number, Dictionary, and even another Array. An empty Array with no elements also exists.
-
Dictionary A Dictionary consists of Key-Value pairs within "<<" and ">>". The Key must be of type Name, and the Value can hold any data type, including another Dictionary. An empty Dictionary with no elements also exists.
-
Indirect Indirect is expressed as "n1 n2 R" and represents an object being referenced.
-
Stream A Stream exists within an object, between the "stream" keyword and the "endstream" keyword.
A Stream indicates several attributes in that object's Dictionary; basically, /Length must indicate the length of the Stream.
- MediaBox/CropBox/BleedBox/TrimBox/ArtBox
Background Information on Boxes
Five areas (boxes) play a role in printing a PDF document. These are called the MediaBox, TrimBox, BleedBox, CropBox, and ArtBox. Here, you can configure or modify a PDF document. Recurring problems include PDF files with no boxes (e.g., trim marks included but no margins), incorrectly set boxes (e.g., a MediaBox that is too large), or inconsistent boxes within a single document. You can use geometry adjustment to set or modify these areas of a PDF document.
MediaBox
The MediaBox contains all objects on the page, including text and images that are displayed on the page or that protrude beyond the page edges. The MediaBox technically shows and defines the physical media limits, on which the page is printed. Alongside the finished page, it can have space for trim marks and color bars in particular. Content outside the MediaBox can be removed without changing the important content of the PDF file, because Adobe® Acrobat® ignores objects outside the MediaBox when creating a PDF file. The media box is allways [0,0,page width, page height].
CropBox
The page size visible on screen and the page size reported by Acrobat is the CropBox size, not the MediaBox size. The box displayed on screen defines the range within which the page content is cropped when the page content is displayed and printed. Unlike the other areas, this area has no defined meaning in relation to the physical page appearance or intended use. It only specifies the cropping of the page content. In the absence of other additional information (e.g., imposition instructions specified in a JDF or PJTF job), the CropBox determines how the page content is placed on the output media.
BleedBox
The BleedBox indicates an area extended around the TrimBox; in this area, the entire page content is trimmed when a bleed area is present. A document that requires bleed also needs a BleedBox. The BleedBox is always larger than the TrimBox and smaller than the MediaBox. Within the bleed range, press marks, fold marks and trim marks, and informational text can be placed over the printed page.
TrimBox
The TrimBox indicates the final size of the document after printing and trimming. A document created for printing at a print shop requires a TrimBox. The TrimBox must be smaller than the BleedBox and the MediaBox.
ArtBox
When PDF content is placed, for example when used in a DTP program, the ArtBox where it can be positioned expresses the extent of the page (e.g., a graphics file). The ArtBox must be smaller than the BleedBox.
Filter (Compression Form)
FlateDecode: Decompresses data encoded using the zlib / deflate compression method and reproduces the original text or binary data. Resources /XObject << /x7 7 0 R /x10 10 0 R >>
This denotes the external object resource name.
Should this be identical to 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 : whether to apply anti-aliasing /BitsPerComponent 8 : the number of bits per pixel of the image
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) : a string identifying the issuer of the character collection /Ordering (Identity) : the unique name of the character collection /Supplement 0 : the supplement number of the original character collection
/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: A description of the widths of the glyphs in the CIDFont. Elements of the array have a variable format that can specify individual widths for consecutive CIDs or a single width for a range of CIDs.
Font Descriptor
29 0 obj << /Type /FontDescriptor /FontName /OEHHEY+HCRDotum (same as BaseFont) /FontFamily (HCR Dotum) /Flags 4 /FontBBox [ -1283 -426 3268 1082 ] /ItalicAngle 90 /Ascent 1070 : above the baseline /Descent -230 : below the baseline /CapHeight 1082 /StemV 80 /StemH 80 /FontFile2 25 0 R
endobj
Font Types
General overview format
Type 1
This was the original outline format created by Adobe together with the Postscript language for printers. Glyph outlines are described using a simplified version of Postscript.
TrueType This is the best known of the font formats that Apple and Microsoft created for operating systems. Glyph outlines are described using a special language unique to this font format.
OpenType Type 1 and TrueType fonts each had their advantages, but the industry grew tired of the "font wars," and so OpenType was born. OpenType combines the advantages of the other formats to the fullest extent, describing glyph outlines as either Type 1 or TrueType.
PDF-only fonts
Type 0:
A Type 0 font points to a single CIDFont.
A Type 0 font, also called a composite font or CIDFont, is created by taking glyph descriptions from one or more other fonts to form an amalgam or composite. This was originally needed when working with fonts that used only a single font with no English/Latin characters, such as Chinese/Japanese/Korean (CJK). In practice, it is not used to mix glyphs from multiple fonts, but it is still used as the method for Unicode fonts, particularly when handling 2-byte data.
Type 2:
Contains the glyph descriptions of a CIDFont and uses the TrueType font format.
Type 3:
Originally provided as a way to embed bitmap fonts, a Type 3 font is actually a PDF dictionary in which each glyph is defined by a standard content stream. This makes it possible to define glyphs using not only raster-based glyphs but any/all PDF graphics operators. It can be very powerful, but it is not used in most PDF generation systems today.
Source:
- http://panda2122.tistory.com/10?category=700538
- https://wiki.scribus.net/canvas/PDF*Boxes*:\_mediabox,\_cropbox,\_bleedbox,\_trimbox,\_artbox
- Font
- Font1