Repository navigation
PDF Spec Annex G
Part of: PDF-Spec-Annexes
Navigation: PDF-Spec-Annex-F | PDF-Spec-Index | PDF-Spec-Annex-H
(informative)
As indicated above, when the document is initially opened, it is retrieved sequentially starting at the beginning. As soon as the hint tables have been received, the conforming reader has sufficient information to request retrieval of any page of the document given its page number. Therefore, the conforming reader can abort the initial transaction and issue a new transaction for the target page, as described in G.4, "Going to Another Page of an Open Document".
The position of the primary hint stream (part 5 in F.3.1, "General") with respect to the first-page section (part 6 in F.3.1, "General") 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 document 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 favour opening at the first page or opening at an arbitrary page must be made at the time a PDF file is linearized.
If an overflow hint stream exists, obtaining it requires issuing an additional transaction. For this reason, inclusion of an overflow hint stream in Linearized PDF, although permitted, is not recommended. The feature exists to allow the linearizer to write the PDF file with space reserved for a primary hint stream of an estimated 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 conforming reader first to read the entire Dests or Names dictionary, for which a hint is present. Using this information, it is possible to determine the page containing the specific destination identified by the name.
Opening to an article requires the conforming reader first to read the entire Threads array, which is located with the document catalogue 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 requires chaining through all the beads until the desired one is reached; there are no hints to accelerate this.
Given a page number and the information in the hint tables, it is now straightforward for the conforming reader 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 determined from information in the shared object hint table.
- The portion or portions of the main cross-reference table referring to those objects, as described above.
The purpose of the fractions in the page offset hint table is to enable the conforming reader 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.
The ordering of objects in pages and the organization of the hint tables are intended to allow progressive update of the display and early opportunities for user interaction when the data is arriving slowly. The conforming reader must recognize 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:
- a) Activate the annotations, but do not draw them yet. Also activate the cursor feedback for any article threads in the page.
- b) 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).
- c) Draw the annotations.
- d) Draw the images as they arrive, together with anything that overlaps them.
- e) 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 8.10.4, "Reference XObjects"), the conforming reader 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 results in an additional level of deferral.
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 conforming reader 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 conforming reader can go to that page, as discussed in G.4, "Going to Another Page of an Open Document."
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 conforming reader must do some additional work to validate the information.
When the conforming reader 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 analyse the objects in that update 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 necessary to take the updates into account.
For a PDF file that has received only a small update, this approach may be worthwhile. Accessing the file this way is quicker than accessing it without hints or retrieving the entire file before displaying any of it.
THIS PAGE BLANK
This annex 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 outline 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.
The example in H.2, "Minimal PDF File" 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 H.1 lists the objects in this example.
Table H.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 the example in H.2, "Minimal PDF File" as a starting point for creating other files, remember to update the ProcSet array as needed (see 14.2, "Procedure Sets"). Also, remember that the cross-reference table entries may need to have a trailing SPACE (see 7.5.4, "Cross-Reference Table").
Navigation: PDF-Spec-Annex-F | PDF-Spec-Index | PDF-Spec-Annex-H