APPENDIX F
1024
Linearized PDF
always reliable and may backfire if the transactions interfere with each other
by competing for scarce resources in the server or the communication chan-
nel.
Note:
Extensive experimentation has determined that having multiple concurrent
transactions does not work very well for PDF in some important environments.
Therefore, Linearized PDF is designed to enable good performance to be achieved
using only one transaction at a time. In particular, this means that the client must
have sufficient information to determine the byte ranges for all the objects re-
quired to display a given page of the PDF file so that it can specify all those byte
ranges in a single request.
The following additional assumptions are made about the PDF viewer application
and its local environment:
•
The viewer application has plenty of local temporary storage available. It
should rarely need to retrieve a given portion of a PDF document more than
once from the server.
•
The viewer application is able to display PDF data quickly once it has been
received. The performance bottleneck is assumed to be in the transport sys-
tem (throughput or round-trip delay), not in the processing of data after it ar-
rives.
The consequence of these assumptions is that it may be advantageous for the cli-
ent to do considerable extra work to minimize delays due to communications.
Such work includes maintaining local caches and reordering actions according to
when the needed data becomes available.
F.2 Linearized PDF Document Structure
Except as noted below, all elements of a Linearized PDF file are as specified in
sequentially in two groups, based on their order of appearance in the file.
•
The first group consists of the document catalog, certain other document-level
objects, and all objects belonging to the first page of the document. These ob-
jects are numbered sequentially, starting at the first object number after the last
number of the second group. (The stream containing the hint tables, called a