open/document-extraction
View Schema
This view of the annotation often reflects the precision of the extraction model or annotator, as well as the complexity of the document.
PDF 1.2 Reference Manual November 12, 1996 :
1
November 12, 1996
Tim Bienz, Richard Cohn, and James R. Meehan Adobe Systems Incorporated
Adobe Systems Incorporated
Portable Document Format
Reference Manual
Version 1.2
Page 2
: November 12, 1996
2 Adobe Systems Inc.
Copyright 1993, 1996. Adobe Systems Incorporated. All rights reserved. Patents Pending.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electr tronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of the publisher. Any software referred to herein is fu furnished under license and may only be used or copied in accordance with the terms of such license. Printed in the United States of America.
This publication and the information herein is furnished AS IS, is subject to change without notice, and should not be construe d as a commitment by Adobe Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or liability for any errors or inaccuracies, makes no warranty of any kind (express, implied or statutory) with respect to this publication, and expressly dis claims any and all warranties of merchantability, fitness for particular purposes and noninfringement of third party rights.
PostScript is a registered trademark of Adobe Systems Incorporated. All instances of the name PostScript in the text are refere nces to the PostScript language as defined by Adobe Systems Incorporated unless otherwise stated. The name PostScript also is used as a pro duct trademark for Adobe Systems’ implementation of the PostScript language interpreter.
Any references to a “PostScript printer,” a “PostScript file,” or a “PostScript driver” refer to printers, files, and driver pr ograms (respectively) which are written in or support the PostScript language. The sentences in this book that use “PostScript language” as an adject ive phrase are so constructed to reinforce that the name refers to the standard language definition as set forth by Adobe Systems Incorporated . Adobe, Acrobat, the Acrobat logo, Adobe Garamond, Adobe Illustrator , Carta, Distiller, FrameMaker, Minion, Photoshop, the Phot oshop logo, Poetica, PostScript, and the PostScript logo are registered trademarks of Adobe Systems Incorporated. TrueType and QuickD raw are trademarks and Apple, Macintosh, and Mac are registered trademarks of Apple Computer, Inc. ITC Stone and ITC Zapf Dingbats are registered trademarks of International Typeface Corporation. Helvetica and Times are registered trademarks of Linotype–Hell AG and/or its subsidiaries. Microsoft and Windows are registered trademarks of Microsoft Corporation. SelectSet is a trademark of Agfa Divisi on, Miles, Inc. Sun is a trademark of Sun Microsystems, Inc. SPARCstation is a registered trademark of SPARC International, Inc., licensed exclusively to Sun Microsystems, Inc. and is based upon an architecture developed by Sun Microsystems, Inc. NeXT is a trademark of NeXT Com puter, Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. All other brand or product names are the trademarks or registered trademarks of their respective holders.
Library of Congress Cataloging-in-Publication Data
Portable document format reference manual / Adobe Systems Incorporated. p. cm. Includes bibliographical references (p. 207) and index. ISBN 0–201–62628–4 1. File organization (Computer science) 2. PostScript (Computer program language) 3. Text processing (Computer science) I. Adobe Systems. QA76.9.F5P67 199393–8046 005.74—dc20CIP
1 2 3 4 5 6 7 8 9–MA–9796959493
Page 3
PDF 1.2 Reference Manual November 12, 1996 :
3
Contents
Chapter 1: Introduction 19
1.1 About this book 19
1.2 Introduction to the Second Edition—PDF 1.1 21
1.3 Introduction to the Third Edition—PDF 1.2 22
1.4 Conventions used in this book 22
1.5 A note on syntax 23
1.6 Copyrights and permissions to use PDF 24
Portable Document Format 27
Chapter 2: Overview 29
2.1 What is the Portable Document Format? 29
2.2 Using PDF 29
2.3 General properties 31
2.4 PDF and the PostScript language 35
2.5 Understanding PDF 36
Chapter 3: Coordinate Systems 37
3.1 Device space 37
3.2 User space 38
3.3 Text space 39
3.4 Character space 39
3.5 Image space 39
3.6 Form space 39
3.7 Pattern space 39
3.8 Relationships among coordinate systems 40
3.9 Transformations between coordinate systems 40
Page 4
: November 12, 1996
4 Adobe Systems Inc.
3.10 Transformation matrices 42
Chapter 4: Objects 45
4.1 Introduction 45
4.2 Booleans 45
4.3 Numbers 45
4.4 Strings 46
4.5 Names 48
4.6 Arrays 49
4.7 Dictionaries 49
4.8 Streams 50
4.9 The null object 62
4.10 Indirect objects 62
4.11 Object references 62
Chapter 5: File Structure 65
5.1 PDF files 65
5.2 Header 66
5.3 Body 66
5.4 Cross-reference table 67
5.5 Trailer 69
5.6 Incremental update 70
5.7 Encryption 72
Chapter 6: Document Structure 75
6.1 Introduction 75
6.2 Catalog 77
6.3 Pages tree 79
6.4 Page objects 81
6.5 Thumbnails 86
6.6 Annotations 87
6.7 Outline tree 96
6.8 Destinations 98
6.9 Actions 100
6.10 Name trees 111
Page 5
November 12, 1996
: 5
6.11 Info dictionary 114
6.12 Articles 115
6.13 File ID 117
6.14 Encryption dictionary 118
6.15 Acrobat Forms 122
6.16 Sounds 135
Chapter 7: Common Data Structures 137
7.1 Rectangle 137
7.2 File specification 137
7.3 Resource Dictionaries 141
7.4 ProcSets 143
7.5 Fonts 144
7.6 Font encodings 157
7.7 CMaps 158
7.8 Font descriptors 163
7.9 Color spaces 171
7.10 XObjects 178
7.11 Functions 187
7.12 Extended graphics states 191
7.13 Halftones 193
7.14 Patterns 203
7.15 Property lists 208
Chapter 8: Page Descriptions 211
8.1 Overview 211
8.2 Graphics state 213
8.3 Special Graphics State 214
8.4 General Graphics state 215
8.5 Color 220
8.6 Paths 223
8.7 Text state 229
8.8 External objects (XObjects) 238
8.9 In-line image objects 238
Page 6
: November 12, 1996
6 Adobe Systems Inc.
8.10 Other operators 241
Chapter 9: Linearized PDF 245
9.1 Introduction 245
9.2 Background and Assumptions 246
9.3 Linearized PDF document structure specification 248
9.4 Hint Tables 258
9.5 Access Strategies 264
Optimizing PDF Files 269
Chapter 10: General Techniques for Optimizing PDF Files 271
10.1 Use short names 271
10.2 Use direct and indirect objects appropriately 272
10.3 Take advantage of combined operators 273
10.4 Remove unnecessary clipping paths 273
10.5 Omit unnecessary spaces 274
10.6 Omit default values 274
10.7 Take advantage of forms 274
10.8 Limit the precision of real numbers 275
10.9 Write parameters only when they change 275
10.10 Don’t draw outside the crop box 275
10.11 Consider target device resolution 276
10.12 Share resources 276
10.13 Store common Page attributes in the Pages object 276
10.14 Use strings for named destinations 277
Chapter 11: Optimizing Text 279
11.1 Don’t produce unnecessary text objects 279
11.2 Use automatic leading 280
11.3 Take advantage of text spacing operators 282
11.4 Don’t replace spaces between words 283
11.5 Use the appropriate operator to draw text 283
11.6 Use the appropriate operator to position text 284
11.7 Remove text clipping 284
11.8 Consider target device resolution 286
Page 7
November 12, 1996
: 7
Chapter 12: Optimizing Graphics 287
12.1 Use the appropriate color-setting operator 287
12.2 Defer path painting until necessary 287
12.3 Take advantage of the closepath operator 288
12.4 Don’t close a path more than once 289
12.5 Don’t draw zero-length lines 290
12.6 Make sure drawing is needed 290
12.7 Take advantage of rectangle and curve operators 290
12.8 Coalesce operations 291
Chapter 13: Optimizing Images 293
13.1 Preprocess images 293
13.2 Match image resolution to target device resolution 293
13.3 Use the minimum number of bits per color component 293
13.4 Take advantage of indexed color spaces 294
13.5 Use the DeviceGray color space for monochrome images 294
13.6 Use in-line images appropriately 295
13.7 Don’t compress in-line images unnecessarily 295
13.8 Choose the appropriate filters 295
13.9 Use predefined spot functions 298
Chapter 14: Clipping and Blends 301
14.1 Clipping to a path 301
14.2 Clipping to text 303
14.3 Image masks 305
14.4 Blends 308
Appendix A: Example PDF Files 315
A.1 Minimal PDF file 315
A.2 Simple text string 317
A.3 Simple graphics 319
A.4 Pages tree 321
A.5 Outline 324
A.6 Updated file 327
Page 8
: November 12, 1996
8 Adobe Systems Inc.
Appendix B: Summary of Page Marking Operators 335
Appendix C: Predefined Font Encodings 339
C.1 Predefined encodings sorted by character name 340
C.2 Predefined encodings sorted by character code 345
C.3 MacExpert encoding 351
Appendix D: Implementation Limits 355
Appendix E: Obtaining XUIDs and Technical Notes 359
Appendix F: PDF Name Registry 361
Appendix G: Compatibility and Implementation Notes 363
G.1 Version numbers 363
G.2 Dictionary keys 364
G.3 Implementation notes 365
Appendix H: Forms Data Format 375
H.1 File Structure 375
H.2 The FDF Catalog Object 376
H.3 Use of FDF 378
H.4 Sample FDF 378
Appendix I: ISO 639 Language Codes 381
Appendix J: ISO 3166 Country Codes 385
Bibliography 391
Colophon 395
Page 9
PDF 1.2 Reference Manual November 12, 1996 :
9
Figures
Page 10
: November 12, 1996
10 Adobe Systems Inc.
Figure 2.1 Creating PDF files using PDF Writer 30 Figure 2.2 Creating PDF files using the Distiller program 31 Figure 2.3 Viewing and printing a PDF document 31 Figure 2.4 PDF components 36 Figure 3.1 Device space 38 Figure 3.2 User space 38 Figure 3.3 Relationships among PDF coordinate systems 40 Figure 3.4 Effects of coordinate transformations 41 Figure 3.5 Effect of the order of transformations 42 Figure 5.1 Structure of a PDF file that has not been updated 66 Figure 5.2 Structure of a PDF file after changes have been appended several times 72 Figure 6.1 Structure of a PDF document 76 Figure 6.2 Page object’s media box and crop box 83 Figure 7.1 Fonts, encodings, CMaps, and descriptors 146 Figure 7.2 Characteristics represented in the Flags field of a font descriptor 167 Figure 7.3 Color spaces 172 Figure 7.4 Mapping with the Decode array 192 Figure 7.5 Star Pattern 208 Figure 8.1 Graphics Objects 212 Figure 8.2 Flatness 215 Figure 8.3 Line cap styles 216 Figure 8.4 Line dash pattern 216 Figure 8.5 Line join styles 217 Figure 8.6 Miter length 218 Figure 8.7 Bézier curve 224 Figure 8.8 v operator 225 Figure 8.9 y operator 226 Figure 8.10 Non-zero winding number rule 227 Figure 8.11 Even–odd rule 227 Figure 8.12 Character spacing 230 Figure 8.13 Effect of word spacing 230 Figure 8.14 Horizontal scaling 231 Figure 8.15 Leading 231 Figure 8.16 Text rendering modes 232 Figure 8.17 Text rise 233 Figure 8.18 Operation of TJ operator 237 Figure 11.1 Restoring clipping path after clipping to text 286 Figure 13.1 Effect of JPEG encoding on a screenshot 296 Figure 13.2 Effect of JPEG encoding on a continuous-tone image 297 Figure 14.1 Clipping to a path 302 Figure 14.2 Using text as a clipping path 303 Figure 14.3 Images and image masks 306 Figure 14.4 Using an image to produce a linear blend 309 Figure 14.5 Using an image to produce a square blend 312 Figure A.1 Pages tree for 62-page document example 321 Figure A.2 Example of outline with six items, all open 324 Figure A.3 Example of outline with six items, five of which are open 326
Page 11
PDF 1.2 Reference Manual November 12, 1996 :
11
Tables
Page 12
: November 12, 1996
12 Adobe Systems Inc.
Table 4.1 Escape sequences in strings 46 Table 4.2 Stream attributes 51 Table 4.3 Standard filters 51 Table 4.4 Optional parameters for LZW filter 55 Table 4.5 Optional parameters for FlateDecode filter 57 Table 4.6 Predictor values 58 Table 4.7 Optional parameters for CCITTFaxDecode filter 60 Table 5.1 Trailer attributes 69 Table 6.1 Catalog attributes 78 Table 6.2 Viewer Preferences 79 Table 6.3 Pages attributes 80 Table 6.4 Page attributes 81 Table 6.5 Transition attributes 85 Table 6.6 Transition Effects 85 Table 6.7 Effect parameters 86 Table 6.8 Annotation attributes (common to all annotations) 88 Table 6.9 Border Style attributes 89 Table 6.10 Highlight Modes 90 Table 6.11 Appearance dictionary 91 Table 6.12 Text annotation attributes (in addition to those in Ta Tab le 6.8 ) 92 Table 6.13 Link annotation attributes (in addition to those in Ta Tab le 6.8 ) 93 Table 6.14 Movie Player annotation attributes (in addition to those in Ta Tab le 6.8 ) 93 Table 6.15 Movie dictionary attributes 94 Table 6.16 Movie Activation attributes 94 Table 6.17 Sound annotation attributes (in addition to those in Ta Tab le 6.8 ) 96 Table 6.18 Outlines attributes 96 Table 6.19 Outline entry attributes 97 Table 6.20 Destination specification 99 Table 6.21 Types of actions 100 Table 6.22 Action attributes (common to all actions) 101 Table 6.23 Additional Actions attributes 102 Table 6.24 GoTo action attributes (in addition to those in Ta Tab le 6.22 ) 103 Table 6.25 GoToR action attributes (in addition to those in Ta Tab le 6.22 ) 104 Table 6.26 Launch action attributes (in addition to those in Ta Tab le 6.22 ) 105 Table 6.27 Windows-specific launch attributes 105 Table 6.28 Thread action attributes (in addition to those in Ta Tab le 6.22 ) 106 Table 6.29 URI action attributes (in addition to those in Ta Tab le 6.22 ) 106 Table 6.30 URI attributes 108 Table 6.31 Sound action attributes (in addition to those in Ta Tab le 6.22 ) 108 Table 6.32 Movie Player attributes (in addition to those in Ta Tab le 6.16 ) 109 Table 6.33 SetState action attributes (in addition to those in Ta Tab le 6.22 ) 109 Table 6.34 Hide action attributes (in addition to those in Ta Tab le 6.22 ) 110 Table 6.35 Named Action Attributes (in addition to those in Ta Tab le 6.22 ) 110 Table 6.36 Named Action List 110 Table 6.37 NOP Action Attributes (in addition to those in Ta Tab le 6.22 ) 111 Table 6.38 Names dictionary in the Catalog 111 Table 6.39 The root node in a name tree 112 Table 6.40 An intermediate node in a name tree 112 Table 6.41 A leaf node in a name tree 112 Table 6.42 PDF Info dictionary attributes 114 Table 6.43 Thread attributes 115 Table 6.44 Bead attributes 116
Page 13
November 12, 1996
: 13
Table 6.45 Standard security handler attributes 118 Table 6.46 Permission flags 119 Table 6.47 AcroForm dictionary attributes 122 Table 6.48 Attributes common to all types of fields 123 Table 6.49 Attributes common to all types of fields containing variable text 125 Table 6.50 Field flags for Btn fields 127 Table 6.51 checkbox attributes 128 Table 6.52 Radio button attributes 129 Table 6.53 Choice attributes 130 Table 6.54 Field flags for choice fields 131 Table 6.55 Text field attributes 132 Table 6.56 SubmitForm action attributes (in addition to those in Ta Tab le 6.22 ) 133 Table 6.57 ResetForm action attributes (in addition to those in Ta Tab le 6.22 ) 134 Table 6.58 ImportData action attributes (in addition to those in Ta Tab le 6.22 ) 135 Table 6.59 Sound attributes 135 Table 7.1 Examples of file specifications 139 Table 7.2 File specification attributes 140 Table 7.3 Predefined procsets 143 Table 7.4 Attributes common to all types of fonts 144 Table 7.5 Type 1 font additional attributes 147 Table 7.6 Base 14 fonts 147 Table 7.7 Multiple master Type 1 font additional attributes 149 Table 7.8 Type 3 font additional attributes 150 Table 7.9 TrueType font attributes 151 Table 7.10 Type 0 font attributes 152 Table 7.11 Attributes common to all CID fonts 154 Table 7.12 CIDFontType 0 font attributes (in addition to those in Ta Tab le 7.11 ) 156 Table 7.13 CIDFontType 2 font attributes 156 Table 7.14 Font encoding attributes 157 Table 7.15 Predefined CJK CMap names 159 Table 7.16 CMap attributes 160 Table 7.17 Font descriptor attributes 163 Table 7.18 Additional attributes for FontFile stream 165 Table 7.19 Font flags 166 Table 7.20 Additional FontDescriptor attributes 168 Table 7.21 Character Subsets in CJK fonts 169 Table 7.22 CID font file 171 Table 7.23 CalGray attributes 173 Table 7.24 CalRGB attributes 174 Table 7.25 Lab attributes 175 Table 7.26 Image XObject attributes 178 Table 7.27 Default Decode arrays for various color spaces 180 Table 7.28 Color rendering intents 181 Table 7.29 Form XObject attributes 182 Table 7.30 PostScript XObject attributes 184 Table 7.31 OPI dictionary 185 Table 7.32 OPI 1.3 dictionary 185 Table 7.33 OPI 2.0 dictionary 186 Table 7.34 Function dictionary attributes shared by all functions 188 Table 7.35 Attributes of sampled functions (FunctionType 0) 189 Table 7.36 ExtGState attributes 191 Table 7.37 Entries in a Type 1 halftone dictionary 194
Page 14
: November 12, 1996
14 Adobe Systems Inc.
Table 7.38 Predefined spot functions 195 Table 7.39 Entries in a Type 5 halftone dictionary 200 Table 7.40 Type 6 halftone attributes 202 Table 7.41 Type 10 halftone attributes 203 Table 7.42 Pattern attributes 204 Table 7.43 Property List attributes 209 Table 8.1 Abbreviations for in-line image names 239 Table 9.1 Linearization parameters 251 Table 9.2 Standard Hint Tables 254 Table 9.3 Page Offset hint table, header section 259 Table 9.4 Page Offset hint table, per-page entry 259 Table 9.5 Shared Object hint table, header section 261 Table 9.6 Shared Object hint table, Shared Object Group entry 262 Table 9.7 Thumbnails hint table, header section 262 Table 9.8 Thumbnails hint table, per-page entry 263 Table 9.9 Generic Hint Table 264 Table 9.10 Forms hint table, continued 264 Table 10.1 Optimized operator combinations 273 Table 11.1 Comparison of text string operators 283 Table 11.2 Comparison of text positioning operators 284 Table 13.1 Comparison of compression filters for images 297 Table A.1 Objects in empty example 315 Table A.2 Objects in “Hello World” example 317 Table A.3 Objects in graphics example 319 Table A.4 Object use after adding four text annotations 328 Table A.5 Object use after deleting two text annotations 331 Table A.6 Object use after adding three text annotations 332 Table B.1 PDF page marking operators 335 Table D.1 Architectural limits 356 Table G.1 Acrobat 1.0 Viewer behavior with unknown filters 365 Table G.2 Acrobat 2.0 Viewer behavior with unknown filters 366 Table H.1 FDF attributes 376 Table H.2 Field attributes 377
Page 15
PDF 1.2 Reference Manual November 12, 1996 :
15
Examples
Example 4.1 Dictionary 49 Example 4.2 Dictionary within a dictionary 49 Example 4.3 Stream that has been LZW and ASCII85 encoded 52 Example 4.4 Unencoded stream 52 Example 4.1 Indirect reference 63 Example 5.1 Cross-reference section with a single subsection 68 Example 5.2 Cross-reference section with multiple subsections 69 Example 5.3 Trailer 70 Example 6.1 Catalog 77 Example 6.2 Pages tree for a document containing three pages 80 Example 6.3 Inheritance of attributes 81 Example 6.4 Page with thumbnail, annotations, and Resources dictionary 83 Example 6.5 A page with information for presentation mode 86 Example 6.6 Thumbnail 87 Example 6.7 Text annotation 92 Example 6.8 Link annotation 93 Example 6.9 Outlines object with six open entries 97 Example 6.10 Outline entry 98 Example 6.11 GoTo action 104 Example 6.1 Info dictionary 115 Example 6.2 Thread 116 Example 6.3 Simple checkbox field 128 Example 6.4 Radio button field with two buttons 129 Example 6.5 List box field 131 Example 6.6 Text field 132 Example 7.1 URLs 141 Example 7.2 Resources dictionary 143 Example 7.1 Type 1 font and character widths array 147 Example 7.2 Multiple master font and character widths array 149 Example 7.3 Type 3 font 151 Example 7.4 TrueType font 152 Example 7.5 Type 0 font referring to a single CID font 153 Example 7.6 Font encoding 158 Example 7.7 CMap Encoding 161 Example 7.8 Embedded Type 1 font definition 165 Example 7.1 Font descriptor 167 Example 7.2 FD entry 170 Example 7.3 Indexed color space 176 Example 7.4 Image with length specified as an indirect object 179 Example 7.1 Form XObject 183
Page 16
: November 12, 1996
16 Adobe Systems Inc.
Example 7.2 Example of a spot function 190 Example 7.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ExtGStates 192 Example 7.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Half tone with spot-function dictionary 200 Example 7.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Half tone dictionary for type 5 200 Example 7.6 Bitmap pattern 205 Example 7.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Star pattern 206 Example 8.1 In-line image 240 Example 9.1 Outline of a linearized PDF file 249 Example 11.1 Changing the text matrix inside a text object 279 Example 11.2 Multiple lines of text without automatic leading 280 Example 11.3 Multiple lines of text using automatic leading 280 Example 11.4 TJ operator without automatic leading 281 Example 11.5 Use of the T* operator 281 Example 11.6 Using the TL operator to set leading 281 Example 11.7 Using the TD operator to set leading 282 Example 11.8 Character and word spacing using the Tc and Tw operators 282 Example 11.9 Character and word spacing using the " operator 283 Example 11.1 Restoring clipping path after using text as clipping path 285 Example 12.1 Each path segment as a separate path 288 Example 12.2 Grouping path segments into a single path 288 Example 12.3 Using redundant l and h operators to close a path inefficiently 288 Example 12.4 Using the l operator to close a path inefficiently 289 Example 12.5 Taking advantage of the h operator to close a path 289 Example 12.6 Improperly closing a path: multiple path closing operators 289 Example 12.7 Properly closing a path: single path closing operator 290 Example 12.8 Portion of a path before coalescing operations 291 Example 12.9 Portion of a path after coalescing operations 291 Example 14.1 Clipping to a path 302 Example 14.2 Using text as a clipping path 304 Example 14.3 Images and image masks 306 Example 14.4 Using images as blends 309 Example 14.5 Image used to produce a grayscale square blend 312 Example A.1 Minimal PDF file 316 Example A.2 PDF file for simple text example 317 Example A.3 PDF file for simple graphics example 319 Example A.4 Pages tree for a document containing 62 pages 321 Example A.5 Six entry outline, all items open 324 Example A.6 Six entry outline, five entries open 326 Example A.7 Update section of PDF file when four text annotations are added 328 Example A.8 Update section of PDF file when one text annotation is modified 330 Example A.9 Update section of PDF file when two text annotations are deleted 331 Example A.10 Update section of PDF file after three text annotations are added 332
Page 17
PDF 1.2 Reference Manual November 12, 1996 1: Introduction
19
CHAPTER 1
Introduction
This book describes the Portable Document Format (PDF), the native file format of the Adobe ® Acrobat ® family of products. The goal of these products is to enable users to easily and reliably exchange and view electronic documents independent of the environment in which they were created. PDF relies on the imaging model of the PostScript ® language to describe text and graphics in a device- and resolution-independent manner. To improve performance for interactive viewing, PDF defines a more structured format than that used by most PostScript language programs. PDF also includes objects, such as annotations and hypertext links, that are not part of the page itself but are useful for interactive viewing.
PDF files are built from a sequence of numbered objects similar to those used in the PostScript language. The text, graphics, and images that make up the contents of a page are represented using operators that are based on those in the PostScript language and that closely follow the Adobe Illustrator ® 3.0 page description operators.
A PDF file is not a PostScript language program and cannot be directly interpreted by a PostScript interpreter. However, the page descriptions in a PDF file can be converted into a PostScript language program.
1.1 About this book
This book provides a description of the PDF file format, as well as suggestions for producing efficient PDF files. It is intended primarily for application developers who wish to produce PDF files directly. This book also contains enough information to allow developers to write applications that read and modify PDF files. While PDF is independent of any particular application, occasionally PDF features are best explained by the actions a particular application takes when it encounters that feature in a file. Similarly, A ppendix D discusses some implementation limits in the Acrobat viewer applications, even though these limits are not part of the file format itself.
This book consists of two sections. The first section describes the file format and the second lists techniques for producing efficient PDF files. In addition, appendices provide example files, detailed descriptions of several predefined font encodings, and a summary of PDF page marking operators.
Page 18
1: Introduction November 12, 1996
20 Adobe Systems Inc.
Readers are assumed to have some knowledge of the PostScript language, as described in the PostScript Language Reference Manual, Second Edition [1] . In addition, some understanding of fonts, as described in the Adobe Type 1 Font Format [6] , is useful.
The first section of this book, Portable Document Format, includes Chapters 2 through 7 and describes the PDF file format.
Cha pter 2 describes the motivation for creating the PDF file format and provides an overview of its architecture. PDF is compared to the PostScript language.
Cha pter 3 discusses the coordinate systems and transformations used in PDF files. Because the coordinate systems used in PDF are very much like those used in the PostScript language, users with substantial background in the PostScript language may wish to read this chapter only as a review.
Cha pter 4 describes the types of objects used to construct documents in PDF files. These types are similar to those used in the PostScript language. Readers familiar with the types of objects present in the PostScript language may wish to read this chapter quickly as a reminder.
Cha pter 5 provides a description of the format of PDF files, how they are organized on disk, and the mechanism by which updates can be appended to a PDF file.
Cha pter 6 describes the way that a document is represented in a PDF file, using the object types presented in Cha pter 4 .
Cha pter 7 defines the resources used in a PDF file, including fonts, color spaces, images, and others.
Cha pter 8 discusses the page marking operators used in PDF files. These are the operators that actually make marks on a page. Many are similar to one or more PostScript language operators. Readers with PostScript language experience will quickly see the similarities.
The second section of this book, Optimizing PDF Files, includes Chapters 10 through 14 and describes techniques for producing efficient PDF files. Many of the techniques presented can also be used in the PostScript language. The techniques are broken down into four areas: text, graphics, images, and general techniques.
Cha pter 10 discusses general optimizations that may be used in a wide variety of situations in PDF files.
Cha pter 11 discusses optimizations for text.
Cha pter 12 discusses graphics optimizations.
Cha pter 13 discusses optimizations that may be used on sampled images.
Finally, Cha pter 14 contains techniques for using clipping paths to restrict the region in which drawing occurs and a technique using images to make efficient blends.
Page 19
November 12, 1996
1: Introduction 21
1.2 Introduction to the Second Edition—PDF 1.1
The second edition of this manual is a revision of the 1993 edition of Portable Document Format Reference Manual . It describes version 1.1 of the Portable Document Format.
The PDF specification is independent of any particular implementation of a PDF generator or consumer. To provide guidance to implementors, however, Implementation Notes that accompany the specification and A ppendix G describe the behavior of Acrobat viewers (versions 1.0, 2.0, and 2.1) when they encounter the changes documented herein.
Implementation note PDF 1.1 is the native file format of the Adobe Acrobat 2.0 family of products.
The PDF 1.1 specification, like the PDF 1.0 specification, defines a minimum interchange level of functionality. The Portable Document Format is an extensible format, which means that PDF files may contain objects not defined by this specification. Consumers , applications that read PDF files and interpret their contents, are expected to implement correctly the semantics of objects that are specified by PDF 1.1 and, as gracefully as possible, to ignore any objects that they do not understand. A ppendix G provides guidance on how a consumer should handle objects it does not understand.
Implementation note Some Acrobat 2.0 and subsequent products provide an interface that supports plug-ins. These plug-ins can use and/or put private data objects within a PDF file. Appendix G indicates the kinds of private data that can be used and Appendix F defines a registry for this data. The registry can be used to avoid conflicts in identifying data from independent plug-ins.
New features introduced in PDF 1.1 include the following:
• The ability to protect a document with a password and to restrict operations on a document.
• The ability to tie blocks of text together into “articles,” making reading easier.
• The generalization of link and bookmark destinations to “actions,” which include links to other PDF files and foreign files.
• The ability to define new annotation types and to provide additional attributes for existing types.
• The ability to specify default settings and actions when a document is opened.
• Device-independent color.
• An ID included in files to make it easier to verify that a file is the correct file, even under circumstances where the file’s name is incorrect (such as files on some networks).
• A binary option that allows files to be smaller.
• A new date format that allows programmatic comparison of dates.
Page 20
1: Introduction November 12, 1996
22 Adobe Systems Inc.
• The ability to provide additional document information.
Note In PDF 1.1, dictionary key names are often one or two letters in order to conserve space in files. When these keys are described below, they are followed in parentheses by a more descriptive string. However, only the actual one- or twoletter name may be used in a PDF file.
1.3 Introduction to the Third Edition—PDF 1.2
This document is a revision of the March 1, 1996, edition of Portable Document Format Reference Manual . It describes version 1.2 of the Portable Document Format.
Implementation note PDF 1.2 is the native file format of the Adobe Acrobat 3.0 family of products.
New features introduced in PDF 1.2 include the following:
• Interactive elements with state, such as radio buttons and checkboxes.
• Support for playing movies (from external files) and sounds (either embedded in the PDF file or from external files).
• Interactive, fill-in forms, with PDF-based format for data that can be imported, exported, transmitted, and received from the Web.
• Support for Chinese, Korean, and Japanese text.
• Enhanced borders, highlights, and fully general appearances for annotations.
• Support for responding to mouse-events.
• Essentially unlimited number of hypertext links.
• Support for OPI (Open Prepress Interface).
• Advanced color features, such as halftone screens, transfer functions, patterns, and separation color spaces.
Note PDF is an evolving language, and new editions of this manual will be offered on an ongoing basis to document the changes. The most recent version will be available on the Adobe’s Web site.
While many readers will use a printed copy of this manual, others will refer to it online. With that in mind, many changes have been made to the formatting, such as the choice and size of fonts, to make on-screen reading somewhat easier.
1.4 Conventions used in this book
Text styles are used to identify various operators, keywords, terms, and objects. Five formatting styles are used in this book:
Page 21
November 12, 1996
1: Introduction 23
• PostScript language operators, PDF operators, PDF keywords, the names of keys in dictionaries, and other predefined names are written in boldface. Examples are moveto , Tf , stream , Type , and MacRomanEncoding .
• Operands of PDF operators are written in an italic sans serif font. An example is linewidth. h.
• Object types are written with initial capital letters. An example is FontDescriptor.
• The first occurrence of terms and the boolean values true and false are written in italics. This style is also used for emphasis.
• Samples of code as it would appear in a PDF file are written in a monospaced font. An example is /MediaBox [0 0 612 792] .
Tables containing dictionary keys are normally organized with the Type and Subtype keys first, followed by any other keys that are required in the dictionary, followed by any optional keys.
Important changes and corrections to the previous edition of this manual are marked with change bars in the left margin. Most of the changes are related to the differences between versions of PDF. Those changes are marked with icons in the right margin:
This marks a section that specifically deals with version 1.0, normally indicating a feature that has been superseded in a later version.
This marks a section that specifically deals with new features in version 1.1.
This marks a section that specifically deals with new features in version 1.2.
Generally, new features and attributes are ignored by older viewers. An attribute marked with a version icon may be new with that version, or may have been substantially redefined in that version.
1.5 A note on syntax
Throughout this book, Backus–Naur form (BNF) notation is used to describe syntax:
<xyz> ::= abc <def> ghi | <k> j
A token enclosed in angle brackets names a class of document component, while plain text appears verbatim or with some obvious substitution. The grammar rules have two parts. The name of a class of component is on the left of the definition
PDF 1.0
PDF 1.1
PDF 1.2
Page 22
1: Introduction November 12, 1996
24 Adobe Systems Inc.
symbol ( ::= ). In the example above, the class is xyz . On the right of the definition symbol is a set of one or more alternative forms that the class component might take in the document. A vertical bar ( | ) separates alternative forms.
The right side of the definition may be on one or more lines. With only a few exceptions, these lines do not correspond to lines in the file.
The notation { ... } means that the items enclosed in braces are optional. If an asterisk follows the braces, the objects inside the braces may be repeated zero or more times. The notation < ... >+ means that the items enclosed within the brackets must be repeated one or more times.
When an operator appears in a BNF specification, it is shorthand for the operator plus its operands. For example, when the operator m appears in a BNF specification, it means x y m , where x and y are numbers.
Note that PDF is case-sensitive. Uppercase and lowercase letters are distinct.
1.6 Copyrights and permissions to use PDF
The general idea of utilizing an interchange format for final-form documents is in the public domain. Anyone is free to devise his or her own set of unique commands and data structures that define an interchange format for final-form documents. Adobe owns the copyright in the data structures, operators, and the written specification for the particular interchange format called the Portable Document Format. These elements may not be copied without Adobe’s permission.
Adobe will enforce its copyright. Adobe’s intention is to maintain the integrity of the Portable Document Format as a standard. This enables the public to distinguish between the Portable Document Format and other interchange formats for finalform documents.
However, Adobe desires to promote the use of the Portable Document Format for information interchange among diverse products and applications. Accordingly, Adobe gives permission to anyone to:
• Prepare files in which the file content conforms to the Portable Document Format.
• Write drivers and applications that produce output represented in the Portable Document Format.
• Write software that accepts input in the form of the Portable Document Format and displays the results, prints the results, or otherwise interprets a file represented in the Portable Document Format.
• Copy Adobe’s copyrighted list of operators and data structures, as well as the PDF sample code and PostScript language Function definitions in the written specification, to the extent necessary to use the Portable Document Format for the above purposes.
Page 23
November 12, 1996
1: Introduction 25
The only condition on such permission is that anyone who uses the copyrighted list of operators and data structures in this way must include an appropriate copyright notice.
This limited right to use the copyrighted list of operators and data structures does not include the right to copy the Portable Document Format Reference Manual , other copyrighted material from Adobe, or the software in any of Adobe’s products which use the Portable Document Format, in whole or in part.
Page 24
1: Introduction November 12, 1996
26 Adobe Systems Inc.
Page 25
PDF 1.2 Reference Manual November 12, 1996 :
27
Section I
Portable Document Format
Page 26
: November 12, 1996
28 Adobe Systems Inc.
Page 27
PDF 1.2 Reference Manual November 12, 1996 2: Overview
29
CHAPTER 2
Overview
Before examining the detailed structure of a PDF file, it is important to understand what PDF is and how it relates to the PostScript language. This chapter discusses PDF and its relationship to the PostScript language.
Cha pter 3 discusses the coordinate systems used to describe various components of a PDF file. Chapters 4 and 5 discuss the basic types of objects supported by PDF and the structure of a PDF file. Chapters 6 and 8 describe the structure of a PDF document and the operators used to draw text, graphics, and images.
2.1 What is the Portable Document Format?
PDF is a file format used to represent a document in a manner independent of the application software, hardware, and operating system used to create it. A PDF file contains a PDF document and other supporting data.
A PDF document contains one or more pages. Each page in the document may contain any combination of text, graphics, and images in a device- and resolutionindependent format. This is the page description . A PDF document may also contain information possible only in an electronic representation, such as hypertext links.
In addition to a document, a PDF file contains the version of the PDF specification used in the file and information about the location of important structures in the file.
2.2 Using PDF
To understand PDF, it is important to understand how PDF documents will be produced and used. As PDF documents and applications that read PDF files become more prevalent, new ways of creating and using PDF files will be invented. This is one of the goals of this book—to make the file format accessible so that application developers can expand on the ideas behind PDF and the applications that initially support it.
Currently, PDF files may be produced either directly from applications or from files containing PostScript page descriptions.
Page 28
2: Overview November 12, 1996
30 Adobe Systems Inc.
Macintosh
PDF W application
PDF Writer
QuickDraw
Windows
r application
GDI
PDF
Acrobat Exchange or Reader
on a Macintosh or Windows c
liilf
Many applications can produce PDF files directly. The PDF Writer, available on both Apple ® Macintosh ® computers and computers running the Microsoft ® Windows ® environment, acts as a printer driver. A printer driver normally converts operating system graphics and text commands (QuickDraw™ for the Macintosh and GDI for Windows) into commands understood by a printer. The driver embeds these commands in a stream of commands sent to a printer that results in a page being printed. Instead of sending these commands to a printer, the PDF Writer converts them to PDF operators and embeds them in a PDF file, as shown in F igur e 2.1 .
Figure 2.1 Creating PDF files using PDF Writer
The resulting PDF files are platform-independent. Regardless of whether they Acrobat Exchange or Reader
were generated on a Macintosh or Windows computer, they may be viewed by a g
PDF viewing application on any platform.
Some applications produce PostScript page descriptions directly because of limitations in the QuickDraw or GDI imaging models or because they run on DOS or UNIX ® computers, where there is no system-level printer driver. For these applications, PostScript page descriptions can be converted into PDF files using the Acrobat Distiller ® application, as shown in F igur e 2.2 . The Distiller application accepts any PostScript page description, whether created by a program or hand-coded by a human. The Distiller application produces more efficient PDF files than PDF Writer for some application programs.
Macintosh application
cintoshW
PDF Writer
QuickDraw
Windows application
GDI
PDF
Acrobat Exchange or Reader
Page 29
November 12, 1996 2.3.1
2: Overview 31
Figure 2.2 Creating PDF files using the Distiller program
Once a PDF file has been created, Acrobat Exchange™ or Acrobat Reader can be used to view and print the document contained in the file, as shown in F igur e 2.3 . Users can navigate through the document using thumbnail sketches, hypertext links, and bookmarks. The document’s text may be searched and extracted for use in other applications. In addition, an Acrobat Exchange user may modify a PDF document by creating text annotations, hypertext links, thumbnail sketches of each page, and bookmarks that directly access views of specific pages.
Figure 2.3 Viewing and printing a PDF document
2.3 General properties
Given the goals and intended use of PDF, its design has several notable properties. This section describes those properties.
2.3.1 PostScript language imaging model
PDF represents text and graphics using the imaging model of the PostScript language. Like a PostScript language program, a PDF page description draws a page by placing “paint” on selected areas.
Acrobat Distiller
PostScript page description
PDF
Acrobat Exchange or Reader
PostScript printer
PostScript program
Other printer
Printer commands
PDF
Acrobat Exchange or Reader
PDF
Page 30
2: Overview November 12, 1996
32 Adobe Systems Inc.
• The painted figures may be letter shapes, regions defined by combinations of lines and curves, or sampled images such as digitally sampled representations of photographs.
• The paint may be any color.
• Any figure can be clipped to another shape, so that only portions of the figure within the shape appear on the page.
• When a page description begins, the page is completely blank. Various operators in the page description place marks on the page. Each new mark completely obscures any marks it may overlay.
The PDF page marking operators are similar to the marking operators in the PostScript language. The main reason that the PDF marking operators differ from the PostScript language marking operators is that PDF is not a programming language and does not contain procedures, variables, or control constructs. PDF trades reduced flexibility for improved efficiency. A typical PostScript language program defines a set of high-level operators using the PostScript language marking operators. PDF defines its own set of high-level operators that is sufficient for describing most pages. Because these operators are implemented directly in machine code rather than PostScript language code, PDF page descriptions can be drawn more quickly. Because arbitrary programming constructs are not permitted, applications can more efficiently and reliably locate text strings in a PDF document.
2.3.2 Portability
A PDF file is either a 7-bit ASCII file or a binary file. If it is a 7-bit ASCII file, only the printable subset of the 7-bit ASCII code plus space, tab, carriage return, and linefeed are used. If it is a binary file, the entire 8-bit range of characters may be used.
ASCII is the most portable form, since it is the only form that will fit through channels that are not 8-bit clean or are subject to end-of-line translation, etc. A binary file simply cannot be transported in such cases.
Unfortunately, some agents, when presented with information labelled as “text,” take unreasonable liberties with the contents. For example, mail transmission systems may not preserve certain 7-bit characters and may change line endings. This can cause damage to PDF files.
Therefore, in situations where it is possible to label PDF files as “binary,” we recommend that this be done. One method for encouraging such treatment is to include a few binary characters (codes greater than 127) in a comment near the beginning of the file, as described in Section 5.1 on pa g e 65 , even if the rest of the file is ASCII . This ensures that a PDF file will be treated as binary when this is possible, while still allowing it to be transferred through a non-binary channel without damage.
Implementation note Acrobat applications produce PDF files with a comment that includes binary characters.
PDF 1.1
Page 31
November 12, 1996 2.3.3
2: Overview 33
2.3.3 Compression
To reduce file size, PDF supports a number of industry-standard compression filters:
• JPEG compression of color and grayscale images
• CCITT Group 3, CCITT Group 4, LZW (Lempel-Ziv-Welch), and Run Length compression of monochrome images
• LZW and Flate compression of text, graphics, and indexed image data.
Using JPEG compression, color and grayscale images can be compressed by a factor of 10 or more. Effective compression of monochrome images depends upon the compression filter used and the properties of the image, but reductions of 2:1 to 8:1 are common. LZW compression of text and graphics comprising the balance of the document results in compression ratios of approximately 2:1. All of these compression filters produce binary data, which may then be encoded in the ASCII base-85 encoding to maintain portability.
2.3.4 Font independence
Managing fonts is a fundamental challenge in document exchange. Generally, the receiver of a document must have the same fonts the sender used to create the document. Otherwise, a default font is substituted, producing unexpected and undesirable effects because the default font has different character metrics (widths) than the intended font. The sender could include the fonts with the document, but this can easily make even a short document quite large—a typical two-page memo using four fonts might grow from 10K to 250K. Another possibility is that the sender could convert each page of the document to a fixed-resolution image like a facsimile. Even when compressed, however, the image of a single page can be quite large (45–60K when sampled at 200 dpi). In addition, there is no intelligence left in the file, preventing the receiver from searching for or extracting text from the document.
PDF provides a new solution that makes a document independent of the fonts used to create it. A PDF file contains a font descriptor for each font used in a document. The font descriptor includes the font name, character metrics, and style information. This is the information needed to simulate missing fonts and is typically only 1–2K per font.
If a font used in a document is available on the computer where the document is viewed, it is used. If it is not available, a multiple master font is used to simulate on a character-by-character basis the weight and width of the original font, to maintain the overall “color” and formatting of the document. This solution applies to both Adobe Type 1 fonts and fonts in the TrueType™ format [20] developed by Apple Computer, Inc.
S ymbolic fonts must be handled in a special way. A symbolic font is any font that does not use the standard ISOLatin1 character set. Fonts such as Carta ® , Adobe Caslon Swash Italic, Minion™ Ornaments, and Lucida ® Math fall into this category. It is not possible to simulate a symbolic font effectively.
PDF 1.2
Page 32
2: Overview November 12, 1996
34 Adobe Systems Inc.
For symbolic fonts, a font descriptor (including metrics and style information) is not sufficient; the actual character shapes (or glyphs) are required to accurately display and print the document. For all symbolic fonts other than Symbol and ITC Zapf Dingbats ® , a compressed version of the Type 1 font program for the font is included in the PDF file. Symbol and ITC Zapf Dingbats, the most widely used symbolic fonts, ship with Acrobat Exchange and Acrobat Reader and do not need to be included in a PDF file.
2.3.5 Single-pass file generation
Because of system limitations and efficiency considerations, it may be desirable or necessary for an implementation of a program that produces PDF such as the PDF Writer to create a PDF file in a single pass. This may be, for example, because the application has access to limited memory or is unable to open temporary files. For this reason, PDF supports single-pass generation of files. While PDF requires certain objects to contain a number specifying their length in bytes, a mechanism is provided allowing the length to be located in the file after the object. In addition, information such as the number of pages in the document can be written into the file after all pages have been written into the file.
2.3.6 Random access
Tools that extract and display a selected page from a PostScript language program must scan the program from its beginning until the desired page is found. On average, the time needed to view a page depends not only on the complexity of the page but also on the total number of pages in the document. This is problematic for interactive document viewing, where it is important that the time needed to view a page be independent of the total number of pages in the document.
Every PDF file contains a cross-reference table that can be used to locate and directly access pages and other important objects in the file. The location of the cross-reference table is stored at the end of the file, allowing applications that produce PDF files in a single pass to store it easily and allowing applications that read PDF files to locate it easily. Using the cross-reference table, the time needed to view a page in a PDF file can be nearly independent of the total number of pages in the document.
2.3.7 Incremental update
Applications may allow users to modify PDF documents, which can contain hundreds of pages or more. Users should not have to wait for the entire file to be rewritten each time modifications to the document are saved. PDF allows modifications to be appended to a file, leaving the original data intact. The addendum appended when a file is incrementally updated contains only the objects that were modified or added, and includes an update to the cross-reference table. Support for incremental update allows an application to save modifications to a PDF document in an amount of time proportional to the size of the modification instead of the size of the file. In addition, because the original contents of the file are still present in the file, it is possible to undo saved changes by deleting one or more addenda.
Page 33
November 12, 1996 2.3.8
2: Overview 35
2.3.8 Extensibility
PDF is designed to be extensible. Undoubtedly, developers will want to add features to PDF that have not yet been implemented or thought of.
The design of PDF is such that not only can new features be added, but applications that understand earlier versions of the format will not completely break when they encounter features that they do not implement. A ppendix G , “ Compa tibility and Implementa tion Notes ,” specifies how a viewer should behave when it reads a file that does not conform to the specification it was expecting.
2.4 PDF and the PostScript language
The preceding sections mentioned several ways in which PDF differs from the PostScript language. This section summarizes these differences and describes the process of converting a PDF file into a PostScript language program.
While PDF and the PostScript language share the same basic imaging model, there are some important differences between them:
• A PDF file may contain objects such as hypertext links that are useful only for interactive viewing.
• To simplify the processing of page descriptions, PDF provides no programming language constructs.
• PDF enforces a strictly defined file structure that allows an application to access parts of a document randomly.
• PDF files contain information such as font metrics, to ensure viewing fidelity.
Because of these differences, a PDF file cannot be downloaded directly to a PostScript printer for printing. An application that prints a PDF file to a PostScript printer must carry out the following steps:
1. Insert procsets , sets of PostScript language procedure definitions that implement the PDF page description operators.
2. Extract the content for each page. Pages are not necessarily stored in sequential order in the PDF file. Each page description is essentially the script portion of a traditional PostScript language program using very specific procedures, such as “m” for moveto and “l” for lineto .
3. Decode compressed text, graphics, and image data. This is not required for PostScript Level 2 printers, which can accept compressed data in a PostScript language file.
4. Insert any resources, such as fonts, into the PostScript language file. Substitute fonts are defined and inserted as needed, based on the font metrics in the PDF file.
Page 34
2: Overview November 12, 1996
36 Adobe Systems Inc.
5. Put the information in the correct order. The result is a traditional PostScript language program that fully represents the visual aspects of the document, but no longer contains PDF elements such as hypertext links, annotations, and bookmarks.
6. Send the PostScript language program to the printer.
2.5 Understanding PDF
PDF is best understood by thinking of it in four parts, as shown in F igur e 2.4 .
Figure 2.4 PDF components
The first component is the set of basic object types used by PDF to represent objects. These types, with only a few exceptions, correspond to the data types used in the PostScript language. Cha pter 4 discusses these object types.
The second component is the PDF file structure. The file structure determines how objects are stored in a PDF file, how they are accessed, and how they are updated. This structure is independent of the semantics of the objects. Cha pter 5 explains the file structure.
The third component is the PDF document structure. The document structure specifies how the basic object types are used to represent components of a PDF document: pages, annotations, hypertext links, fonts, and more. Cha pter 6 explains the PDF document structure.
The fourth and final component is the PDF page description. A PDF page description, while part of a PDF page object, can be explained independently of the other components. A PDF page description has only limited interaction with other parts of a PDF document. This simplifies its conversion into a PostScript language program. Cha pter 8 discusses PDF page descriptions.
Objects
File structure Document structure
Page description
Page 35
PDF 1.2 Reference Manual November 12, 1996 3: Coordinate Systems
37
CHAPTER 3
Coordinate Systems
Coordinate systems define the canvas on which all drawing in a PDF document occurs; that is, the position, orientation, and size of the text, graphics, and images that appear on a page are determined by coordinate systems.
PDF supports a number of coordinate systems, most of them identical to those used in the PostScript language. This chapter describes each of the coordinate systems used in PDF, how they are related, and how transformations among coordinate systems are specified. At the end of the chapter is a description of the mathematics involved in coordinate transformations. It is not necessary to read this section to use coordinate systems and transformations. It is presented for those readers who wish to gain a deeper understanding of the mechanics of coordinate transformations.
3.1 Device space
The contents of a page ultimately appear on a display or a printer. Each type of device on which a PDF page can be drawn has its own built-in coordinate system, and, in general, each type of device has a different coordinate system. Coordinates specified in a device’s native coordinate system are said to be in device space . On pixel-based devices such as computer screens and laser printers, coordinates in device space generally specify a particular pixel.
If coordinates in PDF files were specified in device space, the files would be device-dependent and would accordingly appear differently on different devices. For example, images drawn in the typical device space of a 72 pixel per inch display and on a 600 dpi printer differ in size by more than a factor of 8; an eightinch line segment on a display would appear as a one-inch segment on the printer. Different devices also have different orientations of their coordinate systems. On one device, the origin of the coordinate system may be at the upper left corner of the page, with the positive direction of the y -axis pointing downward. On another device, the origin may be in the lower left corner of the page with the positive direction of the y -axis pointing upward. F igur e 3.1 shows an object that is two units high in device space, and illustrates the fact that coordinates specified in device space are device-dependent.
Page 36
3: Coordinate Systems November 12, 1996
38 Adobe Systems Inc.
Figure 3.1 Device space
3.2 User space
PDF, like the PostScript language, defines a coordinate system that appears the same, regardless of the device on which output occurs. This allows PDF documents to be independent of the resolution of the output device. This resolution-independent coordinate system is called user space and provides the overall coordinate system for a page.
The transformation from user space to device space is specified by the current transformation matrix (CTM). F igur e 3.2 shows an object that is two units high in user space and indicates that the CTM provides the resolution-independence of the user space coordinate system.
Figure 3.2 User space
Device space for 72-dpi screen
Device space for 300-dpi printer
User space
Device space for 72-dpi screen
Device space for 300-dpi printer
CTM
Page 37
November 12, 1996
3: Coordinate Systems 39
The user space coordinate system is initialized to a default state for each page of a document. By default, user space coordinates have 72 units per inch, corresponding roughly to the various definitions of the typographic unit of measurement known as the point . The positive direction of the y -axis points upward, and the positive direction of the x -axis to the right. The region of the default coordinate system that is viewed or printed can be different for each page, and is described on pa g e 81 .
3.3 Text space
The coordinates of text are specified in text space . The transformation from text space to user space is provided by a matrix called the text matrix .
3.4 Character space
Characters in a font are defined in character space . The transformation from character space to text space is defined by a matrix. For most types of fonts, this matrix is predefined except for an overall scale factor. (For details, see pa g e 229 .) This scale factor changes when a user selects the font size for text.
3.5 Image space
All images are defined in image space . The transformation from image space to user space is predefined and cannot be changed. All images are one unit by one unit in user space, regardless of the number of samples in the image.
3.6 Form space
PDF provides an object known as a Form , discussed on pa g e 122 . Forms contain sequences of operations and are the same as forms in the PostScript language. The space in which a form is defined is form space . The transformation from form space to user space is specified by a matrix contained in the form.
3.7 Pattern space
PDF defines a type of color known as a pattern , discussed on pa g e 203 . Like forms, patterns contain sequences of marking operations; they are the same as patterns in the PostScript language. The space in which a pattern is defined is pattern space . The transformation from pattern space to user space is specified by a matrix contained in the pattern.
PDF 1.2
Page 38
3: Coordinate Systems November 12, 1996
40 Adobe Systems Inc.
3.8 Relationships among coordinate systems
PDF defines a number of interrelated coordinate systems, described in the previous sections. F igur e 3.3 shows the relationships among the coordinate systems. Each line in the figure represents a transformation from one coordinate system to another. PDF allows modifications to many of these transformations.
Figure 3.3 Relationships among PDF coordinate systems
Because PDF coordinate systems are defined relative to each other, changes made to one transformation can affect the appearance of objects drawn in several coordinate systems. For example, changes made to the CTM affect the appearance of all objects, not just graphics drawn directly in user space.
3.9 Transformations between coordinate systems
Transformation matrices specify the relationship between two coordinate systems. By modifying a transformation matrix, objects can be scaled, rotated, translated, or transformed in other ways.
A transformation matrix in PDF, as in the PostScript language, is specified by six numbers, usually in the form of an array containing six elements. This section lists the arrays that specify the most common transformations. The following section contains more mathematical details of transformations, including information on specifying transformations that are combinations of those listed in this section.
• Translations are specified as [1 0 0 1 tx tx ty ty ], where tx tx and ty ty are the distances to translate the origin of the coordinate system in x and y , respectively.
• Scaling is obtained by [ s x 0 0 s y 0 0]. This scales the coordinates so that one unit in the x and y directions of the new coordinate system is the same size as s x and s y units in the previous coordinate system, respectively.
• Rotations are carried out by [cos θ sin θ -sin θ cos θ 0 0], which has the effect of rotating the coordinate system axes by an angle θ counterclockwise.
User space
Device space
Form space
Character space
Text space
Image space
Pattern space
Page 39
November 12, 1996
3: Coordinate Systems 41
• Skew is specified by [1 tan α tan β 1 0 0], which skews the x -axis by an angle α and the y -axis by an angle β .
F igur e 3.4 shows examples of each transformation. The directions of translation, rotation, and skew shown in the figure correspond to positive values of the array elements.
Figure 3.4 Effects of coordinate transformations
Translation Scaling
Rotation Skewing
If several transformations are applied, the order in which they are applied generally is important. For example, scaling the x -axis followed by a translation of the x -axis is not the same as first translating the x -axis, then performing the scaling. In general, to obtain the expected results, transformations should be done in the order: translate, rotate, scale/skew.
F igur e 3.5 shows that the order in which transformations are applied is important. The figure shows two sequences of transformations applied to a coordinate system. After each successive transformation, an outline of the letter “n” is drawn. The transformations in the figure are a translation of 10 units in the x -direction and 20 units in the y -direction, a rotation of 30 degrees, and a scaling by a factor of 3 in the x -direction. In the figure, the axes are drawn with a dash-pattern having two units dash, two units gap. In addition, the untransformed coordinate system is drawn in a lighter color in each section. Notice that the scale–rotate–translate ordering results in a distortion of the coordinate system leaving the x - and y -axes no longer perpendicular, while the recommended translate–rotate–scale ordering does not.
t y
t x
s y
s x
θ
β
α
Page 40
3: Coordinate Systems November 12, 1996
42 Adobe Systems Inc.
Figure 3.5 Effect of the order of transformations
3.10 Transformation matrices
This section describes the mathematics of transformation matrices, which is identical to that underlying the PostScript language. It is not necessary to read this section to use the transformations discussed in previous sections.
To understand coordinate system transformations in PDF, it is vital to understand two points:
• Transformations in PDF alter coordinate systems, not objects. All objects drawn before a transformation is specified are unchanged by the transformation. Objects drawn after the transformation is specified will be drawn in the transformed coordinate system.
• Transformation matrices in PDF specify the transformation from the transformed (new) coordinate system to the untransformed (old) coordinate system. All coordinates used after the transformation are specified in the transformed coordinate system. PDF applies the transformation matrix to determine the coordinates in the untransformed coordinate system.
Note Many computer graphics textbooks consider transformations of objects instead of coordinate systems. Although these are formally equivalent, some results differ depending on which point of view is taken.
Original Step 1: Translate Step 2: Rotate Step 3: Scale
Original Step 1: Scale Step 2: Rotate Step 3: Translate
Page 41
November 12, 1996
3: Coordinate Systems 43
PDF represents coordinates in a two-dimensional space. The point (x, y) in such a space can be expressed in vector form as [ x y 1]. Although the third element of this vector (1) is not strictly necessary, it provides a convenient way to specify translations of the coordinate system’s origin.
The transformation between two coordinate systems is represented by a 3 × 3 transformation matrix written as:
Note Because a transformation matrix has only six entries that may be changed, for convenience it is often written as the six-element array [a b c d e f].
Coordinate transformations are expressed as:
Because PDF transformation matrices specify the conversion from the transformed coordinate system to the original (untransformed) coordinate system, x ′ and y ′ in this equation are the coordinates in the untransformed coordinate system, while x and y are the coordinates in the transformed system. Carrying out the multiplication, we have:
If a series of transformations is carried out, the transformation matrices representing each of the transformations can be multiplied together to produce a single equivalent transformation matrix.
Matrix multiplication is not commutative—the order in which matrices are multiplied is significant. It is not a priori obvious in which order the transformation matrices should be multiplied. Matrices representing later transformations could either be multiplied before those representing earlier transformations (premultiplied) or after (postmultiplied).
To determine whether premultiplication or postmultiplication is appropriate, consider a sequence of two transformations. Specifically, apply a scaling transformation to the user space coordinate system, and consider the conversion from this scaled coordinate system to device space. The two transformation matrices in this example are the matrix specifying the scaling ( MS MS ) and the matrix specifying the transformation from user space to device space (the CTM, called MC MC here). Recalling that coordinates are always specified in the transformed space, it is clear that the correct order of transformations must first convert the scaled coordinates to those in default user space, and then convert the default user space coordinates to device space coordinates. This can be expressed:
ab 0 cd 0 ef 1
x ′ y ′ 1 xy 1
ab 0 cd 0 ef 1
=
x ′ = ax cy e ++ cy ++
y ′ = bx dy f ++ dy ++
Page 42
3: Coordinate Systems November 12, 1996
44 Adobe Systems Inc.
where X D is the coordinate in device space and X U is the coordinate in default user space. This shows that when a new transformation is added, the matrix representing it must be premultiplied onto the existing transformation matrix.
This result is true in general for PDF—when a sequence of transformations is carried out, the matrix representing the combined transformation ( M ′) ′) is calculated by premultiplying the matrix representing the transformation being added ( MT MT ) onto the matrix representing any existing transformations ( M) M):
X D X U M C X S M S XSMS () M C X S M S M C XUMC XSMS ()MC == = MSMC ()
M ′ = M T M
Page 43
PDF 1.2 Reference Manual November 12, 1996 4: Objects
45
CHAPTER 4
Objects
The object types supported by PDF are similar to the object types supported by the PostScript language. Readers familiar with the PostScript language may wish to skim this chapter, or skip parts of it, particularly Sections 4.2, “Booleans ,” through 4.7, “Dictionar ies .”
4.1 Introduction
PDF supports seven basic types of objects: Booleans, numbers, strings, names, arrays, dictionaries, and streams. In addition, PDF provides a null object. Objects may be labeled so that they can be referred to by other objects. A labeled object is called an indirect object .
The following sections describe each object type and the null object. A discussion of creating and referring to indirect objects in PDF files follows.
Note PDF is case-sensitive. Uppercase and lowercase letters are different.
4.2 Booleans
The keywords true and false represent Boolean objects with values true and false .
4.3 Numbers
PDF provides two types of numbers, integer and real. Integers may be specified by signed or unsigned constants. Reals may only be in decimal format. Throughout this book, number means an object whose type is either integer or real.
Note Exponential format for numbers (such as 1.0E3) is not supported.
Page 44
4: Objects November 12, 1996
46 Adobe Systems Inc.
4.4 Strings
A string is a sequence of characters delimited by parentheses. If a string is too long to be conveniently placed on a single line, it may be split across multiple lines by using the backslash (\) character at the end of a line to indicate that the string continues on the following line. When this occurs, the backslash and end-of-line characters are not considered part of the string. Examples of strings are:
( This is string number 1? ) ( strangeonium spectroscopy ) (This string is split \ across \ three lines)
Within a string, the backslash character is used as an escape to specify unbalanced parentheses, non-printing ASCII characters, and the backslash character itself. This escape mechanism is the same as for PostScript language strings, described in Section 3.2.2 of the PostScript Language Reference Manual, Second Edition . Ta Ta b le 4.1 lists the escape sequences for PDF.
Table 4.1 Escape sequences in strings
\n linefeed
\r carriage return
\t horizontal tab
\b backspace
\f formfeed
\\ backslash
\( left parenthesis
\) right parenthesis
\ ddd character code ddd (octal)
Use of the \ ddd escape sequence is the preferred way to represent characters outside the printable ASCII character set, in order to minimize potential problems transmitting or storing the characters. The number ddd may contain one, two, or three octal digits. An example of a string with an octal character in it is:
(string with \245two octal characters\307)
As in the PostScript language, strings may also be represented in hexadecimal form. A hexadecimal string consists of a sequence of hexadecimal characters (the digits 0–9 and the letters A–F or a–f) enclosed within angle brackets (< and >). Each pair of hexadecimal digits defines one character of the string. If the final digit of a given string is missing—in other words, if there is an odd number of digits— the final digit is assumed to be zero. Whitespace characters (space, tab, carriage return, linefeed, and formfeed) are ignored. For example,
Page 45
November 12, 1996 4.4.1
4: Objects 47
<901fa3>
is a three-character string consisting of the characters whose hexadecimal codes are 90, 1f, and a3. But:
<901fa>
is a three-character string containing the characters whose hexadecimal codes are 90, 1f, and a0.
In versions 1.1 and later, it is not necessary to represent strings using only the printable 7-bit ASCII character set. A non-printable ASCII code—in fact, any 8-bit value—may appear in a string. In particular, when a document is encrypted (see pa g e 72 ), all its strings are encrypted and often contain arbitrary 8-bit values. Note that the backslash character is still required as an escape to specify unbalanced parentheses and the backslash character itself.
Informational or content strings can be represented in Unicode. These strings include text annotations, bookmark names, article names, document information, date strings, etc. In PDF 1.1 these strings are stored in PDFDocEncoding , which is a superset of ISOLatin1. PDFDocEncoding is compatible with Unicode in that all Unicode codes less than 256 match PDFDocEncoding .
Strings can be stored in either PDFDocEncoding or Unicode. If they are in Unicode, the first two bytes of the string must be the Unicode Byte Order marker, <FE FF>. This sequence collides with the character sequence thorn ydieresis , which is not likely to be a meaningful beginning of a word or phrase. The highorder byte of a Unicode character appears first in a string.
The string may also contain an escape sequence to indicate the language of the string. This is useful when the language cannot be determined from the character codes used in the string. The escape sequence uses the Unicode hex value U+001B followed by the two ASCII codes for the language identifiers defined by ISO 639 (see A ppendix I ), optionally followed by the two ASCII codes for country defined by IS0 3166 (see A ppendix J ), followed by U+001B.
Strings can be used for many purposes and can be formatted in different ways. When a string is used for a specific purpose, to represent a date, for example, it is useful to have a standard format for that purpose. Such formats are conventions for interpreting strings and are not types themselves. The use of a particular format is indicated with the definition of the string object that uses the format.
4.4.1 Date strings
PDF defines a standard date format. The PDF date format closely follows the format defined by the international standard ASN.1 (Abstract Syntax Notation One, defined in CCITT X.208 or ISO/IEC 8824). A date is a string of the form:
(D: YYYYMMDDHHmmSSOHH ' mm ')
where
PDF 1.1
PDF 1.2
PDF 1.1
Page 46
4: Objects November 12, 1996
48 Adobe Systems Inc.
• YYYY is the year.
• MM is the month (01–12).
• DD is the day (01–31).
• HH is the hour (00–23).
• mm are the minutes (00-59).
• SS are the seconds (00-59).
• O is the relation of local time to GMT, where + indicates that local time is later than GMT, - indicates that local time is earlier than GMT, and Z indicates that local time is GMT.
• HH is the absolute value of the offset from GMT in hours. The quote ( ' ) is part of the syntax.
• mm is the absolute value of the offset from GMT in minutes. The quote ( ' ) is part of the syntax.
Example:
D:199512231952-08'00'
The D: prefix permits arbitrary keys to be recognized as dates. However, it is not required. Trailing fields other than the year are also optional. The default value for day and month is 1; all other numerical fields default to 0. If no GMT information is specified, the relationship of the specified time to GMT is considered unknown. Whether the time zone is known or not, the rest of the date should be specified in local time.
4.5 Names
A name, like a string, is a sequence of characters. It must begin with a slash followed by a sequence of ASCII characters in the range ! (<21>) through ~ (<7E>) except %, (, ), <, >, [, ], {, }, /, and #. Examples of names are:
/Name1 /ASomewhatLongerName2 /A;Name_With-various***Characters?. /1.2 /.notdef
Any character except null (<00>) may be included in a name by writing its twocharacter hex code, preceded by # . Examples:
/Adobe#20Green /PANTONE#205757#20CV /paired#28#29parentheses
PDF 1.2
Page 47
November 12, 1996 4.4.1
4: Objects 49
/TheKeyOfF#23Minor /A#42
Note that /A#42 is another way of writing the name /AB .
Note PDF 1.1 allowed # as part of a name; this change is incompatible. PDF 1.1 did not exclude the use of blanks in names, although that was not permitted by the Acrobat implementation. There was no “escape character” in PDF 1.1.
Note The maximum number of characters in a name is 127. This limit refers to the internal representation of the name. For example, the name /A#20B has four characters (/, A, space, and B), not six.
4.6 Arrays
An array is a sequence of PDF objects. An array may contain a mixture of object types. An array is written as a left square bracket ( [ ), followed by a sequence of objects, followed by a right square bracket ( ] ). An example of an array is:
[0 (Higgs) false 3.14 3 549 /SomeName]
4.7 Dictionaries
A dictionary is an associative table containing pairs of objects. The first element of each pair is called the key and the second element is called the value . Unlike dictionaries in the PostScript language, a key must be a name. A value can be any kind of object, including a dictionary. A dictionary is generally used to collect and tie together the attributes of a complex object, with each key–value pair specifying the name and value of an attribute.
A dictionary is represented by two left angle brackets ( << ), followed by a sequence of key–value pairs, followed by two right angle brackets ( >> ). For example:
Example 4.1 Dictionary
<< /Type /Example /Key2 12 /Key3 (a string) >>
Example 4.2 Dictionary within a dictionary
<< /Type /AlsoAnExample /Subtype /Bad /Reason (unsure) /Version 0.01 /MyInfo << /Item1 0.4 /Item2 true
Page 48
4: Objects November 12, 1996
50 Adobe Systems Inc.
/LastItem (not!) /VeryLastItem (OK) >> >>
Dictionary objects are the main building blocks of a PDF document. Many parts of a PDF document, such as pages and fonts, are represented using dictionaries. By convention, the Type key of such a dictionary specifies the type of object being described by the dictionary. Its value is always a name. In some cases, the Subtype key is used to describe a specialization of a particular type. Its value is always a name. For a font, Type is Font and several subtypes exist, including Type1 , MMType1 , Type3 , TrueType , and others.
4.8 Streams
A stream, like a string, is a sequence of characters. However, an application can read a small portion of a stream at a time, while a string must be read in its entirety. For this reason, objects with potentially large amounts of data, such as images and page descriptions, are represented as streams.
A stream consists of a dictionary that describes a sequence of characters, followed by the keyword stream , followed by zero or more lines of characters, followed by the keyword endstream .
<stream> ::= <dictionary> stream { <lines of characters> }* endstream
All streams must be indirect objects (see pa g e 62 ). The stream dictionary must be a direct object. The keyword stream that follows the stream dictionary should be followed by a carriage return and linefeed or just a linefeed.
Note Without this restriction, it is not possible to differentiate a stream that uses carriage return as end of line and whose first byte of data is a linefeed from a stream that uses carriage return-linefeed pairs as end of line.
The sequence of characters that make up a stream may be found between the stream and endstream keywords or, in PDF 1.2, may be contained in an external file. If the data is in an external file, the stream dictionary specifies the file. When a stream’s data is external, the characters between stream and endstream are ignored.
Ta Ta b le 4.2 shows the attributes of a stream.
PDF 1.1
PDF 1.2
Page 49
November 12, 1996 4.4.1
4: Objects 51
Table 4.2 Stream attributes
Key Type Description
Length integer (Required) Number of characters from the first line after the line containing the stream keyword to the endstream keyword.
Filter name or array of names (Optional) Filters to be applied in processing the stream. The value of the Filter key can be either the name of a single decode filter or an array of decode filter names. Specify multiple filters in the order they should be applied to decode the data. For example, data encoded using LZW and ASCII base-85 filters (inthat order) can be decoded by providing the following key and value in the stream dictionary:
/Filter [/ASCII85Decode /LZWDecode]
DecodeParms various (Optional) Parameters used by the decoding filters specified with the Filter key. The number and types of the parameters supplied must match those needed by the specified filters. For example, if two filters are used, the decode parameters must be specified by an array of two objects, one corresponding to each filter. Use the null object for a filter’s entry in the DecodeParms array if that filter does not need any parameters. If none of the filters specified requires any parameters, omit the DecodeParms key.
F (File) F ile specifi ca tion (Optional) The file containing the stream data. If this key is present, the characters between stream and endstream are ignored. However, the Length key should still specify the number of those characters. (Usually there are no characters and the Length is zero.) FFilter name or array of names (Optional) Filters to be applied in processing the data found in the stream’s external file. The same rules apply as for the Filter key.
FDecodeParms variable (Optional) Parameters used by the decoding filters specified with the FFilter key.
Streams may be filtered to compress them or convert binary streams into ASCII form. The standard PostScript Level 2 software decoding filters are supported. These filters and their parameters are listed in Ta Ta b le 4.3 and described in the following sections.
Table 4.3 Standard filters
Filter name Parameters Semantics
ASCIIHexDecode none Decodes binary data in an ASCII hexadecimal representation
ASCII85Decode none Decodes binary data in an ASCII base-85 representation
PDF 1.2
PDF 1.2
PDF 1.2
Page 50
4: Objects November 12, 1996
52 Adobe Systems Inc.
LZWDecode dictionary (Parameters optional) Decompresses text or binary data using LZW adaptive compression method
RunLengthDecode none Decompresses binary data using a byte-oriented run-length decoding algorithm
CCITTFaxDecode dictionary (Parameters optional) Decompresses binary data using a bit-oriented decoding algorithm, the CCITT facsimile standard
DCTDecode dictionary (Parameters optional) Decompresses sampled image data using a discrete cosine transform technique based on the JPEG standard
FlateDecode dictionary (Parameters optional) Decompresses text or binary data using the Flate decompression method.
Example 4.3 shows a stream that has been compressed using LZW and then encoded using ASCII85, while Example 4.4 shows the same stream without any encoding.
Example 4.3 Stream that has been LZW and ASCII85 encoded
<< /Length 528 /Filter [/ASCII85Decode /LZWDecode] >> stream J..)6T`?p&<!J9%_[umg"B7/Z7KNXbN'S+,*Q/ &"OLT'FLIDK#!n`$"<Atdi`\Vn%b%)&'cA*VnK\CJY(sF>c!Jnl@R M]WM;jjH6Gnc75idkL5]+cPZKEBPWdR>FF(kj1_R%W_d&/ jS!;iuad7h?[LF$+]]0A3Ck*$I0KZ?;<)CJtqi65XbVc3\n5ua:Q/ =0$W<#N3U;H,MQKqfg1?:lUpR;6oN[C2E4ZNr8Udn.'p+?#X+1>0K uk$bCDF/ (3fL5]Oq)^kJZ!C2H1'TO]Rl?Q:&'<5&iP!$Rq;BXRecDN[IJB`,) o8XJOSJ9sDS]hQ;Rj@!ND)bD_q&C\g:inYC%)&u#:u,M6Bm%IY!Kb 1+":aAa'S`ViJglLb8<W9k6Yl\\0McJQkDeLWdPN?9A'jX*al>iG1 p&i;eVoK&juJHs9%;Xomop"5KatWRT"JQ#qYuL,JD?M$0QP)lKn06 l1apKDC@\qJ4B!!(5m+j.7F790m(Vj8l8Q:_CZ(Gm1%X\N1&u!FKH MB~> endstream
Example 4.4 Unencoded stream
<< /Length 558 >> stream 2 J
PDF 1.2
Page 51
November 12, 1996 4.8.1
4: Objects 53
BT /F1 12 Tf 0 Tc 0 Tw 72.5 712 TD [(Unencoded streams can be read easily)65 (,)] TJ 0 -14 TD [(b)20 (ut generally tak)10 (e more space than \311)] TJ T* (encoded streams.)Tj 0 -28 TD [(Se) 25 (v) 15 (eral encoding methods are a) 20 (v) 25 (ailable in PDF)80 (.)] TJ 0 -14 TD (Some are used for compression and others simply) Tj T* [(to represent binary data in an ) 55 (ASCII format.)] TJ T* (Some of the compression encoding methods are \ suitable ) Tj T* (for both data and images, while others are \ suitable only ) Tj T* (for continuous-tone images.)Tj ET endstream
4.8.1 ASCIIHexDecode filter
This filter decodes data that has been encoded as ASCII hexadecimal. ASCII hexadecimal encoding and ASCII base-85 encoding (described in the following section) convert binary data such as images to 7-bit data. In general, ASCII base85 encoding is preferred because it is more compact.
ASCII hexadecimal encoding produces a 1:2 expansion in the size of the data. Each pair of ASCII hexadecimal digits (0–9 and A–F or a–f) produces one byte of binary data. All whitespace characters are ignored. The right angle bracket ( > ) indicates the end of data (EOD). Any other character causes an error. If the filter encounters the EOD marker after reading an odd number of hexadecimal digits, it behaves as if a zero followed the last digit.
4.8.2 ASCII85Decode filter
This filter decodes data that has been encoded in the ASCII base-85 encoding and produces binary data.
ASCII base-85 encoding produces five ASCII printing characters from every four bytes of binary data. Each group of four binary bytes ( b 1 b 2 b 3 b 4 ) is converted to a group of five encoded characters ( c 1 c 2 c 3 c 4 c 5 ) using the relation:
Page 52
4: Objects November 12, 1996
54 Adobe Systems Inc.
The five “digits” of the encoded base-85 number are converted to printable ASCII characters by adding 33 (the ASCII code for ! ) to each. The resulting data contains only printable ASCII characters with codes in the range 33 (!) to 117 (u).
Two special cases occur during encoding. First, if all five encoded digits are zero, they are represented by the character code 122 (z), instead of by a series of five exclamation points (!!!!!). In addition, if the length of the binary data to be encoded is not a multiple of four bytes, the last partial 4-tuple is used to produce a last, partial output 5-tuple. Given n (1, 2, or 3) bytes of binary data, the encoding first appends 4 − n zero bytes to make a complete 4-tuple. This 4-tuple is encoded in the usual way, but without applying the special z case. Finally, only the first n + 1 characters of the resulting 5-tuple are written out. Those characters are immediately followed by the EOD marker, which is the two-character sequence ~> .
The following conditions are errors during decoding:
• The value represented by a 5-tuple is greater than 2 32 − 1.
• A z character occurs in the middle of a 5-tuple.
• A final partial 5-tuple contains only one character.
These conditions never occur in the output produced from a correctly encoded byte sequence.
4.8.3 LZWDecode filter
This filter decodes data encoded using the LZW data compression method, which is a variable-length, adaptive compression method. LZW encoding compresses binary and ASCII text data but always produces binary data, even if the original data was ASCII text. If necessary, this binary data may be converted to 7-bit data using either the ASCII hexadecimal or ASCII base-85 encodings described in previous sections.
LZW compression can discover and exploit many patterns in its input data, whether that input is text or image data. The compression obtained using the LZW method varies from file to file; the best case (a file of all zeros) provides a compression approaching 1365:1 for long files, while the worst case (a file in which no pair of adjacent characters appears twice) can produce an expansion of approximately 50%.
Data encoded using LZW consist of a sequence of codes that are 9 to 12 bits long. Each code represents a single character of input data (0–255), a clear-table marker (256), an EOD marker (257), or a table entry representing a multi-character sequence that has been encountered previously in the input (258 and greater).
b 1 256 3 b1 2563 () × × b 2 256 2 b2 2562 () × × b 3 b3 () × 256 × 256 b 4 b2 256() × b3 () × 256 + ++ =
c 1 85 4 c1 854 () × × c 2 85 3 c2 853 () × × c 3 85 2 c3 852 () × × c 4 c4 () × 85 × 85 c 5 c2 85() × c3 85() × c4 () × 85 + + ++
Page 53
November 12, 1996 4.8.3
4: Objects 55
Initially, the code length is 9 bits and the table contains only entries for the 258 fixed codes. As encoding proceeds, entries are appended to the table, associating new codes with longer and longer input character sequences. The encoding and decoding filters maintain identical copies of this table.
Whenever both encoder and decoder independently (but synchronously) realize that the current code length is no longer sufficient to represent the number of entries in the table, they increase the number of bits per code by one. The first output code that is 10 bits long is the one following creation of table entry 511, and similarly for 11 (1023) and 12 (2047) bits. Codes are never longer than 12 bits, so entry 4095 is the last entry of the LZW table.
The encoder executes the following sequence of steps to generate each output code:
1. Accumulate a sequence of one or more input characters matching a sequence already present in the table. For maximum compression, the encoder looks for the longest such sequence.
2. Output the code corresponding to that sequence.
3. Create a new table entry for the first unused code. Its value is the sequence found in step 1 followed by the next input character.
To adapt to changing input sequences, the encoder may at any point issue a cleartable code, which causes both the encoder and decoder to restart with initial tables and a 9-bit code. By convention, the encoder begins by issuing a clear-table code. It must issue a clear-table code when the table becomes full; it may do so sooner.
The LZW filter can be used to compress text or images. When compressing images, several techniques reduce the size of the resulting compressed data. For example, image data frequently change very little from sample to sample. By subtracting the values of adjacent samples (a process called differencing ) and LZW-encoding the differences rather than the raw sample values, the size of the output data may be reduced. Further, when the image data contains several color components (red–green–blue or cyan–magenta–yellow–black) per sample, taking the difference between the values of like components in adjacent samples, rather than between different color components in the same sample, often reduces the output data size. In order to control these and other options, the LZW filter accepts several optional parameters, shown in Ta Ta b le 4.4 . All values supplied to the decode filter by any optional parameters must match those used when the data was encoded.
Table 4.4 Optional parameters for LZW filter
Key Type Semantics
Predictor integer If Predictor is 1, the file is decoded assuming that it was encoded using the normal LZW algorithm. If Predictor > 1, decoding is performed assuming that prior to encoding, the data was differenced. The default value is 1. For details on this value, see Section 4.8.5 on pa g e 57 .
Page 54
4: Objects November 12, 1996
56 Adobe Systems Inc.
Columns integer Has an effect only if Predictor > 1. Columns is the number of samples in a sampled row. The first sample in each row is not differenced; all subsequent samples in a row are differenced with the prior sample. Each row begins on a byte boundary. Any extra bits needed to complete a byte at the end of a row (consisting of Columns × Colors × BitsPerComponent bits) are not differenced. The default value is 1.
Colors integer Has an effect only if Predictor > 1. Number of interleaved color components per sample in a sampled image. Each color component is differenced with the value of the same color component in the previous sample. Allowed values are 1, 2, 3, and 4. The default value is 1.
BitsPerComponent integer Has an effect only if Predictor > 1. BitsPerComponent is the number of bits used to represent each color component in a pixel. Allowed values are 1, 2, 4, and 8. The default value is 8.
EarlyChange integer If EarlyChange is 0, increases in the length of the code are postponed as long as possible. If it is 1, they occur one code word early. The value of EarlyChange used in decoding must match that used during encoding. This parameter is included because LZW sample code distributed by some vendors increases the code word length one word earlier than necessary. The default value is 1.
The LZW compression method is the subject of United States patent number 4,558,302 owned by the Unisys Corporation. Adobe Systems has licensed this patent for use in its products, including Acrobat products. However, independent software vendors may be required to license this patent directly from Unisys to develop software using LZW. Further information can be obtained from Welch Licensing Department, Law Department, M/S C2SW1, Unisys Corporation, Blue Bell, Pennsylvania, 19424.
4.8.4 FlateDecode Filter
This filter decodes data that has been encoded with the Flate compression method, which encodes binary or ASCII data, optionally after transformation by a predictor function. It is based on the public-domain zlib/deflate compression method, which is a variable-length Lempel-Ziv adaptive compression method cascaded with adaptive Huffman coding. The zlib/deflate compression method is fully defined in Internet Engineering Task Force Requests for Comments (IETF RFCs) 1950 and 1951. The optional Predictor functions are discussed in the following text.
The output produced by Flate encoding is always binary, even if the input is ASCII text.
PDF 1.2
Page 55
November 12, 1996 4.8.5
4: Objects 57
Table 4.5 Optional parameters for FlateDecode filter
Key Type Semantics
Predictor integer If Predictor is 1, the file is decoded assuming that it was encoded using the normal Flate algorithm. If Predictor > 1, decoding is performed assuming that prior to encoding, the data was differenced. The default value is 1. For details on this value, see Section 4.8.5, “LZW and Fla te pr edictor functions .”
Columns integer Has an effect only if Predictor > 1. Columns is the number of samples in a sampled row. The first sample in each row is not differenced; all subsequent samples in a row are differenced with the prior sample. Each row begins on a byte boundary. Any extra bits needed to complete a byte at the end of a row (consisting of Columns × Colors × BitsPerComponent bits) are not differenced. The default value is 1.
Colors integer Has an effect only if Predictor > 1. Colors is the number of interleaved color components per sample in a sampled image. Each color component is differenced with the value of the same color component in the previous sample. Allowed values are 1, 2, 3, and 4. The default value is 1.
BitsPerComponent integer Has an effect only if Predictor > 1. BitsPerComponent is the number of bits used to represent each color component in a pixel. Allowed values are 1, 2, 4, and 8. The default value is 8.
4.8.5 LZW and Flate predictor functions
LZW and Flate encoding filters compress more compactly if their input data are highly predictable. One way of increasing the predictability of many continuoustone sampled images is to replace each pixel with the difference between that pixel and some predictor function applied to earlier neighboring pixels. If the predictor function works well, the postprediction data will cluster toward 0.
Two predictor function groups are supported. The first, the TIFF group, consists of the single function that is Predictor 2 in the TIFF standard. (In TIFF 6.0, it applies only to LZW compression, but here it applies to Flate compression as well.) TIFF predictor 2 predicts that each color component of a pixel will be the same as the corresponding color component of the pixel immediately to the left.
The second supported predictor function group, the PNG group, consists of the “filters” of the World Wide Web Consortium’s Portable Network Graphics (PNG) recommendation. The term predictors is used here instead of filters , to avoid confusion. There are five basic PNG predictor algorithms, and a sixth one that invites an optimum hybrid of the first five. The first five are None , Sub (predicting the same as the pixel to the left), Up (predicting the same as the pixel above), Average (predicting the average of the pixel to the left and the pixel above), and Paeth (a nonlinear function of the pixel above, the pixel to the left, and the pixel to the upper left).
PDF 1.2
Page 56
4: Objects November 12, 1996
58 Adobe Systems Inc.
The two predictor function groups have some commonalities. Both assume that data are presented in order, from top row to bottom row, and within a row, from left to right. Both assume that a row occupies a whole number of bytes, rounded upward if necessary. Both assume that pixels and their components are packed into bytes from high- to low-order bits. Both assume that all color components of pixels outside the image (which are necessary for predictions near the boundaries) are 0.
Table 4.6 Predictor values
1 No prediction (Default value)
2 TIFF predictor 2
10 PNG prediction (on encode, PNG None on all rows)
11 PNG prediction (on encode, PNG Sub on all rows)
12 PNG prediction (on encode, PNG Up on all rows)
13 PNG prediction (on encode, PNG Average on all rows)
14 PNG prediction (on encode, PNG Paeth on all rows)
15 PNG prediction (on encode, PNG optimum)
The two predictor function groups also differ in significant ways. First, the postprediction data for each PNG-predicted row begins with an explicit algorithm tag, so different rows can be predicted with different algorithm to improve compression. TIFF 2 prediction has no such identifier; the same algorithm applies to all rows. Second, the TIFF function group predicts each color component from the prior instance of that color component, without regard to the width of the color component or the number of colors. In contrast, the PNG function group predicts each byte from the corresponding byte of the prior pixel (and/or the same pixel on the prior line and/or the prior pixel on the prior line), regardless of whether there are multiple color components in a byte, or whether a single color component spans multiple bytes. This can yield significantly better speed at a cost somewhat worse compression.
4.8.6 Comparison of LZW and Flate encoding
Flate encoding, like LZW encoding, discovers and exploits many patterns in its input data, whether text or images. Thanks to its cascaded adaptive Huffman coding, Flate-encoded output is usually substantially more compact than LZWencoded output for the same input. Flate and LZW decoding speeds are comparable, but Flate encoding speed is considerably slower than LZW encoding speed. Usually, both Flate and LZW compress their inputs substantially. In the worst case, however, Flate encoding expands its input by no more than 11 bytes, plus the effects of algorithm tags added by PNG predictors. LZW encoding has a worst-case expansion of at least a factor of 1.125, which can increase to a factor of nearly 1.5 in some implementations (plus PNG tags effects, as with Flate encoding).
PDF 1.2
Page 57
November 12, 1996 4.8.7
4: Objects 59
4.8.7 RunLengthDecode filter
This filter decodes data that has been encoded in a simple byte-oriented, runlength-encoded format. Run-length encoding produces binary data, even if the original data was ASCII text.
The compression achieved by run-length encoding depends on the input data. In the best case, a file of all zeros, a compression of approximately 64:1 is achieved for long files. The worst case, the hexadecimal sequence of alternating <00 FF 00 FF …>, results in an expansion of 127:128.
The encoded data is a sequence of runs, where each run consists of a length byte followed by 1 to 128 bytes of data. If length is in the range 0 to 127, the following length + 1 (1 to 128 bytes) are copied literally during decompression. If length is in the range 129 to 255, the following single byte is to be copied 257 − length times (2 to 128 times) during decompression. The value 128 is placed at the end of the compressed data, as an EOD marker.
4.8.8 CCITTFaxDecode filter
This filter decodes image data that has been encoded using either Group 3 or Group 4 CCITT facsimile (fax) encoding. This filter is useful only for bitmap image data, not for color images, grayscale images, or text. Group 3 and Group 4 CCITT encoding produce binary data that may be converted, if necessary, to 7-bit data using either the ASCII hexadecimal or ASCII base-85 encodings, described in previous sections.
The compression achieved using CCITT encodings depends on the data, as well as on the value of various optional parameters. For Group 3 one-dimensional encoding, the best case is a file of all zeros. In this case, each scan line compresses to 4 bytes, and the compression factor depends on the length of a scan line. If the scan line is 300 bytes long, a compression ratio of approximately 75:1 is achieved. The worst case, an image of alternating ones and zeros, produces an expansion of 2:9.
CCITT encoding is defined by an international standards organization, the International Coordinating Committee for Telephony and Telegraphy (CCITT). The encoding is designed to achieve efficient compression of monochrome (1 bit per sample) image data at relatively low resolutions. The algorithm is not described in detail here, but can be found in the CCITT standards, [13] and [14] , listed in the Bibliography on pa g e 392 .
The fax encoding method is bit-oriented, rather than byte-oriented. This means that, in principle, encoded or decoded data may not end on a byte boundary. The filter addresses this in the following ways:
• Encoded data are ordinarily treated as a continuous, unbroken bit stream. However, the EncodedByteAlign parameter (described in Ta Ta b le 4.7 ) can be used to cause each encoded scan line to be filled to a byte boundary. Although this is not prescribed by the CCITT standard and fax machines don’t do this, some software packages find it convenient to encode data this way.
Page 58
4: Objects November 12, 1996
60 Adobe Systems Inc.
• When a filter reaches EOD, it always skips to the next byte boundary following the encoded data.
Both Group 3 and Group 4 encoding, as well as optional features of the CCITT standard, are supported. The optional parameters that can be used to control the decoding are listed in Ta Ta b le 4.7 . Except as noted, all values supplied to the decode filter by the optional parameters must match those used when the data was encoded.
Table 4.7 Optional parameters for CCITTFaxDecode filter
Key Type Semantics
K integer Selects the encoding scheme used. A negative value indicates pure twodimensional (Group 4) encoding. Zero indicates pure one-dimensional (Group 3, 1-D) encoding. A positive value indicates mixed one- and two-dimensional encoding (Group 3, 2-D) in which a line encoded one-dimensionally can be followed by at most K − 1 lines encoded two-dimensionally. The decoding filter distinguishes between negative, zero, and positive values of K , but does not distinguish between different positive K values. The default value is 0.
EndOfLine Boolean End-of-line bit patterns are always accepted but required if EndOfLine is true . The default value is false .
EncodedByteAlign Boolean If true , each encoded line must begin on a byte boundary. The default value is false .
Columns integer Specifies the width of the image in samples. If Columns is not a multiple of 8, the width of the unencoded image is adjusted to the next multiple of 8, so that each line starts on a byte boundary. The default value is 1728.
Rows integer Specifies the height of the image in scan lines. If this parameter is zero or is absent, the height of the image is not predetermined and the encoded data must be terminated by an end-of-block bit pattern or by the end of the filter’s data source. The default value is 0.
EndOfBlock Boolean If true , the data is expected to be terminated by an end-of-block, overriding the Rows parameter. If false , decoding stops when Rows lines have been decoded or when the data has been exhausted, whichever occurs first. The end-of-block pattern is the CCITT end-of-facsimile-block (EOFB) or return-to-control (RTC) appropriate for the K parameter. The default value is true .
Blackls1 Boolean If true , causes bits with value 1 to be interpreted as black pixels and bits with value zero to be interpreted as white pixels. The default value is false .
DamagedRowsBeforeError integer If DamagedRowsBeforeError is positive, EndOfLine is true , and K is nonnegative, then up to DamagedRowsBeforeError rows of data are tolerated before an error is generated. Tolerating a damaged row means locating its end in
Page 59
November 12, 1996 4.8.9
4: Objects 61
the encoded data by searching for an EndOfLine pattern, and then substituting decoded data from the previous row if the previous row was not damaged or a white scan line if the previous row was damaged. The default value is 0.
4.8.9 DCTDecode filter
This filter decodes grayscale or color image data that has been encoded in the JPEG baseline format. JPEG encoding produces binary data.
JPEG is a lossy compression method, meaning that some of the information present in the original image is lost when the image is encoded. Because of the information loss, only images (never text) should be encoded in this format. The compression achieved using the JPEG algorithm depends on the image being compressed and the amount of loss that is acceptable. In general, a compression of 15:1 can be achieved without a perceptible loss of information, and 30:1 compression causes little impairment of the image.
During encoding, several optional parameters control the algorithm and the information loss. The values of these parameters are stored in the encoded data, and the decoding filter generally obtains the parameter values it requires directly from the encoded data. A description of the parameters accepted by the encoding filter can be found in Section 3.13.3 of the PostScript Language Reference Manual, Second Edition .
JPEG stands for the ISO/CCITT Joint Photographic Experts Group, an organization responsible for developing an international standard for compression of color image data. The encoding method uses the discrete cosine transform (DCT). Data to be encoded consists of a stream of image samples, each containing one, two, three, or four color components. The color component values for a particular sample must appear consecutively. Each component value occupies an 8-bit byte.
The details of the encoding algorithm are not presented here but can be found in the references [18] and [21] listed in the Bibliography on pa g e 391 . Briefly, the JPEG algorithm breaks an image up into blocks of 8 × 8 samples. Each color component in an image is treated separately. A two-dimensional DCT is performed on each block. This operation produces 64 coefficients, which are then quantized. Each coefficient may be quantized with a different step size. It is the quantization that results in the loss of information in the JPEG algorithm. The quantized coefficients are then compressed.
The amount of loss incurred in JPEG encoding is controlled by the encoding filter, which can reduce the loss by making the step size in the quantization smaller at the expense of reducing the amount of compression achieved by the algorithm. The JPEG filter implementation in the Acrobat products does not support features of the JPEG standard that are not relevant. In addition, certain choices regarding reserved marker codes and other optional features of the standard have been made.
Page 60
4: Objects November 12, 1996
62 Adobe Systems Inc.
4.9 The null object
The keyword null represents the null object.
Note The value of a dictionary key can be specified as null . A simpler but equivalent way to express this is to omit the key from the dictionary.
4.10 Indirect objects
A direct object is a Boolean, number, string, name, array, dictionary, stream, or null, as described in the previous sections. An indirect object is an object that has been labeled so that it can be referenced by other objects. Any type of object may be labeled as an indirect object. Indirect objects are very useful; for example, if the length of a stream is not known before it is written, the value of the stream’s Length key may be specified as an indirect object that is stored in the file after the stream.
An indirect object consists of an object identifier, a direct object, and the endobj keyword. The object identifier consists of an integer object number, r, an integer generation number, r, and the obj keyword:
<indirect object> ::= <object ID> <direct object> endobj <object ID> ::= <object number> <generation number> obj
The combination of object number and generation number serves as a unique identifier for an indirect object. Throughout its existence, an indirect object retains the object number and generation number it was initially assigned, even if the object is modified.
Each indirect object has a unique object number, and indirect objects are often but not necessarily numbered sequentially in the file, beginning with 1. Until an object in the file is deleted, all generation numbers are 0.
4.11 Object references
Any object used as an element of an array or as a value in a dictionary may be specified by either a direct object or an indirect reference. An indirect reference is a reference to an indirect object, and consists of the indirect object’s object number, generation number, and the R keyword:
Page 61
November 12, 1996 4.8.9
4: Objects 63
<indirect reference> ::= <object number> <generation number> R
Using an indirect reference to the stream’s length, a stream could be written in this way:
Example 4.1 Indirect reference
7 0 obj << /Length 8 0 R >> stream BT /F1 12 Tf 72 712 Td (A stream with an indirect Length) Tj ET endstream endobj 8 0 obj 64 endobj
Note An indirect reference to an undefined object is not an error; it is treated as a reference to the null object. For example, if a PDF file contains the indirect reference (12 0 R) but does not contain the definition (12 0 obj ... endobj), then the indirect reference is null.
Page 62
4: Objects November 12, 1996
64 Adobe Systems Inc.
Page 63
PDF 1.2 Reference Manual November 12, 1996 5: File Structure
65
CHAPTER 5
File Structure
This chapter describes the overall organization of a PDF file. A PDF file provides a structure that represents a document. This structure provides a way to rapidly access any part of a document and a mechanism for updating it.
The body of a PDF file contains a sequence of PDF objects that are used to construct a document. Cha pter 4 describes the types of objects supported by PDF. Cha pter 6 explains the way a document is constructed using these object types.
A particular arrangement of the object in a PDF file, optimized for incremental access in network environments, is known as Linearized PDF. F. It is described in Cha pter 9 .
5.1 PDF files
A canonical PDF file consists of four sections: a one-line header, a body, a crossreference table, and a trailer. F igur e 5.1 shows this structure:
<PDF file> ::= <header> <body> <cross-reference table> <trailer>
In a PDF 1.0 file, all information is represented in 7-bit ASCII. Binary data must be encoded in ASCII; ASCII hexadecimal and ASCII base-85 are supported. No line in a PDF 1.0 file may be longer than 255 characters. A line in a file is delimited by a carriage return (<0D>), a linefeed (<0A>), or a carriage return followed by a linefeed. Updates may be appended to a PDF file, as described in Section 5.6, “Incr emental upda te ."
Because the requirement to use ASCII does not guarantee file transmission transparency, and because it can cause a 20% expansion in the size of objects such as images that are naturally binary data, PDF 1.1 and subsequent versions relax the 7-bit ASCII requirement. PDF 1.1 allows files to contain binary data in strings, streams, and comments. In fact, experiments have shown that PDF files are less likely to be corrupted by system utilities if they do contain binary data. It is therefore recommended that the second line of a PDF file be a comment that contains at least four characters with codes 128 or greater.
PDF 1.2
PDF 1.0
PDF 1.1
Page 64
5: File Structure November 12, 1996
66 Adobe Systems Inc.
To accommodate binary data, the restriction on line length is also relaxed in PDF 1.1. PDF 1.1 files with binary data may have arbitrarily long lines. However, to increase compatibility with other applications that process PDF files, all lines that are not part of stream object data shall be no longer than 255 characters.
5.2 Header
The first line of a PDF file specifies the version number of the PDF specification to which the file adheres. The current version is 1.2; the first line of a 1.2-conforming PDF file should be %PDF-1.2 . However, 1.0-conforming files and 1.1conforming files are also 1.2-conforming files, so an application that understands PDF 1.2 also accepts a file that begins with either %PDF-1.1 or %PDF-1.0 .
<header> ::= <PDF version>
5.3 Body
The body of a PDF file consists of a sequence of indirect objects representing a document. The objects, which are of the basic types described in Chapter 4 , represent components of the document such as fonts, pages, and sampled images.
Comments can appear anywhere in the body section of a PDF file. Comments have the same syntax as those in the PostScript language; they begin with a % character and may start at any point on a line. All text between the % character and the end of the line is treated as a comment. Occurrences of the % character within strings or streams are not treated as comments.
Header
Body
Cross-reference table
Trailer
Figure 5.1 Structure of a PDF file that has not been updated
Page 65
November 12, 1996
5: File Structure 67
5.4 Cross-reference table
The cross-reference table contains information that permits random access to indirect objects in the file, so that the entire file need not be read to locate any particular object. For each indirect object in the file, the table contains a one-line entry describing the location of the object in the file.
A PDF file contains one cross-reference table, consisting of one or more sections . If no updates have been appended to the file, the cross-reference table contains a single section. One section is added each time updates are appended to the file.
The cross-reference section is the only part of a PDF file with a fixed format. This permits random access to entries in the cross-reference table. The section begins with a line containing the keyword xref . Following this line are one or more crossreference subsections:
<cross-reference section> ::= xref <cross-reference subsection>+
Each subsection contains entries for a contiguous range of object numbers. The organization of the cross-reference section into subsections is useful for incremental updates, because it allows a new cross-reference section to be added to the PDF file, containing entries only for objects that have been added or deleted. Each cross-reference subsection begins with a header line containing two numbers: the first object number in that subsection and the number of entries in the subsection. Following the header are the entries, one per line:
<cross-reference subsection> ::= <object number of first entry in subsection> <number of entries in subsection> <cross-reference entry>+
Each entry is exactly 20 characters long, including the end-of-line marker. There are two formats for cross-reference table entries: one for objects that are in use and another for objects that have been deleted and so are free:
<cross-reference entry> ::= <in-use entry> | <free entry>
For an object that is in use, the entry contains a byte offset specifying the number of bytes from the beginning of the file to the beginning of the object, the generation number of the object, and the n keyword:
<in-use entry> ::= <byte offset> <generation number> n
The byte offset is a ten-digit number, padded with leading zeros if necessary. It is separated from the generation number by a single space. The generation number is a five-digit number, also padded with leading zeros if necessary. Following the
Page 66
5: File Structure November 12, 1996
68 Adobe Systems Inc.
generation number is a single space and the n keyword. Following the keyword is the end-of-line sequence. If the end-of-line is a single character (either a carriage return or linefeed), it is preceded by a single space. If the end-of-line sequence is two characters (a carriage return followed by a linefeed), it is not preceded by a space.
For an object that is free, the entry contains the object number of the next free object, a generation number, and the f keyword:
<free entry> ::= <object number of next free object> <generation number> f
The entry has the same format as that for an object that is in use: a ten-digit object number, a space, a five-digit generation number, a space, the f keyword, and an end-of-line sequence.
The free objects in the cross-reference table form a linked list, with the entry for each free object containing the object number of the next free object. The first entry in the table (object number 0) is always free and has a generation number of 65535. It is the head of the linked list of free objects. The last free entry in the cross-reference table (the tail of the linked list) uses 0 as the object number of the next free object.
When an indirect object is deleted, its cross-reference entry is marked free, and the generation number in the entry is incremented by one to record the generation number to be used the next time an object with that object number is created. Each time the entry is reused, its generation number is incremented. The maximum generation number is 65535. Once that number is reached, that entry in the crossreference table will not be reused.
Example 5.1 shows a cross-reference section containing a single subsection with six entries; four that are in use (object numbers 1, 2, 4, and 5) and two that are free (object numbers 0 and 3). Object number 3 has been deleted, and the next object created with an object number of 3 will be given the generation number of 7.
Example 5.1 Cross-reference section with a single subsection
xref 0 6 0000000003 65535 f 0000000017 00000 n 0000000081 00000 n 0000000000 00007 f 0000000331 00000 n 0000000409 00000 n
Example 5.2 shows a cross-reference section with four subsections containing a total of five entries. The first subsection contains one entry, for object number 0, which is free. The second subsection contains one entry, for object number 3, which is in use. The third subsection contains two entries, for objects number 23
Page 67
November 12, 1996
5: File Structure 69
and 24, both of which are in use. Object number 23 has been reused, as can be seen from the fact that it has a generation number of 2. The fourth subsection contains one entry, for object number 30, which is in use.
Example 5.2 Cross-reference section with multiple subsections
xref 0 1 0000000000 65535 f 3 1 0000025325 00000 n 23 2 0000025518 00002 n 0000025635 00000 n 30 1 0000025777 00000 n
A ppendix A contains a more extensive example of the structure of a PDF file after several updates have been made to it.
5.5 Trailer
The trailer enables an application reading a PDF file to quickly find the crossreference table and certain special objects. Applications should read a PDF file from its end. The last line of a PDF file contains the end-of-file marker, %%EOF . The two preceding lines contain the keyword startxref and the byte offset from the beginning of the file to the beginning of the word xref in the last crossreference section in the file. The trailer dictionary precedes this line.
The trailer dictionary, shown in Ta Ta b le 5.1 , consists of the keyword trailer followed by a set of key–value pairs enclosed in double angle brackets:
<trailer> ::= trailer << <trailer key–value pair>+ >> startxref <cross-reference table start address> %%EOF
Table 5.1 Trailer attributes
Key Type Semantics
Size integer (Required) Total number of entries in the file’s cross-reference table, including the original table and all updates.
Prev integer (Present only if the file has more than one cross-reference section) Byte offset from the beginning of file to the location of the previous cross-reference section. If the file has never been updated, it will not contain the Prev key.
Page 68
5: File Structure November 12, 1996
70 Adobe Systems Inc.
Root dictionary (Required; must be indirect reference) Catalog object for the document, described on pa g e 77 .
Info dictionary (Optional; must be indirect reference) Info dictionary for the document, described on pa g e 114 .
ID array (Optional) An array of two strings, each of which is an ID. The first ID is established when the file is created and the second ID is changed each time the file is updated. IDs are described on pa g e 117 .
Encrypt dictionary (Required if document is encrypted) Information used to decrypt a document, described on pa g e 118 .
An example trailer for a file that has not been updated is shown in Example 5.3 . The fact that the file has not been updated is determined from the absence of a Prev key in the trailer dictionary.
Example 5.3 Trailer
trailer << /Size 22 /Root 2 0 R /Info 1 0 R >> startxref 18799 %%EOF
5.6 Incremental update
The contents of a PDF file can be updated without rewriting the entire file. Changes can be appended to the end of the file, leaving completely intact the original contents of the file. When a PDF file is updated, any new or changed objects are appended, a cross-reference section is added, and a new trailer is inserted. The resulting file has the structure shown in F igur e 5.2 :
<Updated PDF file> ::= <PDF file> {<update>}*
<update> ::= <body> <cross-reference section> <trailer>
A complete example of an updated file is shown in A ppendix A .
PDF 1.1
PDF 1.1
Page 69
November 12, 1996
5: File Structure 71
The cross-reference section added when a PDF file is updated contains entries only for objects that have been changed, replaced, or deleted, plus the entry for object 0. Deleted objects are left unchanged in the file, but are marked as deleted in their cross-reference entries. The trailer that is added contains all the information in the previous trailer, as well as a Prev key specifying the location of the previous cross-reference section. As shown in F igur e 5.2 , after a file has been updated several times it contains several trailers, as well as several %%EOF lines.
Because updates are appended to PDF files, it is possible to end up with several copies of an object with the same object ID (object number and generation number) in a file. This occurs, for example, if a text annotation is changed several times, with the file being saved between changes. Because the text annotation object is not deleted, it retains the same object number and generation number. Because it has been changed, however, an updated copy of the object is included in the update section added to the file. The cross-reference section added includes a pointer to this new changed version, overriding the information contained in the original cross-reference section. When a program such as Acrobat reads the file, it must build cross-reference information in such a way that the most recent version of an object is accessed in the file.
Page 70
5: File Structure November 12, 1996
72 Adobe Systems Inc.
Figure 5.2 Structure of a PDF file after changes have been appended several times
5.7 Encryption
Documents can be encrypted to protect their contents from unauthorized access. Access to a protected document’s contents is controlled by the security handler specified in the Encryption dictionary. The Encryption dictionary is the value of the Encrypt key in the trailer dictionary. Section 6.14, “Encr yption dictionar y ,” describes the Encryption dictionary and security handlers.
Strings and streams in a protected document are encrypted. Other data types (such as integers and Booleans) that are used primarily for structural information in a PDF file are not encrypted. This combination protects a document’s contents, while allowing random access to the objects within a PDF file.
Header
Original body
Original cross-reference section
Updated trailer n
Body update 1
Cross-reference section 1
Body update n
Cross-reference section n
Original trailer
Updated trailer 1
PDF 1.1
Page 71
November 12, 1996
5: File Structure 73
All strings and streams in a protected document, except those in the Encryption dictionary, are encrypted using the RC4 encryption algorithm. This prevents unauthorized users from simply removing the password from a PDF file to gain access to it. Strings in the Encryption dictionary are encrypted and decrypted by the security handler itself, using whatever encryption algorithm it chooses.
RC4 is a proprietary algorithm of RSA Data Security, Inc. Adobe Systems has licensed this algorithm for use in its products. Independent software vendors may be required to license this algorithm to develop software that encrypts or decrypts PDF documents. Further information can be obtained from RSA Data Security, Inc., 100 Marine Parkway, Redwood City, California, 95065.
Encryption details
Protection of data in a PDF file consists of two steps: computation of a key to be used to encrypt data, and encryption of the data. The key is simply a string of five bytes. (The key is restricted in length to five bytes (40 bits) to satisfy current U.S. cryptographic export requirements.) The key can be computed in any number of ways, more or less cryptographically secure, while encryption of data based on the key is always performed in the same way. The Encryption dictionary identifies the security handler that computes the key. PDF includes one built-in method for computing the key, called “Standard.” The remainder of this section explains how data is encrypted given a key. Section 6.12, “Encrypt dictionary,” discusses security handlers, including the Standard security handler.
Once the key for a document is computed, strings and streams are encrypted using Algorithm 5.3:
Algorithm 5.3 Encrypting string and stream data
1. Extend the key by five bytes using the string or stream’s object identifier. (See Section 4.10, “Indir ect objects .”) If the string or stream is a direct object, the identifier of the indirect object containing it is used. An object identifier consists of an object number and a generation number. These are treated as binary integers. The low-order three bytes of the object number and the low-order two bytes of the generation number are concatenated to the key in that order, low-order byte first.
2. The resulting ten-byte string is used as input for the MD5 hash function.
3. The first ten bytes of the output of the MD5 function are used as input to the RC4 function, along with the string or stream data to be encrypted. The output of the RC4 function is the encrypted data that is stored in the PDF file.
RC4 is a symmetric stream cipher—the same algorithm is used for both encryption and decryption, and the algorithm does not change the length of the data. The PDF encryption algorithm is also symmetric. Given a key, the three steps described above can also be used to decrypt data.
Page 72
5: File Structure November 12, 1996
74 Adobe Systems Inc.
Stream data is encrypted after all stream encoding filters have been applied (and is decrypted before the stream decoding filters are applied). Decryption of strings, other than those in the Encryption dictionary, is done after escape-sequence processing and hex decoding as appropriate to the string representation described in Section 4.4, “Str ings .”
Page 73
PDF 1.2 Reference Manual November 12, 1996 6: Document Structure
75
CHAPTER 6
Document Structure
PDF provides an electronic representation of a document—a series of pages containing text, graphics, and images, along with other information such as thumbnails (miniature images of the pages), text annotations, hypertext links, and outline entries (also called bookmarks ). Previous chapters lay the groundwork for understanding the PDF representation of a document, but do not describe the representation itself. Cha pter 3 presents the coordinate systems that provide the supports on which the visible part of a PDF document depends. Cha pter 4 explains the types of objects supported by PDF. Document components used in PDF are built from those objects. Cha pter 5 describes the overall structure of a PDF file, which provides the framework necessary to organize the pieces of a document, move rapidly among the pages of a document, and update a document.
The body of a PDF file consists of a sequence of objects that collectively represent a PDF document. This chapter focuses exclusively on the contents of the body section of a PDF file and contains a description of each type of object that may be contained in a PDF document. Following each description is an example showing the object as it might appear in a PDF file. Complete example PDF files appear in A ppendix A .
6.1 Introduction
A PDF document can be described as a hierarchy of objects contained in the body section of a PDF file. F igur e 6.1 shows the structure of a PDF document. Most objects in this hierarchy are dictionaries. Parent, child, and sibling relationships are represented by key–value pairs whose values are indirect references to parent, child, or sibling objects. For example, the Catalog object, which is the root of the hierarchy, contains a Pages key whose value is an indirect reference to the object that is the root of the Pages tree.
Each page of the document includes references to its imageable contents, its thumbnail, and any annotations that appear on the page. The PDF file’s standard trailer, described in Section 5.5, “Tr Tr ailer ,” specifies the location of the Catalog object as the value of the trailer’s Root key. In addition, the trailer specifies the location of the document’s Info dictionary, a structure that contains general information about the document, as the value of the trailer’s Info key.
Page 74
6: Document Structure November 12, 1996
76 Adobe Systems Inc.
Note In many of the tables in this chapter, certain key–value pairs contain the notation “must be an indirect reference” or “indirect reference preferred.” Unless one of these is specified in the description of the key–value pair, objects that are the value of a key can either be specified directly or using an indirect reference, as described in Section 4.1 1, “Object re refere rences .”
Fi gure 6 . 1 Structure of of a PDF d ocument
Catalog
Pages tree
Outline entry
Article threads
Named destinations
Outline tree
Page
Imageable content
Thumbnail
Annotations
Page
Outline entry
• • •
• • •
• • • • • •
Bead
Bead
Thread
Thread
Page 75
November 12, 1996
6: Document Structure 77
6.2 Catalog
The Catalog is a dictionary that is the root node of the document. It contains a reference to the tree of pages contained in the document, a reference to the tree of objects representing the document’s outline, a reference to the document’s article threads, and the list of named destinations. In addition, the Catalog indicates whether the document’s outline or thumbnail page images should be displayed automatically when the document is viewed and whether some location other than the first page should be shown when the document is opened. Example 6.1 shows a sample Catalog object.
Example 6.1 Catalog
1 0 obj << /Type /Catalog /Pages 2 0 R /Outlines 3 0 R /PageMode /UseOutlines >> endobj
Ta Ta b le 6.1 shows the attributes for a Catalog.
PDF 1.1
Page 76
6: Document Structure November 12, 1996
78 Adobe Systems Inc.
Table 6.1 Catalog attributes
Key Type Semantics
Type name (Required) Object type. Always Catalog .
Pages dictionary (Required, must be an indirect reference) Pages object that is the root of the document’s Pages tree.
Outlines dictionary (Required if the document has an outline; must be an indirect reference) The Outlines object that is the root of the document’s outline tree, described on pa g e 96 .
PageMode name (Optional) How the document should appear when opened. Allowed values:
UseNone Open document with neither outline nor thumbnails visible. UseOutlines Open document with outline visible. UseThumbs Open document with thumbnails visible. FullScreen Open document in full-screen mode. In full-screen mode, there is no menu bar, window controls, nor any other window present. The default value of PageMode is UseNone .
OpenAction array or dictionary (Optional) If the value of this key is an array, it must be a destination; see pa g e 98 . If it is a dictionary, it must be an action; see pa g e 100 . If this key is omitted, the top of the first page appears at the default zoom level.
Threads array (Required if the document has any threads; must be an indirect reference) An array of threads as described on pa g e 115 .
Dests dictionary (Required in PDF 1.1 if the document has named destinations; must be an indirect reference) A dictionary of names and corresponding destinations; see pa g e 99 .
Names dictionary (Optional) A dictionary object that contains a list of various types of names and strings to be referenced within the document. See pa g e 111 .
URI dictionary (Optional) Contains document-level information for Uniform Resource Identifier annotations; see pa g e 107 .
AA (Additional Actions) dictionary (Optional) An additional-actions dictionary, providing defaults for the entire document. See pa g e 101 .
ViewerPreferences dictionary (Optional) Specifies a dictionary that contains kiosk options for this document; see Ta Ta b le 6.2 . If this key is omitted, viewers behave in accordance with any current user preferences. The name of the key reflects the fact that this dictionary is not part of the document structure itself, but represents a set of viewer-level options for displaying this document. A given viewer implementation may or may not support the options in this dictionary.
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.2
PDF 1.1
PDF 1.2
PDF 1.2
Page 77
November 12, 1996
6: Document Structure 79
The viewer preferences dictionary has the following attributes:
Table 6.2 Viewer Preferences
HideToolbar Boolean (Optional) Specifies that the viewer’s toolbar should be hidden whenever the document is active. This attribute defaults to false .
HideMenubar Boolean (Optional) Specifies that the viewer’s menubar should be hidden whenever the document is active. This attribute defaults to false .
HideWindowUI Boolean (Optional) Specifies that the user interface elements in the document’s window should be hidden. This attribute defaults to false .
FitWindow Boolean (Optional) Specifies that the viewer should resize the window displaying the document to fit the size of the first displayed page of the document. This attribute defaults to false .
CenterWindow Boolean (Optional) Specifies that the viewer should position the window displaying the document in the center of the computer’s monitor. This attribute defaults to false .
PageLayout name (Optional) Specifies the layout for the page when the document is opened. If this attribute is not present, viewers behave in accordance with the current user preference. Allowed values:
SinglePage Display the pages one page at a time.
OneColumn Display the pages in one column.
TwoColumnLeft Display the pages in two columns, with odd-numbered pages on the left.
TwoColumnRight Display the pages in two columns, with odd-numbered pages on the right.
NonFullScreenPageMode name (Optional) Specifies how the document should be displayed after exiting fullscreen mode if the value of the PageMode key in the Catalog is FullScreen . This key is ignored if the value of the PageMode key in the Catalog is not FullScreen . Allowed values and semantics are the same as for the PageMode key in the Catalog, except that a value of FullScreen is not allowed.
6.3 Pages tree
The pages of a document are accessible through a tree of nodes known as the Pages tree. This tree defines the ordering of the pages in the document.
To optimize the performance of viewer applications, the Acrobat Distiller program and Acrobat PDF Writer construct balanced trees. (For further information on balanced trees, see reference [9] in the Bibliography on pa g e 391 .) The tree structure allows applications to quickly open a document containing thousands of pages using only limited memory. Applications should accept any sort of tree
PDF 1.2
Page 78
6: Document Structure November 12, 1996
80 Adobe Systems Inc.
structure as long as the nodes of the tree contain the keys described in Ta Ta b le 6.3 . The simplest structure consists of a single Pages node that references all the page objects directly.
Note The structure of the Pages tree for a document is unrelated to the content of the document. In a PDF file for a book, for example, there is no guarantee that a chapter is represented by a single node in the Pages tree. Applications that consume or produce PDF files are not required to preserve the existing structure of the Pages tree.
The root and all interior nodes of the Pages tree are dictionaries, whose minimum contents are shown in Ta Ta b le 6.3 .
Table 6.3 Pages attributes
Key Type Semantics
Type name (Required) Object type. Always Pages .
Kids array (Required) List of indirect references to the immediate children of this Pages node.
Count integer (Required) Specifies the number of leaf nodes (imageable pages) under this node. The leaf nodes do not have to be immediately below this node in the tree, but can be several levels deeper in the tree.
Parent dictionary (Required; must be indirect reference) Pages object that is the immediate ancestor of this Pages object. The root Pages object has no Parent .
Example 6.2 illustrates the Pages object for a document with three pages, while A ppendix A contains an example showing the Pages tree for a document containing 62 pages.
Example 6.2 Pages tree for a document containing three pages
2 0 obj << /Type /Pages /Kids [4 0 R 10 0 R 24 0 R] /Count 3 >> endobj
6.3.1 Inheritance of attributes
A Pages object may contain additional keys that provide values for Page objects that are its descendants. Such values are said to be “inherited.” For example, a document may specify a MediaBox for all pages by defining one in the root Pages object. An individual page in the document could override the MediaBox in this example by specifying a MediaBox in the Page object for that page.
Page 79
November 12, 1996 6.3.1
6: Document Structure 81
Attributes that may be inherited are indicated in Ta Ta b le 6.4 . If a required key that may be inherited is omitted from a Page object, then a value must be supplied in one of its ancestors. If an optional key that may be inherited is omitted, then a value may be supplied in one of its ancestors; barring that, the default value is used.
Example 6.3 demonstrates inheritance by showing a tree of Pages objects and Page objects. Pages 1, 2, and 4 are rotated 90º. Page 3 is rotated 270º. Pages 5 and 7 are not rotated (rotated 0º). Page 6 is rotated 180º.
6.4 Page objects
A Page object is a dictionary whose keys describe a single page containing text, graphics, and images. A Page object is a leaf of the Pages tree, and has the attributes shown in Ta Ta b le 6.4 .
Table 6.4 Page attributes
Key Type Semantics
Type name (Required) Object type. Always Page .
MediaBox Rectangle (Required; may be inherited) Rectangle specifying the “natural size” of the page, for example the dimensions of an A4 sheet of paper. The coordinates are measured in default user space units.
Parent dictionary (Required; must be indirect reference) The Pages object that is the immediate ancestor of this page.
Pages
page 1
Pages /Rotate 90
Pages Pages /Rotate 180
Pages
Page
Page Page
/Rotate 90
Page Page /Rotate 0
Page
Page /Rotate 270
page 2
page 3 page 4
page 5 page 6 page 7
Example 6.3 Inheritance of attributes
Page 80
6: Document Structure November 12, 1996
82 Adobe Systems Inc.
Resources dictionary (Required; may be inherited) Resources required by this page, described in Cha pter 7 . If the page requires no resources, this value should be an empty dictionary, written as << >> . Omitting this value, or specifying a null value, indicates that the value is to be inherited from an ancestor Pages object.
Contents stream or array (Optional; must be indirect reference) The page description (contents) for this page, described in Cha pter 8 . If Contents is an array of streams, they are concatenated to produce the page description. This allows a program that is creating a PDF file to create image objects and other resources as they occur, even though they interrupt the page description. If Contents is absent, the page is empty.
Note The arrangement of streams in the array is unrelated to the content on the page. Applications that consume or produce PDF files are not required to preserve the existing structure of a Contents array.
CropBox Rectangle (Optional; may be inherited) Rectangle specifying the region of the page displayed and printed.
Rotate integer (Optional; may be inherited) Specifies the number of degrees the page should be rotated clockwise when it is displayed. This value must be zero (the default) or a multiple of 90.
Thumb stream (Optional; must be indirect reference) Object that contains a thumbnail sketch of the page, described in Section 6.5, “T humbnails .”
Annots array (Optional) An array of objects, each representing an annotation on the page, described in Section 6.6, “A “Annota tions .” Omit the Annots key if the page has no annotations.
B (Beads) array (Recommended if the page contains article beads) An array whose elements are indirect references to each article bead on the page, in drawing order (the same order as the Annots array). Articles are described on pa g e 115 .
Dur (Duration) real (Optional; may be inherited) Specifies the “advance timing” (display duration) of a page. By default, the page does not advance automatically. See pa g e 84 .
Hid (Hidden) Boolean (Optional; may be inherited) If true , the page should be hidden (not displayed) during a presentation. The default is false . See pa g e 84 .
Trans (Transition) dictionary (Optional; may be inherited) A Transition dictionary, containing information about transitions between pages. See pa g e 84 .
AA dictionary (Optional; may be inherited) An additional-actions dictionary, providing defaults for the entire page. See pa g e 101 .
Note that some Page attributes may be inherited; see the note, “ Inher itance of a ttr ib utes ,” on pa g e 80 .
0º
270º
180º
90º
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.2
Page 81
November 12, 1996 6.3.1
6: Document Structure 83
Note The intersection between the page’s media box and the crop box is the region of the default user space coordinate system that is viewed or printed. Typically, the crop box is located entirely inside the media box, so that the intersection is the same as the crop box itself.
F igur e 6.2 on pa g e 83 shows the distinction between the media box and the crop box. In the figure, the crop box has been sized so that the crop marks do not appear when the page is viewed or printed.
Example 6.4 on pa g e 83 shows a Page object with a thumbnail and two annotations. In addition, the Resources dictionary is specified as a direct object, and shows that the page makes use of three fonts, with the names F3, F5, and F7.
TIME PHOTONS FROM LIQUID RADIATOR CHARGE DIVISION THIRD COORDINATE READOUT
WIRE ADDRESS
CATHODE ANODE WIRE PLANE
PHOTONS FROM GAS RADIATOR
e –
Figure 2.6 TPC and detector for barrel CRID. The drift space inside each TPC is 1.268 m long, 30.7 cm wide, and the thickness tapers from 9.2 cm to 5.6 cm. Forty TPCs will be used in the CRID, arranged as twenty in each end of the barrel. The TPC's are filled with a gas mixture that is transparent to ultraviolet photons, has good electron lifetime, has a pulse height spectrum with a peak clearly separated from the noise, and includes a component which efficiently converts photons to single photoelectrons. Good electron lifetime is necessary to minimize losses as single electrons drift up to 1.3 m in the TPC. Pure ethane has been chosen for the TPC gas, with Tetrakis 15
Crop box (region displayed and printed)
Media box (size of page)
Fi gure 6 . 2 Page o bj bject’s me d ia b ox an d crop b ox
Example 6.4 Page with thumbnail, annotations, and Resources dictionary
3 0 obj << /Type /Page /Parent 4 0 R /MediaBox [0 0 612 792] /Resources << /Font << /F3 7 0 R /F5 9 0 R /F7 11 0 R >> /ProcSet [/PDF] >> /Thumb 12 0 R /Contents 14 0 R /Annots [23 0 R 24 0 R] >> endobj
Page 82
6: Document Structure November 12, 1996
84 Adobe Systems Inc.
6.4.1 Presentation mode
A Page dictionary may contain three keys, Dur , Hid , and Trans , that provide information that is intended to be used when displaying a PDF document as a “presentation” or “slide show” and are otherwise ignored. A PDF viewer is not required to provide a presentation mode. If such a mode is provided by the viewer or a plug-in, however, then these keys define its behavior.
6.4.1.1 Duration
The Dur key in a Page dictionary specifies the advance timing of the page. The advance timing is intended to be used only when a presentation is being played in a non-interactive mode. It describes the maximum amount of time the page is displayed before the viewer automatically turns to the next page; the user can advance the page manually before the time is up. If no Dur key is specified for a Page object or any of its Pages ancestors, the page does not advance automatically.
The advance timing is defined as the amount of time between the end of the last transition and the beginning of the next one, as shown in the time-line below:
6.4.1.2 Hidden
The Hid (Hidden) key in a Page dictionary specifies that the page is not to be displayed during the presentation. If the user attempts to turn to a hidden page from the previous or following page during a presentation, the page is skipped and the next visible page is displayed. If the page is the destination of a link or thread, the Hidden attribute is ignored and the page is displayed.
The Hidden attribute of a page hides the page only during a presentation; other aspects of the user interface ignore the Hidden attribute.
6.4.1.3 Transition
The Trans key in a Page dictionary specifies a Transition dictionary, which describes the effect to use when going to that page, and the amount of time the transition should take. For example, a transition effect in the Transition dictionary of page two executes whenever the user goes to page two, regardless of the previous page. Ta Ta b le 6.5 defines keys for all Transition dictionaries; they may contain additional keys that control specific transition effects.
PDF 1.1
Transition from page 1 to page 2
Transition from Page 2 is displayed page 2 to page 3
Transition duration Advance timing Transition duration
Page 83
November 12, 1996 6.4.1
6: Document Structure 85
Table 6.5 Transition attributes
Key Type Semantics
Type name (Optional) Object type. Always Trans .
S (Subtype) name (Optional) Describes the transition effect. If this key is omitted, there is no transition effect to that page (the page is displayed normally), and the D key in the Transition dictionary is ignored. Transition effects are described in the following section.
D (Duration) real (Optional) The duration (in seconds) of the transition effect. The default duration is 1 second.
6.4.1.4 Transition effects
All implementations of presentation mode support the transition effects shown in Ta Ta b le 6.6 . Some of these effects include optional parameters that control the appearance of the effect. The parameters are described in Ta Ta b le 6.7 .
Table 6.6 Transition Effects
Effect Parameters Description
Split Dm , M Two lines sweep across the screen revealing the new page image. The lines can be either horizontal or vertical, as determined by the Dm key, and can move from the center out or from the edges in as determined by the M key.
Blinds Dm Multiple lines, evenly distributed across the screen, appear and synchronously sweep in the same direction to reveal the new page. The lines are either horizontal or vertical, as determined by the Dm key. Horizontal lines move down; vertical lines move to the right.
Box M A box sweeps from the center out or from the edges inward, as determined by the M key, revealing the new page image.
Wipe Di A single line sweeps across the screen from one edge to the other, revealing the new page image. Possible values for Di include 0, 90, 180, and 270.
Dissolve (none) The old page image “dissolves” in a piecemeal fashion to reveal the new page.
Glitter Di Similar to Dissolve , except the effect sweeps across the image in a wide band moving from one side of the screen to the other. Supported directions are 0, 270, and 315.
R (none) (Replace) The effect is simply to replace the old page with the new page; i.e., there is no “transition” per se. This is the default effect if the S key is omitted from the transition dictionary, but it may be explicitly specified as a way to override any default transition that may be used for full-screen mode.
Page 84
6: Document Structure November 12, 1996
86 Adobe Systems Inc.
Table 6.7 Effect parameters
Key Type Semantics
Di (Direction) real The direction of movement, specified in degrees, increasing in a counterclockwise direction. A value of 0 points to the right, indicating that the effect proceeds from left to right. A value of 90 points upward, indicating that the effect moves from bottom to top.
Note This is different from the page rotation, where the degrees increase in a clockwise direction.
Dm (Dimension) name For those effects which can be performed either horizontally or vertically, the Dm key specifies which dimension to use. Possible values are H (horizontal) or V (vertical).
M (Motion) name For those effects which can be performed either from the center out or the edges in, the M key specifies which direction to use. Possible values are I (In) or O (Out).
Example 6.5 shows a page that, in presentation mode, would be displayed for 5 seconds before advancing to the following page. Before the page is displayed, there is a 3-second transition in which two vertical lines sweep across the screen, from the center outwards.
Example 6.5 A page with information for presentation mode
<< /Type /Page /Parent 4 0 R /Contents 16 0 R /Dur 5 /Trans << /S /Split /D 3.0 /M /O /Dm /V >> >>
6.5 Thumbnails
A PDF document may include thumbnail sketches of its pages. They are not required, and even if some pages have them, others may not.
The thumbnail image for a page is the value of the Thumb key of the page object. The structure of a thumbnail is very similar to that of an Image resource (see Section 7.10.1 on pa g e 178 ). The only difference between a thumbnail and an Image resource is that a thumbnail does not include Type , Subtype , and Name keys.
Note Different pages in a document may have thumbnails with different numbers of bits per color component.
0º
90º
180º
270º
Page 85
November 12, 1996 6.4.1
6: Document Structure 87
Example 6.6 Thumbnail
12 0 obj << /Filter [/ASCII85Decode /DCTDecode] /Width 76 /Height 99 /BitsPerComponent 8 /ColorSpace /DeviceRGB /Length 13 0 R >> stream s4IA>!"M;*Ddm8XA,lT0!!3,S!/(=R!<E3%!<N<(!WrK*!WrN,! … image data omitted … endstream endobj 13 0 obj 4298 endobj
6.6 Annotations
Annotations are notes or other objects that are associated with a page but are separate from the page description itself. PDF supports several kinds of annotations:
• Text notes (see pa g e 92 )
• Hypertext links ( pa g e 93 )
• Movies ( pa g e 93 )
• Sounds ( pa g e 96 )
In the future, PDF may support additional types.
If a page includes annotations, they are stored in an array as the value of the Annots key of the Page object. Each annotation is a dictionary. As shown in Ta Ta b le 6.8 , all annotations must provide a core set of keys, including Type , Subtype , and Rect . Certain other keys, indicating an annotation’s color, title, modification date, border, and other information, are also defined for all annotations but are optional.
Note All coordinates and measurements in text annotations, link annotations, and outline entries are specified in default user space units.
As an alternative to the simple border and color characteristics defined in PDF 1.0 and 1.1, Annotations in PDF 1.2 can have one or more appearances attached to them. An appearance is a PDF Form XObject that is rendered inside the annotation bounding box.
Page 86
6: Document Structure November 12, 1996
88 Adobe Systems Inc.
Table 6.8 Annotation attributes (common to all annotations)
Key Type Semantics
Type name ( Required in PDF 1.0, optional otherwise) Object type. Always Annot .
Subtype name (Required) Annotation subtype.
Rect Rectangle (Required) Rectangle specifying the location of the annotation.
Border array (Optional) In PDF 1.0, this is an array of three numbers, specifying the horizontal corner radius, the vertical corner radius, and the width of the border of the annotation. The default values are 0, 0, and 1, respectively. No border is drawn if the width is 0.
The array may have a fourth element, a dash array that allows specification of solid and dashed borders. The dash array contains “on” and “off” stroke-lengths for drawing dashes, in the same format as the setdash marking operator, d (see pa g e 219 ). An example of a border with a dash array is [0 0 1 [3]] .
Note This key has been superseded in PDF 1.2 with the BS key, described below.
C (Color) array (Optional) The annotation color. For links, this is the border color. For text annotations, it is the background color of a closed annotation’s icon, the title bar color of an active open annotation’s window, and the window frame color of an inactive open annotation. A color is specified as an array of three numbers in the range 0 to 1, representing a color in DeviceRGB space.
T (Title) string (Optional) An arbitrary text label associated with the annotation. It is displayed in an active open text annotation’s title bar and can be edited from the annotation’s properties dialog. The characters in this string are encoded using the predefined encoding PDFDocEncoding , described in A ppendix C .
M (ModDate) string (Optional) The last time an annotation was modified. A text annotation’s modification date is updated each time the text is changed. The preferred string value is the date format described on pa g e 46 , but viewers should accept and display any string.
F (Flags) integer (Optional) Flags. The binary value of the integer is interpreted as a collection of flags that define various characteristics of the annotation. All undefined bits are reserved and must be set to 0. The default value for this key is 0.
Note Bit-positions are numbered starting at 1, which is the least significant bit.
bit 1 The Invisible flag specifies how an annotation is displayed when the corresponding annotation handler is not available. If this flag’s value is 1, and the viewer does not provide a handler for the annotation’s Subtype, the annotation is not displayed. If this flag’s value is 0, and the viewer does not provide a handler for the annotation’s Subtype, the annotation appears as an unknown annotation.
bit 2 The Hidden flag determines whether the annotation is currently shown. If the value of this flag is 1 then the annotation is hidden, in which case, there is no user interaction, display, or printing of the annotation. The ability to hide and show
PDF 1.0
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.2
Page 87
November 12, 1996 6.6.1
6: Document Structure 89
annotations selectively, combined with appearances (see the AP key), is especially useful in cases where screen real estate is limited. They can then be used to display pop-up auxiliary data similar in function to online help systems.
bit 3 The Print flag indicates whether the annotation should be printed. If the value of this flag is 1 then the annotation is printed. Corresponding to the definition of appearances for annotations, there may be some instances where the author of a document wishes to create an annotation for display purposes only. That is, the annotation should display its appearance while in the viewer but that appearance should not print. This is typical for annotations that act like push buttons whose presence on the printed page would be distracting.
H (Highlight) name (Optional) In PDF 1.1, the visual effect of clicking on a link annotation produced an inversion of the colors inside the bounding box of the annotation. In PDF 1.2, additional highlight modes, specified by this key, ave been added for both Link and Widget annotations, as described in Ta Ta b le 6.10 . The default for this key is I (Invert).
BS (Border Style) dict (Optional) This key overrides the Border key. The value of this key is a dictionary, defined on pa g e 89 , that specifies several attributes related to the border of the annotation.
AP dictionary (Optional) Appearance dictionary. Specifies that one or more appearances are available for this annotation. See pa g e 91 .
AS name (Required if more than one appearance is possible) Appearance state. If the N , R , or D keys in the AP dictionary are dictionaries instead of Form XObjects, then this key indicates which entry in the dictionary is to be used in each instance. This allows for the specification of items such as checkboxes and radio buttons whose appearance may change.
6.6.1 Annotation borders
The border is drawn completely inside the annotation’s bounding box. If neither the BS key nor the Border key is present in the annotation dictionary, the border style is drawn as a solid line with a width of one point.
Table 6.9 Border Style attributes
Key Type Semantics
Type name (Optional) Object type. Always Border .
S (Subtype) name (Optional) One of the following names:
S (Solid) The border is drawn as a solid line. This is the default subtype.
D (Dashed) The border is drawn with a dashed line. The dash pattern is specified by the D attribute.
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
Page 88
6: Document Structure November 12, 1996
90 Adobe Systems Inc.
B (Beveled) The border is drawn in a beveled style (faux three-dimensional) such that it looks as if it is pushed out of the page (opposite of Inset).
I (Inset) The border is drawn in an inset style (faux three-dimensional) such that it looks as if it is inset into the page (opposite of Beveled).
U (Underlined) The border is drawn as a line on the bottom of the annotation rectangle.
Other subtypes may be defined in the future.
W (Width) real (Optional) The border width in points. The default is 1 point.
D (Dash array) array (Optional) If the Subtype key is D , this array contains numbers representing on and off stroke lengths for drawing dashes, in the same format as the setdash marking operator, d . The default for this key is [3].
6.6.2 Annotation highlighting
An annotation is highlighted when any of the following events is triggered.
1. If the user clicks the mouse button down inside the active area of the annotation, the highlight is shown.
2. If the mouse button is down and the user moves the cursor out of the active area of the annotation, the highlight is removed.
3. If the mouse button is down and the user moves the cursor back into the active area of the annotation, the highlight is shown.
4. If the mouse button is released then the highlight is removed.
A highlight is removed by reverting the visual appearance of the document back to what it was before the highlight occurred.
Table 6.10 Highlight Modes
Name Semantics
I (Invert) The rectangle specified by the bounding box of the annotation is inverted.
N (None) No highlighting is done.
O (Outline) The border of the annotation is inverted. If no active color is defined, the border is inverted.
P (Push) If the annotation specifies a Down appearance (i.e., if the Appearance dictionary defines a D key), that appearance is drawn. If the annotation does not specify a Down appearance then the region underneath the bounding box of the annotation is drawn inset into the page.
PDF 1.2
Page 89
November 12, 1996 6.6.3
6: Document Structure 91
The use of the highlighting works in conjunction with the Down sub-appearance specified in the annotation appearance dictionary (if any) in the following manner: If the highlight value is not P (push), then the specified highlight mode is respected regardless of the fact that a down sub-appearance exists.
Note The active behavior of highlighting is applicable only to annotations whose annotation handler is present. The highlighting behavior is logically the responsibility of the handler. Plug-in designers are encouraged to use the same PDF extensions for specifying highlighting for their annotations.
6.6.3 Annotation appearances
The appearance dictionary defines the following three keys.
Table 6.11 Appearance dictionary
Key Type Semantics
N dictionary or stream (Required) Normal appearance. This is the appearance that is used when the annotation is in a normal state, that is, when the user is not interacting with the annotation. This is also the appearance that is used when printing the annotation.
R dictionary or stream (Optional) Rollover appearance. This is the appearance that is used when the user moves the mouse cursor inside the annotation. If the cursor leaves the annotation then the Normal appearance is re-displayed. The default is that no alternative appearance is displayed when the rollover occurs.
D dictionary or stream (Optional) Down appearance. This is the appearance that is used when the user clicks the mouse down inside the annotation. When the user releases the mouse, the viewer displays the Rollover appearance if that is defined, or the Normal appearance otherwise. The default is that no alternative appearance is displayed when the mouse-down event occurs.
If the N , R , or D values are dictionaries, then they contain one or more subappearances. The appearance state ( AS ) key in the annotation dictionary determines which sub-appearance to use as the current appearance.
Consider a checkbox with two states: checked and unchecked. The appearance dictionary, containing only a normal appearance ( N ), would look like this:
/AP << /N << /Checked Form XObject /Unchecked Form XObject >> >>
The appearance state key would determine which appearance is the current normal appearance, For example, if the checkbox were currently checked, the value of the AS key would be the name Checked .
PDF 1.2
Page 90
6: Document Structure November 12, 1996
92 Adobe Systems Inc.
/AS /Checked
If the N , R , or D values are not dictionaries, then they must be Form XObjects (see pa g e 182 ), which are represented as streams, and the appearance does not depend on the AS key.
The Form XObject’s graphics state when rendering the appearance should have the origin translated to the lower left corner of the annotation bounding box and scaled to fit inside and clipped to the annotation bounding box. All other graphics state values are set to their defaults.
Some annotation subtypes defined in PDF (e.g., Movie) and all annotation subtypes defined by third parties are implemented through plug-ins. If the plug-in that implements a particular annotation subtype is not available, the viewer displays that annotation’s Normal appearance.
Note The viewer should attempt to provide reasonable behavior (e.g. display nothing) if the sub-appearance named by the AS key is not present in the N , R , or D dictionaries.
6.6.4 Text annotations
A text annotation contains a string of text. When the annotation is open, the text is displayed. A PDF viewer application chooses the size and typeface of the text. Ta Ta b le 6.12 shows the contents of the text annotation dictionary. Example 6.7 shows a text annotation.
Table 6.12 Text annotation attributes (in addition to those in Ta Table 6.8 )
Key Type Semantics
Subtype name (Required) Annotation subtype. Always Text .
Contents string (Required) The text to be displayed. Text can be separated into paragraphs using carriage returns. The characters in this string are encoded using the predefined encoding PDFDocEncoding , described in A ppendix C .
Open Boolean (Optional) If true , specifies that the annotation should initially be displayed opened. The default is false (closed).
Example 6.7 Text annotation
22 0 obj << /Type /Annot /Subtype /Text /Rect [266 116 430 204] /Contents (text for two) >> endobj
Page 91
November 12, 1996 6.6.5
6: Document Structure 93
6.6.5 Link annotations
A link annotation, when activated, displays a destination or performs an action . A destination is a view of another location, possibly on a different page, with a different zoom factor, or in a different file. Ta Ta b le 6.13 shows the contents of the link annotation dictionary.
Table 6.13 Link annotation attributes (in addition to those in Ta Table 6.8 )
Key Type Semantics
Subtype name (Required) Annotation subtype. Always Link .
Dest array or name (Required unless the A key is present) The view to go to, represented as a destination. See pa g e 98 .
A (Action) dictionary (Required unless the Dest key is present) The action to be performed on activating this link annotation. See pa g e 100 .
Example 6.8 Link annotation
93 0 obj << /Type /Annot /Subtype /Link /Rect [71 717 190 734] /Border [16 16 1] /Dest [3 0 R /FitR –4 399 199 533] >> endobj
6.6.6 Movie Player annotations
A Movie Player annotation describes the static display and playing of movies and sounds within PDF documents. These annotations appear to be embedded in the document, like links. The activation area may be invisible, bordered in the manner of a link button, and it may have the movie’s Poster frame displayed. There are several authoring options that control the way a movie is to be displayed and played.
Table 6.14 Movie Player annotation attributes (in addition to those in Ta Table 6.8 )
Key Type Semantics
Subtype name (Required) Annotation subtype. Always Movie .
Movie dictionary (Required) A description of the static characteristics of the Movie; see Ta Ta b le 6.15 .
A (Activation) Boolean (Optional) A flag that indicates whether the movie should be shown by clicking in the annotation rectangle. Possible values are:
PDF 1.1
PDF 1.2
Page 92
6: Document Structure November 12, 1996
94 Adobe Systems Inc.
false Do not play the movie when clicked. true Play the movie with the default activation values. (This is the default value for the A key.) or
dictionary (Optional) Directions for playing the Movie; see Ta Ta b le 6.16 .
The Movie dictionary contains information needed to locate the movie data and to display the poster (if requested) in the annotation rectangle:
Table 6.15 Movie dictionary attributes
Key Type Semantics
F (File) F ile specifi ca tion (Required) A self-describing movie file.
Note The format of a “self-describing movie file” is left unspecified, and there is no guarantee of portability.
Aspect array (Optional) If the movie is visible, the horizontal and vertical sizes of the movie’s bounding box in pixels: [ horiz vert ]. An “invisible movie” is one with no video: it has only sound.
Rotate integer (Optional) Specifies the number of degrees clockwise the movie must be rotated, relative to the rotation of the page. This value must be a multiple of 90. The default is 0.
Poster Boolean (Optional) A flag indicating whether the poster is to be retrieved from the movie file for display. Possible values are: false Do not show a poster image. (This is the default if the Poster key is omitted.) true Show the poster image from the movie file. or
stream (Optional) An Image resource (see Section 7.10.1 on pa g e 178 ) that is to be displayed as the poster.
The Movie Activation dictionary contains information needed to control the dynamics of playing the movie:
Table 6.16 Movie Activation attributes
Key Type Semantics
ShowControls Boolean (Optional) If this key is true , a Movie Controller bar is shown when the movie is being played. The default is false .
Mode name (Optional) The playing mode for the movie. Currently defined values are:
Once Show the movie once and stop.
90º
0º
270º
180º
Page 93
November 12, 1996 6.6.6
6: Document Structure 95
Open Show the movie and leave the controller open. Repeat Repeat the movie from the beginning until stopped. Palindrome Play the movie back and forth until stopped.
If Mode is omitted or unrecognized, the mode is Once .
Synchronous Boolean (Optional) If this key is true , the player does not return to Acrobat until the movie is completed or dismissed by the user. The default is false .
Start number, string, or array (Optional) The starting time of the movie segment to play. If omitted, the movie is played from the beginning.
Movie time values are based on 64-bit integers. If the start time is representable in 32 bits, the key value should be an integer. If not, the key value should be an 8-byte string, with the most significant byte of the value first, that is treated as a 64-bit integer. If the time scale for the starting time is not the same as the Movie time scale, the start time is represented as an array of two values: the first element is the time value (integer or string), and the second element is the time scale (integer). The time scale is measured in events per second.
Duration number, string, or array (Optional) The duration of the movie segment to play. If omitted, the movie is played to the end.
Movie time values are based on 64-bit integers. If the duration is representable in 32 bits, the key value should be an integer. If not, the key value should be an 8-byte string, with the most significant byte of the value first, that is treated as a 64-bit integer. If the time scale for the duration is not the same as the Movie time scale, the duration is represented as an array of two values: the first element is the time value (integer or string), and the second element is the time scale (integer). The time scale is measured in events per second. A negative duration means the movie is to be played backwards.
Rate number (Optional) The initial speed at which the movie is played. The default speed is 1.0. A negative speed means the movie is to be played backwards with respect to Start and Duration .
Volume number (Optional) The initial volume setting for the movie. This number must be between -1 and 1. Negative settings are muted. The default volume is 1.
FWScale array (Optional) For floating play windows, the magnification at which to play the movie. FWScale is an array of two integers: [ numerator denominator] r] representing a rational magnification factor for the movie. The final window size for the movie is ( numerator ÷ denominator) r) × Aspect pixels . The presence of the FWScale key implies that the movie is to be played in a floating window. The absence of the FWScale key implies that the movie is to be played in the annotation rectangle.
Page 94
6: Document Structure November 12, 1996
96 Adobe Systems Inc.
FWPosition array (Optional) For floating play windows, the position within the screen at which to play the movie. FWPosition is an array of two numbers: [ horizontal vertical] l] representing a relative position of the movie window with respect to the left and top of the screen. Each number must br in the range 0 to 1, with [0.5 0.5] meaning “center the movie window on the screen.”
6.6.7 Sound annotations
A Sound annotation is analogous to a Text annotation, except that it contains sound, recorded from the computer's microphone or imported from a file. The annotation behaves like a Text annotation in most ways, with a different icon (a speaker) to indicate that it is a Sound annotation.
Table 6.17 Sound annotation attributes (in addition to those in Ta Table 6.8 )
Key Type Semantics
Subtype name (Required) Annotation subtype. Always Sound .
Sound stream or F ile specifi ca tion (Required) A Sound object (stream) or an external sound file (file specification). See Section 6.16 on pa g e 135 .
6.7 Outline tree
An outline allows a user to access views of a document by name. As with a link annotation, activation of an outline entry (also called a bookmark ) brings up a new view based on the destination description. Outline entries form a hierarchy of elements. An entry may be one of several at the same level in the outline, it may be a sub-entry of another entry, and it may have its own set of child entries. An outline entry may be open or closed . If it is open, its immediate children are visible when the outline is displayed. If it is closed, they are not.
If a document includes an outline, it is accessed from the Outlines key in the Catalog object. The value of this key is the Outlines object, which is the root of the outline tree. The contents of the Outlines dictionary appear in Ta Ta b le 6.18 and Example 6.9 . The top-level outline entries are contained in a linked list, with First pointing to the head of the list and Last pointing to the tail of the list. When displayed, outline entries appear in the order in which they occur in the linked list.
Table 6.18 Outlines attributes
Key Type Semantics
Count integer ( Required if document has any open outline entries, otherwise optional ) Total number of open entries in the outline. This includes the total number of items open at all outline levels, not just top-level outline entries. If the count is zero, this key should be omitted.
PDF 1.2
Page 95
November 12, 1996 6.6.7
6: Document Structure 97
First dictionary ( Required if document has any outline entries; must be indirect reference ) Reference to the outline entry that is the head of the linked list of top-level outline entries.
Last dictionary ( Required if document has any outline entries; must be indirect reference ) Reference to the outline entry that is the tail of the linked list of top-level outline entries.
Example 6.9 Outlines object with six open entries
21 0 obj << /Count 6 /First 22 0 R /Last 29 0 R >> endobj
Each outline entry is a dictionary, whose contents are shown in Ta Ta b le 6.19 .
Table 6.19 Outline entry attributes
Key Type Semantics
Title string (Required) The text that appears in the outline for this entry. The characters in this string are encoded using the predefined encoding PDFDocEncoding , described in A ppendix C .
Dest array or name (Required unless the A key is present) A destination, as described on pa g e 98 .
A (Action) dictionary (Required unless the Dest key is present) The action to be performed when this link annotation is activated; see pa g e 100 .
AA (Additional Actions) dictionary (Optional; may be inherited) See pa g e 101 .
Parent dictionary (Required; must be indirect reference) Specifies the entry for which the current entry is a sub-entry. The parent of the top-level entries is the Outlines object.
Prev dictionary (Required if the entry is not the first of several entries at the same outline level; must be indirect reference) Specifies the previous entry in the linked list of outline entries at this level.
Next dictionary (Required if the entry is not the last of several entries at the same outline level; must be indirect reference) Specifies the next entry in the linked list of outline entries at this level.
First dictionary (Required if an entry has sub-entries; must be indirect reference) Specifies the outline entry that is the head of the linked list of sub-entries of this outline item.
PDF 1.1
Page 96
6: Document Structure November 12, 1996
98 Adobe Systems Inc.
Last dictionary (Required if an entry has sub-entries; must be indirect reference) Specifies the outline entry that is the tail of the linked list of sub-entries of this outline item.
Count integer (Required if an entry has sub-entries) If positive, specifies the number of open descendants the entry has. This includes not just immediate sub-entries, but subentries of those entries, and so on. If the value is negative, the entry is closed, and the absolute value of Count specifies how many entries would appear if the entry were reopened. If an entry has no descendants, the Count key is omitted.
Example 6.10 shows an outline entry. An example of a complete outline tree can be found in A ppendix A .
Example 6.10 Outline entry
22 0 obj << /Parent 21 0 R /Dest [3 0 R /Top 0 792 0] /Title (Document) /Next 29 0 R /First 25 0 R /Last 28 0 R /Count 4 >> endobj
6.8 Destinations
An annotation or Outline entry may specify a destination , which consists of a page, the location of the display window on that page, and the zoom factor to use when displaying that page.
A destination may be represented explicitly as an array, or implicitly through a name; see pa g e 99 .
6.8.1 Explicit destinations
Ta Ta b le 6.20 shows the allowed forms of the destination. In the table, top, p, left, t, right, t, and bottom are numbers specified in the default user space coordinate system. page is an indirect reference to the destination Page object, except in the case of the GoToR action, where it is a page number. The page’s bounding box is the smallest rectangle enclosing all objects on the page. No side of the bounding box is permitted to be outside the page’s crop box. If it is, that side of the bounding box is defined by the corresponding side of the crop box.
Page 97
November 12, 1996 6.8.2
6: Document Structure 99
Table 6.20 Destination specification
Value of Dest key Semantics
[ page /XYZ left top zoom ] If left, t, top, p, or zoom is null, the current value of that parameter is retained. For example, a destination of [4 0 R null null null] specifies the page object with an object ID of 4, retaining the same top, p, left, t, and zoom as the current page. A zoom of 0 has the same meaning as a zoom of null.
[ page /Fit ] Fit the page to the window.
[ page /FitH top ] Fit the width of the page to the window. top specifies the y -coordinate of the top edge of the window.
[ page /FitV left ] Fit the height of the page to the window. left specifies the x -coordinate of the left edge of the window.
[ page /FitR left bottom right top ] Fit the rectangle specified by left bottom right top in the window. If the height ( top − bottom) m) and width ( right − left) t) imply different zoom factors, the numerically smaller zoom factor is used, to ensure that the specified rectangle fits in the window.
[ page /FitB ] Fit the page’s bounding box to the window.
[ page /FitBH top ] Fit the width of the page’s bounding box to the window. top specifies the y coordinate of the top edge of the window.
[ page /FitBV left ] Fit the height of the page’s bounding box to the window. left specifies the x coordinate of the left edge of the window.
6.8.2 Named destinations
A destination may be represented implicitly, using a string or a name . Both of these cases are referred to as “named destinations.” These are especially useful when the destination is in another file. For example, one file may contain a link to the first page of Chapter 6 in another file. If the link uses a name such as
/Chap6.begin
rather than an explicit location, such as a certain rectangle on page 42, then the place where Chapter 6 starts can change without invalidating the link.
The mapping from strings to destinations is a feature of PDF 1.2. The Catalog of any document may contain a Names key whose value is a dictionary. Each value in this dictionary is a tree, similar to the Pages tree. The leaf-nodes in each such tree contain pairs of strings and indirect objects. The Dests entry in this dictionary is a tree where the indirect objects are destinations. The structure of this tree is described in Section 6.10, “Name tr ees .”
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.1
PDF 1.2
Page 98
6: Document Structure November 12, 1996
100 Adobe Systems Inc.
The mapping from names to destinations is a feature of PDF 1.1, and it is supported in PDF 1.2 for backwards compatibility. The Catalog of any document may contain a Dests key. Each key in this dictionary is a name, and the corresponding value is either a destination or a dictionary. If it is a dictionary, it must have a D key whose value is a destination. (The dictionary enables named destinations to have additional attributes.)
Note There are several performance advantages to using strings instead of names for named destinations. See page 277. 7.
If an annotation or Outline entry that contains a named destination also includes a file specification ( F key), then the destination is in the specified file. Otherwise, if there is no F key, the destination is in the current file.
6.9 Actions
Beginning in PDF 1.1, it is possible to specify an action to be performed when a Link annotation or Outline entry is activated, or when a document is opened. PDF defines several subtypes of actions:
Table 6.21 Types of actions
Action type Description
GoTo Change the current page view to a specified page and zoom factor. See pa g e 103 .
GoToR (“GoTo Remote”) Open another PDF file at a specified page and zoom factor. See pa g e 104
Launch Launch an application, usually to open a file. See pa g e 104 .
Thread Begin reading an article thread. See pa g e 115 .
URI Resolve the specified Uniform Resource Identifier (URI). See pa g e 106 .
Sound Play a sound. See pa g e 108 .
Movie Play a movie. See pa g e 108
SetState Store a value in the appearance-state ( AS key) of an annotation’s appearance dictionary. See pa g e 91 .
Hide Set or clear the Hidden flag for an annotation. See pa g e 110 .
Named actions Execute an action predefined by the viewer. See pa g e 110 .
SubmitForm Send data to a URL. See pa g e 133 .
ResetForm Set field values to their defaults. See pa g e 134 .
ImportData Import field values from a file. See pa g e 134
PDF 1.1
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
PDF 1.2
Page 99
November 12, 1996 6.9.1
6: Document Structure 101
Note It is intended that plug-in extensions may add new actions, as described in Appendix G .
An action is represented as a dictionary. Every action must contain an S (Subtype) key. Other keys may be present, depending on the action type.
Table 6.22 Action attributes (common to all actions)
Key Type Semantics
Type name (Optional) Object type. Always Action .
S (Subtype) name (Required) Action subtype.
Next dictionary or array (Optional) The action, or sequence of actions, to be performed after the current action.
In PDF 1.1, only single actions can be triggered as the result of a user action. PDF 1.2 allows actions to be chained together to provide a richer action model. For example, if a user clicks on a particular link, it might play a sound, then go to a new page, and then start up a movie.
The value of the Next key is either an action or an array of actions, each of which may in turn contain a Next key. Note that this data structure allows the expression of the actions as a tree. Actions are executed in the following order:
1. The current action is performed.
2. If the current action has a Next key whose value is an action, that action is executed.
3. If the current action has a Next key whose value is an array of actions, then each action in the array is executed, in order.
The application should attempt to provide reasonable behavior in extreme situations: actions that are self-referential should not be subsequently executed; actions that close the document or otherwise render the execution of the next action impossible should terminate the execution of the action tree. The application should ensure that a sequence of actions is interruptible by the user.
Note During its execution, an action should not modify its dictionary or the action tree in which it resides. The effect of such modification on subsequent execution of actions in the tree is undefined.
6.9.1 Action Trigger Points
In PDF 1.1, the presence of an A key or Dest key in an annotation or Outline entry denotes an action that is to be performed when the mouse button is released after clicking inside the annotation or Outline entry. PDF 1.2 provides a more general mechanism by defining other “trigger points” (events) and associating actions with
PDF 1.2
PDF 1.2
Page 100
6: Document Structure November 12, 1996
102 Adobe Systems Inc.
each one by means of an “additional actions” dictionary, which is included in an annotation or Outline entry as the value of the AA key. AA keys are also permitted in Page objects and in a document’s Catalog.
Note The term “mouse” is used to represent a generic pointing device available for use inside a viewing application. It is assumed that the pointing device has the following characteristics:
• A selection button that may be activated, held, and released. This is often the (left) mouse button.
• A notion of location, that is, an indication of where the device is pointing. In many systems, this is usually denoted by the cursor.
• A notion of focus, that is, which element in the document is currently interacting with the user. In many systems, this is usually denoted by a blinking caret, a focus rectangle, or a color change.
The viewing application and any accessibility programs must ensure that a mapping exists into this environment in order for these action to be executed correctly.
Table 6.23 Additional Actions attributes
Key Type Semantics
E (Enter) dictionary (Optional) The action that is executed when the cursor enters the activation area.
X (Exit) dictionary (Optional) The action that is executed when the cursor exits the activation area.
D (Down) dictionary (Optional) The action that is executed when the user depresses the mouse button inside the activation area.
U (Up) dictionary (Optional) The action that is executed when the user releases the mouse button inside the activation area. For backwards compatibility, the A key in an annotation dictionary takes precedence over the U key in this dictionary.
O (Open) dictionary (Optional. Defined only for Page objects.) The action that is executed after the page has finished being drawn. This is independent of any OpenAction that may be defined in the Catalog (see Ta Ta b le 6.1 on pa g e 78 ), and would be executed after such an action.
C (Close) dictionary (Optional. Defined only for Page objects.) The action that is executed when the page is no longer being displayed (e.g., when the user goes to the next page or follows a link). This action applies to the page being closed, and it executed before any other page is opened.
FP (first page) dictionary (Optional) The action that is executed when the user goes to the first page of the document.
PP (prev. page) dictionary (Optional) The action that is executed when the user goes to the previous page of the document.
Page 101
November 12, 1996 6.9.2
6: Document Structure 103
NP (next page) dictionary (Optrional) The action that is executed when the user goes to the next page of the document.
LP (last page) dictionary (Optional) The action that is executed when the user goes to the last page of the document.
Trigger points for mouse-events are defined with the following constraints:
• An Enter event cannot occur unless the mouse button is already up.
• An Up event cannot occur without an Enter event and a Down event occurring.
• An Exit cannot occur without an Enter occurring.
• In the case of overlapping or nested annotations, entering a second annotation’s activation area causes an Exit of the first annotation’s area to occur.
Annotations inherit trigger points ( AA dictionaries) from the pages on which they appear and from the document. That is, if an annotation does not define actions for the E , X , D , or U keys, the definitions for the Page object, if any, are used; failing that, the definitions in the Catalog are used. An exception is made for the U key if the annotation has an A key, which takes precedence.
Likewise, pages and outline entries inherit trigger points from the document. That is, if a Page or Outline object does not define actions for the O or C keys, the definitions in the Catalog, if any, are used.
Inheritance of trigger points enables an author to define actions that apply to large groups of annotations.
Note The Enter and Exit triggers are determined by the annotation’s handler and may not correspond to the annotation’s bounding box. Annotation handlers can implement non-rectangular activation regions.
6.9.2 GoTo action
A GoTo action has the same effect as specifying a destination (with a Dest key) in a Link annotation, but it is less compact and is not compatible with PDF 1.0. Destinations are preferred over GoTo actions.
Table 6.24 GoTo action attributes (in addition to those in Ta Table 6.22 )
Key Type Semantics
S (Subtype) name (Required) Action type. Always GoTo .
D (Dest) array, string, or name (Required) The destination, as described in Ta Ta b le 6.20 on pa g e 99 .
Page 102
6: Document Structure November 12, 1996
104 Adobe Systems Inc.
Example 6.11 GoTo action
42 obj << /Type /Annot /Subtype /Link /Rect [71 717 190 734] /Border [16 16 1] /A << /Type /Action /S /GoTo /D [3 0 R /FitR –4 399 199 533] >> >> endobj
Note This example has the same effect as the Link annotation shown in Example 6.8 on page 93 , which uses a destination (a Dest key).
6.9.3 GoToR action
The GoToR action is similar to the GoTo action. However, it includes an additional parameter, the F key, that specifies the PDF file that contains the action’s destination.
Table 6.25 GoToR action attributes (in addition to those in Ta Table 6.22 )
Key Type Semantics
S (Subtype) name (Required) Action type. Always GoToR .
D (Dest) array (Required) An explicit destination, represented by an array, as described in Ta Ta b le 6.20 on pa g e 99 , except that the destination page (the first element of the array) must be specified by a page number, r, not by an indirect reference to a Page object. The first page is 0. or string or name (Required) The name of a destination. See Section 6.8.2 on pa g e 99 .
F (File) F ile specifi ca tion (Required) The file containing the destination.
NewWindow Boolean (Optional) If the value is true , then the destination document will be opened in a new window; if it is false , then the destination document will be opened in the same window as the source document. If this attribute is omitted, the viewer will behave in accordance with the current user preference.
6.9.4 Launch action
The Launch action specifies an application to launch or a document to open. The action must specify the application or document as a file, using the F key.
PDF 1.2
Page 103
November 12, 1996 6.9.5
6: Document Structure 105
PDF also allows platform-specific information to be included in the Launch dictionary where that information is needed for specific platform. The key Win is used for information related to Microsoft Windows launches; the key Unix is used for information related to UNIX system launches. If there is no platform specific key, then the F key is used.
Table 6.26 Launch action attributes (in addition to those in Ta Table 6.22 )
Key Type Semantics
S (Subtype) name (Required) Action type. Always Launch .
F (File)
Truncated: This annotation is too large to fit.
View the raw JSON.
{
"annotation_id": "d486ce59-e2ec-416f-95a8-1dd310e00653",
"date_created": "2026-09-21T13:46:48.595000Z",
"date_modified": "2026-09-21T13:46:48.595000Z",
"file_hash": "3383fb2ab568ca7019834d438f9a14b9d2ccaa2f37f319373848350005779368",
"private": false,
"record": {
"attributes": {
"chunk_type": "page_range",
"end_page": 394,
"start_page": 1
},
"blocks": [
{
"block_type": "box",
"box": {
"height": 11,
"width": 732,
"x": 145,
"y": 18
},
"id": "5ed8b5d5-aaff-4bd7-bb22-01fa23bae900",
"page_number": 1,
"text": "PDF 1.2 Reference Manual November 12, 1996 :"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 4,
"x": 871,
"y": 905
},
"id": "7bbdf0cc-1fae-41b4-bffa-245b2c92674d",
"page_number": 1,
"text": "1"
},
{
"block_type": "box",
"box": {
"height": 20,
"width": 254,
"x": 386,
"y": 317
},
"id": "34247b4d-65c5-4e61-a399-094d7808a445",
"page_number": 1,
"text": "November 12, 1996"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 319,
"x": 384,
"y": 446
},
"id": "ce47c424-b6bd-4075-bc88-7d5ed4f1aea8",
"page_number": 1,
"text": "Tim Bienz, Richard Cohn, and James R. Meehan"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 189,
"x": 384,
"y": 461
},
"id": "953b6d82-7a2d-4b83-bbca-111e7c267215",
"page_number": 1,
"text": "Adobe Systems Incorporated"
},
{
"block_type": "box",
"box": {
"height": 14,
"width": 245,
"x": 388,
"y": 235
},
"id": "c84800e9-cfc3-4f31-ae9a-310171724185",
"page_number": 1,
"text": "Adobe Systems Incorporated"
},
{
"block_type": "box",
"box": {
"height": 22,
"width": 498,
"x": 392,
"y": 124
},
"id": "fb500e02-9968-49cf-9a06-cdfc5e64f012",
"page_number": 1,
"text": "Portable Document Format"
},
{
"block_type": "box",
"box": {
"height": 23,
"width": 329,
"x": 392,
"y": 156
},
"id": "def95e10-2bd0-4850-8cba-f088e2cca45e",
"page_number": 1,
"text": "Reference Manual"
},
{
"block_type": "box",
"box": {
"height": 16,
"width": 145,
"x": 389,
"y": 190
},
"id": "261ad6ad-e744-433c-bf2f-b0bc37e54519",
"page_number": 1,
"text": "Version 1.2"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 437,
"x": 145,
"y": 18
},
"id": "e4ed8c12-3d23-4105-a12e-f786cf72077d",
"page_number": 2,
"text": ": November 12, 1996"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 432,
"x": 144,
"y": 905
},
"id": "bd852240-7b51-4cb9-9bad-fc3ac7225e84",
"page_number": 2,
"text": "2 Adobe Systems Inc."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 53,
"x": 144,
"y": 87
},
"id": "b5c4b5fa-3f5c-4689-befb-654c32cea9d5",
"page_number": 2,
"text": "Copyright"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 9,
"x": 201,
"y": 87
},
"id": "9947c2bd-1a27-45f4-be00-f6746634bbfe",
"page_number": 2,
"text": "\uf8e9"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 412,
"x": 215,
"y": 87
},
"id": "7cd8e866-cb3d-4fac-9619-6da77ad0c3fa",
"page_number": 2,
"text": "1993, 1996. Adobe Systems Incorporated. All rights reserved. Patents Pending."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 637,
"x": 144,
"y": 112
},
"id": "6f12ca70-bbb6-4390-b17d-be6084058b90",
"page_number": 2,
"text": "No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electr"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 95,
"x": 781,
"y": 112
},
"id": "e1c91f8d-e31f-4c1c-a5ac-d4ec56e5885b",
"page_number": 2,
"text": "tronic, mechanical,"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 654,
"x": 144,
"y": 125
},
"id": "65243d42-ff82-4fef-862f-414aa6782609",
"page_number": 2,
"text": "photocopying, recording, or otherwise, without the prior written consent of the publisher. Any software referred to herein is fu"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 78,
"x": 798,
"y": 125
},
"id": "050a4db5-c63e-4bdd-b6b6-c11195a82df0",
"page_number": 2,
"text": "furnished under"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 655,
"x": 144,
"y": 138
},
"id": "b6c096ee-a5b0-4b60-bbf7-ee535858b510",
"page_number": 2,
"text": "license and may only be used or copied in accordance with the terms of such license. Printed in the United States of America."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 661,
"x": 144,
"y": 163
},
"id": "a1d62a8e-18b9-42ac-8961-c0f12264ced2",
"page_number": 2,
"text": "This publication and the information herein is furnished AS IS, is subject to change without notice, and should not be construe"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 30,
"x": 805,
"y": 163
},
"id": "5fc9221c-c456-4adb-940b-3da0b3e50139",
"page_number": 2,
"text": "d as a"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 679,
"x": 144,
"y": 175
},
"id": "1339c220-9df1-4661-b97a-a9faf4709d38",
"page_number": 2,
"text": "commitment by Adobe Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or liability for any errors or"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 653,
"x": 144,
"y": 188
},
"id": "2cf68b98-091b-43c5-a76d-d484e473e4cd",
"page_number": 2,
"text": "inaccuracies, makes no warranty of any kind (express, implied or statutory) with respect to this publication, and expressly dis"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 78,
"x": 798,
"y": 188
},
"id": "ea3d3866-45c2-4d55-9503-238824b49b9d",
"page_number": 2,
"text": "claims any and"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 552,
"x": 144,
"y": 201
},
"id": "600a6a5c-d558-41e0-9e1f-a46f83a498da",
"page_number": 2,
"text": "all warranties of merchantability, fitness for particular purposes and noninfringement of third party rights."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 659,
"x": 144,
"y": 226
},
"id": "bc0ec547-0274-4f2a-9b21-815dbe1913b1",
"page_number": 2,
"text": "PostScript is a registered trademark of Adobe Systems Incorporated. All instances of the name PostScript in the text are refere"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 55,
"x": 804,
"y": 226
},
"id": "a75a4ea7-f0e4-4c0f-82d9-6e6d75f79afe",
"page_number": 2,
"text": "nces to the"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 678,
"x": 144,
"y": 239
},
"id": "19db583a-cc65-4e9f-87fb-d02502155ce0",
"page_number": 2,
"text": "PostScript language as defined by Adobe Systems Incorporated unless otherwise stated. The name PostScript also is used as a pro"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 22,
"x": 823,
"y": 239
},
"id": "5354df26-8636-46f5-956d-17849e3fa3bf",
"page_number": 2,
"text": "duct"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 447,
"x": 144,
"y": 251
},
"id": "4e7726f0-63ce-4875-b8cf-276fb6053e37",
"page_number": 2,
"text": "trademark for Adobe Systems\u2019 implementation of the PostScript language interpreter."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 619,
"x": 144,
"y": 277
},
"id": "e3db945d-0632-4cb1-80e4-321f4524ce75",
"page_number": 2,
"text": "Any references to a \u201cPostScript printer,\u201d a \u201cPostScript file,\u201d or a \u201cPostScript driver\u201d refer to printers, files, and driver pr"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 113,
"x": 763,
"y": 277
},
"id": "bc17b876-68a7-4053-b25c-df116b84e3c4",
"page_number": 2,
"text": "ograms (respectively)"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 659,
"x": 144,
"y": 289
},
"id": "5f458662-b1da-4325-a071-504783fe38a2",
"page_number": 2,
"text": "which are written in or support the PostScript language. The sentences in this book that use \u201cPostScript language\u201d as an adject"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 72,
"x": 803,
"y": 289
},
"id": "70b13209-b23b-459f-ac4d-5ce14422bc31",
"page_number": 2,
"text": "ive phrase are"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 661,
"x": 145,
"y": 302
},
"id": "8ed8d449-70c2-458a-8b97-776c43f7e34d",
"page_number": 2,
"text": "so constructed to reinforce that the name refers to the standard language definition as set forth by Adobe Systems Incorporated"
},
{
"block_type": "box",
"box": {
"height": 1,
"width": 1,
"x": 807,
"y": 308
},
"id": "1d40b35b-ddda-45ba-990e-dfdeb3391bae",
"page_number": 2,
"text": "."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 691,
"x": 144,
"y": 327
},
"id": "5214a6db-cb9e-4adf-ab49-f34a338012ba",
"page_number": 2,
"text": "Adobe, Acrobat, the Acrobat logo, Adobe Garamond, Adobe Illustrator , Carta, Distiller, FrameMaker, Minion, Photoshop, the Phot"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 30,
"x": 836,
"y": 327
},
"id": "171d28ea-1950-4593-b56e-5dbe489e109a",
"page_number": 2,
"text": "oshop"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 685,
"x": 144,
"y": 340
},
"id": "74c04630-9603-487d-94b9-4f0151d6c2e3",
"page_number": 2,
"text": "logo, Poetica, PostScript, and the PostScript logo are registered trademarks of Adobe Systems Incorporated. TrueType and QuickD"
},
{
"block_type": "box",
"box": {
"height": 5,
"width": 38,
"x": 830,
"y": 342
},
"id": "b9eade45-4d90-4639-9239-19dad9eedd51",
"page_number": 2,
"text": "raw are"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 696,
"x": 144,
"y": 352
},
"id": "7debb0f8-dc94-4062-ab78-70bf3a12fc87",
"page_number": 2,
"text": "trademarks and Apple, Macintosh, and Mac are registered trademarks of Apple Computer, Inc. ITC Stone and ITC Zapf Dingbats are"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 680,
"x": 144,
"y": 365
},
"id": "8c488127-f46b-4514-9c19-5087ce4522cb",
"page_number": 2,
"text": "registered trademarks of International Typeface Corporation. Helvetica and Times are registered trademarks of Linotype\u2013Hell AG"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 48,
"x": 827,
"y": 365
},
"id": "3d6e51c8-0886-4518-8b48-b7301f0a369c",
"page_number": 2,
"text": "and/or its"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 676,
"x": 145,
"y": 378
},
"id": "f1e7e8e0-e426-4d6a-b753-5184200dd14e",
"page_number": 2,
"text": "subsidiaries. Microsoft and Windows are registered trademarks of Microsoft Corporation. SelectSet is a trademark of Agfa Divisi"
},
{
"block_type": "box",
"box": {
"height": 8,
"width": 52,
"x": 821,
"y": 378
},
"id": "30062526-b4b0-4567-882b-5d3e5da40169",
"page_number": 2,
"text": "on, Miles,"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 670,
"x": 144,
"y": 390
},
"id": "b0c77321-cb4b-4408-8e3e-ca913100e299",
"page_number": 2,
"text": "Inc. Sun is a trademark of Sun Microsystems, Inc. SPARCstation is a registered trademark of SPARC International, Inc., licensed"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 59,
"x": 817,
"y": 390
},
"id": "6aa13f69-e51b-44b7-9332-a2f37bc66dcf",
"page_number": 2,
"text": "exclusively"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 702,
"x": 144,
"y": 403
},
"id": "889dfaaf-94a1-4d31-9516-3faec961b889",
"page_number": 2,
"text": "to Sun Microsystems, Inc. and is based upon an architecture developed by Sun Microsystems, Inc. NeXT is a trademark of NeXT Com"
},
{
"block_type": "box",
"box": {
"height": 8,
"width": 29,
"x": 846,
"y": 404
},
"id": "a2595ce3-4f8a-4031-9bf9-7afce9472afd",
"page_number": 2,
"text": "puter,"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 679,
"x": 144,
"y": 415
},
"id": "a7eed156-8d22-49ee-ab33-9fbbd0c0cdf0",
"page_number": 2,
"text": "Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd."
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 47,
"x": 827,
"y": 415
},
"id": "6de88d76-7335-46f9-9d73-3742177a66b6",
"page_number": 2,
"text": "All other"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 495,
"x": 144,
"y": 428
},
"id": "f597ce27-3905-4d91-a02c-22547ba8371a",
"page_number": 2,
"text": "brand or product names are the trademarks or registered trademarks of their respective holders."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 272,
"x": 144,
"y": 453
},
"id": "7be83ac9-4f45-4654-bbb2-482d998c4bbb",
"page_number": 2,
"text": "Library of Congress Cataloging-in-Publication Data"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 394,
"x": 144,
"y": 479
},
"id": "e83dc30b-b193-4f76-89a7-a89e55244ebe",
"page_number": 2,
"text": "Portable document format reference manual / Adobe Systems Incorporated."
},
{
"block_type": "box",
"box": {
"height": 6,
"width": 47,
"x": 164,
"y": 494
},
"id": "4bbe8c34-72f5-4081-8f4a-05375af34124",
"page_number": 2,
"text": "p. cm."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 285,
"x": 144,
"y": 504
},
"id": "ea699834-143b-40ad-a534-c20902f610c4",
"page_number": 2,
"text": "Includes bibliographical references (p. 207) and index."
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 118,
"x": 144,
"y": 517
},
"id": "56b206fc-67e1-4d49-96c6-129f7972f725",
"page_number": 2,
"text": "ISBN 0\u2013201\u201362628\u20134"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 438,
"x": 145,
"y": 529
},
"id": "017ac682-9b64-401b-bead-2db972766805",
"page_number": 2,
"text": "1. File organization (Computer science) 2. PostScript (Computer program language)"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 299,
"x": 145,
"y": 542
},
"id": "440823cb-41ac-44d6-82be-1acf90a8594c",
"page_number": 2,
"text": "3. Text processing (Computer science) I. Adobe Systems."
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 163,
"x": 145,
"y": 554
},
"id": "ec920121-7724-4f83-b325-ae07ecc15706",
"page_number": 2,
"text": "QA76.9.F5P67 199393\u20138046"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 94,
"x": 144,
"y": 567
},
"id": "2ac550cb-ab54-4c6f-b19e-393372a2d539",
"page_number": 2,
"text": "005.74\u2014dc20CIP"
},
{
"block_type": "box",
"box": {
"height": 7,
"width": 182,
"x": 145,
"y": 592
},
"id": "04d1247a-0667-47d1-817a-e94385c15f5b",
"page_number": 2,
"text": "1 2 3 4 5 6 7 8 9\u2013MA\u20139796959493"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 732,
"x": 145,
"y": 18
},
"id": "995e8f34-8e37-46db-a293-be5647de8bb0",
"page_number": 3,
"text": "PDF 1.2 Reference Manual November 12, 1996 :"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 8,
"x": 870,
"y": 905
},
"id": "e692ebc6-8ade-4795-8a8b-4fe2544bd121",
"page_number": 3,
"text": "3"
},
{
"block_type": "box",
"box": {
"height": 23,
"width": 166,
"x": 391,
"y": 180
},
"id": "884c14de-7745-41ed-80ff-0bef8fb47499",
"page_number": 3,
"text": "Contents"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 173,
"x": 360,
"y": 269
},
"id": "74c59440-9d0d-43c6-ab13-f978087133d0",
"page_number": 3,
"text": "Chapter 1: Introduction"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 16,
"x": 545,
"y": 269
},
"id": "3e65a47e-c5a3-4b27-86f0-e0981781d896",
"page_number": 3,
"text": "19"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 200,
"x": 299,
"y": 292
},
"id": "7634e72c-01ab-4222-8d3b-1e9249a87090",
"page_number": 3,
"text": "1.1 About this book 19"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 406,
"x": 299,
"y": 316
},
"id": "7c76aa63-1325-4543-b52d-62e241e40294",
"page_number": 3,
"text": "1.2 Introduction to the Second Edition\u2014PDF 1.1 21"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 389,
"x": 299,
"y": 340
},
"id": "ee7fcfe1-f0a2-4957-88d3-96bf163f11e1",
"page_number": 3,
"text": "1.3 Introduction to the Third Edition\u2014PDF 1.2 22"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 304,
"x": 299,
"y": 364
},
"id": "91b068bf-891c-408d-9a98-0e65b30ee157",
"page_number": 3,
"text": "1.4 Conventions used in this book 22"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 209,
"x": 299,
"y": 388
},
"id": "3fe457bc-f310-498f-8e05-3ac41c54e3d3",
"page_number": 3,
"text": "1.5 A note on syntax 23"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 375,
"x": 299,
"y": 412
},
"id": "6ceeeba3-1cc5-451f-8ac4-e1064e63747a",
"page_number": 3,
"text": "1.6 Copyrights and permissions to use PDF 24"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 216,
"x": 361,
"y": 445
},
"id": "2460b479-e8ef-461d-ad58-076e79d4d120",
"page_number": 3,
"text": "Portable Document Format 27"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 153,
"x": 360,
"y": 478
},
"id": "fafc3926-08cc-4639-bf8c-4649328d58a8",
"page_number": 3,
"text": "Chapter 2: Overview"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 17,
"x": 522,
"y": 478
},
"id": "b41f2bf1-5273-4742-9c38-2c7f952b834c",
"page_number": 3,
"text": "29"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 379,
"x": 298,
"y": 502
},
"id": "88c653c7-ce3c-4c8b-aacd-fed01c58663a",
"page_number": 3,
"text": "2.1 What is the Portable Document Format? 29"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 167,
"x": 298,
"y": 526
},
"id": "b1b474d1-e738-4a42-85c1-b68a75d043e1",
"page_number": 3,
"text": "2.2 Using PDF 29"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 221,
"x": 298,
"y": 550
},
"id": "29720327-cd2a-4ef2-971a-873989ebbd5c",
"page_number": 3,
"text": "2.3 General properties 31"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 330,
"x": 298,
"y": 574
},
"id": "a5bae4a7-90e0-4eb0-b360-30cefb86bcb0",
"page_number": 3,
"text": "2.4 PDF and the PostScript language 35"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 231,
"x": 298,
"y": 598
},
"id": "72e643e0-5d71-43bf-9318-557306c33b06",
"page_number": 3,
"text": "2.5 Understanding PDF 36"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 233,
"x": 360,
"y": 631
},
"id": "5b02194a-9769-4b9f-af99-080c8c135767",
"page_number": 3,
"text": "Chapter 3: Coordinate Systems"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 17,
"x": 603,
"y": 631
},
"id": "68aa7e8a-41f3-44da-808d-30fcec99cf0d",
"page_number": 3,
"text": "37"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 186,
"x": 298,
"y": 655
},
"id": "6f8808a7-b3d8-450a-ab61-97f7a5ef69be",
"page_number": 3,
"text": "3.1 Device space 37"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 171,
"x": 298,
"y": 679
},
"id": "a1171e8b-6d3a-45b5-981a-92594af9f16e",
"page_number": 3,
"text": "3.2 User space 38"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 165,
"x": 298,
"y": 703
},
"id": "229fb8de-efc9-489f-ae35-d3596f226dfa",
"page_number": 3,
"text": "3.3 Text space 39"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 208,
"x": 298,
"y": 727
},
"id": "12b06cb9-e504-41dc-bf58-ea0a25ba5467",
"page_number": 3,
"text": "3.4 Character space 39"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 181,
"x": 298,
"y": 751
},
"id": "bc73a199-226e-4e38-a016-ae456ebf280e",
"page_number": 3,
"text": "3.5 Image space 39"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 174,
"x": 298,
"y": 775
},
"id": "2d453658-b5c6-4f09-96d3-486b33d3700d",
"page_number": 3,
"text": "3.6 Form space 39"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 189,
"x": 298,
"y": 799
},
"id": "c2484582-57d3-496d-9781-070b4b565c5b",
"page_number": 3,
"text": "3.7 Pattern space 39"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 386,
"x": 298,
"y": 823
},
"id": "0f58e4b7-30be-447f-9f94-eba6f4de69d5",
"page_number": 3,
"text": "3.8 Relationships among coordinate systems 40"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 415,
"x": 298,
"y": 847
},
"id": "38ab2231-7b8e-48b6-b88d-afdb1c4e078c",
"page_number": 3,
"text": "3.9 Transformations between coordinate systems 40"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 437,
"x": 145,
"y": 18
},
"id": "052f80ca-8aa2-4f13-91ad-3e64b75d6bf6",
"page_number": 4,
"text": ": November 12, 1996"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 432,
"x": 144,
"y": 905
},
"id": "4b05e9b9-3620-4e12-b63a-2a9742e8e711",
"page_number": 4,
"text": "4 Adobe Systems Inc."
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 271,
"x": 289,
"y": 86
},
"id": "cb79b984-36c3-4747-b842-f0c3f8fd63ed",
"page_number": 4,
"text": "3.10 Transformation matrices 42"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 140,
"x": 360,
"y": 120
},
"id": "4a1f9af7-0842-4fe5-ba18-edf3b141d71e",
"page_number": 4,
"text": "Chapter 4: Objects"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 17,
"x": 510,
"y": 120
},
"id": "d5ea3e18-c7da-434c-b237-5fe5bbab7d1b",
"page_number": 4,
"text": "45"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 173,
"x": 298,
"y": 143
},
"id": "143423e9-c2fb-4286-96e3-655819ee679f",
"page_number": 4,
"text": "4.1 Introduction 45"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 156,
"x": 298,
"y": 167
},
"id": "de51c585-198f-4fa6-acac-32f91b23952e",
"page_number": 4,
"text": "4.2 Booleans 45"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 154,
"x": 298,
"y": 191
},
"id": "11040f04-6636-4825-b0e7-50b2a9eb0724",
"page_number": 4,
"text": "4.3 Numbers 45"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 139,
"x": 298,
"y": 215
},
"id": "41dd0a2d-31a0-4ead-b67c-75974bbb9429",
"page_number": 4,
"text": "4.4 Strings 46"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 140,
"x": 298,
"y": 239
},
"id": "351cce40-20b5-4437-bdf6-7632c5ed7b7f",
"page_number": 4,
"text": "4.5 Names 48"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 135,
"x": 298,
"y": 263
},
"id": "bb38538c-fc4e-477c-a9eb-8f1171235941",
"page_number": 4,
"text": "4.6 Arrays 49"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 174,
"x": 298,
"y": 287
},
"id": "cb619b8d-7568-45fa-a8bf-bda4769a19a6",
"page_number": 4,
"text": "4.7 Dictionaries 49"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 149,
"x": 298,
"y": 311
},
"id": "53531005-e6ec-4178-a15e-82501e821d4e",
"page_number": 4,
"text": "4.8 Streams 50"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 194,
"x": 298,
"y": 335
},
"id": "7aba3a23-3689-42c8-af7b-67352e45be79",
"page_number": 4,
"text": "4.9 The null object 62"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 207,
"x": 289,
"y": 359
},
"id": "ea8ddc83-2252-49b0-b6a6-5a339f2aeae7",
"page_number": 4,
"text": "4.10 Indirect objects 62"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 225,
"x": 289,
"y": 383
},
"id": "5b5fd3f8-bc13-4c56-80bb-9e1ead42519c",
"page_number": 4,
"text": "4.11 Object references 62"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 184,
"x": 360,
"y": 416
},
"id": "b319b469-117c-4d1a-8855-add1c1f05422",
"page_number": 4,
"text": "Chapter 5: File Structure"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 16,
"x": 554,
"y": 416
},
"id": "11ca4097-7a7f-412d-ba01-229a73158f09",
"page_number": 4,
"text": "65"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 154,
"x": 298,
"y": 440
},
"id": "21146cc4-b8d4-4d78-8ed3-9c7844556163",
"page_number": 4,
"text": "5.1 PDF files 65"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 142,
"x": 298,
"y": 464
},
"id": "cca29d58-e4d8-436e-86b8-c0bef6536677",
"page_number": 4,
"text": "5.2 Header 66"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 125,
"x": 298,
"y": 488
},
"id": "64451f6d-02c4-4a82-9f5d-2ec704d4fe69",
"page_number": 4,
"text": "5.3 Body 66"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 244,
"x": 298,
"y": 512
},
"id": "d5945107-152a-4aa1-bb2c-7cb3778df9bd",
"page_number": 4,
"text": "5.4 Cross-reference table 67"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 132,
"x": 298,
"y": 536
},
"id": "08cc8bf3-59a3-40fc-b875-d4b4661caac2",
"page_number": 4,
"text": "5.5 Trailer 69"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 228,
"x": 298,
"y": 560
},
"id": "50aa1ed1-96df-4532-ae25-72ebd24f1419",
"page_number": 4,
"text": "5.6 Incremental update 70"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 166,
"x": 298,
"y": 584
},
"id": "6e7a410c-329f-4fd8-9b51-052c6046bc32",
"page_number": 4,
"text": "5.7 Encryption 72"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 233,
"x": 360,
"y": 617
},
"id": "94cdaa86-43f5-4464-a7c6-cf2adce83af9",
"page_number": 4,
"text": "Chapter 6: Document Structure"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 17,
"x": 603,
"y": 617
},
"id": "73f68ac2-a016-4551-868b-c23b5c61a998",
"page_number": 4,
"text": "75"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 173,
"x": 298,
"y": 641
},
"id": "f44cbd47-6bc4-493b-8251-8a434131d3bf",
"page_number": 4,
"text": "6.1 Introduction 75"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 144,
"x": 298,
"y": 665
},
"id": "058deffb-ca83-45c6-b0f2-f9831505daa5",
"page_number": 4,
"text": "6.2 Catalog 77"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 166,
"x": 298,
"y": 689
},
"id": "2b81ed03-8944-407e-84ea-182414092159",
"page_number": 4,
"text": "6.3 Pages tree 79"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 179,
"x": 298,
"y": 713
},
"id": "7c7b1a2e-002d-4af7-9fef-4ba922dba6ec",
"page_number": 4,
"text": "6.4 Page objects 81"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 172,
"x": 298,
"y": 737
},
"id": "b31d412e-3226-4be1-bb76-6f6b0d655672",
"page_number": 4,
"text": "6.5 Thumbnails 86"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 174,
"x": 298,
"y": 761
},
"id": "52133883-6696-4cef-a0da-934ecaca69d7",
"page_number": 4,
"text": "6.6 Annotations 87"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 172,
"x": 298,
"y": 785
},
"id": "bb703bfd-6b71-4e59-8314-cb72f4eeebff",
"page_number": 4,
"text": "6.7 Outline tree 96"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 178,
"x": 298,
"y": 809
},
"id": "2c0abd05-b4f6-43ff-aa34-d8ee106b1001",
"page_number": 4,
"text": "6.8 Destinations 98"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 151,
"x": 298,
"y": 833
},
"id": "1f6553c9-1162-424e-b8a2-e2b22419c050",
"page_number": 4,
"text": "6.9 Actions 100"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 188,
"x": 289,
"y": 857
},
"id": "146e68e8-47de-4c6a-8c33-2d622eef395a",
"page_number": 4,
"text": "6.10 Name trees 111"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 141,
"x": 441,
"y": 18
},
"id": "cc73efd5-dd90-49d7-a5a5-57bbdb9a77b3",
"page_number": 5,
"text": "November 12, 1996"
},
{
"block_type": "box",
"box": {
"height": 6,
"width": 1,
"x": 817,
"y": 908
},
"id": "06b014a6-9b79-4e8f-86a9-d9e3b9cad630",
"page_number": 5,
"text": ":"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 8,
"x": 870,
"y": 905
},
"id": "02dbd689-0433-4120-ab08-6f9e9fb04803",
"page_number": 5,
"text": "5"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 208,
"x": 289,
"y": 86
},
"id": "0830e779-4600-4e75-a0dc-037085c9d729",
"page_number": 5,
"text": "6.11 Info dictionary 114"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 160,
"x": 289,
"y": 111
},
"id": "a6e0da76-242a-4e7e-a636-e2ea1a0bfa43",
"page_number": 5,
"text": "6.12 Articles 115"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 153,
"x": 289,
"y": 135
},
"id": "ca381920-058d-487e-a1e6-3d47381876e7",
"page_number": 5,
"text": "6.13 File ID 117"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 259,
"x": 289,
"y": 159
},
"id": "ff1f54a0-ad37-451f-b739-db94a061a827",
"page_number": 5,
"text": "6.14 Encryption dictionary 118"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 213,
"x": 289,
"y": 183
},
"id": "f572d9a5-1784-43d9-bd09-f861fd435467",
"page_number": 5,
"text": "6.15 Acrobat Forms 122"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 161,
"x": 289,
"y": 206
},
"id": "4e283e80-a43d-4c0d-84ff-ff4384747448",
"page_number": 5,
"text": "6.16 Sounds 135"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 271,
"x": 360,
"y": 240
},
"id": "0dd10a75-bbec-4517-a03f-d238796edd4f",
"page_number": 5,
"text": "Chapter 7: Common Data Structures"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 25,
"x": 642,
"y": 240
},
"id": "95d27a91-e202-4082-94d7-65a43a74194c",
"page_number": 5,
"text": "137"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 171,
"x": 298,
"y": 263
},
"id": "b0494171-7ab5-4a85-bc02-0d2723087338",
"page_number": 5,
"text": "7.1 Rectangle 137"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 218,
"x": 298,
"y": 287
},
"id": "1ea9dcc4-4d0b-4f94-b93b-04fcd8b9de48",
"page_number": 5,
"text": "7.2 File specification 137"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 254,
"x": 298,
"y": 311
},
"id": "74226050-6cf4-4e7a-96b8-6db59c3449f0",
"page_number": 5,
"text": "7.3 Resource Dictionaries 141"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 163,
"x": 298,
"y": 335
},
"id": "bba74506-fff5-4c19-8329-6c7900b24e0d",
"page_number": 5,
"text": "7.4 ProcSets 143"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 138,
"x": 298,
"y": 359
},
"id": "e3edf5e6-cad2-4a56-ae3e-eab47d50dab4",
"page_number": 5,
"text": "7.5 Fonts 144"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 208,
"x": 298,
"y": 383
},
"id": "af751503-74ef-46a1-92c9-6e6c27f5d674",
"page_number": 5,
"text": "7.6 Font encodings 157"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 149,
"x": 298,
"y": 407
},
"id": "30456e60-517b-48df-ba0d-770b2d202c3e",
"page_number": 5,
"text": "7.7 CMaps 158"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 214,
"x": 298,
"y": 431
},
"id": "2dc4060a-0358-400d-a5bb-e046313d3664",
"page_number": 5,
"text": "7.8 Font descriptors 163"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 190,
"x": 298,
"y": 455
},
"id": "b7b28c45-6f6a-462e-87a6-b1f52833d8d8",
"page_number": 5,
"text": "7.9 Color spaces 171"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 172,
"x": 289,
"y": 479
},
"id": "9ac5bb8c-aba7-4331-9c58-8237c58cef7a",
"page_number": 5,
"text": "7.10 XObjects 178"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 177,
"x": 289,
"y": 503
},
"id": "0bff75c4-f3c7-4916-8c37-0b97329f6722",
"page_number": 5,
"text": "7.11 Functions 187"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 287,
"x": 289,
"y": 527
},
"id": "90d5db5c-6ea8-4d92-ac1c-a44914747bce",
"page_number": 5,
"text": "7.12 Extended graphics states 191"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 175,
"x": 289,
"y": 551
},
"id": "4fb90465-b5db-46d3-8b94-f09102722b3e",
"page_number": 5,
"text": "7.13 Halftones 193"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 167,
"x": 289,
"y": 575
},
"id": "f4e4737f-7b18-42dd-a36e-69e2f9ba8f1d",
"page_number": 5,
"text": "7.14 Patterns 203"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 201,
"x": 289,
"y": 599
},
"id": "5e59e731-c9fa-4a6b-aa9a-640f73a7bbf9",
"page_number": 5,
"text": "7.15 Property lists 208"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 218,
"x": 360,
"y": 632
},
"id": "09f8621f-5c98-4fdf-a96a-882b79b68098",
"page_number": 5,
"text": "Chapter 8: Page Descriptions"
},
{
"block_type": "box",
"box": {
"height": 9,
"width": 24,
"x": 588,
"y": 632
},
"id": "0d4238fa-5aee-4f31-a503-48be17c5a6d3",
"page_number": 5,
"text": "211"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 162,
"x": 298,
"y": 656
},
"id": "3d802049-c51f-42eb-bd06-f3be734efc98",
"page_number": 5,
"text": "8.1 Overview 211"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 202,
"x": 298,
"y": 680
},
"id": "4b571fd4-7708-4c36-bded-717d81533dd0",
"page_number": 5,
"text": "8.2 Graphics state 213"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 263,
"x": 298,
"y": 704
},
"id": "871edf2e-9d18-4252-9a2a-354e57095152",
"page_number": 5,
"text": "8.3 Special Graphics State 214"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 265,
"x": 298,
"y": 728
},
"id": "9877a376-cc36-4f12-8860-3ac8bcc5bada",
"page_number": 5,
"text": "8.4 General Graphics state 215"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 136,
"x": 298,
"y": 752
},
"id": "d3f9bdf0-efce-4e61-b9f8-75122663c9c0",
"page_number": 5,
"text": "8.5 Color 220"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 138,
"x": 298,
"y": 776
},
"id": "635742e1-83c1-4fa1-a4ca-d706f0219560",
"page_number": 5,
"text": "8.6 Paths 223"
},
{
"block_type": "box",
"box": {
"height": 10,
"width": 166,
"x": 298,
"y": 800
},
"id": "f81e4de4-9829-419c-9775-dbd3e11c726b",
"page_number": 5,
"text": "8.7 Text state 229"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 295,
"x": 298,
"y": 824
},
"id": "9980c468-e57a-4a7c-80d5-46398f4a360b",
"page_number": 5,
"text": "8.8 External objects (XObjects) 238"
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 247,
"x": 298,
"y": 848
},
"id": "c874e51c-429e-41f5-aa33-e945d5a37bed",
"page_number": 5,
"text": "8.9 In-line image objects 238"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 437,
"x": 145,
"y": 18
},
"id": "6d70bee3-bcf8-4001-9609-29ae6fe1b639",
"page_number": 6,
"text": ": November 12, 1996"
},
{
"block_type": "box",
"box": {
"height": 11,
"width": 431,
"x": 145,
"y": 905
},
"id": "6508b9bb-5679-4e63-9ff2-f1c4081277b8",
"page_number": 6,
"text": "6 Adobe Systems Inc."
},
{
"block_type": "box",
"box": {
"height": 12,
"width": 218,
"x": 289,
"y": 86
},
"id":...