PDF Reference sixth edition, Adobe Portable Document Format Version 1.7 (book 2) — page 12
1043
SECTION F.3
Hint Tables
ITEM
SIZE (BITS)
DESCRIPTION
5
See Table F.3, item 12
(One item for each shared object referenced from the page) The numerator of
the fractional position for each shared object reference, in the same order as
the preceding item. The fraction indicates where in the page’s content stream
the shared object is first referenced. This item is interpreted as the numerator
of a fraction whose denominator is specified once for the entire document
(Table F.3, item 13).
If the denominator is d, a numerator ranging from 0 to d − 1 indicates the
corresponding portion of the page’s content stream. For example, if the
denominator is 4, a numerator of 0, 1, 2, or 3 indicates that the first reference
lies in the first, second, third, or fourth quarter of the content stream, respec-
tively.
There are two (or more) other possible values for the numerator, which indi-
cate that the shared object is not referenced from the content stream but is
needed by annotations or other objects that are drawn after the contents. The
value d indicates that the shared object is needed before image XObjects and
other nonshared objects that are at the end of the page. A value of d + 1 or
greater indicates that the shared object is needed after those objects.
This method of dividing the page into fractions is only approximate. Deter-
mining the first reference to a shared object entails inspecting the unencoded
content stream. The relationship between positions in the unencoded and
encoded streams is not necessarily linear.
6
See Table F.3, item 7
A number that, when added to the least offset to the start of the content
stream (Table F.3, item 6), gives the offset in bytes of the start of the page’s
content stream (the stream object, not the stream data), relative to the begin-
ning of the page. (See implementation note 183 in Appendix H.)
7
See Table F.3, item 9
A number that, when added to the least content stream length (Table F.3,
item 8), gives the length of the page’s content stream in bytes. This length in-
cludes object overhead preceding and following the stream data. (See imple-
mentation note 184 in Appendix H.)
F.3.2
Shared Object Hint Table
The shared object hint table gives information required to locate shared objects
(see Section F.2.8, “Shared Objects (Part 8)”). Shared objects can be physically
located in either of two places: objects that are referenced from the first page are
located with the first-page objects (part 6); all other shared objects are located in
the shared objects section (part 8).
1044
APPENDIX F
Linearized PDF
A single entry in the shared object hint table can actually describe a group of ad-
jacent objects under the following condition: Only the first object in the group is
referenced from outside the group; the remaining objects in the group are refer-
enced only from other objects in the same group. The objects in a group must
have adjacent object numbers.
The page offset hint table, interactive form hint table, and logical structure hint
table refer to an entry in the shared object hint table by a simple index that is its
sequential position in the table, counting from 0.
The shared object hint table consists of a header section (Table F.5) followed by
one or more shared object group entries (Table F.6). There are two sequences of
shared object group entries: the ones for objects located in the first page, followed
by the ones for objects located in the shared objects section. The entries have the
same format in both cases. Note that the items making up each shared object
group entry are not contiguous; they are broken up with items from entries for
other shared object groups. The order of items in each sequence is as follows:
1. Item 1 for the first group, item 1 for the second group, and so on
2. Item 2 for the first group, item 2 for the second group, and so on
3. Item 3 for the first group, item 3 for the second group, and so on
4. Item 4 for the first group, item 4 for the second group, and so on
All objects associated with the first page (part 6) have entries in the shared object
hint table, regardless of whether they are actually shared. The first entry refers to
the beginning of the first page and has an object count and length that span all
the initial nonshared objects. The next entry refers to a group of shared objects.
Subsequent entries span additional groups of either shared or nonshared objects
consecutively until all shared objects in the first page have been enumerated.
(The entries that refer to nonshared objects are never used.)
TABLE F.5 Shared object hint table, header section
ITEM
SIZE (BITS)
DESCRIPTION
1
32
The object number of the first object in the shared objects section (part 8).
2
32
The location of the first object in the shared objects section.
3
32
The number of shared object entries for the first page (including nonshared
objects, as noted above).
1045
SECTION F.3
Hint Tables
ITEM
SIZE (BITS)
DESCRIPTION
4
32
The number of shared object entries for the shared objects section, including
the number of shared object entries for the first page (that is, the value of
item 3).
5
16
The number of bits needed to represent the greatest number of objects in a
shared object group. (See also implementation note 185 in Appendix H.)
6
32
The least length of a shared object group in bytes.
7
16
The number of bits needed to represent the difference between the greatest
and least length of a shared object group, in bytes.
TABLE F.6 Shared object hint table, shared object group entry
ITEM SIZE (BITS)
DESCRIPTION
1
See Table F.5, item 7
A number that, when added to the least shared object group length (Table F.5,
item 6), gives the length of the object group in bytes. The location of the first
object of the first page is given in the page offset hint table, header section
(Table F.3, item 4). The locations of subsequent object groups can be deter-
mined by accumulating the lengths of all previous object groups until all
shared objects in the first page have been enumerated. Following that, the
location of the first object in the shared objects section can be obtained from
the header section of the shared object hint table (Table F.5, item 2).
2
1
A flag indicating whether the shared object signature (item 3) is present; its
value is 1 if the signature is present and 0 if it is absent. (See also implementa-
tion note 186 in Appendix H.)
3
128
(Only if item 2 is 1) The shared object signature, a 16-byte MD5 hash that
uniquely identifies the resource that the group of objects represents. It is in-
tended to enable the client to substitute a locally cached copy of the resource
instead of reading it from the PDF file. Note that this signature is unrelated to
signature fields in interactive forms, as defined in the section “Signature
Fields” on page 695.
1046
APPENDIX F
Linearized PDF
ITEM SIZE (BITS)
DESCRIPTION
4
See Table F.5, item 5
A number equal to 1 less than the number of objects in the group. The first
object of the first page is the one whose object number is given by the O entry
in the linearization parameter dictionary at the beginning of the file. Object
numbers for subsequent entries can be determined by accumulating the
number of objects in all previous entries until all shared objects in the first
page have been enumerated. Following that, the first object in the shared
objects section has a number that can be obtained from the header section of
the shared object hint table (Table F.5, item 1). (See also implementation note
187 in Appendix H.)
Note: In a document consisting of only one page, all of that page’s objects are never-
theless treated as if they were shared; the shared object hint table reflects this. (See
implementation note 188 in Appendix H.)
F.3.3
Thumbnail Hint Table
The thumbnail hint table consists of a header section (Table F.7) followed by the
thumbnails section, which includes one or more per-page entries (Table F.8), each
of which describes the thumbnail image for a single page. The entries are in page
number order starting with page 0, even if the document catalog contains an
OpenAction entry that specifies opening at some page other than page 0. Thumb-
nail images may exist for some pages and not for others.
TABLE F.7 Thumbnail hint table, header section
ITEM
SIZE (BITS)
DESCRIPTION
1
32
The object number of the first thumbnail image (that is, the thumbnail image
that is described by the first entry in the thumbnails section).
2
32
The location of the first thumbnail image.
3
32
The number of pages that have thumbnail images.
4
16
The number of bits needed to represent the greatest number of consecutive
pages that do not have a thumbnail image.
5
32
The least length of a thumbnail image in bytes.
6
16
The number of bits needed to represent the difference between the greatest
and least length of a thumbnail image.
1047
SECTION F.3
Hint Tables
ITEM
SIZE (BITS)
DESCRIPTION
7
32
The least number of objects in a thumbnail image.
8
16
The number of bits needed to represent the difference between the greatest
and least number of objects in a thumbnail image.
9
32
The object number of the first object in the thumbnail shared objects section
(a subsection of part 9). This section includes objects (color spaces, for exam-
ple) that are referenced from some or all thumbnail objects and are not refer-
enced from any other objects. The thumbnail shared objects are
undifferentiated; there is no indication of which shared objects are referenced
from any given page’s thumbnail image.
10
32
The location of the first object in the thumbnail shared objects section.
11
32
The number of thumbnail shared objects.
12
32
The length of the thumbnail shared objects section in bytes.
TABLE F.8 Thumbnail hint table, per-page entry
ITEM SIZE (BITS)
DESCRIPTION
1
See Table F.7, item 4
(Optional) The number of preceding pages lacking a thumbnail image. This
number indicates how many pages without a thumbnail image lie between
the previous entry’s page and this page.
2
See Table F.7, item 8
A number that, when added to the least number of objects in a thumbnail
image (Table F.7, item 7), gives the number of objects in this page’s thumbnail
image.
3
See Table F.7, item 6
A number that, when added to the least length of a thumbnail image (Table
F.7, item 5), gives the length of this page’s thumbnail image in bytes.
The order of items in Table F.8 is as follows:
1. Item 1 for all pages, in page order starting with the first page
2. Item 2 for all pages, in page order starting with the first page
3. Item 3 for all pages, in page order starting with the first page
1048
APPENDIX F
Linearized PDF
F.3.4
Generic Hint Tables
Certain categories of objects are associated with the document as a whole rather
than with individual pages (see Section F.2.9, “Other Objects (Part 9)”), and it is
sometimes useful to provide hints for accessing those objects efficiently. For each
category of hints, there is a separate entry in the primary hint stream giving the
starting position of the table within the stream (see Section F.2.5, “Hint Streams
(Parts 5 and 10)”).
Such hints may be represented by a generic hint table, which describes a single
group of objects that are located together in the PDF file. The entries in this table
are listed in Table F.9. This representation is used for the following hint tables, if
needed:
• Outline hint table
• Thread information hint table
• Named destination hint table
• Information dictionary hint table
• Page label hint table
Generic hint tables may also be useful for application-specific objects accessed by
plug-in extensions. It is considerably more convenient for a plug-in to use the ge-
neric hint representation than to specify custom hints.
TABLE F.9 Generic hint table
ITEM
SIZE (BITS)
DESCRIPTION
1
32
The object number of the first object in the group.
2
32
The location of the first object in the group.
3
32
The number of objects in the group.
4
32
The length of the object group in bytes.
F.3.5
Extended Generic Hint Tables
An extended generic hint table begins with the same entries as in a generic hint
table, followed by three additional entries, as shown in Table F.10. This table is
1049
SECTION F.3
Hint Tables
used to provide hints for accessing objects that reference shared objects. As of
PDF 1.5, the following hint tables, if needed, use the extended generic format:
• Interactive form hint table
• Logical structure hint table
• Renditions name tree hint table
Note: Embedded file streams should not be referred to by this hint table, even if
they are reachable from nodes in the renditions name tree; instead they should use
the hint table described in Section F.3.6, “Embedded File Stream Hint Tables.”
TABLE F.10 Extended generic hint table
ITEM
SIZE (BITS)
DESCRIPTION
1
32
The object number of the first object in the group.
2
32
The location of the first object in the group.
3
32
The number of objects in the group.
4
32
The length of the object group in bytes.
5
32
The number of shared object references.
6
16
The number of bits needed to represent the numerically greatest shared ob-
ject identifier used by the objects in the group.
7…
See Table F.3, item 11
Starting with item 7, each of the remaining items in this table is a shared ob-
ject identifier—that is, an index into the shared object hint table (described in
Section F.3.2, “Shared Object Hint Table”).
F.3.6
Embedded File Stream Hint Tables
The embedded file streams hint table allows a viewer application to locate all byte
ranges of a PDF file needed to access its embedded file streams. An embedded file
stream may be grouped with other objects that it references; all objects in such a
group must have adjacent object numbers. (A group may contain no objects at all
if it contains shared object references.)
This hint table has a header section (see Table F.11), which has general informa-
tion about the embedded file stream groups. The header section is followed by
the entries in Table F.12. Each of the items in Table F.12 is repeated for each em-
1050
APPENDIX F
Linearized PDF
bedded file stream group (the number of groups being represented by item 3 in
Table F.11). That is, the order of items in Table F.12 is item 1 for the first group,
item 1 for the second group, and so on; item 2 for the first group, item 2 for the
second group, and so on; repeated for the 5 items.
TABLE F.11 Embedded file stream hint table, header section
ITEM
SIZE (BITS)
DESCRIPTION
1
32
The object number of the first object in the first embedded file stream group.
2
32
The location of the first object in the first embedded file stream group.
3
32
The number of embedded file stream groups referenced by this hint table.
4
16
The number of bits needed to represent the highest object number corresponding to an
embedded file stream object.
5
16
The number of bits needed to represent the greatest number of objects in an embedded
file stream group.
6
16
The number of bits needed to represent the greatest length of an embedded file stream
group, in bytes.
7
16
The number of bits needed to represent the greatest number of shared object references
in any embedded file stream group.
TABLE F.12 Embedded file stream hint table, per-embedded file stream group entries
ITEM SIZE (BITS)
DESCRIPTION
1
See Table F.11, item 4
The object number of the embedded file stream that this entry is associated
with.
2
See Table F.11, item 5
The number of objects in this embedded file streams group. This item may be
0, meaning that there are only shared object references. In this case, item 4 for
this group must be greater than zero and item 3 must be zero.
3
See Table F.11, item 6
The length of this embedded file stream group, in bytes. This item may be 0,
meaning that there are only shared object references. In this case, item 4 for
this group must be greater than zero and item 2 must be zero.
4
See Table F.11, item 7
The number of shared objects referenced by this embedded file stream group.
1051
SECTION F.4
Access Strategies
ITEM SIZE (BITS)
DESCRIPTION
5
See Table F.3, item 11
A bit-packed list of shared object identifiers; that is, indices into the shared
object hint table (see Section F.3.2, “Shared Object Hint Table”). Item 4 for
this group specifies how many shared object identifiers are associated with
the group.
F.4
Access Strategies
This section outlines how the client can take advantage of the structure of a
Linearized PDF file to retrieve and display it efficiently. This material is not for-
mally a part of the Linearized PDF specification, but it may help explain the ratio-
nale for the organization.
F.4.1
Opening at the First Page
As described earlier, when a document is initially accessed, a request is issued to
retrieve the entire file, starting at the beginning. Consequently, Linearized PDF is
organized so that all the data required to display the first page is at the beginning
of the file. This includes all resources that are referenced from the first page, re-
gardless of whether they are also referenced from other pages.
The first page is usually but not necessarily page 0. If the document catalog con-
tains an OpenAction entry that specifies opening at some page other than page 0,
that page is the one physically located at the beginning of the document. Thus,
opening a document at the default place (rather than a specific destination) re-
quires simply waiting for the first-page data to arrive; no additional transactions
are required.
In an ordinary PDF viewer application, opening a document requires first posi-
tioning to the end to obtain the startxref line. Since a Linearized PDF file has the
first page’s cross-reference table at the beginning, reading the startxref line is not
necessary. All that is required is to verify that the file length given in the lineari-
zation parameter dictionary at the beginning of the file matches the actual length
of the file, indicating that no updates have been appended to the PDF file.
The primary hint stream is located either before or after the first-page section,
which means that it is also retrieved as part of the initial sequential read of the
file. The client is expected to interpret and retain all the information in the hint
1052
APPENDIX F
Linearized PDF
tables. The tables are reasonably compact and are not designed to be obtained
from the file in random pieces.
The client must now decide whether to continue reading the remainder of the
document sequentially or to abort the initial transaction and access subsequent
pages by using separate transactions requesting byte ranges. This decision is a
function of the size of the file, the data rate of the channel, and the overhead cost
of a transaction.
F.4.2
Opening at an Arbitrary Page
The viewer application may be requested to open a PDF file at an arbitrary page.
The page can be specified in one of three ways:
• By page number (remote go-to action, integer page specifier)
• By named destination (remote go-to action, name or string page specifier)
• By article thread (thread action)
Additionally, an indexed search results in opening a document by page number.
Handling this case efficiently is especially important.
As indicated above, when the document is initially opened, it is retrieved sequen-
tially starting at the beginning. As soon as the hint tables have been received, the
client has sufficient information to request retrieval of any page of the document
given its page number. Therefore, the client can abort the initial transaction and
issue a new transaction for the target page, as described in Section F.4.3, “Going
to Another Page of an Open Document.”
The position of the primary hint stream (part 5) with respect to the first-page
section (part 6) determines how quickly this can be done. If the primary hint
stream precedes the first-page section, the initial transaction can be aborted very
quickly; however, this is at the cost of increased delay when opening the docu-
ment at the first page. On the other hand, if the primary hint stream follows the
first-page section, displaying the first page is quicker (since the hint tables are not
needed for that), but opening at an arbitrary page is delayed by the time required
to receive the first page. The decision whether to favor opening at the first page or
opening at an arbitrary page must be made at the time a PDF file is linearized.
1053
SECTION F.4
Access Strategies
If an overflow hint stream exists, obtaining it requires issuing an additional trans-
action. For this reason, inclusion of an overflow hint stream in Linearized PDF,
although permitted, is not recommended. The feature exists to allow the lineariz-
er to write the PDF file with space reserved for a primary hint stream of an esti-
mated size and then go back and fill in the hint tables. If the estimate is too small,
the linearizer can append an overflow stream containing the remaining hint table
data. Thus, the PDF file can be written in one pass, which may be an advantage if
the performance of writing PDF is considered important.
Opening at a named destination requires the viewer application first to read the
entire Dests or Names dictionary, for which a hint is present. Using this informa-
tion, it is possible to determine the page containing the specific destination iden-
tified by the name.
Opening to an article requires the viewer application first to read the entire
Threads array, which is located with the document catalog at the beginning of the
document. Using this information, it is possible to determine the page containing
the first bead of any thread. Opening at other than the first bead of a thread re-
quires chaining through all the beads until the desired one is reached; there are
no hints to accelerate this.
F.4.3
Going to Another Page of an Open Document
Given a page number and the information in the hint tables, it is now straight-
forward for the client to construct a single request to retrieve any arbitrary page
of the document. The request should include the following items:
• The objects of the page itself, whose byte range can be determined from the
entry in the page offset hint table.
• The portion of the main cross-reference table referring to those objects. This
can be computed from main cross-reference table location (the T entry in the
linearization parameter dictionary) and the cumulative object number in the
page offset hint table.
• The shared objects referenced from the page, whose byte ranges can be deter-
mined from information in the shared object hint table.
• The portion or portions of the main cross-reference table referring to those ob-
jects, as described above.
1054
APPENDIX F
Linearized PDF
The purpose of the fractions in the page offset hint table is to enable the client to
schedule retrieval of the page in a way that allows incremental display of the data
as it arrives. It accomplishes this by constructing a request that interleaves pieces
of the page contents with the shared resources that the contents refer to. This
serves much the same purpose as the physical interleaving that is done for the
first page.
F.4.4
Drawing a Page Incrementally
The ordering of objects in pages and the organization of the hint tables are in-
tended to allow progressive update of the display and early opportunities for user
interaction when the data is arriving slowly. The viewer application must recog-
nize instances in which the targets of indirect object references have not yet
arrived and, where possible, rearrange the order in which it acts on the objects in
the page.
The following sequence of actions is recommended:
1. Activate the annotations, but do not draw them yet. Also activate the cursor
feedback for any article threads in the page.
2. Begin drawing the contents. Whenever there is a reference to an image
XObject that has not yet arrived, skip over it. Whenever there is a reference to
a font whose definition is an embedded font file that has not yet arrived, draw
the text using a substitute font (if that is possible).
3. Draw the annotations.
4. Draw the images as they arrive, together with anything that overlaps them.
5. Once the embedded font definitions have arrived, redraw the text using the
correct fonts, together with anything that overlaps the text.
The last two steps should be done using an off-screen buffer, if possible, to avoid
objectionable flashing during the redraw process.
On encountering a reference XObject (see Section 4.9.3, “Reference XObjects”),
the viewer application may choose to initially display the object as a proxy and
defer the retrieval and rendering of the imported content. Note that, since all
XObjects in a Linearized PDF file follow the content stream of the page on which
they appear, their retrieval is already deferred; the use of a reference XObject re-
sults in an additional level of deferral.
1055
SECTION F.4
Access Strategies
F.4.5
Following an Article Thread
As indicated earlier, the bead dictionaries for any article thread that visits a given
page are located with that page. This enables the bead rectangles to be activated
and proper cursor feedback to be shown.
If the user follows a thread, the viewer application can obtain the object number
from the N or P entry of the bead dictionary. This identifies a target bead, which
is located with the page to which it belongs. Given this object number, the viewer
application can go to that page, as discussed in Section F.4.3, “Going to Another
Page of an Open Document.”
F.4.6
Accessing an Updated File
As stated earlier, if a Linearized PDF file subsequently has an incremental update
appended to it, the linearization and hints are no longer valid. Actually, this is not
necessarily true, but the viewer application must do some additional work to val-
idate the information.
When the viewer application sees that the file is longer than the length given in
the linearization parameter dictionary, it must issue an additional transaction to
read everything that was appended. It must then analyze the objects in that up-
date to see whether any of them modify objects that are in the first page or that
are the targets of hints. If so, it must augment its internal data structures as neces-
sary to take the updates into account.
For a PDF file that has received only a small update, this approach may be worth-
while. Accessing the file this way is quicker than accessing it without hints or re-
trieving the entire file before displaying any of it.
1056
APPENDIX F
Linearized PDF
APPENDIX G
Example PDF Files
G
This appendix presents several examples showing the structure of actual PDF
files:
• A minimal file that can serve as a starting point for creating other PDF files
(and that is the basis of later examples)
• A simple example that shows a text string—the classic “Hello World”—and a
simple graphics example that draws lines and shapes
• A fragment of a PDF file that illustrates the structure of the page tree for a large
document and, similarly, two fragments that illustrate the structure of an out-
line hierarchy
• An example showing the structure of a PDF file as it is updated several times,
illustrating multiple body sections, cross-reference sections, and trailers
Note: The Length values of stream objects in the examples and the byte addresses in
cross-reference tables are not necessarily accurate.
G.1
Minimal PDF File
Example G.1 is a PDF file that does not draw anything; it is almost the minimum
acceptable PDF file. It is not strictly the minimum acceptable because it contains
an outline dictionary (Outlines in the document catalog) with a zero count (in
which case this object would normally be omitted); a page content stream
(Contents in the page object); and a resource dictionary (Resources in the page
object) containing a ProcSet array. These objects were included to make this file
useful as a starting point for creating other, more realistic PDF files.
Table G.1 lists the objects in this example.
1057
1058
APPENDIX G
Example PDF Files
TABLE G.1 Objects in minimal example
OBJECT NUMBER
OBJECT TYPE
1
Catalog (document catalog)
2
Outlines (outline dictionary)
3
Pages (page tree node)
4
Page (page object)
5
Content stream
6
Procedure set array
Note: When using Example G.1 as a starting point for creating other files, remem-
ber to update the ProcSet array as needed (see Section 10.1, “Procedure Sets”). Also,
remember that the cross-reference table entries may need to have a trailing space
(see Section 3.4.3, “Cross-Reference Table”).
Example G.1
%PDF−1. 4
1 0 obj
<< /Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
>>
endobj
2 0 obj
<< /Type Outlines
/Count 0
>>
endobj
3 0 obj
<< /Type /Pages
/Kids
[ 4 0 R ]
/Count 1
>>
endobj
1059
SECTION G.1
Minimal PDF File
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [ 0 0 612 792 ]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R >>
>>
endobj
5 0 obj
<< /Length 35 >>
stream
… Page-marking operators…
endstream
endobj
6 0 obj
[ /PDF ]
endobj
xref
0 7
0000000000 65535
f
0000000009 00000
n
0000000074 00000
n
0000000120 00000
n
0000000179 00000
n
0000000300 00000
n
0000000384 00000
n
trailer
<< /Size 7
/Root 1 0 R
>>
startxref
408
%%EOF
1060
APPENDIX G
Example PDF Files
G.2
Simple Text String Example
Example G.2 is the classic “Hello World” example built from the preceding exam-
ple. It shows a single line of text consisting of the string Hello World, illustrating
the use of fonts and several text-related PDF operators. The string is displayed in
24-point Helvetica. Because Helvetica is one of the standard 14 fonts, no font
descriptor is needed.
Table G.2 lists the objects in this example.
TABLE G.2 Objects in simple text string example
OBJECT NUMBER
OBJECT TYPE
1
Catalog (document catalog)
2
Outlines (outline dictionary)
3
Pages (page tree node)
4
Page (page object)
5
Content stream
6
Procedure set array
7
Font (Type 1 font)
Example G.2
%PDF−1. 4
1 0 obj
<< /Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
>>
endobj
2 0 obj
<< /Type /Outlines
/Count 0
>>
endobj
1061
SECTION G.2
Simple Text String Example
3 0 obj
<< /Type /Pages
/Kids
[ 4 0 R ]
/Count 1
>>
endobj
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [ 0 0 612 792 ]
/Contents 5 0 R
/Resources <<
/ProcSet 6 0 R
/Font
<< /F1 7 0 R >>
>>
>>
endobj
5 0 obj
<< /Length 73 >>
stream
BT
/F1 24 Tf
100 100 Td
( Hello World ) Tj
ET
endstream
endobj
6 0 obj
[ /PDF /Text ]
endobj
7 0 obj
<< /Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /MacRomanEncoding
>>
endobj
1062
APPENDIX G
Example PDF Files
xref
0 8
0000000000 65535 f
0000000009 00000 n
0000000074 00000 n
0000000120 00000 n
0000000179 00000 n
0000000364 00000 n
0000000466 00000 n
0000000496 00000 n
trailer
<< /Size 8
/Root 1 0 R
>>
startxref
625
%%EOF
G.3
Simple Graphics Example
Example G.3 draws a thin black line segment, a thick black dashed line segment, a
filled and stroked rectangle, and a filled and stroked cubic Bézier curve. Table G.3
lists the objects in this example, and Figure G.1 shows the resulting output. (Each
shape has a red border, and the rectangle is filled with light blue.)
TABLE G.3 Objects in simple graphics example
OBJECT NUMBER
OBJECT TYPE
1
Catalog (document catalog)
2
Outlines (outline dictionary)
3
Pages (page tree node)
4
Page (page object)
5
Content stream
6
Procedure set array
1063
SECTION G.3
Simple Graphics Example
FIGURE G.1
Output of Example G.3
Example G.3
%PDF−1. 4
1 0 obj
<< /Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
>>
endobj
2 0 obj
<< /Type /Outlines
/Count 0
>>
endobj
3 0 obj
<< /Type /Pages
/Kids
[ 4 0 R ]
/Count 1
>>
endobj
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [ 0 0
612
792 ]
/Contents 5 0 R
1064
APPENDIX G
Example PDF Files
/Resources << /ProcSet 6 0 R >>
>>
endobj
5 0 obj
<< /Length 883 >>
stream
% Draw a black line segment, using the default line width .
150 250 m
150 350 l
S
% Draw a thicker, dashed line segment .
4 w
% Set line width to 4 points
[ 4
6 ] 0 d
% Set dash pattern to 4 units on, 6 units off
150 250 m
400 250 l
S
[ ]
0 d
% Reset dash pattern to a solid line
1 w
% Reset line width to 1 unit
% Draw a rectangle with a 1−unit red border, filled with light blue .
1.0
0.0
0.0 RG
% Red for stroke color
0.5
0.75 1.0 rg
% Light blue for fill color
200 300 50 75 re
B
% Draw a curve filled with gray and with a colored border.
0.5
0.1
0.2 RG
0.7 g
300 300 m
300 400 400 400 400 300 c
b
endstream
endobj
6 0 obj
[ /PDF ]
endobj
xref
0 7
0000000000 65535 f
0000000009 00000 n
0000000074 00000 n
0000000120 00000 n
1065
SECTION G.4
Page Tree Example
0000000179 00000 n
0000000300 00000 n
0000001532 00000 n
trailer
<< /Size 7
/Root 1 0 R
>>
startxref
1556
%%EOF
G.4
Page Tree Example
Example G.4 is a fragment of a PDF file illustrating the structure of the page tree
for a large document. It contains the page tree nodes for a 62-page document.
Figure G.2 shows the structure of this page tree. Numbers in the figure are object
numbers corresponding to the objects in the example.
337
335
336
4
43
77
108
139
170
201
232
263
294
325
3
42
76
107
138
169
200
231
262
293
324
16
48
82
113
144
175
206
237
268
299
330
21
53
87
118
149
180
211
242
273
304
26
58
92
123
154
185
216
247
278
309
31
63
97
128
159
190
221
252
283
314
37
70
102
133
164
195
226
257
288
319
FIGURE G.2 Page tree for Example G.4
1066
APPENDIX G
Example PDF Files
Example G.4
337 0 obj
<< /Type /Pages
/Kids
[
335 0 R
336 0 R
]
/Count 62
>>
endobj
335 0 obj
<< /Type /Pages
/Parent 337 0 R
/Kids
[
4 0 R
43 0 R
77 0 R
108 0 R
139 0 R
170 0 R
]
/Count 36
>>
endobj
336 0 obj
<< /Type /Pages
/Parent 337 0 R
/Kids
[
201 0 R
232 0 R
263 0 R
294 0 R
325 0 R
]
/Count 26
>>
endobj
1067
SECTION G.4
Page Tree Example
4 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids
[
3 0 R
16 0 R
21 0 R
26 0 R
31 0 R
37 0 R
]
/Count 6
>>
endobj
43 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids
[
42 0 R
48 0 R
53 0 R
58 0 R
63 0 R
70 0 R
]
/Count 6
>>
endobj
77 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids
[
76 0 R
82 0 R
87 0 R
92 0 R
97 0 R
102 0 R
]
/Count 6
>>
endobj
1068
APPENDIX G
Example PDF Files
108 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids
[
107 0 R
113 0 R
118 0 R
123 0 R
128 0 R
133 0 R
]
/Count 6
>>
endobj
139 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids
[
138 0 R
144 0 R
149 0 R
154 0 R
159 0 R
164 0 R
]
/Count 6
>>
endobj
170 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids
[
169 0 R
175 0 R
180 0 R
185 0 R
190 0 R
195 0 R
]
/Count 6
>>
endobj
1069
SECTION G.4
Page Tree Example
201 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids
[
200 0 R
206 0 R
211 0 R
216 0 R
221 0 R
226 0 R
]
/Count 6
>>
endobj
232 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids
[
231 0 R
237 0 R
242 0 R
247 0 R
252 0 R
257 0 R
]
/Count 6
>>
endobj
263 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids
[
262 0 R
268 0 R
273 0 R
278 0 R
283 0 R
288 0 R
]
/Count 6
>>
endobj
1070
APPENDIX G
Example PDF Files
294 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids
[
293 0 R
299 0 R
304 0 R
309 0 R
314 0 R
319 0 R
]
/Count 6
>>
endobj
325 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids
[
324 0 R
330 0 R
]
/Count 2
>>
endobj
G.5
Outline Hierarchy Example
This section from a PDF file illustrates the structure of an outline hierarchy with
six items. Example G.5 shows the outline with all items open, as illustrated in
Figure G.3.
Object
On-screen appearance
Count
number
21
6
Document
22
4
Section 1
25
0
Section 2
26
1
Subsection 1
27
0
Section 3
28
0
Summary
29
0
FIGURE G.3 Document outline as displayed in Example G.5
1071
SECTION G.5
Outline Hierarchy Example
Example G.5
21 0 obj
<< /Type /Outlines
/First
22 0 R
/Last
29 0 R
/Count 6
>>
endobj
22 0 obj
<< /Title ( Document )
/Parent 21 0 R
/Next 29 0 R
/First
25 0 R
/Last
28 0 R
/Count 4
/Dest [ 3 0 R /XYZ 0 792 0 ]
>>
endobj
25 0 obj
<< /Title ( Section 1 )
/Parent 22 0 R
/Next 26 0 R
/Dest [ 3 0 R /XYZ null 701 null ]
>>
endobj
26 0 obj
<< /Title ( Section 2 )
/Parent 22 0 R
/Prev 25 0 R
/Next 28 0 R
/First
27 0 R
/Last
27 0 R
/Count 1
/Dest [ 3 0 R /XYZ null 680 null ]
>>
endobj
1072
APPENDIX G
Example PDF Files
27 0 obj
<< /Title ( Subsection 1 )
/Parent 26 0 R
/Dest [ 3 0 R /XYZ null 670 null ]
>>
endobj
28 0 obj
<< /Title ( Section 3 )
/Parent 22 0 R
/Prev 26 0 R
/Dest [ 7 0 R /XYZ null 500 null ]
>>
endobj
29 0 obj
<< /Title ( Summary )
/Parent 21 0 R
/Prev 22 0 R
/Dest [ 8 0 R /XYZ null 199 null ]
>>
endobj
Example G.6 is the same as Example G.5, except that one of the outline items has
been closed in the display. The outline appears as shown in Figure G.4.
Object
On-screen appearance
Count
number
21
5
Document
22
3
Section 1
25
0
Section 2
26
-1
Section 3
28
0
Summary
29
0
FIGURE G.4 Document outline as displayed in Example G.6
1073
SECTION G.5
Outline Hierarchy Example
Example G.6
21 0 obj
<< /Type /Outlines
/First
22 0 R
/Last
29 0 R
/Count 5
>>
endobj
22 0 obj
<< /Title ( Document )
/Parent 21 0 R
/Next 29 0 R
/First
25 0 R
/Last
28 0 R
/Count 3
/Dest [ 3 0 R /XYZ 0 792 0 ]
>>
endobj
25 0 obj
<< /Title ( Section 1 )
/Parent 22 0 R
/Next 26 0 R
/Dest [ 3 0 R /XYZ null 701 null ]
>>
endobj
26 0 obj
<< /Title ( Section 2 )
/Parent 22 0 R
/Prev 25 0 R
/Next 28 0 R
/First
27 0 R
/Last
27 0 R
/Count −1
/Dest [ 3 0 R /XYZ null 680 null ]
>>
endobj
1074
APPENDIX G
Example PDF Files
27 0 obj
<< /Title ( Subsection 1 )
/Parent 26 0 R
/Dest [ 3 0 R /XYZ null 670 null ]
>>
endobj
28 0 obj
<< /Title ( Section 3 )
/Parent 22 0 R
/Prev 26 0 R
/Dest [ 7 0 R /XYZ null 500 null ]
>>
endobj
29 0 obj
<< /Title ( Summary )
/Parent 21 0 R
/Prev 22 0 R
/Dest [ 8 0 R /XYZ null 199 null ]
>>
endobj
G.6
Updating Example
This example shows the structure of a PDF file as it is updated several times; it
illustrates multiple body sections, cross-reference sections, and trailers. In addi-
tion, it shows that once an object has been assigned an object identifier, it keeps
that identifier until the object is deleted, even if the object is altered. Finally, the
example illustrates the reuse of cross-reference entries for objects that have been
deleted, along with the incrementing of the generation number after an object has
been deleted.
The original file is the one shown in Example G.1 on page 1058. The updates are
divided into four stages, with the file saved after each stage:
1. Four text annotations are added.
2. The text of one of the annotations is altered.
3. Two of the text annotations are deleted.
4. Three text annotations are added.
1075
SECTION G.6
Updating Example
The sections following show the segments added to the file at each stage.
Throughout this example, objects are referred to by their object identifiers, which
are made up of the object number and the generation number, rather than simply
by their object numbers as in earlier examples. This is necessary because the ex-
ample reuses object numbers; therefore, the objects they denote are not unique.
Note: The tables in these sections show only those objects that are modified during
the updating process. Objects from Example G.1 that are not altered during the up-
date are not shown.
G.6.1
Stage 1: Add Four Text Annotations
Four text annotations are added to the initial file and the file is saved. Table G.4
lists the objects involved in this update.
TABLE G.4 Object usage after adding four text annotations
OBJECT IDENTIFIER
OBJECT TYPE
4 0
Page (page object)
7 0
Annotation array
8 0
Annot (annotation dictionary)
9 0
Annot (annotation dictionary)
10 0
Annot (annotation dictionary)
11 0
Annot (annotation dictionary)
Example G.7 shows the lines added to the file by this update. The page object is
updated because an Annots entry has been added to it. Note that the file’s trailer
now contains a Prev entry, which points to the original cross-reference section in
the file, while the startxref value at the end of the trailer points to the cross-
reference section added by the update.
1076
APPENDIX G
Example PDF Files
Example G.7
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [ 0 0 612 792 ]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R >>
/Annots 7 0 R
>>
endobj
7 0 obj
[
8 0 R
9 0 R
10 0 R
11 0 R
]
endobj
8 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 44 616 162 735 ]
/Contents ( Text #1 )
/Open true
>>
endobj
9 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 224 668 457 735 ]
/Contents ( Text #2 )
/Open false
>>
endobj
10 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 239 393 328 622 ]
/Contents ( Text #3 )
/Open true
>>
endobj
1077
SECTION G.6
Updating Example
11 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 34 398 225 575 ]
/Contents ( Text #4 )
/Open false
>>
endobj
xref
0 1
0000000000 65535
f
4 1
0000000632 00000
n
7 5
0000000810 00000
n
0000000883 00000
n
0000001024 00000
n
0000001167 00000
n
0000001309 00000
n
trailer
<< /Size 12
/Root 1 0 R
/Prev 408
>>
startxref
1452
%%EOF
G.6.2
Stage 2: Modify Text of One Annotation
One text annotation is modified and the file is saved. Example G.8 shows the lines
added to the file by this update. Note that the file now contains two copies of the
object with identifier 10 0 (the text annotation that was modified) and that the
added cross-reference section points to the more recent version of the object.
This added cross-reference section contains one subsection, which contains only
an entry for the object that was modified. In addition, the Prev entry in the file’s
trailer has been updated to point to the cross-reference section added in the pre-
vious stage, while the startxref value at the end of the trailer points to the newly
added cross-reference section.
1078
APPENDIX G
Example PDF Files
Example G.8
10 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 239 393 328 622 ]
/Contents ( Modified Text #3 )
/Open true
>>
endobj
xref
0 1
0000000000 65535 f
10 1
0000001703 00000 n
trailer
<< /Size 12
/Root 1 0 R
/Prev 1452
>>
startxref
1855
%%EOF
G.6.3
Stage 3: Delete Two Annotations
Two text annotation are deleted and the file is saved. Table G.5 lists the objects
updated.
TABLE G.5 Object usage after deleting two text annotations
OBJECT IDENTIFIER
OBJECT TYPE
7 0
Annotation array
8 0
Free
9 0
Free
The Annots array is the only object that is written in this update. It is updated be-
cause it now contains two annotations fewer.
1079
SECTION G.6
Updating Example
Example G.9 shows the lines added when the file was saved. Note that objects
with identifiers 8 0 and 9 0 have been deleted, as can be seen from the fact that
their entries in the cross-reference section end with the keyword f.
Example G.9
7 0 obj
[
10 0 R
11 0 R
]
endobj
xref
0 1
0000000008 65535
f
7 3
0000001978 00000
n
0000000009 00001
f
0000000000 00001
f
trailer
<< /Size 12
/Root 1 0 R
/Prev 1855
>>
startxref
2027
%%EOF
The cross-reference section added at this stage contains four entries, representing
object number 0, the Annots array, and the two deleted text annotations.
• The cross-reference entry for object number 0 is updated because it is the head
of the linked list of free entries and must now point to the entry for the newly
freed object number 8. The entry for object number 8 points to the entry for
object number 9 (the next free entry), while the entry for object number 9 is the
last free entry in the cross-reference table, indicated by the fact that it points
back to object number 0.
• The entries for the two deleted text annotations are marked as free and as
having generation numbers of 1, which are used for any objects that reuse these
cross-reference entries. Keep in mind that, although the two objects have been
deleted, they are still present in the file. It is the cross-reference table that
records the fact that they have been deleted.
1080
APPENDIX G
Example PDF Files
The Prev entry in the trailer has again been updated so that it points to the cross-
reference section added at the previous stage, and the startxref value points to the
newly added cross-reference section.
G.6.4
Stage 4: Add Three Annotations
Finally, three new text annotations are added to the file. Table G.6 lists the objects
involved in this update.
TABLE G.6 Object usage after adding three text annotations
OBJECT IDENTIFIER
OBJECT TYPE
7 0
Annotation array
8 1
Annot (annotation dictionary)
9 1
Annot (annotation dictionary)
12 0
Annot (annotation dictionary)
Object numbers 8 and 9, which were used for the two annotations deleted in the
previous stage, have been reused; however, the new objects have been given a
generation number of 1. In addition, the third text annotation added has been
assigned the previously unused object identifier of 12 0.
Example G.10 shows the lines added to the file by this update. The added cross-
reference section contains five entries, corresponding to object number 0, the
Annots array, and the three annotations added. The entry for object number 0 is
updated because the previously free entries for object numbers 8 and 9 have been
reused. The entry for object number 0 now shows that the cross-reference table
has no free entries. The Annots array is updated to reflect the addition of the
three text annotations.
Example G.10
7 0 obj
[
10 0 R
11 0 R
8 1 R
9 1 R
12 0 R
]
endobj
1081
SECTION G.6
Updating Example
8 1 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 58 657 172 742 ]
/Contents ( New Text #1 )
/Open true
>>
endobj
9 1 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 389 459 570 537 ]
/Contents ( New Text #2 )
/Open false
>>
endobj
12 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [ 44 253 473 337 ]
/Contents ( New Text #3\203a longer text annotation which we will continue \
onto a second line )
/Open true
>>
endobj
xref
0 1
0000000000 65535 f
7 3
0000002216 00000 n
0000002302 00001 n
0000002447 00001 n
12 1
0000002594 00000 n
trailer
<< /Size 13
/Root 1 0 R
/Prev 2027
>>
startxref
2814
%%EOF
1082
APPENDIX G
Example PDF Files
The annotation with object identifier 12 0 illustrates splitting a long text string
across multiple lines, as well as the technique for including nonstandard charac-
ters in a string. In this case, the character is an ellipsis (…), which is character
code 203 (octal) in PDFDocEncoding, the encoding used for text annotations.
As in previous updates, the trailer’s Prev entry and startxref value have been
updated.
G.7
Structured Elements That Describe Hierarchical Lists
This section presents examples that illustrate how structured elements are used to
described hierarchical lists, such as a table of contents or an index.
G.7.1
Table of Contents
The structured element’s structure type entry (S) can have values that establish
hierarchical relationships between entries in a table of content. The TOCI value
specifies an individual member of a table of contents. The TOC value specifies a
list made up of other table of contents items that are individual members of the
table of contents and/or lists of table of contents items. (The trailing character in
TOCI is an upper case “I”.)
Figure G.5 shows the table of contents described by Example G.11 on page 1084.
TABLE OF CONTENTS
1. Chapter One
3
1.1 Section A
4
1.2 Section B
5
2. Chapter Two
6
3. Chapter Three
7
3.1 Section A
8
FIGURE G.5 Table of contents
Большое спасибо!
Ваше мнение очень важно для нас.
Нет комментариевНе стесняйтесь поделиться с нами вашим ценным мнением.
Текст