PDF Reference
fifth edition
Adobe® Portable Document Format
Version 1.6
Adobe Systems Incorporated
© 1985–2004 Adobe
®
Systems Incorporated. All rights reserved.
PDF Reference, fifth edition: Adobe Portable Document Format version 1.6.
NOTICE: All information contained herein is the property of Adobe Systems Incorporated.
No part of this publication (whether in hardcopy or electronic form) may be reproduced, stored in
a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photo-
copying, recording, or otherwise, without the prior written permission of Adobe Systems Incorpo-
rated. Please note that the content in this guide is protected under copyright law even if it is not
distributed with software that includes an end user license agreement.
Adobe, the Adobe logo, Acrobat, the Acrobat logo, Acrobat Capture, Adobe Garamond, Adobe
Intelligent Document Platform, Adobe PDF, Adobe Reader, Adobe Solutions Network, Aldus, Dis-
tiller, ePaper, Extreme, FrameMaker, Illustrator, InDesign, Minion, Myriad, PageMaker, Photo-
shop, Poetica, PostScript, and XMP are either registered trademarks or trademarks of Adobe
Systems Incorporated in the United States and/or other countries. Microsoft and Windows are
either registered trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries. Apple, Mac, Macintosh, and Power Macintosh are trademarks of Apple Computer,
Inc., registered in the United States and other countries. IBM is a registered trademark of IBM
Corporation in the United States. Sun is a trademark or registered trademark of Sun Microsys-
tems, Inc. in the United States and other countries. UNIX is a registered trademark of The Open
Group. SVG is a trademark of the World Wide Web Consortium; marks of the W3C are registered
and held by its host institutions MIT, INRIA and Keio. Helvetica and Times are registered trade-
marks of Linotype-Hell AG and/or its subsidiaries. Arial and Times New Roman are trademarks of
The Monotype Corporation registered in the U.S. Patent and Trademark Office and may be regis-
tered in certain other jurisdictions. ITC Zapf Dingbats is a registered trademark of International
Typeface Corporation. Ryumin Light is a trademark of Morisawa & Co., Ltd. All other trademarks
are the property of their respective owners.
All instances of the name PostScript in the text are references to the PostScript language as defined
by Adobe Systems Incorporated unless otherwise stated. The name PostScript also is used as a
product trademark for Adobe Systems’ implementation of the PostScript language interpreter.
Except as otherwise stated, any mention of a “PostScript output device,” “PostScript printer,” “Post-
Script software,” or similar item refers to a product that contains PostScript technology created or
licensed by Adobe Systems Incorporated, not to one that purports to be merely compatible.
This publication and the information herein are furnished AS IS, are furnished for informational
use only, are subject to change without notice, and should not be construed as a commitment by
Adobe Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or liability
for any errors or inaccuracies that may appear in the informational content contained in this
guide, makes no warranty of any kind (express, implied, or statutory) with respect to this publica-
tion, and expressly disclaims any and all warranties of merchantability, fitness for particular pur-
poses, and noninfringement of third-party rights.
Please remember that existing artwork or images that you may want to include in your project may
be protected under copyright law. The unauthorized incorporation of such material into your new
work could be a violation of the rights of the copyright owner. Please be sure to obtain any permis-
sion required from the copyright owner. Any references to company names in sample templates
are for demonstration purposes only and are not intended to refer to any actual organization.
iii
Contents
Preface
xxi
Chapter 1: Introduction
1
1.1 About This Book 1
1.2 Introduction to PDF 1.6 Features 4
1.3 Introduction to PDF 1.5 Features 5
1.4 Related Publications 6
1.5 Intellectual Property 7
Chapter 2: Overview
9
2.1 Imaging Model 10
2.2 Other General Properties 14
2.3 Creating PDF 19
2.4 PDF and the PostScript Language 21
Chapter 3: Syntax
23
3.1 Lexical Conventions 24
3.2 Objects 27
3.3 Filters 41
3.4 File Structure 66
3.5 Encryption 91
3.6 Document Structure 112
3.7 Content Streams and Resources 125
3.8 Common Data Structures 130
3.9 Functions 139
3.10 File Specifications 151
Chapter 4: Graphics
163
4.1 Graphics Objects 164
4.2 Coordinate Systems 169
4.3 Graphics State 180
4.4 Path Construction and Painting 194
4.5 Color Spaces 205
4.6 Patterns 259
4.7 External Objects 302
4.8 Images 304
4.9 Form XObjects 325
4.10 Optional Content 334
Contents
iv
Chapter 5: Text
357
5.1 Organization and Use of Fonts 358
5.2 Text State Parameters and Operators 366
5.3 Text Objects 374
5.4 Introduction to Font Data Structures 381
5.5 Simple Fonts 382
5.6 Composite Fonts 403
5.7 Font Descriptors 426
5.8 Embedded Font Programs 436
5.9 Extraction of Text Content 440
Chapter 6: Rendering
447
6.1 CIE-Based Color to Device Color 448
6.2 Conversions among Device Color Spaces 450
6.3 Transfer Functions 454
6.4 Halftones 456
6.5 Scan Conversion Details 478
Chapter 7: Transparency
483
7.1 Overview of Transparency 484
7.2 Basic Compositing Computations 486
7.3 Transparency Groups 499
7.4 Soft Masks 513
7.5 Specifying Transparency in PDF 515
7.6 Color Space and Rendering Issues 529
Chapter 8: Interactive Features
547
8.1 Viewer Preferences 547
8.2 Document-Level Navigation 550
8.3 Page-Level Navigation 558
8.4 Annotations 568
8.5 Actions 609
8.6 Interactive Forms 634
8.7 Digital Signatures 684
8.8 Measurement Properties 703
Chapter 9: Multimedia Features
711
9.1 Multimedia 711
9.2 Sounds 739
9.3 Movies 741
9.4 Alternate Presentations 743
9.5 3D Artwork 746
Contents
v
Chapter 10: Document Interchange
769
10.1 Procedure Sets 770
10.2 Metadata 771
10.3 File Identifiers 775
10.4 Page-Piece Dictionaries 776
10.5 Marked Content 778
10.6 Logical Structure 784
10.7 Tagged PDF 812
10.8 Accessibility Support 863
10.9 Web Capture 873
10.10 Prepress Support 890
Appendix A: Operator Summary
913
Appendix B: Operators in Type 4 Functions
917
B.1 Arithmetic Operators 917
B.2 Relational, Boolean, and Bitwise Operators 918
B.3 Conditional Operators 918
B.4 Stack Operators 918
Appendix C: Implementation Limits
919
Appendix D: Character Sets and Encodings
923
D.1 Latin Character Set and Encodings 925
D.2 Expert Set and MacExpertEncoding 929
D.3 Symbol Set and Encoding 932
D.4 ZapfDingbats Set and Encoding 935
Appendix E: PDF Name Registry
937
Appendix F: Linearized PDF
939
F.1 Background and Assumptions 940
F.2 Linearized PDF Document Structure 942
F.3 Hint Tables 957
F.4 Access Strategies 969
Appendix G: Example PDF Files
975
G.1 Minimal PDF File 975
G.2 Simple Text String Example 978
G.3 Simple Graphics Example 980
G.4 Page Tree Example 983
G.5 Outline Hierarchy Example 988
G.6 Updating Example 992
Contents
vi
Appendix H: Compatibility and Implementation Notes
1001
H.1 PDF Version Numbers 1001
H.2 Feature Compatibility 1004
H.3 Implementation Notes 1005
Appendix I: Computation of Object Digests
1037
I.1 Basic Object Types 1037
I.2 Selective Computation 1039
Color Plates
1045
Bibliography
1057
Index
1065
vii
Figures
2.1
Creating PDF files using the Adobe PDF printer 20
2.2
Creating PDF files using Acrobat Distiller 21
3.1
PDF components 24
3.2
Initial structure of a PDF file 67
3.3
Structure of an updated PDF file 76
3.4
Public-key encryption algorithm 105
3.5
Structure of a PDF document 113
3.6
Inheritance of attributes 124
3.7
Mapping with the
Decode
array 146
4.1
Graphics objects 167
4.2
Device space 170
4.3
User space 172
4.4
Relationships among coordinate systems 174
4.5
Effects of coordinate transformations 175
4.6
Effect of transformation order 176
4.7
Miter length 187
4.8
Cubic Bézier curve generated by the
c
operator 198
4.9
Cubic Bézier curves generated by the
v
and
y
operators 199
4.10
Nonzero winding number rule 203
4.11
Even-odd rule 204
4.12
Color specification 208
4.13
Color rendering 209
4.14
Component transformations in a CIE-based
ABC
color space 215
4.15
Component transformations in a CIE-based
A
color space 216
4.16
Starting a new triangle in a free-form Gouraud-shaded triangle mesh 286
4.17
Connecting triangles in a free-form Gouraud-shaded triangle mesh 287
4.18
Varying the value of the edge flag to create different shapes 288
4.19
Lattice-form triangle meshes 289
4.20
Coordinate mapping from a unit square to a four-sided Coons patch 292
4.21
Painted area and boundary of a Coons patch 293
4.22
Color values and edge flags in Coons patch meshes 295
4.23
Edge connections in a Coons patch mesh 296
4.24
Control points in a tensor-product patch 298
4.25
Typical sampled image 304
4.26
Source image coordinate system 308
4.27
Mapping the source image 308
5.1
Glyphs painted in 50% gray 361
Figures
viii
5.2
Glyph outlines treated as a stroked path 362
5.3
Graphics clipped by a glyph path 363
5.4
Glyph metrics 364
5.5
Metrics for horizontal and vertical writing modes 366
5.6
Character spacing in horizontal writing 369
5.7
Word spacing in horizontal writing 369
5.8
Horizontal scaling 370
5.9
Leading 370
5.10
Text rise 373
5.11
Operation of the
TJ
operator in horizontal writing 378
5.12
Output from Example 394
5.13
Characteristics represented in the
Flags
entry of a font descriptor 430
6.1
Various halftoning effects 464
6.2
Halftone cell with a nonzero angle 470
6.3
Angled halftone cell divided into two squares 471
6.4
Halftone cell and two squares tiled across device space 471
6.5
Tiling of device space in a type 16 halftone 473
6.6
Flatness tolerance 479
6.7
Rasterization without stroke adjustment 482
8.1
Presentation timing 565
8.2
Open annotation 569
8.3
Coordinate adjustment with the NoRotate flag 575
8.4
Free text annotation with callout 590
8.5
Leader lines 592
8.6
Lines with captions 592
8.7
Square and circle annotations 594
8.8
QuadPoints
specification 597
8.9
FDF file structure 671
9.1
Default view of artwork 756
9.2
Annotation 2 rotated 756
9.3
Shared artwork (annotations 2 &3) modified 756
9.4
Rotation around the center of orbit 759
9.5
Perspective projection of 3D artwork onto the near plane 762
9.6
Objects projected onto the near clipping plane, as seen from the position of
the camera 762
9.7
Positioning and scaling the near plane onto the annotation’s 3D view
box 763
9.8
3D annotation positioned on the page 763
10.1
Simple Web Capture file structure 876
10.2
Complex Web Capture file structure 877
10.3
Page boundaries 892
10.4
Trapping example 902
G.1
Output of Example G.3 981
Figures
ix
G.2
Page tree for Example G.4 983
G.3
Document outline as displayed in Example G.5 988
G.4
Document outline as displayed in Example G.6 990
Plate 1
Additive and subtractive color (Section 4.5.3, “Device Color Spaces,” page
211)
Plate 2
Uncalibrated color (Section 4.5.4, “CIE-Based Color Spaces,” page 214)
Plate 3
Lab
color space (“Lab Color Spaces,” page 220)
Plate 4
Color gamuts (“Lab Color Spaces,” page 220)
Plate 5
Rendering intents (“Rendering Intents,” page 230)
Plate 6
Duotone image (“DeviceN Color Spaces,” page 238)
Plate 7
Quadtone image (“DeviceN Color Spaces,” page 238)
Plate 8
Colored tiling pattern (“Colored Tiling Patterns,” page 265)
Plate 9
Uncolored tiling pattern (“Uncolored Tiling Patterns,” page 269)
Plate 10 Axial shading (“Type 2 (Axial) Shadings,” page 280)
Plate 11 Radial shadings depicting a cone (“Type 3 (Radial) Shadings,” page 282)
Plate 12 Radial shadings depicting a sphere (“Type 3 (Radial) Shadings,” page 283)
Plate 13 Radial shadings with extension (“Type 3 (Radial) Shadings,” page 283)
Plate 14 Radial shading effect (“Type 3 (Radial) Shadings,” page 283)
Plate 15 Coons patch mesh (“Type 6 Shadings (Coons Patch Meshes),” page 291)
Plate 16 Transparency groups (Section 7.1, “Overview of Transparency,” page 485)
Plate 17 Isolated and knockout groups (Sections 7.3.4, “Isolated Groups,” page 507
and 7.3.5, “Knockout Groups,” page 508)
Plate 18 RGB blend modes (Section 7.2.4, “Blend Mode,” page 490)
Plate 19 CMYK blend modes (Section 7.2.4, “Blend Mode,” page 490)
Plate 20 Blending and overprinting (“Compatibility with Opaque Overprinting,”
page 537)
Figures
x
xi
Tables
3.1 White-space characters 26
3.2 Escape sequences in literal strings 30
3.3 Examples of literal names using the # character 33
3.4 Entries common to all stream dictionaries 38
3.5 Standard filters 43
3.6 Typical LZW encoding sequence 49
3.7 Optional parameters for LZWDecode and FlateDecode filters 50
3.8 Predictor values 52
3.9 Optional parameters for the CCITTFaxDecode filter 54
3.10 Optional parameter for the JBIG2Decode filter 58
3.11 Optional parameter for the DCTDecode filter 61
3.12 Optional parameters for Crypt filters 66
3.13 Entries in the file trailer dictionary 73
3.14 Additional entries specific to an object stream dictionary 77
3.15 Additional entries specific to a cross-reference stream dictionary 83
3.16 Entries in a cross-reference stream 85
3.17 Additional entries in a hybrid-reference file’s trailer dictionary 86
3.18 Entries common to all encryption dictionaries 92
3.19 Additional encryption dictionary entries for the standard security
handler 98
3.20 User access permissions 99
3.21 Additional encryption dictionary entries for public-key security
handlers 105
3.22 Entries common to all crypt filter dictionaries 108
3.23 Standard crypt filter names 109
3.24 Additional crypt filter dictionary entries for public-key security
handlers 109
3.25 Entries in the catalog dictionary 114
3.26 Required entries in a page tree node 118
3.27 Entries in a page object 119
3.28 Entries in the name dictionary 125
3.29 Compatibility operators 127
3.30 Entries in a resource dictionary 129
3.31 PDF data types 131
3.32 Entries in a name tree node dictionary 135
3.33 Entries in a number tree node dictionary 139
Tables
xii
3.34 Entries common to all function dictionaries 141
3.35 Additional entries specific to a type 0 function dictionary 143
3.36 Additional entries specific to a type 2 function dictionary 146
3.37 Additional entries specific to a type 3 function dictionary 147
3.38 Operators in type 4 functions 149
3.39 Examples of file specifications 154
3.40 Entries in a file specification dictionary 155
3.41 Additional entries in an embedded file stream dictionary 158
3.42 Entries in an embedded file parameter dictionary 158
3.43 Entries in a Mac OS file information dictionary 159
4.1 Operator categories 166
4.2 Device-independent graphics state parameters 180
4.3 Device-dependent graphics state parameters 182
4.4 Line cap styles 186
4.5 Line join styles 186
4.6 Examples of line dash patterns 188
4.7 Graphics state operators 189
4.8 Entries in a graphics state parameter dictionary 190
4.9 Path construction operators 196
4.10 Path-painting operators 200
4.11 Clipping path operators 205
4.12 Color space families 207
4.13 Entries in a CalGray color space dictionary 216
4.14 Entries in a CalRGB color space dictionary 218
4.15 Entries in a Lab color space dictionary 221
4.16 Additional entries specific to an ICC profile stream dictionary 223
4.17 ICC specification versions supported by ICCBased color spaces 223
4.18 ICC profile types 224
4.19 Ranges for typical ICC color spaces 225
4.20 Rendering intents 231
4.21 Entries in a DeviceN color space attributes dictionary 242
4.22 Entries in a DeviceN process dictionary 244
4.23 Entries in a DeviceN mixing hints dictionary 244
4.24 Color operators 257
4.25 Additional entries specific to a type 1 pattern dictionary 262
4.26 Entries in a type 2 pattern dictionary 272
4.27 Shading operator 273
4.28 Entries common to all shading dictionaries 275
4.29 Additional entries specific to a type 1 shading dictionary 278
4.30 Additional entries specific to a type 2 shading dictionary 279
4.31 Additional entries specific to a type 3 shading dictionary 281
4.32 Additional entries specific to a type 4 shading dictionary 285
4.33 Additional entries specific to a type 5 shading dictionary 290
Tables
xiii
4.34 Additional entries specific to a type 6 shading dictionary 294
4.35 Data values in a Coons patch mesh 297
4.36 Data values in a tensor-product patch mesh 301
4.37 XObject operator 302
4.38 Additional entries specific to a PostScript XObject dictionary 303
4.39 Additional entries specific to an image dictionary 310
4.40 Default Decode arrays 315
4.41 Entries in an alternate image dictionary 317
4.42 Inline image operators 322
4.43 Entries in an inline image object 323
4.44 Additional abbreviations in an inline image object 323
4.45 Additional entries specific to a type 1 form dictionary 328
4.46 Entries common to all group attributes dictionaries 331
4.47 Entries in a reference dictionary 332
4.48 Entries in an optional content group dictionary 334
4.49 Entries in an optional content membership dictionary 336
4.50 Entries in the optional content properties dictionary 345
4.51 Entries in an optional content configuration dictionary 346
4.52 Entries in an optional content usage dictionary 350
4.53 Entries in a usage application dictionary 352
5.1 Text state parameters 367
5.2 Text state operators 368
5.3 Text rendering modes 372
5.4 Text object operators 375
5.5 Text-positioning operators 376
5.6 Text-showing operators 377
5.7 Font types 381
5.8 Entries in a Type 1 font dictionary 383
5.9 Entries in a Type 3 font dictionary 390
5.10 Type 3 font operators 392
5.11 Entries in an encoding dictionary 397
5.12 Differences between MacRomanEncoding and Mac OS Roman
encoding 402
5.13 Entries in a CIDSystemInfo dictionary 406
5.14 Entries in a CIDFont dictionary 407
5.15 Predefined CJK CMap names 412
5.16 Character collections for predefined CMaps, by PDF version 416
5.17 Additional entries in a CMap dictionary 419
5.18 Entries in a Type 0 font dictionary 423
5.19 Entries common to all font descriptors 426
5.20 Font flags 429
5.21 Additional font descriptor entries for CIDFonts 431
5.22 Glyph classes in CJK fonts 433
Tables
xiv
5.23 Embedded font organization for various font types 436
5.24 Additional entries in an embedded font stream dictionary 437
6.1 Predefined spot functions 459
6.2 PDF halftone types 466
6.3 Entries in a type 1 halftone dictionary 467
6.4 Additional entries specific to a type 6 halftone dictionary 469
6.5 Additional entries specific to a type 10 halftone dictionary 472
6.6 Additional entries specific to a type 16 halftone dictionary 474
6.7 Entries in a type 5 halftone dictionary 475
7.1 Variables used in the basic compositing formula 488
7.2 Standard separable blend modes 491
7.3 Standard nonseparable blend modes 493
7.4 Variables used in the source shape and opacity formulas 496
7.5 Variables used in the result shape and opacity formulas 497
7.6 Revised variables for the basic compositing formulas 501
7.7 Arguments and results of the group compositing function 503
7.8 Variables used in the group compositing formulas 505
7.9 Variables used in the page group compositing formulas 511
7.10 Entries in a soft-mask dictionary 521
7.11 Restrictions on the entries in a soft-mask image dictionary 523
7.12 Additional entry in a soft-mask image dictionary 524
7.13 Additional entries specific to a transparency group attributes
dictionary 525
7.14 Overprinting behavior in the opaque imaging model 539
7.15 Overprinting behavior in the transparent imaging model 540
8.1 Entries in a viewer preferences dictionary 548
8.2 Destination syntax 552
8.3 Entries in the outline dictionary 554
8.4 Entries in an outline item dictionary 555
8.5 Outline item flags 556
8.6 Entries in a page label dictionary 559
8.7 Entries in a thread dictionary 561
8.8 Entries in a bead dictionary 561
8.9 Entries in a transition dictionary 563
8.10 Entries in a navigation node dictionary 567
8.11 Entries common to all annotation dictionaries 570
8.12 Annotation flags 573
8.13 Entries in a border style dictionary 576
8.14 Entries in a border effect dictionary 577
8.15 Entries in an appearance dictionary 579
8.16 Annotation types 580
8.17 Additional entries specific to markup annotations 583
8.18 Annotation states 585
Tables
xv
8.19 Additional entries specific to a text annotation 586
8.20 Additional entries specific to a link annotation 587
8.21 Additional entries specific to a free text annotation 589
8.22 Additional entries specific to a line annotation 590
8.23 Line ending styles 593
8.24 Additional entries specific to a square or circle annotation 594
8.25 Additional entries specific to a polygon or polyline annotation 595
8.26 Additional entries specific to text markup annotations 596
8.27 Additional entries specific to a caret annotation 597
8.28 Additional entries specific to a rubber stamp annotation 598
8.29 Additional entries specific to an ink annotation 598
8.30 Additional entries specific to a pop-up annotation 599
8.31 Additional entries specific to a file attachment annotation 600
8.32 Additional entries specific to a sound annotation 601
8.33 Additional entries specific to a movie annotation 601
8.34 Additional entries specific to a screen annotation 602
8.35 Additional entries specific to a widget annotation 603
8.36 Entries in an appearance characteristics dictionary 604
8.37 Additional entries specific to a watermark annotation 606
8.38 Entries in a fixed print dictionary 607
8.39 Entries common to all action dictionaries 610
8.40 Entries in an annotation’s additional-actions dictionary 611
8.41 Entries in a page object’s additional-actions dictionary 612
8.42 Entries in a form field’s additional-actions dictionary 612
8.43 Entries in the document catalog’s additional-actions dictionary 613
8.44 Action types 615
8.45 Additional entries specific to a go-to action 616
8.46 Additional entries specific to a remote go-to action 617
8.47 Additional entries specific to an embedded go-to action 618
8.48 Entries specific to a target dictionary 619
8.49 Additional entries specific to a launch action 622
8.50 Entries in a Windows launch parameter dictionary 622
8.51 Additional entries specific to a thread action 623
8.52 Additional entries specific to a URI action 624
8.53 Entry in a URI dictionary 625
8.54 Additional entries specific to a sound action 625
8.55 Additional entries specific to a movie action 627
8.56 Additional entries specific to a hide action 628
8.57 Named actions 628
8.58 Additional entries specific to named actions 629
8.59 Additional entries specific to a set-OCG-state action 629
8.60 Additional entries specific to a rendition action 631
8.61 Additional entries specific to a transition action 632
Tables
xvi
8.62 Additional entries specific to a go-to-3D-view action 633
8.63 Entries in the interactive form dictionary 635
8.64 Signature flags 636
8.65 Entries common to all field dictionaries 637
8.66 Field flags common to all field types 638
8.67 Additional entries common to all fields containing variable text 640
8.68 XHTML Elements used in rich text strings 642
8.69 Attributes of the <body> element 643
8.70 CSS2 style attributes used in rich text strings 644
8.71 Field flags specific to button fields 648
8.72 Additional entry specific to check box and radio button fields 650
8.73 Field flags specific to text fields 653
8.74 Additional entry specific to a text field 654
8.75 Field flags specific to choice fields 656
8.76 Additional entries specific to a choice field 657
8.77 Additional entries specific to a signature field 659
8.78 Entries in a signature field lock dictionary 659
8.79 Entries in a signature field seed value dictionary 660
8.80 Entries in a certificate seed value dictionary 661
8.81 Additional entries specific to a submit-form action 662
8.82 Flags for submit-form actions 663
8.83 Additional entries specific to a reset-form action 667
8.84 Flag for reset-form actions 667
8.85 Additional entries specific to an import-data action 668
8.86 Additional entries specific to a JavaScript action 668
8.87 Entry in the FDF trailer dictionary 672
8.88 Entries in the FDF catalog dictionary 673
8.89 Entries in the FDF dictionary 673
8.90 Additional entry in an embedded file stream dictionary for an encrypted
FDF file 675
8.91 Entries in the JavaScript dictionary 676
8.92 Entries in an FDF field dictionary 677
8.93 Entries in an icon fit dictionary 679
8.94 Entries in an FDF page dictionary 680
8.95 Entries in an FDF template dictionary 680
8.96 Entries in an FDF named page reference dictionary 681
8.97 Additional entry for annotation dictionaries in an FDF file 681
8.98 Entries in a signature dictionary 686
8.99 Entries in a signature reference dictionary 689
8.100 Entries in the DocMDP transform parameters dictionary 692
8.101 Entries in the UR transform parameters dictionary 693
8.102 Entries in the FieldMDP transform parameters dictionary 695
8.103 Entries in a permissions dictionary 700
Tables
xvii
8.104 Entries in a legal attestation dictionary 701
8.105 Entries in a viewport dictionary 704
8.106 Entries in a measure dictionary 705
8.107 Additional entries in a rectilinear measure dictionary 705
8.108 Entries in a number format dictionary 707
9.1 Entries common to all rendition dictionaries 716
9.2 Entries in a rendition MH/BE dictionary 716
9.3 Entries in a media criteria dictionary 716
9.4 Entries in a minimum bit depth dictionary 717
9.5 Entries in a minimum screen size dictionary 718
9.6 Additional entries in a media rendition dictionary 719
9.7 Additional entries specific to a selector rendition dictionary 719
9.8 Entries common to all media clip dictionaries 720
9.9 Additional entries in a media clip data dictionary 720
9.10 Entries in a media permissions dictionary 722
9.11 Entries in a media clip data MH/BE dictionary 723
9.12 Additional entries in a media clip section dictionary 723
9.13 Entries in a media clip section MH/BE dictionary 725
9.14 Entries in a media play parameters dictionary 725
9.15 Entries in a media play parameters MH/BE dictionary 726
9.16 Entries in a media duration dictionary 727
9.17 Entries in a media screen parameters dictionary 728
9.18 Entries in a media screen parameters MH/BE dictionary 728
9.19 Entries in a floating window parameters dictionary 730
9.20 Entries common to all media offset dictionaries 732
9.21 Additional entries in a media offset time dictionary 732
9.22 Additional entries in a media offset frame dictionary 732
9.23 Additional entries in a media offset marker dictionary 732
9.24 Entries in a timespan dictionary 733
9.25 Entries in a media players dictionary 734
9.26 Entries in a media player info dictionary 735
9.27 Entries in a software identifier dictionary 736
9.28 Monitor specifier values 738
9.29 Additional entries specific to a sound object 739
9.30 Entries in a movie dictionary 741
9.31 Entries in a movie activation dictionary 742
9.32 Entries in a slideshow dictionary 744
9.33 Additional entries specific to a 3D annotation 747
9.34 Entries in a 3D activation dictionary 750
9.35 Additional entries in a 3D stream dictionary 752
9.36 Entries in a 3D reference dictionary 754
9.37 Entries in a 3D view dictionary 757
9.38 Entries in a projection dictionary 760
Tables
xviii
9.39 Entries in a 3D background dictionary 764
10.1 Predefined procedure sets 770
10.2 Entries in the document information dictionary 772
10.3 Additional entries in a metadata stream dictionary 774
10.4 Additional entry for components having metadata 774
10.5 Entries in a page-piece dictionary 777
10.6 Entries in an application data dictionary 777
10.7 Marked-content operators 779
10.8 Entries in the mark information dictionary 785
10.9 Entries in the structure tree root 786
10.10 Entries in a structure element dictionary 787
10.11 Entries in a marked-content reference dictionary 792
10.12 Entries in an object reference dictionary 796
10.13 Additional dictionary entries for structure element access 798
10.14 Entry common to all attribute object dictionaries 801
10.15 Additional entries in an attribute object dictionary for user properties 804
10.16 Entries in a user property dictionary 805
10.17 Property list entries for artifacts 814
10.18 Derivation of font characteristics 821
10.19 Font Selector Attributes 822
10.20 Standard structure types for grouping elements 828
10.21 Block-level structure elements 830
10.22 Standard structure types for paragraphlike elements 830
10.23 Standard structure types for list elements 831
10.24 Standard structure types for table elements 832
10.25 Standard structure types for inline-level structure elements 834
10.26 Standard structure types for Ruby and Warichu elements (PDF 1.5) 840
10.27 Standard structure types for illustration elements 841
10.28 Standard attribute owners 843
10.29 Standard layout attributes 845
10.30 Standard layout attributes common to all standard structure types 846
10.31 Additional standard layout attributes specific to block-level structure
elements 851
10.32 Standard layout attributes specific to inline-level structure elements 855
10.33 Standard column attributes 861
10.34 Standard list attribute 862
10.35 Standard table attributes 863
10.36 Entries in the Web Capture information dictionary 874
10.37 Entries common to all Web Capture content sets 882
10.38 Additional entries specific to a Web Capture page set 882
10.39 Additional entries specific to a Web Capture image set 883
10.40 Entries in a source information dictionary 884
10.41 Entries in a URL alias dictionary 885
Tables
xix
10.42 Entries in a Web Capture command dictionary 886
10.43 Web Capture command flags 887
10.44 Entries in a Web Capture command settings dictionary 888
10.45 Entries in a box color information dictionary 895
10.46 Entries in a box style dictionary 895
10.47 Additional entries specific to a printer’s mark annotation 896
10.48 Additional entries specific to a printer’s mark form dictionary 896
10.49 Entries in a separation dictionary 897
10.50 Entries in a PDF/X output intent dictionary 899
10.51 Additional entries specific to a trap network annotation 905
10.52 Additional entries specific to a trap network appearance stream 906
10.53 Entry in an OPI version dictionary 907
10.54 Entries in a version 1.3 OPI dictionary 908
10.55 Entries in a version 2.0 OPI dictionary 911
A.1 PDF content stream operators 913
C.1 Architectural limits 920
D.1 Latin-text encodings 924
F. 1 Entries in the linearization parameter dictionary 947
F. 2 Standard hint tables 951
F. 3 Page offset hint table, header section 959
F. 4 Page offset hint table, per-page entry 960
F. 5 Shared object hint table, header section 962
F. 6 Shared object hint table, shared object group entry 963
F. 7 Thumbnail hint table, header section 964
F. 8 Thumbnail hint table, per-page entry 965
F. 9 Generic hint table 966
F.10 Extended generic hint table 967
F.11 Embedded file stream hint table, header section 968
F.12 Embedded file stream hint table, per-embedded file stream group
entries 968
G.1 Objects in minimal example 976
G.2 Objects in simple text string example 978
G.3 Objects in simple graphics example 980
G.4 Object usage after adding four text annotations 993
G.5 Object usage after deleting two text annotations 996
G.6 Object usage after adding three text annotations 998
H.1 Abbreviations for standard filter names 1007
H.2 Acrobat behavior with unknown filters 1007
H.3 Names of standard fonts 1015
H.4 Recommended media types 1028
I.1 Data added to object digest for basic object types 1038
Tables
xx
xxi
Preface
The origins of the Portable Document Format and the Adobe
®
Acrobat
®
product
family date to early 1990. At that time, the PostScript
®
page description language
was rapidly becoming the worldwide standard for the production of the printed
page. PDF builds on the PostScript page description language by layering a docu-
ment structure and interactive navigation features on PostScript’s underlying im-
aging model, providing a convenient, efficient mechanism enabling documents
to be reliably viewed and printed anywhere.
The PDF specification was first published at the same time the first Acrobat
products were introduced in 1993. Since then, updated versions of the specifica-
tion have been and continue to be available from Adobe on the World Wide Web.
This edition, like several before it, is available in professionally published book
form, as well as in PDF form. (The PDF 1.5 edition was available only in PDF
form.) It includes the precise documentation of the underlying imaging model
from PostScript along with the PDF-specific features that are combined in ver-
sion 1.6 of the PDF standard.
Over the past eleven years, aided by the explosive growth of the Internet, PDF has
become the de facto standard for the electronic exchange of documents. Well over
500 million copies of the free Adobe Reader
®
software have been distributed
around the world, facilitating efficient sharing of digital content. In addition, PDF
is now the industry standard for the intermediate representation of printed mate-
rial in electronic prepress systems for conventional printing applications. As ma-
jor corporations, government agencies, and educational institutions streamline
their operations by replacing paper-based workflow with electronic exchange of
information, the impact and opportunity for the application of PDF will continue
to grow at a rapid pace.
PDF is the file format that underlies the Adobe
®
Intelligent Document Platform,
facilitating the process of creating, managing, securing, collecting, and exchang-
ing digital content on diverse platforms and devices. The Intelligent Document
Preface
xxii
Platform fulfills a set of requirements related to business process needs for the
global desktop user, including:
• Preservation of document fidelity across the enterprise, independently of the
device, platform, and software
• Merging of content from diverse sources—Web sites, word processing and
spreadsheet programs, scanned documents, photos, and graphics—into one
self-contained document while maintaining the integrity of all original source
documents
• Real-time collaborative editing of documents from multiple locations or plat-
forms
• Digital signatures to certify authenticity
• Security and permissions to allow the creator to retain control of the document
and associated rights
• Accessibility of content to those with disabilities
• Extraction and reuse of content using other file formats and applications
• Electronic forms to gather data and integrate it with business systems.
A significant number of third-party developers and systems integrators offer cus-
tomized enhancements and extensions to Adobe’s core family of products. Adobe
publishes the PDF specification in order to encourage the development of such
third-party applications.
The emergence of PDF as a standard for electronic information exchange is the
result of concerted effort by many individuals in both the private and public sec-
tors. Without the dedication of Adobe employees, our industry partners, and our
customers, the widespread acceptance of PDF could not have been achieved. We
thank all of you for your continuing support and creative contributions to the
success of PDF.
Chuck Geschke and John Warnock
November 2004
1
CHAPTER 1
1Introduction
The Adobe Portable Document Format (PDF) is the native file format of the
Adobe
®
Acrobat
®
family of products. The goal of these products is to enable users
to exchange and view electronic documents easily and reliably, independently of
the environment in which they were created. PDF relies on the same imaging
model as the PostScript
®
page description language to describe text and graphics
in a device-independent and resolution-independent manner. To improve perfor-
mance 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 and document interchange.
1.1 About This Book
This book provides a description of the PDF file format and is intended primarily
for developers of PDF producer applications that create PDF files directly. It also
contains enough information to allow developers to write PDF consumer applica-
tions that read existing PDF files and interpret or modify their contents.
Although the PDF specification is independent of any particular software imple-
mentation, some PDF features are best explained by describing the way they are
processed by a typical application program. In such cases, this book uses the Ac-
robat family of PDF viewer applications as its model. (The prototypical viewer is
the fully capable Acrobat product, not the limited Adobe Reader
®
product.) Ap-
pendix C discusses some implementation limits in the Acrobat viewer applica-
tions, even though these limits are not part of the file format itself. Appendix H
provides compatibility and implementation notes that describe how Acrobat
viewers behave when they encounter newer features they do not understand and
specify areas in which the Acrobat products diverge from the specification pre-
IntroductionCHAPTER 1
2
sented in this book. Implementors of PDF producer and consumer applications
can use this information as guidance.
This edition of the PDF Reference describes version 1.6 of PDF. (See implementa-
tion note 1 in Appendix H.) Throughout the book, information specific to partic-
ular versions of PDF is marked with indicators such as (PDF 1.3) or (PDF 1.4).
Features so marked may be new or substantially redefined in that version. Fea-
tures designated (PDF 1.0) have generally been superseded in later versions; un-
less otherwise stated, features identified as specific to other versions are
understood to be available in later versions as well. (PDF consumer applications
designed for a specific PDF version generally ignore newer features they do not
recognize; implementation notes in Appendix H point out exceptions.)
Note: In this edition, the term consumer is generally used to refer to PDF processing
applications; viewer is reserved for applications that implement features that inter-
act with users. This distinction is not always clear, however, since non-interactive
applications may process objects in PDF documents (such as annotations) that rep-
resent interactive features.
The rest of the book is organized as follows:
• Chapter 2, “Overview,” briefly introduces the overall architecture of PDF and
the design considerations behind it, compares it with the PostScript language,
and describes the underlying imaging model that they share.
• Chapter 3, “Syntax,” presents the syntax of PDF at the object, file, and docu-
ment level. It sets the stage for subsequent chapters, which describe how that
information is interpreted as page descriptions, interactive navigational aids,
and application-level logical structure.
• Chapter 4, “Graphics,” describes the graphics operators used to describe the
appearance of pages in a PDF document.
• Chapter 5, “Text,” discusses PDF’s special facilities for presenting text in the
form of character shapes, or glyphs, defined by fonts.
• Chapter 6, “Rendering,” considers how device-independent content descrip-
tions are matched to the characteristics of a particular output device.
• Chapter 7, “Transparency,” discusses the operation of the transparent imaging
model, introduced in PDF 1.4, in which objects can be painted with varying
degrees of opacity, allowing the previous contents of the page to show through.
About This BookSECTION 1.1
3
• Chapter 8, “Interactive Features,” describes those features of PDF that allow a
user to interact with a document on the screen by using the mouse and key-
board.
• Chapter 9, “Multimedia Features,” describes those features of PDF that support
embedding and playing multimedia content.
• Chapter 10, “Document Interchange,” shows how PDF documents can incorpo-
rate higher-level information that is useful for the interchange of documents
among applications.
• Appendix A, “Operator Summary,” lists all the operators used in describing the
visual content of a PDF document.
• Appendix B, “Operators in Type 4 Functions,” summarizes the PostScript oper-
ators that can be used in PostScript calculator functions, which contain code
written in a small subset of the PostScript language.
• Appendix C, “Implementation Limits,” describes typical size and quantity limits
imposed by the Acrobat viewer applications.
• Appendix D, “Character Sets and Encodings,” lists the character sets and en-
codings that are assumed to be predefined in any PDF consumer application.
• Appendix E, “PDF Name Registry,” discusses a registry, maintained for devel-
opers by Adobe Systems, that contains private names and formats used by PDF
producers or Acrobat plug-in extensions.
• Appendix F, “Linearized PDF,” describes a special form of PDF file organization
designed to work efficiently in network environments.
• Appendix G, “Example PDF Files,” presents several examples showing the
structure of actual PDF files, ranging from one containing a minimal one-page
document to one showing how the structure of a PDF file evolves over the
course of several revisions.
• Appendix H, “Compatibility and Implementation Notes,” provides details on
the behavior of Acrobat viewer applications and describes how consumer appli-
cations should handle PDF files containing features that they do not recognize.
• Appendix I, “Computation of Object Digests,” describes in detail an algorithm
for calculating an object digest (discussed in Section 8.7, “Digital Signatures”).
A color plate section provides illustrations of some of PDF’s color-related fea-
tures. References in the text of the form “see Plate 1” refer to the contents of this
section.
IntroductionCHAPTER 1
4
The book concludes with a Bibliography and an Index.
1.2 Introduction to PDF 1.6 Features
Several features have been introduced or modified in PDF 1.6. The following is a
list of the most significant additions, along with the primary sections where the
material is discussed (Section 1.3 below describes PDF 1.5 changes):
• Encryption enhancements to support using the AES (Advanced Encryption
Standard) algorithm and to selectively encrypt embedded files (Section 3.5,
“Encryption”).
• The abilility to specify the size of the unit in default user space, enabling the
maximum page size of a PDF document to be increased (“User Space” on page
170).
• An enhancement to the syntax of DeviceN color spaces to support NChannel
color spaces, which give applications greater flexibility when representing col-
ors that are not available on a target device (“DeviceN Color Spaces” on page
238).
• Greater flexibility in specifying the visibility of graphics based on the state of
optional content groups (“Optional Content Membership Dictionaries” on
page 335), and the ability to lock the states of groups (“Optional Content Con-
figuration Dictionaries” on page 345).
• New facilities for embedding OpenType fonts in PDF files (Section 5.8,
“Embedded Font Programs”).
• Enhancements to markup annotations, including the ability to group them and
specify their intent (“Markup Annotations” on page 581, “Free Text Annota-
tions” on page 588, “Line Annotations” on page 590, and “Polygon and Polyline
Annotations” on page 595).
• The ability to specify non-rectangular regions for link annotations (“Link An-
notations” on page 587).
• The ability to specify objects that should be printed at a specific size, regardless
of the dimensions of the printed page (“Watermark Annotations” on page 606).
• Additional support for embedded file attachments, including cross-document
linking to and from embedded files (“Embedded Go-To Actions” on page 617).
Introduction to PDF 1.5 FeaturesSECTION 1.3
5
• Enhancements and clarifications to digital signatures related to usage rights
and MDP (modification detection and prevention) signatures (Section 8.7,
“Digital Signatures”).
• The ability to accurately specify relationships between the dimensions of ob-
jects on a page and their real-world counterparts (Section 8.8, “Measurement
Properties”).
• The ability to incorporate models of three-dimensional graphical data, using
the U3D format, in a PDF file (Section 9.5, “3D Artwork”).
• The ability to define user properties that contain non-drawing-related informa-
tion about objects on a page (“User Properties” on page 804).
• The addition of Tagged PDF attributes relating to the layout of content in col-
umns (“Column Attributes” on page 861), and the ability to specify content
with in a Tagged PDF document whose page content order cannot be accurate-
ly determined (“Page Content Order” on page 817).
1.3 Introduction to PDF 1.5 Features
Several features were introduced or modified in PDF 1.5 and were described in
the previous edition of this reference. Because that document was not published
professionally and was available only on the Web, the list of significant changes is
repeated here for convenience:
• The ability to display images using JPEG2000 compression (Section 3.3.8,
“JPXDecode Filter”) and to allow 16-bit images (Section 4.8.4, “Image Dictio-
naries”).
• Additional options for the encryption of documents (Section 3.5, “Encryp-
tion”). Major new features include crypt filters (Section 3.3.9, “Crypt Filter”
and “Section 3.5.4, “Crypt Filters”) and syntax for public-key security handlers
(Section 3.5.3, “Public-Key Security Handlers”, which contains information in-
troduced in PDF 1.3 but not previously documented in the PDF Reference).
• An extension to the use of streams to allow greater compression of PDF files
(Section 3.4.6, “Object Streams” and Section 3.4.7, “Cross-Reference Streams”).
• The ability to selectively view or hide content in a PDF document (Section 4.10,
“Optional Content” and “Set-OCG-State Actions” on page 629).
• New predefined CMaps and character collections (“Predefined CMaps” on
page 412).
IntroductionCHAPTER 1
6
• Enhancements to interactive presentations (Section 8.3.3, “Presentations”), in-
cluding navigation between pages (“Sub-page Navigation” on page 566) and a
new action type (“Transition Actions” on page 632).
• Additional annotation types (Section 8.4.5, “Annotation Types”) and other en-
hancements to annotations (Section 8.4, “Annotations”).
• Miscellaneous enhancements to interactive forms (Section 8.6, “Interactive
Forms”), including support for forms based on Adobe’s XML Forms Architec-
ture (Section 8.6.7, “XFA Forms”) and the ability to use styled text in form
fields and markup annotations (“Rich Text Strings” on page 642).
• Enhancements related to digital signatures and signature fields, including the
ability to compute object signatures (“Signature Fields” on page 658, Section
8.7, “Digital Signatures,” and Appendix I, “Computation of Object Digests”).
• Greatly enhanced support for embedding and playback of multimedia (Section
9.1, “Multimedia”, “Screen Annotations” on page 602 and “Rendition Actions”
on page 630).
• The ability to allow the display of a PDF file as a slideshow (Section 9.4, “Alter-
nate Presentations”). (This feature is considered part of PDF 1.4, although it
was not previously documented.)
• Enhancements to Tagged PDF (Section 10.7, “Tagged PDF”) and accessibility
features (Section 10.8, “Accessibility Support”). Related updated information is
found in Section 5.7, “Font Descriptors” and Section 5.9, “Extraction of Text
Content.”
1.4 Related Publications
PDF and the PostScript page description language share the same underlying
Adobe imaging model. A document can be converted straightforwardly between
PDF and the PostScript language; the two representations produce the same out-
put when printed. However, PostScript includes a general-purpose programming
language framework not present in PDF. The PostScript Language Reference is the
comprehensive reference for the PostScript language and its imaging model.
PDF and PostScript support several standard formats for font programs, includ-
ing Adobe Type 1, CFF (Compact Font Format), TrueType, OpenType and CID-
keyed fonts. The PDF manifestations of these fonts are documented in this book.
However, the specifications for the font files themselves are published separately,
because they are highly specialized and are of interest to a different user commu-
Intellectual PropertySECTION 1.5
7
nity. A variety of Adobe publications are available on the subject of font formats.
The Bibliography lists these publications, as well as additional documents related
to PDF and the contents of this book.
1.5 Intellectual Property
The general idea of using an interchange format for electronic documents is in
the public domain. Anyone is free to devise a set of unique data structures and
operators that define an interchange format for electronic documents. However,
Adobe Systems Incorporated owns the copyright for the particular data struc-
tures and operators and the written specification constituting the interchange for-
mat called the Portable Document Format. Thus, these elements of the Portable
Document Format 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 standard. This enables the public to distinguish
between the Portable Document Format and other interchange formats for elec-
tronic documents. However, Adobe desires to promote the use of the Portable
Document Format for information interchange among diverse products and
applications. Accordingly, Adobe gives anyone copyright permission, subject to
the conditions stated below, to:
• Prepare files whose 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, prints, or otherwise interprets the contents
• Copy Adobe’s copyrighted list of data structures and operators, as well as the
example code and PostScript language function definitions in the written
specification, to the extent necessary to use the Portable Document Format for
the purposes above
The conditions of such copyright permission are:
• Authors of software that accepts input in the form of the Portable Document
Format must make reasonable efforts to ensure that the software they create re-
spects the access permissions and permissions controls listed in Table 3.20 of
this specification, to the extent that they are used in any particular document.
IntroductionCHAPTER 1
8
These access permissions express the rights that the document’s author has
granted to users of the document. It is the responsibility of Portable Document
Format consumer software to respect the author’s intent.
• Anyone who uses the copyrighted list of data structures and operators, as stated
above, must include an appropriate copyright notice.
This limited right to use the copyrighted list of data structures and operators does
not include the right to copy this book, other copyrighted material from Adobe,
or the software in any of Adobe’s products that use the Portable Document For-
mat, in whole or in part, nor does it include the right to use any Adobe patents,
except as may be permitted by an official Adobe Patent Clarification Notice (see
the Bibliography).
Acrobat, Acrobat Capture, Adobe Intelligent Document Platform, Adobe Reader,
ePaper, the “Get Adobe Reader” Web logo, the “Adobe PDF” Web logo, and all
other trademarks, service marks, and logos used by Adobe (the “Marks”) are the
registered trademarks or trademarks of Adobe Systems Incorporated in the Unit-
ed States and other countries. Nothing in this book is intended to grant you any
right or license to use the Marks for any purpose.
9
CHAPTER 2
2Overview
Adobe PDF is a file format for representing documents in a manner independent
of the application software, hardware, and operating system used to create them
and of the output device on which they are to be displayed or printed. A PDF doc-
ument consists of a collection of objects that together describe the appearance of
one or more pages, possibly accompanied by additional interactive elements and
higher-level application data. A PDF file contains the objects making up a PDF
document along with associated structural information, all represented as a sin-
gle self-contained sequence of bytes.
A document’s pages (and other visual elements) can contain any combination of
text, graphics, and images. A page’s appearance is described by a PDF content
stream, which contains a sequence of graphics objects to be painted on the page.
This appearance is fully specified; all layout and formatting decisions have al-
ready been made by the application generating the content stream.
In addition to describing the static appearance of pages, a PDF document can
contain interactive elements that are possible only in an electronic representation.
PDF supports annotations of many kinds for such things as text notes, hypertext
links, markup, file attachments, sounds, and movies. A document can define its
own user interface; keyboard and mouse input can trigger actions that are speci-
fied by PDF objects. The document can contain interactive form fields to be filled
in by the user, and can export the values of these fields to or import them from
other applications.
Finally, a PDF document can contain higher-level information that is useful for
interchange of content among applications. In addition to specifying appearance,
a document’s content can include identification and logical structure information
OverviewCHAPTER 2
10
that allows it to be searched, edited, or extracted for reuse elsewhere. PDF is par-
ticularly well suited for representing a document as it moves through successive
stages of a prepress production workflow.
2.1 Imaging Model
At the heart of PDF is its ability to describe the appearance of sophisticated
graphics and typography. This ability is achieved through the use of the Adobe
imaging model, the same high-level, device-independent representation used in
the PostScript page description language.
Although application programs could theoretically describe any page as a full-
resolution pixel array, the resulting file would be bulky, device-dependent, and
impractical for high-resolution devices. A high-level imaging model enables
applications to describe the appearance of pages containing text, graphical
shapes, and sampled images in terms of abstract graphical elements rather than
directly in terms of device pixels. Such a description is economical and device-
independent, and can be used to produce high-quality output on a broad range of
printers, displays, and other output devices.
2.1.1 Page Description Languages
Among its other roles, PDF serves as a page description language, a language for
describing the graphical appearance of pages with respect to an imaging model.
An application program produces output through a two-stage process:
1. The application generates a device-independent description of the desired out-
put in the page description language.
2. A program controlling a specific output device interprets the description and
renders it on that device.
The two stages may be executed in different places and at different times. The
page description language serves as an interchange standard for the compact, de-
vice-independent transmission and storage of printable or displayable docu-
ments.
Imaging ModelSECTION 2.1
11
2.1.2 Adobe Imaging Model
The Adobe imaging model is a simple and unified view of two-dimensional
graphics borrowed from the graphic arts. In this model, “paint” is placed on a
page in selected areas:
• The painted figures can be in the form of character shapes (glyphs), geometric
shapes, lines, or sampled images such as digital representations of photographs.
• The paint may be in color or in black, white, or any shade of gray. It may also
take the form of a repeating pattern (PDF 1.2) or a smooth transition between
colors (PDF 1.3).
• Any of these elements may be clipped to appear within other shapes as they are
placed onto the page.
A page’s content stream contains operands and operators describing a sequence of
graphics objects. A PDF consumer application maintains an implicit current page
that accumulates the marks made by the painting operators. Initially, the current
page is completely blank. For each graphics object encountered in the content
stream, the application places marks on the current page, which replace or com-
bine with any previous marks they may overlay. Once the page has been com-
pletely composed, the accumulated marks are rendered on the output medium
and the current page is cleared to blank again.
PDF 1.3 and earlier versions use an opaque imaging model in which each new
graphics object painted onto a page completely obscures the previous contents of
the page at those locations (subject to the effects of certain optional parameters
that may modify this behavior; see Section 4.5.6, “Overprint Control”). No matter
what color an object has—white, black, gray, or color—it is placed on the page as
if it were applied with opaque paint. PDF 1.4 introduces a transparent imaging
model in which objects painted on the page are not required to be fully opaque.
Instead, newly painted objects are composited with the previously existing con-
tents of the page, producing results that combine the colors of the object and its
backdrop according to their respective opacity characteristics. The transparent
imaging model is described in Chapter 7.
The principal graphics objects (among others) are as follows:
• A path object consists of a sequence of connected and disconnected points,
lines, and curves that together describe shapes and their positions. It is built up
OverviewCHAPTER 2
12
through the sequential application of path construction operators, each of which
appends one or more new elements. The path object is ended by a path-
painting operator, which paints the path on the page in some way. The principal
path-painting operators are
S (stroke), which paints a line along the path, and f
(fill), which paints the interior of the path.
• A text object consists of one or more glyph shapes representing characters of
text. The glyph shapes for the characters are described in a separate data struc-
ture called a font. Like path objects, text objects can be stroked or filled.
• An image object is a rectangular array of sample values, each representing a
color at a particular position within the rectangle. Such objects are typically
used to represent photographs.
The painting operators require various parameters, some explicit and others im-
plicit. Implicit parameters include the current color, current line width, current
font (typeface and size), and many others. Together, these implicit parameters
make up the graphics state; there are operators for setting the value of each im-
plicit parameter in the graphics state. Painting operators use the values currently
in effect at the time they are invoked.
One additional implicit parameter in the graphics state modifies the results of
painting graphics objects. The current clipping path outlines the area of the cur-
rent page within which paint can be placed. Although painting operators may
attempt to place marks anywhere on the current page, only those marks falling
within the current clipping path affect the page; those falling outside it do not af-
fect the page. Initially, the current clipping path encompasses the entire imagea-
ble area of the page. It can temporarily be reduced to the shape defined by a path
or text object, or to the intersection of multiple such shapes. Marks placed by sub-
sequent painting operators are confined within that boundary.
2.1.3 Raster Output Devices
Much of the power of the Adobe imaging model derives from its ability to deal
with the general class of raster output devices. These encompass such technologies
as laser, dot-matrix, and ink-jet printers, digital imagesetters, and raster-scan
displays. The defining property of a raster output device is that a printed or dis-
played image consists of a rectangular array, or raster, of dots called pixels (picture
elements) that can be addressed individually. On a typical bilevel output device,
each pixel can be made either black or white. On some devices, pixels can be set
to intermediate shades of gray or to some color. The ability to set the colors of
Imaging ModelSECTION 2.1
13
individual pixels makes it possible to generate printed or displayed output that
can include text, arbitrary graphical shapes, and reproductions of sampled imag-
es.
The resolution of a raster output device measures the number of pixels per unit of
distance along the two linear dimensions. Resolution is typically—but not neces-
sarily—the same horizontally and vertically. Manufacturers’ decisions on device
technology and price/performance tradeoffs create characteristic ranges of reso-
lution:
• Computer displays have relatively low resolution, typically 75 to 110 pixels per
inch.
• Dot-matrix printers generally range from 100 to 250 pixels per inch.
• Ink-jet and laser-scanned xerographic printing technologies achieve medium-
level resolutions of 300 to 1400 pixels per inch.
• Photographic technology permits high resolutions of 2400 pixels per inch or
more.
Higher resolution yields better quality and fidelity of the resulting output but is
achieved at greater cost. As the technology improves and computing costs de-
crease, products evolve to higher resolutions.
2.1.4 Scan Conversion
An abstract graphical element (such as a line, a circle, a character glyph, or a
sampled image) is rendered on a raster output device by a process known as scan
conversion. Given a mathematical description of the graphical element, this pro-
cess determines which pixels to adjust and what values to assign to those pixels to
achieve the most faithful rendition possible at the available device resolution.
The pixels on a page can be represented by a two-dimensional array of pixel
values in computer memory. For an output device whose pixels can only be black
or white, a single bit suffices to represent each pixel. For a device that can repro-
duce gray levels or colors, multiple bits per pixel are required.
Note: Although the ultimate representation of a printed or displayed page is logically
a complete array of pixels, its actual representation in computer memory need not
consist of one memory cell per pixel. Some implementations use other representa-
OverviewCHAPTER 2
14
tions, such as display lists. The Adobe imaging model has been carefully designed
not to depend on any particular representation of raster memory.
For each graphical element that is to appear on the page, the scan converter sets
the values of the corresponding pixels. When the interpretation of the page de-
scription is complete, the pixel values in memory represent the appearance of the
page. At this point, a raster output process can render this representation (make it
visible) on a printed page or display screen.
Scan-converting a graphical shape, such as a rectangle or circle, entails determin-
ing which device pixels lie inside the shape and setting their values appropriately
(for example, to black). Because the edges of a shape do not always fall precisely
on the boundaries between pixels, some policy is required for deciding how to set
the pixels along the edges. Scan-converting a glyph representing a text character
is conceptually the same as scan-converting an arbitrary graphical shape. How-
ever, character glyphs are much more sensitive to legibility requirements and
must meet more rigid objective and subjective measures of quality.
Rendering grayscale elements on a bilevel device is accomplished by a technique
known as halftoning. The array of pixels is divided into small clusters according to
some pattern (called the halftone screen). Within each cluster, some pixels are set
to black and others to white in proportion to the level of gray desired at that loca-
tion on the page. When viewed from a sufficient distance, the individual dots be-
come imperceptible and the perceived result is a shade of gray. This enables a
bilevel raster output device to reproduce shades of gray and to approximate natu-
ral images such as photographs. Some color devices use a similar technique.
2.2 Other General Properties
This section describes other notable general properties of PDF, aside from its im-
aging model.
2.2.1 Portability
PDF files are represented as sequences of 8-bit binary bytes. A PDF file is de-
signed to be portable across all platforms and operating systems. The binary rep-
resentation is intended to be generated, transported, and consumed directly,
without translation between native character sets, end-of-line representations, or
other conventions used on various platforms.
Other General PropertiesSECTION 2.2
15
Any PDF file can also be represented in a form that uses only 7-bit ASCII
(American Standard Code for Information Interchange) character codes. This is
useful for the purpose of exposition, as in this book. However, this representation
is not recommended for actual use, since it is less efficient than the normal binary
representation. Regardless of which representation is used, PDF files must be
transported and stored as binary files, not as text files. Inadvertent changes, such
as conversion between text end-of-line conventions, will damage the file and may
render it unusable.
2.2.2 Compression
To reduce file size, PDF supports a number of industry-standard compression
filters:
• JPEG and (in PDF 1.5) JPEG2000 compression of color and grayscale images
• CCITT (Group 3 or Group 4), run-length, and (in PDF 1.4) JBIG2 compres-
sion of monochrome images
• LZW (Lempel-Ziv-Welch) and (beginning with PDF 1.2) Flate compression of
text, graphics, and images
Using JPEG compression, color and grayscale images can be compressed by a fac-
tor of 10 or more. Effective compression of monochrome images depends on the
compression filter used and the properties of the image, but reductions of 2:1 to
8:1 are common (or 20:1 to 50:1 for JBIG2 compression of an image of a page full
of text). LZW or Flate compression of the content streams describing all other
text and graphics in the document results in compression ratios of approximately
2:1. All of these compression filters produce binary data, which can be further
converted to ASCII base-85 encoding if a 7-bit ASCII representation is required.
2.2.3 Font Management
Managing fonts is a fundamental challenge in document interchange. Generally,
the receiver of a document must have the same fonts that were originally used to
create it. If a different font is substituted, its character set, glyph shapes, and met-
rics may differ from those in the original font. This substitution can produce un-
expected and unwanted results, such as lines of text extending into margins or
overlapping with graphics.
OverviewCHAPTER 2
16
PDF provides various means for dealing with font management:
• The original font programs can be embedded in the PDF file, which ensures the
most predictable and dependable results. PDF supports various font formats,
including Type 1, TrueType
®
, OpenType, and CID-keyed fonts.
• To conserve space, a font subset can be embedded, containing just the glyph
descriptions for those characters that are actually used in the document. Also,
Type 1 fonts can be represented in a special compact format.
• PDF prescribes a set of 14 standard fonts that can be used without prior defini-
tion. These include four faces each of three Latin text typefaces (Courier,
Helvetica*, and Times*), as well as two symbolic fonts (Symbol and ITC Zapf
Dingbats
®
). These fonts, or suitable substitute fonts with the same metrics, are
required to be available in all PDF consumer applications.
• A PDF file can refer by name to fonts that are not embedded in the PDF file. In
this case, a PDF consumer can use those fonts if they are available in its envi-
ronment. This approach suffers from the uncertainties noted above.
• A PDF file contains a font descriptor for each font that it uses (other than the
standard 14). The font descriptor includes font metrics and style information,
enabling an application to select or synthesize a suitable substitute font if neces-
sary. Although the glyphs’ shapes differ from those intended, their placement is
accurate.
Font management is primarily concerned with producing the correct appearance
of text—that is, the shape and placement of glyphs. However, it is sometimes nec-
essary for a PDF application to extract the meaning of the text, represented in
some standard information encoding such as Unicode. In some cases, this in-
formation can be deduced from the encoding used to represent the text in the
PDF file. Otherwise, the PDF producer application should specify the mapping
explicitly by including a special object, the
ToUnicode CMap.
2.2.4 Single-Pass File Generation
Because of system limitations and efficiency considerations, it may be necessary
or desirable for an application program to generate a PDF file in a single pass. For
example, the program may have limited memory available or be unable to open
temporary files. For this reason, PDF supports single-pass generation of files.
Although some PDF objects must specify their length in bytes, a mechanism is
provided allowing the length to follow the object in the PDF file. In addition, in-
Other General PropertiesSECTION 2.2
17
formation such as the number of pages in the document can be written into the
file after all pages have been generated.
A PDF file that is generated in a single pass is generally not ordered for most effi-
cient viewing, particularly when accessing the contents of the file over a network.
When generating a PDF file that is intended to be viewed many times, it is worth-
while to perform a second pass to optimize the order in which objects occur in
the file. PDF specifies a particular file organization, Linearized PDF, which is doc-
umented in Appendix F. Other optimizations are also possible, such as detecting
duplicated sequences of graphics objects and collapsing them to a single shared
sequence that is specified only once.
2.2.5 Random Access
A PDF file should be thought of as a flattened representation of a data structure
consisting of a collection of objects that can refer to each other in any arbitrary
way. The order of the objects’ occurrence in the PDF file has no semantic signifi-
cance. In general, an application should process a PDF file by following references
from object to object, rather than by processing objects sequentially. This is par-
ticularly important for interactive document viewing or for any application in
which pages or other objects in the PDF file are accessed out of sequence.
To support such random access to individual objects, every PDF file contains a
cross-reference table that can be used to locate and directly access pages and other
important objects within the file. The cross-reference table is stored at the end of
the file, allowing applications that generate PDF files in a single pass to store it
easily and those that read PDF files to locate it easily. By using the cross-reference
table, the time needed to locate a page or other object is nearly independent of the
length of the document, allowing PDF documents containing hundreds or thou-
sands of pages to be accessed efficiently.
2.2.6 Security
PDF has two security features that can be used, separately or together, in any doc-
ument:
• The document can be encrypted so that only authorized users can access it.
There is separate authorization for the owner of the document and for all other
OverviewCHAPTER 2
18
users; the users’ access can be selectively restricted to allow only certain opera-
tions, such as viewing, printing, or editing.
• The document can be digitally signed to certify its authenticity. The signature
may take many forms, including a document digest that has been encrypted
with a public/private key, a biometric signature such as a fingerprint, and oth-
ers. Any subsequent changes to a signed PDF file invalidate the signature.
2.2.7 Incremental Update
Applications may allow users to modify PDF documents. Users should not have
to wait for the entire file—which can contain hundreds of pages or more—to be
rewritten each time modifications to the document are saved. PDF allows modifi-
cations to be appended to a file, leaving the original data intact. The addendum
appended when a file is incrementally updated contains only those objects that
were actually added or modified, and includes an update to the cross-reference
table. Incremental update allows an application to save modifications to a PDF
document in an amount of time proportional to the size of the modification rath-
er than the size of the file.
In addition, because the original contents of the document are still present in the
file, it is possible to undo saved changes by deleting one or more addenda. The
ability to recover the exact contents of an original document is critical when digi-
tal signatures have been applied and subsequently need to be verified.
2.2.8 Extensibility
PDF is designed to be extensible. Not only can new features be added, but appli-
cations based on earlier versions of PDF can behave reasonably when they en-
counter newer features that they do not understand. Appendix H describes how a
PDF consumer application should behave in such cases.
Additionally, PDF provides means for applications to store their own private in-
formation in a PDF file. This information can be recovered when the file is im-
ported by the same application, but it is ignored by other applications. Therefore,
PDF can serve as an application’s native file format while its documents can be
viewed and printed by other applications. Application-specific data can be stored
either as marked content annotating the graphics objects in a PDF content stream
or as entirely separate objects unconnected with the PDF content.
Creating PDFSECTION 2.3
19
2.3 Creating PDF
PDF files may be produced either directly by application programs or indirectly
by conversion from other file formats or imaging models. As PDF documents and
applications that process them become more prevalent, new ways of creating and
using PDF will be invented. One of the goals of this book is to make the file for-
mat accessible so that application developers can expand on the ideas behind
PDF and the applications that initially support it.
Many applications can generate PDF files directly, and some can import them as
well. This direct approach is preferable, since it gives the application access to the
full capabilities of PDF, including the imaging model and the interactive and doc-
ument interchange features. Alternatively, applications that do not generate PDF
directly can produce PDF output indirectly. There are two principal indirect
methods:
• The application describes its printable output by making calls to an application
programming interface (API) such as GDI in Microsoft
®
Windows
®
or Quick-
Draw in the Apple
®
Mac
®
OS. A software component called a printer driver in-
tercepts these calls and interprets them to generate output in PDF form.
• The application produces printable output directly in some other file format,
such as PostScript, PCL, HPGL, or DVI, which is converted to PDF by a sepa-
rate translation program.
Although these indirect strategies are often the easiest way to obtain PDF output
from an existing application, the resulting PDF files may not make the best use of
the high-level Adobe imaging model. This is because the information embodied
in the application’s API calls or in the intermediate output file often describes the
desired results at too low a level. Any higher-level information maintained by the
original application has been lost and is not available to the printer driver or
translator.
Figures 2.1 and 2.2 show how Acrobat products support these indirect
approaches. The Adobe PDF printer (Figure 2.1), available on the Windows and
Mac OS platforms, acts as a printer driver, intercepting graphics and text opera-
tions generated by a running application program through the operating system’s
API. Instead of converting these operations into printer commands and transmit-
ting them directly to a printer, Adobe PDF converts them to equivalent PDF op-
erators and embeds them in a PDF file. The result is a platform-independent file
that can be viewed and printed by a PDF viewer application, such as Acrobat,
OverviewCHAPTER 2
20
running on any supported platform—even a different platform from the one on
which the file was originally generated.
FIGURE 2.1 Creating PDF files using the Adobe PDF printer
Instead of describing their printable output through API calls, some applications
produce PostScript page descriptions directly—either because of limitations in
the QuickDraw or GDI imaging models or because the applications run on plat-
forms such as DOS or UNIX
®
, where no system-level printer driver exists. Post-
Script files generated by such applications can be converted to PDF files using the
Acrobat Distiller
®
application (see Figure 2.2). Because PostScript and PDF share
the same Adobe imaging model, Distiller can preserve the exact graphical content
of the PostScript file in the translation to PDF. Additionally, Distiller supports a
PostScript language extension, called
pdfmark, that allows the producing applica-
tion to embed instructions in the PostScript file for creating hypertext links, logi-
cal structure, and other interactive and document interchange features of PDF.
Acrobat
Macintosh application Windows application
Adobe PDF
printer
QuickDraw/
CoreGraphics
GDI
PDF
PDF and the PostScript LanguageSECTION 2.4
21
Again, the resulting PDF file can be viewed with a viewer application, such as Ac-
robat, on any supported platform.
FIGURE 2.2 Creating PDF files using Acrobat Distiller
2.4 PDF and the PostScript Language
The PDF operators for setting the graphics state and painting graphics objects are
similar to the corresponding operators in the PostScript language. Unlike Post-
Script, however, PDF is not a full-scale programming language; it trades reduced
flexibility for improved efficiency and predictability. PDF therefore differs from
PostScript in the following significant ways:
• PDF enforces a strictly defined file structure that allows an application to access
parts of a document in arbitrary order.
• To simplify the processing of content streams, PDF does not include common
programming language features such as procedures, variables, and control con-
structs.
• PDF files contain information such as font metrics to ensure viewing fidelity.
• A PDF file may contain additional information that is not directly connected
with the imaging model, such as hypertext links for interactive viewing and
logical structure information for document interchange.
Because of these differences, a PDF file generally cannot be transmitted directly
to a PostScript output device for printing (although a few such devices do also
PostScript
page description
Acrobat
PDF
Acrobat Distiller
OverviewCHAPTER 2
22
support PDF directly). An application printing a PDF document to a PostScript
device must follow these steps:
1. Insert procedure sets containing PostScript procedure definitions to implement
the PDF operators.
2. Extract the content for each page. Each content stream is essentially the script
portion of a traditional PostScript program using very specific procedures,
such as
m for moveto and l for lineto.
3. Decode compressed text, graphics, and image data as necessary. The compres-
sion filters used in PDF are compatible with those used in PostScript; they may
or may not be supported, depending on the LanguageLevel of the target output
device.
4. Insert any needed resources, such as fonts, into the PostScript file. These can
be either the original fonts or suitable substitute fonts based on the font met-
rics in the PDF file. Fonts may need to be converted to a format that the Post-
Script interpreter recognizes, such as Type 1 or Type 42.
5. Put the information in the correct order. The result is a traditional PostScript
program that fully represents the visual aspects of the document but no longer
contains PDF elements such as hypertext links, annotations, and bookmarks.
6. Transmit the PostScript program to the output device.
23
CHAPTER 3
3Syntax
This chapter covers everything about the syntax of PDF at the object, file, and
document level. It sets the stage for subsequent chapters, which describe how the
contents of a PDF file are interpreted as page descriptions, interactive navigation-
al aids, and application-level logical structure.
PDF syntax is best understood by thinking of it in four parts, as shown in Figure
3.1:
• Objects. A PDF document is a data structure composed from a small set of
basic types of data objects. Section 3.1, “Lexical Conventions,” describes the
character set used to write objects and other syntactic elements. Section 3.2,
“Objects,” describes the syntax and essential properties of the objects. Section
3.2.7, “Stream Objects,” provides complete details of the most complex data
type, the stream object.
• File structure. The PDF 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. Section 3.4, “File Structure,” de-
scribes the file structure. Section 3.5, “Encryption,” describes a file-level mecha-
nism for protecting a document’s contents from unauthorized access.
• Document structure. The PDF document structure specifies how the basic ob-
ject types are used to represent components of a PDF document: pages, fonts,
annotations, and so forth. Section 3.6, “Document Structure,” describes the
overall document structure; later chapters address the detailed semantics of the
components.
• Content streams. A PDF content stream contains a sequence of instructions de-
scribing the appearance of a page or other graphical entity. These instructions,
while also represented as objects, are conceptually distinct from the objects that
SyntaxCHAPTER 3
24
represent the document structure and are described separately. Section 3.7,
“Content Streams and Resources,” discusses PDF content streams and their as-
sociated resources.
FIGURE 3.1 PDF components
In addition, this chapter describes some data structures, built from basic objects,
that are so widely used that they can almost be considered basic object types in
their own right. These objects are covered in Sections 3.8, “Common Data Struc-
tures”; 3.9, “Functions”; and 3.10, “File Specifications.”
PDF’s object and file syntax is also used as the basis for other file formats. These
include the Forms Data Format (FDF), described in Section 8.6.6, “Forms Data
Format,” and the Portable Job Ticket Format (PJTF), described in Adobe Techni-
cal Note #5620, Portable Job Ticket Format.
3.1 Lexical Conventions
At the most fundamental level, a PDF file is a sequence of 8-bit bytes. These bytes
can be grouped into tokens according to the syntax rules described below. One or
more tokens are assembled to form higher-level syntactic entities, principally ob-
jects, which are the basic data values from which a PDF document is constructed.
PDF can be entirely represented using byte values corresponding to the visible
printable subset of the ASCII character set, plus white space characters such as
space, tab, carriage return, and line feed characters. ASCII is the American Stan-
dard Code for Information Interchange, a widely used convention for encoding a
Objects
File
structure
Document
structure
Content
stream
Lexical ConventionsSECTION 3.1
25
specific set of 128 characters as binary numbers. However, a PDF file is not re-
stricted to the ASCII character set; it can contain arbitrary 8-bit bytes, subject to
the following considerations:
• The tokens that delimit objects and that describe the structure of a PDF file are
all written in the ASCII character set, as are all the reserved words and the
names used as keys in standard dictionaries.
• The data values of certain types of objects—strings and streams—can be but
need not be written entirely in ASCII. For the purpose of exposition (as in this
book), ASCII representation is preferred. However, in actual practice, data that
is naturally binary, such as sampled images, is represented directly in binary for
compactness and efficiency.
• A PDF file containing binary data must be transported and stored by means
that preserve all bytes of the file faithfully; that is, as a binary file rather than a
text file. Such a file is not portable to environments that impose reserved char-
acter codes, maximum line lengths, end-of-line conventions, or other restric-
tions.
Note: In this chapter, the term character is synonymous with byte and merely refers
to a particular 8-bit value. This usage is entirely independent of any logical meaning
that the value may have when it is treated as data in specific contexts, such as repre-
senting human-readable text or selecting a glyph from a font.
3.1.1 Character Set
The PDF character set is divided into three classes, called regular, delimiter, and
white-space characters. This classification determines the grouping of characters
into tokens, except within strings, streams, and comments; different rules apply
in those contexts.
White-space characters (see Table 3.1) separate syntactic constructs such as names
and numbers from each other. All white-space characters are equivalent, except
in comments, strings, and streams. In all other contexts, PDF treats any sequence
of consecutive white-space characters as one character.
SyntaxCHAPTER 3
26
TABLE 3.1 White-space characters
The carriage return (CR) and line feed (LF) characters, also called newline char-
acters, are treated as end-of-line (EOL) markers. The combination of a carriage
return followed immediately by a line feed is treated as one EOL marker. For the
most part, EOL markers are treated the same as any other white-space characters.
However, sometimes an EOL marker is required or recommended—that is, the
following token must appear at the beginning of a line.
Note: The examples in this book illustrate a recommended convention for arranging
tokens into lines. However, the examples’ use of white space for indentation is purely
for clarity of exposition and is not recommended for practical use.
The delimiter characters
(, ), <, >, [, ], {, }, /, and % are special. They delimit syntac-
tic entities such as strings, arrays, names, and comments. Any of these characters
terminates the entity preceding it and is not included in the entity.
All characters except the white-space characters and delimiters are referred to as
regular characters. These characters include 8-bit binary characters that are out-
side the ASCII character set. A sequence of consecutive regular characters com-
prises a single token.
Note: PDF is case-sensitive; corresponding uppercase and lowercase letters are con-
sidered distinct.
DECIMAL HEXADECIMAL OCTAL NAME
0 00 000 Null (NUL)
9 09 011 Tab (HT)
10 0A 012 Line feed (LF)
12 0C 014 Form feed (FF)
13 0D 015 Carriage return (CR)
32 20 040 Space (SP)
ObjectsSECTION 3.2
27
3.1.2 Comments
Any occurrence of the percent sign character (%) outside a string or stream intro-
duces a comment. The comment consists of all characters between the percent
sign and the end of the line, including regular, delimiter, space, and tab charac-
ters. PDF ignores comments, treating them as if they were single white-space
characters. That is, a comment separates the token preceding it from the one fol-
lowing it; thus, the PDF fragment
abc% comment {/%) blah blah blah
123
is syntactically equivalent to just the tokens abc and 123.
Comments (other than the
%PDF1.4 and %%EOF comments described in Sec-
tion 3.4, “File Structure”) have no semantics. They are not necessarily preserved
by applications that edit PDF files (see implementation note 2 in Appendix H). In
particular, there is no PDF equivalent of the PostScript document structuring
conventions (DSC).
3.2 Objects
PDF supports eight basic types of objects:
• Boolean values
• Integer and real numbers
• Strings
• Names
• Arrays
• Dictionaries
• Streams
• The null object
Objects may be labeled so that they can be referred to by other objects. A labeled
object is called an indirect object.
SyntaxCHAPTER 3
28
The following sections describe each object type, as well as how to create and
refer to indirect objects.
3.2.1 Boolean Objects
PDF provides boolean objects identified by the keywords true and false. Boolean
objects can be used as the values of array elements and dictionary entries, and can
also occur in PostScript calculator functions as the results of boolean and
relational operators and as operands to the conditional operators
if and ifelse (see
Section 3.9.4, “Type 4 (PostScript Calculator) Functions”).
3.2.2 Numeric Objects
PDF provides two types of numeric objects: integer and real. Integer objects rep-
resent mathematical integers within a certain interval centered at 0. Real objects
approximate mathematical real numbers, but with limited range and precision;
they are typically represented in fixed-point form rather than floating-point
form. The range and precision of numbers are limited by the internal representa-
tions used in the computer on which the PDF consumer application is running;
Appendix C gives these limits for typical implementations.
An integer is written as one or more decimal digits optionally preceded by a sign:
123 43445 +17 98 0
The value is interpreted as a signed decimal integer and is converted to an integer
object. If it exceeds the implementation limit for integers, it is converted to a real
object.
A real value is written as one or more decimal digits with an optional sign and a
leading, trailing, or embedded period (decimal point):
34.5 3.62 +123.6 4. .002 0.0
The value is interpreted as a real number and is converted to a real object. If it
exceeds the implementation limit for real numbers, an error occurs.
Note: PDF does not support the PostScript syntax for numbers with nondecimal
radices (such as
16#FFFE) or in exponential format (such as 6.02E23).
ObjectsSECTION 3.2
29
Throughout this book, the term number refers to an object whose type may be
either integer or real. Wherever a real number is expected, an integer may be used
instead and is automatically converted to an equivalent real value. For example, it
is not necessary to write the number
1.0 in real format; the integer 1 is sufficient.
3.2.3 String Objects
A string object consists of a series of bytes—unsigned integer values in the range 0
to 255. The string elements are not integer objects, but are stored in a more
compact format. The length of a string is subject to an implementation limit; see
Appendix C.
String objects can be written in two ways:
• As a sequence of literal characters enclosed in parentheses ( ); see “Literal
Strings,” below”
• As hexadecimal data enclosed in angle brackets < >; see “Hexadecimal Strings”
on page 32
This section describes only the basic syntax for writing a string as a sequence of
bytes. Strings can be used for many purposes and can be formatted in a variety of
ways. When a string is used for a specific purpose (to represent a date, for ex-
ample), it is useful to have a standard format for that purpose (see Section 3.8.3,
“Dates”). Such formats are merely conventions for interpreting the contents of a
string and are not separate object types. The use of a particular format is de-
scribed with the definition of the string object that uses that format.
Literal Strings
A literal string is written as an arbitrary number of characters enclosed in paren-
theses. Any characters may appear in a string except unbalanced parentheses and
the backslash, which must be treated specially. Balanced pairs of parentheses
within a string require no special treatment.
The following are valid literal strings:
(This is a string)
(Strings may contain newlines
and such.)
SyntaxCHAPTER 3
30
(Strings may contain balanced parentheses ( ) and
special characters (*!&}^% and so on).)
(The following is an empty string.)
()
(It has zero (0) length.)
Within a literal string, the backslash (\) is used as an escape character for various
purposes, such as to include newline characters, nonprinting ASCII characters,
unbalanced parentheses, or the backslash character itself in the string. The char-
acter immediately following the backslash determines its precise interpretation
(see Table 3.2). If the character following the backslash is not one of those shown
in the table, the backslash is ignored.
TABLE 3.2 Escape sequences in literal strings
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 indi-
cate that the string continues on the following line. The backslash and the end-of-
line marker following it are not considered part of the string. For example:
(These \
two strings \
are the same.)
(These two strings are the same.)
SEQUENCE MEANING
\n
Line feed (LF)
\r
Carriage return (CR)
\t
Horizontal tab (HT)
\b
Backspace (BS)
\f
Form feed (FF)
\(
Left parenthesis
\)
Right parenthesis
\\
Backslash
\ddd Character code ddd (octal)
ObjectsSECTION 3.2
31
If an end-of-line marker appears within a literal string without a preceding back-
slash, the result is equivalent to
\n (regardless of whether the end-of-line marker
was a carriage return, a line feed, or both). For example:
(This string has an endofline at the end of it.
)
(So does this one.\n)
The \ddd escape sequence provides a way to represent characters outside the
printable ASCII character set. For example:
(This string contains \245two octal characters\307.)
The number ddd may consist of one, two, or three octal digits, with high-order
overflow ignored. It is required that three octal digits be used, with leading zeros
as needed, if the next character of the string is also a digit. For example, the literal
(\0053)
denotes a string containing two characters, \005 (Control-E) followed by the digit
3, whereas both
(\053)
and
(\53)
denote strings containing the single character \053, a plus sign (+).
This notation provides a way to specify characters outside the 7-bit ASCII charac-
ter set by using ASCII characters only. However, any 8-bit value may appear in a
string. In particular, when a document is encrypted (see Section 3.5, “Encryp-
tion”), all of its strings are encrypted and often contain arbitrary 8-bit values.
Note that the backslash character is still required as an escape to specify unbal-
anced parentheses or the backslash character itself.
SyntaxCHAPTER 3
32
Hexadecimal Strings
Strings may also be written in hexadecimal form, which is useful for including ar-
bitrary binary data in a PDF file. A hexadecimal string is written as a sequence of
hexadecimal digits (
0–9 and either A–F or a–f) enclosed within angle brackets
(
< and >):
<4E6F762073686D6F7A206B6120706F702E >
Each pair of hexadecimal digits defines one byte of the string. White-space char-
acters (such as space, tab, carriage return, line feed, and form feed) are ignored.
If the final digit of a hexadecimal string is missing—that is, if there is an odd
number of digits—the final digit is assumed to be
0. For example:
<901FA3>
is a 3-byte string consisting of the characters whose hexadecimal codes are 90, 1F,
and
A3, but
<901FA>
is a 3-byte string containing the characters whose hexadecimal codes are 90, 1F,
and
A0.
3.2.4 Name Objects
A name object is an atomic symbol uniquely defined by a sequence of characters.
Uniquely defined means that any two name objects made up of the same sequence
of characters are identically the same object. Atomic means that a name has no
internal structure; although it is defined by a sequence of characters, those char-
acters are not considered elements of the name.
A slash character (
/) introduces a name. The slash is not part of the name but is a
prefix indicating that the following sequence of characters constitutes a name.
There can be no white-space characters between the slash and the first character
in the name. The name may include any regular characters, but not delimiter or
white-space characters (see Section 3.1, “Lexical Conventions”). Uppercase and
ObjectsSECTION 3.2
33
lowercase letters are considered distinct: /A and /a are different names. The fol-
lowing examples are valid literal names:
/Name1
/ASomewhatLongerName
/A;Name_WithVarious***Characters?
/1.2
/$$
/@pattern
/.notdef
Note: The token / (a slash followed by no regular characters) is a valid name.
Beginning with PDF 1.2, any character except null (character code 0) may be in-
cluded in a name by writing its 2-digit hexadecimal code, preceded by the num-
ber sign character (
#); see implementation notes 3 and 4 in Appendix H. This
syntax is required to represent any of the delimiter or white-space characters or
the number sign character itself; it is recommended but not required for charac-
ters whose codes are outside the range 33 (
!) to 126 (~). The examples shown in
Table 3.3 are valid literal names in PDF 1.2 and later.
TABLE 3.3 Examples of literal names using the # character
The length of a name is subject to an implementation limit; see Appendix C. The
limit applies to the number of characters in the name’s internal representation.
For example, the name
/A#20B has four characters (/, A, space, B), not six.
As stated above, name objects are treated as atomic symbols within a PDF file.
Ordinarily, the bytes making up the name are never treated as text to be presented
to a human user or to an application external to a PDF consumer. However, occa-
LITERAL NAME RESULT
/Adobe#20Green Adobe Green
/PANTONE#205757#20CV PANTONE 5757 CV
/paired#28#29parentheses paired()parentheses
/The_Key_of_F#23_Minor The_Key_of_F#_Minor
/A#42
AB
SyntaxCHAPTER 3
34
sionally the need arises to treat a name object as text, such as one that represents a
font name (see the
BaseFont entry in Table 5.8 on page 383) or a structure type
(see Section 10.6.2, “Structure Types”).
In such situations, it is recommended that the sequence of bytes (after expansion
of
# sequences, if any) be interpreted according to UTF-8, a variable-length byte-
encoded representation of Unicode in which the printable ASCII characters have
the same representations as in ASCII. This enables a name object to represent text
in any natural language, subject to the implementation limit on the length of a
name. (See implementation note 5 in Appendix H.)
Note: PDF does not prescribe what UTF-8 sequence to choose for representing any
given piece of externally specified text as a name object. In some cases, multiple
UTF-8 sequences could represent the same logical text. Name objects defined by dif-
ferent sequences of bytes constitute distinct name objects in PDF, even though the
UTF-8 sequences might have identical external interpretations.
In PDF, name objects always begin with the slash character (
/), unlike keywords
such as
true, false, and obj. This book follows a typographic convention of writ-
ing names without the leading slash when they appear in running text and tables.
For example,
Type and FullScreen denote names that would actually be written in
a PDF file (and in code examples in this book) as
/Type and /FullScreen.
3.2.5 Array Objects
An array object is a one-dimensional collection of objects arranged sequentially.
Unlike arrays in many other computer languages, PDF arrays may be hetero-
geneous; that is, an array’s elements may be any combination of numbers, strings,
dictionaries, or any other objects, including other arrays. The number of elements
in an array is subject to an implementation limit; see Appendix C.
An array is written as a sequence of objects enclosed in square brackets (
[ and ]):
[549 3.14 false (Ralph) /SomeName]
PDF directly supports only one-dimensional arrays. Arrays of higher dimension
can be constructed by using arrays as elements of arrays, nested to any depth.
ObjectsSECTION 3.2
35
3.2.6 Dictionary Objects
A dictionary object is an associative table containing pairs of objects, known as
the dictionary’s entries. The first element of each entry is the key and the second
element is the value. The key must be a name (unlike dictionary keys in Post-
Script, which may be objects of any type). The value can be any kind of object,
including another dictionary. A dictionary entry whose value is
null (see Section
3.2.8, “Null Object”) is equivalent to an absent entry. (This differs from Post-
Script, where
null behaves like any other object as the value of a dictionary entry.)
The number of entries in a dictionary is subject to an implementation limit; see
Appendix C.
Note: No two entries in the same dictionary should have the same key. If a key does
appear more than once, its value is undefined.
A dictionary is written as a sequence of key-value pairs enclosed in double angle
brackets (
<<…>>). For example:
<< /Type /Example
/Subtype /DictionaryExample
/Version 0.01
/IntegerItem 12
/StringItem (a string)
/Subdictionary << /Item1 0.4
/Item2 true
/LastItem (not!)
/VeryLastItem (OK)
>>
>>
Note: Do not confuse the double angle brackets with single angle brackets (< and >),
which delimit a hexadecimal string (see “Hexadecimal Strings” on page 32).
Dictionary objects are the main building blocks of a PDF document. They are
commonly used to collect and tie together the attributes of a complex object, such
as a font or a page of the document, with each entry in the dictionary specifying
the name and value of an attribute. By convention, the
Type entry of such a dic-
tionary identifies the type of object the dictionary describes. In some cases, a
Subtype entry (sometimes abbreviated S) is used to further identify a specialized
subcategory of the general type. The value of the
Type or Subtype entry is always
SyntaxCHAPTER 3
36
a name. For example, in a font dictionary, the value of the Type entry is always
Font, whereas that of the Subtype entry may be Type1, TrueType, or one of sever-
al other values.
The value of the
Type entry can almost always be inferred from context. The op-
erand of the
Tf operator, for example, must be a font object; therefore, the Type
entry in a font dictionary serves primarily as documentation and as information
for error checking. The
Type entry is not required unless so stated in its descrip-
tion; however, if the entry is present, it must have the correct value. In addition,
the value of the
Type entry in any dictionary, even in private data, must be either
a name defined in this book or a registered name; see Appendix E for details.
3.2.7 Stream Objects
A stream object, like a string object, is a sequence of bytes. However, a PDF appli-
cation can read a stream incrementally, while a string must be read in its entirety.
Furthermore, a stream can be of unlimited length, whereas a string is subject to
an implementation limit. For this reason, objects with potentially large amounts
of data, such as images and page descriptions, are represented as streams.
Note: As with strings, this section describes only the syntax for writing a stream as a
sequence of bytes. What those bytes represent is determined by the context in which
the stream is referenced.
A stream consists of a dictionary followed by zero or more bytes bracketed be-
tween the keywords
stream and endstream:
dictionary
stream
…Zero or more bytes…
endstream
All streams must be indirect objects (see Section 3.2.9, “Indirect Objects”) and
the stream dictionary must be a direct object. The keyword
stream that follows
the stream dictionary should be followed by an end-of-line marker consisting of
either a carriage return and a line feed or just a line feed, and not by a carriage re-
turn alone. The sequence of bytes that make up a stream lie between the
stream
and endstream keywords; the stream dictionary specifies the exact number of
bytes. It is recommended that there be an end-of-line marker after the data and
before
endstream; this marker is not included in the stream length.
ObjectsSECTION 3.2
37
Alternatively, beginning with PDF 1.2, the bytes may be contained in an external
file, in which case the stream dictionary specifies the file, and any bytes between
stream and endstream are ignored. (See implementation note 6 in Appendix H.)
Note: Without the restriction against following the keyword
stream by a carriage re-
turn alone, it would be impossible to differentiate a stream that uses carriage return
as its end-of-line marker and has a line feed as its first byte of data from one that
uses a carriage return–line feed sequence to denote end-of-line.
Table 3.4 lists the entries common to all stream dictionaries; certain types of
streams may have additional dictionary entries, as indicated where those streams
are described. The optional entries regarding filters for the stream indicate
whether and how the data in the stream must be transformed (decoded) before it
is used. Filters are described further in Section 3.3, “Filters.”
Stream Extent
Every stream dictionary has a Length entry that indicates how many bytes of the
PDF file are used for the stream’s data. (If the stream has a filter,
Length is the
number of bytes of encoded data.) In addition, most filters are defined so that the
data is self-limiting; that is, they use an encoding scheme in which an explicit
end-of-data (EOD) marker delimits the extent of the data. Finally, streams are
used to represent many objects from whose attributes a length can be inferred. All
of these constraints must be consistent.
For example, an image with 10 rows and 20 columns, using a single color compo-
nent and 8 bits per component, requires exactly 200 bytes of image data. If the
stream uses a filter, there must be enough bytes of encoded data in the PDF file to
produce those 200 bytes. An error occurs if
Length is too small, if an explicit
EOD marker occurs too soon, or if the decoded data does not contain 200 bytes.
It is also an error if the stream contains too much data, with the exception that
there may be an extra end-of-line marker in the PDF file before the keyword
endstream.
SyntaxCHAPTER 3
38
TABLE 3.4 Entries common to all stream dictionaries
KEY TYPE VALUE
Length
integer (Required) The number of bytes from the beginning of the line fol-
lowing the keyword
stream to the last byte just before the keyword
endstream. (There may be an additional EOL marker, preceding
endstream, that is not included in the count and is not logically part
of the stream data.) See “Stream Extent,” above, for further discus-
sion.
Filter
name or array (Optional) The name of a filter to be applied in processing the stream
data found between the keywords
stream and endstream, or an array
of such names. Multiple filters should be specified in the order in
which they are to be applied.
DecodeParms
dictionary or array (Optional) A parameter dictionary or an array of such dictionaries,
used by the filters specified by
Filter. If there is only one filter and that
filter has parameters,
DecodeParms must be set to the filter’s parame-
ter dictionary unless all the filter’s parameters have their default
values, in which case the
DecodeParms entry may be omitted. If there
are multiple filters and any of the filters has parameters set to non-
default values,
DecodeParms must be an array with one entry for
each filter: either the parameter dictionary for that filter, or the null
object if that filter has no parameters (or if all of its parameters have
their default values). If none of the filters have parameters, or if all
their parameters have default values, the
DecodeParms entry may be
omitted. (See implementation note 7 in Appendix H.)
F
file specification (Optional; PDF 1.2) The file containing the stream data. If this entry
is present, the bytes between
stream and endstream are ignored, the
filters are specified by
FFilter rather than Filter, and the filter parame-
ters are specified by
FDecodeParms rather than DecodeParms. How-
ever, the
Length entry should still specify the number of those bytes.
(Usually, there are no bytes and
Length is 0.)
FFilter
name or array (Optional; PDF 1.2) The name of a filter to be applied in processing
the data found in the stream’s external file, or an array of such names.
The same rules apply as for
Filter.
FDecodeParms
dictionary or array (Optional; PDF 1.2) A parameter dictionary, or an array of such dic-
tionaries, used by the filters specified by
FFilter. The same rules apply
as for
DecodeParms.
ObjectsSECTION 3.2
39
3.2.8 Null Object
The null object has a type and value that are unequal to those of any other object.
There is only one object of type null, denoted by the keyword
null. An indirect
object reference (see Section 3.2.9, “Indirect Objects”) to a nonexistent object is
treated the same as a null object. Specifying the null object as the value of a dic-
tionary entry (Section 3.2.6, “Dictionary Objects”) is equivalent to omitting the
entry entirely.
3.2.9 Indirect Objects
Any object in a PDF file may be labeled as an indirect object. This gives the object
a unique object identifier by which other objects can refer to it (for example, as an
element of an array or as the value of a dictionary entry). The object identifier
consists of two parts:
• A positive integer object number. Indirect objects are often numbered sequen-
tially within a PDF file, but this is not required; object numbers may be
assigned in any arbitrary order.
• A non-negative integer generation number. In a newly created file, all indirect
objects have generation numbers of 0. Nonzero generation numbers may be in-
troduced when the file is later updated; see Sections 3.4.3, “Cross-Reference
Table,” and 3.4.5, “Incremental Updates.”
Together, the combination of an object number and a generation number unique-
ly identifies an indirect object. The object retains the same object number and
generation number throughout its existence, even if its value is modified.
DL
integer (Optional; PDF 1.5) A non-negative integer representing the number
of bytes in the decoded (defiltered) stream. It can be used to deter-
mine, for example, whether enough disk space is available to write a
stream to a file.
This value should be considered a hint only; for some stream filters, it
may not be possible to determine this value precisely.
KEY TYPE VALUE
SyntaxCHAPTER 3
40
The definition of an indirect object in a PDF file consists of its object number and
generation number, followed by the value of the object bracketed between the
keywords
obj and endobj. For example, the definition
12 0 obj
(Brillig)
endobj
defines an indirect string object with an object number of 12, a generation num-
ber of 0, and the value
Brillig.
The object can be referred to from elsewhere in the file by an indirect reference
consisting of the object number, the generation number, and the keyword
R:
12 0 R
Beginning with PDF 1.5, indirect objects may reside in object streams (see Sec-
tion 3.4.6, “Object Streams”). They are referred to in the same way; however, their
definition does not include the keywords
obj and endobj.
An indirect reference to an undefined object is not an error; it is simply treated as
a reference to the null object. For example, if a file contains the indirect reference
17 0 R but does not contain the corresponding definition
17 0 obj
…
endobj
then the indirect reference is considered to refer to the null object.
Note: In the data structures that make up a PDF document, certain values are re-
quired to be specified as indirect object references. Except where this is explicitly
called out, any object (other than a stream) may be specified either directly or as an
indirect object reference; the semantics are entirely equivalent. Note in particular
that content streams, which define the visible contents of the document, may not
contain indirect references (see Section 3.7.1, “Content Streams”). Also, see imple-
mentation note 8 in Appendix H.
Example 3.1 shows the use of an indirect object to specify the length of a stream.
The value of the stream’s
Length entry is an integer object that follows the stream
FiltersSECTION 3.3
41
in the file. This allows applications that generate PDF in a single pass to defer
specifying the stream’s length until after its contents have been generated.
Example 3.1
7 0 obj
<< /Length 8 0 R >> % An indirect reference to object 8
stream
BT
/F1 12 Tf
72 712 Td
(A stream with an indirect length) Tj
ET
endstream
endobj
8 0 obj
77 % The length of the preceding stream
endobj
3.3 Filters
Stream filters are introduced in Section 3.2.7, “Stream Objects.” A filter is an
optional part of the specification of a stream, indicating how the data in the
stream must be decoded before it is used. For example, if a stream has an
ASCIIHexDecode filter, an application reading the data in that stream will trans-
form the ASCII hexadecimal-encoded data in the stream into binary data.
An application program that produces a PDF file can encode certain information
(for example, data for sampled images) to compress it or to convert it to a port-
able ASCII representation. Then an application that reads (consumes) the PDF
file can invoke the corresponding decoding filter to convert the information back
to its original form.
The filter or filters for a stream are specified by the
Filter entry in the stream’s dic-
tionary (or the
FFilter entry if the stream is external). Filters can be cascaded to
form a pipeline that passes the stream through two or more decoding transforma-
tions in sequence. For example, data encoded using LZW and ASCII base-85
encoding (in that order) can be decoded using the following entry in the stream
dictionary:
/Filter [/ASCII85Decode /LZWDecode]
SyntaxCHAPTER 3
42
Some filters may take parameters to control how they operate. These optional
parameters are specified by the
DecodeParms entry in the stream’s dictionary (or
the
FDecodeParms entry if the stream is external).
PDF supports a standard set of filters that fall into two main categories:
• ASCII filters enable decoding of arbitrary 8-bit binary data that has been en-
coded as ASCII text. (See Section 3.1, “Lexical Conventions,” for an explanation
of why this type of encoding might be useful.) Note that ASCII filters serve no
useful purpose in a PDF file that is encrypted; see Section 3.5, “Encryption.”
• Decompression filters enable decoding of data that has been compressed. The
compressed data is always in 8-bit binary format, even if the original data is
ASCII text. (Compression is particularly valuable for large sampled images,
since it reduces storage requirements and transmission time. Some types of
compression are lossy, meaning that some data is lost during the encoding, re-
sulting in a loss of quality when the data is decompressed. Compression in
which no loss of data occurs is called lossless.)
The standard filters are summarized in Table 3.5, which also indicates whether
they accept any optional parameters. The following sections describe these filters
and their parameters (if any) in greater detail, including specifications of encod-
ing algorithms for some filters. (See also implementation notes 9 and 10 in Ap-
pendix H.)
Example 3.2 shows a stream, containing the marking instructions for a page, that
was compressed using the LZW compression method and then encoded in ASCII
base-85 representation. Example 3.3 shows the same stream without any encod-
ing. (The stream’s contents are explained in Section 3.7.1, “Content Streams,” and
the operators used there are further described in Chapter 5.)
FiltersSECTION 3.3
43
TABLE 3.5 Standard filters
FILTER NAME PARAMETERS? DESCRIPTION
ASCIIHexDecode
no Decodes data encoded in an ASCII hexadecimal representation,
reproducing the original binary data.
ASCII85Decode
no Decodes data encoded in an ASCII base-85 representation, repro-
ducing the original binary data.
LZWDecode
yes Decompresses data encoded using the LZW (Lempel-Ziv-Welch)
adaptive compression method, reproducing the original text or bin-
ary data.
FlateDecode
yes (PDF 1.2) Decompresses data encoded using the zlib/deflate com-
pression method, reproducing the original text or binary data.
RunLengthDecode
no Decompresses data encoded using a byte-oriented run-length encod-
ing algorithm, reproducing the original text or binary data (typically
monochrome image data, or any data that contains frequent long
runs of a single byte value).
CCITTFaxDecode
yes Decompresses data encoded using the CCITT facsimile standard,
reproducing the original data (typically monochrome image data at 1
bit per pixel).
JBIG2Decode
yes (PDF 1.4) Decompresses data encoded using the JBIG2 standard,
reproducing the original monochrome (1 bit per pixel) image data
(or an approximation of that data).
DCTDecode
yes Decompresses data encoded using a DCT (discrete cosine transform)
technique based on the JPEG standard, reproducing image sample
data that approximates the original data.
JPXDecode
no (PDF 1.5) Decompresses data encoded using the wavelet-based
JPEG2000 standard, reproducing the original image data.
Crypt
yes (PDF 1.5) Decrypts data encrypted by a security handler, reproduc-
ing the original data as it was before encryption.
SyntaxCHAPTER 3
44
Example 3.2
1 0 obj
<< /Length 534
/Filter [/ASCII85Decode /LZWDecode]
>>
stream
J..)6T`?p&<!J9%_[umg"B7/Z7KNXbN'S+,*Q/&"OLT'F
LIDK#!n`$"<Atdi`\Vn%b%)&'cA*VnK\CJY(sF>c!Jnl@
RM]WM;jjH6Gnc75idkL5]+cPZKEBPWdR>FF(kj1_R%W_d
&/jS!;iuad7h?[LF$+]]0A3Ck*$I0KZ?;<)CJtqi65Xb
Vc3\n5ua:Q/=0$W<#N3U;H,MQKqfg1?:lUpR;6oN[C2E4
ZNr8Udn.'p+?#X+1>0Kuk$bCDF/(3fL5]Oq)^kJZ!C2H1
'TO]Rl?Q:&'<5&iP!$Rq;BXRecDN[IJB`,)o8XJOSJ9sD
S]hQ;Rj@!ND)bD_q&C\g:inYC%)&u#:u,M6Bm%IY!Kb1+
":aAa'S`ViJglLb8<W9k6Yl\\0McJQkDeLWdPN?9A'jX*
al>iG1p&i;eVoK&juJHs9%;Xomop"5KatWRT"JQ#qYuL,
JD?M$0QP)lKn06l1apKDC@\qJ4B!!(5m+j.7F790m(Vj8
8l8Q:_CZ(Gm1%X\N1&u!FKHMB~>
endstream
endobj
Example 3.3
1 0 obj
<< /Length 568 >>
stream
2J
BT
/F1 12 Tf
0Tc
0Tw
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
FiltersSECTION 3.3
45
T* (for both data and images, while others are \
suitable only ) Tj
T* (for continuoustone images.) Tj
ET
endstream
endobj
3.3.1 ASCIIHexDecode Filter
The ASCIIHexDecode filter decodes data that has been encoded in ASCII hexa-
decimal form. ASCII hexadecimal encoding and ASCII base-85 encoding
(described in the next section) convert binary data, such as image data, to 7-bit
ASCII characters. In general, ASCII base-85 encoding is preferred to ASCII hexa-
decimal encoding because it is more compact: it expands the data by a factor of
4:5, compared with 1:2 for ASCII hexadecimal encoding.
The
ASCIIHexDecode filter produces one byte of binary data for each pair of
ASCII hexadecimal digits (
0–9 and A–F or a–f). All white-space characters (see
Section 3.1, “Lexical Conventions”) are ignored. A right angle bracket character
(
>) indicates EOD. Any other characters cause an error. If the filter encounters
the EOD marker after reading an odd number of hexadecimal digits, it behaves as
if a
0 followed the last digit.
3.3.2 ASCII85Decode Filter
The ASCII85Decode filter decodes data that has been encoded in ASCII base-85
encoding and produces binary data. The following paragraphs describe the pro-
cess for encoding binary data in ASCII base-85; the
ASCII85Decode filter reverses
this process.
The ASCII base-85 encoding uses the characters
! through u and the character z,
with the 2-character sequence
~> as its EOD marker. The ASCII85Decode filter
ignores all white-space characters (see Section 3.1, “Lexical Conventions”). Any
other characters, and any character sequences that represent impossible combi-
nations in the ASCII base-85 encoding, cause an error.
SyntaxCHAPTER 3
46
Specifically, ASCII base-85 encoding produces 5 ASCII characters for every 4
bytes of binary data. Each group of 4 binary input bytes, (b
1
b
2
b
3
b
4
), is converted
to a group of 5 output bytes, (c
1
c
2
c
3
c
4
c
5
), using the relation
In other words, 4 bytes of binary data are interpreted as a base-256 number and
then converted to a base-85 number. The five bytes of the base-85 number are
then converted to ASCII characters by adding 33 (the ASCII code for the charac-
ter
!) to each. The resulting encoded data contains only printable ASCII charac-
ters with codes in the range 33 (
!) to 117 (u). As a special case, if all five bytes are
0, they are represented by the character with code 122 (
z) instead of by five excla-
mation points (
!!!!!).
If the length of the binary data to be encoded is not a multiple of 4 bytes, the last,
partial group of 4 is used to produce a last, partial group of 5 output characters.
Given n (1, 2, or 3) bytes of binary data, the encoder first appends 4 n zero bytes
to make a complete group of 4. It then encodes this group in the usual way, but
without applying the special
z case. Finally, it writes only the first n + 1 characters
of the resulting group of 5. These characters are immediately followed by the
~>
EOD marker.
The following conditions (which never occur in a correctly encoded byte se-
quence) cause errors during decoding:
• The value represented by a group of 5 characters is greater than 2
32
1.
• A z character occurs in the middle of a group.
• A final partial group contains only one character.
b
1
256
3
×()b
2
256
2
×()b
3
256
1
×()b
4
+++
=
c
1
85
4
×()
c
2
85
3
×()
c
3
85
2
×()
c
4
85
1
×()
c
5
++++
Filters
SECTION 3.3
47
3.3.3 LZWDecode and FlateDecode Filters
The
LZWDecode
and (in PDF 1.2)
FlateDecode
filters have much in common and
are discussed together in this section. They decode data that has been encoded
using the LZW or Flate data compression method, respectively:
•
LZW (Lempel-Ziv-Welch) is a variable-length, adaptive compression method
that has been adopted as one of the standard compression methods in the
Tag
Image File Format
(TIFF) standard. Details on LZW encoding follow in the
next section.
•
The Flate method 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. It is fully defined in Internet RFCs
1950,
ZLIB Compressed Data Format Specification
, and 1951,
DEFLATE Com-
pressed Data Format Specification
(see the Bibliography).
Both of these methods compress either binary data or ASCII text but (like all
compression methods) always produce binary data, even if the original data was
text.
The LZW and Flate compression methods can discover and exploit many pat-
terns in the input data, whether the data is text or images. As described later, both
filters support optional transformation by a
predictor function
, which improves
the compression of sampled image data. Because of its cascaded adaptive Huff-
man coding, Flate-encoded output is usually much more compact than LZW-
encoded output for the same input. Flate and LZW decoding speeds are com-
parable, but Flate encoding is considerably slower than LZW encoding.
Usually, both Flate and LZW encodings compress their input substantially. How-
ever, in the worst case (in which no pair of adjacent characters appears twice),
Flate encoding
expands
its input by no more than 11 bytes or a factor of 1.003
(whichever is larger), plus the effects of algorithm tags added by PNG predictors.
For LZW encoding, the best case (all zeros) provides a compression approaching
1365:1 for long files, but the worst-case expansion is at least a factor of 1.125,
which can increase to nearly 1.5 in some implementations, plus the effects of
PNG tags as with Flate encoding.
Syntax
CHAPTER 3
48
Details of LZW Encoding
Data encoded using the LZW compression method consists 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 multiple-character sequence that has been encountered previously
in the input (258 or greater).
Initially, the code length is 9 bits and the LZW table contains only entries for the
258 fixed codes. As encoding proceeds, entries are appended to the table, asso-
ciating new codes with longer and longer sequences of input characters. The
encoder and the decoder maintain identical copies of this table.
Whenever both the encoder and the decoder independently (but synchronously)
realize that the current code length is no longer sufficient to represent the num-
ber of entries in the table, they increase the number of bits per code by 1. The first
output code that is 10 bits long is the one following the creation of table entry
511, and similarly for 11 (1023) and 12 (2047) bits. Codes are never longer than
12 bits; therefore, 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. Emit 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.
For example, suppose the input consists of the following sequence of ASCII char-
acter codes:
45 45 45 45 45 65 45 45 45 66
Starting with an empty table, the encoder proceeds as shown in Table 3.6.
Filters
SECTION 3.3
49
TABLE 3.6 Typical LZW encoding sequence
Codes are packed into a continuous bit stream, high-order bit first. This stream is
then divided into 8-bit bytes, high-order bit first. Thus, codes can straddle byte
boundaries arbitrarily. After the EOD marker (code value 257), any leftover bits
in the final byte are set to 0.
In the example above, all the output codes are 9 bits long; they would pack into
bytes as follows (represented in hexadecimal):
80 0B 60 50 22 0C 0C 85 01
To adapt to changing input sequences, the encoder may at any point issue a clear-
table code, which causes both the encoder and the decoder to restart with initial
tables and a 9-bit code length. 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.
LZWDecode and FlateDecode Parameters
The
LZWDecode
and
FlateDecode
filters accept optional parameters to control
the decoding process. Most of these parameters are related to techniques that re-
duce the size of compressed sampled images (rectangular arrays of color values,
described in Section 4.8, “Images”). For example, image data typically changes
very little from sample to sample. Therefore, subtracting the values of adjacent
INPUT
SEQUENCE
OUTPUT
CODE
CODE ADDED
TO TABLE
SEQUENCE REPRESENTED
BY NEW CODE
– 256 (clear-table) – –
45 45 258 45 45
45 45 258 259 45 45 45
45 45 258 260 45 45 65
65 65 261 65 45
45 45 45 259 262 45 45 45 66
66 66 – –
– 257 (EOD) – –
Syntax
CHAPTER 3
50
samples (a process called
differencing
), and encoding the differences rather than
the raw sample values, can reduce the size of the output data. Furthermore, when
the image data contains several color components (red-green-blue or cyan-ma-
genta-yellow-black) per sample, taking the difference between the values of cor-
responding components in adjacent samples, rather than between different color
components in the same sample, often reduces the output data size.
Table 3.7 shows the parameters that can optionally be specified for
LZWDecode
and
FlateDecode
filters. Except where otherwise noted, all values supplied to the
decoding filter for any optional parameters must match those used when the data
was encoded.
TABLE 3.7 Optional parameters for LZWDecode and FlateDecode filters
KEY TYPE VALUE
Predictor
integer A code that selects the predictor algorithm, if any. If the value of this entry
is 1, the filter assumes that the normal algorithm was used to encode the data,
without prediction. If the value is greater than 1, the filter assumes that the
data was differenced before being encoded, and
Predictor
selects the predic-
tor algorithm. For more information regarding
Predictor
values greater
than 1, see “LZW and Flate Predictor Functions,” below. Default value: 1.
Colors
integer
(Used only if
Predictor
is greater than 1)
The number of interleaved color com-
ponents per sample. Valid values are 1 to 4 in PDF 1.2 or earlier and 1 or
greater in PDF 1.3 or later. Default value: 1.
BitsPerComponent
integer
(Used only if
Predictor
is greater than 1)
The number of bits used to represent
each color component in a sample. Valid values are 1, 2, 4, 8, and (in PDF 1.5)
16. Default value: 8.
Columns
integer (Used only if Predictor is greater than 1) The number of samples in each row.
Default value: 1.
EarlyChange
integer (LZWDecode only) An indication of when to increase the code length. If the
value of this entry is 0, code length increases are postponed as long as pos-
sible. If the value is 1, code length increases occur one code early. This pa-
rameter is included because LZW sample code distributed by some vendors
increases the code length one code earlier than necessary. Default value: 1.
FiltersSECTION 3.3
51
LZW and Flate Predictor Functions
LZW and Flate encoding compress more compactly if their input data is highly
predictable. One way of increasing the predictability of many continuous-tone
sampled images is to replace each sample with the difference between that sample
and a predictor function applied to earlier neighboring samples. If the predictor
function works well, the postprediction data clusters toward 0.
Two groups of predictor functions are supported. The first, the TIFF group, con-
sists of the single function that is Predictor 2 in the TIFF standard. (In the TIFF
standard, Predictor 2 applies only to LZW compression, but here it applies to
Flate compression as well.) TIFF Predictor 2 predicts that each color component
of a sample is the same as the corresponding color component of the sample im-
mediately to its left.
The second supported group of predictor functions, the PNG group, consists of
the filters of the World Wide Web Consortium’s Portable Network Graphics rec-
ommendation, documented in Internet RFC 2083, PNG (Portable Network
Graphics) Specification (see the Bibliography). The term predictors is used here in-
stead of filters to avoid confusion. There are five basic PNG predictor algorithms
(and a sixth that chooses the optimum predictor function separately for each
row):
None No prediction
Sub Predicts the same as the sample to the left
Up Predicts the same as the sample above
Average Predicts the average of the sample to the left and the sample above
Paeth A nonlinear function of the sample above, the sample to the left,
and the sample to the upper left
The predictor algorithm to be used, if any, is indicated by the
Predictor filter
parameter (see Table 3.7), which can have any of the values listed in Table 3.8.
For
LZWDecode and FlateDecode, a Predictor value greater than or equal to 10
merely indicates that a PNG predictor is in use; the specific predictor function
used is explicitly encoded in the incoming data. The value of
Predictor supplied
by the decoding filter need not match the value used when the data was encoded
if they are both greater than or equal to 10.
SyntaxCHAPTER 3
52
TABLE 3.8 Predictor values
The two groups of predictor functions have some commonalities. Both make the
following assumptions:
• Data is presented in order, from the top row to the bottom row and, within a
row, from left to right.
• A row occupies a whole number of bytes, rounded up if necessary.
• Samples and their components are packed into bytes from high-order to low-
order bits.
• All color components of samples outside the image (which are necessary for
predictions near the boundaries) are 0.
The predictor function groups also differ in significant ways:
• The postprediction data for each PNG-predicted row begins with an explicit
algorithm tag; therefore, different rows can be predicted with different algo-
rithms to improve compression. TIFF Predictor 2 has no such identifier; the
same algorithm applies to all rows.
• The TIFF function group predicts each color component from the prior in-
stance of that component, taking into account the number of bits per com-
ponent and components per sample. In contrast, the PNG function group
predicts each byte of data as a function of the corresponding byte of one or
VALUE MEANING
1 No prediction (the default value)
2 TIFF Predictor 2
10 PNG prediction (on encoding, PNG None on all rows)
11 PNG prediction (on encoding, PNG Sub on all rows)
12 PNG prediction (on encoding, PNG Up on all rows)
13 PNG prediction (on encoding, PNG Average on all rows)
14 PNG prediction (on encoding, PNG Paeth on all rows)
15 PNG prediction (on encoding, PNG optimum)
FiltersSECTION 3.3
53
more previous image samples, 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 the cost of somewhat worse
compression.
3.3.4 RunLengthDecode Filter
The RunLengthDecode filter decodes data that has been encoded in a simple
byte-oriented format based on run length. 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
the length byte 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 (2 to 128) times during decom-
pression. A length value of 128 denotes EOD.
The compression achieved by run-length encoding depends on the input data. In
the best case (all zeros), a compression of approximately 64:1 is achieved for long
files. The worst case (the hexadecimal sequence
00 alternating with FF) results in
an expansion of 127:128.
3.3.5 CCITTFaxDecode Filter
The CCITTFaxDecode filter decodes image data that has been encoded using
either Group 3 or Group 4 CCITT facsimile (fax) encoding. CCITT encoding is
designed to achieve efficient compression of monochrome (1 bit per pixel) image
data at relatively low resolutions, and so is useful only for bitmap image data, not
for color images, grayscale images, or general data.
The CCITT encoding standard is defined by the International Telecommunica-
tions Union (ITU), formerly known as the Comité Consultatif International Télé-
phonique et Télégraphique (International Coordinating Committee for
Telephony and Telegraphy). The encoding algorithm is not described in detail in
this book but can be found in ITU Recommendations T.4 and T.6 (see the Bibli-
ography). For historical reasons, we refer to these documents as the CCITT stan-
dard.
SyntaxCHAPTER 3
54
CCITT encoding is bit-oriented, not byte-oriented. Therefore, in principle, en-
coded or decoded data might not end at a byte boundary. This problem is dealt
with in the following ways:
• Unencoded data is treated as complete scan lines, with unused bits inserted at
the end of each scan line to fill out the last byte. This approach is compatible
with the PDF convention for sampled image data.
• Encoded data is ordinarily treated as a continuous, unbroken bit stream. The
EncodedByteAlign parameter (described in Table 3.9) can be used to cause
each encoded scan line to be filled to a byte boundary. Although this is not pre-
scribed by the CCITT standard and fax machines never do this, some software
packages find it convenient to encode data this way.
• When a filter reaches EOD, it always skips to the next byte boundary following
the encoded data.
If the
CCITTFaxDecode filter encounters improperly encoded source data, an
error occurs. The filter does not perform any error correction or resynchroniza-
tion, except as noted for the
DamagedRowsBeforeError parameter in Table 3.9.
Table 3.9 lists the optional parameters that can be used to control the decoding.
Except where noted otherwise, all values supplied to the decoding filter by any of
these parameters must match those used when the data was encoded.
TABLE 3.9 Optional parameters for the CCITTFaxDecode filter
KEY TYPE VALUE
K
integer A code identifying the encoding scheme used:
<0 Pure two-dimensional encoding (Group 4)
0 Pure one-dimensional encoding (Group 3, 1-D)
>0 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 filter distinguishes among negative, zero, and positive values of
K to determine how to interpret the encoded data; however, it does
not distinguish between different positive
K values. Default value: 0.
FiltersSECTION 3.3
55
The compression achieved using CCITT encoding depends on the data, as well as
on the value of various optional parameters. For Group 3 one-dimensional en-
EndOfLine
boolean A flag indicating whether end-of-line bit patterns are required to be
present in the encoding. The
CCITTFaxDecode filter always accepts
end-of-line bit patterns, but requires them only if
EndOfLine is true.
Default value:
false.
EncodedByteAlign
boolean A flag indicating whether the filter expects extra 0 bits before each
encoded line so that the line begins on a byte boundary. If
true, the
filter skips over encoded bits to begin decoding each line at a byte
boundary. If
false, the filter does not expect extra bits in the encod-
ed representation. Default value:
false.
Columns
integer The width of the image in pixels. If the value is not a multiple of 8,
the filter adjusts the width of the unencoded image to the next mul-
tiple of 8 so that each line starts on a byte boundary. Default value:
1728.
Rows
integer The height of the image in scan lines. If the value is 0 or absent, the
image’s height is not predetermined, and the encoded data must be
terminated by an end-of-block bit pattern or by the end of the fil-
ter’s data. Default value: 0.
EndOfBlock
boolean A flag indicating whether the filter expects the encoded data to be
terminated by an end-of-block pattern, overriding the
Rows param-
eter. If
false, the filter stops when it has decoded the number of lines
indicated by
Rows or when its data has been exhausted, whichever
occurs first. The end-of-block pattern is the CCITT end-of-facsimi-
le-block (EOFB) or return-to-control (RTC) appropriate for the
K
parameter. Default value: true.
BlackIs1
boolean A flag indicating whether 1 bits are to be interpreted as black pixels
and 0 bits as white pixels, the reverse of the normal PDF convention
for image data. Default value:
false.
DamagedRowsBeforeError
integer The number of damaged rows of data to be tolerated before an error
occurs. This entry applies only if
EndOfLine is true and K is non-
negative. Tolerating a damaged row means locating its end in the
encoded data by searching for an
EndOfLine pattern and then sub-
stituting decoded data from the previous row if the previous row
was not damaged, or a white scan line if the previous row was also
damaged. Default value: 0.
KEY TYPE VALUE
SyntaxCHAPTER 3
56
coding, in the best case (all zeros), 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.
3.3.6 JBIG2Decode Filter
The JBIG2Decode filter (PDF 1.4) decodes monochrome (1 bit per pixel) image
data that has been encoded using JBIG2 encoding. JBIG stands for the Joint Bi-
Level Image Experts Group, a group within the International Organization for
Standardization (ISO) that developed the format. JBIG2 is the second version of a
standard originally released as JBIG1.
JBIG2 encoding, which provides for both lossy and lossless compression, is useful
only for monochrome images, not for color images, grayscale images, or general
data. The algorithms used by the encoder, and the details of the format, are not
described here. A working draft of the JBIG2 specification can be found through
the Web site for the JBIG and JPEG (Joint Photographic Experts Group) commit-
tees at <http://www.jpeg.org>.
In general, JBIG2 provides considerably better compression than the existing
CCITT standard (discussed in Section 3.3.5). The compression it achieves de-
pends strongly on the nature of the image. Images of pages containing text in any
language compress particularly well, with typical compression ratios of 20:1 to
50:1 for a page full of text. The JBIG2 encoder builds a table of unique symbol bit-
maps found in the image, and other symbols found later in the image are
matched against the table. Matching symbols are replaced by an index into the ta-
ble, and symbols that fail to match are added to the table. The table itself is com-
pressed using other means. This method results in high compression ratios for
documents in which the same symbol is repeated often, as is typical for images
created by scanning text pages. It also results in high compression of white space
in the image, which does not need to be encoded because it contains no symbols.
While best compression is achieved for images of text, the JBIG2 standard also in-
cludes algorithms for compressing regions of an image that contain dithered half-
tone images (for example, photographs).
The JBIG2 compression method can also be used for encoding multiple images
into a single JBIG2 bit stream. Typically, these images are scanned pages of a mul-
tiple-page document. Since a single table of symbol bitmaps is used to match
FiltersSECTION 3.3
57
symbols across multiple pages, this type of encoding can result in higher com-
pression ratios than if each of the pages had been individually encoded using
JBIG2.
In general, an image may be specified in PDF as either an image XObject or an in-
line image (as described in Section 4.8, “Images”); however, the
JBIG2Decode fil-
ter can be applied only to image XObjects.
This filter addresses both single-page and multiple-page JBIG2 bit streams by
representing each JBIG2 page as a PDF image, as follows:
• The filter uses the embedded file organization of JBIG2. (The details of this and
the other types of file organization are provided in an annex of the ISO specifi-
cation.) The optional 2-byte combination (marker) mentioned in the specifica-
tion is not used in PDF. JBIG2 bit streams in random-access organization
should be converted to the embedded file organization. Bit streams in sequen-
tial organization need no reorganization, except for the mappings described
below.
• The JBIG2 file header, end-of-page segments, and end-of-file segment are not
used in PDF. These should be removed before the PDF objects described below
are created.
• The image XObject to which the JBIG2Decode filter is applied contains all seg-
ments that are associated with the JBIG2 page represented by that image; that
is, all segments whose segment page association field contains the page number
of the JBIG2 page represented by the image. In the image XObject, however, the
segment’s page number should always be 1; that is, when each such segment is
written to the XObject, the value of its segment page association field should be
set to 1.
• If the bit stream contains global segments (segments whose segment page asso-
ciation field contains 0), these segments must be placed in a separate PDF
stream, and the filter parameter listed in Table 3.10 should refer to that stream.
The stream can be shared by multiple image XObjects whose JBIG2 encodings
use the same global segments.
SyntaxCHAPTER 3
58
TABLE 3.10 Optional parameter for the JBIG2Decode filter
Example 3.4 shows an image that was compressed using the JBIG2 compression
method and then encoded in ASCII hexadecimal representation. Since the JBIG2
bit stream contains global segments, these segments are placed in a separate PDF
stream, as indicated by the
JBIG2Globals filter parameter.
Example 3.4
5 0 obj
<< /Type /XObject
/Subtype /Image
/Width 52
/Height 66
/ColorSpace /DeviceGray
/BitsPerComponent 1
/Length 224
/Filter [/ASCIIHexDecode /JBIG2Decode]
/DecodeParms [null << /JBIG2Globals 6 0 R >>]
>>
stream
000000013000010000001300000034000000420000000000
00000040000000000002062000010000001e000000340000
004200000000000000000200100000000231db51ce51ffac>
endstream
endobj
6 0 obj
<< /Length 126
/Filter /ASCIIHexDecode
>>
stream
0000000000010000000032000003fffdff02fefefe000000
01000000012ae225aea9a5a538b4d9999c5c8e56ef0f872
7f2b53d4e37ef795cc5506dffac>
endstream
endobj
KEY TYPE VALUE
JBIG2Globals
stream A stream containing the JBIG2 global (page 0) segments. Global segments
must be placed in this stream even if only a single JBIG2 image XObject re-
fers to it.
FiltersSECTION 3.3
59
The JBIG2 bit stream for this example is as follows:
97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01 00 00 00 00 00 01 00 00 00 00 32
00 00 03 FF FD FF 02 FE FE FE 00 00 00 01 00 00 00 01 2A E2 25 AE A9 A5
A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87 27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D
FF AC 00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00
00 00 00 00 00 40 00 00 00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34
00 00 00 42 00 00 00 00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51
FF AC 00 00 00 03 31 00 01 00 00 00 00 00 00 00 04 33 01 00 00 00 00
This bit stream is made up of the following parts (in the order listed):
1. The JBIG2 file header
97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01
Since the JBIG2 file header is not used in PDF, this header is not placed in the
JBIG2 stream object and is discarded.
2. The first JBIG2 segment (segment 0)—in this case, the symbol dictionary seg-
ment
00 00 00 00 00 01 00 00 00 00 32 00 00 03 FF FD FF 02 FE FE FE 00 00 00
01 00 00 00 01 2A E2 25 AE A9 A5 A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87
27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D FF AC
This is a global segment (segment page association = 0) and so is placed in the
JBIG2Globals stream.
3. The page information segment
00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00 00
00 00 00 00 40 00 00
and the immediate text region segment
00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34 00 00 00 42 00 00 00
00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51 FF AC
These two segments constitute the contents of the JBIG2 page and are placed
in the PDF XObject representing this image.
4. The end-of-page segment
00 00 00 03 31 00 01 00 00 00 00
and the end-of-file segment
00 00 00 04 33 01 00 00 00 00
Since these segments are not used in PDF, they are discarded.
SyntaxCHAPTER 3
60
The resulting PDF image object, then, contains the page information segment
and the immediate text region segment and refers to a
JBIG2Globals stream that
contains the symbol dictionary segment.
3.3.7 DCTDecode Filter
The DCTDecode filter decodes grayscale or color image data that has been encod-
ed in the JPEG baseline format. (JPEG stands for the Joint Photographic Experts
Group, a group within the International Organization for Standardization that
developed the format; DCT stands for discrete cosine transform, the primary
technique used in the encoding.)
JPEG encoding is a lossy compression method, designed specifically for compres-
sion of sampled continuous-tone images and not for general data compression.
Data to be encoded using JPEG consists of a stream of image samples, each con-
sisting of one, two, three, or four color components. The color component values
for a particular sample must appear consecutively. Each component value occu-
pies an 8-bit byte.
During encoding, several parameters control the algorithm and the information
loss. The values of these parameters, which include the dimensions of the image
and the number of components per sample, are entirely under the control of the
encoder and are stored in the encoded data.
DCTDecode generally obtains the
parameter values it requires directly from the encoded data. However, in one
instance, the parameter might not be present in the encoded data but must be
specified in the filter parameter dictionary; see Table 3.11.
The details of the encoding algorithm are not presented here but are in the ISO
specification and in JPEG: Still Image Data Compression Standard, by Pennebaker
and Mitchell (see the Bibliography). Briefly, the JPEG algorithm breaks an image
up into blocks that are 8 samples wide by 8 samples shigh. 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 this quantization that
results in the loss of information in the JPEG algorithm. The quantized coef-
ficients are then compressed.
FiltersSECTION 3.3
61
TABLE 3.11 Optional parameter for the DCTDecode filter
The encoding algorithm can reduce the information loss by making the step size
in the quantization smaller at the expense of reducing the amount of compression
achieved by the algorithm. The compression achieved by the JPEG algorithm de-
pends on the image being compressed and the amount of loss that is acceptable.
In general, a compression of 15:1 can be achieved without perceptible loss of in-
formation, and 30:1 compression causes little impairment of the image.
Better compression is often possible for color spaces that treat luminance and
chrominance separately than for those that do not. The RGB-to-YUV conversion
provided by the filters is one attempt to separate luminance and chrominance; it
conforms to CCIR recommendation 601-1. Other color spaces, such as the CIE
1976 L*a*b* space, may also achieve this objective. The chrominance compo-
nents can then be compressed more than the luminance by using coarser sam-
pling or quantization, with no degradation in quality.
The JPEG filter implementation in Acrobat products does not support features of
the JPEG standard that are irrelevant to images. In addition, certain choices have
KEY TYPE VALUE
ColorTransform
integer A code specifying the transformation to be performed on the sample values:
0 No transformation.
1 If the image has three color components, transform RGB values to
YUV before encoding and from YUV to RGB after decoding. If the
image has four components, transform CMYK values to YUVK be-
fore encoding and from YUVK to CMYK after decoding. This option
is ignored if the image has one or two color components.
Note: The RGB and YUV used here have nothing to do with the color spaces de-
fined as part of the Adobe imaging model. The purpose of converting from RGB
to YUV is to separate luminance and chrominance information (see below).
The default value of
ColorTransform is 1 if the image has three components
and 0 otherwise. In other words, conversion between RGB and YUV is per-
formed for all three-component images unless explicitly disabled by setting
ColorTransform to 0. Additionally, the encoding algorithm inserts an Adobe-
defined marker code in the encoded data, indicating the
ColorTransform val-
ue used. If present, this marker code overrides the
ColorTransform value giv-
en to
DCTDecode. Thus it is necessary to specify ColorTransform only when
decoding data that does not contain the Adobe-defined marker code.
SyntaxCHAPTER 3
62
been made regarding reserved marker codes and other optional features of the
standard. For details, see Adobe Technical Note #5116, Supporting the DCT Filters
in PostScript Level 2.
In addition to the baseline JPEG format, beginning with PDF 1.3, the
DCTDecode
filter supports the progressive JPEG extension. This extension does not add any
entries to the
DCTDecode parameter dictionary; the distinction between baseline
and progressive JPEG is represented in the encoded data.
Note: There is no benefit to using progressive JPEG for stream data that is embed-
ded in a PDF file. Decoding progressive JPEG is slower and consumes more memory
than baseline JPEG. The purpose of this feature is to enable a stream to refer to an
external file whose data happens to be already encoded in progressive JPEG. (See
also implementation note 11 in Appendix H.)
3.3.8 JPXDecode Filter
The JPXDecode filter (PDF 1.5) decodes data that has been encoded using the
JPEG2000 compression method, an international standard for the compression
and packaging of image data. JPEG2000 defines a wavelet-based method for im-
age compression that gives somewhat better size reduction than other methods
such as regular JPEG or CCITT. Although the filter can reproduce samples that
are losslessly compressed, it is recommended only for use with images and not for
general data compression.
In PDF, this filter can be applied only to image XObjects, and not to inline images
(see Section 4.8, “Images”). It is suitable both for images that have a single color
component and for those that have multiple color components. The color com-
ponents in an image may have different numbers of bits per sample. Any value
from 1 to 38 is allowed.
From a single JPEG2000 data stream, multiple versions of an image may be de-
coded. These different versions form progressions along four degrees of freedom:
sampling resolution, color depth, band, and location. For example, with a resolu-
tion progression, a thumbnail version of the image may be decoded from the
data, followed by a sequence of other versions of the image, each with approxi-
mately four times as many samples (twice the width times twice the height) as the
previous one. The last version is the full-resolution image.
FiltersSECTION 3.3
63
Viewing and printing applications may gain performance benefits by using the
resolution progression. If the full-resolution image is densely sampled, the appli-
cation may be able to select and decode only the data making up a lower-resolu-
tion version, thereby spending less time decoding. Fewer bytes need be
processed, a particular benefit when viewing files over the Web. The tiling struc-
ture of the image may also provide benefits if only certain areas of an image need
to be displayed or printed.
Note: Information on these progressions is encoded in the data; no decode parame-
ters are needed to describe them. The decoder deals with any progressions it encoun-
ters to deliver the correct image data. Progressions that are of no interest may simply
have performance consequences.
The JPEG2000 specifications define two widely used formats, JP2 and JPX, for
packaging the compressed image data. JP2 is a subset of JPX. These packagings
contain all the information needed to properly interpret the image data, includ-
ing the color space, bits per component, and image dimensions. In other words,
they are complete descriptions of images (as opposed to image data that require
outside parameters for correct interpretation). The
JPXDecode filter expects to
read a full JPX file structure—either internal to the PDF file or as an external file.
To promote interoperability, the specifications define a subset of JPX called JPX
baseline (of which JP2 is also a subset). The complete details of the baseline set of
JPX features are contained in ISO/IEC 15444-2, Information Technology—JPEG
2000 Image Coding System: Extensions (see the Bibliography). See also
<http://www.jpeg.org/jpeg2000/>.
Data used in PDF image XObjects should be limited to the JPX baseline set of
features, except for enumerated color space 19 (CIEJab). In addition, enumerated
color space 12 (CMYK), which is part of JPX but not JPX baseline, is supported in
PDF.
A JPX file describes a collection of channels that are present in the image data. A
channel may have one of three types:
• An ordinary channel contains values that, when decoded, become samples for a
specified color component.
• An opacity channel provides samples that are to be interpreted as raw opacity
information.
SyntaxCHAPTER 3
64
• A premultiplied opacity channel provides samples that have been multiplied
into the color samples of those channels with which it is associated.
Opacity and premultiplied opacity channels are associated with specific color
channels. There is never more than one opacity channel (of either type) associat-
ed with a given color channel. For example, it is possible for one opacity channel
to apply to the red samples and another to apply to the green and blue color chan-
nels of an RGB image.
Note: The method by which the opacity information is to be used is explicitly not
specified, although one possible method shows a normal blending mode.
In addition to using opacity channels for describing transparency, JPX files also
have the ability to specify chroma-key transparency. A single color is specified by
giving an array of values, one value for each color channel. Any image location
that matches this color is considered to be completely transparent.
Images in JPX files can have one of the following color spaces:
• A predefined color space, chosen from a list of enumerated color spaces. (Two of
these are actually families of spaces and parameters are included.)
• A “restricted ICC profile.” (These are the only sorts of ICC profiles that are al-
lowed in JP2 files.)
• An input ICC profile of any sort defined by ICC-1.
• A vendor-defined color space.
More than one color space may be specified for an image, with each space being
tagged with a precedence and an approximation value that indicates how well it
represents the preferred color space. In addition, the image’s color space may
serve as the foundation for a palette of colors that are selected using samples com-
ing from the image’s data channels: the equivalent of an
Indexed color space in
PDF.
There are other features in the JPX format beyond describing a simple image.
These include provisions for describing layering and giving instructions on com-
position, specifying simple animation, and including generic XML metadata
(along with JPEG2000-specific schemas for such data). It is recommended, but
not required, that relevant metadata be replicated in the image dictionary’s
Metadata stream in XMP format (see Section 10.2.2, “Metadata Streams).
FiltersSECTION 3.3
65
When using the JPXDecode filter with image XObjects, there are changes to and
constraints on some entries in the image dictionary (see Section 4.8.4, “Image
Dictionaries” for details on these entries):
• Width and Height must match the corresponding width and height values in
the JPEG2000 data.
• ColorSpace is optional since JPEG2000 data contain color space specifications.
If present, it determines how the image samples are interpreted, and the color
space specifications in the JPEG2000 data are ignored. The number of color
channels in the JPEG2000 data must match the number of components in the
color space; the PDF producer must ensure that the samples are consistent with
the color space used.
Any color space other than
Pattern may be specified. If an Indexed color space
is used, it is subject to the PDF limit of 256 colors. (The analogous concept in
the JPEG2000 color specifications is a palette color space, which has a limit of
1024 colors.) If the color space does not match one of JPX’s enumerated color
spaces (for example, if it has two color components or more than four), it can
be specified as a vendor color space in the JPX data.
If
ColorSpace is not present in the image dictionary, the color space informa-
tion in the JPEG2000 data is used. Consumer applications must support the
JPX baseline set of enumerated color spaces; they are also responsible for deal-
ing with the interaction between the color spaces and the bit depth of samples.
If multiple color space specifications are given in the JPEG2000 data, a render-
ing application should attempt to use the one with the highest precedence and
best approximation value. If the color space is given by an unsupported ICC
profile, the next lower color space, in terms of precedence and approximation
value, is used. If no supported color space is found, the color space used should
be
DeviceGray, DeviceRGB, or DeviceCMYK, depending on the number of color
channels in the JPEG2000 data.
• SMaskInData specifies whether soft-mask information packaged with the im-
age samples should be used (see “Soft-Mask Images” on page 522); if it is, the
SMask entry is not needed. If SMaskInData is nonzero, there must be only one
opacity channel in the JPEG2000 data and it must apply to all color channels.
• Decode is ignored, except in the case where the image is treated as a mask; that
is, when
ImageMask is true. In this case, the JPEG2000 data must provide a sin-
gle color channel with 1-bit samples.
SyntaxCHAPTER 3
66
3.3.9 Crypt Filter
The Crypt filter (PDF 1.5) allows the document-level security handler (see Sec-
tion 3.5, “Encryption”) to determine which algorithms should be used to decrypt
the input data. The
Name parameter in the decode parameters dictionary for this
filter (see Table 3.12) specifies which of the named crypt filters in the document
(see Section 3.5.4, “Crypt Filters”) should be used.
TABLE 3.12 Optional parameters for Crypt filters
In addition, the decode parameters dictionary may include entries that are pri-
vate to the security handler. Security handlers may use information from both the
crypt filter decode parameters dictionary and the crypt filter dictionaries (see Ta-
ble 3.22) when decrypting data or providing a key to decrypt data.
Note: When adding private data to the decode parameters dictionary, security han-
dlers should name these entries in conformance with the PDF name registry (see
Appendix E, “PDF Name Registry”).
3.4 File Structure
The preceding sections describe the syntax of individual objects. This section
describes how objects are organized in a PDF file for efficient random access and
incremental update. A canonical PDF file initially consists of four elements (see
Figure 3.2):
• A one-line header identifying the version of the PDF specification to which the
file conforms
• A body containing the objects that make up the document contained in the file
KEY TYPE VALUE
Type
name (Optional) If present, must be CryptFilterDecodeParms for a Crypt filter de-
code parameter dictionary.
Name
name (Optional) The name of the crypt filter that is to be used to decrypt this
stream. The name must correspond to an entry in the
CF entry of the encryp-
tion dictionary (see Table 3.18) or one of the standard crypt filters (see Table
3.23).
Default value:
Identity.
File StructureSECTION 3.4
67
• A cross-reference table containing information about the indirect objects in the
file
• A trailer giving the location of the cross-reference table and of certain special
objects within the body of the file
This initial structure may be modified by later updates, which append additional
elements to the end of the file; see Section 3.4.5, “Incremental Updates,” for
details.
FIGURE 3.2 Initial structure of a PDF file
As a matter of convention, the tokens in a PDF file are arranged into lines; see
Section 3.1, “Lexical Conventions.” Each line is terminated by an end-of-line
(EOL) marker, which may be a carriage return (character code 13), a line feed
(character code 10), or both. PDF files with binary data may have arbitrarily long
lines. However, to increase compatibility with other applications that process
PDF files, lines that are not part of stream object data are limited to no more than
255 characters, with one exception. Beginning with PDF 1.3, the
Contents string
Header
Body
Cross-reference
table
Trailer
SyntaxCHAPTER 3
68
of a signature dictionary (see Section 8.7, “Digital Signatures”) is not subject to
the restriction on line length. See also implementation note 12 in Appendix H.
The rules described here are sufficient to produce a well-formed PDF file. How-
ever, additional rules apply to organizing a PDF file to enable efficient incremen-
tal access to a document’s components in a network environment. This form of
organization, called Linearized PDF, is described in Appendix F.
3.4.1 File Header
The first line of a PDF file is a header identifying the version of the PDF specifica-
tion to which the file conforms. For a file conforming to PDF version 1.5, the
header should be
%PDF1.5
However, since any file conforming to an earlier version of PDF also conforms to
version 1.4, an application that processes PDF 1.4 can also accept files with any of
the following headers:
%PDF1.0
%PDF1.1
%PDF1.2
%PDF1.3
(See also implementation notes 13 and 14 in Appendix H.)
In PDF 1.4, the version in the file header can be overridden by the
Version entry
in the document’s catalog dictionary (located by means of the
Root entry in the
file’s trailer, as described in Section 3.4.4, “File Trailer”). This enables a PDF pro-
ducer application to update the version using an incremental update (see Section
3.4.5, “Incremental Updates”).
Under some conditions, a consumer application may be able to process PDF files
conforming to a later version than it was designed to accept. New PDF features
are often introduced in such a way that they can safely be ignored by a consumer
that does not understand them (see Section H.1, “PDF Version Numbers”).
Note: If a PDF file contains binary data, as most do (see Section 3.1, “Lexical Con-
ventions”), it is recommended that the header line be immediately followed by a
File StructureSECTION 3.4
69
comment line containing at least four binary characters—that is, characters whose
codes are 128 or greater. This ensures proper behavior of file transfer applications
that inspect data near the beginning of a file to determine whether to treat the file’s
contents as text or as binary.
3.4.2 File Body
The body of a PDF file consists of a sequence of indirect objects representing the
contents of a document. The objects, which are of the basic types described in
Section 3.2, “Objects,” represent components of the document such as fonts,
pages, and sampled images. Beginning with PDF 1.5, the body can also contain
object streams, each of which contains a sequence of indirect objects; see Section
3.4.6, “Object Streams.”
3.4.3 Cross-Reference Table
The cross-reference table contains information that permits random access to in-
direct objects within the file so that the entire file need not be read to locate any
particular object. The table contains a one-line entry for each indirect object,
specifying the location of that object within the body of the file. (Beginning with
PDF 1.5, some or all of the cross-reference information may alternatively be con-
tained in cross-reference streams; see Section 3.4.7, “Cross-Reference Streams”.)
The cross-reference table is the only part of a PDF file with a fixed format, which
permits entries in the table to be accessed randomly. The table comprises one or
more cross-reference sections. Initially, the entire table consists of a single section
(or two sections if the file is linearized; see Appendix F). One additional section is
added each time the file is updated (see Section 3.4.5, “Incremental Updates”).
Each cross-reference section begins with a line containing the keyword
xref. Fol-
lowing this line are one or more cross-reference subsections, which may appear in
any order. The subsection structure is useful for incremental updates, since 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. For a file that has never
been updated, the cross-reference section contains only one subsection, whose
object numbering begins at 0.
Each cross-reference subsection contains entries for a contiguous range of object
numbers. The subsection begins with a line containing two numbers separated by
SyntaxCHAPTER 3
70
a space: the object number of the first object in this subsection and the number of
entries in the subsection. For example, the line
28 5
introduces a subsection containing five objects numbered consecutively from 28
to 32.
Note: A given object number must not have an entry in more than one subsection
within a single section. However, see implementation note 15 in Appendix H.
Following this line are the cross-reference entries themselves, one per line. Each
entry is exactly 20 bytes long, including the end-of-line marker. There are two
kinds of cross-reference entries: one for objects that are in use and another for
objects that have been deleted and therefore are free. Both types of entries have
similar basic formats, distinguished by the keyword
n (for an in-use entry) or f
(for a free entry). The format of an in-use entry is
nnnnnnnnnn ggggg n eol
where
nnnnnnnnnn is a 10-digit byte offset
ggggg is a 5-digit generation number
n is a literal keyword identifying this as an in-use entry
eol is a 2-character end-of-line sequence
The byte offset is a 10-digit number, padded with leading zeros if necessary,
giving the number of bytes from the beginning of the file to the beginning of the
object. It is separated from the generation number by a single space. The genera-
tion number is a 5-digit number, also padded with leading zeros if necessary. Fol-
lowing the generation number is a single space, the keyword
n, and a 2-character
end-of-line sequence. If the file’s end-of-line marker is a single character (either a
carriage return or a line feed), it is preceded by a single space; if the marker is 2
characters (both a carriage return and a line feed), it is not preceded by a space.
Thus, the overall length of the entry is always exactly 20 bytes.
File StructureSECTION 3.4
71
The cross-reference entry for a free object has essentially the same format, except
that the keyword is
f instead of n and the interpretation of the first item is differ-
ent:
nnnnnnnnnn ggggg f eol
where
nnnnnnnnnn is the 10-digit object number of the next free object
ggggg is a 5-digit generation number
f is a literal keyword identifying this as a free entry
eol is a 2-character end-of-line sequence
The free entries in the cross-reference table form a linked list, with each free entry
containing the object number of the next. The first entry in the table (object
number 0) is always free and has a generation number of 65,535; it is the head of
the linked list of free objects. The last free entry (the tail of the linked list) links
back to object number 0. (In addition, the table may contain other free entries
that link back to object number 0 and have a generation number of 65,535, even
though these entries are not in the linked list itself.) See implementation note 16
in Appendix H.
Except for object number 0, all objects in the cross-reference table initially have
generation numbers of 0. When an indirect object is deleted, its cross-reference
entry is marked free and it is added to the linked list of free entries. The entry’s
generation number is incremented by 1 to indicate the generation number to be
used the next time an object with that object number is created. Thus, each time
the entry is reused, it is given a new generation number. The maximum genera-
tion number is 65,535; when a cross-reference entry reaches this value, it is never
reused.
The cross-reference table (comprising the original cross-reference section and all
update sections) must contain one entry for each object number from 0 to the
maximum object number used in the file, even if one or more of the object num-
bers in this range do not actually occur in the file. See implementation note 17 in
Appendix H.
Example 3.5 shows a cross-reference section consisting of a single subsection
with six entries: four that are in use (objects number 1, 2, 4, and 5) and two that
SyntaxCHAPTER 3
72
are free (objects number 0 and 3). Object number 3 has been deleted, and the
next object created with that object number is given a generation number of 7.
Example 3.5
xref
06
0000000003 65535 f
0000000017 00000 n
0000000081 00000 n
0000000000 00007 f
0000000331 00000 n
0000000409 00000 n
Example 3.6 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
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 3.6
xref
01
0000000000 65535 f
31
0000025325 00000 n
23 2
0000025518 00002 n
0000025635 00000 n
30 1
0000025777 00000 n
See Section G.6, “Updating Example,” for a more extensive example of the struc-
ture of a PDF file that has been updated several times.
3.4.4 File Trailer
The trailer of a PDF file enables an application reading the file to quickly find the
cross-reference table and certain special objects. Applications should read a PDF
File StructureSECTION 3.4
73
file from its end. The last line of the file contains only the end-of-file marker,
%%EOF. (See implementation note 18 in Appendix H.) The two preceding lines
contain the keyword
startxref and the byte offset from the beginning of the file to
the beginning of the
xref keyword in the last cross-reference section. The
startxref line is preceded by the trailer dictionary, consisting of the keyword
trailer followed by a series of key-value pairs enclosed in double angle brackets
(
<<…>>). Thus, the trailer has the following overall structure:
trailer
<< key
1
value
1
key
2
value
2
…
key
n
value
n
>>
startxref
Byte_offset_of_last_cross-reference_section
%%EOF
Table 3.13 lists the contents of the trailer dictionary.
TABLE 3.13 Entries in the file trailer dictionary
KEY TYPE VALUE
Size
integer (Required; must not be an indirect reference) The total number of entries in the file’s
cross-reference table, as defined by the combination of the original section and all
update sections. Equivalently, this value is 1 greater than the highest object number
used in the file.
Note: Any object in a cross-reference section whose number is greater than this value is
ignored and considered missing.
Prev
integer (Present only if the file has more than one cross-reference section; must not be an indi-
rect reference) The byte offset from the beginning of the file to the beginning of the
previous cross-reference section.
Root
dictionary (Required; must be an indirect reference) The catalog dictionary for the PDF docu-
ment contained in the file (see Section 3.6.1, “Document Catalog”).
Encrypt
dictionary (Required if document is encrypted; PDF 1.1) The document’s encryption dictionary
(see Section 3.5, “Encryption”).
Info
dictionary (Optional; must be an indirect reference) The document’s information dictionary
(see Section 10.2.1, “Document Information Dictionary”).
SyntaxCHAPTER 3
74
Note: Table 3.17 defines an additional entry, XRefStm, that appears only in the trail-
er of hybrid-reference files, described in “Compatibility with PDF 1.4” on page 85.
Example 3.7 shows an example trailer for a file that has never been updated (as
indicated by the absence of a
Prev entry in the trailer dictionary).
Example 3.7
trailer
<< /Size 22
/Root 2 0 R
/Info 1 0 R
/ID [ <81b14aafa313db63dbd6f981e49f94f4 >
<81b14aafa313db63dbd6f981e49f94f4 >
]
>>
startxref
18799
%%EOF
3.4.5 Incremental Updates
The contents of a PDF file can be updated incrementally without rewriting the
entire file. Changes are appended to the end of the file, leaving its original con-
tents intact. The main advantage to updating a file in this way (as discussed in
Section 2.2.7, “Incremental Update”) is that small changes to a large document
can be saved quickly. There are additional advantages:
• In some cases, incremental updating is the only way to save changes to a docu-
ment. An accepted practice for minimizing the risk of data loss when saving a
document is to write it to a new file and rename the new file to replace the old
one. However, in certain contexts, such as when editing a document across an
HTTP connection or using OLE embedding (a Windows-specific technology),
ID
array (Optional, but strongly recommended; PDF 1.1) An array of two strings constituting
a file identifier (see Section 10.3, “File Identifiers”) for the file. Although this entry is
optional, its absence might prevent the file from functioning in some workflows
that depend on files being uniquely identified.
KEY TYPE VALUE
File StructureSECTION 3.4
75
it is not possible to overwrite the contents of the original file in this manner. In-
cremental updates can be used to save changes to documents in these contexts.
• Once a document has been signed (see Section 2.2.6, “Security”), all changes
made to the document must be saved using incremental updates, since altering
any existing bytes in the file invalidates existing signatures.
In an incremental update, any new or changed objects are appended to the file, a
cross-reference section is added, and a new trailer is inserted. The resulting file
has the structure shown in Figure 3.3. A complete example of an updated file is
shown in Section G.6, “Updating Example.”
The cross-reference section added when a file is updated contains entries only for
objects that have been changed, replaced, or deleted. Deleted objects are left un-
changed in the file, but are marked as deleted by means of their cross-reference
entries. The added trailer contains all the entries (perhaps modified) from the
previous trailer, as well as a
Prev entry giving the location of the previous cross-
reference section (see Table 3.13 on page 73). As shown in Figure 3.3, a file that
has been updated several times contains several trailers; each trailer is terminated
by its own end-of-file (
%%EOF) marker.
Because updates are appended to PDF files, a file can have several copies of an
object with the same object identifier (object number and generation number).
This can occur, for example, if a text annotation (see Section 8.4, “Annotations”)
is changed several times and the file is saved between changes. Because the text
annotation object is not deleted, it retains the same object number and generation
number as before. An updated copy of the object is included in the new update
section added to the file. The update’s cross-reference section includes a byte off-
set to this new copy of the object, overriding the old byte offset contained in the
original cross-reference section. When a consumer application reads the file, it
must build its cross-reference information in such a way that the most recent
copy of each object is the one accessed in the file.
In versions of PDF earlier than 1.4, it was not possible to use an incremental up-
date to alter the version of PDF to which the document conforms, since the ver-
sion was specified only in the header at the beginning of the file (see Section
3.4.1, “File Header”). In PDF 1.4, it is possible for a
Version entry in the docu-
ment’s catalog dictionary (see Section 3.6.1, “Document Catalog”) to override the
version specified in the header, which enables the version to be altered using an
incremental update.
SyntaxCHAPTER 3
76
FIGURE 3.3 Structure of an updated PDF file
3.4.6 Object Streams
PDF 1.5 introduces a new kind of stream, an object stream, which contains a se-
quence of PDF objects. The purpose of object streams is to allow a greater num-
ber of PDF objects to be compressed, thereby substantially reducing the size of
PDF files. The objects in the stream are referred to as compressed objects. (This
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
File StructureSECTION 3.4
77
term is used regardless of whether the stream is actually encoded with a compres-
sion filter.)
Any PDF object can appear in an object stream, with the following exceptions:
• Stream objects
• Objects with a generation number other than zero
• A document’s encryption dictionary (see Section 3.5, “Encryption”)
• An object representing the value of the Length entry in an object stream dictio-
nary
Note: In addition, in linearized files (see Appendix F, “Linearized PDF”), the docu-
ment catalog, the linearization dictionary, and page objects may not appear in an
object stream.
Indirect references to objects inside object streams use the normal syntax: for ex-
ample,
14 0 R. Access to these objects requires a different way of storing cross-ref-
erence information; see Section 3.4.7, “Cross-Reference Streams.” Although an
application must support PDF 1.5 to use compressed objects, the objects can be
stored in a manner that is compatible with PDF 1.4. Applications that do not sup-
port PDF 1.5 can ignore the objects; see “Compatibility with PDF 1.4” on page 85.
In addition to the standard keys for streams shown in Table 3.4, the stream dictio-
nary describing an object stream contains the following entries:
TABLE 3.14 Additional entries specific to an object stream dictionary
KEY TYPE DESCRIPTION
Type
name (Required) The type of PDF object that this dictionary describes; must be ObjStm
for an object stream.
N
integer (Required) The number of compressed objects in the stream.
First
integer (Required) The byte offset (in the decoded stream) of the first compressed object.
Extends
stream (Optional) A reference to an object stream, of which the current object stream is
considered an extension. Both streams are considered part of a collection of object
streams (see below). A given collection consists of a set of streams whose
Extends
links form a directed acyclic graph.
SyntaxCHAPTER 3
78
The creator of a PDF file has flexibility in determining which objects, if any, to
store in object streams. For example, it can be useful to store objects having com-
mon characteristics together, such as “fonts on page 1,” or “Comments for draft
#3.” These objects are known as a collection.
To avoid a degradation of performance, such as would occur when downloading
and decompressing a large object stream to access a single compressed object, the
number of objects in an individual object stream should be limited. (See imple-
mentation note 19 in Appendix H.) This may require a group of object streams to
be linked as a collection, which can be done by means of the
Extends entry in the
object stream dictionary.
Extends can also be used when a collection is being updated to include new ob-
jects. Rather than redefine the original object stream, which would require dupli-
cating the stream data, the new objects can be stored in a new object stream. This
is particularly important when adding an update section to a document.
The stream data in an object stream consists of the following items:
• N pairs of integers, where the first integer in each pair represents the object
number of a compressed object and the second integer represents the byte off-
set of that object, relative to the first one. The offsets must be in increasing or-
der, but there is no restriction on the order of object numbers.
Note: The byte offset in the decoded stream of the first object is the value of the
First entry.
• The N objects stored consecutively. Only the object values are stored in the
stream; the
obj and endobj keywords are not used. A compressed dictionary or
array may contain indirect references.
Note: It is illegal for a compressed object to consist of only an indirect reference;
for example,
3 0 R.
By contrast, dictionaries and arrays in content streams (Section 3.7.1) may not
contain indirect references. In an encrypted file, strings occurring anywhere in
an object stream must not be separately encrypted, since the entire object
stream is encrypted.
Note: The data for the first object is not required to immediately follow the last
byte offset. Future extensions may place additional information between those
two points in the stream.
File StructureSECTION 3.4
79
An object stream itself, like any stream, is an indirect object, and there must be an
entry for it in a cross-reference table or cross-reference stream (see Section 3.4.7,
“Cross-Reference Streams”), although there might not be any references to it (of
the form
243 0 R).
The generation number of an object stream and of any compressed object is im-
plicitly zero. If either an object stream or a compressed object is deleted and the
object number is freed, that object number can be reused only for an ordinary
(uncompressed) object other than an object stream. When new object streams
and compressed objects are created, they must always be assigned new object
numbers, not old ones taken from the free list.
Example 3.8 shows three objects (two fonts and a font descriptor) as they would
be represented in a PDF 1.4 or earlier file, along with a cross-reference table. In
Example 3.9, the same objects are stored in an object stream in a PDF 1.5 file,
along with a cross-reference stream.
Example 3.8
11 0 obj
<< /Type /Font
/Subtype /TrueType
...other entries...
/FontDescriptor 12 0 R
>>
endobj
12 0 obj
<< /Type /FontDescriptor
/Ascent 891
...other entries...
/FontFile2 22 0 R
>>
endobj
13 0 obj
<< /Type /Font
/Subtype /Type0
...other entries...
/ToUnicode 10 0 R
>>
endobj
SyntaxCHAPTER 3
80
...
xref
0 32
0000000000 65535 f
...
0000001434 00000 n % Cross-reference entry for object 11
0000001735 00000 n % Cross-reference entry for object 12
0000002155 00000 n % Cross-reference entry for object 13
...
trailer
<< /Size 32
/Root ...
>>
In Example 3.9, the cross-reference stream (see Section 3.4.7, “Cross-Reference
Streams”) contains entries for the fonts (objects 11 and 13) and the descriptor
(object 12), which are compressed objects in an object stream. The first field of
these entries is the entry type (2), the second field is the number of the object
stream (15), and the third field is the position within the sequence of objects in
the object stream (0, 1, and 2). The cross-reference stream also contains a type 1
entry for the object stream itself.
Note: For readability, the object stream has been shown unencoded. In a real PDF
1.5 file, Flate encoding would typically be used to gain the benefits of compression.
Example 3.9
15 0 obj % The object stream
<< /Type /ObjStm
/Length 1856
/N 3 % The number of objects in the stream
/First 24 % The byte offset of the first object
>>
stream
% The object numbers and offsets of the objects, relative to the first
11 0 12 547 13 665
<< /Type /Font
/Subtype /TrueType
...other keys...
/FontDescriptor 12 0 R
>>
File StructureSECTION 3.4
81
<< /Type /FontDescriptor
/Ascent 891
...other keys...
/FontFile2 22 0 R
>>
<< /Type /Font
/Subtype /Type0
...other keys...
/ToUnicode 10 0 R
>>
...
endstream
endobj
99 0 obj % The cross-reference stream
<< /Type /XRef
/Index [0 32] % This section has one subsection with 32 objects
/W [1 2 2] % Each entry has 3 fields: 1, 2 and 2 bytes in width,
% respectively
/Filter /ASCIIHexDecode % For readability in this example
/Size 32
...
>>
stream
00 0000 FFFF % “0 65535 f” in a cross-reference table
...
02 000F 0000 % The entry for object 11, the first font
02 000F 0001 % The entry for object 12, the font descriptor
02 000F 0002 % The entry for object 13, the second font
...
01 BA5E 0000 % The entry for object 15, the object stream
...
endstream
endobj
startxref
54321 % The offset of “99 0 obj”
%%EOF
SyntaxCHAPTER 3
82
3.4.7 Cross-Reference Streams
Beginning with PDF 1.5, cross-reference information may be stored in a cross-ref-
erence stream instead of in a cross-reference table. Cross-reference streams pro-
vide the following advantages:
• A more compact representation of cross-reference information
• The ability to access compressed objects that are stored in object streams (see
Section 3.4.6, “Object Streams”) and to allow new cross-reference entry types to
be added in the future
Cross-reference streams are stream objects (see Section 3.2.7, “Stream Objects”),
and contain a dictionary and a data stream. Each cross-reference stream contains
the information equivalent to the cross-reference table (see Section 3.4.3, “Cross-
Reference Table”) and trailer (see Section 3.4.4, “File Trailer”) for one cross-refer-
ence section. The trailer dictionary entries are stored in the stream dictionary,
and the cross-reference table entries are stored as the stream data, as shown in the
following example:
Example 3.10
... objects ...
12 0 obj % Cross-reference stream
<< /Type /XRef % Cross-reference stream dictionary
/Size ...
/Root ...
>>
stream
... % Stream data containing cross-reference information
endstream
endobj
... more objects ...
startxref
byte_offset_of_cross-reference_stream % Points to object 12
%%EOF
Note that the value following the startxref keyword is now the offset of the cross-
reference stream rather than an
xref keyword. For files that use cross-reference
streams entirely (that is, PDF 1.5 files that are not hybrid-reference files; see
File StructureSECTION 3.4
83
“Compatibility with PDF 1.4” on page 85), the keywords xref and trailer are no
longer used. Therefore, with the exception of the
startxref address %%EOF seg-
ment and comments, a PDF 1.5 file is entirely a sequence of objects.
Note: The use of object streams and cross-reference streams is permitted in linear-
ized PDF, with minor modifications to the specification (see Section F.2, “Linearized
PDF Document Structure”).
Cross-Reference Stream Dictionary
Cross-reference streams contain the entries shown in Table 3.15 in addition to the
entries common to all streams (Table 3.4) and trailer dictionaries (Table 3.13).
Since some of the information in the cross-reference stream is needed by the con-
sumer application to construct the index that allows indirect references to be re-
solved, the entries in cross-reference streams are subject to the following
restrictions:
• The value of all entries shown in Table 3.15 must be direct objects; indirect ref-
erences are not permitted. For arrays (the
Index and W entries), all their ele-
ments must be direct objects as well. If the stream is encoded, the
Filter and
DecodeParms entries in Table 3.4 must also be direct objects. Also, see imple-
mentation note 20 in Appendix H.
Note: Other cross-reference stream entries not listed in Table 3.15 may be indirect;
in fact, some (such as
Root in Table 3.13) are required to be indirect.
• The cross-reference stream must not be encrypted, nor may any strings appear-
ing in the cross-reference stream dictionary. It must not have a
Filter entry that
specifies a
Crypt filter (see 3.3.9, “Crypt Filter”).
TABLE 3.15 Additional entries specific to a cross-reference stream dictionary
KEY TYPE DESCRIPTION
Type
name (Required) The type of PDF object that this dictionary describes; must be XRef for
a cross-reference stream.
Size
integer (Required) The number one greater than the highest object number used in this
section or in any section for which this is an update. It is equivalent to the
Size en-
try in a trailer dictionary.
SyntaxCHAPTER 3
84
Cross-Reference Stream Data
Each entry in a cross-reference stream has one or more fields, the first of which
designates the entry’s type (see Table 3.16). In PDF 1.5, only types 0, 1, and 2 are
allowed. Any other value is interpreted as a reference to the null object, thus per-
mitting new entry types to be defined in the future.
The fields are written in increasing order of field number; the length of each field
is determined by the corresponding value in the
W entry (see Table 3.15). Fields
requiring more than one byte are stored with the high-order byte first.
Index
array (Optional) An array containing a pair of integers for each subsection in this sec-
tion. The first integer is the first object number in the subsection; the second inte-
ger is the number of entries in the subsection
The array is sorted in ascending order by object number. Subsections cannot over-
lap; an object number may have at most one entry in a section.
Default value:
[0 Size].
Prev
integer (Present only if the file has more than one cross-reference stream; not meaningful in
hybrid-reference files; see “Compatibility with PDF 1.4” on page 85) The byte offset
from the beginning of the file to the beginning of the previous cross-reference
stream. This entry has the same function as the
Prev entry in the trailer dictionary
(Table 3.13).
W
array (Required) An array of integers representing the size of the fields in a single cross-
reference entry. Table 3.16 describes the types of entries and their fields. For PDF
1.5,
W always contains three integers; the value of each integer is the number of
bytes (in the decoded stream) of the corresponding field. For example,
[1 2 1]
means that the fields are one byte, two bytes, and one byte, respectively.
A value of zero for an element in the
W array indicates that the corresponding field
is not present in the stream, and the default value is used, if there is one. If the first
element is zero, the type field is not present, and it defaults to type 1.
The sum of the items is the total length of each entry; it can be used with the
Index
array to determine the starting position of each subsection.
Note: Different cross-reference streams in a PDF file may use different values for
W.
KEY TYPE DESCRIPTION
File StructureSECTION 3.4
85
TABLE 3.16 Entries in a cross-reference stream
Like any stream, a cross-reference stream is an indirect object. Therefore, an en-
try for it must exist in either a cross-reference stream (usually itself) or in a cross-
reference table (in hybrid-reference files; see “Compatibility with PDF 1.4” on
page 85).
Compatibility with PDF 1.4
Applications that do not support PDF 1.5 cannot access objects that are refer-
enced by cross-reference streams. If a file uses cross-reference streams exclusively,
it cannot be opened by such applications.
However, it is possible to construct a file called a hybrid-reference file that is read-
able by a PDF 1.4 consumer. Such a file contains objects referenced by standard
TYPE FIELD DESCRIPTION
0 1 The type of this entry, which must be 0. Type 0 entries define the
linked list of free objects (corresponding to
f entries in a cross-
reference table).
2 The object number of the next free object.
3 The generation number to use if this object number is used again.
1 1 The type of this entry, which must be 1. Type 1 entries define
objects that are in use but are not compressed (corresponding to
n
entries in a cross-reference table).
2 The byte offset of the object, starting from the beginning of the
file.
3 The generation number of the object. Default value: 0.
2 1 The type of this entry, which must be 2. Type 2 entries define
compressed objects.
2 The object number of the object stream in which this object is
stored. (The generation number of the object stream is implicitly
0.)
3 The index of this object within the object stream.
SyntaxCHAPTER 3
86
cross-reference tables in addition to objects in object streams that are referenced
by cross-reference streams.
In these files, the trailer dictionary can contain, in addition to the entry for trail-
ers shown in Table 3.13, an additional entry, as shown in Table 3.17. This entry is
ignored by PDF 1.4 consumers, which therefore have no access to entries in the
cross-reference stream the entry refers to.
TABLE 3.17 Additional entries in a hybrid-reference file’s trailer dictionary
The Size entry of the trailer must be large enough to include all objects, including
those defined in the cross-reference stream referenced by the
XRefStm entry.
However, to allow random access, a main cross-reference section contain have
entries for all objects numbered 0 through
Size - 1 (see Section 3.4.3, “Cross-
Reference Table”). Therefore, the
XRefStm entry cannot be used in the trailer dic-
tionary of the main cross-reference section but only in an update cross-reference
section.
When a PDF 1.5 consumer opens a hybrid-reference file, objects with entries in
cross-reference streams are not hidden. When the application searches for an ob-
ject, if an entry is not found in any given standard cross-reference section, the
search proceeds to a cross-reference stream specified by the
XRefStm entry before
looking in the previous cross-reference section (the
Prev entry in the trailer).
Hidden objects, therefore, have two cross-reference entries. One is in the cross-
reference stream. The other is a free entry in some previous section, typically the
section referenced by the
Prev entry. A PDF 1.5 consumer looks in the cross-ref-
erence stream first, finds the object there, and ignores the free entry in the previ-
ous section. A PDF 1.4 consumer ignores the cross-reference stream and looks in
the previous section, where it finds the free entry. The free entry must have a
next-generation number of 65535 so that the object number is never reused.
There are limitations on which objects in a hybrid-reference file can be hidden
without making the file appear invalid to PDF 1.4 and earlier consumers. In par-
ticular, the root of the PDF file, the document catalog (see Section 3.6.1, “Docu-
ment Catalog”), must not be hidden, nor any object that is visible from the root.
KEY TYPE VALUE
XRefStm
integer (Optional) The byte offset from the beginning of the file of a cross-reference
stream.
File StructureSECTION 3.4
87
Such objects can be determined by starting from the root and working recursive-
ly:
• In any dictionary that is visible, direct objects are visible. The value of any re-
quired key-value pair is visible.
• In any array that is visible, every element is visible.
• Resource dictionaries in content streams are visible. Although a resource dic-
tionary is not required, strictly speaking, the content stream to which it is at-
tached is assumed to contain references to the resources.
In general, the objects that may be hidden are optional objects specified by indi-
rect references. A PDF 1.5 consumer can resolve those references by processing
the cross-reference streams. In a PDF 1.4 consumer, the objects appear to be free,
and the references are treated as references to the null object.
For example, the
Outlines entry in the catalog dictionary is optional. Therefore,
its value may be an indirect reference to a hidden object. A PDF 1.4 consumer
treats it as a reference to the null object, which is equivalent to having omitted the
entry entirely; a PDF 1.5 consumer recognizes it. However, if the value of the
Outlines entry is an indirect reference to a visible object, the entire outline tree
must be visible because nodes in the outline tree contain required pointers to oth-
er nodes.
Following this logic, items that must be visible include the entire page tree, fonts,
font descriptors, and width tables. Objects that may be hidden in a hybrid-refer-
ence file include the structure tree, the outline tree, article threads, annotations,
destinations, Web Capture information, and page labels,.
Example 3.11 shows a hybrid-reference file containing a main cross-reference
section and an update cross-reference section with an
XRefStm entry that points
to a cross-reference stream (object 11), which in turn has references to an object
stream (object 2).
In this example, the catalog (object 1) contains an indirect reference (
3 0 R) to the
root of the structure tree. The search for the object starts at the update cross-ref-
erence table, which has no objects in it. The search proceeds depending on the
version of the consumer application:
• In a PDF 1.4 consumer, the search continues by following the Prev pointer to
the main cross-reference table. That table defines object 3 as a free object,
SyntaxCHAPTER 3
88
which is treated as the null object. Therefore, the entry is considered missing,
and the document has no structure tree.
• In a PDF 1.5 consumer, the search continues by following the XRefStm pointer
to the cross-reference stream (object 11). It defines object 3 as a compressed
object, stored at index 0 in the object stream (
2 0 obj). Therefore, the document
has a structure tree.
Note: To make the format and contents of the cross-reference stream readable in this
example, an
ASCIIHexDecode filter is specified. As explained in implementation
note 20 in Appendix H, the example would not be acceptable to Acrobat 6.0 and lat-
er viewers as written.
Example 3.11
1 0 obj % The document root, at offset 23.
<< /Type /Catalog
/StructTreeRoot 3 0 R
…
>>
endobj
12 0 obj
…
endobj
…
99 0 obj
…
endobj
xref % The main xref section, at offset 2664
0 100 % This subsection has entries for objects 0 - 99.
0000000002 65535 f % Entry for object 0
0000000023 00000 n % Entry for object 1, the root
0000000003 65535 f % Entry for object 2 (object stream), marked free in this table
0000000004 65535 f % Entry for object 3, marked free in this table
0000000005 65535 f % …
0000000006 65535 f
0000000007 65535 f
0000000008 65535 f
0000000009 65535 f
0000000010 65535 f
0000000011 65535 f
File StructureSECTION 3.4
89
0000000000 65535 f % Entry for object 11 (xref stream), marked free in this table.
0000000045 00000 n % Entry for object 12, in use.
0000000179 00000 n % Entry for object 13, in use.
…
0000002201 00000 n % Entry for object 99, in use.
trailer
<< /Size 100
/Root 1 0 R
/ID …
>>
startxref
2264 % Offset of the main xref section
%%EOF
2 0 obj % The object stream, at offset 3722
<< /Length ...
/N 8 % This stream contains 8 objects.
/First 47 % The stream-offset of the first object
>>
stream
3 0 4 50 5 72 … % The numbers and stream-offsets of the 8 objects
<< /Type /StructTreeRoot % This is object 3.
/K 4 0 R
/RoleMap 5 0 R
/ClassMap 6 0 R
/ParentTree 7 0 R
/ParentTreeNextKey 8
>>
<< /S /Workbook % This is object 4 (K value from StructTreeRoot).
/P 8 0 R
/K 9 0 R
>>
<< /Workbook /Div % This is object 5 (RoleMap).
/Worksheet /Sect
/TextBox /Figure
/Shape /Figure
>>
… % Objects 6 through 10 are defined here.
endstream
endobj
SyntaxCHAPTER 3
90
11 0 obj % The cross-reference stream, at offset 4899
<< /Type /XRef
/Index [2 10] % This stream contains entries for objects 2 through 11
/Size 100
/W [1 2 1] % The byte-widths of each field
/Filter /ASCIIHexDecode % For readability only (not supported by Acrobat 6)
…
>>
stream
01 0E8A 0 % Entry for object 2 (0x0E8A = 3722)
02 0002 00 % Entry for object 3 (in object stream 2, index 0)
02 0002 01 % Entry for object 4 (in object stream 2, index 1)
02 0002 02 % …
02 0002 03
02 0002 04
02 0002 05
02 0002 06
02 0002 07 % Entry for object 10 (in object stream 2, index 7)
01 1323 0 % Entry for object 11 (0x1323 = 4899)
endstream
endobj
xref % The update xref section, at offset 5640
0 0 % There are no entries in this section.
trailer
<< /Size 100
/Prev 2664 % Offset of previous xref section
/XRefStm 4899
/Root 1 0 R
/ID …
>>
startxref
5640
%%EOF
The example illustrates several other points:
• The object stream is unencoded and the cross-reference stream uses an ASCII
hexadecimal encoding for clarity. In practice, both streams would be Flate-en-
coded. Also, the comments shown in the cross-reference table in the above ex-
EncryptionSECTION 3.5
91
ample are for illustrative purposes; PDF comments are not legal in a cross-
reference table.
• The hidden objects, 2 through 11, are numbered consecutively. In practice,
there is no such requirement, nor is there a requirement that free items in a
cross-reference table be linked in ascending order until the end.
• The update cross-reference table contains no entries, which is not a require-
ment but is reasonable. A PDF creator that uses the hybrid-reference format
creates the main cross-reference table, the update cross-reference table, and the
cross-reference stream at the same time. Objects 12 and 13, for example, are
not compressed. They might have entries in the update table. Since objects 2
and 11, the object stream and the cross-reference stream, are not compressed,
they might also be defined in the update table. Since they are part of the hidden
section, however, it makes sense to define them in the cross-reference stream.
• The update cross-reference section must appear at the end of the file, but other-
wise, there are no ordering restrictions on any of the objects or on the main
cross-reference section. However, a file that uses both the hybrid-reference for-
mat and the linearized format has ordering requirements (see Appendix F,
“Linearized PDF”).
3.5 Encryption
A PDF document can be encrypted (PDF 1.1) to protect its contents from un-
authorized access. Encryption applies to all strings and streams in the document’s
PDF file, but not to other object types such as integers and boolean values, which
are used primarily to convey information about the document’s structure rather
than its content. Leaving these values unencrypted allows random access to the
objects within a document, whereas encrypting the strings and streams protects
the document’s substantive contents.
Note: When a PDF stream object (see Section 3.2.7, “Stream Objects”) refers to an
external file, the stream’s contents are not encrypted, since they are not part of the
PDF file itself. However, if the contents of the stream are embedded within the PDF
file (see Section 3.10.3, “Embedded File Streams”), they are encrypted like any other
stream in the file. Beginning with PDF 1.5, embedded files may be encrypted in an
otherwise unencrypted document (see Section 3.5.4, “Crypt Filters”).
Encryption-related information is stored in a document’s encryption dictionary,
which is the value of the
Encrypt entry in the document’s trailer dictionary (see
SyntaxCHAPTER 3
92
Table 3.13 on page 73). The absence of this entry from the trailer dictionary
means that the document is not encrypted. The entries shown in Table 3.18 are
common to all encryption dictionaries.
The encryption dictionary’s
Filter entry identifies the file’s security handler, a soft-
ware module that implements various aspects of the encryption process and con-
trols access to the contents of the encrypted document. PDF specifies a standard
password-based security handler that all consumer applications are expected to
support, but applications may optionally provide security handlers of their own.
The
SubFilter entry specifies the syntax of the encryption dictionary contents. It
allows interoperability between handlers; that is, a document may be decrypted
by a handler other than the preferred one (the
Filter entry) if they both support
the format specified by
SubFilter.
The
V entry, in specifying which algorithm to use, determines the length of the
encryption key, on which the encryption (and decryption) of data in a PDF file is
based. For
V values 2 and 3, the Length entry specifies the exact length of the en-
cryption key. In PDF 1.5, a value of 4 for
V permits the security handler to use its
own encryption and decryption algorithms and to specify crypt filters to use on
specific streams (see Section 3.5.4, “Crypt Filters”).
The remaining contents of the encryption dictionary are determined by the secu-
rity handler and may vary from one handler to another. Entries for the standard
security handler are described in Section 3.5.2, “Standard Security Handler.” En-
tries for public-key security handlers are described in Section 3.5.3, “Public-Key
Security Handlers.”
TABLE 3.18 Entries common to all encryption dictionaries
KEY TYPE VALUE
Filter
name (Required) The name of the preferred security handler for this document. Typically, it is
the name of the security handler that was used to encrypt the document. If
SubFilter is
not present, only this security handler should be used when opening the document. If it
is present, consumer applications can use any security handler that implements the for-
mat specified by
SubFilter.
Standard is the name of the built-in password-based security handler. Names for other
security handlers can be registered by using the procedure described in Appendix E.
Note: The definition of this entry has been clarified since the previous version of this docu-
ment.
EncryptionSECTION 3.5
93
SubFilter
name (Optional; PDF 1.3) A name that completely specifies the format and interpretation of
the contents of the encryption dictionary. It is needed to allow security handlers other
than the one specified by
Filter to decrypt the document. If this entry is absent, other se-
curity handlers should not be allowed to decrypt the document.
Note: This entry was introduced in PDF 1.3 to support the use of public-key cryptography
in PDF files (see Section 3.5.3, “Public-Key Security Handlers”); however, it was not incor-
porated into the PDF Reference until the fourth edition (PDF 1.5).
V
number (Optional but strongly recommended) A code specifying the algorithm to be used in en-
crypting and decrypting the document:
0 An algorithm that is undocumented and no longer supported, and whose use is
strongly discouraged.
1 Algorithm 3.1 on page 95, with an encryption key length of 40 bits; see below.
2 (PDF 1.4) Algorithm 3.1, but permitting encryption key lengths greater than 40
bits.
3 (PDF 1.4) An unpublished algorithm that permits encryption key lengths rang-
ing from 40 to 128 bits; see implementation note 21 in Appendix H.
4 (PDF 1.5) The security handler defines the use of encryption and decryption in
the document, using the rules specified by the
CF, StmF, and StrF entries.
The default value if this entry is omitted is 0, but a value of 1 or greater is strongly rec-
ommended. (See implementation note 22 in Appendix H.)
Length
integer (Optional; PDF 1.4; only if V is 2 or 3) The length of the encryption key, in bits. The value
must be a multiple of 8, in the range 40 to 128. Default value: 40.
CF
dictionary (Optional; meaningful only when the value of V is 4; PDF 1.5) A dictionary whose keys
are crypt filter names and whose values are the corresponding crypt filter dictionaries
(see Table 3.22). Every crypt filter used in the document must have an entry in this dic-
tionary, except for the standard crypt filter names (see Table 3.23).
Note: An attempt to redefine any of the standard names in Table 3.23 is ignored.
StmF
name (Optional; meaningful only when the value of V is 4; PDF 1.5) The name of the crypt filter
that is used by default when decrypting streams. The name must be a key in the
CF dic-
tionary or a standard crypt filter name specified in Table 3.23. All streams in the docu-
ment, except for cross-reference streams (see Section 3.4.7, “Cross-Reference Streams”)
or streams that have a
Crypt entry in their Filter array (see Table 3.5), are decrypted by
the security handler, using this crypt filter.
Default value:
Identity.
KEY TYPE VALUE
SyntaxCHAPTER 3
94
Unlike strings within the body of the document, those in the encryption dictio-
nary must be direct objects. The contents of the encryption dictionary are not en-
crypted by the usual methods (the algorithm specified by the
V entry). Security
handlers are responsible for encrypting any data in the encryption dictionary that
they need to protect.
Note: Document creators have two choices if the encryption methods and syntax
provided by PDF are not sufficient for their needs: they can provide an alternate se-
curity handler or they can encrypt whole PDF documents themselves, not making
use of PDF security.
3.5.1 General Encryption Algorithm
The following algorithms are used when encrypting data in a PDF file:
• A proprietary encryption algorithm known as RC4. 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.
Note: RC4 is a copyrighted, proprietary algorithm of RSA Security, Inc. Adobe
Systems has licensed this algorithm for use in its Acrobat products. Independent
software vendors may be required to license RC4 to develop software that encrypts
or decrypts PDF documents. For further information, visit the RSA Web site at
<http://www.rsasecurity.com> or send e-mail to <products@rsasecurity.com>.
StrF
name (Optional; meaningful only when the value of V is 4; PDF 1.5) The name of the crypt filter
that is used when decrypting all strings in the document. The name must be a key in the
CF dictionary or a standard crypt filter name specified in Table 3.23.
Default value:
Identity.
EFF
name (Optional; meaningful only when the value of V is 4; PDF 1.6) The name of the crypt filter
that should be used by default when encrypting embedded file streams; it must corre-
spond to a key in the
CF dictionary or a standard crypt filter name specified in Table
3.23.
This entry is provided by the security handler. (See implementation note 23 in Appendix
H.) Applications should respect this value when encrypting embedded files, except for
embedded file streams that have their own crypt filter specifier. If this entry is not
present, and the embedded file stream does not contain a crypt filter specifier, the
stream should be encrypted using the default stream crypt filter specified by
StmF.
KEY TYPE VALUE
EncryptionSECTION 3.5
95
• The AES (Advanced Encryption Standard) algorithm (beginning with PDF
1.6). AES is a symmetric block cipher: the same algorithm is used for both en-
cryption and decryption, and the length of the data when encrypted is rounded
up to a multiple of the block size, which is fixed in this implementation to al-
ways be 16 bytes, as specified in FIPS 197, Advanced Encryption Standard
(AES); see the Bibliography).
PDF’s standard encryption methods also make use of the MD5 message-digest al-
gorithm for key generation purposes (described in Internet RFC 1321, The MD5
Message-Digest Algorithm; see the Bibliography).
The encryption of data in a PDF file is based on the use of an encryption key com-
puted by the security handler. Different security handlers compute the encryp-
tion key using their own mechanisms. Regardless of how the key is computed, its
use in the encryption of data is always the same (see Algorithm 3.1). Because the
RC4 algorithm and AES algorithms are symmetric, this same sequence of steps
can be used both to encrypt and to decrypt data.
Algorithm 3.1 Encryption of data using the RC4 or AES algorithms
1. Obtain the object number and generation number from the object identifier of the
string or stream to be encrypted (see Section 3.2.9, “Indirect Objects”). If the
string is a direct object, use the identifier of the indirect object containing it.
2. Treating the object number and generation number as binary integers, extend the
original n-byte encryption key to n + 5 bytes by appending the low-order 3 bytes
of the object number and the low-order 2 bytes of the generation number in that
order, low-order byte first. (n is 5 unless the value of
V in the encryption dictio-
nary is greater than 1, in which case n is the value of
Length divided by 8.)
3. Initialize the MD5 hash function and pass the result of step 2 as input to this func-
tion.
4. Use the first (n + 5) bytes, up to a maximum of 16, of the output from the MD5
hash as the key for the RC4 or AES symmetric key algorithms, along with the
string or stream data to be encrypted.
If using the AES algorithm, the Cipher Block Chaining (CBC) mode, which re-
quires an initialization vector, is used. The block size parameter is set to 16 bytes,
and the initialization vector is a 16-byte random number that is stored as the first
16 bytes of the encrypted stream or string.
The output is the encrypted data to be stored in the PDF file.
SyntaxCHAPTER 3
96
Stream data is encrypted after applying all stream encoding filters and is decrypt-
ed before applying any stream decoding filters. The number of bytes to be en-
crypted or decrypted is given by the
Length entry in the stream dictionary.
Decryption of strings (other than those in the encryption dictionary) is done
after escape-sequence processing and hexadecimal decoding as appropriate to the
string representation described in Section 3.2.3, “String Objects.”
3.5.2 Standard Security Handler
PDF’s standard security handler allows access permissions and up to two pass-
words to be specified for a document: an owner password and a user password. An
application’s decision to encrypt a document is based on whether the user creat-
ing the document specifies any passwords or access restrictions (for example, in a
security settings dialog box that the user can invoke before saving the PDF file). If
so, the document is encrypted, and the permissions and information required to
validate the passwords are stored in the encryption dictionary. (An application
may also create an encrypted document without any user interaction if it has
some other source of information about what passwords and permissions to use.)
If a user attempts to open an encrypted document that has a user password, the
application should prompt for a password. Correctly supplying either password
enables the user to open the document, decrypt it, and display it on the screen. If
the document does not have a user password, no password is requested; the appli-
cation can simply open, decrypt, and display the document. Whether additional
operations are allowed on a decrypted document depends on which password (if
any) was supplied when the document was opened and on any access restrictions
that were specified when the document was created:
• Opening the document with the correct owner password (assuming it is not the
same as the user password) allows full (owner) access to the document. This
unlimited access includes the ability to change the document’s passwords and
access permissions.
• Opening the document with the correct user password (or opening a docu-
ment that does not have a user password) allows additional operations to be
performed according to the user access permissions specified in the docu-
ment’s encryption dictionary.
Access permissions are specified in the form of flags corresponding to the various
operations, and the set of operations to which they correspond depends on the
EncryptionSECTION 3.5
97
security handler’s revision number (also stored in the encryption dictionary). If
the revision number is 2 or greater, the operations to which user access can be
controlled are as follows:
• Modifying the document’s contents
• Copying or otherwise extracting text and graphics from the document, includ-
ing extraction for accessibility purposes (that is, to make the contents of the
document accessible through assistive technologies such as screen readers or
Braille output devices; see Section 10.8, “Accessibility Support”)
• Adding or modifying text annotations (see “Text Annotations” on page 586)
and interactive form fields (Section 8.6, “Interactive Forms”)
• Printing the document
If the security handler’s revision number is 3 or greater, user access to the follow-
ing operations can be controlled more selectively:
• Filling in forms (that is, filling in existing interactive form fields) and signing
the document (which amounts to filling in existing signature fields, a type of
interactive form field).
• Assembling the document: inserting, rotating, or deleting pages and creating
navigation elements such as bookmarks or thumbnail images (see Section 8.2,
“Document-Level Navigation”).
• Printing to a representation from which a faithful digital copy of the PDF con-
tent could be generated. Disallowing such printing may result in degradation of
output quality (a feature implemented as “Print As Image” in Acrobat).
In addition, revisions 3 and greater enable the extraction of text and graphics (in
support of accessibility to users with disabilities or for other purposes) to be con-
trolled separately.
If revision 4 is specified, the standard security handler supports crypt filters (see
Section 3.5.4, “Crypt Filters”). The support is limited to the
Identity crypt filter
(see Table 3.23) and crypt filters named
StdCF whose dictionaries contain a CFM
value of V2 or AESV2 and an AuthEvent value of DocOpen.
Note: Once the document has been opened and decrypted successfully, the applica-
tion has access to the entire contents of the document. There is nothing inherent in
PDF encryption that enforces the document permissions specified in the encryption
SyntaxCHAPTER 3
98
dictionary. It is up to the implementors of PDF consumer applications to respect the
intent of the document creator by restricting user access to an encrypted PDF file ac-
cording to the permissions contained in the file.
Note: PDF 1.5 introduces a set of access permissions that do not require the docu-
ment to be encrypted; see Section 8.7.3, “Permissions.”
Standard Encryption Dictionary
Table 3.19 shows the encryption dictionary entries for the standard security
handler (in addition to those in Table 3.18).
TABLE 3.19 Additional encryption dictionary entries for the standard security handler
KEY TYPE VALUE
R
number (Required) A number specifying which revision of the standard security handler
should be used to interpret this dictionary:
• 2 if the document is encrypted with a V value less than 2 (see Table 3.18) and
does not have any of the access permissions set (by means of the
P entry, below)
that are designated “Revision 3 or greater” in Table 3.20
• 3 if the document is encrypted with a V value of 2 or 3, or has any “Revision 3 or
greater” access permissions set
• 4 if the document is encrypted with a V value of 4
O
string (Required) A 32-byte string, based on both the owner and user passwords, that is
used in computing the encryption key and in determining whether a valid owner
password was entered. For more information, see “Encryption Key Algorithm” on
page 100 and “Password Algorithms” on page 101.
U
string (Required) A 32-byte string, based on the user password, that is used in determin-
ing whether to prompt the user for a password and, if so, whether a valid user or
owner password was entered. For more information, see “Password Algorithms”
on page 101.
P
integer (Required) A set of flags specifying which operations are permitted when the doc-
ument is opened with user access (see Table 3.20).
EncryptMetadata
boolean (Optional; meaningful only when the value of V is 4; PDF 1.5) Indicates whether
the document-level metadata stream (see Section 10.2.2, “Metadata Streams”) is
to be encrypted. Applications should respect this value.
Default value:
true.
EncryptionSECTION 3.5
99
The values of the O and U entries in this dictionary are used to determine wheth-
er a password entered when the document is opened is the correct owner pass-
word, user password, or neither.
The value of the
P entry is an unsigned 32-bit integer containing a set of flags
specifying which access permissions should be granted when the document is
opened with user access. Table 3.20 shows the meanings of these flags. Bit posi-
tions within the flag word are numbered from 1 (low-order) to 32 (high-order). A
1 bit in any position enables the corresponding access permission. Which bits are
meaningful, and in some cases how they are interpreted, depends on the security
handler’s revision number (specified in the encryption dictionary’s
R entry).
Note: PDF integer objects are represented internally in signed twos-complement
form. Since all the reserved high-order flag bits in the encryption dictionary’s
P val-
ue are required to be 1, the value must be specified as a negative integer. For exam-
ple, assuming revision 2 of the security handler, the value -44 permits printing and
copying but disallows modifying the contents and annotations.
TABLE 3.20 User access permissions
BIT POSITION MEANING
1–2 Reserved; must be 0.
3 (Revision 2) Print the document.
(Revision 3 or greater) Print the document (possibly not at the high-
est quality level, depending on whether bit 12 is also set).
4 Modify the contents of the document by operations other than
those controlled by bits 6, 9, and 11.
5 (Revision 2) Copy or otherwise extract text and graphics from the
document, including extracting text and graphics (in support of ac-
cessibility to users with disabilities or for other purposes).
(Revision 3 or greater) Copy or otherwise extract text and graphics
from the document by operations other than that controlled by bit
10.
6 Add or modify text annotations, fill in interactive form fields, and,
if bit 4 is also set, create or modify interactive form fields (including
signature fields).
7–8 Reserved; must be 1.
SyntaxCHAPTER 3
100
Encryption Key Algorithm
As noted earlier, one function of a security handler is to generate an encryption
key for use in encrypting and decrypting the contents of a document. Given a
password string, the standard security handler computes an encryption key as
shown in Algorithm 3.2.
Algorithm 3.2 Computing an encryption key
1. Pad or truncate the password string to exactly 32 bytes. If the password string is
more than 32 bytes long, use only its first 32 bytes; if it is less than 32 bytes long,
pad it by appending the required number of additional bytes from the beginning
of the following padding string:
<28BF4E5E4E758A4164004E56FFFA0108
2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A >
That is, if the password string is n bytes long, append the first 32 n bytes of the
padding string to the end of the password string. If the password string is empty
(zero-length), meaning there is no user password, substitute the entire padding
string in its place.
2. Initialize the MD5 hash function and pass the result of step 1 as input to this func-
tion.
9 (Revision 3 or greater) Fill in existing interactive form fields (includ-
ing signature fields), even if bit 6 is clear.
10 (Revision 3 or greater) Extract text and graphics (in support of ac-
cessibility to users with disabilities or for other purposes).
11 (Revision 3 or greater) Assemble the document (insert, rotate, or de-
lete pages and create bookmarks or thumbnail images), even if bit 4
is clear.
12 (Revision 3 or greater) Print the document to a representation from
which a faithful digital copy of the PDF content could be generated.
When this bit is clear (and bit 3 is set), printing is limited to a low-
level representation of the appearance, possibly of degraded quality.
(See implementation note 24 in Appendix H.)
13–32 (Revision 3 or greater) Reserved; must be 1.
BIT POSITION MEANING
EncryptionSECTION 3.5
101
3. Pass the value of the encryption dictionary’s O entry to the MD5 hash function.
(Algorithm 3.3 shows how the
O value is computed.)
4. Treat the value of the
P entry as an unsigned 4-byte integer and pass these bytes to
the MD5 hash function, low-order byte first.
5. Pass the first element of the file’s file identifier array (the value of the
ID entry in
the document’s trailer dictionary; see Table 3.13 on page 73) to the MD5 hash
function. (See implementation note 25 in Appendix H.)
6. (Revision 3 or greater) If document metadata is not being encrypted, pass 4 bytes
with the value 0xFFFFFFFF to the MD5 hash function.
7. Finish the hash.
8. (Revision 3 or greater) Do the following 50 times: Take the output from the previ-
ous MD5 hash and pass the first n bytes of the output as input into a new MD5
hash, where n is the number of bytes of the encryption key as defined by the value
of the encryption dictionary’s
Length entry.
9. Set the encryption key to the first n bytes of the output from the final MD5 hash,
where n is always 5 for revision 2 but, for revision 3 or greater, depends on the val-
ue of the encryption dictionary’s
Length entry.
This algorithm, when applied to the user password string, produces the encryp-
tion key used to encrypt or decrypt string and stream data according to Algo-
rithm 3.1 on page 95. Parts of this algorithm are also used in the algorithms
described below.
Password Algorithms
In addition to the encryption key, the standard security handler must provide the
contents of the encryption dictionary (Table 3.18 on page 92 and Table 3.19 on
page 98). The values of the
Filter, V, Length, R, and P entries are straightforward,
but the computation of the
O (owner password) and U (user password) entries re-
quires further explanation. Algorithms 3.3 through 3.5 show how the values of
the owner password and user password entries are computed (with separate ver-
sions of the latter depending on the revision of the security handler).
Algorithm 3.3 Computing the encryption dictionary’s O (owner password) value
1. Pad or truncate the owner password string as described in step 1 of Algorithm 3.2.
If there is no owner password, use the user password instead. (See implementation
note 26 in Appendix H.)
SyntaxCHAPTER 3
102
2. Initialize the MD5 hash function and pass the result of step 1 as input to this func-
tion.
3. (Revision 3 or greater) Do the following 50 times: Take the output from the previ-
ous MD5 hash and pass it as input into a new MD5 hash.
4. Create an RC4 encryption key using the first n bytes of the output from the final
MD5 hash, where n is always 5 for revision 2 but, for revision 3 or greater, depends
on the value of the encryption dictionary’s
Length entry.
5. Pad or truncate the user password string as described in step 1 of Algorithm 3.2.
6. Encrypt the result of step 5, using an RC4 encryption function with the encryp-
tion key obtained in step 4.
7. (Revision 3 or greater) Do the following 19 times: Take the output from the previ-
ous invocation of the RC4 function and pass it as input to a new invocation of the
function; use an encryption key generated by taking each byte of the encryption
key obtained in step 4 and performing an XOR (exclusive or) operation between
that byte and the single-byte value of the iteration counter (from 1 to 19).
8. Store the output from the final invocation of the RC4 function as the value of the
O entry in the encryption dictionary.
Algorithm 3.4 Computing the encryption dictionary’s U (user password) value (Revision 2)
1. Create an encryption key based on the user password string, as described in Algo-
rithm 3.2.
2. Encrypt the 32-byte padding string shown in step 1 of Algorithm 3.2, using an
RC4 encryption function with the encryption key from the preceding step.
3. Store the result of step 2 as the value of the
U entry in the encryption dictionary.
Algorithm 3.5 Computing the encryption dictionary’s U (user password) value (Revision 3
or greater)
1. Create an encryption key based on the user password string, as described in Algo-
rithm 3.2.
2. Initialize the MD5 hash function and pass the 32-byte padding string shown in
step 1 of Algorithm 3.2 as input to this function.
3. Pass the first element of the file’s file identifier array (the value of the
ID entry in
the document’s trailer dictionary; see Table 3.13 on page 73) to the hash function
and finish the hash. (See implementation note 25 in Appendix H.)
4. Encrypt the 16-byte result of the hash, using an RC4 encryption function with the
encryption key from step 1.
EncryptionSECTION 3.5
103
5. Do the following 19 times: Take the output from the previous invocation of the
RC4 function and pass it as input to a new invocation of the function; use an en-
cryption key generated by taking each byte of the original encryption key (ob-
tained in step 1) and performing an XOR (exclusive or) operation between that
byte and the single-byte value of the iteration counter (from 1 to 19).
6. Append 16 bytes of arbitrary padding to the output from the final invocation of
the RC4 function and store the 32-byte result as the value of the
U entry in the en-
cryption dictionary.
The standard security handler uses Algorithms 3.6 and 3.7 to determine whether
a supplied password string is the correct user or owner password. Note too that
Algorithm 3.6 can be used to determine whether a document’s user password is
the empty string, and therefore whether to suppress prompting for a password
when the document is opened.
Algorithm 3.6 Authenticating the user password
1. Perform all but the last step of Algorithm 3.4 (Revision 2) or Algorithm 3.5 (Revi-
sion 3 or greater) using the supplied password string.
2. If the result of step 1 is equal to the value of the encryption dictionary’s
U entry
(comparing on the first 16 bytes in the case of Revision 3 or greater), the password
supplied is the correct user password. The key obtained in step 1 (that is, in the
first step of Algorithm 3.4 or 3.5) can be used to decrypt the document using Al-
gorithm 3.1 on page 95.
Algorithm 3.7 Authenticating the owner password
1. Compute an encryption key from the supplied password string, as described in
steps 1 to 4 of Algorithm 3.3.
2. (Revision 2 only) Decrypt the value of the encryption dictionary’s
O entry, using an
RC4 encryption function with the encryption key computed in step 1.
(Revision 3 or greater) Do the following 20 times: Decrypt the value of the encryp-
tion dictionary’s
O entry (first iteration) or the output from the previous iteration
(all subsequent iterations), using an RC4 encryption function with a different en-
cryption key at each iteration. The key is generated by taking the original key (ob-
tained in step 1) and performing an XOR (exclusive or) operation between each
byte of the key and the single-byte value of the iteration counter (from 19 to 0).
3. The result of step 2 purports to be the user password. Authenticate this user pass-
word using Algorithm 3.6. If it is correct, the password supplied is the correct
owner password.
SyntaxCHAPTER 3
104
3.5.3 Public-Key Security Handlers
Security handlers may use public-key encryption technology to encrypt a docu-
ment (or strings and streams within a document). When doing so, it is possible to
specify one or more lists of recipients, where each list has its own unique access
permissions. Only specified recipients can open the encrypted document or con-
tent, unlike the standard security handler, where a password determines access.
The permissions defined for public-key security handlers are identical to those
defined for the standard security handler (see Section 3.5.2, “Standard Security
Handler”).
Public-key security handlers use the industry standard Public Key Cryptographic
Standard Number 7 (PKCS#7) binary encoding syntax to encode recipient list,
decryption key, and access permission information. The PKCS#7 specification is
in Internet RFC 2315, PKCS #7: Cryptographic Message Syntax, Version 1.5 (see
the Bibliography).
When encrypting the data, each recipient’s X.509 public key certificate (as de-
scribed in ITU-T Recommendation X.509; see the Bibliography) must be avail-
able. When decrypting the data, the application scans the recipient list for which
the content is encrypted and attempts to find a match with a certificate that be-
longs to the user. If a match is found, the user requires access to the correspond-
ing private key, which may require authentication, possibly using a password.
Once access is obtained, the private key is used to decrypt the encrypted data.
Public-Key Encryption Dictionary
Encryption dictionaries for public-key security handlers contain the common en-
tries shown in Table 3.18, whose values are described below. In addition, they
may contain the entry shown in Table 3.21.
The
Filter entry is the name of a public-key security handler. Examples of existing
security handlers that support public-key encryption are
Entrust.PPKEF,
Adobe.PPKLite, and Adobe.PubSec. This handler will be the preferred handler
when encrypting the document.
Permitted values of the
SubFilter entry for use with conforming public-key secu-
rity handlers are
adbe.pkcs7.s3, adbe.pkcs7.s4, which are used when not using
crypt filters (see Section 3.5.4, “Crypt Filters”) and
adbe.pkcs7.s5, which is used
when using crypt filters.
EncryptionSECTION 3.5
105
The CF, StmF, and StrF entries may be present when SubFilter is adbe.pkcs7.s5.
TABLE 3.21 Additional encryption dictionary entries for public-key security handlers
Public-Key Encryption Algorithms
Figure 3.4 illustrates how PKCS#7 objects are used when encrypting PDF files. A
PKCS#7 object is designed to encapsulate and encrypt what is referred to as the
enveloped data.
FIGURE 3.4 Public-key encryption algorithm
KEY TYPE VALUE
Recipients
array (Required when SubFilter is adbe.pkcs7.s3 or adbe.pkcs7.s4; PDF 1.3) An array of
strings, where each string is a PKCS#7 object listing recipients who have been
granted equal access rights to the document. The data contained in the PKCS#7 ob-
ject includes both a cryptographic key that is used to decrypt the encrypted data
and the access permissions (see Table 3.20) that apply to the recipient list. There
should be only one PKCS#7 object per unique set of access permissions; if a recipi-
ent appears in more than one list, the permissions used are those in the first match-
ing list.
Note: When
SubFilter is adbe.pkcs7.s5, recipient lists are specified in the crypt filter
dictionary; see Table 3.24.
20-byte seed
Permissions*
PKCS#7 Object
Enveloped data
Encrypted key
John Doe
Decrypt
John Doe’s private key
Plaintext key
Decrypt
Plaintext byte array
Used to generate
encryption key as
described on page
106
Encrypted key
Jeff Smith
* Permissions not present
when PKCS#7 object is ref-
erenced from Crypt filter
decode parameter dictio-
nary
SyntaxCHAPTER 3
106
The enveloped data in the PKCS#7 object contains keying material that must be
used to decrypt the document (or individual strings or streams in the document,
when crypt filters are used; see Section 3.5.4, “Crypt Filters”). A key is used to en-
crypt (and decrypt) the enveloped data. This key (the plaintext key in Figure 3.4)
is encrypted for each recipient, using that recipient’s public key, and is stored in
the PKCS#7 object (as the encrypted key for each recipient). To decrypt the docu-
ment, that key is decrypted using the recipient’s private key, which yields a de-
crypted (plaintext) key. That key, in turn, is used to decrypt the enveloped data in
the PKCS#7 object, resulting in a byte array that includes the following informa-
tion:
• A 20-byte seed that is used to create the encryption key that is used by Algo-
rithm 3.1. The seed should be a unique random number generated by the secu-
rity handler that encrypted the document.
• A 4-byte value defining the permissions, least significant byte first. See Table
3.20 for the possible permission values.
• When SubFilter is adbe.pkcs7.s3, the relevant permissions are restricted to
those specified for revision 2 of the standard security handler.
• For adbe.pkcs7.s4, revision 3 permissions apply.
• For adbe.pkcs7.s5, which supports the use of crypt filters, the permissions
are the same as
adbe.pkcs7.s4 when the crypt filter is referenced from the
StmF or StrF entries of the encryption dictionary. When referenced from the
Crypt filter decode parameter dictionary of a stream object (see Table 3.12),
the 4 bytes of permissions are absent from the enveloped data.
The encryption key that is used by Algorithm 3.1 is calculated by means of an
SHA-1 message digest operation that digests the following data, in order:
1. The 20 bytes of seed
2. The bytes of each item in the
Recipients array of PKCS#7 objects in the order
in which they appear in the array
3. 4 bytes with the value 0xFF if the key being generated is intended for use in
document-level encryption and the document metadata is being left as plain-
text
The first n/8 bytes of the resulting digest is used as the encryption key, where n is
the bit length of the RC4 key.
EncryptionSECTION 3.5
107
3.5.4 Crypt Filters
PDF 1.5 introduces crypt filters, which provide finer granularity control of en-
cryption within a PDF file. The use of crypt filters involves the following struc-
tures:
• The encryption dictionary (see Table 3.18) contains entries that enumerate the
crypt filters in the document (
CF) and specify which ones are used by default to
decrypt all the streams (
StmF) and strings (StrF) in the document. In addition,
the value of the
V entry must be 4 to use crypt filters.
• Each crypt filter specified in the CF entry of the encryption dictionary is repre-
sented by a crypt filter dictionary, whose entries are shown in Table 3.22.
• A stream filter type, the Crypt filter (see Section 3.3.9, “Crypt Filter”) can be
specified for any stream in the document to override the default filter for
streams. A standard
Identity filter is provided (see Table 3.23) to allow specific
streams, such as document metadata, to be unencrypted in an otherwise en-
crypted document. The stream’s
DecodeParms entry must contain a Crypt filter
decode parameters dictionary (see Table 3.12) whose
Name entry specifies the
particular crypt filter to be used (if missing,
Identity is used). Different streams
may specify different crypt filters; however, see implementation notes 27 and
28 in Appendix H.
Authorization to decrypt a stream must always be obtained before the stream can
be accessed. This typically occurs when the document is opened, as specified by a
value of
DocOpen for the AuthEvent entry in the crypt filter dictionary. PDF con-
sumer applications and security handlers should treat any attempt to access a
stream for which authorization has failed as an error.
AuthEvent may also be
EFOpen, which indicates the presence of an embedded file that is encrypted with
a crypt filter that may be different from the crypt filters used by default to encrypt
strings and streams in the document; see implementation note 30 in Appendix H.
By specifying a value of
None for the CFM entry in the crypt filter dictionary, the
security handler can do its own decryption. This allows the handler to tightly
control key management and use any preferred symmetric-key cryptographic al-
gorithm.
SyntaxCHAPTER 3
108
TABLE 3.22 Entries common to all crypt filter dictionaries
KEY TYPE VALUE
Type
name (Optional) If present, must be CryptFilter for a crypt filter dictionary.
CFM
name (Optional) The method used, if any, by the consumer application to decrypt
data. The following values are supported:
None The application does not decrypt data but directs the input stream
to the security handler for decryption. (See implementation note
29 in Appendix H.)
V2 The application asks the security handler for the encryption key
and implicitly decrypts data with Algorithm 3.1, using the RC4 al-
gorithm.
AESV2 (PDF 1.6) The application asks the security handler for the en-
cryption key and implicitly decrypts data with Algorithm 3.1, us-
ing the AES algorithm in Cipher Block Chaining (CBC) mode
with a 16-byte block size and an initialization vector that is ran-
domly generated and placed as the first 16 bytes in the stream or
string.
When the value is
V2 or AESV2, the application may ask once for this encryp-
tion key and cache the key for subsequent use for streams that use the same
crypt filter. Therefore, there must be a one-to-one relationship between a
crypt filter name and the corresponding encryption key.
Only the values listed here are supported. Applications that encounter other
values should report that the file is encrypted with an unsupported algo-
rithm.
Default value:
None.
AuthEvent
name (Optional) The event to be used to trigger the authorization that is required
to access encryption keys used by this filter. If authorization fails, the event
should fail. Valid values are:
• DocOpen: Authorization is required when a document is opened.
• EFOpen: Authorization is required when accessing embedded files.
Default value:
DocOpen.
If this filter is used as the value of
StrF or StmF in the encryption dictionary
(see Table 3.18), the application should ignore this key and behave as if the
value is
DocOpen.
EncryptionSECTION 3.5
109
Security handlers can add their own private data to crypt filter dictionaries.
Names for private data entries must conform to the PDF name registry (see Ap-
pendix E, “PDF Name Registry”).
TABLE 3.23 Standard crypt filter names
Table 3.24 lists the additional crypt filter dictionary entries used by public-key se-
curity handlers (see Section 3.5.3, “Public-Key Security Handlers”). When these
entries are present, the value of
CFM must be V2 or AESV2.
TABLE 3.24 Additional crypt filter dictionary entries for public-key security handlers
Length
integer (Optional) The bit length of the encryption key. It must be a multiple of 8 in
the range of 40 to 128.
Note: Security handlers can define their own use of the
Length entry but are en-
couraged to use it to define the bit length of the encryption key.
NAME DESCRIPTION
Identity
Input data is passed through without any processing.
KEY TYPE VALUE
Recipients
array or
string
(Required) If the crypt filter is referenced from StmF or StrF in the encryption
dictionary, this entry is an array of strings, where each string is a binary-en-
coded PKCS#7 object listing recipients that have been granted equal access
rights to the document. The enveloped data contained in the PKCS#7 object
includes both a 20-byte seed value used to compute the encryption key (see
“Public-Key Encryption Algorithms” on page 105) followed by 4 bytes of per-
missions settings (see Table 3.20) that apply to the recipient list. There should
be only one object per unique set of access permissions. If a recipient appears
in more than one list, the permissions used are those in the first matching list.
If the crypt filter is referenced from a
Crypt filter decode parameter dictio-
nary (see Table 3.12), this entry is a string that is a binary-encoded PKCS#7
object containing a list of all recipients who are permitted to access the corre-
sponding encrypted stream. The enveloped data contained in the PKCS#7
object is a 20-byte seed value used to create the encryption key that is used by
Algorithm 3.1.
KEY TYPE VALUE
SyntaxCHAPTER 3
110
Example 3.12 shows the use of crypt filters in an encrypted document containing
a plaintext document-level metadata stream. The metadata stream is left as is by
applying the
Identity crypt filter. The remaining streams and strings are decrypt-
ed using the default filters.
Example 3.12
%PDF1.5
1 0 obj % Document catalog
<< /Type /Catalog
/Pages 2 0 R
/Metadata 6 0 R
>>
endobj
2 0 obj % Page tree
<< /Type /Pages
/Kids [3 0 R]
/Count 1
>>
endobj
3 0 obj % 1s t page
<< /Type /Page
/Parent 2 0 R
/MediaBox [0 0 612 792]
/Contents 4 0 R
>>
endobj
4 0 obj % Page contents
<< /Length 35 >>
stream
*** Encrypted Page-marking operators ***
endstream
endobj
EncryptMetadata
boolean (Optional; used only by crypt filters that are referenced from StmF in an encryp-
tion dictionary) Indicates whether the document-level metadata stream (see
Section 10.2.2, “Metadata Streams”) is to be encrypted. PDF consumer app-
plications should respect this value when determining whether metadata
should be encrypted; see implementation note 31 in Appendix H.
Default value:
true.
KEY TYPE VALUE
EncryptionSECTION 3.5
111
5 0 obj
<< /Title ($#*#%*$#^&##) >> % Info dictionary: encrypted text string
endobj
6 0 obj
<< /Type /Metadata
/Subtype /XML
/Length 15
/Filter [/Crypt] % Uses a crypt filter
/DecodeParms % with these parameters
<< /Type /CryptFilterDecodeParms
/Name /Identity % Indicates no encryption
>>
>>
stream
XML metadata % Unencrypted metadata
endstream
endobj
8 0 obj % Encryption dictionary
<< /Filter /MySecurityHandlerName
/V 4 % Version 4: allow crypt filters
/CF % List of crypt filters
<< /MyFilter0
<< /Type /CryptFilter
/CFM V2 >> % Uses the standard algorithm
>>
/StrF /MyFilter0 % Strings are decrypted using /MyFilter0
/StmF /MyFilter0 % Streams are decrypted using /MyFilter0
... % Private data for /MySecurityHandlerName
/MyUnsecureKey (12345678)
/EncryptMetadata false
>>
endobj
xref
....
trailer
<< /Size 8
/Root 1 0 R
/Info 5 0 R
/Encrypt 8 0 R
>>
startxref
495
%%EOF
SyntaxCHAPTER 3
112
3.6 Document Structure
A PDF document can be regarded as a hierarchy of objects contained in the
body section of a PDF file. At the root of the hierarchy is the document’s catalog
dictionary (see Section 3.6.1, “Document Catalog”). Most of the objects in the
hierarchy are dictionaries. For example, each page of the document is represent-
ed by a page object—a dictionary that includes references to the page’s contents
and other attributes, such as its thumbnail image (Section 8.2.3, “Thumbnail
Images”) and any annotations (Section 8.4, “Annotations”) associated with it.
The individual page objects are tied together in a structure called the page tree
(described in Section 3.6.2, “Page Tree”), which in turn is specified by an indirect
reference in the document catalog. Parent, child, and sibling relationships within
the hierarchy are defined by dictionary entries whose values are indirect refer-
ences to other dictionaries. Figure 3.5 illustrates the structure of the object hier-
archy.
Note: The data structures described in this section, particularly the catalog and page
dictionaries, combine entries describing document structure with ones dealing with
the detailed semantics of documents and pages. All entries are listed here, but many
of their descriptions are deferred to subsequent chapters.
3.6.1 Document Catalog
The root of a document’s object hierarchy is the catalog dictionary, located by
means of the
Root entry in the trailer of the PDF file (see Section 3.4.4, “File Trail-
er”). The catalog contains references to other objects defining the document’s
contents, outline, article threads (PDF 1.1), named destinations, and other at-
tributes. In addition, it contains information about how the document should be
displayed on the screen, such as whether its outline and thumbnail page images
should be displayed automatically and whether some location other than the first
page should be shown when the document is opened. Table 3.25 shows the en-
tries in the catalog dictionary.
Document StructureSECTION 3.6
113
FIGURE 3.5 Structure of a PDF document
Outline
entry
Page
Thumbnail
image
Annotations
Bead
Bead
Thread
Outline
entry
Content
stream
Thread
Named
destinations
Article
threads
Interactive
form
Outline
hierarchy
Document catalog
Page
•
•
•
•
•
•
•
•
•
•
•
•
Page
tree
• • •
• • •
• • •
• • •
SyntaxCHAPTER 3
114
TABLE 3.25 Entries in the catalog dictionary
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be
Catalog for the catalog dictionary.
Version
name (Optional; PDF 1.4) The version of the PDF specification to which the
document conforms (for example,
1.4) if later than the version specified
in the file’s header (see Section 3.4.1, “File Header”). If the header speci-
fies a later version, or if this entry is absent, the document conforms to
the version specified in the header. This entry enables a PDF producer
application to update the version using an incremental update; see Sec-
tion 3.4.5, “Incremental Updates.” (See implementation note 32 in Ap-
pendix H.)
Note: The value of this entry is a name object, not a number, and therefore
must be preceded by a slash character (
/) when written in the PDF file (for
example,
/1.4).
Pages
dictionary (Required; must be an indirect reference) The page tree node that is the
root of the document’s page tree (see Section 3.6.2, “Page Tree”).
PageLabels
number tree (Optional; PDF 1.3) A number tree (see Section 3.8.6, “Number Trees”)
defining the page labeling for the document. The keys in this tree are
page indices; the corresponding values are page label dictionaries (see
Section 8.3.1, “Page Labels”). Each page index denotes the first page in a
labeling range to which the specified page label dictionary applies. The
tree must include a value for page index 0.
Names
dictionary (Optional; PDF 1.2) The document’s name dictionary (see Section 3.6.3,
“Name Dictionary”).
Dests
dictionary (Optional; PDF 1.1; must be an indirect reference) A dictionary of names
and corresponding destinations (see “Named Destinations” on page
553).
ViewerPreferences
dictionary (Optional; PDF 1.2) A viewer preferences dictionary (see Section 8.1,
“Viewer Preferences”) specifying the way the document is to be dis-
played on the screen. If this entry is absent, applications should use their
own current user preference settings.
Document StructureSECTION 3.6
115
PageLayout
name (Optional) A name object specifying the page layout to be used when the
document is opened:
SinglePage Display 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
TwoPageLeft (PDF 1.5) Display the pages two at a time, with
odd-numbered pages on the left
TwoPageRight (PDF 1.5) Display the pages two at a time, with
odd-numbered pages on the right
(See implementation note 33 in Appendix H.) Default value:
SinglePage.
PageMode
name (Optional) A name object specifying how the document should be dis-
played when opened:
UseNone Neither document outline nor thumbnail im-
ages visible
UseOutlines Document outline visible
UseThumbs Thumbnail images visible
FullScreen Full-screen mode, with no menu bar, window
controls, or any other window visible
UseOC (PDF 1.5) Optional content group panel visible
UseAttachments (PDF 1.6) Attachments panel visible
Default value:
UseNone.
Outlines
dictionary (Optional; must be an indirect reference) The outline dictionary that is the
root of the document’s outline hierarchy (see Section 8.2.2, “Document
Outline”).
Threads
array (Optional; PDF 1.1; must be an indirect reference) An array of thread
dictionaries representing the document’s article threads (see Section
8.3.2, “Articles”).
OpenAction
array or
dictionary
(Optional; PDF 1.1) A value specifying a destination to be displayed or an
action to be performed when the document is opened. The value is ei-
ther an array defining a destination (see Section 8.2.1, “Destinations”) or
an action dictionary representing an action (Section 8.5, “Actions”). If
this entry is absent, the document should be opened to the top of the
first page at the default magnification factor.
KEY TYPE VALUE
SyntaxCHAPTER 3
116
AA dictionary (Optional; PDF 1.4) An additional-actions dictionary defining the actions
to be taken in response to various trigger events affecting the document
as a whole (see “Trigger Events” on page 610). (See also implementation
note 34 in Appendix H.)
URI
dictionary (Optional; PDF 1.1) A URI dictionary containing document-level infor-
mation for URI (uniform resource identifier) actions (see “URI Actions”
on page 624).
AcroForm
dictionary (Optional; PDF 1.2) The document’s interactive form (AcroForm) dictio-
nary (see Section 8.6.1, “Interactive Form Dictionary”).
Metadata
stream (Optional; PDF 1.4; must be an indirect reference) A metadata stream
containing metadata for the document (see Section 10.2.2, “Metadata
Streams”).
StructTreeRoot
dictionary (Optional; PDF 1.3) The document’s structure tree root dictionary (see
Section 10.6.1, “Structure Hierarchy”).
MarkInfo
dictionary (Optional; PDF 1.4) A mark information dictionary containing informa-
tion about the document’s usage of Tagged PDF conventions (see Sec-
tion 10.6, “Logical Structure”).
Lang
text string (Optional; PDF 1.4) A language identifier specifying the natural language
for all text in the document except where overridden by language speci-
fications for structure elements or marked content (see Section 10.8.1,
“Natural Language Specification”). If this entry is absent, the language is
considered unknown.
SpiderInfo
dictionary (Optional; PDF 1.3) A Web Capture information dictionary containing
state information used by the Acrobat Web Capture (AcroSpider) plug-
in extension (see Section 10.9.1, “Web Capture Information Dictio-
nary”).
OutputIntents
array (Optional; PDF 1.4) An array of output intent dictionaries describing the
color characteristics of output devices on which the document might be
rendered (see “Output Intents” on page 898).
PieceInfo
dictionary (Optional; PDF 1.4) A page-piece dictionary associated with the docu-
ment (see Section 10.4, “Page-Piece Dictionaries”).
OCProperties
dictionary (Optional; PDF 1.5; required if a document contains optional content) The
document’s optional content properties dictionary (see Section 4.10.3,
“Configuring Optional Content”).
KEY TYPE VALUE
Document StructureSECTION 3.6
117
Example 3.13 shows a sample catalog object.
Example 3.13
1 0 obj
<< /Type /Catalog
/Pages 2 0 R
/PageMode /UseOutlines
/Outlines 3 0 R
>>
endobj
3.6.2 Page Tree
The pages of a document are accessed through a structure known as the page tree,
which defines the ordering of pages in the document. The tree structure allows
PDF consumer applications, using only limited memory, to quickly open a docu-
ment containing thousands of pages. The tree contains nodes of two types—in-
termediate nodes, called page tree nodes, and leaf nodes, called page objects—
whose form is described in the sections below. Applications should be prepared
to handle any form of tree structure built of such nodes. The simplest structure
would consist of a single page tree node that references all of the document’s page
objects directly. However, to optimize application performance, the Acrobat Dis-
tiller program constructs trees of a particular form, known as balanced trees. Fur-
ther information on this form of tree can be found in Data Structures and
Algorithms, by Aho, Hopcroft, and Ullman (see the Bibliography).
Page Tree Nodes
Table 3.26 shows the required entries in a page tree node.
Perms
dictionary (Optional; PDF 1.5) A permissions dictionary that specifies user access
permissions for the document. Section 8.7.3, “Permissions,” describes
this dictionary and how it is used.
Legal
dictionary (Optional; PDF 1.5) A dictionary containing attestations regarding the
content of a PDF document, as it relates to the legality of digital signa-
tures (see Section 8.7.4, “Legal Content Attestations”).
KEY TYPE VALUE
SyntaxCHAPTER 3
118
TABLE 3.26 Required entries in a page tree node
Note: The structure of the page tree is not necessarily related to the logical structure
of the document; that is, page tree nodes do not represent chapters, sections, and so
forth. (Other data structures are defined for that purpose; see Section 10.6, “Logical
Structure.”) Applications that consume or produce PDF files are not required to pre-
serve the existing structure of the page tree.
Example 3.14 illustrates the page tree for a document with three pages. See “Page
Objects,” below, for the contents of the individual page objects, and Section G.4,
“Page Tree Example,” for a more extended example showing the page tree for a
longer document.
Example 3.14
2 0 obj
<< /Type /Pages
/Kids [ 4 0 R
10 0 R
24 0 R
]
/Count 3
>>
endobj
4 0 obj
<< /Type /Page
…Additional entries describing the attributes of this page…
>>
endobj
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be Pages for
a page tree node.
Parent
dictionary (Required except in root node; must be an indirect reference) The page tree node that
is the immediate parent of this one.
Kids
array (Required) An array of indirect references to the immediate children of this node.
The children may be page objects or other page tree nodes.
Count
integer (Required) The number of leaf nodes (page objects) that are descendants of this
node within the page tree.
Document StructureSECTION 3.6
119
10 0 obj
<< /Type /Page
…Additional entries describing the attributes of this page…
>>
endobj
24 0 obj
<< /Type /Page
…Additional entries describing the attributes of this page…
>>
endobj
In addition to the entries shown in Table 3.26, a page tree node may contain fur-
ther entries defining inherited attributes for the page objects that are its descen-
dants (see “Inheritance of Page Attributes” on page 123).
Page Objects
The leaves of the page tree are page objects, each of which is a dictionary specify-
ing the attributes of a single page of the document. Table 3.27 shows the contents
of this dictionary (see also implementation note 35 in Appendix H). The table
also identifies which attributes a page may inherit from its ancestor nodes in the
page tree, as described under “Inheritance of Page Attributes” on page 123.
Attributes that are not explicitly identified in the table as inheritable cannot be in-
herited.
TABLE 3.27 Entries in a page object
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be
Page for a page object.
Parent
dictionary (Required; must be an indirect reference) The page tree node that is the im-
mediate parent of this page object.
LastModified
date (Required if PieceInfo is present; optional otherwise; PDF 1.3) The date and
time (see Section 3.8.3, “Dates”) when the page’s contents were most re-
cently modified. If a page-piece dictionary (
PieceInfo) is present, the
modification date is used to ascertain which of the application data dictio-
naries that it contains correspond to the current content of the page (see
Section 10.4, “Page-Piece Dictionaries”).
SyntaxCHAPTER 3
120
Resources
dictionary (Required; inheritable) A dictionary containing any resources required by
the page (see Section 3.7.2, “Resource Dictionaries”). If the page requires
no resources, the value of this entry should be an empty dictionary. Omit-
ting the entry entirely indicates that the resources are to be inherited from
an ancestor node in the page tree.
MediaBox
rectangle (Required; inheritable) A rectangle (see Section 3.8.4, “Rectangles”), ex-
pressed in default user space units, defining the boundaries of the physical
medium on which the page is intended to be displayed or printed (see Sec-
tion 10.10.1, “Page Boundaries”).
CropBox
rectangle (Optional; inheritable) A rectangle, expressed in default user space units,
defining the visible region of default user space. When the page is dis-
played or printed, its contents are to be clipped (cropped) to this rectangle
and then imposed on the output medium in some implementation-
defined manner (see Section 10.10.1, “Page Boundaries”). Default value:
the value of
MediaBox.
BleedBox
rectangle (Optional; PDF 1.3) A rectangle, expressed in default user space units, de-
fining the region to which the contents of the page should be clipped
when output in a production environment (see Section 10.10.1, “Page
Boundaries”). Default value: the value of
CropBox.
TrimBox
rectangle (Optional; PDF 1.3) A rectangle, expressed in default user space units, de-
fining the intended dimensions of the finished page after trimming (see
Section 10.10.1, “Page Boundaries”). Default value: the value of
CropBox.
ArtBox
rectangle (Optional; PDF 1.3) A rectangle, expressed in default user space units, de-
fining the extent of the page’s meaningful content (including potential
white space) as intended by the page’s creator (see Section 10.10.1, “Page
Boundaries”). Default value: the value of
CropBox.
BoxColorInfo
dictionary (Optional; PDF 1.4) A box color information dictionary specifying the col-
ors and other visual characteristics to be used in displaying guidelines on
the screen for the various page boundaries (see “Display of Page Bound-
aries” on page 893). If this entry is absent, the application should use its
own current default settings.
KEY TYPE VALUE
Document StructureSECTION 3.6
121
Contents
stream or array (Optional) A content stream (see Section 3.7.1, “Content Streams”) de-
scribing the contents of this page. If this entry is absent, the page is empty.
The value may be either a single stream or an array of streams. If the value
is an array, the effect is as if all of the streams in the array were concatenat-
ed, in order, to form a single stream. This allows PDF producers to create
image objects and other resources as they occur, even though they inter-
rupt the content stream. The division between streams may occur only at
the boundaries between lexical tokens (see Section 3.1, “Lexical Conven-
tions”) but is unrelated to the page’s logical content or organization. Appli-
cations that consume or produce PDF files are not required to preserve
the existing structure of the
Contents array. (See implementation note 36
in Appendix H.)
Rotate
integer (Optional; inheritable) The number of degrees by which the page should
be rotated clockwise when displayed or printed. The value must be a mul-
tiple of 90. Default value: 0.
Group
dictionary (Optional; PDF 1.4) A group attributes dictionary specifying the attributes
of the page’s page group for use in the transparent imaging model (see
Sections 7.3.6, “Page Group,” and 7.5.5, “Transparency Group XObjects”).
Thumb
stream (Optional) A stream object defining the page’s thumbnail image (see Sec-
tion 8.2.3, “Thumbnail Images”).
B
array (Optional; PDF 1.1; recommended if the page contains article beads) An ar-
ray of indirect references to article beads appearing on the page (see Sec-
tion 8.3.2, “Articles”; see also implementation note 37 in Appendix H).
The beads are listed in the array in natural reading order.
Dur
number (Optional; PDF 1.1) The page’s display duration (also called its advance
timing): the maximum length of time, in seconds, that the page is dis-
played during presentations before the viewer application automatically
advances to the next page (see Section 8.3.3, “Presentations”). By default,
the viewer does not advance automatically.
Trans
dictionary (Optional; PDF 1.1) A transition dictionary describing the transition effect
to be used when displaying the page during presentations (see Section
8.3.3, “Presentations”).
Annots
array (Optional) An array of annotation dictionaries representing annotations
associated with the page (see Section 8.4, “Annotations”).
KEY TYPE VALUE
SyntaxCHAPTER 3
122
AA
dictionary (Optional; PDF 1.2) An additional-actions dictionary defining actions to
be performed when the page is opened or closed (see Section 8.5.2, “Trig-
ger Events”; see also implementation note 38 in Appendix H).
Metadata
stream (Optional; PDF 1.4) A metadata stream containing metadata for the page
(see Section 10.2.2, “Metadata Streams”).
PieceInfo
dictionary (Optional; PDF 1.3) A page-piece dictionary associated with the page (see
Section 10.4, “Page-Piece Dictionaries”).
StructParents
integer (Required if the page contains structural content items; PDF 1.3) The inte-
ger key of the page’s entry in the structural parent tree (see “Finding Struc-
ture Elements from Content Items” on page 797).
ID
string (Optional; PDF 1.3; indirect reference preferred) The digital identifier of
the page’s parent Web Capture content set (see Section 10.9.5, “Object At-
tributes Related to Web Capture”).
PZ
number (Optional; PDF 1.3) The page’s preferred zoom (magnification) factor: the
factor by which it should be scaled to achieve the natural display magnifi-
cation (see Section 10.9.5, “Object Attributes Related to Web Capture”).
SeparationInfo
dictionary (Optional; PDF 1.3) A separation dictionary containing information need-
ed to generate color separations for the page (see Section 10.10.3, “Separa-
tion Dictionaries”).
Tabs
name (Optional; PDF 1.5) A name specifying the tab order to be used for anno-
tations on the page
. The possible values are R (row order), C (column or-
der), and
S (structure order). See Section 8.4, “Annotations,” for details.
TemplateInstantiated
name
(Required if this page was created from a named page object; PDF 1.5) The
name of the originating page object (see Section 8.6.5, “Named Pages”).
PresSteps
dictionary (Optional; PDF 1.5) A navigation node dictionary representing the first
node on the page (see “Sub-page Navigation” on page 566).
UserUnit
number (Optional; PDF 1.6) A positive number giving the size of default user space
units, in multiples of 1⁄72 inch. The range of supported values is imple-
mentation-dependent; see implementation note 171 in Appendix H.
Default value: 1.0 (user unit is 1⁄72 inch).
VP
dictionary (Optional; PDF 1.6) An array of viewport dictionaries (see Table 8.105)
specifying rectangular regions of the page.
KEY TYPE VALUE
Document StructureSECTION 3.6
123
Example 3.15 shows the definition of a page object with a thumbnail image and
two annotations. The media box specifies that the page is to be printed on letter-
size paper. In addition, the resource dictionary is specified as a direct object and
shows that the page makes use of three fonts named
F3, F5, and F7.
Example 3.15
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]
>>
/Contents 12 0 R
/Thumb 14 0 R
/Annots [ 23 0 R
24 0 R
]
>>
endobj
Inheritance of Page Attributes
Some of the page attributes shown in Table 3.27 are designated as inheritable. If
such an attribute is omitted from a page object, its value is inherited from an an-
cestor node in the page tree. If the attribute is a required one, a value must be sup-
plied in an ancestor node. If the attribute is optional and no inherited value is
specified, the default value is used.
An attribute can thus be defined once for a whole set of pages by specifying it in
an intermediate page tree node and arranging the pages that share the attribute as
descendants of that node. For example, a document might specify the same me-
dia box for all of its pages by including a
MediaBox entry in the root node of the
page tree. If necessary, an individual page object could override this inherited val-
ue with a
MediaBox entry of its own.
SyntaxCHAPTER 3
124
Note: In a document conforming to the Linearized PDF organization (see Appen-
dix F), all page attributes must be specified explicitly as entries in the page dictio-
naries to which they apply; they may not be inherited from an ancestor node.
Figure 3.6 illustrates the inheritance of attributes. In the page tree shown, pages 1,
2, and 4 are rotated clockwise by 90 degrees, page 3 by 270 degrees, page 6 by 180
degrees, and pages 5 and 7 not at all (0 degrees).
FIGURE 3.6 Inheritance of attributes
3.6.3 Name Dictionary
Some categories of objects in a PDF file can be referred to by name rather than by
object reference. The correspondence between names and objects is established
by the document’s name dictionary (PDF 1.2), located by means of the
Names en-
try in the document’s catalog (see Section 3.6.1, “Document Catalog”). Each entry
in this dictionary designates the root of a name tree (Section 3.8.5, “Name Trees”)
defining names for a particular category of objects. Table 3.28 shows the contents
of the name dictionary.
Pages
PagesPages
/Rotate 90
Pages
/Rotate 180
PagePage Page
/Rotate 0
PagePagePages
Page
/Rotate 90
Page
/Rotate 270
Page 1 Page 2 Page 5 Page 6 Page 7
Page 4Page 3
Content Streams and ResourcesSECTION 3.7
125
TABLE 3.28 Entries in the name dictionary
3.7 Content Streams and Resources
Content streams are the primary means for describing the appearance of pages
and other graphical elements. A content stream depends on information con-
tained in an associated resource dictionary; in combination, these two objects
form a self-contained entity. This section describes these objects.
KEY TYPE VALUE
Dests
name tree (Optional; PDF 1.2) A name tree mapping name strings to destinations
(see “Named Destinations” on page 553).
AP
name tree (Optional; PDF 1.3) A name tree mapping name strings to annotation
appearance streams (see Section 8.4.4, “Appearance Streams”).
JavaScript
name tree (Optional; PDF 1.3) A name tree mapping name strings to document-
level JavaScript actions (see “JavaScript Actions” on page 668).
Pages
name tree (Optional; PDF 1.3) A name tree mapping name strings to visible pages
for use in interactive forms (see Section 8.6.5, “Named Pages”).
Templates
name tree (Optional; PDF 1.3) A name tree mapping name strings to invisible
(template) pages for use in interactive forms (see Section 8.6.5, “Named
Pages”).
IDS
name tree (Optional; PDF 1.3) A name tree mapping digital identifiers to Web
Capture content sets (see Section 10.9.3, “Content Sets”).
URLS
name tree (Optional; PDF 1.3) A name tree mapping uniform resource locators
(URLs) to Web Capture content sets (see Section 10.9.3, “Content
Sets”).
EmbeddedFiles
name tree (Optional; PDF 1.4) A name tree mapping name strings to file specifica-
tions for embedded file streams (see Section 3.10.3, “Embedded File
Streams”).
AlternatePresentations
name tree (Optional; PDF 1.4) A name tree mapping name strings to alternate pre-
sentations (see Section 9.4, “Alternate Presentations”).
Renditions
name tree (Optional; PDF 1.5) A name tree mapping name strings (which must
have Unicode encoding) to rendition objects (see Section 9.1.2, “Rendi-
tions”).
SyntaxCHAPTER 3
126
3.7.1 Content Streams
A content stream is a PDF stream object whose data consists of a sequence of in-
structions describing the graphical elements to be painted on a page. The instruc-
tions are represented in the form of PDF objects, using the same object syntax as
in the rest of the PDF document. However, whereas the document as a whole is a
static, random-access data structure, the objects in the content stream are intend-
ed to be interpreted and acted upon sequentially.
Each page of a document is represented by one or more content streams. Content
streams are also used to package sequences of instructions as self-contained
graphical elements, such as forms (see Section 4.9, “Form XObjects”), patterns
(Section 4.6, “Patterns”), certain fonts (Section 5.5.4, “Type 3 Fonts”), and anno-
tation appearances (Section 8.4.4, “Appearance Streams”).
A content stream, after decoding with any specified filters, is interpreted accord-
ing to the PDF syntax rules described in Section 3.1, “Lexical Conventions.” It
consists of PDF objects denoting operands and operators. The operands needed
by an operator precede it in the stream. See Example 3.3 on page 44 for an exam-
ple of a content stream.
An operand is a direct object belonging to any of the basic PDF data types except
a stream. Dictionaries are permitted as operands only by certain specific opera-
tors. Indirect objects and object references are not permitted at all.
An operator is a PDF keyword that specifies some action to be performed, such as
painting a graphical shape on the page. An operator keyword is distinguished
from a name object by the absence of an initial slash character (
/). Operators are
meaningful only inside a content stream.
Note: This postfix notation, in which an operator is preceded by its operands, is
superficially the same as in the PostScript language. However, PDF has no concept
of an operand stack as PostScript has. In PDF, all of the operands needed by an op-
erator must immediately precede that operator. Operators do not return results, and
operands cannot be left over when an operator finishes execution.
Content Streams and ResourcesSECTION 3.7
127
Most operators have to do with painting graphical elements on the page or with
specifying parameters that affect subsequent painting operations. The individual
operators are described in the chapters devoted to their functions:
• Chapter 4 describes operators that paint general graphics, such as filled areas,
strokes, and sampled images, and that specify device-independent graphical
parameters, such as color.
• Chapter 5 describes operators that paint text using character glyphs defined in
fonts.
• Chapter 6 describes operators that specify device-dependent rendering param-
eters.
• Chapter 10 describes the marked-content operators that associate higher-level
logical information with objects in the content stream. These operators do not
affect the rendered appearance of the content; they specify information useful
to applications that use PDF for document interchange.
Ordinarily, when an application encounters an operator in a content stream that
it does not recognize, an error occurs. (See implementation note 39 in Appendix
H.) A pair of compatibility operators,
BX and EX (PDF 1.1), modify this behavior
(see Table 3.29). These operators must occur in pairs and may be nested. They
bracket a compatibility section, a portion of a content stream within which unrec-
ognized operators are to be ignored without error. This mechanism enables a
PDF document to use operators defined in later versions of PDF without sacrific-
ing compatibility with older applications. It should be used only in cases where
ignoring such newer operators is the appropriate thing to do. The
BX and EX op-
erators are not themselves part of any graphics object (see Section 4.1, “Graphics
Objects”) or of the graphics state (Section 4.3, “Graphics State”).
TABLE 3.29 Compatibility operators
OPERANDS OPERATOR DESCRIPTION
—
BX
(PDF 1.1) Begin a compatibility section. Unrecognized operators (along with their
operands) are ignored without error until the balancing
EX operator is encountered.
—
EX
(PDF 1.1) End a compatibility section begun by a balancing BX operator.
SyntaxCHAPTER 3
128
3.7.2 Resource Dictionaries
As stated above, the operands supplied to operators in a content stream may only
be direct objects; indirect objects and object references are not permitted. In
some cases, an operator needs to refer to a PDF object that is defined outside the
content stream, such as a font dictionary or a stream containing image data. This
can be accomplished by defining such objects as named resources and referring to
them by name from within the content stream.
Note: Named resources are meaningful only in the context of a content stream. The
scope of a resource name is local to a particular content stream and is unrelated to
externally known identifiers for objects such as fonts. References from one object to
another outside of content streams should be made by means of indirect object refer-
ences rather than named resources.
A content stream’s named resources are defined by a resource dictionary, which
enumerates the named resources needed by the operators in the content stream
and the names by which they can be referred to. For example, if a text operator
appearing within the content stream needs a certain font, the content stream’s re-
source dictionary can associate the name
F42 with the corresponding font dictio-
nary. The text operator can use this name to refer to the font.
A resource dictionary is associated with a content stream in one of the following
ways:
• For a content stream that is the value of a page’s Contents entry (or is an
element of an array that is the value of that entry), the resource dictionary is
designated by the page dictionary’s
Resources entry. (Since a page’s Resources
attribute is inheritable, as described under “Inheritance of Page Attributes” on
page 123, it may actually reside in some ancestor node of the page object.)
• For other content streams, the stream dictionary’s Resources entry specifies the
resource dictionary. This applies to content streams that define form XObjects,
patterns, Type 3 fonts, and annotation appearances.
• A form XObject or a Type 3 font’s glyph description may omit the Resources
entry, in which case resources are looked up in the Resources entry of the page
on which the form or font is used. This practice is not recommended.
Content Streams and ResourcesSECTION 3.7
129
In the context of a given content stream, the term current resource dictionary
refers to the resource dictionary associated with the stream in one of the ways
described above.
Each key in a resource dictionary is the name of a resource type, as shown in
Table 3.30. The corresponding values are as follows:
• For resource type ProcSet, the value is an array of procedure set names
• For all other resource types, the value is a subdictionary. Each key in the sub-
dictionary is the name of a specific resource, and the corresponding value is a
PDF object associated with the name.
TABLE 3.30 Entries in a resource dictionary
Example 3.16 shows a resource dictionary containing procedure sets, fonts, and
external objects. The procedure sets are specified by an array, as described in Sec-
tion 10.1, “Procedure Sets.” The fonts are specified with a subdictionary associat-
KEY TYPE VALUE
ExtGState
dictionary (Optional) A dictionary that maps resource names to graphics state parame-
ter dictionaries (see Section 4.3.4, “Graphics State Parameter Dictionaries”).
ColorSpace
dictionary (Optional) A dictionary that maps each resource name to either the name of a
device-dependent color space or an array describing a color space (see Sec-
tion 4.5, “Color Spaces”).
Pattern
dictionary (Optional) A dictionary that maps resource names to pattern objects (see Sec-
tion 4.6, “Patterns”).
Shading
dictionary (Optional; PDF 1.3) A dictionary that maps resource names to shading dictio-
naries (see “Shading Dictionaries” on page 274).
XObject
dictionary (Optional) A dictionary that maps resource names to external objects (see
Section 4.7, “External Objects”).
Font
dictionary (Optional) A dictionary that maps resource names to font dictionaries (see
Chapter 5).
ProcSet
array (Optional) An array of predefined procedure set names (see Section 10.1,
“Procedure Sets”).
Properties
dictionary (Optional; PDF 1.2) A dictionary that maps resource names to property list
dictionaries for marked content (see Section 10.5.1, “Property Lists”).
SyntaxCHAPTER 3
130
ing the names F5, F6, F7, and F8 with objects 6, 8, 10, and 12, respectively.
Likewise, the
XObject subdictionary associates the names Im1 and Im2 with ob-
jects 13 and 15, respectively.
Example 3.16
<< /ProcSet [/PDF /ImageB]
/Font << /F5 6 0 R
/F6 8 0 R
/F7 10 0 R
/F8 12 0 R
>>
/XObject << /Im1 13 0 R
/Im2 15 0 R
>>
>>
3.8 Common Data Structures
As mentioned at the beginning of this chapter, there are some general-purpose
data structures that are built from the basic object types described in Section 3.2,
“Objects,” and are used in many places throughout PDF. This section describes
data structures for text strings, dates, rectangles, name trees, and number trees.
The subsequent two sections describe more complex data structures for functions
and file specifications.
All of these data structures are meaningful only as part of the document hier-
archy; they cannot appear within content streams. In particular, the special con-
ventions for interpreting the values of string objects apply only to strings outside
content streams. An entirely different convention is used within content streams
for using strings to select sequences of glyphs to be painted on the page (see
Chapter 5). Table 3.31 summarizes the basic and higher-level data types that are
used throughout this book to describe the values of dictionary entries and other
PDF data values.
Common Data StructuresSECTION 3.8
131
TABLE 3.31 PDF data types
3.8.1 Text Strings
Certain strings contain information that is intended to be human-readable, such
as text annotations, bookmark names, article names, document information, and
so forth. Such strings are referred to as text strings. Text strings are encoded in
either
PDFDocEncoding or Unicode character encoding. PDFDocEncoding is a
superset of the ISO Latin 1 encoding and is documented in Appendix D. Unicode
is described in the Unicode Standard by the Unicode Consortium (see the Bibli-
ography).
TYPE DESCRIPTION SECTION PAGE
array Array object 3.2.5 34
boolean Boolean value 3.2.1 28
date Date (string) 3.8.3 133
dictionary Dictionary object 3.2.6 35
file specification File specification (string or dictionary) 3.10 151
function Function (dictionary or stream) 3.9 139
integer Integer number 3.2.2 28
name Name object 3.2.4 32
name tree Name tree (dictionary) 3.8.5 134
null Null object 3.2.8 39
number Number (integer or real) 3.2.2 28
number tree Number tree (dictionary) 3.8.6 138
rectangle Rectangle (array) 3.8.4 134
stream Stream object 3.2.7 36
string String object 3.2.3 29
text string Text string 3.8.1 131
text stream Text stream 3.8.2 132
SyntaxCHAPTER 3
132
For text strings encoded in Unicode, the first two bytes must be 254 followed by
255. These two bytes represent the Unicode byte order marker,
U+FEFF, indicating
that the string is encoded in the UTF-16BE (big-endian) encoding scheme speci-
fied in the Unicode standard. (This mechanism precludes beginning a string us-
ing
PDFDocEncoding with the two characters thorn ydieresis, which is unlikely to
be a meaningful beginning of a word or phrase).
Note: Applications that process PDF files containing Unicode text strings should be
prepared to handle supplementary characters; that is, characters requiring more
than two bytes to represent.
An escape sequence may appear anywhere in a Unicode text string to indicate the
language in which subsequent text is written, which is useful when the language
cannot be determined from the character codes used in the text. The escape se-
quence consists of the following elements, in order:
1. The Unicode value
U+001B (that is, the byte sequence 0 followed by 27)
2. A 2-character ISO 639 language code—for example,
en for English or ja for
Japanese
3. (Optional) A 2-character ISO 3166 country code—for example,
US for the
United States or
JP for Japan
4. The Unicode value
U+001B
The complete list of codes defined by ISO 639 and ISO 3166 can be obtained
from the International Organization for Standardization (see the Bibliography).
3.8.2 Text Streams
A text stream (PDF 1.5) is a PDF stream object (Section 3.2.7) whose unencoded
bytes meet the same requirements as a text string (Section 3.8.1) with respect to
encoding, byte order, and lead bytes.
Common Data StructuresSECTION 3.8
133
3.8.3 Dates
PDF defines a standard date format, which closely follows that of the internation-
al standard ASN.1 (Abstract Syntax Notation One), defined in ISO/IEC 8824 (see
the Bibliography). A date is a string of the form
(D:YYYYMMDDHHmmSSOHH'mm')
where
YYYY is the year
MM is the month
DD is the day (01–31)
HH is the hour (00–23)
mm is the minute (00–59)
SS is the second (00–59)
O is the relationship of local time to Universal Time (UT), denoted by one of
the characters
+, , or Z (see below)
HH followed by ' is the absolute value of the offset from UT in hours (00–23)
mm followed by ' is the absolute value of the offset from UT in minutes (00–59)
The apostrophe character (
') after HH and mm is part of the syntax. All fields after
the year are optional. (The prefix
D:, although also optional, is strongly recom-
mended.) The default values for
MM and DD are both 01; all other numerical
fields default to zero values. A plus sign (
+) as the value of the O field signifies that
local time is later than UT, a minus sign (
) signifies that local time is earlier than
UT, and the letter
Z signifies that local time is equal to UT. If no UT information
is specified, the relationship of the specified time to UT is considered to be un-
known. Regardless of whether the time zone is known, the rest of the date should
be specified in local time.
For example, December 23, 1998, at 7:52 PM, U.S. Pacific Standard Time, is rep-
resented by the string
D:19981223195208'00'
SyntaxCHAPTER 3
134
3.8.4 Rectangles
Rectangles are used to describe locations on a page and bounding boxes for a
variety of objects, such as fonts. A rectangle is written as an array of four numbers
giving the coordinates of a pair of diagonally opposite corners. Typically, the
array takes the form
[ll
x
ll
y
ur
x
ur
y
]
specifying the lower-left x, lower-left y, upper-right x, and upper-right y coordi-
nates of the rectangle, in that order. The other two corners of the rectangle are
then assumed to have coordinates (
ll
x
, ur
y
) and (ur
x
, ll
y
).
Note: Although rectangles are conventionally specified by their lower-left and upper-
right corners, it is acceptable to specify any two diagonally opposite corners. Appli-
cations that process PDF should be prepared to normalize such rectangles in situa-
tions where specific corners are required.
3.8.5 Name Trees
A name tree serves a similar purpose to a dictionary—associating keys and
values—but by different means. A name tree differs from a dictionary in the fol-
lowing important ways:
• Unlike the keys in a dictionary, which are name objects, those in a name tree
are strings.
• The keys are ordered.
• The values associated with the keys may be objects of any type. Stream objects
are required to be specified by indirect object references. It is recommended,
though not required, that dictionary, array, and string objects be specified by
indirect object references, and other PDF objects (nulls, numbers, booleans,
and names) be specified as direct objects.
• The data structure can represent an arbitrarily large collection of key-value
pairs, which can be looked up efficiently without requiring the entire data
structure to be read from the PDF file. (In contrast, a dictionary is subject to an
implementation limit on the number of entries it can contain.)
Common Data StructuresSECTION 3.8
135
A name tree is constructed of nodes, each of which is a dictionary object. Table
3.32 shows the entries in a node dictionary. The nodes are of three kinds,
depending on the specific entries they contain. The tree always has exactly one
root node, which contains a single entry: either
Kids or Names but not both. If the
root node has a
Names entry, it is the only node in the tree. If it has a Kids entry,
each of the remaining nodes is either an intermediate node, containing a
Limits
entry and a Kids entry, or a leaf node, containing a Limits entry and a Names en-
try.
TABLE 3.32 Entries in a name tree node dictionary
The Kids entries in the root and intermediate nodes define the tree’s structure by
identifying the immediate children of each node. The
Names entries in the leaf
(or root) nodes contain the tree’s keys and their associated values, arranged in
key-value pairs and sorted lexically in ascending order by key. Shorter keys
appear before longer ones beginning with the same byte sequence. The encoding
of the keys is immaterial as long as it is self-consistent; keys are compared for
equality on a simple byte-by-byte basis.
The keys contained within the various nodes’
Names entries do not overlap; each
Names entry contains a single contiguous range of all the keys in the tree. In a leaf
node, the
Limits entry specifies the least and greatest keys contained within the
node’s
Names entry. In an intermediate node, it specifies the least and greatest
keys contained within the
Names entries of any of that node’s descendants. The
KEY TYPE VALUE
Kids
array (Root and intermediate nodes only; required in intermediate nodes; present in the root
node if and only if
Names is not present) An array of indirect references to the immediate
children of this node. The children may be intermediate or leaf nodes.
Names
array (Root and leaf nodes only; required in leaf nodes; present in the root node if and only if Kids
is not present) An array of the form
[key
1
value
1
key
2
value
2
… key
n
value
n
]
where each key
i
is a string and the corresponding value
i
is the object associated with that
key. The keys are sorted in lexical order, as described below.
Limits
array (Intermediate and leaf nodes only; required) An array of two strings, specifying the (lexi-
cally) least and greatest keys included in the
Names array of a leaf node or in the Names
arrays of any leaf nodes that are descendants of an intermediate node.
SyntaxCHAPTER 3
136
value associated with a given key can thus be found by walking the tree in order,
searching for the leaf node whose
Names entry contains that key.
Example 3.17 is an abbreviated outline, showing object numbers and nodes, of a
name tree that maps the names of all the chemical elements, from actinium to
zirconium, to their atomic numbers. Example 3.18 shows the representation of
this tree in a PDF file.
Example 3.17 Example of a name tree
1: Root node
2: Intermediate node: Actinium to Gold
5: Leaf node: Actinium = 25, …, Astatine = 31
25: Integer: 89
…
31: Integer: 85
…
11: Leaf node: Gadolinium = 56, …, Gold = 59
56: Integer: 64
…
59: Integer: 79
3: Intermediate node: Hafnium to Protactinium
12: Leaf node: Hafnium = 60, …, Hydrogen = 65
60: Integer: 72
…
65: Integer: 1
…
19: Leaf node: Palladium = 92, …, Protactinium = 100
92: Integer: 46
…
100:Integer: 91
4: Intermediate node: Radium to Zirconium
20: Leaf node: Radium = 101, …, Ruthenium = 107
101:Integer: 89
…
107:Integer: 85
…
24: Leaf node: Xenon = 129, …, Zirconium = 133
129:Integer: 54
…
133:Integer: 40
Common Data StructuresSECTION 3.8
137
Example 3.18
1 0 obj
<< /Kids [ 2 0 R % Root node
3 0 R
4 0 R
]
>>
endobj
2 0 obj
<< /Limits [(Actinium) (Gold)] % Intermediate node
/Kids [ 5 0 R
6 0 R
7 0 R
8 0 R
9 0 R
10 0 R
11 0 R
]
>>
endobj
3 0 obj
<< /Limits [(Hafnium) (Protactinium)] % Intermediate node
/Kids [ 12 0 R
13 0 R
14 0 R
15 0 R
16 0 R
17 0 R
18 0 R
19 0 R
]
>>
endobj
4 0 obj
<< /Limits [(Radium) (Zirconium)] % Intermediate node
/Kids [ 20 0 R
21 0 R
22 0 R
23 0 R
24 0 R
]
>>
endobj
SyntaxCHAPTER 3
138
5 0 obj
<< /Limits [(Actinium) (Astatine)] % Leaf node
/Names [ (Actinium) 25 0 R
(Aluminum) 26 0 R
(Americium) 27 0 R
(Antimony) 28 0 R
(Argon) 29 0 R
(Arsenic) 30 0 R
(Astatine) 31 0 R
]
>>
endobj
…
24 0 obj
<< /Limits [(Xenon) (Zirconium)] % Leaf node
/Names [ (Xenon) 129 0 R
(Ytterbium) 130 0 R
(Yttrium) 131 0 R
(Zinc) 132 0 R
(Zirconium) 133 0 R
]
>>
endobj
25 0 obj
89 % Atomic number (Actinium)
endobj
…
133 0 obj
40 % Atomic number (Zirconium)
endobj
3.8.6 Number Trees
A number tree is similar to a name tree (see Section 3.8.5, “Name Trees”), except
that its keys are integers instead of strings and are sorted in ascending numerical
order. The entries in the leaf (or root) nodes containing the key-value pairs are
named
Nums instead of Names as in a name tree. Table 3.33 shows the entries in a
number tree’s node dictionaries.
FunctionsSECTION 3.9
139
TABLE 3.33 Entries in a number tree node dictionary
3.9 Functions
PDF is not a programming language, and a PDF file is not a program. However,
PDF does provide several types of function objects (PDF 1.2) that represent pa-
rameterized classes of functions, including mathematical formulas and sampled
representations with arbitrary resolution. Functions are used in various ways in
PDF, including device-dependent rasterization information for high-quality
printing (halftone spot functions and transfer functions), color transform func-
tions for certain color spaces, and specification of colors as a function of position
for smooth shadings.
Functions in PDF represent static, self-contained numerical transformations. A
function to add two numbers has two input values and one output value:
Similarly, a function that computes the arithmetic and geometric mean of two
numbers could be viewed as a function of two input values and two output values:
KEY TYPE VALUE
Kids
array (Root and intermediate nodes only; required in intermediate nodes; present in the root
node if and only if
Nums is not present) An array of indirect references to the immediate
children of this node. The children may be intermediate or leaf nodes.
Nums
array (Root and leaf nodes only; required in leaf nodes; present in the root node if and only if Kids
is not present) An array of the form
[key
1
value
1
key
2
value
2
… key
n
value
n
]
where each key
i
is an integer and the corresponding value
i
is the object associated with
that key. The keys are sorted in numerical order, analogously to the arrangement of keys
in a name tree as described in Section 3.8.5, “Name Trees.”
Limits
array (Intermediate and leaf nodes only; required) An array of two integers, specifying the
(numerically) least and greatest keys included in the
Nums array of a leaf node or in the
Nums arrays of any leaf nodes that are descendants of an intermediate node.
fx
0
x
1
,()x
0
x
1
+=
fx
0
x
1
,()
x
0
x
1
+
2
-----------------
x
0
x
1
×,=
SyntaxCHAPTER 3
140
In general, a function can take any number (m) of input values and produce any
number (n) of output values:
In PDF functions, all the input values and all the output values are numbers, and
functions have no side effects.
Each function definition includes a domain, the set of legal values for the input.
Some types of functions also define a range, the set of legal values for the output.
Input values passed to the function are clipped to the domain, and output values
produced by the function are clipped to the range. For example, suppose the
function
is defined with a domain of
[11]. If the function is called with the input value 6,
that value is replaced with the nearest value in the defined domain, 1, before the
function is evaluated; the resulting output value is therefore 3. Similarly, if the
function
is defined with a range of
[0 100], and if the input values 6 and 4 are passed to
the function (and are within its domain), then the output value produced by the
function,
14, is replaced with 0, the nearest value in the defined range.
A function object may be a dictionary or a stream, depending on the type of
function. The term function dictionary is used generically in this section to refer
to either a dictionary object or the dictionary portion of a stream object. A func-
tion dictionary specifies the function’s representation, the set of attributes that
parameterize that representation, and the additional data needed by that repre-
sentation. Four types of functions are available, as indicated by the dictionary’s
FunctionType entry:
• (PDF 1.2) A sampled function (type 0) uses a table of sample values to define the
function. Various techniques are used to interpolate values between the sample
values (see Section 3.9.1, “Type 0 (Sampled) Functions”).
• (PDF 1.3) An exponential interpolation function (type 2) defines a set of coef-
ficients for an exponential function (see Section 3.9.2, “Type 2 (Exponential In-
terpolation) Functions”).
fx
0
… x
m 1–
,,()y
0
… y
n 1–
,,=
fx() x 2+=
fx
0
x
1
,()3 x
0
× x
1
+=
FunctionsSECTION 3.9
141
• (PDF 1.3) A stitching function (type 3) is a combination of other functions, par-
titioned across a domain (see Section 3.9.3, “Type 3 (Stitching) Functions”).
• (PDF 1.3) A PostScript calculator function (type 4) uses operators from the
PostScript language to describe an arithmetic expression (see Section 3.9.4,
“Type 4 (PostScript Calculator) Functions”).
All function dictionaries share the entries listed in Table 3.34.
TABLE 3.34 Entries common to all function dictionaries
In addition, each type of function dictionary must include entries appropriate to
the particular function type. The number of output values can usually be inferred
from other attributes of the function; if not (as is always the case for type 0 and
type 4 functions), the
Range entry is required. The dimensionality of the function
implied by the
Domain and Range entries must be consistent with that implied by
other attributes of the function.
KEY TYPE VALUE
FunctionType
integer (Required) The function type:
0Sampled function
2 Exponential interpolation function
3Stitching function
4 PostScript calculator function
Domain
array (Required) An array of 2 × m numbers, where m is the number of input val-
ues. For each i from 0 to m 1,
Domain
2i
must be less than or equal to
Domain
2i+1
, and the ith input value, x
i
, must lie in the interval
Domain
2i
x
i
Domain
2i+1
. Input values outside the declared domain are
clipped to the nearest boundary value.
Range
array (Required for type 0 and type 4 functions, optional otherwise; see below) An
array of 2 × n numbers, where n is the number of output values. For each j
from 0 to n 1,
Range
2j
must be less than or equal to Range
2j+1
, and the jth
output value, y
j
, must lie in the interval Range
2j
y
j
Range
2j+1
. Output
values outside the declared range are clipped to the nearest boundary value. If
this
entry is absent, no clipping is done.
SyntaxCHAPTER 3
142
3.9.1 Type 0 (Sampled) Functions
Type 0 functions use a sequence of sample values (contained in a stream) to pro-
vide an approximation for functions whose domains and ranges are bounded.
The samples are organized as an m-dimensional table in which each entry has n
components.
Sampled functions are highly general and offer reasonably accurate representa-
tions of arbitrary analytic functions at low expense. For example, a 1-input sinu-
soidal function can be represented over the range
[0 180] with an average error
of only 1 percent, using just ten samples and linear interpolation. Two-input
functions require significantly more samples but usually not a prohibitive num-
ber if the function does not have high frequency variations.
The dimensionality of a sampled function is restricted only by implementation
limits. However, the number of samples required to represent functions with high
dimensionality multiplies rapidly unless the sampling resolution is very low. Also,
the process of multilinear interpolation becomes computationally intensive if the
number of inputs m is greater than 2. The multidimensional spline interpolation
is even more computationally intensive.
In addition to the entries in Table 3.34, a type 0 function dictionary includes
those shown in Table 3.35.
The
Domain, Encode, and Size entries determine how the function’s input vari-
able values are mapped into the sample table. For example, if
Size is [21 31], the
default
Encode array is [0 20 0 30], which maps the entire domain into the full
set of sample table entries. Other values of
Encode may be used.
To explain the relationship between
Domain, Encode, Size, Decode, and Range,
we use the following notation:
For a given value of x, Interpolate calculates the y value on the line defined by the
two points (x
min
, y
min
) and (x
max
, y
max
).
y Interpolate xx
min
x
max
y
min
y
max
,,,,)(=
y
min
xx
min
– )(
y
max
y
min
–
x
max
x
min
–
----------------------------
×
+=
FunctionsSECTION 3.9
143
TABLE 3.35 Additional entries specific to a type 0 function dictionary
When a sampled function is called, each input value x
i
, for 0 i < m, is clipped to
the domain:
That value is encoded:
That value is clipped to the size of the sample table in that dimension:
KEY TYPE VALUE
Size
array (Required) An array of m positive integers specifying the number of samples
in each input dimension of the sample table.
BitsPerSample
integer (Required) The number of bits used to represent each sample. (If the function
has multiple output values, each one occupies
BitsPerSample bits.) Valid
values are 1, 2, 4, 8, 12, 16, 24, and 32.
Order
integer (Optional) The order of interpolation between samples. Valid values are 1 and
3, specifying linear and cubic spline interpolation, respectively. (See imple-
mentation note 40 in Appendix H.) Default value: 1.
Encode
array (Optional) An array of 2 × m numbers specifying the linear mapping of input
values into the domain of the function’s sample table. Default value:
[0 (Size
0
1) 0 (Size
1
1) …].
Decode
array (Optional) An array of 2 × n numbers specifying the linear mapping of sam-
ple values into the range appropriate for the function’s output values. Default
value: same as the value of
Range.
other stream
attributes
(various) (Optional) Other attributes of the stream that provides the sample values, as
appropriate (see Table 3.4 on page 38).
x
i
min max x
i
Domain
2i
,)( Domain
2i 1+
,)(=
e
i
Interpolate x
i
Domain
2i
Domain
2i 1+
Encode
2i
Encode
2i 1+
,, ,, )(=
e
i
min max e
i
0,)( Size
i
1–,)(=
SyntaxCHAPTER 3
144
The encoded input values are real numbers, not restricted to integers. Interpola-
tion is used to determine output values from the nearest surrounding values in
the sample table. Each output value r
j
, for 0 j < n, is then decoded:
Finally, each decoded value is clipped to the range:
Sample data is represented as a stream of unsigned 8-bit bytes (integers in the
range 0 to 255). The bytes constitute a continuous bit stream, with the high-order
bit of each byte first. Each sample value is represented as a sequence of
BitsPerSample bits. Successive values are adjacent in the bit stream; there is no
padding at byte boundaries.
For a function with multidimensional input (more than one input variable), the
sample values in the first dimension vary fastest, and the values in the last dimen-
sion vary slowest. For example, for a function f(a, b, c), where a, b, and c vary
from 0 to 9 in steps of 1, the sample values would appear in this order: f(0, 0, 0),
f(1, 0, 0), …, f(9, 0, 0), f(0, 1, 0), f(1, 1, 0), …, f(9, 1, 0), f(0, 2, 0), f(1, 2, 0), …,
f(9, 9, 0), f(0, 0, 1), f(1, 0, 1), and so on.
For a function with multidimensional output (more than one output value), the
values are stored in the same order as
Range.
The stream data must be long enough to contain the entire sample array, as indi-
cated by
Size, Range, and BitsPerSample; see “Stream Extent” on page 37.
Example 3.19 illustrates a sampled function with 4-bit samples in an array
containing 21 columns and 31 rows (651 values). The function takes two argu-
ments, x and y, in the domain
[1.0 1.0], and returns one value, z, in that same
range. The x argument is linearly transformed by the encoding to the domain
[0 20] and the y argument to the domain [0 30]. Using bilinear interpolation be-
tween sample points, the function computes a value for z, which (because
BitsPerSample is 4) will be in the range [0 15], and the decoding transforms z to
a number in the range
[1.0 1.0] for the result. The sample array is stored in a
string of 326 bytes, calculated as follows (rounded up):
326 bytes = 31 rows × 21 samples/row × 4 bits/sample ÷ 8 bits/byte
r
j
Interpolate r
j
02
BitsPerSample
1– Decode
2j
Decode
2j 1+
,, , , )(=
y
j
min max r
j
Range
2j
,)( Range
2j 1+
,)(=
FunctionsSECTION 3.9
145
The first byte contains the sample for the point (1.0, 1.0) in the high-order 4
bits and the sample for the point (0.9, 1.0) in the low-order 4 bits.
Example 3.19
14 0 obj
<< /FunctionType 0
/Domain [1.0 1.0 1.0 1.0]
/Size [21 31]
/Encode [0 20 0 30]
/BitsPerSample 4
/Range [1.0 1.0]
/Decode [1.0 1.0]
/Length …
/Filter …
>>
stream
…651 sample values…
endstream
endobj
The Decode entry can be used creatively to increase the accuracy of encoded
samples corresponding to certain values in the range. For example, if the range of
the function is
[1.0 1.0] and BitsPerSample is 4, the usual value of Decode
would be [1.0 1.0] and the sample values would be integers in the interval
[0 15] (as shown in Figure 3.7). But if these values are used, the midpoint of the
range, 0.0, is not represented exactly by any sample value, since it falls halfway be-
tween 7 and 8. However, if the
Decode array is [1.0 +1.1429] (1.1429 being ap-
proximately equal to 16 ÷ 14) and the sample values supplied are in the interval
[0 14], the effective range of [1.0 1.0] is achieved, and the range value 0.0 is rep-
resented by the sample value 7.
The
Size value for an input dimension can be 1, in which case all input values in
that dimension will be mapped to the single allowed value. If
Size is less than 4,
cubic spline interpolation is not possible and
Order 3 will be ignored if specified.
SyntaxCHAPTER 3
146
FIGURE 3.7 Mapping with the Decode array
3.9.2 Type 2 (Exponential Interpolation) Functions
Type 2 functions (PDF 1.3) include a set of parameters that define an exponential
interpolation of one input value and n output values:
In addition to the entries in Table 3.34 on page 141, a type 2 function dictionary
includes those listed in Table 3.36. (See implementation note 41 in Appendix H.)
TABLE 3.36 Additional entries specific to a type 2 function dictionary
Values of Domain must constrain x in such a way that if N is not an integer, all val-
ues of x must be non-negative, and if
N is negative, no value of x may be zero.
Typically,
Domain is declared as [0.0 1.0], and N is a positive number. The Range
attribute is optional and can be used to clip the output to a specified range. Note
that when
N is 1, the function performs a linear interpolation between C0 and C1;
therefore, the function can also be expressed as a sampled function (type 0).
KEY TYPE VALUE
C0
array (Optional) An array of n numbers defining the function result when x = 0.0. Default value:
[0.0].
C1
array (Optional) An array of n numbers defining the function result when x = 1.0. Default value:
[1.0].
N
number (Required) The interpolation exponent. Each input value x will return n values, given by
y
j
= C0
j
+ x
N
× (C1
j
C0
j
), for 0 j < n.
1
+1
1
0
2345 789 101112131415
Samples
Range
/Decode [1 1]
1
+1
1
0
234 67891011121314 15
Samples
Range
/Decode [1 1.1429]
fx() y
0
… y
n 1–
,,=
FunctionsSECTION 3.9
147
3.9.3 Type 3 (Stitching) Functions
Type 3 functions (PDF 1.3) define a stitching of the subdomains of several 1-input
functions to produce a single new 1-input function. Since the resulting stitching
function is a 1-input function, the domain is given by a two-element array,
[Domain
0
Domain
1
].
In addition to the entries in Table 3.34 on page 141, a type 3 function dictionary
includes those listed in Table 3.37. (See implementation note 42 in Appendix H.)
TABLE 3.37 Additional entries specific to a type 3 function dictionary
Domain must be of size 2 (that is, m = 1), and Domain
0
must be strictly less than
Domain
1
unless k = 1. The domain is partitioned into k subdomains, as indicated
by the dictionary’s
Bounds entry, which is an array of k 1 numbers that obey the
following relationships (with exceptions as noted below):
The
Bounds array describes a series of half-open intervals, closed on the left and
open on the right (except the last, which is closed on the right as well). The value
of the
Functions entry is an array of k functions. The first function applies to x
values in the first subdomain,
Domain
0
x < Bounds
0
; the second function ap-
plies to x values in the second subdomain,
Bounds
0
x < Bounds
1
; and so on.
The last function applies to x values in the last subdomain, which includes the
upper bound:
Bounds
k2
x Domain
1
. The value of k may be 1, in which case
KEY TYPE VALUE
Functions
array (Required) An array of k 1-input functions making up the stitching function. The out-
put dimensionality of all functions must be the same, and compatible with the value of
Range if Range is present.
Bounds
array (Required) An array of k 1 numbers that, in combination with Domain, define the
intervals to which each function from the
Functions array applies. Bounds elements
must be in order of increasing value, and each value must be within the domain
defined by
Domain.
Encode
array (Required) An array of 2 × k numbers that, taken in pairs, map each subset of the do-
main defined by
Domain and the Bounds array to the domain of the corresponding
function.
Domain
0
Bounds
0
Bounds
1
… Bounds
k 2–
Domain
1
<<<< <
SyntaxCHAPTER 3
148
the Bounds array is empty and the single item in the Functions array applies to all
x values,
Domain
0
x Domain
1
.
The
Encode array contains 2 × k numbers. A value x from the ith subdomain is
encoded as follows:
for 0 i < k. In this equation,
Bounds
1
means Domain
0
, and Bounds
k1
means
Domain
1
. If the last bound, Bounds
k2
, is equal to Domain
1
, then x is defined to
be
Encode
2i
.
The stitching function is designed to make it easy to combine several functions to
be used within one shading pattern over different parts of the shading’s domain.
(Shading patterns are discussed in Section 4.6.3, “Shading Patterns.”) The same
effect could be achieved by creating a separate shading dictionary for each of the
functions, with adjacent domains. However, since each shading would have simi-
lar parameters, and because the overall effect is one shading, it is more con-
venient to have a single shading with multiple function definitions.
Also, type 3 functions provide a general mechanism for inverting the domains of
1-input functions. For example, consider a function f with a
Domain of [0.0 1.0]
and a stitching function g with a Domain of [0.0 1.0], a Functions array contain-
ing f, and an
Encode array of [1.0 0.0]. In effect, g(x) = f(1 x).
3.9.4 Type 4 (PostScript Calculator) Functions
A type 4 function (PDF 1.3), also called a PostScript calculator function, is repre-
sented as a stream containing code written in a small subset of the PostScript lan-
guage. Although any function can be sampled (in a type 0 PDF function) and
others can be described with exponential functions (type 2 in PDF), type 4 func-
tions offer greater flexibility and potentially greater accuracy. For example, a tint
transformation function for a hexachrome (six-component)
DeviceN color space
with an alternate color space of
DeviceCMYK (see “DeviceN Color Spaces” on
page 238) requires a 6-in, 4-out function. If such a function were sampled with m
values for each input variable, the number of samples, 4 × m
6
, could be prohibi-
tively large. In practice, such functions are often written as short, simple Post-
Script functions. (See implementation note 43 in Appendix H.)
x Interpolate x
Bounds
i 1–
Bounds
i
˙
Encode
2i
Encode
2i 1+
,,,, )(=
FunctionsSECTION 3.9
149
Type 4 functions also make it possible to include a wide variety of halftone spot
functions without the loss of accuracy that comes from sampling, and without
adding to the list of predefined spot functions (see Section 6.4.2, “Spot Func-
tions”). All of the predefined spot functions can be written as type 4 functions.
The language that can be used in a type 4 function contains expressions involving
integers, real numbers, and boolean values only. There are no composite data
structures such as strings or arrays, no procedures, and no variables or names. Ta-
ble 3.38 lists the operators that can be used in this type of function. (For more in-
formation on these operators, see Appendix B of the PostScript Language
Reference, Third Edition.) Although the semantics are those of the corresponding
PostScript operators, a PostScript interpreter is not required.
TABLE 3.38 Operators in type 4 functions
The operand syntax for type 4 functions follows PDF conventions rather than
PostScript conventions. The entire code stream defining the function is enclosed
in braces
{ }. Braces also delimit expressions that are executed conditionally by the
if and ifelse operators:
boolean {expression}if
boolean {expression
1
}{expression
2
} ifelse
This construct is purely syntactic; unlike in PostScript, no “procedure objects” are
involved.
OPERATOR TYPE OPERATORS
Arithmetic operators abs
add
atan
ceiling
cos
cvi
cvr
div
exp
floor
idiv
ln
log
mod
mul
neg
round
sin
sqrt
sub
truncate
Relational, boolean,
and bitwise operators
and
bitshift
eq
false
ge
gt
le
lt
ne
not
or
true
xor
Conditional operators if ifelse
Stack operators copy
dup
exch
index
pop
roll
SyntaxCHAPTER 3
150
A type 4 function dictionary includes the entries in Table 3.34 on page 141, as
well as other appropriate stream attributes (see Table 3.4 on page 38). Example
3.20 shows a type 4 function equivalent to the predefined spot function
DoubleDot (see Section 6.4.2, “Spot Functions”).
Example 3.20
10 0 obj
<< /FunctionType 4
/Domain [1.0 1.0 1.0 1.0]
/Range [1.0 1.0]
/Length 71
>>
stream
{ 360 mul sin
2 div
exch 360 mul sin
2 div
add
}
endstream
endobj
The Domain and Range entries are both required. The input variables constitute
the initial operand stack; the items remaining on the operand stack after execu-
tion of the function are the output variables. It is an error for the number of re-
maining operands to differ from the number of output variables specified by
Range or for any of them to be objects other than numbers.
Implementations of type 4 functions must provide a stack with room for at least
100 entries. No implementation is required to provide a larger stack, and it is an
error to overflow the stack.
Although any integers or real numbers that may appear in the stream fall under
the same implementation limits (defined in Appendix C) as in other contexts, the
intermediate results in type 4 function computations do not. An implementation
may use a representation that exceeds those limits. Operations on real numbers,
for example, might use single-precision or double-precision floating-point num-
bers. (See implementation note 44 in Appendix H.)
File SpecificationsSECTION 3.10
151
Errors in Type 4 Functions
The code that reads a type 4 function (analogous to the PostScript scanner) must
detect and report syntax errors. It may also be able to detect some errors that will
occur when the function is used, although this is not always possible. Any errors
detected by the scanner are considered to be errors in the PDF file and are han-
dled like other errors in the file.
The code that executes a type 4 function (analogous to the PostScript interpreter)
must detect and report errors. PDF does not define a representation for the
errors; those details are provided by the application that processes the PDF file.
The following types of errors can occur (among others):
• Stack overflow
• Stack underflow
• A type error (for example, applying not to a real number)
• A range error (for example, applying sqrt to a negative number)
• An undefined result (for example, dividing by 0)
3.10 File Specifications
A PDF file can refer to the contents of another file by using a file specification
(PDF 1.1), which can take either of two forms:
• A simple file specification gives just the name of the target file in a standard for-
mat, independent of the naming conventions of any particular file system. It
can take the form of either a string or a dictionary
• A full file specification includes information related to one or more specific file
systems. It can only be represented as a dictionary.
Although the file designated by a file specification is normally external to the
PDF file referring to it, PDF 1.3 permits a copy of the external file to be embed-
ded within the referring PDF file, allowing its contents to be stored or transmitted
along with the PDF file. However, embedding a file does not change the presump-
tion that it is external to the PDF file. Consequently, to ensure that the PDF file
can be processed correctly, it may be necessary to copy its embedded files back
into a local file system.
SyntaxCHAPTER 3
152
3.10.1 File Specification Strings
The standard format for representing a simple file specification in string form
divides the string into component substrings separated by the slash character (
/).
The slash is a generic component separator that is mapped to the appropriate
platform-specific separator when generating a platform-dependent file name.
Any of the components may be empty. If a component contains one or more liter-
al slashes, each must be preceded by a backslash (
\), which in turn must be pre-
ceded by another backslash to indicate that it is part of the string and not an
escape character. For example, the string
(in\\/out)
represents the file name
in/out
The backslashes are removed in processing the string; they are needed only to
distinguish the component values from the component separators. The compo-
nent substrings are stored as bytes and are passed to the operating system without
interpretation or conversion of any sort.
Absolute and Relative File Specifications
A simple file specification that begins with a slash is an absolute file specification.
The last component is the file name; the preceding components specify its con-
text. In some file specifications, the file name may be empty; for example, URL
(uniform resource locator) specifications can specify directories instead of files. A
file specification that does not begin with a slash is a relative file specification giv-
ing the location of the file relative to that of the PDF file containing it.
In the case of a URL-based file system, the rules of Internet RFC 1808, Relative
Uniform Resource Locators (see the Bibliography), are used to compute an abso-
lute URL from a relative file specification and the specification of the PDF file.
Prior to this process, the relative file specification is converted to a relative URL
by using the escape mechanism of RFC 1738, Uniform Resource Locators, to rep-
resent any bytes that would be either unsafe according to RFC 1738 or not
representable in 7-bit U.S. ASCII. In addition, such URL-based relative file speci-
fications are limited to paths as defined in RFC 1808. The scheme, network loca-
File SpecificationsSECTION 3.10
153
tion/login, fragment identifier, query information, and parameter sections are
not allowed.
In the case of other file systems, a relative file specification is converted to an ab-
solute file specification by removing the file name component from the specifica-
tion of the containing PDF file and appending the relative file specification in its
place. For example, the relative file specification
ArtFiles/Figure1.pdf
appearing in a PDF file whose specification is
/HardDisk/PDFDocuments/AnnualReport/Summary.pdf
yields the absolute specification
/HardDisk/PDFDocuments/AnnualReport/ArtFiles/Figure1.pdf
The special component .. (two periods) can be used in a relative file specification
to move up a level in the file system hierarchy. When the component immediately
preceding
.. is not another .., the two cancel each other; both are eliminated from
the file specification and the process is repeated. Thus, in the example above, the
relative file specification
../../ArtFiles/Figure1.pdf
would yield the absolute specification
/HardDisk/ArtFiles/Figure1.pdf
Conversion to Platform-Dependent File Names
The conversion of a file specification to a platform-dependent file name depends
on the specific file naming conventions of each platform:
• For DOS, the initial component is either a physical or logical drive identifier or
a network resource name as returned by the Microsoft Windows function
WNetGetConnection, and is followed by a colon (:). A network resource name is
constructed from the first two components; the first component is the server
name and the second is the share name (volume name). All components are
then separated by backslashes. It is possible to specify an absolute DOS path
SyntaxCHAPTER 3
154
without a drive by making the first component empty. (Empty components are
ignored by other platforms.)
• For Mac OS, all components are separated by colons (:).
• For UNIX, all components are separated by slashes (/). An initial slash, if
present, is preserved.
Strings used to specify a file name are interpreted in the standard encoding for
the platform on which the document is being viewed. Table 3.39 shows examples
of file specifications on the most common platforms.
TABLE 3.39 Examples of file specifications
When creating documents that are to be viewed on multiple platforms, care must
be taken to ensure file name compatibility. Only a subset of the U.S. ASCII char-
acter set should be used in file specifications: the uppercase alphabetic characters
(
A–Z), the numeric characters (0–9), and the underscore (_). The period (.) has
special meaning in DOS and Windows file names, and as the first character in a
Mac OS pathname. In file specifications, the period should be used only to sepa-
rate a base file name from a file extension.
Some file systems are case-insensitive, and names within a directory should re-
main distinguishable if lowercase letters are changed to uppercase or vice versa.
On DOS and Windows 3.1 systems and on some CD-ROM file systems, file
names are limited to 8 characters plus a 3-character extension. File system soft-
ware typically converts long names to short names by retaining the first 6 or 7
characters of the file name and the first 3 characters after the last period, if any.
Since characters beyond the sixth or seventh are often converted to other values
unrelated to the original value, file names must be distinguishable from the first
6 characters.
SYSTEM SYSTEM-DEPENDENT PATHS WRITTEN FORM
DOS \pdfdocs\spec.pdf (no drive)
r:\pdfdocs\spec.pdf
pclib/eng:\pdfdocs\spec.pdf
(//pdfdocs/spec.pdf)
(/r/pdfdocs/spec.pdf)
(/pclib/eng/pdfdocs/spec.pdf)
Mac OS
Mac HD:PDFDocs:spec.pdf (/Mac HD/PDFDocs/spec.pdf)
UNIX /user/fred/pdfdocs/spec.pdf
pdfdocs/spec.pdf (relative)
(/user/fred/pdfdocs/spec.pdf)
(pdfdocs/spec.pdf)
File SpecificationsSECTION 3.10
155
Multiple-Byte Strings in File Specifications
In PDF 1.2 or higher, a file specification may contain multiple-byte character
codes, represented in hexadecimal form between angle brackets (
< and >). Since
the slash character
<2F> is used as a component delimiter and the backslash
<5C> is used as an escape character, any occurrence of either of these bytes in a
multiple-byte character must be preceded by the ASCII code for the backslash
character. For example, a file name containing the 2-byte character code
<89 5C> must write it as <89 5C 5C>. When the application encounters this se-
quence of bytes in a file name, it replaces the sequence with the original 2-byte
code.
3.10.2 File Specification Dictionaries
The dictionary form of file specification provides more flexibility than the string
form, allowing different files to be specified for different file systems or plat-
forms, or for file systems other than the standard ones (DOS/Windows, Mac OS,
and UNIX). Table 3.40 shows the entries in a file specification dictionary. Con-
sumer applications running on a particular platform should use the appropriate
platform-specific entry (
DOS, Mac, or Unix) if available. If the required platform-
specific entry is not present and there is no file system entry (
FS), the generic F
entry should be used as a simple file specification.
TABLE 3.40 Entries in a file specification dictionary
KEY TYPE VALUE
Type
name (Required if an EF or RF entry is present; recommended always) The type of PDF object
that this dictionary describes; must be
Filespec for a file specification dictionary (see
implementation note 45 in Appendix H).
FS
name (Optional) The name of the file system to be used to interpret this file specification. If
this entry is present, all other entries in the dictionary are interpreted by the designat-
ed file system. PDF defines only one standard file system name,
URL (see Section
3.10.4, “URL Specifications”); an application or plug-in extension can register other
names (see Appendix E). This entry is independent of the
F, DOS, Mac, and Unix en-
tries.
F
string (Required if the DOS, Mac, and Unix entries are all absent) A file specification string of
the form described in Section 3.10.1, “File Specification Strings,” or (if the file system
is
URL) a uniform resource locator, as described in Section 3.10.4, “URL Specifica-
tions.”
SyntaxCHAPTER 3
156
DOS
string (Optional) A file specification string (see Section 3.10.1, “File Specification Strings”)
representing a DOS file name.
Mac
string (Optional) A file specification string (see Section 3.10.1, “File Specification Strings”)
representing a Mac OS file name.
Unix
string (Optional) A file specification string (see Section 3.10.1, “File Specification Strings”)
representing a UNIX file name.
ID
array (Optional) An array of two strings constituting a file identifier (see Section 10.3, “File
Identifiers”) that is also included in the referenced file. The use of this entry improves
an application’s chances of finding the intended file and allows it to warn the user if
the file has changed since the link was made.
V
boolean (Optional; PDF 1.2) A flag indicating whether the file referenced by the file specifica-
tion is volatile (changes frequently with time). If the value is
true, applications should
never cache a copy of the file. For example, a movie annotation referencing a URL to
a live video camera could set this flag to
true to notify the application that it should
reacquire the movie each time it is played. Default value:
false.
EF
dictionary (Required if RF is present; PDF 1.3) A dictionary containing a subset of the keys F,
DOS, Mac, and Unix, corresponding to the entries by those names in the file specifica-
tion dictionary. The value of each such key is an embedded file stream (see Section
3.10.3, “Embedded File Streams”) containing the corresponding file. If this entry is
present, the
Type entry is required and the file specification dictionary must be indi-
rectly referenced.
RF
dictionary (Optional; PDF 1.3) A dictionary with the same structure as the EF dictionary, which
must also be present. Each key in the
RF dictionary must also be present in the EF dic-
tionary. Each value is a related files array (see “Related Files Arrays” on page 159)
identifying files that are related to the corresponding file in the
EF dictionary. If this
entry is present, the
Type entry is required and the file specification dictionary must
be indirectly referenced.
Desc
text string (Optional; PDF 1.6) Descriptive text associated with the file specification. It is used
for files in the
EmbeddedFiles name tree (see Section 3.6.3, “Name Dictionary”).
KEY TYPE VALUE
File SpecificationsSECTION 3.10
157
3.10.3 Embedded File Streams
File specifications ordinarily refer to files external to the PDF file in which they
occur. When a PDF file is archived or transmitted, all external files it refers to
must accompany it to preserve the file’s integrity. Embedded file streams (PDF 1.3)
address this problem by allowing the contents of referenced files to be embedded
directly within the body of the PDF file. For example, if the file contains OPI
(Open Prepress Interface) dictionaries that refer to externally stored high-resolu-
tion images (see Section 10.10.6, “Open Prepress Interface (OPI)”), the image
data can be incorporated into the PDF file with embedded file streams. This
makes the PDF file a self-contained unit that can be stored or transmitted as a
single entity. (The embedded files are included purely for convenience and need
not be directly processed by any PDF consumer application.)
An embedded file stream can be included in a PDF document in the following
ways:
• Any file specification dictionary in the document may have an EF entry that
specifies an embedded file stream. The stream data must still be associated with
a location in the file system. In particular, this method is used for file attach-
ment annotations (see “File Attachment Annotations” on page 600), which as-
sociate the embedded file with a location on a page in the document.
• Embedded file streams can be associated with the document as a whole
through the
EmbeddedFiles entry (PDF 1.4) in the PDF document’s name dic-
tionary (see Section 3.6.3, “Name Dictionary”). The associated name tree maps
name strings to file specifications that refer to embedded file streams through
their
EF entries. (See implementation note 45 in Appendix H.)
Note: Beginning with PDF 1.6, the
Desc entry of the file specification dictionary
(see Table 3.40) can be used to provide a textual description of the embedded file,
which can be displayed in the user interface of a viewer application. Previously, it
was necessary to identify document-level embedded files by the the name string
provided in the name dictionary associated with an embedded file stream in
much the same way that the JavaScript name tree associates name strings with
document-level JavaScript actions (see “JavaScript Actions” on page 668).
The stream dictionary describing an embedded file contains the standard entries
for any stream, such as
Length and Filter (see Table 3.4 on page 38), as well as the
additional entries shown in Table 3.41.
SyntaxCHAPTER 3
158
TABLE 3.41 Additional entries in an embedded file stream dictionary
TABLE 3.42 Entries in an embedded file parameter dictionary
For Mac OS files, the Mac entry in the embedded file parameter dictionary holds
a further subdictionary containing Mac OS–specific file information. Table 3.43
shows the contents of this subdictionary.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
EmbeddedFile for an embedded file stream.
Subtype
name (Optional) The subtype of the embedded file. The value of this entry must be
a first-class name, as defined in Appendix E. Names without a registered pre-
fix must conform to the MIME media type names defined in Internet RFC
2046, Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types
(see the Bibliography), with the provision that characters not allowed in
names must use the 2-character hexadecimal code format described in Sec-
tion 3.2.4, “Name Objects.”
Params
dictionary (Optional) An embedded file parameter dictionary containing additional, file-
specific information (see Table 3.42).
KEY TYPE VALUE
Size
integer (Optional) The size of the embedded file, in bytes.
CreationDate
date (Optional) The date and time when the embedded file was created.
ModDate
date (Optional) The date and time when the embedded file was last modified.
Mac
dictionary (Optional) A subdictionary containing additional information specific to
Mac OS files (see Table 3.43).
CheckSum
string (Optional) A 16-byte string that is the checksum of the bytes of the uncom-
pressed embedded file. The checksum is calculated by applying the standard
MD5 message-digest algorithm (described in Internet RFC 1321, The MD5
Message-Digest Algorithm; see the Bibliography) to the bytes of the embedded
file stream.
File SpecificationsSECTION 3.10
159
TABLE 3.43 Entries in a Mac OS file information dictionary
Related Files Arrays
In some circumstances, a PDF file can refer to a group of related files, such as the
set of five files that make up a DCS 1.0 color-separated image. The file specifica-
tion explicitly names only one of the files; the rest are identified by some system-
atic variation of that file name (such as by altering the extension). When such a
file is to be embedded in a PDF file, the related files must be embedded as well.
This is accomplished by including a related files array (PDF 1.3) as the value of the
RF entry in the file specification dictionary. The array has 2 × n elements, which
are paired in the form
[ string
1
stream
1
string
2
stream
2
…
string
n
stream
n
]
The first element of each pair is a string giving the name of one of the related files;
the second element is an embedded file stream holding the file’s contents.
In Example 3.21, objects 21, 31, and 41 are embedded file streams containing the
DOS file
SUNSET.EPS, the Mac OS file Sunset.eps, and the UNIX file Sunset.eps,
respectively. The file specification dictionary’s
RF entry specifies an array, object
30, identifying a set of embedded files related to the Mac OS file, forming a
DCS 1.0 set. The example shows only the first two embedded file streams in the
set; an actual PDF file would, of course, include all of them.
KEY TYPE VALUE
Subtype
integer (Optional) The embedded file’s file type. It is encoded as an integer according to Mac
OS conventions: a 4-character ASCII text literal, converted to a 32-bit integer, with the
high-order byte first. For example, the file type
'CARO' is represented as the hexadeci-
mal integer 4341524F, which is expressed in decimal as 1128354383.
Creator
integer (Optional) The embedded file’s creator signature, encoded in the same way as Subtype.
ResFork
stream (Optional) The binary contents of the embedded file’s resource fork.
SyntaxCHAPTER 3
160
Example 3.21
10 0 obj % File specification dictionary
<< /Type /Filespec
/DOS (SUNSET.EPS)
/Mac (Sunset.eps) % Name of Mac OS file
/Unix (Sunset.eps )
/EF << /DOS 21 0 R
/Mac 31 0 R % Embedded Mac OS file
/Unix 41 0 R
>>
/RF << /Mac 30 0 R >> % Related files array for Mac OS file
>>
endobj
30 0 obj % Related files array for Mac OS file
[ (Sunset.eps) 31 0 R % Includes file Sunset .eps itself
(Sunset.C) 32 0 R
(Sunset.M) 33 0 R
(Sunset.Y) 34 0 R
(Sunset.K) 35 0 R
]
endobj
31 0 obj % Embedded file stream for Mac OS file
<< /Type /EmbeddedFile % Sunset.eps
/Length …
/Filter …
>>
stream
…Data for Sunset .eps…
endstream
endobj
32 0 obj % Embedded file stream for related file
<< /Type /EmbeddedFile % Sunset.C
/Length …
/Filter …
>>
stream
…Data for Sunset .C…
endstream
endobj
File SpecificationsSECTION 3.10
161
3.10.4 URL Specifications
When the FS entry in a file specification dictionary has the value URL, the value of
the
F entry in that dictionary is not a file specification string, but a uniform
resource locator (URL) of the form defined in Internet RFC 1738, Uniform
Resource Locators (see the Bibliography). Example 3.22 shows a URL specifica-
tion.
Example 3.22
<< /FS /URL
/F (ftp://www.beatles.com/Movies/AbbeyRoad.mov)
>>
The URL must adhere to the character-encoding requirements specified in RFC
1738. Because 7-bit U.S. ASCII is a strict subset of
PDFDocEncoding, this value
may also be considered to be in that encoding.
3.10.5 Maintenance of File Specifications
The techniques described in this section can be used to maintain the integrity of
the file specifications within a PDF file during the following types of operations:
• Updating the relevant file specification when a referenced file is renamed
• Determining the complete collection of files that must be copied to a mirror
site
• When creating new links to external files, discovering existing file specifica-
tions that refer to the same files and sharing them
• Finding the file specifications associated with embedded files to be packed or
unpacked
It is not possible, in general, to find all file specification strings in a PDF file be-
cause there is no way to determine whether a given string is a file specification
string. It is possible, however, to find all file specification dictionaries, provided
that they meet the following conditions:
• They are indirect objects.
• They contain a Type entry whose value is the name Filespec.
SyntaxCHAPTER 3
162
An application can locate all of the file specification dictionaries by traversing the
PDF file’s cross-reference table (see Section 3.4.3, “Cross-Reference Table”) and
finding all dictionaries with
Type keys whose value is Filespec. For this reason, it
is highly recommended that all file specifications be expressed in dictionary form
and meet the conditions stated above. Note that any file specification dictionary
specifying embedded files (that is, one that contains an
EF entry) must satisfy
these conditions (see Table 3.40 on page 155).
Note: It may not be possible to locate file specification dictionaries that are direct
objects, since they are neither self-typed nor necessarily reachable by any standard
path of object references.
Files may be embedded in a PDF file either directly, using the
EF entry in a file
specification dictionary, or indirectly, using related files arrays specified in the
RF
entry. If a file is embedded indirectly, its name is given by the string that precedes
the embedded file stream in the related files array. If it is embedded directly, its
name is obtained from the value of the corresponding entry in the file specifica-
tion dictionary. In Example 3.21 on page 160, for instance, the
EF dictionary has a
DOS entry identifying object number 21 as an embedded file stream. The name of
the embedded DOS file,
SUNSET.EPS, is given by the DOS entry in the file
specification dictionary.
A given external file may be referenced from more than one file specification.
Therefore, when embedding a file with a given name, it is necessary to check for
other occurrences of the same name as the value associated with the correspond-
ing key in other file specification dictionaries. This requires finding all em-
beddable file specifications and, for each matching key, checking for both of the
following conditions:
• The string value associated with the key matches the name of the file being em-
bedded.
• A value has not already been embedded for the file specification. (If there is
already a corresponding key in the
EF dictionary, a file has already been embed-
ded for that use of the file name.)
Note that there is no requirement that the files associated with a given file name
be unique. The same file name, such as
readme.txt, may be associated with differ-
ent embedded files in distinct file specifications.
163
CHAPTER 4
4Graphics
The graphics operators used in PDF content streams describe the appearance of
pages that are to be reproduced on a raster output device. The facilities described
in this chapter are intended for both printer and display applications.
The graphics operators form six main groups:
• Graphics state operators manipulate the data structure called the graphics state,
the global framework within which the other graphics operators execute. The
graphics state includes the current transformation matrix (CTM), which maps
user space coordinates used within a PDF content stream into output device
coordinates. It also includes the current color, the current clipping path, and
many other parameters that are implicit operands of the painting operators.
• Path construction operators specify paths, which define shapes, line trajectories,
and regions of various sorts. They include operators for beginning a new path,
adding line segments and curves to it, and closing it.
• Path-painting operators fill a path with a color, paint a stroke along it, or use it
as a clipping boundary.
• Other painting operators paint certain self-describing graphics objects. These
include sampled images, geometrically defined shadings, and entire content
streams that in turn contain sequences of graphics operators.
• Text operators select and show character glyphs from fonts (descriptions of type-
faces for representing text characters). Because PDF treats glyphs as general
graphical shapes, many of the text operators could be grouped with the graph-
ics state or painting operators. However, the data structures and mechanisms
for dealing with glyph and font descriptions are sufficiently specialized that
Chapter 5 focuses on them.
GraphicsCHAPTER 4
164
• Marked-content operators associate higher-level logical information with ob-
jects in the content stream. This information does not affect the rendered ap-
pearance of the content (although it may determine if the content should be
presented at all; see Section 4.10, “Optional Content”); it is useful to applica-
tions that use PDF for document interchange. Marked content is described in
Section 10.5, “Marked Content.”
This chapter presents general information about device-independent graphics in
PDF: how a PDF content stream describes the abstract appearance of a page.
Rendering—the device-dependent part of graphics—is covered in Chapter 6. The
Bibliography lists a number of books that give details of these computer graphics
concepts and their implementation.
4.1 Graphics Objects
As discussed in Section 3.7.1, “Content Streams,” the data in a content stream is
interpreted as a sequence of operators and their operands, expressed as basic data
objects according to standard PDF syntax. A content stream can describe the
appearance of a page, or it can be treated as a graphical element in certain other
contexts.
The operands and operators are written sequentially using postfix notation.
Although this notation resembles the sequential execution model of the Post-
Script language, a PDF content stream is not a program to be interpreted; rather,
it is a static description of a sequence of graphics objects. There are specific rules,
described below, for writing the operands and operators that describe a graphics
object.
PDF provides five types of graphics objects:
• A path object is an arbitrary shape made up of straight lines, rectangles, and
cubic Bézier curves. A path may intersect itself and may have disconnected
sections and holes. A path object ends with one or more painting operators that
specify whether the path is stroked, filled, used as a clipping boundary, or some
combination of these operations.
• A text object consists of one or more character strings that identify sequences of
glyphs to be painted. Like a path, text can be stroked, filled, or used as a clip-
ping boundary.
Graphics ObjectsSECTION 4.1
165
• An external object (XObject) is an object defined outside the content stream
and referenced as a named resource (see Section 3.7.2, “Resource Diction-
aries”). The interpretation of an XObject depends on its type. An image XObject
defines a rectangular array of color samples to be painted; a form XObject is an
entire content stream to be treated as a single graphics object. Specialized types
of form XObjects are used to import content from one PDF file into another
(reference XObjects) and to group graphical elements together as a unit for
various purposes (group XObjects). In particular, the latter are used to define
transparency groups for use in the transparent imaging model (transparency
group XObjects, discussed in detail in Chapter 7). There is also a PostScript
XObject, whose use is discouraged.
• An inline image object uses a special syntax to express the data for a small image
directly within the content stream.
• A shading object describes a geometric shape whose color is an arbitrary func-
tion of position within the shape. (A shading can also be treated as a color
when painting other graphics objects; it is not considered to be a separate
graphics object in that case.)
PDF 1.3 and earlier versions use an opaque imaging model in which each graphics
object is painted in sequence, completely obscuring any previous marks it may
overlay on the page. PDF 1.4 introduces a transparent imaging model in which ob-
jects can be less than fully opaque, allowing previously painted marks to show
through. Each object is painted on the page with a specified opacity, which may
be constant at every point within the object’s shape or may vary from point to
point. The previously existing contents of the page form a backdrop with which
the new object is composited, producing results that combine the colors of the
object and backdrop according to their respective opacity characteristics. The ob-
jects at any given point on the page can be thought of as forming a transparency
stack, where the stacking order is defined to be the order in which the objects are
specified, bottommost object first. All objects in the stack can potentially contrib-
ute to the result, depending on their colors, shapes, and opacities.
PDF’s graphics parameters are so arranged that objects are painted by default
with full opacity, reducing the behavior of the transparent imaging model to that
of the opaque model. Accordingly, the material in this chapter applies to both the
opaque and transparent models except where explicitly stated otherwise; the
transparent model is described in its full generality in Chapter 7.
GraphicsCHAPTER 4
166
Although the painting behavior described above is often attributed to individual
operators making up an object, it is always the object as a whole that is painted.
Figure 4.1 shows the ordering rules for the operations that define graphics
objects. Some operations are permitted only in certain types of graphics objects
or in the intervals between graphics objects (called the page description level in
the figure). Every content stream begins at the page description level, where
changes can be made to the graphics state, such as colors and text attributes, as
discussed in the following sections.
In the figure, arrows indicate the operators that mark the beginning or end of
each type of graphics object. Some operators are identified individually, others by
general category. Table 4.1 summarizes these categories for all PDF operators.
TABLE 4.1 Operator categories
CATEGORY OPERATORS TABLE PAGE
General graphics state w, J, j, M, d, ri, i, gs 4.7 189
Special graphics state
q, Q, cm 4.7 189
Path construction
m, l, c, v, y, h, re 4.9 196
Path painting
S, s, f, F, f*, B, B*, b, b*, n 4.10 200
Clipping paths
W, W* 4.11 205
Text objects
BT, ET 5.4 375
Text state
Tc, Tw, Tz, TL, Tf, Tr, Ts 5.2 368
Text positioning
Td, TD, Tm, T* 5.5 376
Text showing
Tj, TJ, ', " 5.6 377
Type 3 fonts
d0, d1 5.10 392
Color
CS, cs, SC, SCN, sc, scn, G, g, RG, rg, K, k 4.24 257
Shading patterns
sh 4.27 273
Inline images
BI, ID, EI 4.42 322
XObjects
Do 4.37 302
Marked content
MP, DP, BMC, BDC, EMC 10.7 779
Compatibility
BX, EX 3.29 127
Graphics ObjectsSECTION 4.1
167
FIGURE 4.1 Graphics objects
Path object
Allowed operators:
• Path construction
Text object
Allowed operators:
• General graphics state
• Color
• Text state
• Text-showing
• Text-positioning
• Marked-content
Page description level
Allowed operators:
• General graphics state
• Special graphics state
• Color
• Text state
• Marked-content
Clipping path object
Allowed operators:
• None
Shading object
Allowed operators:
• None
In-line image object
Allowed operators:
• ID
External object
Allowed operators:
• None
(immediate)
Path-painting
operators
(immediate)
Path-painting
operators
m, re
EI BI Do
sh
BT ET
W, W*
GraphicsCHAPTER 4
168
For example, the path construction operators m and re signal the beginning of a
path object. Inside the path object, additional path construction operators are
permitted, as are the clipping path operators
W and W*, but not general graphics
state operators such as
w or J. A path-painting operator, such as S or f, ends the
path object and returns to the page description level.
Note: A content stream whose operations violate these rules for describing graphics
objects can produce unpredictable behavior, even though it may display and print
correctly. Applications that attempt to extract graphics objects for editing or other
purposes depend on the objects’ being well formed. The rules for graphics objects are
also important for the proper interpretation of marked content (see Section 10.5,
“Marked Content”).
A graphics object also implicitly includes all graphics state parameters that affect
its behavior. For instance, a path object depends on the value of the current color
parameter at the moment the path object is defined. The effect is as if this param-
eter were specified as part of the definition of the path object. However, the oper-
ators that are invoked at the page description level to set graphics state
parameters are not considered to belong to any particular graphics object. Graph-
ics state parameters need to be specified only when they change. A graphics
object may depend on parameters that were defined much earlier.
Similarly, the individual character strings within a text object implicitly include
the graphics state parameters on which they depend. Most of these parameters
may be set inside or outside the text object. The effect is as if they were separately
specified for each text string.
The important point is that there is no semantic significance to the exact arrange-
ment of graphics state operators. An application that reads and writes a PDF con-
tent stream is not required to preserve this arrangement, but is free to change it to
any other arrangement that achieves the same values of the relevant graphics state
parameters for each graphics object. An application should not infer any higher-
level logical semantics from the arrangement of tokens constituting a graphics
object. A separate mechanism, marked content (see Section 10.5, “Marked Con-
tent”), allows such higher-level information to be explicitly associated with the
graphics objects.
Coordinate SystemsSECTION 4.2
169
4.2 Coordinate Systems
Coordinate systems define the canvas on which all painting occurs. They deter-
mine the position, orientation, and size of the text, graphics, and images that
appear on a page. This section describes each of the coordinate systems used in
PDF, how they are related, and how transformations among them are specified.
Note: The coordinate systems discussed in this section apply to two-dimensional
graphics. PDF 1.6 introduces the ability to display 3D artwork, in which objects are
described in a three-dimensional coordinate system, as described in Section 9.5.4,
“Coordinate Systems for 3D Annotations.”
4.2.1 Coordinate Spaces
Paths and positions are defined in terms of pairs of coordinates on the Cartesian
plane. A coordinate pair is a pair of real numbers x and y that locate a point hori-
zontally and vertically within a two-dimensional coordinate space. A coordinate
space is determined by the following properties with respect to the current page:
• The location of the origin
• The orientation of the x and y axes
• The lengths of the units along each axis
PDF defines several coordinate spaces in which the coordinates specifying graph-
ics objects are interpreted. The following sections describe these spaces and the
relationships among them.
Transformations among coordinate spaces are defined by transformation matri-
ces, which can specify any linear mapping of two-dimensional coordinates, in-
cluding translation, scaling, rotation, reflection, and skewing. Transformation
matrices are discussed in Sections 4.2.2, “Common Transformations,” and 4.2.3,
“Transformation Matrices.”
Device Space
The contents of a page ultimately appear on a raster output device such as a dis-
play or a printer. Such devices vary greatly in the built-in coordinate systems they
use to address pixels within their imageable areas. A particular device’s coordi-
GraphicsCHAPTER 4
170
nate system is called its device space. The origin of the device space on different
devices can fall in different places on the output page; on displays, the origin can
vary depending on the window system. Because the paper or other output me-
dium moves through different printers and imagesetters in different directions,
the axes of their device spaces may be oriented differently. For instance, vertical
(y) coordinates may increase from the top of the page to the bottom on some
devices and from bottom to top on others. Finally, different devices have different
resolutions; some even have resolutions that differ in the horizontal and vertical
directions.
If coordinates in a PDF file were specified in device space, the file would be
device-dependent and would appear differently on different devices. For exam-
ple, images specified in the typical device spaces of a 72-pixel-per-inch display
and a 600-dot-per-inch printer would differ in size by more than a factor of 8; an
8-inch line segment on the display would appear less than 1 inch long on the
printer. Figure 4.2 shows how the same graphics object, specified in device space,
can appear drastically different when rendered on different output devices.
FIGURE 4.2 Device space
User Space
To avoid the device-dependent effects of specifying objects in device space, PDF
defines a device-independent coordinate system that always bears the same rela-
tionship to the current page, regardless of the output device on which printing or
displaying occurs. This device-independent coordinate system is called user
space.
Device space for
72-dpi screen
Device space for
300-dpi printer
Coordinate SystemsSECTION 4.2
171
The user space coordinate system is initialized to a default state for each page of a
document. The
CropBox entry in the page dictionary specifies the rectangle of
user space corresponding to the visible area of the intended output medium (dis-
play window or printed page). The positive x axis extends horizontally to the
right and the positive y axis vertically upward, as in standard mathematical prac-
tice (subject to alteration by the
Rotate entry in the page dictionary). The length
of a unit along both the x and y axes is set by the
UserUnit entry (PDF 1.6) in the
page dictionary (see Table 3.27). If that entry is not present or supported, the de-
fault value of 1⁄72 inch is used. This coordinate system is called default user space.
Note: In PostScript, the origin of default user space always corresponds to the lower-
left corner of the output medium. While this convention is common in PDF docu-
ments as well, it is not required; the page dictionary’s
CropBox entry can specify any
rectangle of default user space to be made visible on the medium.
Note: The default for the size of the unit in default user space (1⁄72 inch) is approx-
imately the same as a point, a unit widely used in the printing industry. It is not ex-
actly the same, however; there is no universal definition of a point.
Conceptually, user space is an infinite plane. Only a small portion of this plane
corresponds to the imageable area of the output device: a rectangular region de-
fined by the
CropBox entry in the page dictionary. The region of default user
space that is viewed or printed can be different for each page and is described in
Section 10.10.1, “Page Boundaries.”
Note: Because coordinates in user space (as in any other coordinate space) may be
specified as either integers or real numbers, the unit size in default user space does
not constrain positions to any arbitrary grid. The resolution of coordinates in user
space is not related in any way to the resolution of pixels in device space.
The transformation from user space to device space is defined by the current
transformation matrix (CTM), an element of the PDF graphics state (see Section
4.3, “Graphics State”). A PDF consumer application can adjust the CTM for the
native resolution of a particular output device, maintaining the device-
independence of the PDF page description. Figure 4.3 shows how this allows an
object specified in user space to appear the same regardless of the device on
which it is rendered.
The default user space provides a consistent, dependable starting place for PDF
page descriptions regardless of the output device used. If necessary, a PDF con-
GraphicsCHAPTER 4
172
tent stream may modify user space to be more suitable to its needs by applying
the coordinate transformation operator,
cm (see Section 4.3.3, “Graphics State Op-
erators”). Thus, what may appear to be absolute coordinates in a content stream
are not absolute with respect to the current page because they are expressed in a
coordinate system that may slide around and shrink or expand. Coordinate sys-
tem transformation not only enhances device-independence but is a useful tool
in its own right. For example, a content stream originally composed to occupy an
entire page can be incorporated without change as an element of another page by
shrinking the coordinate system in which it is drawn.
FIGURE 4.3 User space
User space
Device space for
72-dpi screen
Device space for
300-dpi printer
CTM
Coordinate SystemsSECTION 4.2
173
Other Coordinate Spaces
In addition to device space and user space, PDF uses a variety of other coordinate
spaces for specialized purposes:
• The coordinates of text are specified in text space. The transformation from text
space to user space is defined by a text matrix in combination with several text-
related parameters in the graphics state (see Section 5.3.1, “Text-Positioning
Operators”).
• Character glyphs in a font are defined in glyph space (see Section 5.1.3, “Glyph
Positioning and Metrics”). The transformation from glyph space to text space
is defined by the font matrix. For most types of fonts, this matrix is predefined
to map 1000 units of glyph space to 1 unit of text space; for Type 3 fonts, the
font matrix is given explicitly in the font dictionary (see Section 5.5.4, “Type 3
Fonts”).
• All sampled images are defined in image space. The transformation from image
space to user space is predefined and cannot be changed. All images are 1 unit
wide by 1 unit high in user space, regardless of the number of samples in the
image. To be painted, an image is mapped to a region of the page by temporari-
ly altering the CTM.
Note: In PostScript, unlike PDF, the relationship between image space and user
space can be specified explicitly. The fixed transformation prescribed in PDF cor-
responds to the convention that is recommended for use in PostScript.
• A form XObject (discussed in Section 4.9, “Form XObjects”) is a self-contained
content stream that can be treated as a graphical element within another con-
tent stream. The space in which it is defined is called form space. The transfor-
mation from form space to user space is specified by a form matrix contained
in the form XObject.
• PDF 1.2 defines a type of color known as a pattern, discussed in Section 4.6,
“Patterns.” A pattern is defined either by a content stream that is invoked
repeatedly to tile an area or by a shading whose color is a function of position.
The space in which a pattern is defined is called pattern space. The transforma-
tion from pattern space to user space is specified by a pattern matrix contained
in the pattern.
• PDF 1.6 introduces embedded 3D artwork, which is described in three-dimen-
sional coordinates (see Section 9.5.4, “Coordinate Systems for 3D Annota-
GraphicsCHAPTER 4
174
tions”) that are projected into an annotation’s target coordinate system (see
Section 9.5.1, “3D Annotations”).
Relationships among Coordinate Spaces
Figure 4.4 shows the relationships among the coordinate spaces described above.
Each arrow in the figure represents a transformation from one coordinate space
to another. PDF allows modifications to many of these transformations.
Because PDF coordinate spaces are defined relative to one another, changes made
to one transformation can affect the appearance of objects defined in several
coordinate spaces. For example, a change in the CTM, which defines the trans-
formation from user space to device space, affects forms, text, images, and pat-
terns, since they are all upstream from user space.
4.2.2 Common Transformations
A transformation matrix specifies the relationship between two coordinate spac-
es. By modifying a transformation matrix, objects can be scaled, rotated, translat-
ed, or transformed in other ways.
FIGURE 4.4 Relationships among coordinate systems
User
space
Device
space
Form
space
Glyph
space
Text
space
Image
space
Pattern
space
Coordinate SystemsSECTION 4.2
175
A transformation matrix in PDF is specified by six numbers, usually in the form
of an array containing six elements. In its most general form, this array is denoted
[abcdef]; it can represent any linear transformation from one coordinate
system to another. This section lists the arrays that specify the most common
transformations; Section 4.2.3, “Transformation Matrices,” discusses more math-
ematical details of transformations, including information on specifying transfor-
mations that are combinations of those listed here:
• Translations are specified as [1 0 0 1 t
x
t
y
], where t
x
and t
y
are the distances
to translate the origin of the coordinate system in the horizontal and vertical
dimensions, respectively.
• Scaling is obtained by [s
x
00s
y
00]. This scales the coordinates so that 1
unit in the horizontal and vertical dimensions of the new coordinate system is
the same size as
s
x
and s
y
units, respectively, in the previous coordinate system.
• Rotations are produced by [cos
sin
sin
cos
00], which has the effect
of rotating the coordinate system axes by an angle
counterclockwise.
• Skew is specified by [1 tan
tan
100], which skews the x axis by an angle
and the y axis by an angle
.
Figure 4.5 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 4.5 Effects of coordinate transformations
t
y
t
x
s
y
s
x
SkewingRotationScalingTranslation
GraphicsCHAPTER 4
176
If several transformations are combined, the order in which they are applied is
significant. For example, first scaling and then translating the x axis is not the
same as first translating and then scaling it. In general, to obtain the expected
results, transformations should be done in the following order:
1. Translate
2. Rotate
3. Scale or skew
Figure 4.6 shows the effect of the order in which transformations are applied. The
figure shows two sequences of transformations applied to a coordinate system.
After each successive transformation, an outline of the letter
n is drawn.
FIGURE 4.6 Effect of transformation order
Original Step 1: Translation Step 2: Rotation Step 3: Scaling
Original Step 1: Scaling Step 2: Rotation Step 3: Translation
Coordinate SystemsSECTION 4.2
177
The following transformations are shown in the figure:
• A translation of 10 units in the x direction and 20 units in the y direction
• A rotation of 30 degrees
• A scaling by a factor of 3 in the x direction
In the figure, the axes are shown with a dash pattern having a 2-unit dash and a
2-unit gap. In addition, the original (untransformed) axes are shown in a lighter
color for reference. Notice that the scale-rotate-translate ordering results in a
distortion of the coordinate system, leaving the x and y axes no longer perpendic-
ular; the recommended translate-rotate-scale ordering results in no distortion.
4.2.3 Transformation Matrices
This section discusses the mathematics of transformation matrices. It is not
necessary to read this section to use the transformations described previously;
the information is presented for the benefit of readers who want to gain a deeper
understanding of the theoretical basis of coordinate transformations.
To understand the mathematics of coordinate transformations in PDF, it is vital
to remember two points:
• Transformations alter coordinate systems, not graphics objects. All objects paint-
ed before a transformation is applied are unaffected by the transformation. Ob-
jects painted after the transformation is applied are interpreted in the
transformed coordinate system.
• Transformation matrices specify the transformation from the new (transformed)
coordinate system to the original (untransformed) coordinate system. All coor-
dinates used after the transformation are expressed in the transformed coordi-
nate system. PDF applies the transformation matrix to find the equivalent
coordinates in the untransformed coordinate system.
Note: Many computer graphics textbooks consider transformations of graphics ob-
jects rather than of coordinate systems. Although either approach is correct and self-
consistent, some details of the calculations differ depending on which point of view
is taken.
GraphicsCHAPTER 4
178
PDF represents coordinates in a two-dimensional space. The point (x, y) in such
a space can be expressed in vector form as
[xy1]. The constant third element of
this vector (
1) is needed so that the vector can be used with 3-by-3 matrices in the
calculations described below.
The transformation between two coordinate systems is represented by a 3-by-3
transformation matrix written as follows:
Because a transformation matrix has only six elements that can be changed, it is
usually specified in PDF as the six-element array
[abcdef].
Coordinate transformations are expressed as matrix multiplications:
Because PDF transformation matrices specify the conversion from the trans-
formed coordinate system to the original (untransformed) coordinate system, x
and y in this equation are the coordinates in the untransformed coordinate sys-
tem, and x and y are the coordinates in the transformed system. The multiplica-
tion is carried out as follows:
If a series of transformations is carried out, the matrices representing each of the
individual transformations can be multiplied together to produce a single equiva-
lent matrix representing the composite transformation.
Matrix multiplication is not commutative—the order in which matrices are mul-
tiplied is significant. Consider a sequence of two transformations: a scaling trans-
formation applied to the user space coordinate system, followed by a conversion
from the resulting scaled user space to device space. Let M
S
be the matrix specify-
ing the scaling and M
C
the current transformation matrix, which transforms user
space to device space. Recalling that coordinates are always specified in the trans-
ab0
cd0
ef1
x y 1[]xy1[]
ab0
cd0
ef1
×=
x ax× cy× e++=
y bx× dy× f++=
Coordinate SystemsSECTION 4.2
179
formed space, the correct order of transformations must first convert the scaled
coordinates to default user space and then the default user space coordinates to
device space. This can be expressed as
where
X
D
denotes the coordinates in device space
X
U
denotes the coordinates in default user space
X
S
denotes the coordinates in scaled user space
This shows that when a new transformation is concatenated with an existing one,
the matrix representing it must be multiplied before (premultiplied with) the
existing transformation matrix.
This result is true in general for PDF: when a sequence of transformations is car-
ried out, the matrix representing the combined transformation (M) is calculated
by premultiplying the matrix representing the additional transformation (M
T
)
with the one representing all previously existing transformations (M):
Note: When rendering graphics objects, it is sometimes necessary for an application
to perform the inverse of a transformation—that is, to find the user space coordi-
nates that correspond to a given pair of device space coordinates. Not all transfor-
mations are invertible, however. For example, if a matrix contains a, b, c, and d
elements that are all zero, all user coordinates map to the same device coordinates
and there is no unique inverse transformation. Such noninvertible transformations
are not very useful and generally arise from unintended operations, such as scaling
by 0. Use of a noninvertible matrix when painting graphics objects can result in un-
predictable behavior.
X
D
X
U
M
C
× X
S
M
S
×()M
C
× X
S
M
S
M
C
×()×== =
M M
T
M×=
GraphicsCHAPTER 4
180
4.3 Graphics State
A PDF consumer application maintains an internal data structure called the
graphics state that holds current graphics control parameters. These parameters
define the global framework within which the graphics operators execute. For ex-
ample, the
f (fill) operator implicitly uses the current color parameter, and the S
(stroke) operator additionally uses the current line width parameter from the
graphics state.
The graphics state is initialized at the beginning of each page with the values
specified in Tables 4.2 and 4.3. Table 4.2 lists those graphics state parameters that
are device-independent and are appropriate to specify in page descriptions. The
parameters listed in Table 4.3 control details of the rendering (scan conversion)
process and are device-dependent; a page description that is intended to be de-
vice-independent should not modify these parameters.
TABLE 4.2 Device-independent graphics state parameters
PARAMETER TYPE VALUE
CTM array The current transformation matrix, which maps positions from user
coordinates to device coordinates (see Section 4.2, “Coordinate Sys-
tems”). This matrix is modified by each application of the coordi-
nate transformation operator,
cm. Initial value: a matrix that
transforms default user coordinates to device coordinates.
clipping path (internal) The current clipping path, which defines the boundary against
which all output is to be cropped (see Section 4.4.3, “Clipping Path
Operators”). Initial value: the boundary of the entire imageable
portion of the output page.
color space name or array The current color space in which color values are to be interpreted
(see Section 4.5, “Color Spaces”). There are two separate color space
parameters: one for stroking and one for all other painting opera-
tions. Initial value:
DeviceGray.
color (various) The current color to be used during painting operations (see Section
4.5, “Color Spaces”). The type and interpretation of this parameter
depend on the current color space; for most color spaces, a color
value consists of one to four numbers. There are two separate color
parameters: one for stroking and one for all other painting opera-
tions. Initial value: black.
Graphics StateSECTION 4.3
181
text state (various) A set of nine graphics state parameters that pertain only to the
painting of text. These include parameters that select the font, scale
the glyphs to an appropriate size, and accomplish other effects. The
text state parameters are described in Section 5.2, “Text State
Parameters and Operators.”
line width number The thickness, in user space units, of paths to be stroked (see “Line
Width” on page 185). Initial value: 1.0.
line cap integer A code specifying the shape of the endpoints for any open path that
is stroked (see “Line Cap Style” on page 186). Initial value: 0, for
square butt caps.
line join integer A code specifying the shape of joints between connected segments
of a stroked path (see “Line Join Style” on page 186). Initial value: 0,
for mitered joins.
miter limit number The maximum length of mitered line joins for stroked paths (see
“Miter Limit” on page 187). This parameter limits the length of
“spikes” produced when line segments join at sharp angles. Initial
value: 10.0, for a miter cutoff below approximately 11.5 degrees.
dash pattern array and number A description of the dash pattern to be used when paths are stroked
(see “Line Dash Pattern” on page 187). Initial value: a solid line.
rendering intent name The rendering intent to be used when converting CIE-based colors
to device colors (see “Rendering Intents” on page 230). Initial value:
RelativeColorimetric.
stroke adjustment boolean (PDF 1.2) A flag specifying whether to compensate for possible ras-
terization effects when stroking a path with a line width that is
small relative to the pixel resolution of the output device (see Sec-
tion 6.5.4, “Automatic Stroke Adjustment”). Note that this is consid-
ered a device-independent parameter, even though the details of its
effects are device-dependent. Initial value:
false.
blend mode name or array (PDF 1.4) The current blend mode to be used in the transparent
imaging model (see Sections 7.2.4, “Blend Mode,” and 7.5.2, “Speci-
fying Blending Color Space and Blend Mode”). This parameter is
implicitly reset to its initial value at the beginning of execution of a
transparency group XObject (see Section 7.5.5, “Transparency
Group XObjects”). Initial value:
Normal.
PARAMETER TYPE VALUE
GraphicsCHAPTER 4
182
TABLE 4.3 Device-dependent graphics state parameters
soft mask dictionary
or name
(PDF 1.4) A soft-mask dictionary (see “Soft-Mask Dictionaries” on
page 520) specifying the mask shape or mask opacity values to be
used in the transparent imaging model (see “Source Shape and
Opacity” on page 495 and “Mask Shape and Opacity” on page 518),
or the name
None if no such mask is specified. This parameter is
implicitly reset to its initial value at the beginning of execution of a
transparency group XObject (see Section 7.5.5, “Transparency
Group XObjects”). Initial value:
None.
alpha constant number (PDF 1.4) The constant shape or constant opacity value to be used
in the transparent imaging model (see “Source Shape and Opacity”
on page 495 and “Constant Shape and Opacity” on page 519). There
are two separate alpha constant parameters: one for stroking and
one for all other painting operations. This parameter is implicitly
reset to its initial value at the beginning of execution of a transpar-
ency group XObject (see Section 7.5.5, “Transparency Group
XObjects”). Initial value: 1.0.
alpha source boolean (PDF 1.4) A flag specifying whether the current soft mask and alpha
constant parameters are to be interpreted as shape values (
true) or
opacity values (
false). This flag also governs the interpretation of
the
SMask entry, if any, in an image dictionary (see Section 4.8.4,
“Image Dictionaries”). Initial value:
false.
PARAMETER TYPE VALUE
overprint boolean (PDF 1.2) A flag specifying (on output devices that support the
overprint control feature) whether painting in one set of colorants
should cause the corresponding areas of other colorants to be
erased (
false) or left unchanged (true); see Section 4.5.6, “Overprint
Control.” In PDF 1.3, there are two separate overprint parameters:
one for stroking and one for all other painting operations. Initial
value:
false.
overprint mode number (PDF 1.3) A code specifying whether a color component value of 0
in a
DeviceCMYK color space should erase that component (0) or
leave it unchanged (1) when overprinting (see Section 4.5.6, “Over-
print Control”). Initial value: 0.
PARAMETER TYPE VALUE
Graphics StateSECTION 4.3
183
Some graphics state parameters are set with specific PDF operators, some are set
by including a particular entry in a graphics state parameter dictionary, and some
can be specified either way. The current line width, for example, can be set either
with the
w operator or (in PDF 1.3) with the LW entry in a graphics state parame-
ter dictionary, whereas the current color is set only with specific operators, and
the current halftone is set only with a graphics state parameter dictionary. It is
expected that all future graphics state parameters will be specified with new
entries in the graphics state parameter dictionary rather than with new operators.
black generation function or name (PDF 1.2) A function that calculates the level of the black color
component to use when converting RGB colors to CMYK (see Sec-
tion 6.2.3, “Conversion from DeviceRGB to DeviceCMYK”). Initial
value: installation-dependent.
undercolor removal function or name (PDF 1.2) A function that calculates the reduction in the levels of
the cyan, magenta, and yellow color components to compensate for
the amount of black added by black generation (see Section 6.2.3,
“Conversion from DeviceRGB to DeviceCMYK”). Initial value: in-
stallation-dependent.
transfer function,
array, or name
(PDF 1.2) A function that adjusts device gray or color component
levels to compensate for nonlinear response in a particular output
device (see Section 6.3, “Transfer Functions”). Initial value:
installation-dependent.
halftone dictionary,
stream, or name
(PDF 1.2) A halftone screen for gray and color rendering, specified
as a halftone dictionary or stream (see Section 6.4, “Halftones”).
Initial value: installation-dependent.
flatness number The precision with which curves are to be rendered on the output
device (see Section 6.5.1, “Flatness Tolerance”). The value of this
parameter gives the maximum error tolerance, measured in output
device pixels; smaller numbers give smoother curves at the expense
of more computation and memory use. Initial value: 1.0.
smoothness number (PDF 1.3) The precision with which color gradients are to be ren-
dered on the output device (see Section 6.5.2, “Smoothness Toler-
ance”). The value of this parameter gives the maximum error
tolerance, expressed as a fraction of the range of each color compo-
nent; smaller numbers give smoother color transitions at the
expense of more computation and memory use. Initial value:
installation-dependent.
PARAMETER TYPE VALUE
GraphicsCHAPTER 4
184
In general, the operators that set graphics state parameters simply store them un-
changed for later use by the painting operators. However, some parameters have
special properties or behavior:
• Most parameters must be of the correct type or have values that fall within a
certain range.
• Parameters that are numeric values, such as the current color, line width, and
miter limit, are forced into valid range, if necessary. However, they are not ad-
justed to reflect capabilities of the raster output device, such as resolution or
number of distinguishable colors. Painting operators perform such adjust-
ments, but the adjusted values are not stored back into the graphics state.
• Paths are internal objects that are not directly represented in PDF.
Note: As indicated in Tables 4.2 and 4.3, some of the parameters—color space, color,
and overprint—have two values, one used for stroking (of paths and text objects)
and one for all other painting operations. The two parameter values can be set inde-
pendently, allowing for operations such as combined filling and stroking of the same
path with different colors. Except where noted, a term such as current color should
be interpreted to refer to whichever color parameter applies to the operation being
performed. When necessary, the individual color parameters are distinguished ex-
plicitly as the stroking color and the nonstroking color.
4.3.1 Graphics State Stack
A well-structured PDF document typically contains many graphical elements
that are essentially independent of each other and sometimes nested to multiple
levels. The graphics state stack allows these elements to make local changes to the
graphics state without disturbing the graphics state of the surrounding environ-
ment. The stack is a LIFO (last in, first out) data structure in which the contents
of the graphics state can be saved and later restored using the following operators:
• The q operator pushes a copy of the entire graphics state onto the stack.
• The Q operator restores the entire graphics state to its former value by popping
it from the stack.
These operators can be used to encapsulate a graphical element so that it can
modify parameters of the graphics state and later restore them to their previous
values. Occurrences of the
q and Q operators must be balanced within a given
Graphics StateSECTION 4.3
185
content stream (or within the sequence of streams specified in a page dictionary’s
Contents array).
4.3.2 Details of Graphics State Parameters
This section gives details of several of the device-independent graphics state pa-
rameters listed in Table 4.2.
Line Width
The line width parameter specifies the thickness of the line used to stroke a path.
It is a non-negative number expressed in user space units; stroking a path entails
painting all points whose perpendicular distance from the path in user space is
less than or equal to half the line width. The effect produced in device space
depends on the current transformation matrix (CTM) in effect at the time the
path is stroked. If the CTM specifies scaling by different factors in the horizontal
and vertical dimensions, the thickness of stroked lines in device space will vary
according to their orientation. The actual line width achieved can differ from the
requested width by as much as 2 device pixels, depending on the positions of lines
with respect to the pixel grid. Automatic stroke adjustment can be used to ensure
uniform line width; see Section 6.5.4, “Automatic Stroke Adjustment.”
A line width of 0 denotes the thinnest line that can be rendered at device resolu-
tion: 1 device pixel wide. However, some devices cannot reproduce 1-pixel lines,
and on high-resolution devices, they are nearly invisible. Since the results of ren-
dering such zero-width lines are device-dependent, their use is not recommend-
ed.
GraphicsCHAPTER 4
186
Line Cap Style
The line cap style specifies the shape to be used at the ends of open subpaths (and
dashes, if any) when they are stroked. Table 4.4 shows the possible values.
TABLE 4.4 Line cap styles
Line Join Style
The line join style specifies the shape to be used at the corners of paths that are
stroked. Table 4.5 shows the possible values. Join styles are significant only at
points where consecutive segments of a path connect at an angle; segments that
meet or intersect fortuitously receive no special treatment.
TABLE 4.5 Line join styles
STYLE APPEARANCE DESCRIPTION
0 Butt cap. The stroke is squared off at the endpoint of the path. There is no
projection beyond the end of the path.
1 Round cap. A semicircular arc with a diameter equal to the line width is
drawn around the endpoint and filled in.
2 Projecting square cap. The stroke continues beyond the endpoint of the path
for a distance equal to half the line width and is squared off.
STYLE APPEARANCE DESCRIPTION
0 Miter join. The outer edges of the strokes for the two segments are extended
until they meet at an angle, as in a picture frame. If the segments meet at too
sharp an angle (as defined by the miter limit parameter—see “Miter Limit,”
above), a bevel join is used instead.
1 Round join. An arc of a circle with a diameter equal to the line width is drawn
around the point where the two segments meet, connecting the outer edges of
the strokes for the two segments. This pieslice-shaped figure is filled in, pro-
ducing a rounded corner.
2 Bevel join. The two segments are finished with butt caps (see “Line Cap Style”
on page 186) and the resulting notch beyond the ends of the segments is filled
with a triangle.
Graphics StateSECTION 4.3
187
Note: The definition of round join was changed in PDF 1.5. In rare cases, the imple-
mentation of the previous specification could produce unexpected results.
Miter Limit
When two line segments meet at a sharp angle and mitered joins have been spec-
ified as the line join style, it is possible for the miter to extend far beyond the
thickness of the line stroking the path. The miter limit imposes a maximum on
the ratio of the miter length to the line width (see Figure 4.7). When the limit is
exceeded, the join is converted from a miter to a bevel.
The ratio of miter length to line width is directly related to the angle
between
the segments in user space by the following formula:
For example, a miter limit of 1.414 converts miters to bevels for
less than 90
degrees, a limit of 2.0 converts them for
less than 60 degrees, and a limit of 10.0
converts them for
less than approximately 11.5 degrees.
FIGURE 4.7 Miter length
Line Dash Pattern
The line dash pattern controls the pattern of dashes and gaps used to stroke paths.
It is specified by a dash array and a dash phase. The dash array’s elements are
numbers that specify the lengths of alternating dashes and gaps; the dash phase
miterLength
lineWidth
-----------------------------
1
2
---
sin
------------------=
Miter
length
Line width
GraphicsCHAPTER 4
188
specifies the distance into the dash pattern at which to start the dash. The ele-
ments of both the dash array and the dash phase are expressed in user space units.
Before beginning to stroke a path, the dash array is cycled through, adding up the
lengths of dashes and gaps. When the accumulated length equals the value speci-
fied by the dash phase, stroking of the path begins, and the dash array is used cy-
clically from that point onward. Table 4.6 shows examples of line dash patterns.
As can be seen from the table, an empty dash array and zero phase can be used to
restore the dash pattern to a solid line.
TABLE 4.6 Examples of line dash patterns
Dashed lines wrap around curves and corners just as solid stroked lines do. The
ends of each dash are treated with the current line cap style, and corners within
dashes are treated with the current line join style. A stroking operation takes no
measures to coordinate the dash pattern with features of the path; it simply dis-
penses dashes and gaps along the path in the pattern defined by the dash array.
When a path consisting of several subpaths is stroked, each subpath is treated in-
dependently—that is, the dash pattern is restarted and the dash phase is reapplied
to it at the beginning of each subpath.
4.3.3 Graphics State Operators
Table 4.7 shows the operators that set the values of parameters in the graphics
state. (See also the color operators listed in Table 4.24 and the text state operators
in Table 5.2 on page 368.)
DASH ARRAY
AND PHASE
APPEARANCE DESCRIPTION
[ ] 0
No dash; solid, unbroken lines
[3] 0
3 units on, 3 units off, …
[2] 1
1 on, 2 off, 2 on, 2 off, …
[2 1] 0
2 on, 1 off, 2 on, 1 off, …
[3 5] 6
2 off, 3 on, 5 off, 3 on, 5 off, …
[2 3] 11
1 on, 3 off, 2 on, 3 off, 2 on, …
Graphics StateSECTION 4.3
189
TABLE 4.7 Graphics state operators
4.3.4 Graphics State Parameter Dictionaries
While some parameters in the graphics state can be set with individual operators,
as shown in Table 4.7, others cannot. The latter can only be set with the generic
graphics state operator
gs (PDF 1.2). The operand supplied to this operator is the
OPERANDS OPERATOR DESCRIPTION
—
q
Save the current graphics state on the graphics state stack (see “Graphics
State Stack” on page 184).
—
Q
Restore the graphics state by removing the most recently saved state from
the stack and making it the current state (see “Graphics State Stack” on
page 184).
abcdef cm Modify the current transformation matrix (CTM) by concatenating the
specified matrix (see Section 4.2.1, “Coordinate Spaces”). Although the
operands specify a matrix, they are written as six separate numbers, not as
an array.
lineWidth
w
Set the line width in the graphics state (see “Line Width” on page 185).
lineCap
J
Set the line cap style in the graphics state (see “Line Cap Style” on page
186).
lineJoin
j
Set the line join style in the graphics state (see “Line Join Style” on page
186).
miterLimit
M
Set the miter limit in the graphics state (see “Miter Limit” on page 187).
dashArray dashPhase d Set the line dash pattern in the graphics state (see “Line Dash Pattern” on
page 187).
intent
ri
(PDF 1.1) Set the color rendering intent in the graphics state (see “Render-
ing Intents” on page 230).
flatness
i
Set the flatness tolerance in the graphics state (see Section 6.5.1, “Flatness
Tolerance”).
flatness is a number in the range 0 to 100; a value of 0 speci-
fies the output device’s default flatness tolerance.
dictName
gs
(PDF 1.2) Set the specified parameters in the graphics state. dictName is
the name of a graphics state parameter dictionary in the
ExtGState subdic-
tionary of the current resource dictionary (see the next section).
GraphicsCHAPTER 4
190
name of a graphics state parameter dictionary whose contents specify the values of
one or more graphics state parameters. This name is looked up in the
ExtGState
subdictionary of the current resource dictionary. (The name ExtGState, for
extended graphics state, is a vestige of earlier versions of PDF.)
Note: The graphics state parameter dictionary is also used by type 2 patterns, which
do not have a content stream in which the graphics state operators could be invoked
(see Section 4.6.3, “Shading Patterns”).
Each entry in the parameter dictionary specifies the value of an individual graph-
ics state parameter, as shown in Table 4.8. All entries need not be present for ev-
ery invocation of the
gs operator; the supplied parameter dictionary may include
any combination of parameter entries. The results of
gs are cumulative; parame-
ter values established in previous invocations persist until explicitly overridden.
Note that some parameters appear in both Tables 4.7 and 4.8; these parameters
can be set either with individual graphics state operators or with
gs. It is expected
that any future extensions to the graphics state will be implemented by adding
new entries to the graphics state parameter dictionary rather than by introducing
new graphics state operators.
TABLE 4.8 Entries in a graphics state parameter dictionary
KEY TYPE DESCRIPTION
Type
name (Optional) The type of PDF object that this dictionary describes; must be
ExtGState for a graphics state parameter dictionary.
LW
number (Optional; PDF 1.3) The line width (see “Line Width” on page 185).
LC
integer (Optional; PDF 1.3) The line cap style (see “Line Cap Style” on page 186).
LJ
integer (Optional; PDF 1.3) The line join style (see “Line Join Style” on page 186).
ML
number (Optional; PDF 1.3) The miter limit (see “Miter Limit” on page 187).
D
array (Optional; PDF 1.3) The line dash pattern, expressed as an array of the form
[dashArray dashPhase], where dashArray is itself an array and dashPhase is an
integer (see “Line Dash Pattern” on page 187).
RI
name (Optional; PDF 1.3) The name of the rendering intent (see “Rendering
Intents” on page 230).
Graphics StateSECTION 4.3
191
OP
boolean (Optional) A flag specifying whether to apply overprint (see Section 4.5.6,
“Overprint Control”). In PDF 1.2 and earlier, there is a single overprint
parameter that applies to all painting operations. Beginning with PDF 1.3,
there are two separate overprint parameters: one for stroking and one for all
other painting operations. Specifying an
OP entry sets both parameters unless
there is also an
op entry in the same graphics state parameter dictionary, in
which case the
OP entry sets only the overprint parameter for stroking.
op
boolean (Optional; PDF 1.3) A flag specifying whether to apply overprint (see Section
4.5.6, “Overprint Control”) for painting operations other than stroking. If this
entry is absent, the
OP entry, if any, sets this parameter.
OPM
integer (Optional; PDF 1.3) The overprint mode (see Section 4.5.6, “Overprint Con-
trol”).
Font
array (Optional; PDF 1.3) An array of the form [font size], where font is an indirect
reference to a font dictionary and
size is a number expressed in text space
units. These two objects correspond to the operands of the
Tf operator (see
Section 5.2, “Text State Parameters and Operators”); however, the first oper-
and is an indirect object reference instead of a resource name.
BG
function (Optional) The black-generation function, which maps the interval [0.0 1.0]
to the interval [0.0 1.0] (see Section 6.2.3, “Conversion from DeviceRGB to
DeviceCMYK”).
BG2
function or name (Optional; PDF 1.3) Same as BG except that the value may also be the name
Default, denoting the black-generation function that was in effect at the start
of the page. If both
BG and BG2 are present in the same graphics state param-
eter dictionary,
BG2 takes precedence.
UCR
function (Optional) The undercolor-removal function, which maps the interval
[0.0 1.0] to the interval [1.0 1.0] (see Section 6.2.3, “Conversion from
DeviceRGB to DeviceCMYK”).
UCR2
function or name (Optional; PDF 1.3) Same as UCR except that the value may also be the name
Default, denoting the undercolor-removal function that was in effect at the
start of the page. If both
UCR and UCR2 are present in the same graphics state
parameter dictionary,
UCR2 takes precedence.
KEY TYPE DESCRIPTION
GraphicsCHAPTER 4
192
TR
function, array, or
name
(Optional) The transfer function, which maps the interval [0.0 1.0] to the in-
terval [0.0 1.0] (see Section 6.3, “Transfer Functions”). The value is either a
single function (which applies to all process colorants) or an array of four
functions (which apply to the process colorants individually). The name
Identity may be used to represent the identity function.
TR2
function, array, or
name
(Optional; PDF 1.3) Same as TR except that the value may also be the name
Default, denoting the transfer function that was in effect at the start of the
page. If both
TR and TR2 are present in the same graphics state parameter dic-
tionary,
TR2 takes precedence.
HT
dictionary, stream,
or name
(Optional) The halftone dictionary or stream (see Section 6.4, “Halftones”) or
the name
Default, denoting the halftone that was in effect at the start of the
page.
FL
number (Optional; PDF 1.3) The flatness tolerance (see Section 6.5.1, “Flatness Toler-
ance”).
SM
number (Optional; PDF 1.3) The smoothness tolerance (see Section 6.5.2, “Smooth-
ness Tolerance”).
SA
boolean (Optional) A flag specifying whether to apply automatic stroke adjustment
(see Section 6.5.4, “Automatic Stroke Adjustment”).
BM
name or array (Optional; PDF 1.4) The current blend mode to be used in the transparent
imaging model (see Sections 7.2.4, “Blend Mode,” and 7.5.2, “Specifying
Blending Color Space and Blend Mode”).
SMask
dictionary or name (Optional; PDF 1.4) The current soft mask, specifying the mask shape or
mask opacity values to be used in the transparent imaging model (see
“Source Shape and Opacity” on page 495 and “Mask Shape and Opacity” on
page 518).
Note: Although the current soft mask is sometimes referred to as a “soft clip,”
altering it with the
gs operator completely replaces the old value with the new
one, rather than intersecting the two as is done with the current clipping path
parameter (see Section 4.4.3, “Clipping Path Operators”).
CA
number (Optional; PDF 1.4) The current stroking alpha constant, specifying the con-
stant shape or constant opacity value to be used for stroking operations in the
transparent imaging model (see “Source Shape and Opacity” on page 495 and
“Constant Shape and Opacity” on page 519).
ca
number (Optional; PDF 1.4) Same as CA, but for nonstroking operations.
KEY TYPE DESCRIPTION
Graphics StateSECTION 4.3
193
Example 4.1 shows two graphics state parameter dictionaries. In the first, auto-
matic stroke adjustment is turned on, and the dictionary includes a transfer func-
tion that inverts its value, f(x) = 1 x. In the second, overprint is turned off, and
the dictionary includes a parabolic transfer function, f(x) = (2x 1)
2
, with a sam-
ple of 21 values. The domain of the transfer function, [0.0 1.0], is mapped to
[0 20], and the range of the sample values, [0 255], is mapped to the range of
the transfer function, [0.0 1.0].
Example 4.1
10 0 obj % Page object
<< /Type /Page
/Parent 5 0 R
/Resources 20 0 R
/Contents 40 0 R
>>
endobj
20 0 obj % Resource dictionary for page
<< /ProcSet [/PDF /Text]
/Font << /F1 25 0 R >>
/ExtGState << /GS1 30 0 R
/GS2 35 0 R
>>
>>
endobj
30 0 obj % First graphics state parameter dictionary
<< /Type /ExtGState
/SA true
/TR 31 0 R
>>
endobj
AIS
boolean (Optional; PDF 1.4) The alpha source flag (“alpha is shape”), specifying
whether the current soft mask and alpha constant are to be interpreted as
shape values (
true) or opacity values (false).
TK
boolean (Optional; PDF 1.4) The text knockout flag, which determines the behavior of
overlapping glyphs within a text object in the transparent imaging model (see
Section 5.2.7, “Text Knockout”).
KEY TYPE DESCRIPTION
GraphicsCHAPTER 4
194
31 0 obj % First transfer function
<< /FunctionType 0
/Domain [0.0 1.0]
/Range [0.0 1.0]
/Size 2
/BitsPerSample 8
/Length 7
/Filter /ASCIIHexDecode
>>
stream
01 00 >
endstream
endobj
35 0 obj % Second graphics state parameter dictionary
<< /Type /ExtGState
/OP false
/TR 36 0 R
>>
endobj
36 0 obj % Second transfer function
<< /FunctionType 0
/Domain [0.0 1.0]
/Range [0.0 1.0]
/Size 21
/BitsPerSample 8
/Length 63
/Filter /ASCIIHexDecode
>>
stream
FF CE A3 7C 5B 3F 28 16 0A 02 00 02 0A 16 28 3F 5B 7C A3 CE FF >
endstream
endobj
4.4 Path Construction and Painting
Paths define shapes, trajectories, and regions of all sorts. They are used to draw
lines, define the shapes of filled areas, and specify boundaries for clipping other
graphics. The graphics state includes a current clipping path that defines the clip-
ping boundary for the current page. At the beginning of each page, the clipping
path is initialized to include the entire page.
Path Construction and PaintingSECTION 4.4
195
A path is composed of straight and curved line segments, which may connect to
one another or may be disconnected. A pair of segments are said to connect only
if they are defined consecutively, with the second segment starting where the first
one ends. Thus, the order in which the segments of a path are defined is signifi-
cant. Nonconsecutive segments that meet or intersect fortuitously are not consid-
ered to connect.
A path is made up of one or more disconnected subpaths, each comprising a se-
quence of connected segments. The topology of the path is unrestricted: it may be
concave or convex, may contain multiple subpaths representing disjoint areas,
and may intersect itself in arbitrary ways. The
h operator explicitly connects the
end of a subpath back to its starting point; such a subpath is said to be closed. A
subpath that has not been explicitly closed is open.
As discussed in Section 4.1, “Graphics Objects,” a path object is defined by a se-
quence of operators to construct the path, followed by one or more operators to
paint the path or to use it as a clipping boundary. PDF path operators fall into
three categories:
• Path construction operators (Section 4.4.1) define the geometry of a path. A
path is constructed by sequentially applying one or more of these operators.
• Path-painting operators (Section 4.4.2) end a path object, usually causing the
object to be painted on the current page in any of a variety of ways.
• Clipping path operators (Section 4.4.3), invoked immediately before a path-
painting operator, cause the path object also to be used for clipping of sub-
sequent graphics objects.
4.4.1 Path Construction Operators
A page description begins with an empty path and builds up its definition by in-
voking one or more path construction operators to add segments to it. The path
construction operators may be invoked in any sequence, but the first one invoked
must be
m or re to begin a new subpath. The path definition concludes with the
application of a path-painting operator such as
S, f, or b (see Section 4.4.2, “Path-
Painting Operators”); this operator may optionally be preceded by one of the
clipping path operators
W or W* (Section 4.4.3, “Clipping Path Operators”). Note
that the path construction operators do not place any marks on the page; only the
painting operators do that. A path definition is not complete until a path-painting
operator has been applied to it.
GraphicsCHAPTER 4
196
The path currently under construction is called the current path. In PDF (unlike
PostScript), the current path is not part of the graphics state and is not saved and
restored along with the other graphics state parameters. PDF paths are strictly in-
ternal objects with no explicit representation. Once a path has been painted, it is
no longer defined; there is then no current path until a new one is begun with the
m or re operator.
The trailing endpoint of the segment most recently added to the current path is
referred to as the current point. If the current path is empty, the current point is
undefined. Most operators that add a segment to the current path start at the cur-
rent point; if the current point is undefined, an error is generated.
Table 4.9 shows the path construction operators. All operands are numbers de-
noting coordinates in user space.
TABLE 4.9 Path construction operators
OPERANDS OPERATOR DESCRIPTION
xy
m
Begin a new subpath by moving the current point to coordinates
(
x, y), omitting any connecting line segment. If the previous path
construction operator in the current path was also
m, the new m
overrides it; no vestige of the previous m operation remains in the
path.
xy
l
(lowercase L) Append a straight line segment from the current point to the point
(
x, y). The new current point is (x, y).
x
1
y
1
x
2
y
2
x
3
y
3
c Append a cubic Bézier curve to the current path. The curve extends
from the current point to the point (
x
3
, y
3
), using (x
1
, y
1
) and
(
x
2
, y
2
) as the Bézier control points (see “Cubic Bézier Curves,” be-
low). The new current point is (
x
3
, y
3
).
x
2
y
2
x
3
y
3
v Append a cubic Bézier curve to the current path. The curve extends
from the current point to the point (
x
3
, y
3
), using the current point
and (
x
2
, y
2
) as the Bézier control points (see “Cubic Bézier Curves,”
below). The new current point is (
x
3
, y
3
).
x
1
y
1
x
3
y
3
y Append a cubic Bézier curve to the current path. The curve extends
from the current point to the point (
x
3
, y
3
), using (x
1
, y
1
) and
(
x
3
, y
3
) as the Bézier control points (see “Cubic Bézier Curves,” be-
low). The new current point is (
x
3
, y
3
).
Path Construction and PaintingSECTION 4.4
197
Cubic Bézier Curves
Curved path segments are specified as cubic Bézier curves. Such curves are de-
fined by four points: the two endpoints (the current point P
0
and the final point
P
3
) and two control points P
1
and P
2
. Given the coordinates of the four points, the
curve is generated by varying the parameter t from 0.0 to 1.0 in the following
equation:
When t = 0.0, the value of the function R(t) coincides with the current point P
0
;
when t = 1.0, R(t) coincides with the final point P
3
. Intermediate values of t gen-
erate intermediate points along the curve. The curve does not, in general, pass
through the two control points P
1
and P
2
.
—
h
Close the current subpath by appending a straight line segment
from the current point to the starting point of the subpath. If the
current subpath is already closed,
h does nothing.
This operator terminates the current subpath. Appending another
segment to the current path begins a new subpath, even if the new
segment begins at the endpoint reached by the
h operation.
x y width height
re
Append a rectangle to the current path as a complete subpath, with
lower-left corner (
x, y) and dimensions width and height in user
space. The operation
x y width height re
is equivalent to
xym
(x + width ) y l
(x + width )(y + height)l
x (y + height )l
h
OPERANDS OPERATOR DESCRIPTION
Rt() 1 t–()
3
P
0
3t 1 t–()
2
P
1
3t
2
1 t–()P
2
t
3
P
3
+++=
GraphicsCHAPTER 4
198
Cubic Bézier curves have two useful properties:
• The curve can be very quickly split into smaller pieces for rapid rendering.
• The curve is contained within the convex hull of the four points defining the
curve, most easily visualized as the polygon obtained by stretching a rubber
band around the outside of the four points. This property allows rapid testing
of whether the curve lies completely outside the visible region, and hence does
not have to be rendered.
The Bibliography lists several books that describe cubic Bézier curves in more
depth.
The most general PDF operator for constructing curved path segments is the
c
operator, which specifies the coordinates of points P
1
, P
2
, and P
3
explicitly, as
shown in Figure 4.8. (The starting point, P
0
, is defined implicitly by the current
point.)
FIGURE 4.8 Cubic Bézier curve generated by the c operator
x
1
y
1
x
2
y
2
x
3
y
3
c
P
0
(current point)
P
2
(x
2
, y
2
)
P
3
(x
3
, y
3
)
P
1
(x
1
, y
1
)
Path Construction and PaintingSECTION 4.4
199
Two more operators, v and y, each specify one of the two control points implic-
itly (see Figure 4.9). In both of these cases, one control point and the final point
of the curve are supplied as operands; the other control point is implied:
• For the v operator, the first control point coincides with initial point of the
curve.
• For the y operator, the second control point coincides with final point of the
curve.
FIGURE 4.9 Cubic Bézier curves generated by the v and y operators
4.4.2 Path-Painting Operators
The path-painting operators end a path object, causing it to be painted on the
current page in the manner that the operator specifies. The principal path-
painting operators are
S (for stroking) and f (for filling). Variants of these opera-
tors combine stroking and filling in a single operation or apply different rules for
determining the area to be filled. Table 4.10 lists all the path-painting operators.
x
2
y
2
x
3
y
3
v
Current point
(x
2
,
y
2
)
(x
3
,
y
3
)
x
1
y
1
x
3
y
3
y
Current point
(x
1
,
y
1
)
(x
3
,
y
3
)
GraphicsCHAPTER 4
200
TABLE 4.10 Path-painting operators
OPERANDS OPERATOR DESCRIPTION
—
S
Stroke the path.
—
s
Close and stroke the path. This operator has the same effect as the sequence h S.
—
f
Fill the path, using the nonzero winding number rule to determine the region to fill
(see “Nonzero Winding Number Rule” on page 202). Any subpaths that are open are
implicitly closed before being filled.
—
F
Equivalent to f; included only for compatibility. Although PDF consumer applica-
tions must be able to accept this operator, PDF producer applications should use
f
instead.
—
f*
Fill the path, using the even-odd rule to determine the region to fill (see “Even-Odd
Rule” on page 203).
—
B
Fill and then stroke the path, using the nonzero winding number rule to determine
the region to fill. This operator produces the same result as constructing two identi-
cal path objects, painting the first with
f and the second with S. Note, however, that
the filling and stroking portions of the operation consult different values of several
graphics state parameters, such as the current color. See also “Special Path-Painting
Considerations” on page 538.
—
B*
Fill and then stroke the path, using the even-odd rule to determine the region to fill.
This operator produces the same result as
B, except that the path is filled as if with
f* instead of f. See also “Special Path-Painting Considerations” on page 538.
—
b
Close, fill, and then stroke the path, using the nonzero winding number rule to de-
termine the region to fill. This operator has the same effect as the sequence
h B. See
also “Special Path-Painting Considerations” on page 538.
—
b*
Close, fill, and then stroke the path, using the even-odd rule to determine the re-
gion to fill. This operator has the same effect as the sequence
h B*. See also “Special
Path-Painting Considerations” on page 538.
—
n
End the path object without filling or stroking it. This operator is a path-painting
no-op, used primarily for the side effect of changing the current clipping path (see
Section 4.4.3, “Clipping Path Operators”).
Path Construction and PaintingSECTION 4.4
201
Stroking
The S operator paints a line along the current path. The stroked line follows each
straight or curved segment in the path, centered on the segment with sides paral-
lel to it. Each of the path’s subpaths is treated separately.
The results of the
S operator depend on the current settings of various parameters
in the graphics state (see Section 4.3, “Graphics State,” for further information on
these parameters):
• The width of the stroked line is determined by the current line width parameter
(“Line Width” on page 185).
• The color or pattern of the line is determined by the current color and color
space for stroking operations.
• The line can be painted either solid or with a dash pattern, as specified by the
current line dash pattern (“Line Dash Pattern” on page 187).
• If a subpath is open, the unconnected ends are treated according to the current
line cap style, which may be butt, rounded, or square (“Line Cap Style” on page
186).
• Wherever two consecutive segments are connected, the joint between them is
treated according to the current line join style, which may be mitered, rounded,
or beveled (“Line Join Style” on page 186). Mitered joins are also subject to the
current miter limit (“Miter Limit” on page 187).
Note: Points at which unconnected segments happen to meet or intersect receive
no special treatment. In particular, using an explicit
l operator to give the appear-
ance of closing a subpath, rather than using
h, may result in a messy corner, be-
cause line caps are applied instead of a line join.
• The stroke adjustment parameter (PDF 1.2) specifies that coordinates and line
widths be adjusted automatically to produce strokes of uniform thickness
despite rasterization effects (Section 6.5.4, “Automatic Stroke Adjustment”).
If a subpath is degenerate (consists of a single-point closed path or of two or
more points at the same coordinates), the
S operator paints it only if round line
caps have been specified, producing a filled circle centered at the single point. If
butt or projecting square line caps have been specified,
S produces no output, be-
cause the orientation of the caps would be indeterminate. (This rule applies only
to zero-length subpaths of the path being stroked, and not to zero-length dashes
GraphicsCHAPTER 4
202
in a dash pattern. In the latter case, the line caps are always painted, since their
orientation is determined by the direction of the underlying path.) A single-
point open subpath (specified by a trailing
m operator) produces no output.
Filling
The f operator uses the current nonstroking color to paint the entire region en-
closed by the current path. If the path consists of several disconnected subpaths,
f
paints the insides of all subpaths, considered together. Any subpaths that are open
are implicitly closed before being filled.
If a subpath is degenerate (consists of a single-point closed path or of two or more
points at the same coordinates),
f paints the single device pixel lying under that
point; the result is device-dependent and not generally useful. A single-point
open subpath (specified by a trailing
m operator) produces no output.
For a simple path, it is intuitively clear what region lies inside. However, for a
more complex path—for example, a path that intersects itself or has one subpath
that encloses another—it is not always obvious which points lie inside the path.
The path machinery uses one of two rules for determining which points lie inside
a path: the nonzero winding number rule and the even-odd rule, both discussed in
detail below.
The nonzero winding number rule is more versatile than the even-odd rule and is
the standard rule the
f operator uses. Similarly, the W operator uses this rule to
determine the inside of the current clipping path. The even-odd rule is occasion-
ally useful for special effects or for compatibility with other graphics systems; the
f* and W* operators invoke this rule.
Nonzero Winding Number Rule
The nonzero winding number rule determines whether a given point is inside a
path by conceptually drawing a ray from that point to infinity in any direction
and then examining the places where a segment of the path crosses the ray. Start-
ing with a count of 0, the rule adds 1 each time a path segment crosses the ray
from left to right and subtracts 1 each time a segment crosses from right to left.
After counting all the crossings, if the result is 0, the point is outside the path;
otherwise, it is inside.
Path Construction and PaintingSECTION 4.4
203
Note: The method just described does not specify what to do if a path segment coin-
cides with or is tangent to the chosen ray. Since the direction of the ray is arbitrary,
the rule simply chooses a ray that does not encounter such problem intersections.
For simple convex paths, the nonzero winding number rule defines the inside
and outside as one would intuitively expect. The more interesting cases are those
involving complex or self-intersecting paths like the ones shown in Figure 4.10.
For a path consisting of a five-pointed star, drawn with five connected straight
line segments intersecting each other, the rule considers the inside to be the entire
area enclosed by the star, including the pentagon in the center. For a path com-
posed of two concentric circles, the areas enclosed by both circles are considered
to be inside, provided that both are drawn in the same direction. If the circles are
drawn in opposite directions, only the doughnut shape between them is inside,
according to the rule; the doughnut hole is outside.
FIGURE 4.10 Nonzero winding number rule
Even-Odd Rule
An alternative to the nonzero winding number rule is the even-odd rule. This rule
determines whether a point is inside a path by drawing a ray from that point in
any direction and simply counting the number of path segments that cross the
ray, regardless of direction. If this number is odd, the point is inside; if even, the
point is outside. This yields the same results as the nonzero winding number rule
for paths with simple shapes, but produces different results for more complex
shapes.
Figure 4.11 shows the effects of applying the even-odd rule to complex paths. For
the five-pointed star, the rule considers the triangular points to be inside the path,
GraphicsCHAPTER 4
204
but not the pentagon in the center. For the two concentric circles, only the dough-
nut shape between the two circles is considered inside, regardless of the direc-
tions in which the circles are drawn.
FIGURE 4.11 Even-odd rule
4.4.3 Clipping Path Operators
The graphics state contains a current clipping path that limits the regions of the
page affected by painting operators. The closed subpaths of this path define the
area that can be painted. Marks falling inside this area are applied to the page;
those falling outside it are not. (“Filling” on page 202 discusses precisely what is
considered to be inside a path.)
Note: In the context of the transparent imaging model (PDF 1.4), the current clip-
ping path constrains an object’s shape (see Section 7.1, “Overview of Transparency”).
The effective shape is the intersection of the object’s intrinsic shape with the clipping
path; the source shape value is 0.0 outside this intersection. Similarly, the shape of a
transparency group (defined as the union of the shapes of its constituent objects) is
influenced both by the clipping path in effect when each of the objects is painted and
by the one in effect at the time the group’s results are painted onto its backdrop.
The initial clipping path includes the entire page. A clipping path operator (
W or
W*, shown in Table 4.11) may appear after the last path construction operator
and before the path-painting operator that terminates a path object. Although the
clipping path operator appears before the painting operator, it does not alter the
clipping path at the point where it appears. Rather, it modifies the effect of the
succeeding painting operator. After the path has been painted, the clipping path
in the graphics state is set to the intersection of the current clipping path and the
newly constructed path.
Color SpacesSECTION 4.5
205
TABLE 4.11 Clipping path operators
Note: In addition to path objects, text objects can also be used for clipping; see Sec-
tion 5.2.5, “Text Rendering Mode.”
The
n operator (see Table 4.10) is a no-op path-painting operator; it causes no
marks to be placed on the page, but can be used with a clipping path operator to
establish a new clipping path. That is, after a path has been constructed, the se-
quence
W n intersects that path with the current clipping path to establish a new
clipping path.
There is no way to enlarge the current clipping path or to set a new clipping path
without reference to the current one. However, since the clipping path is part of
the graphics state, its effect can be localized to specific graphics objects by en-
closing the modification of the clipping path and the painting of those objects
between a pair of
q and Q operators (see Section 4.3.1, “Graphics State Stack”).
Execution of the
Q operator causes the clipping path to revert to the value that
was saved by the
q operator before the clipping path was modified.
4.5 Color Spaces
PDF includes powerful facilities for specifying the colors of graphics objects to be
painted on the current page. The color facilities are divided into two parts:
• Color specification. A PDF file can specify abstract colors in a device-
independent way. Colors can be described in any of a variety of color systems,
or color spaces. Some color spaces are related to device color representation
(grayscale, RGB, CMYK), others to human visual perception (CIE-based). Cer-
tain special features are also modeled as color spaces: patterns, color mapping,
separations, and high-fidelity and multitone color.
OPERANDS OPERATOR DESCRIPTION
—
W
Modify the current clipping path by intersecting it with the current path, using the
nonzero winding number rule to determine which regions lie inside the clipping
path.
—
W*
Modify the current clipping path by intersecting it with the current path, using the
even-odd rule to determine which regions lie inside the clipping path.
GraphicsCHAPTER 4
206
• Color rendering. The application reproduces colors on the raster output device
by a multiple-step process that includes some combination of color conversion,
gamma correction, halftoning, and scan conversion. Some aspects of this pro-
cess use information that is specified in PDF. However, unlike the facilities for
color specification, the color-rendering facilities are device-dependent and or-
dinarily should not be included in a page description.
Figures 4.12 and 4.13 on pages 208 and 209 illustrate the division between PDF’s
(device-independent) color specification and (device-dependent) color-render-
ing facilities. This section describes the color specification features, covering
everything that most PDF documents need to specify colors. The facilities for
controlling color rendering are described in Chapter 6; a PDF document should
use these facilities only to configure or calibrate an output device or to achieve
special device-dependent effects.
4.5.1 Color Values
As described in Section 4.4.2, “Path-Painting Operators,” marks placed on the
page by operators such as
f and S have a color that is determined by the current
color parameter of the graphics state. A color value consists of one or more color
components, which are usually numbers. For example, a gray level can be speci-
fied by a single number ranging from 0.0 (black) to 1.0 (white). Full color values
can be specified in any of several ways; a common method uses three numeric
values to specify red, green, and blue components.
Color values are interpreted according to the current color space, another pa-
rameter of the graphics state. A PDF content stream first selects a color space by
invoking the
CS operator (for the stroking color) or the cs operator (for the non-
stroking color). It then selects color values within that color space with the
SC
operator (stroking) or the sc operator (nonstroking). There are also conve-
nience operators—
G, g, RG, rg, K, and k—that select both a color space and a
color value within it in a single step. Table 4.24 on page 257 lists all the color-
setting operators.
Sampled images (see Section 4.8, “Images”) specify the color values of individual
samples with respect to a color space designated by the image object itself. While
these values are independent of the current color space and color parameters in
the graphics state, all later stages of color processing treat them in exactly the
same way as color values specified with the
SC or sc operator.
Color SpacesSECTION 4.5
207
4.5.2 Color Space Families
Color spaces can be classified into color space families. Spaces within a family
share the same general characteristics; they are distinguished by parameter values
supplied at the time the space is specified. The families fall into three broad cate-
gories:
• Device color spaces directly specify colors or shades of gray that the output
device is to produce. They provide a variety of color specification methods,
including grayscale, RGB (red-green-blue), and CMYK (cyan-magenta-yellow-
black), corresponding to the color space families
DeviceGray, DeviceRGB, and
DeviceCMYK. Since each of these families consists of just a single color space
with no parameters, they are often loosely referred to as the
DeviceGray,
DeviceRGB, and DeviceCMYK color spaces.
• CIE-based color spaces are based on an international standard for color specifi-
cation created by the Commission Internationale de l’Éclairage (International
Commission on Illumination). These spaces specify colors in a way that is in-
dependent of the characteristics of any particular output device. Color space
families in this category include
CalGray, CalRGB, Lab, and ICCBased. Individu-
al color spaces within these families are specified by means of dictionaries con-
taining the parameter values needed to define the space.
• Special color spaces add features or properties to an underlying color space.
They include facilities for patterns, color mapping, separations, and high-
fidelity and multitone color. The corresponding color space families are
Pattern, Indexed, Separation, and DeviceN. Individual color spaces within
these families are specified by means of additional parameters.
Table 4.12 summarizes the color space families supported by PDF. (See imple-
mentation note 46 in Appendix H.)
TABLE 4.12 Color space families
DEVICE CIE-BASED SPECIAL
DeviceGray (PDF 1.1) CalGray (PDF 1.1) Indexed (PDF 1.1)
DeviceRGB (PDF 1.1) CalRGB (PDF 1.1) Pattern (PDF 1.2)
DeviceCMYK (PDF 1.1) Lab (PDF 1.1) Separation (PDF 1.2)
ICCBased (PDF 1.3) DeviceN (PDF 1.3)
GraphicsCHAPTER 4
208
FIGURE 4.12 Color specification
Color spaces Color values
Sources of
color values
CalRGB
Conversion
to internal
X, Y, Z
values
A, B, C
X, Y, Z
sc, SC, sh,
BI, Do (image XObject)
Alternative
color
transform
tint
Another
color space
scn, SCN, sh,
BI, Do (image XObject)
Indexed
Table
lookup
Another
color space
CIE-
based
color
spaces
Device
color
spaces
Special
color
spaces
Pattern
sc, SC, sh,
BI, Do (image XObject)
scn, SCN
Another
color space
Pattern
dictionary
CalGray
A
sc, SC, sh,
BI, Do (image XObject)
index
pattern
Separation
Lab
A, B, C
sc, SC, sh,
BI, Do (image XObject)
ICCBased
scn, SCN, sh,
BI, Do (image XObject)
DeviceCMYK
C, M, Y, K
k, K, sc, SC, sh,
BI, Do (image XObject)
Another
(4-component)
color space
DeviceGray
gray
g, G, sc, SC, sh,
BI, Do (image XObject)
Another
(1-component)
color space
Alternative
color
transform
n
components
Another
color space
scn, SCN, sh,
BI, Do (image XObject)
DeviceN
DeviceRGB
rg, RG, sc, SC, sh,
BI, Do (image XObject)
R, G, B
DefaultCMYK
DefaultGray
DefaultRGB
Another
(3-component)
color space
n
components
Color SpacesSECTION 4.5
209
FIGURE 4.13 Color rendering
Conversion
from CIE-based
to device
color space
R, G, B
C, M, Y, K
gray
Device color values
(depending on
results of
conversion)
R, G, B
C, M, Y, K
Conversion
from input
device color
space to
device’s
process color
model
Transfer
functions
(per
component)
Halftones
(per
component)
Any single
device
colorant
Device’s
process
colorant(s)
UCR, BG
TR, HT HT
X, Y, Z
gray
tint
(not specified by PDF)
n
components
Any n device
colorants
Component(s)
of device’s
process
color model
GraphicsCHAPTER 4
210
A color space is defined by an array object whose first element is a name object
identifying the color space family. The remaining array elements, if any, are
parameters that further characterize the color space; their number and types vary
according to the particular family. For families that do not require parameters,
the color space can be specified simply by the family name itself instead of an
array.
A color space can be specified in two principal ways:
• Within a content stream, the CS or cs operator establishes the current color
space parameter in the graphics state. The operand is always a name object,
which either identifies one of the color spaces that need no additional parame-
ters (
DeviceGray, DeviceRGB, DeviceCMYK, or some cases of Pattern) or is used
as a key in the
ColorSpace subdictionary of the current resource dictionary (see
Section 3.7.2, “Resource Dictionaries”). In the latter case, the value of the dic-
tionary entry is in turn a color space array or name. A color space array is never
permitted inline within a content stream.
• Outside a content stream, certain objects, such as image XObjects, specify a
color space as an explicit parameter, often associated with the key
ColorSpace.
In this case, the color space array or name is always defined directly as a PDF
object, not by an entry in the
ColorSpace resource subdictionary. This conven-
tion also applies when color spaces are defined in terms of other color spaces.
The following operators set the current color space and current color parameters
in the graphics state:
• CS sets the stroking color space; cs sets the nonstroking color space.
• SC and SCN set the stroking color; sc and scn set the nonstroking color. De-
pending on the color space, these operators require one or more operands, each
specifying one component of the color value.
• G, RG, and K set the stroking color space implicitly and the stroking color as
specified by the operands;
g, rg, and k do the same for the nonstroking color
space and color.
Color SpacesSECTION 4.5
211
4.5.3 Device Color Spaces
The device color spaces enable a page description to specify color values that are
directly related to their representation on an output device. Color values in these
spaces map directly (or by simple conversions) to the application of device colo-
rants, such as quantities of ink or intensities of display phosphors. This enables a
PDF document to control colors precisely for a particular device, but the results
may not be consistent from one device to another.
Output devices form colors either by adding light sources together or by subtract-
ing light from an illuminating source. Computer displays and film recorders typi-
cally add colors; printing inks typically subtract them. These two ways of forming
colors give rise to two complementary methods of color specification, called ad-
ditive and subtractive color (see Plate 1). The most widely used forms of these two
types of color specification are known as RGB and CMYK, respectively, for the
names of the primary colors on which they are based. They correspond to the fol-
lowing device color spaces:
• DeviceGray controls the intensity of achromatic light, on a scale from black to
white.
• DeviceRGB controls the intensities of red, green, and blue light, the three addi-
tive primary colors used in displays.
• DeviceCMYK controls the concentrations of cyan, magenta, yellow, and black
inks, the four subtractive process colors used in printing.
Although the notion of explicit color spaces is a PDF 1.1 feature, the operators for
specifying colors in the device color spaces—
G, g, RG, rg, K, and k—are available
in all versions of PDF. Beginning with PDF 1.2, colors specified in device color
spaces can optionally be remapped systematically into other color spaces; see
“Default Color Spaces” on page 227.
Note: In the transparent imaging model (PDF 1.4), the use of device color spaces is
subject to special treatment within a transparency group whose group color space is
CIE-based (see Sections 7.3, “Transparency Groups,” and 7.5.5, “Transparency
Group XObjects”). In particular, the device color space operators should be used
only if device color spaces have been remapped to CIE-based spaces by means of the
default color space mechanism. Otherwise, the results are implementation-
dependent and unpredictable.
GraphicsCHAPTER 4
212
DeviceGray Color Space
Black, white, and intermediate shades of gray are special cases of full color. A
grayscale value is represented by a single number in the range 0.0 to 1.0, where
0.0 corresponds to black, 1.0 to white, and intermediate values to different gray
levels. Example 4.2 shows alternative ways to select the
DeviceGray color space
and a specific gray level within that space for stroking operations.
Example 4.2
/DeviceGray CS % Set DeviceGray color space
gray SC % Set gray level
gray G % Set both in one operation
The CS and SC operators select the current stroking color space and current
stroking color separately;
G sets them in combination. (The cs, sc, and g opera-
tors perform the same functions for nonstroking operations.) Setting either cur-
rent color space to
DeviceGray initializes the corresponding current color to 0.0.
DeviceRGB Color Space
Colors in the DeviceRGB color space are specified according to the additive RGB
(red-green-blue) color model, in which color values are defined by three compo-
nents representing the intensities of the additive primary colorants red, green,
and blue. Each component is specified by a number in the range 0.0 to 1.0, where
0.0 denotes the complete absence of a primary component and 1.0 denotes maxi-
mum intensity. If all three components have equal intensity, the perceived result
theoretically is a pure gray on the scale from black to white. If the intensities are
not all equal, the result is some color other than a pure gray.
Example 4.3 shows alternative ways to select the
DeviceRGB color space and a
specific color within that space for stroking operations.
Example 4.3
/DeviceRGB CS % Set DeviceRGB color space
red green blue SC % Set color
red green blue RG % Set both in one operation
Color SpacesSECTION 4.5
213
The CS and SC operators select the current stroking color space and current
stroking color separately;
RG sets them in combination. (The cs, sc, and rg opera-
tors perform the same functions for nonstroking operations.) Setting either cur-
rent color space to
DeviceRGB initializes the red, green, and blue components of
the corresponding current color to 0.0.
DeviceCMYK Color Space
The DeviceCMYK color space allows colors to be specified according to the sub-
tractive CMYK (cyan-magenta-yellow-black) model typical of printers and other
paper-based output devices. In theory, each of the three standard process colorants
used in printing (cyan, magenta, and yellow) absorbs one of the additive primary
colors (red, green, and blue, respectively). Black, a fourth standard process colo-
rant, absorbs all of the additive primaries in equal amounts. The four components
in a
DeviceCMYK color value represent the concentrations of these process colo-
rants. Each component is specified by a number in the range 0.0 to 1.0, where 0.0
denotes the complete absence of a process colorant (that is, absorbs none of the
corresponding additive primary) and 1.0 denotes maximum concentration (ab-
sorbs as much as possible of the additive primary). Note that the sense of these
numbers is opposite to that of RGB color components.
Example 4.4 shows alternative ways to select the
DeviceCMYK color space and a
specific color within that space for stroking operations.
Example 4.4
/DeviceCMYK CS % Set DeviceCMYK color space
cyan magenta yellow black SC % Set color
cyan magenta yellow black K % Set both in one operation
The CS and SC operators select the current stroking color space and current strok-
ing color separately;
K sets them in combination. (The cs, sc, and k operators per-
form the same functions for nonstroking operations.) Setting either current color
space to
DeviceCMYK initializes the cyan, magenta, and yellow components of the
corresponding current color to 0.0 and the black component to 1.0.
GraphicsCHAPTER 4
214
4.5.4 CIE-Based Color Spaces
Calibrated color in PDF is defined in terms of an international standard used in
the graphic arts, television, and printing industries. CIE-based color spaces enable
a page description to specify color values in a way that is related to human visual
perception. The goal is for the same color specification to produce consistent re-
sults on different output devices, within the limitations of each device; Plate 2 il-
lustrates the kind of variation in color reproduction that can result from the use
of uncalibrated color on different devices. PDF 1.1 supports three CIE-based col-
or space families, named
CalGray, CalRGB, and Lab; PDF 1.3 adds a fourth, named
ICCBased.
Note: In PDF 1.1, a color space family named
CalCMYK was partially defined, with
the expectation that its definition would be completed in a future version. However,
this is no longer being considered. PDF 1.3 and later versions support calibrated
four-component color spaces by means of ICC profiles (see “ICCBased Color Spaces”
on page 222). PDF consumer applications should ignore
CalCMYK color space at-
tributes and render colors specified in this family as if they had been specified using
DeviceCMYK.
The details of the CIE colorimetric system and the theory on which it is based are
beyond the scope of this book; see the Bibliography for sources of further in-
formation. The semantics of CIE-based color spaces are defined in terms of the
relationship between the space’s components and the tristimulus values X, Y, and
Z of the CIE 1931 XYZ space. The
CalRGB and Lab color spaces (PDF 1.1) are
special cases of three-component CIE-based color spaces, known as CIE-based
ABC color spaces. These spaces are defined in terms of a two-stage, nonlinear
transformation of the CIE 1931 XYZ space. The formulation of such color spaces
models a simple zone theory of color vision, consisting of a nonlinear trichro-
matic first stage combined with a nonlinear opponent-color second stage. This
formulation allows colors to be digitized with minimum loss of fidelity, an impor-
tant consideration in sampled images.
Color values in a CIE-based ABC color space have three components, arbitrarily
named A, B, and C. The first stage transforms these components by first forcing
their values to a specified range, then applying decoding functions, and then mul-
tiplying the results by a 3-by-3 matrix, producing three intermediate components
arbitrarily named L, M, and N. The second stage transforms these intermediate
components in a similar fashion, producing the final X, Y, and Z components of
the CIE 1931 XYZ space (see Figure 4.14).
Color SpacesSECTION 4.5
215
FIGURE 4.14 Component transformations in a CIE-based ABC color space
Color spaces in the CIE-based families are defined by an array
[name dictionary]
where name is the name of the family and dictionary is a dictionary containing
parameters that further characterize the space. The entries in this dictionary have
specific interpretations that depend on the color space; some entries are required
and some are optional. See the sections on specific color space families, below, for
details.
Setting the current stroking or nonstroking color space to any CIE-based color
space initializes all components of the corresponding current color to 0.0 (unless
the range of valid values for a given component does not include 0.0, in which
case the nearest valid value is substituted.)
Note: The model and terminology used here—CIE-based ABC (above) and CIE-
based A (below)—are derived from the PostScript language, which supports these
color space families in their full generality. PDF supports specific useful cases of CIE-
based ABC and CIE-based A spaces; most others can be represented as
ICCBased
spaces.
CalGray Color Spaces
A CalGray color space (PDF 1.1) is a special case of a single-component CIE-
based color space, known as a CIE-based A color space. This type of space is the
one-dimensional (and usually achromatic) analog of CIE-based ABC spaces.
Color values in a CIE-based A space have a single component, arbitrarily named
A. Figure 4.15 illustrates the transformations of the A component to X, Y, and Z
components of the CIE 1931 XYZ space.
Decode ABC
Decode LMN
A
B
C
Matrix ABC
L
M
N
Matrix LMN
X
Y
Z
GraphicsCHAPTER 4
216
FIGURE 4.15 Component transformations in a CIE-based A color space
A CalGray color space is a CIE-based A color space with only one transformation
stage instead of two. In this type of space, A represents the gray component of a
calibrated gray space. This component must be in the range 0.0 to 1.0. The decod-
ing function (denoted by “Decode A” in Figure 4.15) is a gamma function whose
coefficient is specified by the
Gamma entry in the color space dictionary (see Ta-
ble 4.13). The transformation matrix denoted by “Matrix A” in the figure is de-
rived from the dictionary’s
WhitePoint entry, as described below. Since there is no
second transformation stage, “Decode LMN” and “Matrix LMN” are implicitly
taken to be identity transformations.
TABLE 4.13 Entries in a CalGray color space dictionary
KEY TYPE VALUE
WhitePoint
array (Required) An array of three numbers [X
W
Y
W
Z
W
] specifying the tri-
stimulus value, in the CIE 1931 XYZ space, of the diffuse white point; see
“CalRGB Color Spaces,” below, for further discussion. The numbers X
W
and
Z
W
must be positive, and Y
W
must be equal to 1.0.
BlackPoint
array (Optional) An array of three numbers [X
B
Y
B
Z
B
] specifying the tristimulus
value, in the CIE 1931 XYZ space, of the diffuse black point; see “CalRGB
Color Spaces,” below, for further discussion. All three of these numbers must
be non-negative. Default value:
[0.0 0.0 0.0].
Gamma
number (Optional) A number G defining the gamma for the gray (A) component. G
must be positive and is generally greater than or equal to 1. Default value: 1.
Decode A
Decode LMN
A
L
M
N
Matrix A Matrix LMN
X
Y
Z
Color SpacesSECTION 4.5
217
The transformation defined by the Gamma and WhitePoint entries is
In other words, the A component is first decoded by the gamma function, and the
result is multiplied by the components of the white point to obtain the L, M, and
N components of the intermediate representation. Since there is no second stage,
the L, M, and N components are also the X, Y, and Z components of the final rep-
resentation.
The following examples illustrate interesting and useful special cases of
CalGray
spaces. Example 4.5 establishes a space consisting of the Y dimension of the CIE
1931 XYZ space with the CCIR XA/11–recommended D65 white point.
Example 4.5
[ /CalGray
<< /WhitePoint [0.9505 1.0000 1.0890] >>
]
Example 4.6 establishes a calibrated gray space with the CCIR XA/11–
recommended D65 white point and opto-electronic transfer function.
Example 4.6
[ /CalGray
<< /WhitePoint [0.9505 1.0000 1.0890]
/Gamma 2.222
>>
]
CalRGB Color Spaces
A CalRGB color space is a CIE-based ABC color space with only one transforma-
tion stage instead of two. In this type of space, A, B, and C represent calibrated
red, green, and blue color values. These three color components must be in the
range 0.0 to 1.0; component values falling outside that range are adjusted to the
nearest valid value without error indication. The decoding functions (denoted by
“Decode ABC” in Figure 4.14 on page 215) are gamma functions whose coeffi-
XL X
W
A
G
×==
YMY
W
A
G
×==
ZN Z
W
A
G
×==
GraphicsCHAPTER 4
218
cients are specified by the Gamma entry in the color space dictionary (see Table
4.14). The transformation matrix denoted by “Matrix ABC” in Figure 4.14 is de-
fined by the dictionary’s
Matrix entry. Since there is no second transformation
stage, “Decode LMN” and “Matrix LMN” are implicitly taken to be identity trans-
formations.
TABLE 4.14 Entries in a CalRGB color space dictionary
The WhitePoint and BlackPoint entries in the color space dictionary control the
overall effect of the CIE-based gamut mapping function described in Section 6.1,
“CIE-Based Color to Device Color.” Typically, the colors specified by
WhitePoint
and BlackPoint are mapped to the nearly lightest and nearly darkest achromatic
colors that the output device is capable of rendering in a way that preserves color
appearance and visual contrast.
WhitePoint is assumed to represent the diffuse achromatic highlight, not a specu-
lar highlight. Specular highlights, achromatic or otherwise, are often reproduced
lighter than the diffuse highlight.
BlackPoint is assumed to represent the diffuse
achromatic shadow; its value is typically limited by the dynamic range of the in-
put device. In images produced by a photographic system, the values of
WhitePoint and BlackPoint vary with exposure, system response, and artistic in-
tent; hence, their values are image-dependent.
KEY TYPE VALUE
WhitePoint
array (Required) An array of three numbers [X
W
Y
W
Z
W
] specifying the tristimulus value,
in the CIE 1931 XYZ space, of the diffuse white point; see below for further discus-
sion. The numbers X
W
and Z
W
must be positive, and Y
W
must be equal to 1.0.
BlackPoint
array (Optional) An array of three numbers [X
B
Y
B
Z
B
] specifying the tristimulus value, in
the CIE 1931 XYZ space, of the diffuse black point; see below for further discussion.
All three of these numbers must be non-negative. Default value:
[0.0 0.0 0.0].
Gamma
array (Optional) An array of three numbers [G
R
G
G
G
B
] specifying the gamma for the red,
green, and blue (A, B, and C) components of the color space. Default value:
[1.0 1.0 1.0].
Matrix
array (Optional) An array of nine numbers [X
A
Y
A
Z
A
X
B
Y
B
Z
B
X
C
Y
C
Z
C
] specifying
the linear interpretation of the decoded A, B, and C components of the color space
with respect to the final XYZ representation. Default value: the identity matrix
[100010001].
Color SpacesSECTION 4.5
219
The transformation defined by the Gamma and Matrix entries in the CalRGB
color space dictionary is
In other words, the A, B, and C components are first decoded individually by the
gamma functions. The results are treated as a three-element vector and multi-
plied by
Matrix (a 3-by-3 matrix) to obtain the L, M, and N components of the in-
termediate representation. Since there is no second stage, these are also the X, Y,
and Z components of the final representation.
Example 4.7 shows an example of a
CalRGB color space for the CCIR XA/11–
recommended D65 white point with 1.8 gammas and Sony Trinitron
®
phosphor
chromaticities.
Example 4.7
[ /CalRGB
<< /WhitePoint [0.9505 1.0000 1.0890]
/Gamma [1.8000 1.8000 1.8000]
/Matrix [ 0.4497 0.2446 0.0252
0.3163 0.6720 0.1412
0.1845 0.0833 0.9227
]
>>
]
In some cases, the parameters of a CalRGB color space may be specified in terms
of the CIE 1931 chromaticity coordinates (x
R
, y
R
), (x
G
, y
G
), (x
B
, y
B
) of the red,
green, and blue phosphors, respectively, and the chromaticity (x
W
, y
W
) of the dif-
fuse white point corresponding to some linear RGB value (R, G, B), where usually
R = G = B = 1.0. Note that standard CIE notation uses lowercase letters to specify
chromaticity coordinates and uppercase letters to specify tristimulus values. Giv-
en this information,
Matrix and WhitePoint can be found as follows:
XLX
A
A
G
R
× X
B
B
G
G
× X
C
C
G
B
×++==
YMY
A
A
G
R
× Y
B
B
G
G
× Y
C
C
G
B
×++==
ZN Z
A
A
G
R
× Z
B
B
G
G
× Z
C
C
G
B
×++==
GraphicsCHAPTER 4
220
Lab Color Spaces
A Lab color space is a CIE-based ABC color space with two transformation stages
(see Figure 4.14 on page 215). In this type of space, A, B, and C represent the L*,
a*, and b* components of a CIE 1976 L*a*b* space. The range of the first (L*)
component is always 0 to 100; the ranges of the second and third (a* and b*)
components are defined by the
Range entry in the color space dictionary (see
Table 4.15).
Plate 3 illustrates the coordinates of a typical
Lab color space; Plate 4 compares
the gamuts (ranges of representable colors) for L*a*b*, RGB, and CMYK spaces.
zy
W
x
G
x
B
–()y
R
× x
R
x
B
–()y
G
×– x
R
x
G
–()y
B
×)+(×=
Y
A
y
R
R
-----
x
G
x
B
–()y
W
× x
W
x
B
–()y
G
× x
W
x
G
–()y
B
×+–
z
---------------------------------------------------------------------------------------------------------------------------------
×=
X
A
Y
A
x
R
y
R
------
×= Z
A
Y
A
1 x
R
–
y
R
--------------- 1–
×=
Y
B
y
G
G
------–
x
R
x
B
–()y
W
× x
W
x
B
–()y
R
× x
W
x
R
–()y
B
×+–
z
--------------------------------------------------------------------------------------------------------------------------------
×=
X
B
Y
B
x
G
y
G
------
×= Z
B
Y
B
1 x
G
–
y
G
--------------- 1–
×=
Y
C
y
B
B
-----
x
R
x
G
–()y
W
× x
W
x
G
–()y
R
× x
W
x
R
–()y
G
×+–
z
---------------------------------------------------------------------------------------------------------------------------------
×=
X
C
Y
C
x
B
y
B
------
×= Z
C
Y
C
1 x
B
–
y
B
-------------- 1–
×=
X
W
X
A
R× X
B
G× X
C
B×++=
Y
W
Y
A
R× Y
B
G× Y
C
B×++=
Z
W
Z
A
R× Z
B
G× Z
C
B×++=
Color SpacesSECTION 4.5
221
TABLE 4.15 Entries in a Lab color space dictionary
A Lab color space does not specify explicit decoding functions or matrix coef-
ficients for either stage of the transformation from L*a*b* space to XYZ space
(denoted by “Decode ABC,” “M at rix ABC,” “D e c ode LMN,” and “Matrix LMN” in
Figure 4.14 on page 215). Instead, these parameters have constant implicit values.
The first transformation stage is defined by the equations
KEY TYPE VALUE
WhitePoint
array (Required) An array of three numbers [X
W
Y
W
Z
W
] specifying the tristimulus value,
in the CIE 1931 XYZ space, of the diffuse white point; see “CalRGB Color Spaces” on
page 217 for further discussion. The numbers X
W
and Z
W
must be positive, and Y
W
must be equal to 1.0.
BlackPoint
array (Optional) An array of three numbers [X
B
Y
B
Z
B
] specifying the tristimulus value, in
the CIE 1931 XYZ space, of the diffuse black point; see “CalRGB Color Spaces” on
page 217 for further discussion. All three of these numbers must be non-negative.
Default value:
[0.0 0.0 0.0].
Range
array (Optional) An array of four numbers [a
min
a
max
b
min
b
max
] specifying the range of
valid values for the a* and b* (B and C) components of the color space—that is,
and
Component values falling outside the specified range are adjusted to the nearest valid
value without error indication. Default value:
[100 100 100 100].
a
min
a* a
max
b
min
b* b
max
L
L* 16+
116
------------------
a*
500
--------+=
M
L* 16+
116
------------------=
N
L* 16+
116
------------------
b*
200
--------–=
GraphicsCHAPTER 4
222
The second transformation stage is given by
where the function g(x) is defined as
Example 4.8 defines the CIE 1976 L*a*b* space with the CCIR XA/11–
recommended D65 white point. The a* and b* components, although theoretical-
ly unbounded, are defined to lie in the useful range 128 to +127.
Example 4.8
[ /Lab
<< /WhitePoint [0.9505 1.0000 1.0890]
/Range [128 127 128 127]
>>
]
ICCBased Color Spaces
ICCBased color spaces (PDF 1.3) are based on a cross-platform color profile as
defined by the International Color Consortium (ICC). Unlike the
CalGray,
CalRGB, and Lab color spaces, which are characterized by entries in the color
space dictionary, an
ICCBased color space is characterized by a sequence of bytes
in a standard format. Details of the profile format can be found in the ICC speci-
fication (see the Bibliography).
An
ICCBased color space is specified as an array:
[/ICCBased stream]
The stream contains the ICC profile. Besides the usual entries common to all
streams (see Table 3.4 on page 38), the profile stream has the additional entries
listed in Table 4.16.
XX
W
gL()×=
YY
W
gM()×=
ZZ
W
gN()×=
gx() x
3
= if x
6
29
-----
gx()
108
841
--------
x
4
29
-----–
×=
otherwise
Color SpacesSECTION 4.5
223
TABLE 4.16 Additional entries specific to an ICC profile stream dictionary
The ICC specification is an evolving standard. Table 4.17 shows the versions of
the ICC specification on which the
ICCBased color spaces supported by PDF ver-
sions 1.3 and later are based. (Earlier versions of the ICC specification are also
supported.)
TABLE 4.17 ICC specification versions supported by ICCBased color spaces
KEY TYPE VALUE
N
integer (Required) The number of color components in the color space described by the ICC
profile data. This number must match the number of components actually in the ICC
profile. As of PDF 1.4,
N must be 1, 3, or 4.
Alternate
array or
name
(Optional) An alternate color space to be used in case the one specified in the stream
data is not supported (for example, by applications designed for earlier versions of
PDF). The alternate space may be any valid color space (except a
Pattern color space)
that has the number of components specified by
N. If this entry is omitted and the ap-
plication does not understand the ICC profile data, the color space used is
DeviceGray, DeviceRGB, or DeviceCMYK, depending on whether the value of N is 1, 3,
or 4, respectively.
Note: There is no conversion of source color values, such as a tint transformation, when
using the alternate color space. Color values within the range of the
ICCBased color space
might not be within the range of the alternate color space. In this case, the nearest values
within the range of the alternate space are substituted.
Range
array (Optional) An array of 2 × N numbers [min
0
max
0
min
1
max
1
…] specifying the min-
imum and maximum valid values of the corresponding color components. These val-
ues must match the information in the ICC profile. Default value:
[0.0 1.0 0.0 1.0 …].
Metadata
stream (Optional; PDF 1.4) A metadata stream containing metadata for the color space (see
Section 10.2.2, “Metadata Streams”).
PDF VERSION ICC SPECIFICATION VERSION
1.3 3.3
1.4 ICC.1:1998-09 and its addendum ICC.1A:1999-04
1.5 ICC.1:2001-12
1.6 ICC.1:2003-09
GraphicsCHAPTER 4
224
PDF producers and consumers should follow these guidelines:
• A consumer that supports a given PDF version is required to support ICC pro-
files conforming to the corresponding version (and earlier versions) of the ICC
specification, as described above. It may optionally support later ICC versions.
• For the most predictable and consistent results, a producer of a given PDF ver-
sion should embed only profiles conforming to the corresponding version of
the ICC specification.
• A PDF producer may embed profiles conforming to a later ICC version, with
the understanding that the results will vary depending on the capabilities of the
consumer. The consumer might process the profile while ignoring newer
features, or it might fail altogether to process the profile. Therefore, it is recom-
mended that the producer provide an alternate color space (
Alternate entry in
the
ICCBased color space dictionary) containing a profile that is appropriate for
the PDF version.
PDF supports only the profile types shown in Table 4.18; other types may be sup-
ported in the future. (In particular, note that XYZ and 16-bit L*a*b* profiles are
not supported.) Each of the indicated fields must have one of the values listed for
that field in the second column of the table. (Profiles must satisfy both the criteria
shown in the table.) The terminology is taken from the ICC specifications.
TABLE 4.18 ICC profile types
The terminology used in PDF color spaces and ICC color profiles is similar, but
sometimes the same terms are used with different meanings. For example, the
default value for each component in an
ICCBased color space is 0. The range of
each color component is a function of the color space specified by the profile and
HEADER FIELD REQUIRED VALUE
deviceClass icSigInputClass ('scnr')
icSigDisplayClass ('mntr')
icSigOutputClass ('prtr')
icSigColorSpaceClass ('spac')
colorSpace icSigGrayData ('GRAY')
icSigRgbData ('RGB ')
icSigCmykData ('CMYK')
icSigLabData ('Lab ')
Color SpacesSECTION 4.5
225
is indicated in the ICC specification. The ranges for several ICC color spaces are
shown in Table 4.19.
TABLE 4.19 Ranges for typical ICC color spaces
Since the ICCBased color space is being used as a source color space, only the “to
CIE” profile information (AToB in ICC terminology) is used; the “from CIE”
(BToA) information is ignored when present. An ICC profile may also specify a
rendering intent, but PDF consumer applications ignore this information; the ren-
dering intent is specified in PDF by a separate parameter (see “Rendering Intents”
on page 230).
Note: The requirements stated above apply to an
ICCBased color space that is used
to specify the source colors of graphics objects. When such a space is used as the
blending color space for a transparency group in the transparent imaging model
(see Sections 7.2.3, “Blending Color Space”; 7.3, “Transparency Groups”; and 7.5.5,
“Transparency Group XObjects”), it must have both “to CIE” (AToB) and “from
CIE” (BToA) information. This is because the group color space is used as both the
destination for objects being painted within the group and the source for the
group’s results. ICC profiles are also used in specifying output intents for matching
the color characteristics of a PDF document with those of a target output device or
production environment. When used in this context, they are subject to still other
constraints on the “to CIE” and “from CIE” information; see Section 10.10.4, “Out-
put Intents,” for details.
The representations of
ICCBased color spaces are less compact than CalGray,
CalRGB, and Lab, but can represent a wider range of color spaces. In those cases
where a given color space can be expressed by more than one of the CIE-based
color space families, the resulting colors are expected to be rendered similarly,
regardless of the method selected for representation.
ICC COLOR SPACE COMPONENT RANGES
Gray
[0.0 1.0]
RGB
[0.0 1.0]
CMYK
[0.0 1.0]
L*a*b*
L*: [0 100]; a* and b*: [128 127]
GraphicsCHAPTER 4
226
One particular color space is the so-called “standard RGB” or sRGB, defined in
the International Electrotechnical Commission (IEC) document Colour Measure-
ment and Management in Multimedia Systems and Equipment (see the Bibliogra-
phy). In PDF, the sRGB color space can be expressed precisely only as an
ICCBased space, although it can be approximated by a CalRGB space.
Example 4.9 shows an
ICCBased color space for a typical three-component RGB
space. The profile’s data has been encoded in hexadecimal representation for
readability; in actual practice, a lossless decompression filter such as
FlateDecode
should be used.
Example 4.9
10 0 obj % Color space
[/ICCBased 15 0 R]
endobj
15 0 obj % ICC profile stream
<< /N 3
/Alternate /DeviceRGB
/Length 1605
/Filter /ASCIIHexDecode
>>
stream
00 00 02 0C 61 70 70 6C 02 00 00 00 6D 6E 74 72
52 47 42 20 58 59 5A 20 07 CB 00 02 00 16 00 0E
00 22 00 2C 61 63 73 70 41 50 50 4C 00 00 00 00
61 70 70 6C 00 00 04 01 00 00 00 00 00 00 00 02
00 00 00 00 00 00 F6 D4 00 01 00 00 00 00 D3 2B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 09 64 65 73 63 00 00 00 F0 00 00 00 71
72 58 59 5A 00 00 01 64 00 00 00 14 67 58 59 5A
00 00 01 78 00 00 00 14 62 58 59 5A 00 00 01 8C
00 00 00 14 72 54 52 43 00 00 01 A0 00 00 00 0E
67 54 52 43 00 00 01 B0 00 00 00 0E 62 54 52 43
00 00 01 C0 00 00 00 0E 77 74 70 74 00 00 01 D0
00 00 00 14 63 70 72 74 00 00 01 E4 00 00 00 27
64 65 73 63 00 00 00 00 00 00 00 17 41 70 70 6C
65 20 31 33 22 20 52 47 42 20 53 74 61 6E 64 61
72 64 00 00 00 00 00 00 00 00 00 00 00 17 41 70
70 6C 65 20 31 33 22 20 52 47 42 20 53 74 61 6E
64 61 72 64 00 00 00 00 00 00 00 00 00 00 00 00
Color SpacesSECTION 4.5
227
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 58 59 5A 58 59 5A 20 00 00 00 00 00 00 63 0A
00 00 35 0F 00 00 03 30 58 59 5A 20 00 00 00 00
00 00 53 3D 00 00 AE 37 00 00 15 76 58 59 5A 20
00 00 00 00 00 00 40 89 00 00 1C AF 00 00 BA 82
63 75 72 76 00 00 00 00 00 00 00 01 01 CC 63 75
63 75 72 76 00 00 00 00 00 00 00 01 01 CC 63 75
63 75 72 76 00 00 00 00 00 00 00 01 01 CC 58 59
58 59 5A 20 00 00 00 00 00 00 F3 1B 00 01 00 00
00 01 67 E7 74 65 78 74 00 00 00 00 20 43 6F 70
79 72 69 67 68 74 20 41 70 70 6C 65 20 43 6F 6D
70 75 74 65 72 73 20 31 39 39 34 00 >
endstream
endobj
Default Color Spaces
Colors that are specified in a device color space (DeviceGray, DeviceRGB, or
DeviceCMYK) are device-dependent. By setting default color spaces (PDF 1.1), a
PDF document can request that such colors be systematically transformed
(remapped) into device-independent CIE-based color spaces. This capability can
be useful in a variety of circumstances:
• A document originally intended for one output device is redirected to a differ-
ent device.
• A document is intended to be compatible with applications designed for earlier
versions of PDF and thus cannot specify CIE-based colors directly.
• Color corrections or rendering intents need to be applied to device colors (see
“Rendering Intents” on page 230).
A color space is selected for painting each graphics object. This is either the cur-
rent color space parameter in the graphics state or a color space given as an entry
in an image XObject, inline image, or shading dictionary. Regardless of how the
color space is specified, it may be subject to remapping as described below.
When a device color space is selected, the
ColorSpace subdictionary of the cur-
rent resource dictionary (see Section 3.7.2, “Resource Dictionaries”) is checked
for the presence of an entry designating a corresponding default color space
(
DefaultGray, DefaultRGB, or DefaultCMYK, corresponding to DeviceGray,
GraphicsCHAPTER 4
228
DeviceRGB, or DeviceCMYK, respectively). If such an entry is present, its value is
used as the color space for the operation currently being performed. (If the appli-
cation does not recognize this color space, no remapping occurs; the original de-
vice color space is used.)
Color values in the original device color space are passed unchanged to the
default color space, which must have the same number of components as the
original space. The default color space should be chosen to be compatible with
the original, taking into account the components’ ranges and whether the compo-
nents are additive or subtractive. If a color value lies outside the range of the de-
fault color space, it is adjusted to the nearest valid value.
Note: Any color space other than a
Lab, Indexed, or Pattern color space may be used
as a default color space provided that it is compatible with the original device color
space as described above.
If the selected space is a special color space based on an underlying device color
space, the default color space is used in place of the underlying space. This applies
to the following color spaces:
• The underlying color space of a Pattern color space
• The base color space of an Indexed color space
• The alternate color space of a Separation or DeviceN color space (but only if
the alternate color space is actually selected)
See Section 4.5.5, “Special Color Spaces,” for details on these color spaces.
Note: There is no conversion of color values, such as a tint transformation, when us-
ing the default color space. Color values that are within the range of the device color
space might not be within the range of the default color space (particularly if the de-
fault is an
ICCBased color space). In this case, the nearest values within the range of
the default space are used. For this reason, a
Lab color space is not permitted as the
DefaultRGB color space.
Implicit Conversion of CIE-Based Color Spaces
In workflows in which PDF documents are intended for rendering on a specific
target output device (such as a printing press with particular inks and media), it is
often useful to specify the source colors for some or all of a document’s objects in
Color SpacesSECTION 4.5
229
a CIE-based color space that matches the calibration of the intended device. The
resulting document, although tailored to the specific characteristics of the target
device, remains device-independent and will produce reasonable results if re-
targeted to a different output device. However, the expectation is that if the
document is printed on the intended target device, source colors that have been
specified in a color space matching the calibration of the device will pass through
unchanged, without conversion to and from the intermediate CIE 1931 XYZ
space as depicted in Figure 4.14 on page 215.
In particular, when colors intended for a CMYK output device are specified in an
ICCBased color space using a matching CMYK printing profile, converting such
colors from four components to three and back is unnecessary and results in a
loss of fidelity in the black component. In such cases, PDF consumer applications
may provide the ability for the user to specify a particular calibration to use for
printing, proofing, or previewing. This calibration is then considered to be that of
the native color space of the intended output device (typically
DeviceCMYK), and
colors expressed in a CIE-based source color space matching it can be treated as if
they were specified directly in the device’s native color space. Note that the condi-
tions under which such implicit conversion is done cannot be specified in PDF,
since nothing in PDF describes the calibration of the output device (although an
output intent dictionary, if present, may suggest such a calibration; see Section
10.10.4, “Output Intents”). The conversion is completely hidden by the applica-
tion and plays no part in the interpretation of PDF color spaces.
When this type of implicit conversion is done, all of the semantics of the device
color space should also apply, even though they do not apply to CIE-based spaces
in general. In particular:
• The nonzero overprint mode (see Section 4.5.6, “Overprint Control”) deter-
mines the interpretation of color component values in the space.
• If the space is used as the blending color space for a transparency group in the
transparent imaging model (see Sections 7.2.3, “Blending Color Space”; 7.3,
“Transparency Groups”; and 7.5.5, “Transparency Group XObjects”), compo-
nents of the space, such as
Cyan, can be selected in a Separation or DeviceN
color space used within the group (see “Separation Color Spaces” on page 234
and “DeviceN Color Spaces” on page 238).
• Likewise, any uses of device color spaces for objects within such a transparency
group have well-defined conversions to the group color space.
GraphicsCHAPTER 4
230
Note: A source color space can be specified directly (for example, with an ICCBased
color space) or indirectly using the default color space mechanism (for example,
DefaultCMYK; see “Default Color Spaces” on page 227). The implicit conversion of a
CIE-based color space to a device space should not depend on whether the CIE-
based space is specified directly or indirectly.
Rendering Intents
Although CIE-based color specifications are theoretically device-independent,
they are subject to practical limitations in the color reproduction capabilities of
the output device. Such limitations may sometimes require compromises to be
made among various properties of a color specification when rendering colors for
a given device. Specifying a rendering intent (PDF 1.1) allows a PDF file to set pri-
orities regarding which of these properties to preserve and which to sacrifice. For
example, the PDF file might request that colors falling within the output device’s
gamut (the range of colors it can reproduce) be rendered exactly while sacrificing
the accuracy of out-of-gamut colors, or that a scanned image such as a photo-
graph be rendered in a perceptually pleasing manner at the cost of strict colori-
metric accuracy.
Rendering intents are specified with the
ri operator (see Section 4.3.3, “Graphics
State Operators”), the
RI entry in a graphics state parameter dictionary (see Sec-
tion 4.3.4), and with the
Intent entry in image dictionaries (Section 4.8.4, “Image
Dictionaries”). The value is a name identifying the rendering intent. Table 4.20
lists the standard rendering intents recognized in the initial release of PDF viewer
applications from Adobe Systems; Plate 5 illustrates their effects. These intents
have been deliberately chosen to correspond closely to those defined by the Inter-
national Color Consortium (ICC), an industry organization that has developed
standards for device-independent color. Note, however, that the exact set of ren-
dering intents supported may vary from one output device to another; a particu-
lar device may not support all possible intents or may support additional ones
beyond those listed in the table. If the application does not recognize the speci-
fied name, it uses the
RelativeColorimetric intent by default.
See Section 7.6.4, “Rendering Parameters and Transparency,” and in particular
“Rendering Intent and Color Conversions” on page 543, for further discussion of
the role of rendering intents in the transparent imaging model.
Color SpacesSECTION 4.5
231
TABLE 4.20 Rendering intents
NAME DESCRIPTION
AbsoluteColorimetric
Colors are represented solely with respect to the light source; no
correction is made for the output medium’s white point (such as
the color of unprinted paper). Thus, for example, a monitor’s
white point, which is bluish compared to that of a printer’s pa-
per, would be reproduced with a blue cast. In-gamut colors are
reproduced exactly; out-of-gamut colors are mapped to the
nearest value within the reproducible gamut. This style of repro-
duction has the advantage of providing exact color matches from
one output medium to another. It has the disadvantage of caus-
ing colors with Y values between the medium’s white point and
1.0 to be out of gamut. A typical use might be for logos and solid
colors that require exact reproduction across different media.
RelativeColorimetric
Colors are represented with respect to the combination of the
light source and the output medium’s white point (such as the
color of unprinted paper). Thus, for example, a monitor’s white
point would be reproduced on a printer by simply leaving the
paper unmarked, ignoring color differences between the two
media. In-gamut colors are reproduced exactly; out-of-gamut
colors are mapped to the nearest value within the reproducible
gamut. This style of reproduction has the advantage of adapting
for the varying white points of different output media. It has the
disadvantage of not providing exact color matches from one me-
dium to another. A typical use might be for vector graphics.
Saturation
Colors are represented in a manner that preserves or emphasizes
saturation. Reproduction of in-gamut colors may or may not be
colorimetrically accurate. A typical use might be for business
graphics, where saturation is the most important attribute of the
color.
Perceptual
Colors are represented in a manner that provides a pleasing per-
ceptual appearance. To preserve color relationships, both in-
gamut and out-of-gamut colors are generally modified from
their precise colorimetric values. A typical use might be for
scanned images.
GraphicsCHAPTER 4
232
4.5.5 Special Color Spaces
Special color spaces add features or properties to an underlying color space.
There are four special color space families:
Pattern, Indexed, Separation, and
DeviceN.
Pattern Color Spaces
A Pattern color space (PDF 1.2) enables a PDF content stream to paint an area
with a pattern rather than a single color. The pattern may be either a tiling pattern
(type
1) or a shading pattern (type 2). Section 4.6, “Patterns,” discusses patterns in
detail.
Indexed Color Spaces
An Indexed color space allows a PDF content stream to use small integers as indi-
ces into a color map or color table of arbitrary colors in some other space. A PDF
consumer application treats each sample value as an index into the color table
and uses the color value it finds there. This technique can considerably reduce the
amount of data required to represent a sampled image—for example, by using
8-bit index values as samples instead of 24-bit RGB color values.
An
Indexed color space is defined by a four-element array:
[/Indexed base hival lookup]
The first element is the color space family name Indexed. The remaining ele-
ments are parameters that an
Indexed color space requires; their meanings are
discussed below. Setting the current stroking or nonstroking color space to an
Indexed color space initializes the corresponding current color to 0.
The
base parameter is an array or name that identifies the base color space in
which the values in the color table are to be interpreted. It can be any device or
CIE-based color space or (in PDF 1.3) a
Separation or DeviceN space, but not a
Pattern space or another Indexed space. For example, if the base color space is
DeviceRGB, the values in the color table are to be interpreted as red, green, and
blue components; if the base color space is a CIE-based ABC space such as a
CalRGB or Lab space, the values are to be interpreted as A, B, and C components.
Color SpacesSECTION 4.5
233
Note: Attempting to use a Separation or DeviceN color space as the base for an
Indexed color space generates an error in PDF 1.2.
The
hival parameter is an integer that specifies the maximum valid index value. In
other words, the color table is to be indexed by integers in the range 0 to
hival.
hival can be no greater than 255, which is the integer required to index a table
with 8-bit index values.
The color table is defined by the
lookup parameter, which can be either a stream
or (in PDF 1.2) a string. It provides the mapping between index values and the
corresponding colors in the base color space.
The color table data must be m × (
hival + 1) bytes long, where m is the number of
color components in the base color space. Each byte is an unsigned integer in the
range 0 to 255 that is scaled to the range of the corresponding color component in
the base color space; that is, 0 corresponds to the minimum value in the range for
that component, and 255 corresponds to the maximum.
Note: PostScript uses a different interpretation of an
Indexed color space’s color ta-
ble. In PostScript, the component value is always scaled to the range 0.0 to 1.0, re-
gardless of the range of color values in the base color space.
The color components for each entry in the table appear consecutively in the
string or stream. For example, if the base color space is
DeviceRGB and the
indexed color space contains two colors, the order of bytes in the string or stream
is
R
0
G
0
B
0
R
1
G
1
B
1
, where letters denote the color component and numeric
subscripts denote the table entry.
Example 4.10 illustrates the specification of an
Indexed color space that maps
8-bit index values to three-component color values in the
DeviceRGB color space.
Example 4.10
[ /Indexed
/DeviceRGB
255
<000000 FF0000 00FF00 0000FF B57342 …>
]
The example shows only the first five color values in the lookup string; in all, there
should be 256 color values and the string should be 768 bytes long. Having
GraphicsCHAPTER 4
234
established this color space, the program can now specify colors as single-compo-
nent values in the range 0 to 255. For example, a color value of 4 selects an RGB
color whose components are coded as the hexadecimal integers
B5, 73, and 42.
Dividing these by 255 and scaling the results to the range 0.0 to 1.0 yields a color
with red, green, and blue components of 0.710, 0.451, and 0.259, respectively.
Although an
Indexed color space is useful mainly for images, index values can
also be used with the color selection operators
SC, SCN, sc, and scn. For example:
123 sc
selects the same color as does an image sample value of 123. The index value
should be an integer in the range 0 to
hival. If the value is a real number, it is
rounded to the nearest integer; if it is outside the range 0 to
hival, it is adjusted to
the nearest value within that range.
Separation Color Spaces
Color output devices produce full color by combining primary or process
colorants in varying amounts. On an additive color device such as a display, the
primary colorants consist of red, green, and blue phosphors; on a subtractive de-
vice such as a printer, they typically consist of cyan, magenta, yellow, and some-
times black inks. In addition, some devices can apply special colorants, often
called spot colorants, to produce effects that cannot be achieved with the standard
process colorants alone. Examples include metallic and fluorescent colors and
special textures.
When printing a page, most devices produce a single composite page on which all
process colorants (and spot colorants, if any) are combined. However, some de-
vices, such as imagesetters, produce a separate, monochromatic rendition of the
page, called a separation, for each colorant. When the separations are later com-
bined—on a printing press, for example—and the proper inks or other colorants
are applied to them, the result is a full-color page.
A
Separation color space (PDF 1.2) provides a means for specifying the use of
additional colorants or for isolating the control of individual color components of
a device color space for a subtractive device. When such a space is the current col-
or space, the current color is a single-component value, called a tint, that controls
the application of the given colorant or color components only.
Color SpacesSECTION 4.5
235
Note: The term separation is often misused as a synonym for an individual device
colorant. In the context of this discussion, a printing system that produces separa-
tions generates a separate piece of physical medium (generally film) for each color-
ant. It is these pieces of physical medium that are correctly referred to as separations.
A particular colorant properly constitutes a separation only if the device is generat-
ing physical separations, one of which corresponds to the given colorant. The
Separation color space is so named for historical reasons, but it has evolved to the
broader purpose of controlling the application of individual colorants in general, re-
gardless of whether they are actually realized as physical separations.
Note also that the operation of a
Separation color space itself is independent of the
characteristics of any particular output device. Depending on the device, the space
may or may not correspond to a true, physical separation or to an actual colorant.
For example, a
Separation color space could be used to control the application of a
single process colorant (such as cyan) on a composite device that does not produce
physical separations, or could represent a color (such as orange) for which no specif-
ic colorant exists on the device. A
Separation color space provides consistent, pre-
dictable behavior, even on devices that cannot directly generate the requested color.
A
Separation color space is defined as follows:
[/Separation name alternateSpace tintTransform]
In other words, it is a four-element array whose first element is the color space
family name
Separation. The remaining elements are parameters that a
Separation color space requires; their meanings are discussed below.
A color value in a
Separation color space consists of a single tint component in
the range 0.0 to 1.0. The value 0.0 represents the minimum amount of colorant
that can be applied; 1.0 represents the maximum. Tints are always treated as
subtractive colors, even if the device produces output for the designated compo-
nent by an additive method. Thus, a tint value of 0.0 denotes the lightest color
that can be achieved with the given colorant, and 1.0 is the darkest. (This conven-
tion is the same as for
DeviceCMYK color components but opposite to the one for
DeviceGray and DeviceRGB.) The initial value for both the stroking and non-
stroking color in the graphics state is 1.0. The
SCN and scn operators respectively
set the current stroking and nonstroking color to a tint value. A sampled image
with single-component samples can also be used as a source of tint values.
The
name parameter is a name object specifying the name of the colorant that
this
Separation color space is intended to represent (or one of the special names
GraphicsCHAPTER 4
236
All or None; see below). Such colorant names are arbitrary, and there can be any
number of them, subject to implementation limits.
The special colorant name
All refers collectively to all colorants available on an
output device, including those for the standard process colorants. When a
Separation space with this colorant name is the current color space, painting
operators apply tint values to all available colorants at once. This is useful for pur-
poses such as painting registration targets in the same place on every separation.
Such marks are typically painted as the last step in composing a page to ensure
that they are not overwritten by subsequent painting operations.
The special colorant name
None never produces any visible output. Painting op-
erations in a
Separation space with this colorant name have no effect on the cur-
rent page.
All devices support
Separation color spaces with the colorant names All and
None, even if they do not support any others. Separation spaces with either of
these colorant names ignore the
alternateSpace and tintTransform parameters (dis-
cussed below), although valid values must still be provided.
At the moment the color space is set to a
Separation space, the consumer applica-
tion determines whether the device has an available colorant corresponding to
the name of the requested space. If so, the application ignores the
alternateSpace
and tintTransform parameters; subsequent painting operations within the space
apply the designated colorant directly, according to the tint values supplied.
Note: The preceding paragraph applies only to subtractive output devices such as
printers and imagesetters. For an additive device such as a computer display, a
Separation color space never applies a process colorant directly; it always reverts to
the alternate color space as described below. This is because the model of applying
process colorants independently does not work as intended on an additive device; for
instance, painting tints of the
Red component on a white background produces a
result that varies from white to cyan.
Note that this exception applies only to colorants for additive devices, not to the spe-
cific names
Red, Green, and Blue. In contrast, a printer might have a (subtractive)
ink named, for example,
Red, which should work as a Separation color space just
the same as any other supported colorant.
Color SpacesSECTION 4.5
237
If the colorant name associated with a Separation color space does not cor-
respond to a colorant available on the device, the application arranges for subse-
quent painting operations to be performed in an alternate color space. The
intended colors can be approximated by colors in a device or CIE-based color
space, which are then rendered with the usual primary or process colorants:
• The alternateSpace parameter must be an array or name object that identifies
the alternate color space, which can be any device or CIE-based color space but
not another special color space (
Pattern, Indexed, Separation, or DeviceN).
• The tintTransform parameter must be a function (see Section 3.9, “Functions”).
During subsequent painting operations, an application calls this function to
transform a tint value into color component values in the alternate color space.
The function is called with the tint value and must return the corresponding
color component values. That is, the number of components and the interpre-
tation of their values depend on the alternate color space.
Note: Painting in the alternate color space may produce a good approximation of
the intended color when only opaque objects are painted. However, it does not cor-
rectly represent the interactions between an object and its backdrop when the object
is painted with transparency or when overprinting (see Section 4.5.6, “Overprint
Control”) is enabled.
Example 4.11 illustrates the specification of a
Separation color space (object 5)
that is intended to produce a color named
LogoGreen. If the output device has no
colorant corresponding to this color,
DeviceCMYK is used as the alternate color
space, and the tint transformation function (object 12) maps tint values linearly
into shades of a CMYK color value approximating the
LogoGreen color.
Example 4.11
5 0 obj % Color space
[ /Separation
/LogoGreen
/DeviceCMYK
12 0 R
]
endobj
GraphicsCHAPTER 4
238
12 0 obj % Tint transformation function
<< /FunctionType 4
/Domain [0.0 1.0]
/Range [0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]
/Length 62
>>
stream
{ dup 0.84 mul
exch 0.00 exch dup 0.44 mul
exch 0.21 mul
}
endstream
endobj
See Section 7.6.2, “Spot Colors and Transparency,” for further discussion of the
role of
Separation color spaces in the transparent imaging model.
DeviceN Color Spaces
DeviceN color spaces (PDF 1.3) can contain an arbitrary number of color compo-
nents. They provide greater flexibility than is possible with standard device color
spaces such as
DeviceCMYK or with individual Separation color spaces. For ex-
ample, it is possible to create a
DeviceN color space consisting of only the cyan,
magenta, and yellow color components, with the black component excluded.
DeviceN color spaces are used in applications such as these:
• High-fidelity color is the use of more than the standard CMYK process colo-
rants to produce an extended gamut, or range of colors. A popular example is
the PANTONE Hexachrome system, which uses six colorants: the usual cyan,
magenta, yellow, and black, plus orange and green.
• Multitone color systems use a single-component image to specify multiple color
components. In a duotone, for example, a single-component image can be used
to specify both the black component and a spot color component. The tone
reproduction is generally different for the different components. For example,
the black component might be painted with the exact sample data from the sin-
gle-component image; the spot color component might be generated as a
nonlinear function of the image data in a manner that emphasizes the shadows.
Plate 6 shows an example that uses black and magenta color components. In
Plate 7, a single-component grayscale image is used to generate a quadtone re-
Color SpacesSECTION 4.5
239
sult that uses four colorants: black and three PANTONE spot colors. See Exam-
ple 4.21 on page 252 for the code used to generate this image.
DeviceN was designed to represent color spaces containing multiple components
that correspond to colorants of some target device. As with
Separation color
spaces, PDF consumer applications must be able to approximate the colorants if
they are not available on the current output device, such as a display. To accom-
plish this, the color space definition provides a tint transformation function that
can be used to convert all the components to an alternate color space.
PDF 1.6 extends the meaning of
DeviceN to include color spaces that are referred
to as
NChannel color spaces. Such color spaces may contain an arbitrary number
of spot and process components, which may or may not correspond to specific
device colorants (the process components must be from a single process color
space). They provide information about each component that allows applications
more flexibility in converting colors. For example, they may use their own blend-
ing algorithms for on-screen viewing and composite printing, rather than being
required to use a specified tint transformation function. These color spaces are
identified by a value of
NChannel for the Subtype entry of the attributes dictio-
nary (see Table 4.21). A value of
DeviceN for the Subtype entry, or no value,
means that only the previous features are supported. PDF consumer applications
that do not support PDF 1.6 treat these color spaces as normal
DeviceN color
spaces and use the tint transformation function as appropriate. Producer applica-
tions using the
NChannel features should follow certain guidelines, as noted
throughout this section, to achieve good backward compatibility.
DeviceN color spaces are defined in a similar way to Separation color spaces—in
fact, a
Separation color space can be defined as a DeviceN color space with only
one component.
A
DeviceN color space is specified as follows:
[/DeviceN names alternateSpace tintTransform]
or
[/DeviceN names alternateSpace tintTransform attributes]
It is a four- or five-element array whose first element is the color space family
name
DeviceN. The remaining elements are parameters that a DeviceN color
space requires.
GraphicsCHAPTER 4
240
The names parameter is an array of name objects specifying the individual color
components. The length of the array determines the number of components in
the
DeviceN color space, which is subject to an implementation limit; see Appen-
dix C.The component names must all be different from one another, except for
the name
None, which can be repeated as described later in this section. (The
special name
All, used by Separation color spaces, is not allowed.)
Color values are tint components in the range 0.0 to 1.0:
• For DeviceN color spaces that do not have a subtype of NChannel, 0.0 always
represents the minimum amount of colorant; 1.0 represents the maximum.
Tints are always treated as subtractive colors, even if the device produces output
for the designated component by an additive method. Thus, a tint value of 0.0
denotes the lightest color that can be achieved with the given colorant, and 1.0
the darkest. (This convention is the same one as for
DeviceCMYK color compo-
nents but opposite to the one for
DeviceGray and DeviceRGB.)
• For NChannel color spaces, values for additive process colors (such as RGB) are
specified in their natural form, where 1.0 represents maximum intensity of col-
or.
When this space is set to the current color space (using the
CS or cs operators),
each component is given an initial value of 1.0. The
SCN and scn operators re-
spectively set the current stroking and nonstroking color. Operand values sup-
plied to
SCN or scn are interpreted as color component values in the order in
which the colors are given in the
names array, as are the values in a sampled im-
age that uses a
DeviceN color space.
The
alternateSpace parameter is an array or name object that can be any device or
CIE-based color space but not another special color space (
Pattern, Indexed,
Separation, or DeviceN). When the color space is set to a DeviceN space, if any of
the component names in the color space do not correspond to a colorant avail-
able on the device, the PDF consumer application can perform subsequent paint-
ing operations in the alternate color space specified by this parameter.
Note: For
NChannel color spaces, the components are evaluated individually; that
is, only the ones not present on the output device use the alternate color space.
The
tintTransform parameter specifies a function (see Section 3.9, “Functions”)
that is used to transform the tint values into the alternate color space. It is called
with n tint values and returns m color component values, where n is the number
Color SpacesSECTION 4.5
241
of components needed to specify a color in the DeviceN color space and m is the
number required by the alternate color space.
Note: Painting in the alternate color space may produce a good approximation of
the intended color when only opaque objects are painted. However, it does not cor-
rectly represent the interactions between an object and its backdrop when the object
is painted with transparency or when overprinting (see Section 4.5.6, “Overprint
Control”) is enabled.
The color component name
None, which may be present only for DeviceN color
spaces that do not have the
NChannel subtype, indicates that the corresponding
color component is never painted on the page, as in a
Separation color space for
the
None colorant. (However, see implementation note 47 in Appendix H.) When
a
DeviceN color space is painting the named device colorants directly, color com-
ponents corresponding to
None colorants are discarded. However, when the
DeviceN color space reverts to its alternate color space, those components are
passed to the tint transformation function, which can use them as desired.
Note: A
DeviceN color space whose component colorant names are all None always
discards its output, just the same as a
Separation color space for None; it never
reverts to the alternate color space. Reversion occurs only if at least one color com-
ponent (other than
None) is specified and is not available on the device.
The optional
attributes parameter is a dictionary (see Table 4.21) containing addi-
tional information about the components of color space that PDF consumer ap-
plications may use. PDF consumers are not required to use the
alternateSpace and
tintTransform parameters, and may instead use custom blending algorithms, along
with other information provided in the attributes dictionary if present. (If the val-
ue of the
Subtype entry in the attributes dictionary is NChannel, such informa-
tion must be present.) However,
alternateSpace and tintTransform must always be
provided for applications that want to use them or do not support PDF 1.6.
GraphicsCHAPTER 4
242
TABLE 4.21 Entries in a DeviceN color space attributes dictionary
A value of NChannel for the the Subtype entry indicates that some of the other
entries in this dictionary are required rather than optional. The
Colorants entry
specifies a colorants dictionary that contains entries for all the spot colorants in
the color space; they are defined using individual
Separation color spaces. The
Process entry specifies a process dictionary (see Table 4.22) that identifies the pro-
cess color space that is used by this color space and the names of its components.
It must be present if
Subtype is NChannel and the color space has process color
components. (An
NChannel color space may contain components from at most
one process color space.)
KEY TYPE VALUE
Subtype
name (Optional; PDF 1.6) A name specifying the preferred treatment for the color
space. Possible values are
DeviceN and NChannel. Default value: DeviceN.
Colorants
dictionary (Required if Subtype is NChannel and the color space includes spot colorants; other-
wise optional) A dictionary describing the individual colorants used in the
DeviceN color space. For each entry in this dictionary, the key is a colorant name
and the value is an array defining a
Separation color space for that colorant (see
“Separation Color Spaces” on page 234). The key must match the colorant name
given in that color space.
This dictionary provides information about the individual colorants that may be
useful to some applications. In particular, the alternate color space and tint trans-
formation function of a
Separation color space describe the appearance of that
colorant alone, whereas those of a
DeviceN color space describe only the appear-
ance of its colorants in combination.
If
Subtype is NChannel, this dictionary must have entries for all spot colorants in
this color space. This dictionary may also include additional colorants not used
by this color space.
Process
dictionary (Required if Subtype is NChannel and the color space includes components of a pro-
cess color space, otherwise optional; PDF 1.6) A dictionary (see Table 4.22) that de-
scribes the process color space whose components are included in this color
space.
MixingHints
dictionary (Optional; PDF 1.6) A dictionary (see Table 4.23) that specifies optional attributes
of the inks to be used in blending calculations when used as an alternative to the
tint transformation function.
Color SpacesSECTION 4.5
243
For color spaces that have a value of NChannel for the Subtype entry in the at-
tributes dictionary (see Table 4.21), the following restrictions apply to process
colors:
• There can be color components from at most one process color space, which
can be any device or CIE-based color space.
• For a non-CMYK color space, the names of the process components must ap-
pear sequentially in the
names array, in the normal color space order (for exam-
ple,
Red, Green, and Blue). However, the names in the names array need not
match the actual color space names (for example, a
Red component need not be
named
Red).The mapping of names is specified in the process dictionary (see
Table 4.22 and discussion below), which is required to be present.
• Definitions for process colorants should not appear in the colorants dictionary.
Any such definition should be ignored if the colorant is also present in the pro-
cess dictionary. Any component not specified in the process dictionary is con-
sidered to be a spot colorant.
• For a CMYK color space, a subset of the components may be present, and they
may appear in any order in the
names array. The reserved names Cyan,
Magenta, Yellow, and Black are always considered to be process colors, which
do not necessarily correspond to the colorants of a specific device; they are not
required to have entries in the process dictionary.
• The values associated with the process components must be stored in their nat-
ural form (that is, subtractive color values for CMYK and additive color values
for RGB), since they are interpreted directly as process values by consumers
making use of the process dictionary. (For additive color spaces, this is the re-
verse of how color values are specified for
DeviceN, as described above in the
discussion of the
names parameter.)
The
MixingHints entry in the attributes dictionary specifies a mixing hints dictio-
nary (see Table 4.23) that provides information about the characteristics of colo-
rants that can be used in blending calculations when the actual colorants are not
available on the target device. Applications are not required to use this informa-
tion.
GraphicsCHAPTER 4
244
TABLE 4.22 Entries in a DeviceN process dictionary
TABLE 4.23 Entries in a DeviceN mixing hints dictionary
KEY TYPE VALUE
ColorSpace
name or
array
(Required) A name or array identifying the process color space, which may be any
device or CIE-based color space. If an
ICCBased color space is specified, it must
provide calibration information appropriate for the process color components
specified in the
names array of the DeviceN color space.
Components
array (Required) An array of component names that correspond, in order, to the com-
ponents of the process color space specified in
ColorSpace. For example, an RGB
color space must have three names corresponding to red, green, and blue. The
names may be arbitrary (that is, not the same as the standard names for the color
space components) and must match those specified in the
names array of the
DeviceN color space, even if all components are not present in the names array.
KEY TYPE VALUE
Solidities
dictionary (Optional) A dictionary specifying the solidity of inks to be used in blending
calculations when used as an alternative to the tint transformation function.
For each entry, the key is a colorant name, and the value is a number between
0.0 and 1.0. This dictionary need not contain entries for all colorants used in
this color space; it may also include additional colorants not used by this color
space.
A value of 1.0 simulates an ink that completely covers the inks beneath; a value
of 0.0 simulates a transparent ink that completely reveals the inks beneath. An
entry with a key of
Default specifies a value to be used by all components in the
associated
DeviceN color space for which a solidity value is not explicitly pro-
vided. If
Default is not present, the default value for unspecified colorants is
0.0; applications may choose to use other values.
If this entry is present,
PrintingOrder must also be present.
PrintingOrder
array (Required if Solidities is present) An array of colorant names, specifying the or-
der in which inks are laid down. Each component in the
names array of the
DeviceN color space must appear in this array (although the order is unrelated
to the order specified in the
names array). This entry may also list colorants
unused by this specific
DeviceN instance.
Color SpacesSECTION 4.5
245
Each entry in the mixing hints dictionary refers to colorant names, which include
spot colorants referenced by the
Colorants dictionary. Under some circumstanc-
es, they may also refer to one or more individual process components called
Cyan, Magenta, Yellow, or Black when DeviceCMYK is specified as the process col-
or space in the process dictionary. However, applications should ignore these pro-
cess component entries if they can obtain the information from an ICC profile.
Note: The mixing hints subdictionaries (as well as the colorants dictionary) may
specify colorants that are not used in any given instance of a
DeviceN color space.
This allows them to be referenced from multiple
DeviceN color spaces, which can
produce smaller file sizes as well as consistent color definitions across instances.
For consistency of color, PDF consumers should follow these guidelines:
• The consumer should apply either the specified tint transformation function or
invoke the same alternative blending algorithm for all
DeviceN instances in the
document.
Note: When the tint transformation function is used, the burden is on the produc-
er to guarantee that the individual function definitions chosen for all
DeviceN in-
stances produce similar color appearances throughout the document.
• Blending algorithms should produce a similar appearance for colors when they
are used as separation colors or as a component of a
DeviceN color space.
DotGain
dictionary (Optional) A dictionary specifying the dot gain of inks to be used in blending
calculations when used as an alternative to the tint transformation function.
Dot gain (or loss) represents the amount by which a printer’s halftone dots
change as the ink spreads and is absorbed by paper.
For each entry, the key is a colorant name, and the value is a function that maps
values in the range 0 to 1 to values in the range 0 to 1. The dictionary may list
colorants unused by this specific
DeviceN instance and need not list all colo-
rants. An entry with a key of
Default specifies a function to be used by all colo-
rants for which a dot gain function is not explicitly specified.
PDF consumer applications may ignore values in this dictionary when other
sources of dot gain information are available, such as ICC profiles associated
with the process color space or tint transformation functions associated with
individual colorants.
KEY TYPE VALUE
GraphicsCHAPTER 4
246
Example 4.12 shows a DeviceN color space consisting of three color components
named
Orange, Green, and None. In this example, the DeviceN color space,
object 30, has an attributes dictionary whose
Colorants entry is an indirect refer-
ence to object 45 (which might also be referenced by attributes dictionaries of
other
DeviceN color spaces). tintTransform1, whose definition is not shown, maps
three color components (tints of the colorants
Orange, Green, and None) to four
color components in the alternate color space,
DeviceCMYK. tintTransform2 maps
a single color component (an orange tint) to four components in
DeviceCMYK.
Likewise,
tintTransform3 maps a green tint to DeviceCMYK, and tintTransform4
maps a tint of PANTONE 131 to DeviceCMYK.
Example 4.12
30 0 obj % Color space
[ /DeviceN
[/Orange /Green /None]
/DeviceCMYK
tintTransform1
<< /Colorants 45 0 R >>
]
endobj
45 0 obj % Colorants dictionary
<< /Orange [ /Separation
/Orange
/DeviceCMYK
tintTransform2
]
/Green [ /Separation
/Green
/DeviceCMYK
tintTransform3
]
/PANTONE#20131 [ /Separation
/PANTONE#20131
/DeviceCMYK
tintTransform4
]
>>
endobj
Color SpacesSECTION 4.5
247
Examples 4.13 through 4.16 show the use of NChannel color spaces. Example 4.13
shows the use of calibrated CMYK process components. Example 4.14 shows the
use of
Lab process components.
Example 4.13
10 0 obj % Color space
[ /DeviceN
[/Magenta /Spot1 /Yellow /Spot2]
alternateSpace
tintTransform1
<< % Attributes dictionary
/Subtype /NChannel
/Process
<< /ColorSpace [/ICCBased CMYK_ICC profile ]
/Components [/Cyan /Magenta /Yellow /Black]
>>
/Colorants
<< /Spot1 [/Separation /Spot1 alternateSpace tintTransform2]
/Spot2 [/Separation /Spot2 alternateSpace tintTransform3]
>>
>>
]
endobj
Example 4.14
10 0 obj % Color space
[ /DeviceN
[/L /a /b /Spot1 /Spot2]
alternateSpace
tintTransform1
<< % Attributes dictionary
/Subtype /NChannel
/Process
<< /ColorSpace [ /Lab << /WhitePoint ... /Range ... >> ]
/Components [/L /a /b]
>>
/Colorants
<< /Spot1 [/Separation /Spot1 alternateSpace tintTransform2 ]
/Spot2 [/Separation /Spot2 alternateSpace tintTransform3]
>>
>>
]
GraphicsCHAPTER 4
248
Example 4.15 shows the recommended convention for dealing with situations
where a spot colorant and a process color component have the same name. Since
the
names array may not have duplicate names, the process colors should be given
different names, which are mapped to process components in the
Components
entry of the process dictionary. In this case, Red refers to a spot colorant;
ProcessRed, ProcessGreen, and ProcessBlue are mapped to the components of an
RGB color space.
Example 4.15
10 0 obj % Color space
[ /DeviceN
[/ProcessRed /ProcessGreen /ProcessBlue /Red]
alternateSpace
tintTransform1
<< % Attributes dictionary
/Subtype /NChannel
/Process
<< /ColorSpace [ /ICCBased RGB_ICC profile ]
/Components [/ProcessRed /ProcessGreen /ProcessBlue]
>>
/Colorants
<< /Red [/Separation /Red alternateSpace tintTransform2 ] >>
>>
]
Example 4.16 shows the use of a mixing hints dictionary.
Example 4.16
10 0 obj % Color space
[/DeviceN
[/Magenta /Spot1 /Yellow /Spot2]
alternateSpace
tintTransform1
<<
/Subtype /NChannel
/Process
<< /ColorSpace [ /ICCBased CMYK_ICC profile ]
/Components [/Cyan /Magenta /Yellow /Black]
>>
/Colorants
<< /Spot1 [/Separation /Spot1 alternateSpace tintTransform2 ]
/Spot2 [/Separation /Spot2 alternateSpace tintTransform2 ]
Color SpacesSECTION 4.5
249
>>
/MixingHints
<<
/Solidities
<< /Spot1 1.0
/Spot2 0.0
>>
/DotGain
<< /Spot1 function1
/Spot2 function2
/Magenta function3
/Yellow function4
>>
/PrintingOrder [/Magenta /Yellow /Spot1 /Spot2]
>>
>>
]
See Section 7.6.2, “Spot Colors and Transparency,” for further discussion of the
role of
DeviceN color spaces in the transparent imaging model.
Multitone Examples
The following examples illustrate various interesting and useful special cases of
the use of
Indexed and DeviceN color spaces in combination to produce multi-
tone colors.
Examples 4.17 and 4.18 illustrate the use of
DeviceN to create duotone color spac-
es. In Example 4.17, an
Indexed color space maps index values in the range 0 to
255 to a duotone
DeviceN space in cyan and black. In effect, the index values are
treated as if they were tints of the duotone space, which are then mapped into
tints of the two underlying colorants. Only the beginning of the lookup table
string for the
Indexed color space is shown; the full table would contain 256 two-
byte entries, each specifying a tint value for cyan and black, for a total of 512
bytes. If the alternate color space of the
DeviceN space is selected, the tint trans-
formation function (object 15 in the example) maps the two tint components for
cyan and black to the four components for a
DeviceCMYK color space by supply-
ing zero values for the other two components. Example 4.18 shows the definition
of another duotone color space, this time using black and gold colorants (where
gold is a spot colorant) and using a
CalRGB space as the alternate color space. This
could be defined in the same way as in the preceding example, with a tint trans-
GraphicsCHAPTER 4
250
formation function that converts from the two tint components to colors in the
alternate
CalRGB color space.
Example 4.17
10 0 obj % Color space
[ /Indexed
[ /DeviceN
[/Cyan /Black]
/DeviceCMYK
15 0 R
]
255
<6605 6806 6907 6B09 6C0A …>
]
endobj
15 0 obj % Tint transformation function
<< /FunctionType 4
/Domain [0.0 1.0 0.0 1.0]
/Range [0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]
/Length 16
>>
stream
{0 0 3 1 roll}
endstream
endobj
Example 4.18
30 0 obj % Color space
[ /Indexed
[ /DeviceN
[/Black /Gold]
[ /CalRGB
<< /WhitePoint [1.0 1.0 1.0]
/Gamma [2.2 2.2 2.2]
>>
]
35 0 R % Tint transformation function
]
255
…Lookup table…
]
endobj
Color SpacesSECTION 4.5
251
Given a formula for converting any combination of black and gold tints to cali-
brated RGB, a 2-in, 3-out type 4 (PostScript calculator) function could be used for
the tint transformation. Alternatively, a type 0 (sampled) function could be used,
but this would require a large number of sample points to represent the function
accurately; for example, sampling each input variable for 256 tint values between
0.0 and 1.0 would require 256
2
= 65,536 samples. But since the DeviceN color
space is being used as the base of an
Indexed color space, there are actually only
256 possible combinations of black and gold tint values. A more compact way to
represent this information is to put the alternate color values directly into the
lookup table alongside the
DeviceN color values, as in Example 4.19.
Example 4.19
10 0 obj % Color space
[ /Indexed
[ /DeviceN
[/Black /Gold /None /None /None]
[ /CalRGB
<< /WhitePoint [1.0 1.0 1.0]
/Gamma [2.2 2.2 2.2]
>>
]
20 0 R % Tint transformation function
]
255
…Lookup table…
]
endobj
In this example, each entry in the lookup table has five components: two for the
black and gold colorants and three more (specified as
None) for the equivalent
CalRGB color components. If the black and gold colorants are available on the
output device, the
None components are ignored; if black and gold are not
available, the tint transformation function is used to convert a five-component
color into a three-component equivalent in the alternate
CalRGB color space.
But because, by construction, the third, fourth, and fifth components are the
CalRGB components, the tint transformation function can merely discard the
first two components and return the last three. This can be easily expressed
with a type 4 (PostScript calculator) function, as shown in Example 4.20.
GraphicsCHAPTER 4
252
Example 4.20
20 0 obj % Tint transformation function
<< /FunctionType 4
/Domain [0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]
/Range [0.0 1.0 0.0 1.0 0.0 1.0]
/Length 27
>>
stream
{5 3 roll pop pop}
endstream
endobj
Example 4.21 uses an extension of the techniques described above to produce the
quadtone (four-component) image shown in Plate 7.
Example 4.21
5 0 obj % Image XObject
<< /Type /XObject
/Subtype /Image
/Width 288
/Height 288
/ColorSpace 10 0 R
/BitsPerComponent 8
/Length 105278
/Filter /ASCII85Decode
>>
stream
…Data for grayscale image…
endstream
endobj
10 0 obj % Indexed color space for image
[ /Indexed
15 0 R % Base color space
255 % Table has 256 entries
30 0 R % Lookup table
]
endobj
Color SpacesSECTION 4.5
253
15 0 obj % Base color space (DeviceN) for Indexed space
[ /DeviceN
[ /Black % Four colorants (black plus three spot colors)
/PANTONE#20216#20CVC
/PANTONE#20409#20CVC
/PANTONE#202985#20CVC
/None % Three components for alternate space
/None
/None
]
16 0 R % Alternate color space
20 0 R % Tint transformation function
]
endobj
16 0 obj % Alternate color space for DeviceN space
[ /CalRGB
<< /WhitePoint [1.0 1.0 1.0] >>
]
endobj
20 0 obj % Tint transformation function for DeviceN space
<< /FunctionType 4
/Domain [0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]
/Range [0.0 1.0 0.0 1.0 0.0 1.0]
/Length 44
>>
stream
{ 7 3 roll % Just discard first four values
pop pop pop pop
}
endstream
endobj
30 0 obj % Lookup table for Indexed color space
<< /Length 1975
/Filter [/ASCII85Decode /FlateDecode]
>>
stream
8;T1BB2"M7*!"psYBt1k\gY1T<D&tO]r*F7Hga*
…Additional data ( seven components for each table entry)…
endstream
endobj
GraphicsCHAPTER 4
254
As in the preceding examples, an Indexed color space based on a DeviceN space is
used to paint the grayscale image shown on the left in the plate with four colo-
rants: black and three PANTONE spot colors. The alternate color space is a sim-
ple calibrated RGB. Thus, the
DeviceN color space has seven components: the
four desired colorants plus the three components of the alternate space. The ex-
ample shows the image XObject (see Section 4.8.4, “Image Dictionaries”) repre-
senting the quadtone image, followed by the color space used to interpret the
image data. (See implementation note 48 in Appendix H.)
4.5.6 Overprint Control
The graphics state contains an overprint parameter, controlled by the OP and op
entries in a graphics state parameter dictionary. Overprint control is useful main-
ly on devices that produce true physical separations, but it is available on some
composite devices as well. Although the operation of this parameter is device-
dependent, it is described here rather than in the chapter on color rendering,
because it pertains to an aspect of painting in device color spaces that is impor-
tant to many applications.
Any painting operation marks some specific set of device colorants, depending
on the color space in which the painting takes place. In a
Separation or DeviceN
color space, the colorants to be marked are specified explicitly; in a device or
CIE-based color space, they are implied by the process color model of the output
device (see Chapter 6). The overprint parameter is a boolean flag that determines
how painting operations affect colorants other than those explicitly or implicitly
specified by the current color space.
If the overprint parameter is
false (the default value), painting a color in any color
space causes the corresponding areas of unspecified colorants to be erased (paint-
ed with a tint value of 0.0). The effect is that the color at any position on the page
is whatever was painted there last, which is consistent with the normal painting
behavior of the opaque imaging model.
If the overprint parameter is
true and the output device supports overprinting, no
such erasing actions are performed; anything previously painted in other colo-
rants is left undisturbed. Consequently, the color at a given position on the page
may be a combined result of several painting operations in different colorants.
The effect produced by such overprinting is device-dependent and is not defined
by the PDF language.
Color SpacesSECTION 4.5
255
Note: Not all devices support overprinting. Furthermore, many PostScript printers
support it only when separations are being produced, and not for composite output.
If overprinting is not supported, the value of the overprint parameter is ignored.
An additional graphics state parameter, the overprint mode (PDF 1.3),
affects the
interpretation of a tint value of 0.0 for a color component in a
DeviceCMYK color
space when overprinting is enabled. This parameter is controlled by the
OPM
entry in a graphics state parameter dictionary; it has an effect only when the
overprint parameter is
true, as described above.
When colors are specified in a
DeviceCMYK color space and the native color space
of the output device is also
DeviceCMYK, each of the source color components
controls the corresponding device colorant directly. Ordinarily, each source color
component value replaces the value previously painted for the corresponding de-
vice colorant, no matter what the new value is; this is the default behavior, speci-
fied by overprint mode 0.
When the overprint mode is 1 (also called nonzero overprint mode), a tint value of
0.0 for a source color component leaves the corresponding component of the
previously painted color unchanged. The effect is equivalent to painting in a
DeviceN color space that includes only those components whose values are non-
zero. For example, if the overprint parameter is
true and the overprint mode is 1,
the operation
0.2 0.3 0.0 1.0 k
is equivalent to
0.2 0.3 1.0 scn
in the color space shown in Example 4.22.
Example 4.22
10 0 obj % Color space
[ /DeviceN
[/Cyan /Magenta /Black]
/DeviceCMYK
15 0 R
]
endobj
GraphicsCHAPTER 4
256
15 0 obj % Tint transformation function
<< /FunctionType 4
/Domain [0.0 1.0 0.0 1.0 0.0 1.0]
/Range [0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]
/Length 13
>>
stream
{0 exch}
endstream
endobj
Nonzero overprint mode applies only to painting operations that use the current
color in the graphics state when the current color space is
DeviceCMYK (or is im-
plicitly converted to
DeviceCMYK; see “Implicit Conversion of CIE-Based Color
Spaces” on page 228). It does not apply to the painting of images or to any colors
that are the result of a computation, such as those in a shading pattern or conver-
sions from some other color space. It also does not apply if the device’s native col-
or space is not
DeviceCMYK; in that case, source colors must be converted to the
device’s native color space, and all components participate in the conversion,
whatever their values. (This is shown explicitly in the alternate color space and
tint transformation function of the
DeviceN color space in Example 4.22.)
See Section 7.6.3, “Overprinting and Transparency,” for further discussion of the
role of overprinting in the transparent imaging model.
4.5.7 Color Operators
Table 4.24 lists the PDF operators that control color spaces and color values. (Also
color-related is the graphics state operator
ri, listed in Table 4.7 on page 189 and
discussed under “Rendering Intents” on page 230.) Color operators may appear at
the page description level or inside text objects (see Figure 4.1 on page 167).
Color SpacesSECTION 4.5
257
TABLE 4.24 Color operators
OPERANDS OPERATOR DESCRIPTION
name
CS
(PDF 1.1) Set the current color space to use for stroking operations. The operand
name must be a name object. If the color space is one that can be specified by a
name and no additional parameters (
DeviceGray, DeviceRGB, DeviceCMYK, and
certain cases of
Pattern), the name may be specified directly. Otherwise, it must
be a name defined in the
ColorSpace subdictionary of the current resource dic-
tionary (see Section 3.7.2, “Resource Dictionaries”); the associated value is an ar-
ray describing the color space (see Section 4.5.2, “Color Space Families”).
Note: The names
DeviceGray, DeviceRGB, DeviceCMYK, and Pattern always iden-
tify the corresponding color spaces directly; they never refer to resources in the
ColorSpace subdictionary.
The
CS operator also sets the current stroking color to its initial value, which de-
pends on the color space:
• In a DeviceGray, DeviceRGB, CalGray, or CalRGB color space, the initial color
has all components equal to 0.0.
• In a DeviceCMYK color space, the initial color is [0.0 0.0 0.0 1.0].
• In a Lab or ICCBased color space, the initial color has all components equal to
0.0 unless that falls outside the intervals specified by the space’s
Range entry,
in which case the nearest valid value is substituted.
• In an Indexed color space, the initial color value is 0.
• In a Separation or DeviceN color space, the initial tint value is 1.0 for all colo-
rants.
• In a Pattern color space, the initial color is a pattern object that causes nothing
to be painted.
name
cs
(PDF 1.1) Same as CS but used for nonstroking operations.
c
1
…c
n
SC (PDF 1.1) Set the color to use for stroking operations in a device, CIE-based
(other than
ICCBased), or Indexed color space. The number of operands re-
quired and their interpretation depends on the current stroking color space:
• For DeviceGray, CalGray, and Indexed color spaces, one operand is required
(n = 1).
• For DeviceRGB, CalRGB, and Lab color spaces, three operands are required
(n = 3).
• For DeviceCMYK, four operands are required (n = 4).
GraphicsCHAPTER 4
258
Invoking operators that specify colors or other color-related parameters in the
graphics state is restricted in certain circumstances. This restriction occurs when
c
1
…c
n
c
1
…c
n
name
SCN
SCN
(PDF 1.2) Same as SC but also supports Pattern, Separation, DeviceN, and
ICCBased color spaces.
If the current stroking color space is a
Separation, DeviceN, or ICCBased color
space, the operands
c
1
…c
n
are numbers. The number of operands and their in-
terpretation depends on the color space.
If the current stroking color space is a
Pattern color space, name is the name of
an entry in the
Pattern subdictionary of the current resource dictionary (see
Section 3.7.2, “Resource Dictionaries”). For an uncolored tiling pattern
(
PatternType = 1 and PaintType = 2), c
1
…c
n
are component values specifying a
color in the pattern’s underlying color space. For other types of patterns, these
operands must not be specified.
c
1
…c
n
sc (PDF 1.1) Same as SC but used for nonstroking operations.
c
1
…c
n
c
1
…c
n
name
scn
scn
(PDF 1.2) Same as SCN but used for nonstroking operations.
gray
G
Set the stroking color space to DeviceGray (or the DefaultGray color space; see
“Default Color Spaces” on page 227) and set the gray level to use for stroking op-
erations.
gray is a number between 0.0 (black) and 1.0 (white).
gray
g
Same as G but used for nonstroking operations.
rgb RG Set the stroking color space to DeviceRGB (or the DefaultRGB color space; see
“Default Color Spaces” on page 227) and set the color to use for stroking opera-
tions. Each operand must be a number between 0.0 (minimum intensity) and 1.0
(maximum intensity).
rgb rg Same as RG but used for nonstroking operations.
cmyk K Set the stroking color space to DeviceCMYK (or the DefaultCMYK color space; see
“Default Color Spaces” on page 227) and set the color to use for stroking opera-
tions. Each operand must be a number between 0.0 (zero concentration) and 1.0
(maximum concentration). The behavior of this operator is affected by the over-
print mode (see Section 4.5.6, “Overprint Control”).
cmyk k Same as K but used for nonstroking operations.
OPERANDS OPERATOR DESCRIPTION
PatternsSECTION 4.6
259
defining graphical figures whose colors are to be specified separately each time
they are used. Specifically, the restriction applies in these circumstances:
• In any glyph description that uses the d1 operator (see Section 5.5.4, “Type 3
Fonts”)
• In the content stream of an uncolored tiling pattern (see “Uncolored Tiling Pat-
terns” on page 268)
In these circumstances, the following actions cause an error:
• Invoking any of the following operators:
CS scn K
cs G k
SC g ri
SCN RG sh
sc rg
• Invoking the gs operator with any of the following entries in the graphics state
parameter dictionary:
TR BG UCR
TR2 BG2 UCR2
HT
• Painting an image. However, painting an image mask (see “Stencil Masking” on
page 320) is permitted because it does not specify colors; instead, it designates
places where the current color is to be painted.
4.6 Patterns
When operators such as S (stroke), f (fill), and Tj (show text) paint an area of the
page with the current color, they ordinarily apply a single color that covers the
area uniformly. However, it is also possible to apply “paint” that consists of a re-
peating graphical figure or a smoothly varying color gradient instead of a simple
color. Such a repeating figure or smooth gradient is called a pattern. Patterns are
quite general, and have many uses; for example, they can be used to create various
graphical textures, such as weaves, brick walls, sunbursts, and similar geometrical
and chromatic effects. (See implementation note 49 in Appendix H.)
GraphicsCHAPTER 4
260
Patterns come in two varieties:
• Tiling patterns consist of a small graphical figure (called a pattern cell) that is
replicated at fixed horizontal and vertical intervals to fill the area to be painted.
The graphics objects to use for tiling are described by a content stream.
• Shading patterns define a gradient fill that produces a smooth transition
between colors across the area. The color to use is specified as a function of
position using any of a variety of methods.
Note: The ability to paint with patterns is a feature of PDF 1.2 (tiling patterns) and
PDF 1.3 (shading patterns). With some effort, it is possible to achieve a limited form
of tiling patterns in PDF 1.1 by defining them as character glyphs in a special font
and painting them repeatedly with the
Tj operator. Another technique, defining
patterns as halftone screens, is not recommended because the effects produced are
device-dependent.
Patterns are specified in a special family of color spaces named
Pattern. These
spaces use pattern objects as the equivalent of color values instead of the numeric
component values used with other spaces. A pattern object may be a dictionary or
a stream, depending on the type of pattern; the term pattern dictionary is used ge-
nerically throughout this section to refer to either a dictionary object or the dic-
tionary portion of a stream object. (Those pattern objects that are streams are
specifically identified as such in the descriptions of particular pattern types; un-
less otherwise stated, they are understood to be simple dictionaries instead.) This
section describes
Pattern color spaces and the specification of color values within
them. See Section 4.5, “Color Spaces,” for information about color spaces and col-
or values in general and Section 7.5.6, “Patterns and Transparency,” for further
discussion of the treatment of patterns in the transparent imaging model.
4.6.1 General Properties of Patterns
A pattern dictionary contains descriptive information defining the appearance
and properties of a pattern. All pattern dictionaries contain an entry named
PatternType, whose value identifies the kind of pattern the dictionary describes:
type 1 for a tiling pattern or type 2 for a shading pattern. The remaining contents
of the dictionary depend on the pattern type and are detailed below in the sec-
tions on individual pattern types.
PatternsSECTION 4.6
261
All patterns are treated as colors; a Pattern color space is established with the CS
or cs operator just like other color spaces, and a particular pattern is installed as
the current color with the
SCN or scn operator (see Table 4.24 on page 257).
A pattern’s appearance is described with respect to its own internal coordinate
system. Every pattern has a pattern matrix, a transformation matrix that maps the
pattern’s internal coordinate system to the default coordinate system of the pat-
tern’s parent content stream (the content stream in which the pattern is defined as
a resource). The concatenation of the pattern matrix with that of the parent con-
tent stream establishes the pattern coordinate space, within which all graphics ob-
jects in the pattern are interpreted.
For example, if a pattern is used on a page, the pattern appears in the
Pattern sub-
dictionary of that page’s resource dictionary, and the pattern matrix maps pattern
space to the default (initial) coordinate space of the page. Changes to the page’s
transformation matrix that occur within the page’s content stream, such as rota-
tion and scaling, have no effect on the pattern; it maintains its original relation-
ship to the page no matter where on the page it is used. Similarly, if a pattern is
used within a form XObject (see Section 4.9, “Form XObjects”), the pattern ma-
trix maps pattern space to the form’s default user space (that is, the form co-
ordinate space at the time the form is painted with the
Do operator). A pattern
may be used within another pattern; the inner pattern’s matrix defines its
relationship to the pattern space of the outer pattern.
Note: PostScript allows a pattern to be defined in one context but used in another.
For example, a pattern might be defined on a page (that is, its pattern matrix maps
the pattern coordinate space to the user space of the page) but be used in a form on
that page, so that its relationship to the page is independent of each individual
placement of the form. PDF does not support this feature; in PDF, all patterns are
local to the context in which they are defined.
4.6.2 Tiling Patterns
A tiling pattern consists of a small graphical figure called a pattern cell. Painting
with the pattern replicates the cell at fixed horizontal and vertical intervals to fill
an area. The effect is as if the figure were painted on the surface of a clear glass
tile, identical copies of which were then laid down in an array covering the area
and trimmed to its boundaries. This process is called tiling the area.
GraphicsCHAPTER 4
262
The pattern cell can include graphical elements such as filled areas, text, and sam-
pled images. Its shape need not be rectangular, and the spacing of tiles can differ
from the dimensions of the cell itself. When performing painting operations such
as
S (stroke) or f (fill), the application paints the cell on the current page as many
times as necessary to fill an area. The order in which individual tiles (instances of
the cell) are painted is unspecified and unpredictable; it is inadvisable for the fig-
ures on adjacent tiles to overlap.
The appearance of the pattern cell is defined by a content stream containing the
painting operators needed to paint one instance of the cell. Besides the usual en-
tries common to all streams (see Table 3.4 on page 38), this stream’s dictionary
has the additional entries listed in Table 4.25.
TABLE 4.25 Additional entries specific to a type 1 pattern dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
Pattern for a pattern dictionary.
PatternType
integer (Required) A code identifying the type of pattern that this dictionary de-
scribes; must be 1 for a tiling pattern.
PaintType
integer (Required) A code that determines how the color of the pattern cell is to be
specified:
1 Colored tiling pattern. The pattern’s content stream specifies the col-
ors used to paint the pattern cell. When the content stream begins ex-
ecution, the current color is the one that was initially in effect in the
pattern’s parent content stream. (This is similar to the definition of
the pattern matrix; see Section 4.6.1, “General Properties of Pat-
terns.”)
2 Uncolored tiling pattern. The pattern’s content stream does not specify
any color information. Instead, the entire pattern cell is painted with
a separately specified color each time the pattern is used. Essentially,
the content stream describes a stencil through which the current col-
or is to be poured. The content stream must not invoke operators that
specify colors or other color-related parameters in the graphics state;
otherwise, an error occurs (see Section 4.5.7, “Color Operators”). The
content stream may paint an image mask, however, since it does not
specify any color information (see “Stencil Masking” on page 320).
PatternsSECTION 4.6
263
The pattern dictionary’s BBox, XStep, and YStep values are interpreted in the pat-
tern coordinate system, and the graphics objects in the pattern’s content stream
are defined with respect to that coordinate system. The placement of pattern cells
in the tiling is based on the location of one key pattern cell, which is then dis-
TilingType
integer (Required) A code that controls adjustments to the spacing of tiles relative to
the device pixel grid:
1 Constant spacing. Pattern cells are spaced consistently—that is, by a
multiple of a device pixel. To achieve this, the application may need
to distort the pattern cell slightly by making small adjustments to
XStep, YStep, and the transformation matrix. The amount of distor-
tion does not exceed 1 device pixel.
2 No distortion. The pattern cell is not distorted, but the spacing
between pattern cells may vary by as much as 1 device pixel, both
horizontally and vertically, when the pattern is painted. This achieves
the spacing requested by
XStep and YStep on average but not neces-
sarily for each individual pattern cell.
3 Constant spacing and faster tiling. Pattern cells are spaced consistently
as in tiling type 1 but with additional distortion permitted to enable a
more efficient implementation.
BBox
rectangle (Required) An array of four numbers in the pattern coordinate system giving
the coordinates of the left, bottom, right, and top edges, respectively, of the
pattern cell’s bounding box. These boundaries are used to clip the pattern cell.
XStep
number (Required) The desired horizontal spacing between pattern cells, measured in
the pattern coordinate system.
YStep
number (Required) The desired vertical spacing between pattern cells, measured in
the pattern coordinate system. Note that
XStep and YStep may differ from the
dimensions of the pattern cell implied by the
BBox entry. This allows tiling
with irregularly shaped figures.
XStep and YStep may be either positive or
negative but not zero.
Resources
dictionary (Required) A resource dictionary containing all of the named resources
required by the pattern’s content stream (see Section 3.7.2, “Resource Dic-
tionaries”).
Matrix
array (Optional) An array of six numbers specifying the pattern matrix (see Section
4.6.1, “General Properties of Patterns”). Default value: the identity matrix
[100100].
KEY TYPE VALUE
GraphicsCHAPTER 4
264
placed by multiples of XStep and YStep to replicate the pattern. The origin of the
key pattern cell coincides with the origin of the pattern coordinate system. The
phase of the tiling can be controlled by the translation components of the
Matrix
entry in the pattern dictionary.
The first step in painting with a tiling pattern is to establish the pattern as the cur-
rent color in the graphics state. Subsequent painting operations tile the painted
areas with the pattern cell described by the pattern’s content stream. To obtain the
pattern cell, the application performs these steps:
1. Saves the current graphics state (as if by invoking the
q operator)
2. Installs the graphics state that was in effect at the beginning of the pattern’s
parent content stream, with the current transformation matrix altered by the
pattern matrix as described in Section 4.6.1, “General Properties of Patterns”
3. Paints the graphics objects specified in the pattern’s content stream
4. Restores the saved graphics state (as if by invoking the
Q operator)
Note: The pattern’s content stream should not set any of the device-dependent
parameters in the graphics state (see Table 4.3 on page 182) because it may result in
incorrect output.
Colored Tiling Patterns
A colored tiling pattern is a pattern whose color is self-contained. In the course of
painting the pattern cell, the pattern’s content stream explicitly sets the color of
each graphical element it paints. A single pattern cell can contain elements that
are painted different colors; it can also contain sampled grayscale or color images.
This type of pattern is identified by a pattern type of 1 and a paint type of 1 in the
pattern dictionary.
When the current color space is a
Pattern space, a colored tiling pattern can be
selected as the current color by supplying its name as the single operand to the
SCN or scn operator. This name must be the key of an entry in the Pattern subdic-
tionary of the current resource dictionary (see Section 3.7.2, “Resource Diction-
aries”), whose value is the stream object representing the pattern. Since the
PatternsSECTION 4.6
265
pattern defines its own color information, no additional operands representing
color components are specified to
SCN or scn. For example, if P1 is the name of a
pattern resource in the current resource dictionary, the following code establishes
it as the current nonstroking color:
/Pattern cs
/P1 scn
Subsequent executions of nonstroking painting operators, such as f (fill), Tj (show
text), or
Do (paint external object) with an image mask, use the designated pat-
tern to tile the areas to be painted.
Example 4.23 defines a page (object 5) that paints three circles and a triangle
using a colored tiling pattern (object 15) over a yellow background. The pattern
consists of the symbols for the four suits of playing cards (spades, hearts, dia-
monds, and clubs), which are character glyphs taken from the
ZapfDingbats font
(see Section D.4, “ZapfDingbats Set and Encoding”); the pattern’s content stream
specifies the color of each glyph. Plate 8 shows the results.
Example 4.23
5 0 obj % Page object
<< /Type /Page
/Parent 2 0 R
/Resources 10 0 R
/Contents 30 0 R
/CropBox [0 0 225 225]
>>
endobj
10 0 obj % Resource dictionary for page
<< /Pattern << /P1 15 0 R >>
>>
endobj
GraphicsCHAPTER 4
266
15 0 obj % Pattern definition
<< /Type /Pattern
/PatternType 1 % Tiling pattern
/PaintType 1 % Colored
/TilingType 2
/BBox [0 0 100 100]
/XStep 100
/YStep 100
/Resources 16 0 R
/Matrix [0.4 0.0 0.0 0.4 0.0 0.0]
/Length 183
>>
stream
BT % Begin text object
/F1 1 Tf % Set text font and size
64 0 0 64 7.1771 2.4414 Tm % Set text matrix
0 Tc % Set character spacing
0 Tw % Set word spacing
1.0 0.0 0.0 rg % Set nonstroking color to red
(\001) Tj % Show spade glyph
0.7478 0.007 TD % Move text position
0.0 1.0 0.0 rg % Set nonstroking color to green
(\002) Tj % Show heart glyph
0.7323 0.7813 TD % Move text position
0.0 0.0 1.0 rg % Set nonstroking color to blue
(\003) Tj % Show diamond glyph
0.6913 0.007 TD % Move text position
0.0 0.0 0.0 rg % Set nonstroking color to black
(\004) Tj % Show club glyph
ET % End text object
endstream
endobj
16 0 obj % Resource dictionary for pattern
<< /Font << /F1 20 0 R >>
>>
endobj
20 0 obj % Font for pattern
<< /Type /Font
/Subtype /Type1
/Encoding 21 0 R
/BaseFont /ZapfDingbats
>>
endobj
PatternsSECTION 4.6
267
21 0 obj % Font encoding
<< /Type /Encoding
/Differences [1 /a109 /a110 /a111 /a112]
>>
endobj
30 0 obj % Contents of page
<< /Length 1252 >>
stream
0.0 G % Set stroking color to black
1.0 1.0 0.0 rg % Set nonstroking color to yellow
25 175 175 150 re % Construct rectangular path
f % Fill path
/Pattern cs % Set pattern color space
/P1 scn % Set pattern as nonstroking color
99.92 49.92 m % Start new path
99.92 77.52 77.52 99.92 49.92 99.92 c % Construct lower-left circle
22.32 99.92 0.08 77.52 0.08 49.92 c
0.08 22.32 22.32 0.08 49.92 0.08 c
77.52 0.08 99.92 22.32 99.92 49.92 c
B % Fill and stroke path
224.96 49.92 m % Start new path
224.96 77.52 202.56 99.92 174.96 99.92 c % Construct lower-right circle
147.36 99.92 124.96 77.52 124.96 49.92 c
124.96 22.32 147.36 -0.08 174.96 0.08 c
202.56 0.08 224.96 22.32 224.96 49.92 c
B % Fill and stroke path
87.56 201.70 m % Start new path
63.66 187.90 55.46 157.32 69.26 133.40 c % Construct upper circle
83.06 109.50 113.66 101.30 137.56 115.10 c
161.46 128.90 169.66 159.50 155.86 183.40 c
142.06 207.30 111.46 215.50 87.56 201.70 c
B % Fill and stroke path
50 50 m % Start new path
175 50 l % Construct triangular path
112.5 158.253 l
b % Close, fill, and stroke path
endstream
endobj
GraphicsCHAPTER 4
268
Several features of Example 4.23 are noteworthy:
• The three circles and the triangle are painted with the same pattern. The pat-
tern cells align, even though the circles and triangle are not aligned with re-
spect to the pattern cell. For example, the position of the blue diamonds varies
relative to the three circles.
• The pattern cell does not completely cover the tile: it leaves the spaces between
the glyphs unpainted. When the tiling pattern is used as a color, the existing
background (the yellow rectangle) shows through these unpainted areas.
Uncolored Tiling Patterns
An uncolored tiling pattern is a pattern that has no inherent color: the color must
be specified separately whenever the pattern is used. It provides a way to tile dif-
ferent regions of the page with pattern cells having the same shape but different
colors. This type of pattern is identified by a pattern type of 1 and a paint type of
2 in the pattern dictionary. The pattern’s content stream does not explicitly speci-
fy any colors; it can paint an image mask (see “Stencil Masking” on page 320) but
no other kind of image.
A
Pattern color space representing an uncolored tiling pattern requires a parame-
ter: an object identifying the underlying color space in which the actual color of
the pattern is to be specified. The underlying color space is given as the second
element of the array that defines the
Pattern color space. For example, the array
[/Pattern /DeviceRGB]
defines a Pattern color space with DeviceRGB as its underlying color space.
Note: The underlying color space cannot be another
Pattern color space.
Operands supplied to the
SCN or scn operator in such a color space must include
a color value in the underlying color space, specified by one or more numeric
color components, as well as the name of a pattern object representing an un-
colored tiling pattern. For example, if the current resource dictionary (see Section
3.7.2, “Resource Dictionaries”) defines
Cs3 as the name of a ColorSpace resource
PatternsSECTION 4.6
269
whose value is the Pattern color space shown above and P2 as a Pattern resource
denoting an uncolored tiling pattern, the code
/Cs3 cs
0.30 0.75 0.21 /P2 scn
establishes Cs3 as the current nonstroking color space and P2 as the current non-
stroking color, to be painted in the color represented by the specified components
in the
DeviceRGB color space. Subsequent executions of nonstroking painting op-
erators, such as
f (fill), Tj (show text), and Do (paint external object) with an im-
age mask, use the designated pattern and color to tile the areas to be painted. The
same pattern can be used repeatedly with a different color each time.
Example 4.24 is similar to Example 4.23 on page 265, except that it uses an uncol-
ored tiling pattern to paint the three circles and the triangle, each in a different
color (see Plate 9). To do so, it supplies four operands each time it invokes the
scn
operator: three numbers denoting the color components in the underlying
DeviceRGB color space, along with the name of the pattern.
Example 4.24
5 0 obj % Page object
<< /Type /Page
/Parent 2 0 R
/Resources 10 0 R
/Contents 30 0 R
/CropBox [0 0 225 225]
>>
endobj
10 0 obj % Resource dictionary for page
<< /ColorSpace << /Cs12 12 0 R >>
/Pattern << /P1 15 0 R >>
>>
endobj
12 0 obj % Color space
[/Pattern /DeviceRGB]
endobj
GraphicsCHAPTER 4
270
15 0 obj % Pattern definition
<< /Type /Pattern
/PatternType 1 % Tiling pattern
/PaintType 2 % Uncolored
/TilingType 2
/BBox [0 0 100 100]
/XStep 100
/YStep 100
/Resources 16 0 R
/Matrix [0.4 0.0 0.0 0.4 0.0 0.0]
/Length 127
>>
stream
BT % Begin text object
/F1 1 Tf % Set text font and size
64 0 0 64 7.1771 2.4414 Tm % Set text matrix
0 Tc % Set character spacing
0 Tw % Set word spacing
(\001) Tj % Show spade glyph
0.7478 0.007 TD % Move text position
(\002) Tj % Show heart glyph
0.7323 0.7813 TD % Move text position
(\003) Tj % Show diamond glyph
0.6913 0.007 TD % Move text position
(\004) Tj % Show club glyph
ET % End text object
endstream
endobj
16 0 obj % Resource dictionary for pattern
<< /Font << /F1 20 0 R >>
>>
endobj
20 0 obj % Font for pattern
<< /Type /Font
/Subtype /Type1
/Encoding 21 0 R
/BaseFont /ZapfDingbats
>>
endobj
PatternsSECTION 4.6
271
21 0 obj % Font encoding
<< /Type /Encoding
/Differences [1 /a109 /a110 /a111 /a112]
>>
endobj
30 0 obj % Contents of page
<< /Length 1316 >>
stream
0.0 G % Set stroking color to black
1.0 1.0 0.0 rg % Set nonstroking color to yellow
25 175 175 150 re % Construct rectangular path
f % Fill path
/Cs12 cs % Set pattern color space
0.77 0.20 0.00 /P1 scn % Set nonstroking color and pattern
99.92 49.92 m % Start new path
99.92 77.52 77.52 99.92 49.92 99.92 c % Construct lower-left circle
22.32 99.92 0.08 77.52 0.08 49.92 c
0.08 22.32 22.32 0.08 49.92 0.08 c
77.52 0.08 99.92 22.32 99.92 49.92 c
B % Fill and stroke path
0.2 0.8 0.4 /P1 scn % Change nonstroking color
224.96 49.92 m % Start new path
224.96 77.52 202.56 99.92 174.96 99.92 c % Construct lower-right circle
147.36 99.92 124.96 77.52 124.96 49.92 c
124.96 22.32 147.36 -0.08 174.96 0.08 c
202.56 0.08 224.96 22.32 224.96 49.92 c
B % Fill and stroke path
0.3 0.7 1.0 /P1 scn % Change nonstroking color
87.56 201.70 m % Start new path
63.66 187.90 55.46 157.30 69.26 133.40 c % Construct upper circle
83.06 109.50 113.66 101.30 137.56 115.10 c
161.46 128.90 169.66 159.50 155.86 183.40 c
142.06 207.30 111.46 215.50 87.56 201.70 c
B % Fill and stroke path
0.5 0.2 1.0 /P1 scn % Change nonstroking color
50 50 m % Start new path
175 50 l % Construct triangular path
112.5 158.253 l
b % Close, fill, and stroke path
endstream
endobj
GraphicsCHAPTER 4
272
4.6.3 Shading Patterns
Shading patterns (PDF 1.3) provide a smooth transition between colors across an
area to be painted, independent of the resolution of any particular output device
and without specifying the number of steps in the color transition. Patterns of
this type are described by pattern dictionaries with a pattern type of 2. Table 4.26
shows the contents of this type of dictionary.
TABLE 4.26 Entries in a type 2 pattern dictionary
The most significant entry is Shading, whose value is a shading object defining
the properties of the shading pattern’s gradient fill. This is a complex “paint” that
determines the type of color transition the shading pattern produces when paint-
ed across an area. A shading object may be a dictionary or a stream, depending
on the type of shading; the term shading dictionary is used generically throughout
this section to refer to either a dictionary object or the dictionary portion of a
stream object. (Those shading objects that are streams are specifically identified
as such in the descriptions of particular shading types; unless otherwise stated,
they are understood to be simple dictionaries instead.)
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
Pattern for a pattern dictionary.
PatternType
integer (Required) A code identifying the type of pattern that this dictionary de-
scribes; must be 2 for a shading pattern.
Shading
dictionary
or stream
(Required) A shading object (see below) defining the shading pattern’s gradi-
ent fill. The contents of the dictionary consist of the entries in Table 4.28 and
those in one of Tables 4.29 to 4.34.
Matrix
array (Optional) An array of six numbers specifying the pattern matrix (see Section
4.6.1, “General Properties of Patterns”). Default value: the identity matrix
[100100].
ExtGState
dictionary (Optional) A graphics state parameter dictionary (see Section 4.3.4, “Graphics
State Parameter Dictionaries”) containing graphics state parameters to be put
into effect temporarily while the shading pattern is painted. Any parameters
that are not so specified are inherited from the graphics state that was in ef-
fect at the beginning of the content stream in which the pattern is defined as a
resource.
PatternsSECTION 4.6
273
By setting a shading pattern as the current color in the graphics state, a PDF con-
tent stream can use it with painting operators such as
f (fill), S (stroke), Tj (show
text), or
Do (paint external object) with an image mask to paint a path, character
glyph, or mask with a smooth color transition. When a shading is used in this
way, the geometry of the gradient fill is independent of that of the object being
painted.
Shading Operator
When the area to be painted is a relatively simple shape whose geometry is the
same as that of the gradient fill itself, the
sh operator can be used instead of the
usual painting operators.
sh accepts a shading dictionary as an operand and
applies the corresponding gradient fill directly to current user space. This opera-
tor does not require the creation of a pattern dictionary or a path and works with-
out reference to the current color in the graphics state. Table 4.27 describes the
sh
operator.
Note: Patterns defined by type 2 pattern dictionaries do not tile. To create a tiling
pattern containing a gradient fill, invoke the
sh operator from within the content
stream of a type 1 (tiling) pattern.
TABLE 4.27 Shading operator
OPERANDS OPERATOR DESCRIPTION
name
sh
(PDF 1.3) Paint the shape and color shading described by a shading dictionary, sub-
ject to the current clipping path. The current color in the graphics state is neither
used nor altered. The effect is different from that of painting a path using a shading
pattern as the current color.
name is the name of a shading dictionary resource in the Shading subdictionary of
the current resource dictionary (see Section 3.7.2, “Resource Dictionaries”). All co-
ordinates in the shading dictionary are interpreted relative to the current user space.
(By contrast, when a shading dictionary is used in a type 2 pattern, the coordinates
are expressed in pattern space.) All colors are interpreted in the color space identi-
fied by the shading dictionary’s
ColorSpace entry (see Table 4.28). The Background
entry, if present, is ignored.
This operator should be applied only to bounded or geometrically defined shadings.
If applied to an unbounded shading, it paints the shading’s gradient fill across the
entire clipping region, which may be time-consuming.
GraphicsCHAPTER 4
274
Shading Dictionaries
A shading dictionary specifies details of a particular gradient fill, including the
type of shading to be used, the geometry of the area to be shaded, and the geome-
try of the gradient fill. Various shading types are available, depending on the val-
ue of the dictionary’s
ShadingType entry:
• Function-based shadings (type 1) define the color of every point in the domain
using a mathematical function (not necessarily smooth or continuous).
• Axial shadings (type 2) define a color blend along a line between two points,
optionally extended beyond the boundary points by continuing the boundary
colors.
• Radial shadings (type 3) define a blend between two circles, optionally ex-
tended beyond the boundary circles by continuing the boundary colors. This
type of shading is commonly used to represent three-dimensional spheres and
cones.
• Free-form Gouraud-shaded triangle meshes (type 4) define a common construct
used by many three-dimensional applications to represent complex colored
and shaded shapes. Vertices are specified in free-form geometry.
• Lattice-form Gouraud-shaded triangle meshes (type 5) are based on the same
geometrical construct as type 4 but with vertices specified as a pseudo-
rectangular lattice.
• Coons patch meshes (type 6) construct a shading from one or more color
patches, each bounded by four cubic Bézier curves.
• Tensor-product patch meshes (type 7) are similar to type 6 but with additional
control points in each patch, affording greater control over color mapping.
Table 4.28 shows the entries that all shading dictionaries share in common;
entries specific to particular shading types are described in the relevant sections
below.
Note: The term target coordinate space, used in many of the following descriptions,
refers to the coordinate space into which a shading is painted. For shadings used
with a type 2 pattern dictionary, this is the pattern coordinate space, discussed in
Section 4.6.1, “General Properties of Patterns.” For shadings used directly with the
sh operator, it is the current user space.
PatternsSECTION 4.6
275
TABLE 4.28 Entries common to all shading dictionaries
KEY TYPE VALUE
ShadingType
integer (Required) The shading type:
1 Function-based shading
2 Axial shading
3 Radial shading
4 Free-form Gouraud-shaded triangle mesh
5 Lattice-form Gouraud-shaded triangle mesh
6 Coons patch mesh
7 Tensor-product patch mesh
ColorSpace
name or
array
(Required) The color space in which color values are expressed. This may be
any device, CIE-based, or special color space except a
Pattern space. See
“Color Space: Special Considerations” on page 276 for further information.
Background
array (Optional) An array of color components appropriate to the color space, spec-
ifying a single background color value. If present, this color is used, before
any painting operation involving the shading, to fill those portions of the area
to be painted that lie outside the bounds of the shading object. In the opaque
imaging model, the effect is as if the painting operation were performed
twice: first with the background color and then with the shading.
Note: The background color is applied only when the shading is used as part of
a shading pattern, not when it is painted directly with the
sh operator.
BBox
rectangle (Optional) An array of four numbers giving the left, bottom, right, and top
coordinates, respectively, of the shading’s bounding box. The coordinates are
interpreted in the shading’s target coordinate space. If present, this bounding
box is applied as a temporary clipping boundary when the shading is painted,
in addition to the current clipping path and any other clipping boundaries in
effect at that time.
AntiAlias
boolean (Optional) A flag indicating whether to filter the shading function to prevent
aliasing artifacts. The shading operators sample shading functions at a rate
determined by the resolution of the output device. Aliasing can occur if the
function is not smooth—that is, if it has a high spatial frequency relative to
the sampling rate. Anti-aliasing can be computationally expensive and is usu-
ally unnecessary, since most shading functions are smooth enough or are
sampled at a high enough frequency to avoid aliasing effects. Anti-aliasing
may not be implemented on some output devices, in which case this flag is ig-
nored. Default value:
false.
GraphicsCHAPTER 4
276
Shading types 4 to 7 are defined by a stream containing descriptive data charac-
terizing the shading’s gradient fill. In these cases, the shading dictionary is also a
stream dictionary and can contain any of the standard entries common to all
streams (see Table 3.4 on page 38). In particular, it always includes a
Length en-
try, which is required for all streams.
In addition, some shading dictionaries also include a
Function entry whose value
is a function object (dictionary or stream) defining how colors vary across the
area to be shaded. In such cases, the shading dictionary usually defines the geom-
etry of the shading, and the function defines the color transitions across that
geometry. The function is required for some types of shading and optional for
others. Functions are described in detail in Section 3.9, “Functions.”
Note: Discontinuous color transitions, or those with high spatial frequency, may ex-
hibit aliasing effects when painted at low effective resolutions.
Color Space: Special Considerations
Conceptually, a shading determines a color value for each individual point within
the area to be painted. In practice, however, the shading may actually be used to
compute color values only for some subset of the points in the target area, with
the colors of the intervening points determined by interpolation between the
ones computed. Consumer applications are free to use this strategy as long as the
interpolated color values approximate those defined by the shading to within the
smoothness tolerance specified in the graphics state (see Section 6.5.2, “Smooth-
ness Tolerance”). The
ColorSpace entry common to all shading dictionaries not
only defines the color space in which the shading specifies its color values but
also determines the color space in which color interpolation is performed.
Note: Some shading types (4 to 7) perform interpolation on a parametric value sup-
plied as input to the shading’s color function, as described in the relevant sections
below. This form of interpolation is conceptually distinct from the interpolation
described here, which operates on the output color values produced by the color
function and takes place within the shading’s target color space.
Gradient fills between colors defined by most shadings are implemented using a
variety of interpolation algorithms, and these algorithms are sensitive to the char-
acteristics of the color space. Linear interpolation, for example, may have observ-
ably different results when applied in a
DeviceCMYK color space than in a Lab
color space, even if the starting and ending colors are perceptually identical. The
PatternsSECTION 4.6
277
difference arises because the two color spaces are not linear relative to each other.
Shadings are rendered according to the following rules:
• If ColorSpace is a device color space different from the native color space of the
output device, color values in the shading are converted to the native color
space using the standard conversion formulas described in Section 6.2, “Con-
versions among Device Color Spaces.” To optimize performance, these conver-
sions may take place at any time (before or after any interpolation on the color
values in the shading). Thus, shadings defined with device color spaces may
have color gradient fills that are less accurate and somewhat device-dependent.
(This does not apply to axial and radial shadings—shading types 2 and 3—be-
cause those shading types perform gradient fill calculations on a single variable
and then convert to parametric colors.)
• If ColorSpace is a CIE-based color space, all gradient fill calculations are per-
formed in that space. Conversion to device colors occurs only after all interpo-
lation calculations have been performed. Thus, the color gradients are device-
independent for the colors generated at each point.
• If ColorSpace is a Separation or DeviceN color space and the specified colo-
rants are supported, no color conversion calculations are needed. If the speci-
fied colorants are not supported (so that the space’s alternate color space must
be used), gradient fill calculations are performed in the designated
Separation
or DeviceN color space before conversion to the alternate space. Thus, non-
linear tint transformation functions are accommodated for the best possible
representation of the shading.
• If ColorSpace is an Indexed color space, all color values specified in the shading
are immediately converted to the base color space. Depending on whether the
base color space is a device or CIE-based space, gradient fill calculations are
performed as stated above. Interpolation never occurs in an
Indexed color
space, which is quantized and therefore inappropriate for calculations that as-
sume a continuous range of colors. For similar reasons, an
Indexed color space
is not allowed in any shading whose color values are generated by a function;
this rule applies to any shading dictionary that contains a
Function entry.
Shading Types
In addition to the entries listed in Table 4.28, all shading dictionaries have entries
specific to the type of shading they represent, as indicated by the value of their
GraphicsCHAPTER 4
278
ShadingType entry. The following sections describe the available shading types
and the dictionary entries specific to each.
Type 1 (Function-Based) Shadings
In type 1 (function-based) shadings, the color at every point in the domain is
defined by a specified mathematical function. The function need not be smooth
or continuous. This type is the most general of the available shading types and is
useful for shadings that cannot be adequately described with any of the other
types. Table 4.29 shows the shading dictionary entries specific to this type of
shading, in addition to those common to all shading dictionaries (Table 4.28).
Note: This type of shading cannot be used with an
Indexed color space.
TABLE 4.29 Additional entries specific to a type 1 shading dictionary
The domain rectangle (Domain) establishes an internal coordinate space for the
shading that is independent of the target coordinate space in which it is to be
painted. The color function(s) (
Function) specify the color of the shading at each
point within this domain rectangle. The transformation matrix (
Matrix) then
maps the domain rectangle into a corresponding rectangle or parallelogram in
the target coordinate space. Points within the shading’s bounding box (
BBox) that
fall outside this transformed domain rectangle are painted with the shading’s
KEY TYPE VALUE
Domain
array (Optional) An array of four numbers [x
min
x
max
y
min
y
max
] specifying the
rectangular domain of coordinates over which the color function(s) are defined.
Default value:
[0.0 1.0 0.0 1.0].
Matrix
array (Optional) An array of six numbers specifying a transformation matrix mapping
the coordinate space specified by the
Domain entry into the shading’s target co-
ordinate space. For example, to map the domain rectangle
[0.0 1.0 0.0 1.0] to a
1-inch square with lower-left corner at coordinates (100, 100) in default user
space, the
Matrix value would be [72 0 0 72 100 100]. Default value: the iden-
tity matrix
[100100].
Function
function (Required) A 2-in, n-out function or an array of n 2-in, 1-out functions (where n
is the number of color components in the shading dictionary’s color space). Each
function’s domain must be a superset of that of the shading dictionary. If the val-
ue returned by the function for a given color component is out of range, it is ad-
justed to the nearest valid value.
PatternsSECTION 4.6
279
background color (Background); if the shading dictionary has no Background
entry, such points are left unpainted. If the function is undefined at any point
within the declared domain rectangle, an error may occur, even if the corre-
sponding transformed point falls outside the shading’s bounding box.
Type 2 (Axial) Shadings
Type 2 (axial) shadings define a color blend that varies along a linear axis be-
tween two endpoints and extends indefinitely perpendicular to that axis. The
shading may optionally be extended beyond either or both endpoints by continu-
ing the boundary colors indefinitely. Table 4.30 shows the shading dictionary en-
tries specific to this type of shading, in addition to those common to all shading
dictionaries (Table 4.28).
Note: This type of shading cannot be used with an
Indexed color space.
TABLE 4.30 Additional entries specific to a type 2 shading dictionary
The color blend is accomplished by linearly mapping each point (x, y) along the
axis between the endpoints (x
0
, y
0
) and (x
1
, y
1
) to a corresponding point in the
KEY TYPE VALUE
Coords
array (Required) An array of four numbers [x
0
y
0
x
1
y
1
] specifying the starting and
ending coordinates of the axis, expressed in the shading’s target coordinate
space.
Domain
array (Optional) An array of two numbers [t
0
t
1
] specifying the limiting values of a
parametric variable t. The variable is considered to vary linearly between these
two values as the color gradient varies between the starting and ending points of
the axis. The variable t becomes the input argument to the color function(s). De-
fault value:
[0.0 1.0].
Function
function (Required) A 1-in, n-out function or an array of n 1-in, 1-out functions (where n
is the number of color components in the shading dictionary’s color space). The
function(s) are called with values of the parametric variable t in the domain de-
fined by the
Domain entry. Each function’s domain must be a superset of that of
the shading dictionary. If the value returned by the function for a given color
component is out of range, it is adjusted to the nearest valid value.
Extend
array (Optional) An array of two boolean values specifying whether to extend the
shading beyond the starting and ending points of the axis, respectively. Default
value:
[false false].
GraphicsCHAPTER 4
280
domain specified by the shading dictionary’s Domain entry. The points (0, 0) and
(1, 0) in the domain correspond respectively to (x
0
, y
0
) and (x
1
, y
1
) on the axis.
Since all points along a line in domain space perpendicular to the line from (0, 0)
to (1, 0) have the same color, only the new value of x needs to be computed:
The value of the parametric variable t is then determined from x as follows:
• For 0 x 1, t = t
0
+ (t
1
t
0
) × x.
• For x < 0, if the first element of the Extend array is true, then t = t
0
; otherwise,
t is undefined and the point is left unpainted.
• For x > 1, if the second element of the Extend array is true, then t = t
1
; other-
wise, t is undefined and the point is left unpainted.
The resulting value of t is passed as input to the function(s) defined by the shad-
ing dictionary’s
Function entry, yielding the component values of the color with
which to paint the point (x, y).
Plate 10 shows three examples of the use of an axial shading to fill a rectangle and
display text. The area to be filled extends beyond the shading’s bounding box.
The shading is the same in all three cases, except for the values of the
Background
and Extend entries in the shading dictionary. In the first example, the shading is
not extended at either end and no background color is specified; therefore, the
shading is clipped to its bounding box at both ends. The second example still has
no background color specified, but the shading is extended at both ends; the re-
sult is to fill the remaining portions of the filled area with the colors defined at the
ends of the shading. In the third example, the shading is extended at both ends
and a background color is specified; therefore, the background color is used for
the portions of the filled area beyond the ends of the shading.
Type 3 (Radial) Shadings
Type 3 (radial) shadings define a color blend that varies between two circles.
Shadings of this type are commonly used to depict three-dimensional spheres
and cones. Shading dictionaries for this type of shading contain the entries shown
in Table 4.31, as well as those common to all shading dictionaries (Table 4.28).
x
x
1
x
0
–()xx
0
–()× y
1
y
0
–()yy
0
–()×+
x
1
x
0
–()
2
y
1
y
0
–()
2
+
----------------------------------------------------------------------------------------------------=
PatternsSECTION 4.6
281
Note: This type of shading cannot be used with an Indexed color space.
TABLE 4.31 Additional entries specific to a type 3 shading dictionary
The color blend is based on a family of blend circles interpolated between the
starting and ending circles that are defined by the shading dictionary’s
Coords
entry. The blend circles are defined in terms of a subsidiary parametric variable
KEY TYPE VALUE
Coords
array (Required) An array of six numbers [x
0
y
0
r
0
x
1
y
1
r
1
] specifying the centers and
radii of the starting and ending circles, expressed in the shading’s target coor-
dinate space. The radii r
0
and r
1
must both be greater than or equal to 0. If one
radius is 0, the corresponding circle is treated as a point; if both are 0, nothing is
painted.
Domain
array (Optional) An array of two numbers [t
0
t
1
] specifying the limiting values of a
parametric variable t. The variable is considered to vary linearly between these
two values as the color gradient varies between the starting and ending circles.
The variable t becomes the input argument to the color function(s). Default
value:
[0.0 1.0].
Function
function (Required) A 1-in, n-out function or an array of n 1-in, 1-out functions (where n
is the number of color components in the shading dictionary’s color space). The
function(s) are called with values of the parametric variable t in the domain de-
fined by the shading dictionary’s
Domain entry. Each function’s domain must be
a superset of that of the shading dictionary. If the value returned by the function
for a given color component is out of range, it is adjusted to the nearest valid val-
ue.
Extend
array (Optional) An array of two boolean values specifying whether to extend the
shading beyond the starting and ending circles, respectively. Default value:
[false false].
s
tt
0
–
t
1
t
0
–
---------------=
GraphicsCHAPTER 4
282
which varies linearly between 0.0 and 1.0 as t varies across the domain from t
0
to
t
1
, as specified by the dictionary’s Domain entry. The center and radius of each
blend circle are given by the following parametric equations:
Each value of s between 0.0 and 1.0 determines a corresponding value of t, which
is passed as the input argument to the function(s) defined by the shading dictio-
nary’s
Function entry. This yields the component values of the color with which
to fill the corresponding blend circle. For values of s not lying between 0.0 and
1.0, the boolean elements of the shading dictionary’s
Extend array determine
whether and how the shading is extended. If the first of the two elements is
true,
the shading is extended beyond the defined starting circle to values of s less than
0.0; if the second element is
true, the shading is extended beyond the defined
ending circle to s values greater than 1.0.
Note that either of the starting and ending circles may be larger than the other. If
the shading is extended at the smaller end, the family of blend circles continues as
far as that value of s for which the radius of the blend circle r(s) = 0. If the shading
is extended at the larger end, the blend circles continue as far as that s value for
which r(s) is large enough to encompass the shading’s entire bounding box
(
BBox). Extending the shading can thus cause painting to extend beyond the
areas defined by the two circles themselves. The two examples in the rightmost
column of Plate 11 depict the results of extending the shading at the smaller and
larger ends, respectively.
Conceptually, all of the blend circles are painted in order of increasing values of s,
from smallest to largest. Blend circles extending beyond the starting circle are
painted in the same color defined by the shading dictionary’s
Function entry for
the starting circle (t = t
0
, s = 0.0). Blend circles extending beyond the ending cir-
cle are painted in the color defined for the ending circle (t = t
1
, s = 1.0). The
painting is opaque, with the color of each circle completely overlaying those pre-
ceding it. Therefore, if a point lies within more than one blend circle, its final col-
or is that of the last of the enclosing circles to be painted, corresponding to the
greatest value of s.
x
c
s() x
0
sx
1
x
0
–()×+=
y
c
s() y
0
sy
1
y
0
–()×+=
rs() r
0
sr
1
r
0
–()×+=
PatternsSECTION 4.6
283
Note the following points:
• If one of the starting and ending circles entirely contains the other, the shading
depicts a sphere, as in Plates 12 and 13. In Plate 12, the inner circle has zero ra-
dius; it is the starting circle in the figure on the left and the ending circle in the
figure on the right. Neither shading is extended at either the smaller or larger
end. In Plate 13, the inner circle in both figures has a nonzero radius and the
shading is extended at the larger end. In each plate, a background color is spec-
ified for the figure on the right but not for the figure on the left.
• If neither circle contains the other, the shading depicts a cone. If the starting
circle is larger, the cone appears to point out of the page. If the ending circle is
larger, the cone appears to point into the page (see Plate 11).
Example 4.25 paints the leaf-covered branch shown in Plate 14. Each leaf is filled
with the same radial shading (object number 5). The color function (object 10) is
a stitching function (described in Section 3.9.3, “Type 3 (Stitching) Functions”)
whose two subfunctions (objects 11 and 12) are both exponential interpolation
functions (see Section 3.9.2, “Type 2 (Exponential Interpolation) Functions”).
Each leaf is drawn as a path and then filled with the shading, using code such as
that shown in Example 4.26 (where the name
Sh1 is associated with object 5 by
the
Shading subdictionary of the current resource dictionary; see Section 3.7.2,
“Resource Dictionaries”).
Example 4.25
5 0 obj % Shading dictionary
<< /ShadingType 3
/ColorSpace /DeviceCMYK
/Coords [0.0 0.0 0.096 0.0 0.0 1.000] % Concentric circles
/Function 10 0 R
/Extend [true true]
>>
endobj
10 0 obj % Color function
<< /FunctionType 3
/Domain [0.0 1.0]
/Functions [11 0 R 12 0 R]
/Bounds [0.708]
/Encode [1.0 0.0 0.0 1.0]
>>
endobj
GraphicsCHAPTER 4
284
11 0 obj % First subfunction
<< /FunctionType 2
/Domain [0.0 1.0]
/C0 [0.929 0.357 1.000 0.298]
/C1 [0.631 0.278 1.000 0.027]
/N 1.048
>>
endobj
12 0 obj % Second subfunction
<< /FunctionType 2
/Domain [0.0 1.0]
/C0 [0.929 0.357 1.000 0.298]
/C1 [0.941 0.400 1.000 0.102]
/N 1.374
>>
endobj
Example 4.26
316.789 140.311 m % Move to start of leaf
303.222 146.388 282.966 136.518 279.122 121.983 c % Curved segment
277.322 120.182 l % Straight line
285.125 122.688 291.441 121.716 298.156 119.386 c % Curved segment
336.448 119.386 l % Straight line
331.072 128.643 323.346 137.376 316.789 140.311 c % Curved segment
W n % Set clipping path
q % Save graphics state
27.7843 0.0000 0.0000 27.7843 310.2461 121.1521 cm % Set matrix
/Sh1 sh % Paint shading
Q % Restore graphics state
Type 4 Shadings (Free-Form Gouraud-Shaded Triangle Meshes)
Type 4 shadings (free-form Gouraud-shaded triangle meshes) are commonly
used to represent complex colored and shaded three-dimensional shapes. The
area to be shaded is defined by a path composed entirely of triangles. The color at
each vertex of the triangles is specified, and a technique known as Gouraud
interpolation is used to color the interiors. The interpolation functions defining
the shading may be linear or nonlinear. Table 4.32 shows the entries specific to
this type of shading dictionary, in addition to those common to all shading dic-
tionaries (Table 4.28) and stream dictionaries (Table 3.4 on page 38).
PatternsSECTION 4.6
285
TABLE 4.32 Additional entries specific to a type 4 shading dictionary
Unlike shading types 1 to 3, types 4 to 7 are represented as streams. Each stream
contains a sequence of vertex coordinates and color data that defines the triangle
mesh. In a type 4 shading, each vertex is specified by the following values, in the
order shown:
fxyc
1
…c
n
KEY TYPE VALUE
BitsPerCoordinate
integer (Required) The number of bits used to represent each vertex coordinate.
Valid values are 1, 2, 4, 8, 12, 16, 24, and 32.
BitsPerComponent
integer (Required) The number of bits used to represent each color component.
Valid values are 1, 2, 4, 8, 12, and 16.
BitsPerFlag
integer (Required) The number of bits used to represent the edge flag for each ver-
tex (see below). Valid values of
BitsPerFlag are 2, 4, and 8, but only the
least significant 2 bits in each flag value are used. Valid values for the edge
flag are 0, 1, and 2.
Decode
array (Required) An array of numbers specifying how to map vertex coordinates
and color components into the appropriate ranges of values. The decoding
method is similar to that used in image dictionaries (see “Decode Arrays”
on page 314). The ranges are specified as follows:
[x
min
x
max
y
min
y
max
c
1,min
c
1,max
… c
n,min
c
n,max
]
Note that only one pair of c values should be specified if a Function entry
is present.
Function
function (Optional) A 1-in, n-out function or an array of n 1-in, 1-out functions
(where n is the number of color components in the shading dictionary’s
color space). If this entry is present, the color data for each vertex must be
specified by a single parametric variable rather than by n separate color
components. The designated function(s) are called with each interpolated
value of the parametric variable to determine the actual color at each
point. Each input value is forced into the range interval specified for the
corresponding color component in the shading dictionary’s
Decode array.
Each function’s domain must be a superset of that interval. If the value re-
turned by the function for a given color component is out of range, it is
adjusted to the nearest valid value.
This entry may not be used with an
Indexed color space.
GraphicsCHAPTER 4
286
where
f is the vertex’s edge flag (discussed below)
x and y are its horizontal and vertical coordinates
c
1
…c
n
are its color components
All vertex coordinates are expressed in the shading’s target coordinate space. If
the shading dictionary includes a
Function entry, only a single parametric value,
t, is permitted for each vertex in place of the color components c
1
…c
n
.
The edge flag associated with each vertex determines the way it connects to the
other vertices of the triangle mesh. A vertex v
a
with an edge flag value f
a
= 0
begins a new triangle, unconnected to any other. At least two more vertices (v
b
and v
c
) must be provided, but their edge flags are ignored. These three vertices
define a triangle (v
a
, v
b
, v
c
), as shown in Figure 4.16.
FIGURE 4.16 Starting a new triangle in a free-form Gouraud-shaded triangle mesh
Subsequent triangles are defined by a single new vertex combined with two verti-
ces of the preceding triangle. Given triangle (v
a
, v
b
, v
c
), where vertex v
a
precedes
vertex v
b
in the data stream and v
b
precedes v
c
, a new vertex v
d
can form a new
triangle on side v
bc
or side v
ac
, as shown in Figure 4.17. (Side v
ab
is assumed to be
shared with a preceding triangle and therefore is not available for continuing the
mesh.) If the edge flag is f
d
= 1 (side v
bc
), the next vertex forms the triangle
(v
b
, v
c
, v
d
); if the edge flag is f
d
= 2 (side v
ac
), the next vertex forms the triangle
(v
a
, v
c
, v
d
). An edge flag of f
d
= 0 would start a new triangle, as described above.
f
a
=0
(Start new triangle)
Previous
triangle
v
a
v
c
v
b
PatternsSECTION 4.6
287
FIGURE 4.17 Connecting triangles in a free-form Gouraud-shaded triangle mesh
Complex shapes can be created by using the edge flags to control the edge on
which subsequent triangles are formed. Figure 4.18 shows two simple examples.
Mesh 1 begins with triangle 1 and uses the following edge flags to draw each suc-
ceeding triangle:
Mesh 2 again begins with triangle 1 and uses the following edge flags:
The stream must provide vertex data for a whole number of triangles with appro-
priate edge flags; otherwise, an error occurs.
Three new
vertices
v
d
v
f
v
e
f
d
=0 f
d
=1
v
a
v
c
v
b
One new
vertex
v
d
v
a
v
c
v
b
f
d
=2
One new
vertex
v
d
v
a
v
c
v
b
1 f
a
f
b
f
c
0===() 7 f
i
2=()
2 f
d
1=() 8 f
j
2=()
3 f
e
1=() 9 f
k
2=()
4 f
f
1=() 10 f
l
1=()
5 f
g
1=() 11 f
m
1=()
6 f
h
1=()
1 f
a
f
b
f
c
0===() 4 f
f
2=()
2 f
d
1=() 5 f
g
2=()
3 f
e
2=() 6 f
h
2=()
GraphicsCHAPTER 4
288
FIGURE 4.18 Varying the value of the edge flag to create different shapes
The data for each vertex consists of the following items, reading in sequence from
higher-order to lower-order bit positions:
• An edge flag, expressed in BitsPerFlag bits
• A pair of horizontal and vertical coordinates, expressed in BitsPerCoordinate
bits each
• A set of n color components (where n is the number of components in the
shading’s color space), expressed in
BitsPerComponent bits each, in the order
expected by the
sc operator
Each set of vertex data must occupy a whole number of bytes. If the total number
of bits required is not divisible by 8, the last data byte for each vertex is padded at
the end with extra bits, which are ignored. The coordinates and color values are
decoded according to the
Decode array in the same way as in an image dictionary
(see “Decode Arrays” on page 314).
If the shading dictionary contains a
Function entry, the color data for each vertex
must be specified by a single parametric value t rather than by n separate color
components. All linear interpolation within the triangle mesh is done using the t
values. After interpolation, the results are passed to the function(s) specified in
the
Function entry to determine the color at each point.
Mesh 1 Mesh 2
v
l
v
j
v
i
v
f
v
e
v
c
v
a
v
e
v
g
v
a
v
h
v
c
v
d
v
k
v
b
v
h
v
g
v
d
v
m
v
m
=
v
b
v
k
=
v
d
v
h
=
v
a
v
f
v
b
1
4
53
62
5
8
97
4
31
10
11
26
PatternsSECTION 4.6
289
Type 5 Shadings (Lattice-Form Gouraud-Shaded Triangle Meshes)
Type 5 shadings (lattice-form Gouraud-shaded triangle meshes) are similar to
type 4, but instead of using free-form geometry, their vertices are arranged in a
pseudorectangular lattice, which is topologically equivalent to a rectangular grid.
The vertices are organized into rows, which need not be geometrically linear (see
Figure 4.19).
FIGURE 4.19 Lattice-form triangle meshes
Table 4.33 shows the shading dictionary entries specific to this type of shading, in
addition to those common to all shading dictionaries (Table 4.28) and stream dic-
tionaries (Table 3.4 on page 38).
The data stream for a type 5 shading has the same format as for type 4, except that
type 5 does not use edge flags to define the geometry of the triangle mesh. The
data for each vertex thus consists of the following values, in the order shown:
xyc
1
…c
n
where
x and y are the vertex’s horizontal and vertical coordinates
c
1
…c
n
are its color components
Ideal lattice
(i, j)(i, j+1)
(i+1, j)(i+1, j+1)
Pseudorectangular lattice
GraphicsCHAPTER 4
290
TABLE 4.33 Additional entries specific to a type 5 shading dictionary
All vertex coordinates are expressed in the shading’s target coordinate space. If
the shading dictionary includes a
Function entry, only a single parametric value,
t, is permitted for each vertex in place of the color components c
1
…c
n
.
The
VerticesPerRow entry in the shading dictionary gives the number of vertices
in each row of the lattice. All of the vertices in a row are specified sequentially, fol-
lowed by those for the next row. Given m rows of k vertices each, the triangles of
KEY TYPE VALUE
BitsPerCoordinate
integer (Required) The number of bits used to represent each vertex coordinate.
Valid values are 1, 2, 4, 8, 12, 16, 24, and 32.
BitsPerComponent
integer (Required) The number of bits used to represent each color component.
Valid values are 1, 2, 4, 8, 12, and 16.
VerticesPerRow
integer (Required) The number of vertices in each row of the lattice; the value
must be greater than or equal to 2. The number of rows need not be
specified.
Decode
array (Required) An array of numbers specifying how to map vertex coordinates
and color components into the appropriate ranges of values. The decoding
method is similar to that used in image dictionaries (see “Decode Arrays”
on page 314). The ranges are specified as follows:
[x
min
x
max
y
min
y
max
c
1,min
c
1,max
… c
n,min
c
n,max
]
Note that only one pair of c values should be specified if a Function entry
is present.
Function
function (Optional) A 1-in, n-out function or an array of n 1-in, 1-out functions
(where n is the number of color components in the shading dictionary’s
color space). If this entry is present, the color data for each vertex must be
specified by a single parametric variable rather than by n separate color
components. The designated function(s) are called with each interpolated
value of the parametric variable to determine the actual color at each
point. Each input value is forced into the range interval specified for the
corresponding color component in the shading dictionary’s
Decode array.
Each function’s domain must be a superset of that interval. If the value re-
turned by the function for a given color component is out of range, it is
adjusted to the nearest valid value.
This entry cannot be used with an
Indexed color space.
PatternsSECTION 4.6
291
the mesh are constructed using the following triplets of vertices, as shown in
Figure 4.19:
See “Type 4 Shadings (Free-Form Gouraud-Shaded Triangle Meshes)” on page
284 for further details on the format of the vertex data.
Type 6 Shadings (Coons Patch Meshes)
Type 6 shadings (Coons patch meshes) are constructed from one or more color
patches, each bounded by four cubic Bézier curves. Degenerate Bézier curves are
allowed and are useful for certain graphical effects. At least one complete patch
must be specified.
A Coons patch generally has two independent aspects:
• Colors are specified for each corner of the unit square, and bilinear interpola-
tion is used to fill in colors over the entire unit square (see the upper figure in
Plate 15).
• Coordinates are mapped from the unit square into a four-sided patch whose
sides are not necessarily linear (see the lower figure in Plate 15). The mapping
is continuous: the corners of the unit square map to corners of the patch and
the sides of the unit square map to sides of the patch, as shown in Figure 4.20.
The sides of the patch are given by four cubic Bézier curves, C
1
, C
2
, D
1
, and D
2
,
defined over a pair of parametric variables, u and v, that vary horizontally and
vertically across the unit square. The four corners of the Coons patch satisfy the
following equations:
V
ij,
V
ij 1+,
V
i 1+ j,
,,()for 0 im2– 0 jk2–,
V
ij 1+,
V
i 1+ j,
V
i 1+ j 1+,
,, )(
C
1
0() D
1
0()=
C
1
1() D
2
0()=
C
2
0() D
1
1()=
C
2
1() D
2
1()=
GraphicsCHAPTER 4
292
FIGURE 4.20 Coordinate mapping from a unit square to a four-sided Coons patch
Two surfaces can be described that are linear interpolations between the bound-
ary curves. Along the u axis, the surface S
C
is defined by
Along the v axis, the surface S
D
is given by
A third surface is the bilinear interpolation of the four corners:
The coordinate mapping for the shading is given by the surface S, defined as
This defines the geometry of each patch. A patch mesh is constructed from a
sequence of one or more such colored patches.
Patches can sometimes appear to fold over on themselves—for example, if a
boundary curve intersects itself. As the value of parameter u or v increases in
parameter space, the location of the corresponding pixels in device space may
D
1
C
1
D
2
C
2
v
u
S
C
uv,() 1 v–()C
1
u()× vC
2
u()×+=
S
D
uv,() 1 u–()D
1
v() uD
2
v()×+×=
S
B
uv,() 1 v–()1 u–()C
1
0()×[ uC
1
1()×+ ]×
v 1 u–()C
2
0()×[ uC
2
1()×]+×+
=
SS
C
S
D
S
B
–+=
PatternsSECTION 4.6
293
change direction so that new pixels are mapped onto previous pixels already
mapped. If more than one point (u, v) in parameter space is mapped to the same
point in device space, the point selected is the one with the largest value of v. If
multiple points have the same v, the one with the largest value of u is selected. If
one patch overlaps another, the patch that appears later in the data stream paints
over the earlier one.
Note also that the patch is a control surface rather than a painting geometry. The
outline of a projected square (that is, the painted area) might not be the same as
the patch boundary if, for example, the patch folds over on itself, as shown in
Figure 4.21.
FIGURE 4.21 Painted area and boundary of a Coons patch
Table 4.34 shows the shading dictionary entries specific to this type of shading, in
addition to those common to all shading dictionaries (Table 4.28) and stream dic-
tionaries (Table 3.4 on page 38).
Appearance Painted area Patch boundary
GraphicsCHAPTER 4
294
TABLE 4.34 Additional entries specific to a type 6 shading dictionary
The data stream provides a sequence of Bézier control points and color values
that define the shape and colors of each patch. All of a patch’s control points are
given first, followed by the color values for its corners. Note that this differs from
a triangle mesh (shading types 4 and 5), in which the coordinates and color of
each vertex are given together. All control point coordinates are expressed in the
shading’s target coordinate space. See “Type 4 Shadings (Free-Form Gouraud-
KEY TYPE VALUE
BitsPerCoordinate
integer (Required) The number of bits used to represent each geometric coordi-
nate. Valid values are 1, 2, 4, 8, 12, 16, 24, and 32.
BitsPerComponent
integer (Required) The number of bits used to represent each color component.
Valid values are 1, 2, 4, 8, 12, and 16.
BitsPerFlag
integer (Required) The number of bits used to represent the edge flag for each
patch (see below). Valid values of
BitsPerFlag are 2, 4, and 8, but only the
least significant 2 bits in each flag value are used. Valid values for the edge
flag are 0, 1, 2, and 3.
Decode
array (Required) An array of numbers specifying how to map coordinates and
color components into the appropriate ranges of values. The decoding
method is similar to that used in image dictionaries (see “Decode Arrays”
on page 314). The ranges are specified as follows:
[x
min
x
max
y
min
y
max
c
1,min
c
1,max
… c
n,min
c
n,max
]
Note that only one pair of c values should be specified if a Function entry
is present.
Function
function (Optional) A 1-in, n-out function or an array of n 1-in, 1-out functions
(where n is the number of color components in the shading dictionary’s
color space). If this entry is present, the color data for each vertex must be
specified by a single parametric variable rather than by n separate color
components. The designated function(s) are called with each interpolated
value of the parametric variable to determine the actual color at each
point. Each input value is forced into the range interval specified for the
corresponding color component in the shading dictionary’s
Decode array.
Each function’s domain must be a superset of that interval. If the value re-
turned by the function for a given color component is out of range, it is
adjusted to the nearest valid value.
This entry may not be used with an
Indexed color space.
PatternsSECTION 4.6
295
Shaded Triangle Meshes)” on page 284 for further details on the format of the da-
ta.
As in free-form triangle meshes (type 4), each patch has an edge flag that indi-
cates which edge, if any, it shares with the previous patch. An edge flag of 0 begins
a new patch, unconnected to any other. This must be followed by 12 pairs of co-
ordinates, x
1
y
1
x
2
y
2
… x
12
y
12
, which specify the Bézier control points that
define the four boundary curves. Figure 4.22 shows how these control points cor-
respond to the cubic Bézier curves C
1
, C
2
, D
1
, and D
2
identified in Figure 4.20 on
page 292. Color values are given for the four corners of the patch, in the same or-
der as the control points corresponding to the corners. Thus, c
1
is the color at co-
ordinates (x
1
, y
1
), c
2
at (x
4
, y
4
), c
3
at (x
7
, y
7
), and c
4
at (x
10
, y
10
), as shown in the
figure.
FIGURE 4.22 Color values and edge flags in Coons patch meshes
Figure 4.22 also shows how nonzero values of the edge flag (f = 1, 2, or 3) connect
a new patch to one of the edges of the previous patch. In this case, some of the
previous patch’s control points serve implicitly as control points for the new patch
as well (see Figure 4.23), and therefore are not explicitly repeated in the data
stream. Table 4.35 summarizes the required data values for various values of the
edge flag.
5
3
8
6
7
9
11
12
2
1
4
10
Use this side when next f = 3.
Use this side when next f = 1.
Use this side when next f = 2.
This side already attached
to previous patch. Start a
new patch when next f = 0.
c
1
c
2
c
3
c
4
C
1
C
2
D
2
D
1
GraphicsCHAPTER 4
296
FIGURE 4.23 Edge connections in a Coons patch mesh
If the shading dictionary contains a Function entry, the color data for each corner
of a patch must be specified by a single parametric value t rather than by n sepa-
rate color components c
1
…c
n
. All linear interpolation within the mesh is done
using the t values. After interpolation, the results are passed to the function(s)
specified in the
Function entry to determine the color at each point.
When f
B
= 0, start a new patch.
Patch B
f
B
= 1
Patch A
Patch B
f
B
= 3
Patch B
f
B
= 2
2
1
4
5
3
c
1
c
2
12
9
3
4
1
1
2
2
4
3
11
c
1
c
1
c
2
c
4
1
4
7
6
8
2
3
c
3
c
1
c
2
c
2
10
PatternsSECTION 4.6
297
TABLE 4.35 Data values in a Coons patch mesh
Type 7 Shadings (Tensor-Product Patch Meshes)
Type 7 shadings (tensor-product patch meshes) are identical to type 6, except that
they are based on a bicubic tensor-product patch defined by 16 control points in-
stead of the 12 control points that define a Coons patch. The shading dictionaries
representing the two patch types differ only in the value of the
ShadingType entry
and in the number of control points specified for each patch in the data stream.
EDGE FLAG NEXT SET OF DATA VALUES
f = 0 x
1
y
1
x
2
y
2
x
3
y
3
x
4
y
4
x
5
y
5
x
6
y
6
x
7
y
7
x
8
y
8
x
9
y
9
x
10
y
10
x
11
y
11
x
12
y
12
c
1
c
2
c
3
c
4
New patch; no implicit values
f = 1 x
5
y
5
x
6
y
6
x
7
y
7
x
8
y
8
x
9
y
9
x
10
y
10
x
11
y
11
x
12
y
12
c
3
c
4
Implicit values:
(x
1
, y
1
) = (x
4
, y
4
) previous c
1
= c
2
previous
(x
2
, y
2
) = (x
5
, y
5
) previous c
2
= c
3
previous
(x
3
, y
3
) = (x
6
, y
6
) previous
(x
4
, y
4
) = (x
7
, y
7
) previous
f = 2 x
5
y
5
x
6
y
6
x
7
y
7
x
8
y
8
x
9
y
9
x
10
y
10
x
11
y
11
x
12
y
12
c
3
c
4
Implicit values:
(x
1
, y
1
) = (x
7
, y
7
) previous c
1
= c
3
previous
(x
2
, y
2
) = (x
8
, y
8
) previous c
2
= c
4
previous
(x
3
, y
3
) = (x
9
, y
9
) previous
(x
4
, y
4
) = (x
10
, y
10
) previous
f = 3 x
5
y
5
x
6
y
6
x
7
y
7
x
8
y
8
x
9
y
9
x
10
y
10
x
11
y
11
x
12
y
12
c
3
c
4
Implicit values:
(x
1
, y
1
) = (x
10
, y
10
) previous c
1
= c
4
previous
(x
2
, y
2
) = (x
11
, y
11
) previous c
2
= c
1
previous
(x
3
, y
3
) = (x
12
, y
12
) previous
(x
4
, y
4
) = (x
1
, y
1
) previous
GraphicsCHAPTER 4
298
Although the Coons patch is more concise and easier to use, the tensor-product
patch affords greater control over color mapping.
Note: The data format for type 7 shadings (as for types 4 through 6) is the same in
PDF as it is in PostScript. However, the numbering and order of control points was
described incorrectly in the first printing of the PostScript Language Reference,
Third Edition. That description has been corrected here.
Like the Coons patch mapping, the tensor-product patch mapping is controlled
by the location and shape of four cubic Bézier curves marking the boundaries of
the patch. However, the tensor-product patch has four additional, “internal”
control points to adjust the mapping. The 16 control points can be arranged in a
4-by-4 array indexed by row and column, as follows (see Figure 4.24):
p
03
p
13
p
23
p
33
p
02
p
12
p
22
p
32
p
01
p
11
p
21
p
31
p
00
p
10
p
20
p
30
FIGURE 4.24 Control points in a tensor-product patch
p
02
p
00
p
01
p
12
p
22
p
21
p
11
p
10
p
20
p
30
p
31
p
32
p
33
p
23
p
13
p
03
PatternsSECTION 4.6
299
As in a Coons patch mesh, the geometry of the tensor-product patch is described
by a surface defined over a pair of parametric variables, u and v, which vary hori-
zontally and vertically across the unit square. The surface is defined by the equa-
tion
where p
ij
is the control point in column i and row j of the tensor, and B
i
and B
j
are
the Bernstein polynomials
Since each point p
ij
is actually a pair of coordinates (x
ij
, y
ij
), the surface can also
be expressed as
The geometry of the tensor-product patch can be visualized in terms of a cubic
Bézier curve moving from the bottom boundary of the patch to the top. At the
bottom and top, the control points of this curve coincide with those of the patch’s
bottom (p
00
…p
30
) and top (p
03
…p
33
) boundary curves, respectively. As the
curve moves from the bottom edge of the patch to the top, each of its four control
points follows a trajectory that is in turn a cubic Bézier curve defined by the four
control points in the corresponding column of the array. That is, the starting
point of the moving curve follows the trajectory defined by control points
p
00
…p
03
, the trajectory of the ending point is defined by points p
30
…p
33
, and
those of the two intermediate control points by p
10
…p
13
and p
20
…p
23
. Equiva-
Suv,() p
ij
B
i
u() B
j
v()××
j 0=
3
i 0=
3
=
B
0
t() 1 t–()
3
=
B
1
t() 3t 1 t–()
2
×=
B
2
t() 3t
2
1 t–()×=
B
3
t() t
3
=
xuv,() x
ij
B
i
u() B
j
v()××
j
0=
3
i 0=
3
=
yuv,() y
ij
B
i
u() B
j
v()××
j 0=
3
i 0=
3
=
GraphicsCHAPTER 4
300
lently, the patch can be considered to be traced by a cubic Bézier curve moving
from the left edge to the right, with its control points following the trajectories
defined by the rows of the coordinate array instead of the columns.
The Coons patch (type 6) is actually a special case of the tensor-product patch
(type 7) in which the four internal control points (p
11
, p
12
, p
21
, p
22
) are implicitly
defined by the boundary curves. The values of the internal control points are giv-
en by these equations:
In the more general tensor-product patch, the values of these four points are un-
restricted.
The coordinates of the control points in a tensor-product patch are actually spec-
ified in the shading’s data stream in the following order:
4567
31415 8
21316 9
1121110
All control point coordinates are expressed in the shading’s target coordinate
space. These are followed by the color values for the four corners of the patch, in
the same order as the corners themselves. If the patch’s edge flag f is 0, all 16
control points and four corner colors must be explicitly specified in the data
stream. If f is 1, 2, or 3, the control points and colors for the patch’s shared edge
are implicitly understood to be the same as those along the specified edge of the
previous patch and are not repeated in the data stream. Table 4.36 summarizes
the data values for various values of the edge flag f, expressed in terms of the row
and column indices used in Figure 4.24 above. See “Type 4 Shadings (Free-Form
p
11
19⁄
4– p
00
× 6 p
01
p
10
+()× 2 p
03
p
30
+()×– 3 p
31
p
13
+()× 1 p
33
×–++[]
×=
p
12
19⁄
4– p
03
× 6 p
02
p
13
+()× 2 p
00
p
33
+()×– 3 p
32
p
10
+()× 1 p×
30
–++[]
×=
p
21
19⁄
4– p
30
× 6 p
31
p
20
+()× 2 p
33
p
00
+()×– 3 p
01
p
23
+()× 1 p
03
×–++[]
×=
p
22
19⁄
4– p
33
× 6 p
32
p
23
+()× 2 p
30
p
03
+()×– 3 p
02
p
20
+()× 1 p
00
×–++[]
×=
PatternsSECTION 4.6
301
Gouraud-Shaded Triangle Meshes)” on page 284 for further details on the format
of the data.
TABLE 4.36 Data values in a tensor-product patch mesh
EDGE FLAG NEXT SET OF DATA VALUES
f = 0 x
00
y
00
x
01
y
01
x
02
y
02
x
03
y
03
x
13
y
13
x
23
y
23
x
33
y
33
x
32
y
32
x
31
y
31
x
30
y
30
x
20
y
20
x
10
y
10
x
11
y
11
x
12
y
12
x
22
y
22
x
21
y
21
c
00
c
03
c
33
c
30
New patch; no implicit values
f = 1 x
13
y
13
x
23
y
23
x
33
y
33
x
32
y
32
x
31
y
31
x
30
y
30
x
20
y
20
x
10
y
10
x
11
y
11
x
12
y
12
x
22
y
22
x
21
y
21
c
33
c
30
Implicit values:
(x
00
, y
00
) = (x
03
, y
03
) previous c
00
= c
03
previous
(x
01
, y
01
) = (x
13
, y
13
) previous c
03
= c
33
previous
(x
02
, y
02
) = (x
23
, y
23
) previous
(x
03
, y
03
) = (x
33
, y
33
) previous
f = 2 x
13
y
13
x
23
y
23
x
33
y
33
x
32
y
32
x
31
y
31
x
30
y
30
x
20
y
20
x
10
y
10
x
11
y
11
x
12
y
12
x
22
y
22
x
21
y
21
c
33
c
30
Implicit values:
(x
00
, y
00
) = (x
33
, y
33
) previous c
00
= c
33
previous
(x
01
, y
01
) = (x
32
, y
32
) previous c
03
= c
30
previous
(x
02
, y
02
) = (x
31
, y
31
) previous
(x
03
, y
03
) = (x
30
, y
30
) previous
f = 3 x
13
y
13
x
23
y
23
x
33
y
33
x
32
y
32
x
31
y
31
x
30
y
30
x
20
y
20
x
10
y
10
x
11
y
11
x
12
y
12
x
22
y
22
x
21
y
21
c
33
c
30
Implicit values:
(x
00
, y
00
) = (x
30
, y
30
) previous c
00
= c
30
previous
(x
01
, y
01
) = (x
20
, y
20
) previous c
03
= c
00
previous
(x
02
, y
02
) = (x
10
, y
10
) previous
(x
03
, y
03
) = (x
00
, y
00
) previous
GraphicsCHAPTER 4
302
4.7 External Objects
An external object (commonly called an XObject) is a graphics object whose con-
tents are defined by a self-contained content stream, separate from the content
stream in which it is used. There are three types of external objects:
• An image XObject (Section 4.8.4, “Image Dictionaries”) represents a sampled
visual image such as a photograph.
• A form XObject (Section 4.9, “Form XObjects”) is a self-contained description
of an arbitrary sequence of graphics objects.
• A PostScript XObject (Section 4.7.1, “PostScript XObjects”) contains a fragment
of code expressed in the PostScript page description language. PostScript XOb-
jects are no longer recommended to be used.
Two further categories of external objects, group XObjects and reference XObjects
(both PDF 1.4), are actually specialized types of form XObjects with additional
properties. See Sections 4.9.2, “Group XObjects,” and 4.9.3, “Reference XObjects,”
for additional information.
Any XObject can be painted as part of another content stream by means of the
Do
operator (see Table 4.37). This operator applies to any type of XObject—image,
form, or PostScript. The syntax is the same in all cases, although details of the
operator’s behavior differ depending on the type. (See implementation note 50 in
Appendix H.)
TABLE 4.37 XObject operator
OPERANDS OPERATOR DESCRIPTION
name
Do
Paint the specified XObject. The operand name must appear as a key in the
XObject subdictionary of the current resource dictionary (see Section 3.7.2, “Re-
source Dictionaries”). The associated value must be a stream whose
Type entry,
if present, is
XObject. The effect of Do depends on the value of the XObject’s
Subtype entry, which may be Image (see Section 4.8.4, “Image Dictionaries”),
Form (Section 4.9, “Form XObjects”), or PS (Section 4.7.1, “PostScript XOb-
jects”).
External ObjectsSECTION 4.7
303
4.7.1 PostScript XObjects
Beginning with PDF 1.1, a content stream can include PostScript language frag-
ments. These fragments are used only when printing to a PostScript output de-
vice; they have no effect either when viewing the document on-screen or when
printing it to a non-PostScript device. In addition, applications that understand
PDF are unlikely to be able to interpret the PostScript fragments. Hence, this ca-
pability should be used with extreme caution and only if there is no other way to
achieve the same result. Inappropriate use of PostScript XObjects can cause PDF
files to print incorrectly.
Note: Since PDF 1.4 encompasses all of the Adobe imaging model features of the
PostScript language, there is no longer any reason to use PostScript XObjects. This
feature is likely to be removed from PDF in a future version.
A PostScript XObject is an XObject stream whose
Subtype entry has the value PS.
A PostScript XObject dictionary can contain the entries shown in Table 4.38 in
addition to the usual entries common to all streams (see Table 3.4 on page 38).
TABLE 4.38 Additional entries specific to a PostScript XObject dictionary
When a PDF content stream is translated into the PostScript language, any Do
operation that references a PostScript XObject is replaced by the contents of the
XObject stream itself. The stream is copied without interpretation. The PostScript
fragment may use Type 1 and TrueType fonts listed in the
Font subdictionary of
the current resource dictionary (see Section 3.7.2, “Resource Dictionaries”), ac-
cessing them by their
BaseFont names using the PostScript findfont operator. The
fragment may not use other types of fonts listed in the
Font subdictionary. It
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
XObject for a PostScript XObject.
Subtype
name (Required) The type of XObject that this dictionary describes; must be PS for a Post-
Script XObject.
Note: Alternatively, the value of this entry may be
Form, with an additional Subtype2
entry whose value is PS.
Level1
stream (Optional) A stream whose contents are to be used in place of the PostScript
XObject’s stream when the target PostScript interpreter is known to support only
LanguageLevel 1.
GraphicsCHAPTER 4
304
should not reference the PostScript definitions corresponding to PDF procedure
sets (see Section 10.1, “Procedure Sets”), which are subject to change.
4.8 Images
PDF’s painting operators include general facilities for dealing with sampled im-
ages. A sampled image (or just image for short) is a rectangular array of sample
values, each representing a color. The image may approximate the appearance of
some natural scene obtained through an input scanner or a video camera, or it
may be generated synthetically.
FIGURE 4.25 Typical sampled image
An image is defined by a sequence of samples obtained by scanning the image
array in row or column order. Each sample in the array consists of as many color
components as are needed for the color space in which they are specified—for
example, one component for
DeviceGray, three for DeviceRGB, four for
DeviceCMYK, or whatever number is required by a particular DeviceN space.
Each component is a 1-, 2-, 4-, 8-, or (in PDF 1.5) 16-bit integer, permitting the
representation of 2, 4, 16, 256, or (in PDF 1.5) 65536 distinct values for each com-
ponent. (Other component sizes can be accommodated when a
JPXDecode filter
is used; see Section 3.3.8, “JPXDecode Filter.)
ImagesSECTION 4.8
305
PDF provides two means for specifying images:
• An image XObject (described in Section 4.8.4, “Image Dictionaries”) is a
stream object whose dictionary specifies attributes of the image and whose
data contains the image samples. Like all external objects, it is painted on the
page by invoking the
Do operator in a content stream (see Section 4.7, “Exter-
nal Objects”). Image XObjects have other uses as well, such as for alternate im-
ages (see “Alternate Images” on page 317), image masks (Section 4.8.5,
“Masked Images”), and thumbnail images (Section 8.2.3, “Thumbnail
Images”).
• An inline image is a small image that is completely defined—both attributes
and data—directly inline within a content stream. The kinds of images that can
be represented in this way are limited; see Section 4.8.6, “Inline Images,” for
details.
4.8.1 Image Parameters
The properties of an image—resolution, orientation, scanning order, and so
forth—are entirely independent of the characteristics of the raster output device
on which the image is to be rendered. A PDF consumer application usually ren-
ders images by a sampling technique that attempts to approximate the color val-
ues of the source as accurately as possible. The actual accuracy achieved depends
on the resolution and other properties of the output device.
To paint an image, four interrelated items must be specified:
• The format of the image: number of columns (width), number of rows (height),
number of color components per sample, and number of bits per color compo-
nent
• The sample data constituting the image’s visual content
• The correspondence between coordinates in user space and those in the image’s
own internal coordinate space, defining the region of user space that will re-
ceive the image
• The mapping from color component values in the image data to component
values in the image’s color space
All of these items are specified explicitly or implicitly by an image XObject or an
inline image.
GraphicsCHAPTER 4
306
Note: For convenience, the following sections refer consistently to the object defining
an image as an image dictionary. Although this term properly refers only to the
dictionary portion of the stream object representing an image XObject, it should be
understood to apply equally to the stream’s data portion or to the parameters and
data of an inline image.
4.8.2 Sample Representation
The source format for an image can be described by four parameters:
• The width of the image in samples
• The height of the image in samples
• The number of color components per sample
• The number of bits per color component
The image dictionary specifies the width, height, and number of bits per compo-
nent explicitly. The number of color components can be inferred from the color
space specified in the dictionary.
Note: For images using the
JPXDecode filter (see Section 3.3.8, “JPXDecode Filter”),
the number of bits per component is determined from the image data and not speci-
fied in the image dictionary. The color space may or may not be specified in the dic-
tionary.
Sample data is represented as a stream of bytes, interpreted as 8-bit unsigned
integers in the range 0 to 255. The bytes constitute a continuous bit stream, with
the high-order bit of each byte first. This bit stream, in turn, is divided into units
of n bits each, where n is the number of bits per component. Each unit encodes a
color component value, given with high-order bit first; units of 16 bits are given
with the most significant byte first. Byte boundaries are ignored, except that each
row of sample data must begin on a byte boundary. If the number of data bits per
row is not a multiple of 8, the end of the row is padded with extra bits to fill out
the last byte. A PDF consumer application ignores these padding bits.
Each n-bit unit within the bit stream is interpreted as an unsigned integer in the
range 0 to 2
n
1, with the high-order bit first. The image dictionary’s Decode
entry maps this integer to a color component value, equivalent to what could be
used with color operators such as
sc or g. Color components are interleaved sam-
ImagesSECTION 4.8
307
ple by sample; for example, in a three-component RGB image, the red, green, and
blue components for one sample are followed by the red, green, and blue compo-
nents for the next.
Normally, the color samples in an image are interpreted according to the color
space specified in the image dictionary (see Section 4.5, “Color Spaces”), without
reference to the color parameters in the graphics state. However, if the image dic-
tionary’s
ImageMask entry is true, the sample data is interpreted as a stencil mask
for applying the graphics state’s nonstroking color parameters (see “Stencil Mask-
ing” on page 320).
4.8.3 Image Coordinate System
Each image has its own internal coordinate system, or image space. The image oc-
cupies a rectangle in image space w units wide and h units high, where w and h
are the width and height of the image in samples. Each sample occupies one
square unit. The coordinate origin (0, 0) is at the upper-left corner of the image,
with coordinates ranging from 0 to w horizontally and 0 to h vertically.
The image’s sample data is ordered by row, with the horizontal coordinate varying
most rapidly. This is shown in Figure 4.26, where the numbers inside the squares
indicate the order of the samples, counting from 0. The upper-left corner of the
first sample is at coordinates (0, 0), the second at (1, 0), and so on through the last
sample of the first row, whose upper-left corner is at (w 1, 0) and whose upper-
right corner is at (w, 0). The next samples after that are at coordinates (0, 1),
(1, 1), and so on to the final sample of the image, whose upper-left corner is at
(w 1, h 1) and whose lower-right corner is at (w, h).
Note: The image coordinate system and scanning order imposed by PDF do not pre-
clude using different conventions in the actual image. Coordinate transformations
can be used to map from other conventions to the PDF convention.
The correspondence between image space and user space is constant: the unit
square of user space, bounded by user coordinates (0, 0) and (1, 1), corresponds
to the boundary of the image in image space (see Figure 4.27). Following the
normal convention for user space, the coordinate (0, 0) is at the lower-left corner
of this square, corresponding to coordinates (0, h) in image space. The transfor-
mation from image space to user space could be described by the matrix
[1⁄w 001⁄h 01].
GraphicsCHAPTER 4
308
FIGURE 4.26 Source image coordinate system
FIGURE 4.27 Mapping the source image
An image can be placed on the output page in any position, orientation, and size
by using the
cm operator to modify the current transformation matrix (CTM) so
as to map the unit square of user space to the rectangle or parallelogram in which
the image is to be painted. Typically, this is done within a pair of
q and Q opera-
tors to isolate the effect of the transformation, which can include translation, ro-
0
1
h1
2
h
012 w1 w
01 w1
ww+12w1
(h1)w (h1)w+1 hw1
h
0 w
0
(0, 1) (1, 1)
(0, 0) (1, 0)
Unit square
in user space
Current pageSource image
CTM
ImagesSECTION 4.8
309
tation, reflection, and skew (see Section 4.2, “Coordinate Systems”). For example,
if the
XObject subdictionary of the current resource dictionary defines the name
Image1 to denote an image XObject, the code shown in Example 4.27 paints the
image in a rectangle whose lower-left corner is at coordinates (100, 200), that is
rotated 45 degrees counterclockwise, and that is 150 units wide and 80 units high.
Example 4.27
q % Save graphics state
1 0 0 1 100 200 cm % Translate
0.7071 0.7071 0.7071 0.7071 0 0 cm % Rotate
150 0 0 80 0 0 cm % Scale
/Image1 Do % Paint image
Q % Restore graphics state
(As discussed in Section 4.2.3, “Transformation Matrices,” these three transfor-
mations could be combined into one.) Of course, if the aspect ratio (width to
height) of the original image in this example is different from 150:80, the result
will be distorted.
4.8.4 Image Dictionaries
An image dictionary—that is, the dictionary portion of a stream representing an
image XObject—can contain the entries listed in Table 4.39 in addition to the
usual entries common to all streams (see Table 3.4 on page 38). There are many
relationships among these entries, and the current color space may limit the
choices for some of them. Attempting to use an image dictionary whose entries
are inconsistent with each other or with the current color space causes an error.
Note: The entries described here are appropriate for a base image—one that is in-
voked directly with the
Do operator. Some of the entries are not relevant for images
used in other ways, such as for alternate images (see “Alternate Images” on page
317), image masks (Section 4.8.5, “Masked Images”), or thumbnail images (Section
8.2.3, “Thumbnail Images”). Except as noted, such irrelevant entries are simply ig-
nored.
GraphicsCHAPTER 4
310
TABLE 4.39 Additional entries specific to an image dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if
present, must be
XObject for an image XObject.
Subtype
name (Required) The type of XObject that this dictionary describes; must be
Image for an image XObject.
Width
integer (Required) The width of the image, in samples.
Height
integer (Required) The height of the image, in samples.
ColorSpace
name or
array
(Required for images, except those that use the JPXDecode filter; not allowed
for image masks) The color space in which image samples are specified; it
can be any type of color space except
Pattern.
If the image uses the
JPXDecode filter, this entry is optional:
• If ColorSpace is present, any color space specifications in the JPEG2000
data are ignored.
• If ColorSpace is absent, the color space specifications in the JPEG2000
data are used. The
Decode array is also ignored unless ImageMask is
true.
BitsPerComponent
integer (Required except for image masks and images that use the JPXDecode filter)
The number of bits used to represent each color component. Only a single
value may be specified; the number of bits is the same for all color compo-
nents. Valid values are 1, 2, 4, 8, and (in PDF 1.5) 16. If
ImageMask is true,
this entry is optional, and if specified, its value must be 1.
If the image stream uses a filter, the value of
BitsPerComponent must be
consistent with the size of the data samples that the filter delivers. In par-
ticular, a
CCITTFaxDecode or JBIG2Decode filter always delivers 1-bit
samples, a
RunLengthDecode or DCTDecode filter delivers 8-bit samples,
and an
LZWDecode or FlateDecode filter delivers samples of a specified
size if a predictor function is used.
If the image stream uses the
JPXDecode filter, this entry is optional and ig-
nored if present. The bit depth is determined in the process of decoding
the JPEG2000 image.
Intent
name (Optional; PDF 1.1) The name of a color rendering intent to be used in
rendering the image (see “Rendering Intents” on page 230). Default value:
the current rendering intent in the graphics state.
ImagesSECTION 4.8
311
ImageMask
boolean (Optional) A flag indicating whether the image is to be treated as an image
mask (see Section 4.8.5, “Masked Images”). If this flag is
true, the value of
BitsPerComponent must be 1 and Mask and ColorSpace should not be
specified; unmasked areas are painted using the current nonstroking col-
or. Default value:
false.
Mask
stream
or array
(Optional except for image masks; not allowed for image masks; PDF 1.3)
An image XObject defining an image mask to be applied to this image (see
“Explicit Masking” on page 321), or an array specifying a range of colors
to be applied to it as a color key mask (see “Color Key Masking” on page
321). If
ImageMask is true, this entry must not be present. (See
implementation note 51 in Appendix H.)
Decode
array (Optional) An array of numbers describing how to map image samples
into the range of values appropriate for the image’s color space (see
“Decode Arrays” on page 314). If
ImageMask is true, the array must be
either [0 1] or [1 0]; otherwise, its length must be twice the number of
color components required by
ColorSpace. If the image uses the
JPXDecode filter and ImageMask is false, Decode is ignored.
Default value: see “Decode Arrays” on page 314.
Interpolate
boolean (Optional) A flag indicating whether image interpolation is to be per-
formed (see “Image Interpolation” on page 316). Default value:
false.
Alternates
array (Optional; PDF 1.3) An array of alternate image dictionaries for this image
(see “Alternate Images” on page 317). The order of elements within the
array has no significance. This entry may not be present in an image XOb-
ject that is itself an alternate image.
SMask
stream (Optional; PDF 1.4) A subsidiary image XObject defining a soft-mask
image (see “Soft-Mask Images” on page 522) to be used as a source of
mask shape or mask opacity values in the transparent imaging model. The
alpha source parameter in the graphics state determines whether the mask
values are interpreted as shape or opacity.
If present, this entry overrides the current soft mask in the graphics state,
as well as the image’s
Mask entry, if any. (However, the other transparency-
related graphics state parameters—blend mode and alpha constant—
remain in effect.) If
SMask is absent, the image has no associated soft
mask (although the current soft mask in the graphics state may still ap-
ply).
KEY TYPE VALUE
GraphicsCHAPTER 4
312
SMaskInData
integer (Optional for images that use the JPXDecode filter, meaningless otherwise;
PDF 1.5) A code specifying how soft-mask information (see “Soft-Mask
Images” on page 522) encoded with image samples should be used:
0 If present, encoded soft-mask image information should be ig-
nored.
1 The image’s data stream includes encoded soft-mask values. An
application can create a soft-mask image from the information to
be used as a source of mask shape or mask opacity in the transpar-
ency imaging model.
2 The image’s data stream includes color channels that have been
preblended with a background; the image data also includes an
opacity channel. An application can create a soft-mask image with
a
Matte entry from the opacity channel information to be used as
a source of mask shape or mask opacity in the transparency mod-
el.
If this entry has a nonzero value,
SMask should not be specified. See also
Section 3.3.8, “JPXDecode Filter.”
Default value: 0.
Name
name (Required in PDF 1.0; optional otherwise) The name by which this image
XObject is referenced in the
XObject subdictionary of the current resource
dictionary (see Section 3.7.2, “Resource Dictionaries”).
Note: This entry is obsolescent and its use is no longer recommended. (See
implementation note 52 in Appendix H.)
StructParent
integer (Required if the image is a structural content item; PDF 1.3) The integer key
of the image’s entry in the structural parent tree (see “Finding Structure
Elements from Content Items” on page 797).
ID
string (Optional; PDF 1.3; indirect reference preferred) The digital identifier of
the image’s parent Web Capture content set (see Section 10.9.5, “Object
Attributes Related to Web Capture”).
OPI
dictionary (Optional; PDF 1.2) An OPI version dictionary for the image (see Section
10.10.6, “Open Prepress Interface (OPI)”). If
ImageMask is true, this entry
is ignored.
Metadata
stream (Optional; PDF 1.4) A metadata stream containing metadata for the image
(see Section 10.2.2, “Metadata Streams”).
KEY TYPE VALUE
ImagesSECTION 4.8
313
Example 4.28 defines an image 256 samples wide by 256 high, with 8 bits per
sample in the
DeviceGray color space. It paints the image on a page with its lower-
left corner positioned at coordinates (45, 140) in current user space and scaled to
a width and height of 132 user space units.
Example 4.28
20 0 obj % Page object
<< /Type /Page
/Parent 1 0 R
/Resources 21 0 R
/MediaBox [0 0 612 792]
/Contents 23 0 R
>>
endobj
21 0 obj % Resource dictionary for page
<< /ProcSet [/PDF /ImageB]
/XObject << /Im1 22 0 R >>
>>
endobj
22 0 obj % Image XObject
<< /Type /XObject
/Subtype /Image
/Width 256
/Height 256
/ColorSpace /DeviceGray
/BitsPerComponent 8
/Length 83183
/Filter /ASCII85Decode
>>
OC
dictionary (Optional; PDF 1.5) An optional content group or optional content mem-
bership dictionary (see Section 4.10, “Optional Content”), specifying the
optional content properties for this image XObject. Before the image is
processed, its visibility is determined based on this entry. If it is deter-
mined to be invisible, the entire image is skipped, as if there were no
Do
operator to invoke it.
KEY TYPE VALUE
GraphicsCHAPTER 4
314
stream
9LhZI9h\GY9i+bb;,p:e;G9SP92/)X9MJ>^:f14d;,U(X8P;cO;G9e];c$=k9Mn\]
…Image data representing 65,536 samples …
8P;cO;G9e];c$=k9Mn\]~>
endstream
endobj
23 0 obj % Contents of page
<< /Length 56 >>
stream
q % Save graphics state
132 0 0 132 45 140 cm % Translate to (45,140) and scale by 132
/Im1 Do % Paint image
Q % Restore graphics state
endstream
endobj
Decode Arrays
An image’s data stream is initially decomposed into integers in the domain 0 to
2
n
1, where n is the value of the image dictionary’s BitsPerComponent entry.
The image’s
Decode array specifies a linear mapping of each integer component
value to a number that would be appropriate as a component value in the image’s
color space.
Each pair of numbers in a
Decode array specifies the lower and upper values to
which the domain of sample values in the image is mapped. A
Decode array con-
tains one pair of numbers for each component in the color space specified by the
image’s
ColorSpace entry. The mapping for each color component is a linear
transformation; that is, it uses the following formula for linear interpolation:
Generally, this formula is used to convert a value x between x
min
and x
max
to a
corresponding value y between y
min
and y
max
, projecting along the line defined
by the points (x
min
, y
min
) and (x
max
, y
max
). While this formula applies to values
outside the domain x
min
to x
max
and does not require that x
min
< x
max
, note that
interpolation used for color conversion, such as the
Decode array, does require
y Interpolate x x
min
x
max
y
min
y
max
,,,,)(=
y
min
xx
min
– )(
y
max
y
min
–
x
max
x
min
–
----------------------------
×
+=
ImagesSECTION 4.8
315
that x
min
< x
max
and clips x values to this domain so that y = y
min
for all x x
min
,
and y = y
max
for all x x
max
.
For a
Decode array of the form [D
min
D
max
], this can be written as
where
n is the value of
BitsPerComponent
x is the input value, in the domain 0 to 2
n
1
D
min
and D
max
are the values specified in the Decode array
y is the output value, to be interpreted in the image’s color space
Samples with a value of 0 are mapped to
D
min
, those with a value of 2
n
1 are
mapped to
D
max
, and those with intermediate values are mapped linearly be-
tween
D
min
and D
max
. Table 4.40 lists the default Decode arrays for use with the
various color spaces. For most color spaces, the
Decode arrays listed in the table
map into the full range of allowed component values. For an
Indexed color space,
the default
Decode array ensures that component values that index a color table
are passed through unchanged.
TABLE 4.40 Default Decode arrays
COLOR SPACE Decode ARRAY
DeviceGray
[0.0 1.0]
DeviceRGB
[0.0 1.0 0.0 1.0 0.0 1.0]
DeviceCMYK
[0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]
CalGray
[0.0 1.0]
CalRGB
[0.0 1.0 0.0 1.0 0.0 1.0]
Lab [0 100 a
min
a
max
b
min
b
max
] where a
min
, a
max
, b
min
, and b
max
correspond to the values in the Range array of the image’s color
space
y Interpolate x 02
n
1– D
min
D
max
,, , , )(=
D
min
x
D
max
D
min
–
2
n
1–
-------------------------------
×
+=
GraphicsCHAPTER 4
316
It is possible to specify a mapping that inverts sample color intensities by specify-
ing a D
min
value greater than D
max
. For example, if the image’s color space is
DeviceGray and the Decode array is [1.0 0.0], an input value of 0 is mapped to 1.0
(white); an input value of 2
n
1 is mapped to 0.0 (black).
The D
min
and D
max
parameters for a color component are not required to fall
within the range of values allowed for that component. For instance, if an applica-
tion uses 6-bit numbers as its native image sample format, it can represent those
samples in PDF in 8-bit form, setting the two unused high-order bits of each
sample to 0. The image dictionary should then specify a
Decode array of
[0.00000 4.04762], which maps input values from 0 to 63 into the range 0.0 to 1.0
(4.04762 being approximately equal to 255 ÷ 63). If an output value falls outside
the range allowed for a component, it is automatically adjusted to the nearest al-
lowed value.
Image Interpolation
When the resolution of a source image is significantly lower than that of the out-
put device, each source sample covers many device pixels. As a result, images can
appear jaggy or blocky. These visual artifacts can be reduced by applying an im-
age interpolation algorithm during rendering. Instead of painting all pixels cov-
ered by a source sample with the same color, image interpolation attempts to
produce a smooth transition between adjacent sample values. Image interpola-
tion is enabled by setting the
Interpolate entry in the image dictionary to true. It
is disabled by default because it may increase the time required to render the im-
age.
ICCBased Same as the value of Range in the ICC profile of the image’s color
space
Indexed [0 N], where N = 2
n
1
Pattern (Not permitted with images)
Separation
[0.0 1.0]
DeviceN [ 0.0 1.0 0.0 1.0 … 0.0 1.0]
(one pair of elements for each color
component)
COLOR SPACE Decode ARRAY
ImagesSECTION 4.8
317
Note: The interpolation algorithm is implementation-dependent and is not specified
by PDF. Image interpolation may not always be performed for some classes of imag-
es or on some output devices.
Alternate Images
Alternate images (PDF 1.3) provide a straightforward and backward-compatible
way to include multiple versions of an image in a PDF file for different purposes.
These variant representations of the image may differ, for example, in resolution
or in color space. The primary goal is to reduce the need to maintain separate
versions of a PDF document for low-resolution on-screen viewing and high-
resolution printing.
In PDF 1.3, a base image (that is, the image XObject referred to in a resource
dictionary) can contain an
Alternates entry. The value of this entry is an array of
alternate image dictionaries specifying variant representations of the base image.
Each alternate image dictionary contains an image XObject for one variant and
specifies its properties. Table 4.41 shows the contents of an alternate image dictio-
nary.
TABLE 4.41 Entries in an alternate image dictionary
Example 4.29 shows an image with a single alternate. The base image is a gray-
scale image, and the alternate is a high-resolution RGB image stored on a Web
server.
KEY TYPE VALUE
Image
stream (Required) The image XObject for the alternate image.
DefaultForPrinting
boolean (Optional) A flag indicating whether this alternate image is the default ver-
sion to be used for printing. At most one alternate for a given base image may
be so designated. If no alternate has this entry set to
true, the base image is
used for printing.
OC
dictionary (Optional; PDF 1.5) An optional content group (see Section 4.10.1, “Optional
Content Groups”) or optional content membership dictionary (see “Optional
Content Membership Dictionaries” on page 335”) that facilitates the selection
of which alternate image to use.
GraphicsCHAPTER 4
318
Example 4.29
10 0 obj % Image XObject
<< /Type /XObject
/Subtype /Image
/Width 100
/Height 200
/ColorSpace /DeviceGray
/BitsPerComponent 8
/Alternates 15 0 R
/Length 2167
/Filter /DCTDecode
>>
stream
…Image data …
endstream
endobj
15 0 obj % Alternate images array
[ << /Image 16 0 R
/DefaultForPrinting true
>>
]
endobj
16 0 obj % Alternate image
<< /Type /XObject
/Subtype /Image
/Width 1000
/Height 2000
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Length 0 % This is an external stream
/F << /FS /URL
/F (http://www.myserver.mycorp.com/images/exttest.jpg)
>>
/FFilter /DCTDecode
>>
stream
endstream
endobj
ImagesSECTION 4.8
319
In PDF 1.5, optional content (see Section 4.10) can be used to facilitate selection
between alternate images. If an image XObject contains both an
Alternates entry
and an
OC entry, the choice of which image to use is determined as follows:
1. If the image’s
OC entry specifies that the base image is visible, that image is dis-
played.
2. Otherwise, the list of alternates specified by the
Alternates entry is examined,
and the first alternate containing an
OC entry specifying that its content
should be visible is shown. (Alternate images that have no
OC entry are not
shown.)
4.8.5 Masked Images
Ordinarily, in the opaque imaging model, images mark all areas they occupy on
the page as if with opaque paint. All portions of the image, whether black, white,
gray, or color, completely obscure any marks that may previously have existed in
the same place on the page. In the graphic arts industry and page layout appli-
cations, however, it is common to crop or mask out the background of an image
and then place the masked image on a different background so that the existing
background shows through the masked areas. A number of PDF features are
available for achieving such masking effects (see implementation note 53 in Ap-
pendix H):
• The ImageMask entry in the image dictionary, available in all versions of PDF,
specifies that the image data is to be used as a stencil mask for painting in the
current color.
• The Mask entry in the image dictionary (PDF 1.3) may specify a separate image
XObject to be used as an explicit mask specifying which areas of the image to
paint and which to mask out.
• Alternatively, the Mask entry (PDF 1.3) may specify a range of colors to be
masked out wherever they occur within the image. This technique is known as
color key masking.
Note: Although the
Mask entry is a PDF 1.3 feature, its effects are commonly simu-
lated in earlier versions of PDF by defining a clipping path enclosing only those of an
image’s samples that are to be painted. However, implementation limits can cause
errors if the clipping path is very complex (or if there is more than one clipping
path). An alternative way to achieve the effect of an explicit mask in PDF 1.2 is to
GraphicsCHAPTER 4
320
define the image being clipped as a pattern, make it the current color, and then
paint the explicit mask as an image whose
ImageMask entry is true. In any case, the
PDF 1.3 features allow masked images to be placed on the page regardless of the
complexity of the clipping path.
In the transparent imaging model, a fourth type of masking effect, soft masking, is
available through the
SMask entry (PDF 1.4) or the SMaskInData entry (PDF 1.5)
in the image dictionary; see Section 7.5.4, “Specifying Soft Masks,” for further dis-
cussion.
Stencil Masking
An image mask (an image XObject whose ImageMask entry is true) is a mono-
chrome image in which each sample is specified by a single bit. However, instead
of being painted in opaque black and white, the image mask is treated as a stencil
mask that is partly opaque and partly transparent. Sample values in the image do
not represent black and white pixels; rather, they designate places on the page that
should either be marked with the current color or masked out (not marked at all).
Areas that are masked out retain their former contents. The effect is like applying
paint in the current color through a cut-out stencil, which lets the paint reach the
page in some places and masks it out in others.
An image mask differs from an ordinary image in the following significant ways:
• The image dictionary does not contain a ColorSpace entry because sample
values represent masking properties (1 bit per sample) rather than colors.
• The value of the BitsPerComponent entry must be 1.
• The Decode entry determines how the source samples are to be interpreted. If
the
Decode array is [0 1] (the default for an image mask), a sample value of 0
marks the page with the current color, and a 1 leaves the previous contents un-
changed. If the
Decode array is [1 0], these meanings are reversed.
One of the most important uses of stencil masking is for painting character
glyphs represented as bitmaps. Using such a glyph as a stencil mask transfers only
its “black” bits to the page, leaving the “white” bits (which are really just back-
ground) unchanged. For reasons discussed in Section 5.5.4, “Type 3 Fonts,” an
image mask, rather than an image, should almost always be used to paint glyph
bitmaps.
ImagesSECTION 4.8
321
Note: If image interpolation (see “Image Interpolation” on page 316) is requested
during stencil masking, the effect is to smooth the edges of the mask, not to interpo-
late the painted color values. This effect can minimize the jaggy appearance of a
low-resolution stencil mask.
Explicit Masking
In PDF 1.3, the Mask entry in an image dictionary may be an image mask, as de-
scribed above under “Stencil Masking,” which serves as an explicit mask for the
primary (base) image. The base image and the image mask need not have the
same resolution (
Width and Height values), but since all images are defined on
the unit square in user space, their boundaries on the page will coincide; that is,
they will overlay each other. The image mask indicates which places on the page
are to be painted and which are to be masked out (left unchanged). Unmasked ar-
eas are painted with the corresponding portions of the base image; masked areas
are not.
Color Key Masking
In PDF 1.3, the Mask entry in an image dictionary may alternatively be an array
specifying a range of colors to be masked out. Samples in the image that fall with-
in this range are not painted, allowing the existing background to show through.
The effect is similar to that of the video technique known as chroma-key.
For color key masking, the value of the
Mask entry is an array of 2 × n integers,
[min
1
max
1
… min
n
max
n
], where n is the number of color components in the
image’s color space. Each integer must be in the range 0 to 2
BitsPerComponent
1,
representing color values before decoding with the
Decode array. An image sam-
ple is masked (not painted) if all of its color components before decoding, c
1
…c
n
,
fall within the specified ranges (that is, if min
i
c
i
max
i
for all 1 i n).
Note: When color key masking is specified, the use of a
DCTDecode filter for the
stream is not recommended.
DCTDecode is a lossy filter, meaning that the output is
only an approximation of the original input data. Therefore, the use of this filter can
lead to slight changes in the color values of image samples, possibly causing samples
that were intended to be masked to be unexpectedly painted instead, in colors slight-
ly different from the mask color.
GraphicsCHAPTER 4
322
4.8.6 Inline Images
As an alternative to the image XObjects described in Section 4.8.4, “Image Dictio-
naries,” a sampled image may be specified in the form of an inline image. This
type of image is defined directly within the content stream in which it will be
painted rather than as a separate object. Because the inline format gives the appli-
cation less flexibility in managing the image data, it should be used only for small
images (4 KB or less).
An inline image object is delimited in the content stream by the operators
BI
(begin image), ID (image data), and EI (end image). These operators are summa-
rized in Table 4.42.
BI and ID bracket a series of key-value pairs specifying the
characteristics of the image, such as its dimensions and color space; the image
data follows between the
ID and EI operators. The format is thus analogous to that
of a stream object such as an image XObject:
BI
…Key-value pairs…
ID
…Image data …
EI
TABLE 4.42 Inline image operators
Inline image objects may not be nested; that is, two BI operators may not appear
without an intervening
EI to close the first object. Similarly, an ID operator may
appear only between a
BI and its balancing EI. Unless the image uses
ASCIIHexDecode or ASCII85Decode as one of its filters, the ID operator should be
followed by a single white-space character, and the next character is interpreted
as the first byte of image data.
The key-value pairs appearing between the
BI and ID operators are analogous to
those in the dictionary portion of an image XObject (though the syntax is differ-
ent). Table 4.43 shows the entries that are valid for an inline image, all of which
OPERANDS OPERATOR DESCRIPTION
—
BI
Begin an inline image object.
—
ID
Begin the image data for an inline image object.
—
EI
End an inline image object.
ImagesSECTION 4.8
323
have the same meanings as in a stream dictionary (Table 3.4 on page 38) or an
image dictionary (Table 4.39). Entries other than those listed are ignored; in par-
ticular, the
Type, Subtype, and Length entries normally found in a stream or im-
age dictionary are unnecessary. For convenience, the abbreviations shown in the
table may be used in place of the fully spelled-out keys. Table 4.44 shows addi-
tional abbreviations that can be used for the names of color spaces and filters.
Note, however, that these abbreviations are valid only in inline images; they may
not be used in image XObjects. Also note that
JBIG2Decode and JPXDecode are
not listed in Table 4.44 because those filters can be applied only to image
XObjects.
TABLE 4.43 Entries in an inline image object
TABLE 4.44 Additional abbreviations in an inline image object
FULL NAME ABBREVIATION
BitsPerComponent
BPC
ColorSpace CS
Decode D
DecodeParms DP
Filter F
Height H
ImageMask IM
Intent
(PDF 1.1) No abbreviation
Interpolate
I
(uppercase I)
Width W
FULL NAME ABBREVIATION
DeviceGray G
DeviceRGB
RGB
DeviceCMYK
CMYK
Indexed I
(uppercase I)
GraphicsCHAPTER 4
324
The color space specified by the ColorSpace (or CS) entry may be any of the stan-
dard device color spaces (
DeviceGray, DeviceRGB, or DeviceCMYK). It may not be
a CIE-based color space or a special color space, with the exception of a limited
form of
Indexed color space whose base color space is a device space and whose
color table is specified by a string (see “Indexed Color Spaces” on page 232).
Beginning with PDF 1.2, the value of the
ColorSpace entry may also be the name
of a color space in the
ColorSpace subdictionary of the current resource dictio-
nary (see Section 3.7.2, “Resource Dictionaries”). In this case, the name may des-
ignate any color space that can be used with an image XObject.
Note: The names
DeviceGray, DeviceRGB, and DeviceCMYK (as well as their abbre-
viations
G, RGB, and CMYK) always identify the corresponding color spaces directly;
they never refer to resources in the
ColorSpace subdictionary.
The image data in an inline image may be encoded by using any of the standard
PDF filters. The bytes between the
ID and EI operators are treated much the same
as a stream object’s data (see Section 3.2.7, “Stream Objects”), even though they
do not follow the standard stream syntax. (This is an exception to the usual rule
that the data in a content stream is interpreted according to the standard PDF
syntax for objects.)
Example 4.30 shows an inline image 17 samples wide by 17 high with 8 bits per
component in the
DeviceRGB color space. The image has been encoded using
LZW and ASCII base-85 encoding. The
cm operator is used to scale it to a width
and height of 17 units in user space and position it at coordinates (298, 388). The
q and Q operators encapsulate the cm operation to limit its effect to resizing the
image.
ASCIIHexDecode AHx
ASCII85Decode A85
LZWDecode LZW
FlateDecode
(PDF 1.2) Fl (uppercase F, lowercase L)
RunLengthDecode RL
CCITTFaxDecode CCF
DCTDecode DCT
FULL NAME ABBREVIATION
Form XObjectsSECTION 4.9
325
Example 4.30
q % Save graphics state
17 0 0 17 298 388 cm % Scale and translate coordinate space
BI % Begin inline image object
/W 17 % Width in samples
/H 17 % Height in samples
/CS /RGB % Color space
/BPC 8 % Bits per component
/F [/A85 /LZW] % Filters
ID % Begin image data
J1/gKA>.]AN&J?]-<HW]aRVcg*bb.\eKAdVV%/PcZ
…Omitted data…
R.s(4KE3&d&7hb*7[%Ct2HCqC~>
EI % End inline image object
Q % Restore graphics state
4.9 Form XObjects
A form XObject is a PDF content stream that is a self-contained description of any
sequence of graphics objects (including path objects, text objects, and sampled
images). A form XObject may be painted multiple times—either on several pages
or at several locations on the same page—and produces the same results each
time, subject only to the graphics state at the time it is invoked. Not only is this
shared definition economical to represent in the PDF file, but under suitable cir-
cumstances the PDF consumer application can optimize execution by caching the
results of rendering the form XObject for repeated reuse.
Note: The term form also refers to a completely different kind of object, an inter-
active form (sometimes called an AcroForm), discussed in Section 8.6, “Interactive
Forms.” Whereas the form XObjects described in this section correspond to the no-
tion of forms in the PostScript language, interactive forms are the PDF equivalent of
the familiar paper instrument. Any unqualified use of the word form is understood
to refer to an interactive form; the type of form described here is always referred to
explicitly as a form XObject.
GraphicsCHAPTER 4
326
Form XObjects have various uses:
• As its name suggests, a form XObject can serve as the template for an entire
page. For example, a program that prints filled-in tax forms can first paint the
fixed template as a form XObject and then paint the variable information on
top of it.
• Any graphical element that is to be used repeatedly, such as a company logo or
a standard component in the output from a computer-aided design system, can
be defined as a form XObject.
• Certain document elements that are not part of a page’s contents, such as
annotation appearances (see Section 8.4.4, “Appearance Streams”), are repre-
sented as form XObjects.
• A specialized type of form XObject, called a group XObject (PDF 1.4), can be
used to group graphical elements together as a unit for various purposes (see
Section 4.9.2, “Group XObjects”). In particular, group XObjects are used to de-
fine transparency groups and soft masks for use in the transparent imaging
model (see “Soft-Mask Dictionaries” on page 520 and Section 7.5.5, “Transpar-
ency Group XObjects”).
• Another specialized type of form XObject, a reference XObject (PDF 1.4), can
be used to import content from one PDF document into another (see Section
4.9.3, “Reference XObjects”).
The use of form XObjects requires two steps:
1. Define the appearance of the form XObject. A form XObject is a PDF content
stream. The dictionary portion of the stream (called the form dictionary)
contains descriptive information about the form XObject; the body of the
stream describes the graphics objects that produce its appearance. The con-
tents of the form dictionary are described in Section 4.9.1, “Form Diction-
aries.”
2. Paint the form XObject. The
Do operator (see Section 4.7, “External Objects”)
paints a form XObject whose name is supplied as an operand. (The name is
defined in the
XObject subdictionary of the current resource dictionary.)
Before invoking this operator, the content stream in which it appears should
set appropriate parameters in the graphics state. In particular, it should alter
the current transformation matrix to control the position, size, and orientation
of the form XObject in user space.
Form XObjectsSECTION 4.9
327
Each form XObject is defined in its own coordinate system, called form space.
The
BBox entry in the form dictionary is expressed in form space, as are any
coordinates used in the form XObject’s content stream, such as path coordinates.
The
Matrix entry in the form dictionary specifies the mapping from form space to
the current user space. Each time the form XObject is painted by the
Do operator,
this matrix is concatenated with the current transformation matrix to define the
mapping from form space to device space. (This differs from the
Matrix entry in a
pattern dictionary, which maps pattern space to the initial user space of the con-
tent stream in which the pattern is used.)
When the
Do operator is applied to a form XObject, it does the following tasks:
1. Saves the current graphics state, as if by invoking the
q operator (see Section
4.3.3, “Graphics State Operators”)
2. Concatenates the matrix from the form dictionary’s
Matrix entry with the cur-
rent transformation matrix (CTM)
3. Clips according to the form dictionary’s
BBox entry
4. Paints the graphics objects specified in the form’s content stream
5. Restores the saved graphics state, as if by invoking the
Q operator (see Section
4.3.3, “Graphics State Operators”)
Except as described above, the initial graphics state for the form is inherited from
the graphics state that is in effect at the time
Do is invoked.
4.9.1 Form Dictionaries
Every form XObject has a form type, which determines the format and meaning
of the entries in its form dictionary. At the time of publication, only one form
type, type 1, has been defined. Form XObject dictionaries may contain the entries
shown in Table 4.45, in addition to the usual entries common to all streams (see
Table 3.4 on page 38).
GraphicsCHAPTER 4
328
TABLE 4.45 Additional entries specific to a type 1 form dictionary
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if present,
must be
XObject for a form XObject.
Subtype name (Required) The type of XObject that this dictionary describes; must be Form
for a form XObject.
FormType integer (Optional) A code identifying the type of form XObject that this dictionary
describes. The only valid value defined at the time of publication is 1. Default
value: 1.
BBox rectangle (Required) An array of four numbers in the form coordinate system (see
above), giving the coordinates of the left, bottom, right, and top edges,
respectively, of the form XObject’s bounding box. These boundaries are used
to clip the form XObject and to determine its size for caching.
Matrix array (Optional) An array of six numbers specifying the form matrix, which maps
form space into user space (see Section 4.2.3, “Transformation Matrices”).
Default value: the identity matrix
[100100].
Resources dictionary (Optional but strongly recommended; PDF 1.2) A dictionary specifying any
resources (such as fonts and images) required by the form XObject (see Sec-
tion 3.7, “Content Streams and Resources”).
In PDF 1.1 and earlier, all named resources used in the form XObject must be
included in the resource dictionary of each page object on which the form
XObject appears, regardless of whether they also appear in the resource dic-
tionary of the form XObject. It can be useful to specify these resources in the
form XObject’s resource dictionary as well, to determine which resources are
used inside the form XObject. If a resource is included in both dictionaries, it
should have the same name in both locations.
In PDF 1.2 and later versions, form XObjects can be independent of the
content streams in which they appear, and this is strongly recommended
although not required. In an independent form XObject, the resource dictio-
nary of the form XObject is required and contains all named resources used
by the form XObject. These resources are not promoted to the outer content
stream’s resource dictionary, although that stream’s resource dictionary refers
to the form XObject.
Form XObjectsSECTION 4.9
329
Group dictionary (Optional; PDF 1.4) A group attributes dictionary indicating that the contents
of the form XObject are to be treated as a group and specifying the attributes
of that group (see Section 4.9.2, “Group XObjects”).
Note: If a
Ref entry (see below) is present, the group attributes also apply to the
external page imported by that entry, which allows such an imported page to be
treated as a group without further modification.
Ref dictionary (Optional; PDF 1.4) A reference dictionary identifying a page to be imported
from another PDF file, and for which the form XObject serves as a proxy (see
Section 4.9.3, “Reference XObjects”).
Metadata stream (Optional; PDF 1.4) A metadata stream containing metadata for the form
XObject (see Section 10.2.2, “Metadata Streams”).
PieceInfo dictionary (Optional; PDF 1.3) A page-piece dictionary associated with the form
XObject (see Section 10.4, “Page-Piece Dictionaries”).
LastModified date (Required if PieceInfo is present; optional otherwise; PDF 1.3) The date and
time (see Section 3.8.3, “Dates”) when the form XObject’s contents were most
recently modified. If a page-piece dictionary (
PieceInfo) is present, the modi-
fication date is used to ascertain which of the application data dictionaries it
contains correspond to the current content of the form (see Section 10.4,
“Page-Piece Dictionaries”).
StructParent integer (Required if the form XObject is a structural content item; PDF 1.3) The integer
key of the form XObject’s entry in the structural parent tree (see “Finding
Structure Elements from Content Items” on page 797).
StructParents integer (Required if the form XObject contains marked-content sequences that are
structural content items; PDF 1.3) The integer key of the form XObject’s entry
in the structural parent tree (see “Finding Structure Elements from Content
Items” on page 797).
Note: At most one of the entries
StructParent or StructParents may be present. A
form XObject can be either a content item in its entirety or a container for
marked-content sequences that are content items, but not both.
OPI dictionary (Optional; PDF 1.2) An OPI version dictionary for the form XObject (see Sec-
tion 10.10.6, “Open Prepress Interface (OPI)”).
KEY TYPE VALUE
GraphicsCHAPTER 4
330
Example 4.31 shows a simple form XObject that paints a filled square 1000 units
on each side.
Example 4.31
6 0 obj % Form XObject
<< /Type /XObject
/Subtype /Form
/FormType 1
/BBox [0 0 1000 1000]
/Matrix[100100]
/Resources << /ProcSet [/PDF] >>
/Length 58
>>
stream
00m
0 1000 l
1000 1000 l
1000 0 l
f
endstream
endobj
4.9.2 Group XObjects
A group XObject (PDF 1.4) is a special type of form XObject that can be used to
group graphical elements together as a unit for various purposes. It is distin-
guished by the presence of the optional
Group entry in the form dictionary (see
OC
dictionary (Optional; PDF 1.5) An optional content group or optional content member-
ship dictionary (see Section 4.10, “Optional Content”) specifying the optional
content properties for the form XObject. Before the form is processed, its vis-
ibility is determined based on this entry. If it is determined to be invisible, the
entire form is skipped, as if there were no
Do operator to invoke it.
Name name (Required in PDF 1.0; optional otherwise) The name by which this form
XObject is referenced in the
XObject subdictionary of the current resource
dictionary (see Section 3.7.2, “Resource Dictionaries”).
Note: This entry is obsolescent and its use is no longer recommended. (See
implementation note 54 in Appendix H.)
KEY TYPE VALUE
Form XObjectsSECTION 4.9
331
Section 4.9.1, “Form Dictionaries”). The value of this entry is a subsidiary group
attributes dictionary describing the properties of the group.
As shown in Table 4.46, every group XObject has a group subtype (specified by
the
S entry in the group attributes dictionary) that determines the format and
meaning of the dictionary’s remaining entries. Only one such subtype is currently
defined, a transparency group XObject (subtype
Transparency) representing a
transparency group for use in the transparent imaging model (see Section 7.3,
“Transparency Groups”). The remaining contents of this type of dictionary are
described in Section 7.5.5, “Transparency Group XObjects.”
TABLE 4.46 Entries common to all group attributes dictionaries
4.9.3 Reference XObjects
Reference XObjects (PDF 1.4) enable one PDF document to import content from
another. The document in which the reference occurs is called the containing
document; the one whose content is being imported is the target document. The
target document may reside in a file external to the containing document or may
be included within it as an embedded file stream (see Section 3.10.3, “Embedded
File Streams”).
The reference XObject in the containing document is a form XObject containing
the optional
Ref entry in its form dictionary, as described below. This form XOb-
ject serves as a proxy that can be displayed or printed in place of the imported
content. The proxy might consist of a low-resolution image of the imported con-
tent, a piece of descriptive text referring to it, a gray box to be displayed in its
place, or any other similar placeholder. PDF consumers that do not recognize the
Ref entry simply display or print the proxy as an ordinary form XObject (see im-
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if present, must
be
Group for a group attributes dictionary.
S name (Required) The group subtype, which identifies the type of group whose at-
tributes this dictionary describes and determines the format and meaning of the
dictionary’s remaining entries. The only group subtype defined in PDF 1.4 is
Transparency; see Section 7.5.5, “Transparency Group XObjects,” for the re-
maining contents of this type of dictionary. Other group subtypes may be added
in the future.
GraphicsCHAPTER 4
332
plementation note 55 in Appendix H). Those that do implement reference XOb-
jects can use the proxy in place of the imported content if the latter is unavailable.
An application may also provide a user interface to allow editing and updating of
imported content links.
The imported content consists of a single, complete PDF page in the target docu-
ment. It is designated by a reference dictionary, which in turn is the value of the
Ref entry in the reference XObject’s form dictionary (see Section 4.9.1, “Form
Dictionaries”). The presence of the
Ref entry distinguishes reference XObjects
from other types of form XObjects. Table 4.47 shows the contents of the reference
dictionary.
TABLE 4.47 Entries in a reference dictionary
When the imported content replaces the proxy, it is transformed according to the
proxy object’s transformation matrix and clipped to the boundaries of its bound-
ing box, as specified by the
Matrix and BBox entries in the proxy’s form dictionary
(see Section 4.9.1, “Form Dictionaries”). The combination of the proxy object’s
matrix and bounding box thus implicitly defines the bounding box of the import-
ed page. This bounding box typically coincides with the imported page’s crop box
or art box (see Section 10.10.1, “Page Boundaries”), but it is not required to corre-
spond to any of the defined page boundaries. If the proxy object’s form dictionary
contains a
Group entry, the specified group attributes apply to the imported page
as well, which allows the imported page to be treated as a group without further
modification.
KEY TYPE VALUE
F file specification (Required) The file containing the target document.
Page integer or
text string
(Required) A page index or page label (see Section 8.3.1, “Page Labels”) iden-
tifying the page of the target document containing the content to be
imported. Note that the reference is a weak one and can be inadvertently in-
validated if the referenced page is changed or replaced in the target document
after the reference is created.
ID array (Optional) An array of two strings constituting a file identifier (see Section
10.3, “File Identifiers”) for the file containing the target document. The use of
this entry improves an application’s chances of finding the intended file and
allows it to warn the user if the file has changed since the reference was creat-
ed.
Form XObjectsSECTION 4.9
333
Printing Reference XObjects
When printing a page containing reference XObjects, an application may emit
any of the following items, depending on the capabilities of the application, the
user’s preferences, and the nature of the print job:
• The imported content designated by the reference XObject
• The reference XObject as a proxy for the imported content
• An OPI proxy or substitute image taken from the reference XObject’s OPI dic-
tionary, if any (see Section 10.10.6, “Open Prepress Interface (OPI)”)
The imported content or the reference XObject may also be emitted in place of an
OPI proxy when generating OPI comments in a PostScript output stream.
Special Considerations
Certain special considerations arise when reference XObjects interact with other
PDF features:
• When the page imported by a reference XObject contains annotations (see Sec-
tion 8.4, “Annotations”), all annotations that contain a printable, unhidden, vis-
ible appearance stream (Section 8.4.4, “Appearance Streams”) must be included
in the rendering of the imported page. If the proxy is a snapshot image of the
imported page, it must also include the annotation appearances. These appear-
ances must therefore be converted into part of the proxy’s content stream, ei-
ther as subsidiary form XObjects or by flattening them directly into the content
stream.
• Logical structure information associated with a page (see Section 10.6, “Logical
Structure”) should normally be ignored when importing the page into another
document with a reference XObject. In a target document with multiple pages,
structure elements occurring on the imported page are typically part of a larger
structure pertaining to the document as a whole; such elements cannot mean-
ingfully be incorporated into the structure of the containing document. In a
one-page target document or one made up of independent, structurally unre-
lated pages, the logical structure for the imported page may be wholly self-con-
tained; in this case, it may be possible to incorporate this structure information
into that of the containing document. However, PDF provides no mechanism
GraphicsCHAPTER 4
334
for the logical structure hierarchy of one document to refer indirectly to that of
another.
4.10 Optional Content
Optional content (PDF 1.5) refers to sections of content in a PDF document that
can be selectively viewed or hidden by document authors or consumers. This ca-
pability is useful in items such as CAD drawings, layered artwork, maps, and
multi-language documents.
The following sections describe the PDF structures used to implement optional
content:
• Section 4.10.1, “Optional Content Groups,” describes the primary structures
used to control the visibility of content.
• Section 4.10.2, “Making Graphical Content Optional,” describes how individual
pieces of content in a document may declare themselves as belonging to one or
more optional content groups.
• Section 4.10.3, “Configuring Optional Content,” describes how the states of op-
tional content groups are set.
4.10.1 Optional Content Groups
An optional content group is a dictionary representing a collection of graphics
that can be made visible or invisible dynamically by users of viewer applications.
The graphics belonging to such a group can reside anywhere in the document:
they need not be consecutive in drawing order, nor even belong to the same con-
tent stream. Table 4.48 shows the entries in an optional content group dictionary.
TABLE 4.48 Entries in an optional content group dictionary
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be OCG
for an optional content group dictionary.
Name
text string (Required) The name of the optional content group, suitable for presentation in
a viewer application’s user interface.
Optional ContentSECTION 4.10
335
In its simplest form, each dictionary contains a Type entry and a Name for pre-
sentation in a user interface. It may also have an
Intent entry that describes its in-
tended use (see “Intent” on page 338) and a
Usage entry that describes the nature
of its content (see “Usage and Usage Application Dictionaries” on page 350).
Individual content elements in a document specify the optional content group or
groups that affect their visibility (see Section 4.10.2, “Making Graphical Content
Optional”). Any content whose visibility can be affected by a given optional con-
tent group is said to belong to that group.
A group is assigned a state, which is either
ON or OFF. States are not themselves
part of the PDF document but can be set programmatically or through the viewer
user interface to change the visibility of content. When a document is first
opened, the groups’ states are initialized based on the document’s default config-
uration dictionary (see “Optional Content Configuration Dictionaries” on page
345).
In the typical case, content belonging to a group is visible when the group is
ON
and invisible when it is OFF. In more complex cases, content can belong to multi-
ple groups, which may have conflicting states. These cases are described by the
use of optional content membership dictionaries, described in the next section.
Optional Content Membership Dictionaries
As mentioned above, content typically belongs to a single optional content group
and is visible when the group is
ON and invisible when it is OFF. To express more
complex visibility policies, content should declare itself not to belong directly to
Intent
name or array (Optional) A single intent name or an array containing any combination of
names. PDF 1.5 defines two names,
View and Design, that indicate the intended
use of the graphics in the group. Future versions may define others. A process-
ing application can choose to use only groups that have a specific intent and ig-
nore others.
Default value:
View. See “Intent” on page 338 for more information.
Usage
dictionary (Optional) A usage dictionary describing the nature of the content controlled by
the group. It may be used by features that automatically control the state of the
group based on outside factors. See “Usage and Usage Application Dictionaries”
on page 350 for more information.
KEY TYPE VALUE
GraphicsCHAPTER 4
336
an optional content group but rather to an optional content membership dictio-
nary, whose entries are shown in Table 4.49. (Section 4.10.2 describes how con-
tent declares its membership in a group or membership dictionary.)
TABLE 4.49 Entries in an optional content membership dictionary
An optional content membership dictionary can express its visibility policy in
two ways:
• The P entry specifies a simple boolean expression indicating how the optional
content groups specified by the
OCGs entry determine the visibility of content
controlled by the membership dictionary.
• PDF 1.6 introduces the VE entry, which is a visibility expression that can specify
an arbitrary boolean expression for computing the visibility of content from the
states of optional content groups.
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be OCMD
for an optional content membership dictionary.
OCGs
dictionary or
array
(Optional) A dictionary or array of dictionaries specifying the optional content
groups whose states determine the visibility of content controlled by this member-
ship dictionary.
Note: Null values or references to deleted objects are ignored. If this entry is not
present, is an empty array, or contains references only to null or deleted objects, the
membership dictionary has no effect on the visibility of any content.
P
name (Optional) A name specifying the visibility policy for content belonging to this
membership dictionary. Valid values are:
• AllOn: visible only if all of the entries in OCGs are ON
• AnyOn: visible if any of the entries in OCGs are ON
• AnyOff: visible if any of the entries in OCGs are OFF
• AllOff: visible only if all of the entries in OCGs are OFF
Default value: AnyOn
VE
array (Optional; PDF 1.6) An array specifying a visibility expression, used to compute vis-
ibility of content based on a set of optional content groups; see discussion below.
Optional ContentSECTION 4.10
337
Note: Since the VE entry is more general, if it is present and supported by the PDF
consumer software, it should be used in preference to
OCGs and P. However, for
compatibility purposes, PDF creators should use
OCGs and P entries where possible.
When the use of
VE is necessary to express the intended behavior, OCGs and P en-
tries should also be provided to approximate the behavior in older consumer soft-
ware.
A visibility expression is an array with the following characteristics:
• Its first element is a name representing a boolean operator (And, Or, or Not).
• Subsequent elements are either optional content groups or other visibility ex-
pressions.
• If the first element is Not, it should have only one subsequent element. If the
first element is
And or Or, it may have one or more subsequent elements.
• In evaluating a visibility expression, the ON state of an optional content group is
equated to the boolean value
true; OFF is equated to false.
Examples 4.33 and 4.34 illustrate the use of visibility expressions.
Membership dictionaries are useful in cases such as these:
• Some content may choose to be invisible when a group is ON and visible when it
is
OFF. In this case, the content would belong to a membership dictionary
whose
OCGs entry consists of a single optional content group and whose P en-
try is
AnyOff or AllOff.
Note: It is legal to have an
OCGs entry consisting of a single group and a P entry
that is
AnyOn or AllOn. However, in this case it is preferable to use an optional
content group directly because it uses fewer objects.
• Some content may belong to more than one group and must specify its policy
when the groups are in conflicting states. In this case, the content would belong
to a membership dictionary whose
OCGs entry consists of an array of optional
content groups and whose
P entry specifies the visibility policy, as illustrated in
Example 4.32 below. (Example 4.33 shows the equivalent policy using visibility
expressions.)
GraphicsCHAPTER 4
338
Example 4.32
<< /Type /OCMD % Content belonging to this optional content
% membership dictionary is controlled by the states
/OCGs [12 0 R 13 0 R 14 0 R] % of three optional content groups.
/P /AllOn % Content is visible only if the state of all three
>> % groups is ON; otherwise it’s hidden.
Example 4.33
<< /Type /OCMD
/VE [/And 12 0 R 13 0 R 14 0 R] % Visibility expression equivalent to Example 4.32.
>>
Example 4.34 shows a more complicated visibility expression based on five op-
tional content groups, represented by objects 1 through 5. It is equivalent to
“OCG 1” OR (NOT “OCG 2”) OR (“OCG 3” AND “OCG 4” AND “OCG 5”)
Example 4.34
<< /Type /OCMD
/VE [/Or % Visibility expression: OR
1 0 R % OCG 1
[/Not 2 0 R] % NOT OCG 2
[/And 3 0 R 4 0 R 5 0 R] % OCG 3 AND OCG 4 AND OCG 5
]
>>
Intent
The Intent entry in Table 4.48 provides a way to distinguish between different in-
tended uses of optional content. For example, many document design applica-
tions, such as CAD packages, offer layering features for collecting groups of
graphics together and selectively hiding or viewing them for the convenience of
the author. However, this layering may be different (at a finer granularity, for ex-
ample) than would be useful to consumers of the document. Therefore, it is pos-
sible to specify different intents for optional content groups within a single
document. A given application may decide to use only groups that are of a specif-
ic intent.
PDF 1.5 defines two intents:
Design, which is intended to represent a document
designer’s structural organization of artwork, and
View, which is intended for in-
Optional ContentSECTION 4.10
339
teractive use by document consumers. More intents may be added in future PDF
versions; for compatibility with future versions, PDF consumers should allow un-
recognized
Intent values.
Configuration dictionaries (see “Optional Content Configuration Dictionaries”
on page 345) also contain an
Intent entry. If one or more of a group’s intents is
contained in the current configuration’s set of intents, the group is used in deter-
mining visibility. If there is no match, the group has no effect on visibility.
Note: If the configuration’s
Intent is an empty array, no groups are used in determin-
ing visibility; therefore, all content is considered visible.
4.10.2 Making Graphical Content Optional
Graphical content in a PDF file can be made optional by specifying membership
in an optional content group or optional content membership dictionary. Two
primary mechanisms are available:
• Sections of content streams delimited by marked-content operators can be
made optional, as described in “Optional Content in Content Streams,” below.
• Form and image XObjects and annotations can be made optional in their en-
tirety by means of a dictionary entry, as described in “Optional Content in
XObjects and Annotations” on page 344.
When a piece of optional content in a PDF file is determined to be hidden, the
following occurs:
• The content is not drawn.
• Graphics state operations, such as setting the color, transformation matrix, and
clipping, are still applied. In addition, graphics state side effects that arise from
drawing operators are applied; in particular, the current text position is updat-
ed even for text wrapped in optional content. In other words, graphics state pa-
rameters that persist past the end of a marked-content section must be the
same whether the optional content is visible or not. For example, hiding a sec-
tion of optional content does not change the color of objects that do not belong
to the same optional content group.
Note: This rule also applies to operators that set state that is not strictly graphics
state; for example,
BX and EX.
GraphicsCHAPTER 4
340
• Objects such as form XObjects and annotations that are made optional may be
skipped entirely, because their contents are encapsulated such that no changes
to the graphics state (or other state) persist beyond the processing of their con-
tent stream.
Other features in PDF consuming applications, such as searching and editing,
may be affected by the ability to selectively show or hide content. Features must
choose whether to use the document’s current state of optional content groups
(and, correspondingly, the document’s visible graphics) or to supply their own
states of optional content groups to control the graphics they process. For exam-
ple, tools to select and move annotations should honor the current on-screen vis-
ibility of annotations when performing cursor tracking and mouse-click
processing. A full text search engine, however, may need to process all content in
a document, regardless of its current visibility on-screen. Export filters might
choose the current on-screen visibility, the full content, or present the user with a
selection of OCGs to control visibility.
Note: All optional content-related PDF structures are unknown to, and hence ig-
nored by, PDF 1.4 and earlier consumers, which therefore draw and otherwise pro-
cess all content in the document.
Optional Content in Content Streams
Sections of content in a content stream (including a page's Contents stream, a
form or pattern’s content stream, glyph descriptions a Type 3 font as specified by
its
CharProcs entry, or an annotation’s appearance) can be made optional by en-
closing them between the marked-content operators
BDC and EMC (see Section
10.5, “Marked Content”) with a marked-content tag of
OC. In addition, a DP
marked-content operator can be placed in a page’s content stream to force a refer-
ence to an optional content group or groups on the page, even when the page has
no current content in that layer.
The property list associated with the marked content specifies either an optional
content group or optional content membership dictionary to which the content
belongs. Because a group must be an indirect object and a membership dictio-
nary contains references to indirect objects, the property list must be a named re-
source listed in the
Properties subdictionary of the current resource dictionary
(see Section 10.5.1, “Property Lists”), as shown in Examples 4.35 and 4.36.
Optional ContentSECTION 4.10
341
Note: Although the marked-content tag must be OC, other applications of marked
content are not precluded from using
OC as a tag. The marked content is considered
to be for optional content only if the tag is
OC and the dictionary operand is a valid
optional content group or optional content membership dictionary.
To avoid conflict with other features that used marked content (such as logical
structure; see Section 10.6, “Logical Structure”), the following strategy is recom-
mended:
• Where content is to be tagged with optional content markers as well as other
markers, the optional content markers should be nested inside the other
marked content.
• Where optional content and the other markers would overlap but there is not
strict containment, the optional content should be broken up into two or more
BDC/EMC sections, nesting the optional content sections inside the others as
necessary. Breaking up optional content spans does not damage the nature of
the visibility of the content, whereas the same guarantee cannot be made for all
other uses of marked content.
Note: Any marked content tagged for optional content that is nested inside other
marked content tagged for optional content is visible only if all the levels indicate
visibility. In other words, if the settings that apply to the outer level indicate that the
content should be hidden, the inner level is hidden regardless of its settings.
In the following example, the state of the
Show Greeting optional content group
directly controls the visibility of the text string “Hello” on the page. When the
group is
ON, the text is visible; when the group is OFF, the text is hidden.
Example 4.35
% Within a content stream
...
/OC /oc1 BDC % Optional content follows
BT
/F1 1 Tf
12 0 0 12 100 600 Tm
(Hello) Tj
ET
EMC % End of optional content
...
GraphicsCHAPTER 4
342
<< % In the resources dictionary
/Properties << /oc1 5 0 R >> % This dictionary maps the name oc1 to an
... % optional content group (object 5)
>>
5 0 obj % The OCG controlling the visibility
<< % of the text.
/Type /OCG
/Name (Show Greeting)
>>
endobj
The example above shows one piece of content associated with one optional con-
tent group. There are other possibilities:
• More than one section of content can refer to the same group or membership
dictionary, in which case the visibility of both sections is always the same.
• Equivalently, although less space-efficient, different sections can have separate
membership dictionaries with the same
OCGs and P entries. The sections will
have identical visibility behavior.
• Two sections of content can belong to membership dictionaries that refer to the
same group(s) but with different
P settings. For example, if one section has no P
entry, and the other has a P entry of AllOff, the visibility of the two sections of
content are opposite. That is, the first section is visible when the second is hid-
den, and vice versa.
The following example demonstrates both the direct use of optional content
groups and the indirect use of groups through a membership dictionary. The
content (a black rectangle frame) is drawn if either of the images controlled by
the groups named
Image A or Image B is shown. If both groups are hidden, the
rectangle frame is hidden.
Example 4.36
% Within a content stream
...
/OC /OC2 BDC % Draws a black rectangle frame
0 g
4 w
100 100 412 592 re s
EMC
Optional ContentSECTION 4.10
343
/OC /OC3 BDC % Draws an image XObject
q
412 0 0 592 100 100 cm
/Im3 Do
Q
EMC
/OC /OC4 BDC % Draws an image XObject
q
412 0 0 592 100 100 cm
/Im4 Do
Q
EMC
...
<< % The resource dictionary
/Properties << /OC2 20 0 R /OC3 30 0 R /OC4 40 0 R >>
/XObject << /lm3 50 0 R /lm4 /60 0 R >>
>>
20 0 obj
<< % Optional content membership dictionary
/Type /OCMD
/OCGs [30 0 R 40 0 R]
/P /AnyOn
>>
endobj
30 0 obj % Optional content group “Image A”
<<
/Type /OCG
/Name (Image A)
>>
endobj
40 0 obj % Optional content group “Image B”
<<
/Type /OCG
/Name (Image B)
>>
endobj
GraphicsCHAPTER 4
344
Optional Content in XObjects and Annotations
In addition to marked content within content streams, form XObjects and image
XObjects (see Section 4.7, “External Objects”) and annotations (see Section 8.4,
“Annotations”) may contain an
OC entry, which is an optional content group or
an optional content membership dictionary.
A form or image XObject's visibility is determined by the state of the group or
those of the groups referenced by the membership dictionary in conjunction with
its
P (or VE) entry, along with the current visibility state in the context in which
the XObject is invoked (that is, whether objects are visible in the contents stream
at the place where the
Do operation occurred).
Annotations have various flags controlling on-screen and print visibility (see Sec-
tion 8.4.2, “Annotation Flags”). If an annotation contains an
OC entry, it is visible
for screen or print only if the flags have the appropriate settings and the group or
membership dictionary indicates it is visible.
4.10.3 Configuring Optional Content
A PDF document containing optional content can specify the default states for
the optional content groups in the document and indicate which external factors
should be used to alter the states. The following sections describe the PDF struc-
tures that are used to specify this information.
• “Optional Content Properties Dictionary” on page 345 describes the structure
that lists all the optional content groups in the document and their possible
configurations.
• “Optional Content Configuration Dictionaries” on page 345 describes the
structures that specify initial state settings and other information about the
groups in the document.
• “Usage and Usage Application Dictionaries” on page 350 and “Determining the
State of Optional Content Groups” on page 355 describe how the states of
groups can be affected based on external factors.
Optional ContentSECTION 4.10
345
Optional Content Properties Dictionary
The optional OCProperties entry in the document catalog (see Section 3.6.1,
“Document Catalog”) holds the optional content properties dictionary, which con-
tains a list of all the optional content groups in the document, as well as informa-
tion about the default and alternate configurations for optional content. This
dictionary is required if the file contains any optional content; if it is missing, a
PDF consumer should ignore any optional content structures in the document.
This dictionary contains the following entries:
TABLE 4.50 Entries in the optional content properties dictionary
Optional Content Configuration Dictionaries
The D and Configs entries in Table 4.50 are configuration dictionaries, which rep-
resent different presentations of a document’s optional content groups for use by
PDF processing applications or features. The
D configuration dictionary specifies
the initial state of the optional content groups when a document is first opened.
Configs lists other configurations that may be used under particular circumstanc-
es. The entries in a configuration dictionary are shown in Table 4.51.
KEY TYPE VALUE
OCGs
array (Required) An array of indirect references to all the optional content groups in
the document (see Section 4.10.1, “Optional Content Groups”), in any order.
Every optional content group must be included in this array.
D
dictionary (Required) The default viewing optional content configuration dictionary (see
“Optional Content Configuration Dictionaries,” below).
Configs
array (Optional) An array of alternate optional content configuration dictionaries (see
“Optional Content Configuration Dictionaries,” below) for PDF processing ap-
plications or features.
GraphicsCHAPTER 4
346
TABLE 4.51 Entries in an optional content configuration dictionary
KEY TYPE VALUE
Name
text string (Optional) A name for the configuration, suitable for presentation in a user
interface.
Creator
text string (Optional) Name of the application or feature that created this configuration
dictionary.
BaseState
name (Optional) Used to initialize the states of all the optional content groups in a
document when this configuration is applied. The value of this entry must
be one of the following names:
• ON: The states of all groups are turned ON.
• OFF: The states of all groups are turned OFF.
• Unchanged: The states of all groups are left unchanged.
After this initialization, the contents of the
ON and OFF arrays are processed,
overriding the state of the groups included in the arrays.
Default value:
ON.
Note: If
BaseState is present in the document’s default configuration dictio-
nary, its value must be
ON.
ON
array (Optional) An array of optional content groups whose state should be set to
ON when this configuration is applied.
Note: If the
BaseState entry is ON, this entry is redundant.
OFF
array (Optional) An array of optional content groups whose state should be set to
OFF when this configuration is applied.
Note: If the
BaseState entry is OFF, this entry is redundant.
Intent
name or array (Optional) A single intent name or an array containing any combination of
names. It is used to determine which optional content groups’ states to con-
sider and ignore in calculating the visibility of content (see “Intent” on page
338).
PDF 1.5 defines two intent names,
View and Design. Future versions may de-
fine others. In addition, the name
All indicates the set of all intents, including
those not yet defined. Default value:
View. The value must be View for the
document’s default configuration.
Optional ContentSECTION 4.10
347
AS
array (Optional) An array of usage application dictionaries (see Table 4.53) speci-
fying which usage dictionary categories (see Table 4.52) should be consulted
by viewer applications to automatically set the states of optional content
groups based on external factors, such as the current system language or
viewing magnification, and when they should be applied.
Order
array (Optional) An array specifying the recommended order for presentation of
optional content groups in a user interface. The array elements may include
the following objects:
• Optional content group dictionaries, whose Name entry is to be displayed
in the user interface.
• Arrays of optional content groups to allow nesting as in a tree or outline
structure. Each nested array may optionally have as its first element a text
string to be used as a non-selectable label in the user interface.
Note: Text labels in nested arrays should be used to present collections of relat-
ed optional content groups, and not to communicate actual nesting of content
inside multiple layers of groups (see Example 4.37). To reflect actual nesting of
groups in the content, such as for layers with sublayers, nested arrays of groups
without a text label should be used (see Example 4.38).
An empty array
[] explicitly specifies that no groups should be presented.
In the default configuration dictionary, the default value is an empty array;
in other configuration dictionaries, the default is the
Order value from the
default configuration dictionary.
Note: Any groups not listed in this array should not be presented in any user
interface that uses the configuration.
ListMode
name (Optional) A name specifying which optional content groups in the Order ar-
ray should be displayed to the user. Valid values are:
• AllPages: Display all groups in the Order array.
• VisiblePages: Display only those groups in the Order array that are refer-
enced by one or more visible pages.
Default value:
AllPages.
KEY TYPE VALUE
GraphicsCHAPTER 4
348
Examples 4.37 and 4.38 illustrates the use of the Order entry to control the display
of groups in a user interface.
Example 4.37
Given the following PDF objects:
1 0 obj <</Type /OCG /Name (Skin)>> endobj % Optional content groups
2 0 obj <</Type /OCG /Name (Bones)>> endobj
3 0 obj <</Type /OCG /Name (Bark)>> endobj
4 0 obj <</Type /OCG /Name (Wood)>> endobj
5 0 obj % Configuration dictionary
<< /Order [[(Frog Anatomy) 1 0 R 2 0 R] [(Tree Anatomy) 3 0 R 4 0 R] ] >>
RBGroups
array (Optional) An array consisting of one or more arrays, each of which repre-
sents a collection of optional content groups whose states are intended to fol-
low a radio button paradigm. That is, the state of at most one optional
content group in each array should be
ON at a time. If one group is turned
ON, all others must be turned OFF. However, turning a group from ON to
OFF does not force any other group to be turned ON.
An empty array
[] explicitly indicates that no such collections exist.
In the default configuration dictionary, the default value is an empty array;
in other configuration dictionaries, the default is the
RBGroups value from
the default configuration dictionary.
Locked
array (Optional; PDF 1.6) An array of optional content groups that should be
locked when this configuration is applied. The state of a locked group cannot
be changed through the user interface of a viewer application. Producers can
use this entry to prevent the visibility of content that depends on these
groups from being changed by users.
Default value: an empty array.
Note: This entry does not prevent the states of optional content groups from be-
ing changed by means other than the user interface, such as JavaScript or items
in the
AS entry of a configuration dictionary.
KEY TYPE VALUE
Optional ContentSECTION 4.10
349
A PDF viewer should display the optional content groups as follows:
Frog Anatomy
Skin
Bones
Tree Anatomy
Bark
Wood
Example 4.38
Given the following PDF objects:
% Page contents
/OC /L1 BDC % Layer 1
/OC /L1a BDC % Sublayer A of layer 1
0 0 100 100 re f
EMC
/OC /L1b BDC % Sublayer B of layer 1
0 100 100 100 re f
EMC
EMC
...
<< /L1 1 0 R % Resource names
/L1a 2 0 R
/L1b 3 0 R
>>
... %Optional content groups
1 0 obj <</Type /OCG /Name (Layer 1)>> endobj
2 0 obj <</Type /OCG /Name (Sublayer A)>> endobj
3 0 obj <</Type /OCG /Name (Sublayer B)>> endobj
...
4 0 obj % Configuration dictionary
<< /Order [1 0 R [2 0 R 3 0 R]] >>
A PDF viewer should display the OCGs as follows:
Layer 1
Sublayer A
Sublayer B
The AS entry is an auto state array consisting of one or more usage application
dictionaries that specify how viewer applications should automatically set the
state of optional content groups based on external factors, as discussed in the fol-
lowing section.
GraphicsCHAPTER 4
350
Usage and Usage Application Dictionaries
Optional content groups are typically constructed to control the visibility of
graphic objects that are related in some way. Objects can be related in several
ways; for example, a group may contain content in a particular language or con-
tent suitable for viewing at a particular magnification.
An optional content group’s usage dictionary (the value of the
Usage entry in an
optional content group dictionary; see Table 4.48) contains information describ-
ing the nature of the content controlled by the group. This dictionary can contain
any combination of the entries shown in Table 4.52.
TABLE 4.52 Entries in an optional content usage dictionary
KEY TYPE VALUE
CreatorInfo
dictionary (Optional) A dictionary used by the creating application to store application-spe-
cific data associated with this optional content group. It contains two required en-
tries:
• Creator: A text string specifying the application that created the group.
• Subtype: A name defining the type of content controlled by the group. Suggest-
ed values include but are not limited to
Artwork, for graphic-design or publish-
ing applications, and
Technical, for technical designs such as building plans or
schematics.
Additional entries may be included to present information relevant to the creat-
ing application or related applications.
Note: Groups whose
Intent entry contains Design typically include a CreatorInfo en-
try.
Language
dictionary (Optional) A dictionary specifying the language of the content controlled by this
optional content group. It has two entries:
• Lang (required): A language string (see Section 10.8.1, “Natural Language Spec-
ification”) that specifies a language and possibly a locale (for example,
es-MX
represents Mexican Spanish).
• Preferred (optional): A name whose values may be ON or OFF. Default value:
OFF. It is used by viewer applications when there is a partial match but no exact
match between the system language and the language strings in all usage dic-
tionaries. See “Usage and Usage Application Dictionaries” on page 350 for
more information.
Optional ContentSECTION 4.10
351
Export
dictionary (Optional) A dictionary containing one entry, ExportState, a name whose value
may be
ON or OFF. This value indicates the recommended state for content in this
group when the document (or part of it) is saved by a viewer application to a for-
mat that does not support optional content (for example, an earlier version of
PDF or a raster image format).
Zoom
dictionary (Optional) A dictionary specifying a range of magnifications at which the content
in this optional content group is best viewed. It may contain one or both of the
following entries:
• min: The minimum recommended magnification factor at which the group
should be
ON. Default value: 0.
• max: The magnification factor below which the group should be ON. Default
value: infinity.
Print
dictionary (Optional) A dictionary specifying that the content in this group is intended for
use in printing. It contains the following optional entries:
• Subtype: A name object specifying the kind of content controlled by the group;
for example,
Trapping, PrintersMarks and Watermark.
• PrintState: A name that may be ON or OFF, indicating that the group should be
set to that state when the document is printed from a viewer application.
View
dictionary (Optional) A dictionary that has a single entry, ViewState, a name that may have a
value of
ON or OFF, indicating that the group should be set to that state when the
document is opened in a viewer application.
User
dictionary (Optional) A dictionary specifying one or more users for whom this optional con-
tent group is primarily intended. Each dictionary has two required entries:
• Type: A name object that can be Ind (individual), Ttl (title), or Org (organiza-
tion).
• Name: A text string or array of text strings representing the name(s) of the indi-
vidual, position or organization.
PageElement
dictionary (Optional) A dictionary declaring that the group contains a pagination artifact. It
contains one entry,
Subtype, whose value is a name that can be HF (header/foot-
er),
FG (foreground image or graphic), BG (background image or graphic), or L
(logo).
KEY TYPE VALUE
GraphicsCHAPTER 4
352
While the data in the usage dictionary can be viewed as information for a docu-
ment user to examine, it can also be used by viewer applications to automatically
manipulate the state of optional content groups based on external factors such as
current system language settings or zoom level. Document authors can use usage
application dictionaries to specify which entries in the usage dictionary should be
consulted to automatically set the state of optional content groups based on such
factors. Usage application dictionaries are listed in the
AS entry in an optional
content configuration dictionary (see Table 4.51). If no
AS entry is present, states
are not automatically adjusted based on usage information.
A usage application dictionary specifies the rules for which usage entries should
be used by viewer applications to automatically manipulate the state of optional
content groups, which groups should be affected, and under which circumstanc-
es. Table 4.53 shows the entries in a usage application dictionary.
Note: Usage application dictionaries are only intended for use by interactive viewer
applications, not for applications that use PDF as final form output (see “Determin-
ing the State of Optional Content Groups” on page 355 for more information).
TABLE 4.53 Entries in a usage application dictionary
The Event entry specifies whether the usage settings should be applied during
viewing, printing, or exporting the document. The
OCGs entry specifies the set of
optional content groups to which usage settings should be applied. For each of
the groups in
OCGs, the entries in its usage dictionary (see Table 4.52) specified
by
Category are examined to yield a recommended state for the group. If all the
KEY TYPE VALUE
Event
name (Required) A name defining the situation in which this usage application dictio-
nary should be used. May be
View, Print, or Export.
OCGs
array (Optional) An array listing the optional content groups that should have their
states automatically managed based on information in their usage dictionary
(see “Usage and Usage Application Dictionaries” on page 350). Default value: an
empty array, indicating that no groups are affected.
Category
array (Required) An array of names, each of which corresponds to a usage dictionary
entry (see Table 4.52). When managing the states of the optional content groups
in the
OCGs array, each of the corresponding categories in the group’s usage dic-
tionary should be considered.
Optional ContentSECTION 4.10
353
entries yield a recommended state of ON, the group’s state is set to ON; otherwise,
its state is set to
OFF.
The entries in the usage dictionary are used as follows:
• View: The recommended state is the value of the ViewState entry. This entry al-
lows a document to contain content that is relevant only when the document is
viewed interactively, such as instructions for how to interact with the docu-
ment.
• Print: The recommended state is the value of the PrintState entry. If PrintState
is not present, the state of the optional content group is left unchanged.
• Export: The recommended state is the value of the ExportState entry.
• Zoom: If the current magnification level of the document is greater than or
equal to
min and less than max, an ON state is recommended; otherwise, OFF is
recommended.
• User: The Name entry specifies a name or names to match with the user’s iden-
tification. The
Type entry determines how the Name entry is interpreted
(name, title, or organization). If there is an exact match, an
ON state is recom-
mended; otherwise
OFF is recommended.
• Language: This category allows the selection of content based on the language
and locale of the application. If an exact match to the language and locale is
found among the
Lang entries of the optional content groups in the usage ap-
plication dictionary’s
OCGs list, all groups that have exact matches receive an
ON recommendation. If no exact match is found, but a partial match is found
(that is, the language matches but not the locale), all partially matching groups
that have
Preferred entries with a value of ON receive an ON recommendation.
All other groups receive an
OFF recommendation.
Example 4.39 shows the use of an auto state array with usage application dictio-
naries. The
AS entry in the default configuration dictionary is an array of three
usage application dictionaries, one for each of the
Event values View, Print, and
Export.
Note: While this case is typical, there is no restriction on multiple entries with the
same value of
Event, which allows documents with incompatible usage application
dictionaries to be combined into larger documents and have their behavior pre-
served. If a given optional content group appears in more than one
OCGs array, its
GraphicsCHAPTER 4
354
state is ON only if all categories in all the usage application dictionaries it appears in
recommend a state of
ON.
Example 4.39
/OCProperties % OCProperties dictionary in document catalog
<< /OCGs [1 0 R 2 0 R 3 0 R 4 0 R]
/D << /BaseState /OFF % The default configuration
/ON [1 0 R]
/AS [ % Auto state array of usage application dictionaries
<< /Event /View /Category [/Zoom] /OCGs [1 0 R 2 0 R 3 0 R 4 0 R] >>
<< /Event /Print /Category [/Print] /OCGs [4 0 R] >>
<< /Event /Export /Category [/Export] /OCGs [3 0 R 4 0 R] >>
]
>>
>>
...
1 0 obj
<< /Type /OCG
/Name (20000 foot view)
/Usage << /Zoom << /max 1.0 >> >>
>>
endobj
2 0 obj
<< /Type /OCG
/Name (10000 foot view)
/Usage << /Zoom << /min 1.0 /max 2.0 >> >>
>>
endobj
3 0 obj
<< /Type /OCG
/Name (1000 foot view)
/Usage << /Zoom << /min 2.0 /max 20.0 >>
/Export << /ExportState /OFF >> >>
>>
endobj
4 0 obj
<< /Type /OCG
/Name (Copyright notice)
/Usage << /Print << /PrintState /ON >>
/Export << /ExportState /ON>> >>
>>
endobj
Optional ContentSECTION 4.10
355
In the example, the usage application dictionary with event type View specifies
that all optional content groups are to have their states managed based on zoom
level when viewing. Three groups (objects 1, 2, and 3) contain
Zoom usage infor-
mation. Object 4 has none; therefore, it is not affected by zoom level changes. Ob-
ject 3 receives an
OFF recommendation when exporting. When printing or
exporting, object 4 receives an
ON recommendation.
Determining the State of Optional Content Groups
This section summarizes the rules by which applications make use of the configu-
ration and usage application dictionaries to set the state of optional content
groups. For purposes of this discussion, it is useful to distinguish the following
types of applications:
• Viewer applications, such as Acrobat, which allow users to interact with the
document in various ways.
• Design applications, which offer layering features for collecting groups of
graphics together and selectively hiding or viewing them.
Note: The following rules are not meant to apply to design applications; they may
manage their states in an entirely different manner if they choose.
• Aggregating applications, which import PDF files as graphics.
• Printing applications, which print PDF files.
When a document is first opened, its optional content groups are assigned a state
based on the
D (default) configuration dictionary in the OCProperties dictionary:
1. The value of
BaseState is applied to all the groups.
2. The groups listed in either the
ON or OFF array (depending on which one is
opposite to
BaseState) have their states adjusted.
This state is the recommended state for printing and aggregating applications,
which should not apply the changes based on usage application dictionaries de-
scribed below. However, for more advanced functionality, they may provide user
control for manipulating the individual states of optional content groups.
Note: Viewer applications should also provide users with an option to view docu-
ments in this state (that is, to disable the automatic adjustments discussed below).
GraphicsCHAPTER 4
356
This option permits an accurate preview of the content as it will appear when placed
into an aggregating application or sent to a stand-alone printing system.
The remaining discussion in this section applies only to viewer applications. Such
applications should examine the
AS array for usage application dictionaries that
have an
Event of type View. For each one found, the groups listed in its OCGs ar-
ray should be adjusted as described in “Usage and Usage Application Dictionar-
ies” on page 350.
Subsequently, the document is ready for interactive viewing by a user. Whenever
there is a change to a factor that the usage application dictionaries with event type
View depend on (such as zoom level), the corresponding dictionaries should be
reapplied.
The user may manipulate optional content group states manually or by triggering
SetOCGState actions (see “Set-OCG-State Actions” on page 629) by, for example,
clicking links or bookmarks. Manual changes override the states that were set au-
tomatically. The states of these groups remain overridden and are not readjusted
based on usage application dictionaries with event type
View as long as the docu-
ment is open (or until the user reverts the document to its original state).
When a document is printed by a viewer application, usage application dictionar-
ies with an event type
Print are applied over the current states of optional content
groups. These changes persist only for the duration of the print operation; then
all groups revert to their prior states.
Similarly, when a document is exported to an earlier version of PDF or other for-
mat that does not support optional content, usage application dictionaries with
an event type
Export are applied over the current states of optional content
groups. Changes persist only for the duration of the export operation; then all
groups revert to their prior states.
Note: Although the event types
Print and Export have identically named counter-
parts that are usage categories, the corresponding usage application dictionaries are
permitted to specify that other categories may be applied.
357
CHAPTER 5
5Text
This chapter describes the special facilities in PDF for dealing with text— specifi-
cally, for representing characters with glyphs from fonts. A glyph is a graphical
shape and is subject to all graphical manipulations, such as coordinate transfor-
mation. Because of the importance of text in most page descriptions, PDF pro-
vides higher-level facilities that permit an application to describe, select, and
render glyphs conveniently and efficiently.
The first section is a general description of how glyphs from fonts are painted on
the page. Subsequent sections cover the following topics in detail:
• Text state. A subset of the graphics state parameters pertain to text, including
parameters that select the font, scale the glyphs to an appropriate size, and
accomplish other graphical effects.
• Text objects and operators. The text operators specify the glyphs to be painted,
represented by string objects whose values are interpreted as sequences of char-
acter codes. A text object encloses a sequence of text operators and associated
parameters.
• Font data structures. Font dictionaries and associated data structures provide
information that a consumer application needs to interpret the text and posi-
tion the glyphs properly. The definitions of the glyphs themselves are contained
in font programs, which may be embedded in the PDF file, built into the appli-
cation, or obtained from an external font file.
TextCHAPTER 5
358
5.1 Organization and Use of Fonts
A character is an abstract symbol, whereas a glyph is a specific graphical render-
ing of a character. For example, the glyphs
A, A, and A are renderings of the ab-
stract “A” character. Historically these two terms have often been used
interchangeably in computer typography (as evidenced by the names chosen for
some PDF dictionary keys and PostScript operators), but advances in this area
have made the distinction more meaningful. Consequently, this book distin-
guishes between characters and glyphs, though with some residual names that are
inconsistent.
Glyphs are organized into fonts. A font defines glyphs for a particular character
set; for example, the Helvetica and Times fonts define glyphs for a set of standard
Latin characters. A font for use with a PDF consumer application is prepared in
the form of a program. Such a font program is written in a special-purpose lan-
guage, such as the Type 1 or TrueType font format, that is understood by a special-
ized font interpreter.
In PDF, the term font refers to a font dictionary, a PDF object that identifies the
font program and contains additional information about it. There are several dif-
ferent font types, identified by the
Subtype entry of the font dictionary.
For most font types, the font program is defined in a separate font file, which may
be either embedded in a PDF stream object or obtained from an external source.
The font program contains glyph descriptions that generate glyphs.
A content stream paints glyphs on the page by specifying a font dictionary and a
string object that is interpreted as a sequence of one or more character codes
identifying glyphs in the font. This operation is called showing the text string; the
text strings drawn in this way are called show strings. The glyph description con-
sists of a sequence of graphics operators that produce the specific shape for that
character in this font. To render a glyph, the application executes the glyph de-
scription.
Programmers who have experience with scan conversion of general shapes may
be concerned about the amount of computation that this description seems to
imply. However, this is only the abstract behavior of glyph descriptions and font
programs, not how they are implemented. In fact, an efficient implementation
can be achieved through careful caching and reuse of previously rendered glyphs.
Organization and Use of FontsSECTION 5.1
359
5.1.1 Basics of Showing Text
Example 5.1 illustrates the most straightforward use of a font. The text ABC is
placed 10 inches from the bottom of the page and 4 inches from the left edge, us-
ing 12-point Helvetica.
Example 5.1
BT
/F13 12 Tf
288 720 Td
(ABC) Tj
ET
The five lines of this example perform the following steps:
1. Begin a text object.
2. Set the font and font size to use, installing them as parameters in the text state.
(The font resource identified by the name
F13 specifies the font externally
known as
Helvetica.)
3. Specify a starting position on the page, setting parameters in the text object.
4. Paint the glyphs for a string of characters at that position.
5. End the text object.
The following paragraphs explain these operations in more detail.
To paint glyphs, a content stream must first identify the font to be used. The
Tf
operator specifies the name of a font resource—that is, an entry in the Font
subdictionary of the current resource dictionary. The value of that entry is a font
dictionary. The font dictionary identifies the font’s externally known name, such
as
Helvetica, and supplies some additional information that the application needs
to paint glyphs from that font. The font dictionary optionally provides the defini-
tion of the font program itself.
Note: The font resource name presented to the
Tf operator is arbitrary, as are the
names for all kinds of resources. It bears no relationship to an actual font name,
such as
Helvetica.
Example 5.2 illustrates an excerpt from the current page’s resource dictionary,
which defines the font dictionary that is referenced as
F13 in Example 5.1.
TextCHAPTER 5
360
Example 5.2
/Resources
<< /Font << /F13 23 0 R >>
>>
23 0 obj
<< /Type /Font
/Subtype /Type1
/BaseFont /Helvetica
>>
endobj
A font defines the glyphs for one standard size. This standard is arranged so that
the nominal height of tightly spaced lines of text is 1 unit. In the default user
coordinate system, this means the standard glyph size is 1 unit in user space, or
1⁄72 inch. (In PDF 1.6, the size of this unit may be specified as greater than 1⁄72
inch by means of the
UserUnit entry of the page dictionary; see Table 3.27.) The
standard-size font must then be scaled to be usable. The scale factor is specified
as the second operand of the
Tf operator, thereby setting the text font size param-
eter in the graphics state. Example 5.1 establishes the Helvetica font with a 12-
unit size in the graphics state.
Once the font has been selected and scaled, it can be used to paint glyphs. The
Td
operator adjusts the current text position (actually, the translation components of
the text matrix, as described in Section 5.3.1, “Text-Positioning Operators”).
When executed for the first time after
BT, Td establishes the text position in the
current user coordinate system. This determines the position on the page at
which to begin painting glyphs.
The
Tj operator takes a string operand and paints the corresponding glyphs, using
the current font and other text-related parameters in the graphics state. In Exam-
ple 5.1, the
Tj operator treats each element of the string (an integer in the range 0
to 255) as a character code. Each code selects a glyph description in the font, and
the glyph description is executed to paint that glyph on the page. This is the be-
havior of
Tj for simple fonts, such as ordinary Latin text fonts. Interpretation of
the string as a sequence of character codes is more complex for composite fonts,
described in Section 5.6, “Composite Fonts.”
Note: What these steps produce on the page is not a 12-point glyph, but rather a
12-unit glyph, where the unit size is that of the text space at the time the glyphs are
rendered on the page. The actual size of the glyph is determined by the text matrix
Organization and Use of FontsSECTION 5.1
361
(T
m
) in the text object, several text state parameters, and the current transforma-
tion matrix (CTM) in the graphics state; see Section 5.3.3, “Text Space Details.” If
the text space is later scaled to make the unit size 1 centimeter, painting glyphs from
the same 12-unit font generates results that are 12 centimeters high.
5.1.2 Achieving Special Graphical Effects
Normal uses of Tj and other glyph-painting operators cause black-filled glyphs to
be painted. Other effects can be obtained by combining font operators with gen-
eral graphics operators.
The color used for painting glyphs is the current color in the graphics state: either
the nonstroking color or the stroking color (or both), depending on the text ren-
dering mode (see Section 5.2.5, “Text Rendering Mode”). The default color is
black, but other colors can be obtained by executing an appropriate color-setting
operator or operators (see Section 4.5.7, “Color Operators”) before painting the
glyphs. Example 5.3 uses text rendering mode 0 and the
g operator to fill glyphs
in 50 percent gray, as shown in Figure 5.1.
Example 5.3
BT
/F13 48 Tf
20 40 Td
0Tr
0.5 g
(ABC) Tj
ET
FIGURE 5.1
Glyphs painted in 50% gray
ABC
TextCHAPTER 5
362
Other graphical effects can be achieved by treating the glyph outline as a path in-
stead of filling it. The text rendering mode parameter in the graphics state speci-
fies whether glyph outlines are to be filled, stroked, used as a clipping boundary,
or some combination of these effects. (This parameter does not apply to Type 3
fonts.)
Example 5.4 treats glyph outlines as a path to be stroked. The
Tr operator sets the
text rendering mode to 1 (stroke). The
w operator sets the line width to 2 units in
user space. Given those graphics state parameters, the
Tj operator strokes the
glyph outlines with a line 2 points thick (see Figure 5.2).
Example 5.4
BT
/F13 48 Tf
20 38 Td
1Tr
2w
(ABC) Tj
ET
FIGURE 5.2
Glyph outlines treated as a stroked path
Example 5.5 treats the glyphs’ outlines as a clipping boundary. The Tr operator
sets the text rendering mode to 7 (clip), causing the subsequent
Tj operator to
impose the glyph outlines as the current clipping path. All subsequent painting
operations mark the page only within this path, as illustrated in Figure 5.3. This
state persists until some earlier clipping path is reinstated by the
Q operator.
ABC
ABC
Organization and Use of FontsSECTION 5.1
363
Example 5.5
BT
/F13 48 Tf
20 38 Td
7Tr
(ABC) Tj
ET
…Graphics operators to draw a starburst …
FIGURE 5.3
Graphics clipped by a glyph path
5.1.3 Glyph Positioning and Metrics
A glyph’s width—formally, its horizontal displacement—is the amount of space it
occupies along the baseline of a line of text that is written horizontally. In other
words, it is the distance the current text position moves (by translating text space)
when the glyph is painted. Note that the width is distinct from the dimensions of
the glyph outline.
In some fonts, the width is constant; it does not vary from glyph to glyph. Such
fonts are called fixed-pitch or monospaced. They are used mainly for typewriter-
style printing. However, most fonts used for high-quality typography associate a
different width with each glyph. Such fonts are called proportional or variable-
pitch fonts. In either case, the
Tj operator positions the consecutive glyphs of a
string according to their widths.
The width information for each glyph is stored both in the font dictionary and in
the font program itself. (The two sets of widths must be identical; storing this in-
formation in the font dictionary, although redundant, enables a consumer appli-
ABC
TextCHAPTER 5
364
cation to determine glyph positioning without having to look inside the font
program.) The operators for showing text are designed on the assumption that
glyphs are ordinarily positioned according to their standard widths. However,
means are provided to vary the positioning in certain limited ways. For example,
the
TJ operator enables the text position to be adjusted between any consecutive
pair of glyphs corresponding to characters in a text string. There are graphics
state parameters to adjust character and word spacing systematically.
In addition to width, a glyph has several other metrics that influence glyph posi-
tioning and painting. For most font types, this information is largely internal to
the font program and is not specified explicitly in the PDF font dictionary. How-
ever, in a Type 3 font, all metrics are specified explicitly (see Section 5.5.4, “Type 3
Fonts”).
The glyph coordinate system is the space in which an individual character’s glyph
is defined. All path coordinates and metrics are interpreted in glyph space. For all
font types except Type 3, the units of glyph space are one-thousandth of a unit of
text space; for a Type 3 font, the transformation from glyph space to text space is
defined by a font matrix specified in an explicit
FontMatrix entry in the font.
Figure 5.4 shows a typical glyph outline and its metrics.
FIGURE 5.4 Glyph metrics
The glyph origin is the point (0, 0) in the glyph coordinate system. Tj and other
text-showing operators position the origin of the first glyph to be painted at the
origin of text space. For example, the following code adjusts the origin of text
Glyph
bounding
box
Next
glyph
origin
Glyph
origin
Glyph width
Organization and Use of FontsSECTION 5.1
365
space to (40, 50) in the user coordinate system and then places the origin of the A
glyph at that point:
BT
40 50 Td
(ABC) Tj
ET
The glyph displacement is the distance from the glyph’s origin to the point at
which the origin of the next glyph should normally be placed when painting the
consecutive glyphs of a line of text. This distance is a vector (called the displace-
ment vector) in the glyph coordinate system; it has horizontal and vertical com-
ponents. (A displacement that is horizontal is usually called a width.) Most
Western writing systems, including those based on the Latin alphabet, have a
positive horizontal displacement and a zero vertical displacement. Some Asian
writing systems have a nonzero vertical displacement. In all cases, the text-show-
ing operators transform the displacement vector into text space and then trans-
late text space by that amount.
The glyph bounding box is the smallest rectangle (oriented with the axes of the
glyph coordinate system) that just encloses the entire glyph shape. The bounding
box is expressed in terms of its left, bottom, right, and top coordinates relative to
the glyph origin in the glyph coordinate system.
In some writing systems, text is frequently aligned in two different directions. For
example, it is common to write Japanese and Chinese glyphs either horizontally
or vertically. To handle this, a font can optionally contain a second set of metrics
for each glyph. Which set of metrics to use is selected according to a writing
mode, where 0 specifies horizontal writing and 1 specifies vertical writing. This
feature is available only for composite fonts, discussed in Section 5.6, “Composite
Fonts.”
When a glyph has two sets of metrics, each set specifies a glyph origin and a dis-
placement vector for that writing mode. In vertical writing, the glyph position is
described by a position vector from the origin used for horizontal writing
(origin 0) to the origin used for vertical writing (origin 1). Figure 5.5 illustrates
the metrics for the two writing modes:
• The left diagram illustrates the glyph metrics associated with writing mode 0,
horizontal writing. The coordinates ll and ur specify the bounding box of the
glyph relative to origin 0. w0 is the displacement vector that specifies how the
TextCHAPTER 5
366
text position is changed after the glyph is painted in writing mode 0; its vertical
component is always 0.
• The center diagram illustrates writing mode 1, vertical writing. w1 is the dis-
placement vector for writing mode 1; its horizontal component is always 0.
• In the right diagram, v is a position vector defining the position of origin 1 rel-
ative to origin 0.
FIGURE 5.5 Metrics for horizontal and vertical writing modes
Glyph metric information is also available separately in the form of Adobe font
metrics (AFM) and Adobe composite font metrics (ACFM) files. These files are
for use by application programs that generate PDF page descriptions and must
make formatting decisions based on the widths and other metrics of glyphs. Also
available in the AFM and ACFM files is kerning information, which allows an
application generating a PDF file to determine spacing adjustments between
glyphs depending on context. Specifications for the AFM and ACFM file formats
are available in Adobe Technical Note #5004, Adobe Font Metrics File Format
Specification; the files can be obtained from the Adobe Solutions Network Web
site (see the Bibliography).
5.2 Text State Parameters and Operators
The text state comprises those graphics state parameters that only affect text.
There are nine parameters in the text state (see Table 5.1).
New text
position
ur
w0
Origin
0
ll
New text position
Writing mode 0
(horizontal)
Writing mode 1
(vertical)
Mode 1 relative to mode 0
w1
Origin
0
v
Origin 1 Origin 1
Text State Parameters and OperatorsSECTION 5.2
367
TABLE 5.1 Text state parameters
Except for the self-explanatory T
f
and T
fs
, these parameters are discussed further
in the following sections. (As described in Section 5.3, “Text Objects,” three addi-
tional text-related parameters are defined only within a text object: T
m
, the text
matrix; T
lm
, the text line matrix; and T
rm
, the text rendering matrix.) The values
of the text state parameters are consulted when text is positioned and shown
(using the operators described in Sections 5.3.1, “Text-Positioning Operators,”
and 5.3.2, “Text-Showing Operators”). In particular, the spacing and scaling
parameters participate in a computation described in Section 5.3.3, “Text Space
Details.” The text state parameters can be set using the operators listed in Table
5.2.
Note: The text knockout parameter, T
k
, is set through the TK entry in a graphics
state parameter dictionary by using the
gs operator (see Section 4.3.4, “Graphics
State Parameter Dictionaries”). There is no specific operator for setting this parame-
ter.
The text state operators can appear outside text objects, and the values they set
are retained across text objects in a single content stream. Like other graphics
state parameters, these parameters are initialized to their default values at the
beginning of each page.
PARAMETER DESCRIPTION
T
c
Character spacing
T
w
Word spacing
T
h
Horizontal scaling
T
l
Leading
T
f
Text font
T
fs
Text font size
T
mode
Text rendering mode
T
rise
Text rise
T
k
Text knockout
TextCHAPTER 5
368
TABLE 5.2 Text state operators
Note that some of these parameters are expressed in unscaled text space units.
This means that they are specified in a coordinate system that is defined by the
text matrix, T
m
but is not scaled by the font size parameter, T
fs
.
5.2.1 Character Spacing
The character-spacing parameter, T
c
, is a number specified in unscaled text space
units (although it is subject to scaling by the T
h
parameter if the writing mode is
horizontal). When the glyph for each character in the string is rendered, T
c
is
added to the horizontal or vertical component of the glyph’s displacement,
depending on the writing mode. (See Section 5.1.3, “Glyph Positioning and
Metrics,” for a discussion of glyph displacements.) In the default coordinate sys-
tem, horizontal coordinates increase from left to right and vertical coordinates
from bottom to top. Therefore, for horizontal writing, a positive value of T
c
has
OPERANDS OPERATOR DESCRIPTION
charSpace
Tc
Set the character spacing, T
c
, to charSpace, which is a number expressed in un-
scaled text space units. Character spacing is used by the
Tj, TJ, and ' operators.
Initial value: 0.
wordSpace
Tw
Set the word spacing, T
w
, to wordSpace, which is a number expressed in unscaled
text space units. Word spacing is used by the
Tj, TJ, and ' operators. Initial
value: 0.
scale
Tz
Set the horizontal scaling, T
h
, to (scale ÷ 100). scale is a number specifying the
percentage of the normal width. Initial value: 100 (normal width).
leading
TL
Set the text leading, T
l
, to leading, which is a number expressed in unscaled text
space units. Text leading is used only by the
T*, ', and " operators. Initial value: 0.
font size Tf Set the text font, T
f
, to font and the text font size, T
fs
, to size. font is the name of a
font resource in the
Font subdictionary of the current resource dictionary; size is
a number representing a scale factor. There is no initial value for either
font or
size; they must be specified explicitly by using Tf before any text is shown.
render
Tr
Set the text rendering mode, T
mode
, to render, which is an integer. Initial value: 0.
rise
Ts
Set the text rise, T
rise
, to rise, which is a number expressed in unscaled text space
units. Initial value: 0.
Text State Parameters and OperatorsSECTION 5.2
369
the effect of expanding the distance between glyphs (see Figure 5.6), whereas for
vertical writing, a negative value of T
c
has this effect.
FIGURE 5.6 Character spacing in horizontal writing
5.2.2 Word Spacing
Word spacing works the same way as character spacing but applies only to the
space character, code 32. The word-spacing parameter, T
w
, is added to the
glyph’s horizontal or vertical displacement (depending on the writing mode). For
horizontal writing, a positive value for T
w
has the effect of increasing the spacing
between words. For vertical writing, a positive value for T
w
decreases the spacing
between words (and a negative value increases it), since vertical coordinates in-
crease from bottom to top. Figure 5.7 illustrates the effect of word spacing in
horizontal writing.
FIGURE 5.7 Word spacing in horizontal writing
Note: Word spacing is applied to every occurrence of the single-byte character code
32 in a string when using a simple font or a composite font that defines code 32 as a
Character
Character
T
c
= 0 (default)
T
c
= 0.25
T
w
= 0 (default)
T
w
= 2.5
Word Space
Word Space
TextCHAPTER 5
370
single-byte code. It does not apply to occurrences of the byte value 32 in multiple-
byte codes.
5.2.3 Horizontal Scaling
The horizontal scaling parameter, T
h
, adjusts the width of glyphs by stretching or
compressing them in the horizontal direction. Its value is specified as a percent-
age of the normal width of the glyphs, with 100 being the normal width. The scal-
ing always applies to the horizontal coordinate in text space, independently of the
writing mode. It affects both the glyph’s shape and its horizontal displacement
(that is, its displacement vector). If the writing mode is horizontal, it also affects
the spacing parameters T
c
and T
w
, as well as any positioning adjustments per-
formed by the
TJ operator. Figure 5.8 shows the effect of horizontal scaling.
FIGURE 5.8 Horizontal scaling
5.2.4 Leading
The leading parameter, T
l
, is measured in unscaled text space units. It specifies
the vertical distance between the baselines of adjacent lines of text, as shown in
Figure 5.9.
FIGURE 5.9 Leading
Word
WordWord
T
h
= 100 (default)
T
h
= 50
This is 12-point text with
14.5-point leading
Leading
Text State Parameters and OperatorsSECTION 5.2
371
The leading parameter is used by the TD, T*, ', and " operators; see Table 5.5 on
page 376 for a precise description of its effects. This parameter always applies to
the vertical coordinate in text space, independently of the writing mode.
5.2.5 Text Rendering Mode
The text rendering mode, T
mode
, determines whether showing text causes glyph
outlines to be stroked, filled, used as a clipping boundary, or some combination
of the three. Stroking, filling, and clipping have the same effects for a text object
as they do for a path object (see Sections 4.4.2, “Path-Painting Operators,” and
4.4.3, “Clipping Path Operators”), although they are specified in an entirely dif-
ferent way. The graphics state parameters affecting those operations, such as line
width, are interpreted in user space rather than in text space.
Note: The text rendering mode has no effect on text displayed in a Type 3 font (see
Section 5.5.4, “Type 3 Fonts”).
The text rendering modes are shown in Table 5.3. In the examples, a stroke color
of black and a fill color of light gray are used. For the clipping modes (4 to 7), a
series of lines has been drawn through the glyphs to show where the clipping
occurs.
If the text rendering mode calls for filling, the current nonstroking color in the
graphics state is used; if it calls for stroking, the current stroking color is used. In
modes that perform both filling and stroking, the effect is as if each glyph outline
were filled and then stroked in separate operations. If any of the glyphs overlap,
the result is equivalent to filling and stroking them one at a time, producing the
appearance of stacked opaque glyphs, rather than first filling and then stroking
them all at once (see implementation note 56 in Appendix H). In the transparent
imaging model, these combined filling and stroking modes are subject to further
considerations; see “Special Path-Painting Considerations” on page 538.
The behavior of the clipping modes requires further explanation. Glyph outlines
begin accumulating if a
BT operator is executed while the text rendering mode is
set to a clipping mode or if it is set to a clipping mode within a text object. Glyphs
accumulate until the text object is ended by an
ET operator; the text rendering
mode must not be changed back to a nonclipping mode before that point.
TextCHAPTER 5
372
TABLE 5.3 Text rendering modes
At the end of the text object, the accumulated glyph outlines, if any, are combined
into a single path, treating the individual outlines as subpaths of that path and ap-
plying the nonzero winding number rule (see “Nonzero Winding Number Rule”
on page 202). The current clipping path in the graphics state is set to the intersec-
tion of this path with the previous clipping path. As is the case for path objects,
this clipping occurs after all filling and stroking operations for the text object
have occurred. It remains in effect until some previous clipping path is restored
by an invocation of the
Q operator.
Note: If no glyphs are shown or if the only glyphs shown have no outlines (for exam-
ple, if they are space characters), no clipping occurs.
MODE EXAMPLE DESCRIPTION
0 Fill text.
1 Stroke text.
2 Fill, then stroke text.
3 Neither fill nor stroke text (invisible).
4 Fill text and add to path for clipping (see above).
5 Stroke text and add to path for clipping.
6 Fill, then stroke text and add to path for clipping.
7 Add text to path for clipping.
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
Text State Parameters and OperatorsSECTION 5.2
373
5.2.6 Text Rise
Text rise, T
rise
, specifies the distance, in unscaled text space units, to move the
baseline up or down from its default location. Positive values of text rise move the
baseline up. Adjustments to the baseline are useful for drawing superscripts or
subscripts. The default location of the baseline can be restored by setting the text
rise to 0. Figure 5.10 illustrates the effect of the text rise. Text rise always applies
to the vertical coordinate in text space, regardless of the writing mode.
FIGURE 5.10 Text rise
5.2.7 Text Knockout
The text knockout parameter, T
k
(PDF 1.4), is a boolean flag that determines
what text elements are considered elementary objects for purposes of color com-
positing in the transparent imaging model. Unlike other text state parameters,
there is no specific operator for setting this parameter; it can be set only through
the
TK entry in a graphics state parameter dictionary by using the gs operator (see
Section 4.3.4, “Graphics State Parameter Dictionaries”).
The text knockout parameter applies only to entire text objects; it may not be set
between the
BT and ET operators delimiting a text object. Its initial value is true. If
its value is
false, each glyph in a text object is treated as a separate elementary ob-
ject; when glyphs overlap, they composite with one another.
(This text is ) Tj
5 Ts
(superscripted) Tj
(This ) Tj
–5 Ts
(text ) Tj
5 Ts
(moves ) Tj
0 Ts
(around) Tj
(This text is ) Tj
–5 Ts
(subscripted) Tj
This text is
superscripted
This
text
moves
around
This text is
subscripted
TextCHAPTER 5
374
If the parameter is true, all glyphs in the text object are treated together as a single
elementary object; when glyphs overlap, later glyphs overwrite (“knock out”) ear-
lier ones in the area of overlap. This behavior is equivalent to treating the entire
text object as if it were a non-isolated knockout transparency group; see Section
7.3.5, “Knockout Groups.” Transparency parameters are applied to the glyphs in-
dividually rather than to the implicit transparency group as a whole:
• Graphics state parameters, including transparency parameters, are inherited
from the context in which the text object appears. They are not saved and re-
stored, nor are the transparency parameters reset at the beginning of the trans-
parency group (as they are when a transparency group XObject is explicitly
invoked). Changes made to graphics state parameters within the text object
persist beyond the end of the text object.
• After the implicit transparency group for the text object has been completely
evaluated, the group results are composited with the backdrop, using the
Normal blend mode and alpha and soft mask values of 1.0.
5.3 Text Objects
A PDF text object consists of operators that can show text strings, move the text
position, and set text state and certain other parameters. In addition, three pa-
rameters are defined only within a text object and do not persist from one text
object to the next:
• T
m
, the text matrix
• T
lm
, the text line matrix
• T
rm
, the text rendering matrix, which is actually just an intermediate result that
combines the effects of text state parameters, the text matrix (T
m
), and the cur-
rent transformation matrix
A text object begins with the
BT operator and ends with the ET operator, as shown
below and described in Table 5.4.
BT
…Zero or more text operators or other allowed operators…
ET
Text O b j ectsSECTION 5.3
375
TABLE 5.4 Text object operators
These specific categories of text-related operators can appear in a text object:
• Text state operators, described in Section 5.2, “Text State Parameters and Oper-
ators”
• Text-positioning operators, described in Section 5.3.1, “Text-Positioning Opera-
tors”
• Text-showing operators, described in Section 5.3.2, “Text-Showing Operators”
The latter two sections also provide further details about the text object parame-
ters described above. The other operators that can appear in a text object are
those related to the general graphics state, color, and marked content, as shown in
Figure 4.1 on page 167.
Note: If a content stream does not contain any text, the
Tex t procedure set may be
omitted (see Section 10.1, “Procedure Sets”). In those circumstances, no text opera-
tors (including operators that merely set the text state) may be present in the content
stream, since those operators are defined in the same procedure set.
Note: Although text objects cannot be statically nested, text might be shown using a
Type 3 font whose glyph descriptions include any graphics objects, including another
text object. Likewise, the current color might be a tiling pattern whose pattern cell
includes a text object.
OPERANDS OPERATOR DESCRIPTION
— BT Begin a text object, initializing the text matrix, T
m
, and the text line matrix, T
lm
, to
the identity matrix. Text objects cannot be nested; a second
BT cannot appear before
an
ET.
—
ET End a text object, discarding the text matrix.
TextCHAPTER 5
376
5.3.1 Text-Positioning Operators
Text space is the coordinate system in which text is shown. It is defined by the
text matrix, T
m
, and the text state parameters T
fs
, T
h
, and T
rise
, which together
determine the transformation from text space to user space. Specifically, the ori-
gin of the first glyph shown by a text-showing operator is placed at the origin of
text space. If text space has been translated, scaled, or rotated, then the position,
size, or orientation of the glyph in user space is correspondingly altered.
TABLE 5.5 Text-positioning operators
OPERANDS OPERATOR DESCRIPTION
t
x
t
y
Td Move to the start of the next line, offset from the start of the current line by
(
t
x
, t
y
). t
x
and t
y
are numbers expressed in unscaled text space units. More pre-
cisely, this operator performs the following assignments:
t
x
t
y
TD Move to the start of the next line, offset from the start of the current line by
(
t
x
, t
y
). As a side effect, this operator sets the leading parameter in the text state.
This operator has the same effect as the following code:
t
y
TL
t
x
t
y
Td
abcdef
Tm Set the text matrix, T
m
, and the text line matrix, T
lm
:
The operands are all numbers, and the initial value for T
m
and T
lm
is the identity
matrix,
[100100]. Although the operands specify a matrix, they are passed
to
Tm as six separate numbers, not as an array.
The matrix specified by the operands is not concatenated onto the current text
matrix, but replaces it.
—
T* Move to the start of the next line. This operator has the same effect as the code
0 T
l
Td
where T
l
is the current leading parameter in the text state.
T
m
T
lm
100
010
t
x
t
y
1
T
lm
×==
T
m
T
lm
ab0
cd0
ef1
==
Text O b j ectsSECTION 5.3
377
At the beginning of a text object, T
m
is the identity matrix; therefore, the origin of
text space is initially the same as that of user space. The text-positioning operators,
described in Table 5.5, alter T
m
and thereby control the placement of glyphs that
are subsequently painted. Also, the text-showing operators, described in Table 5.6
in the next section, update T
m
(by altering its e and f translation components) to
take into account the horizontal or vertical displacement of each glyph painted as
well as any character or word-spacing parameters in the text state.
Additionally, a text object keeps track of a text line matrix, T
lm
, which captures
the value of T
m
at the beginning of a line of text. This is convenient for aligning
evenly spaced lines of text. The text-positioning and text-showing operators read
and set T
lm
on specific occasions mentioned in Tables 5.5 and 5.6.
Note: The text-positioning operators can appear only within text objects.
5.3.2 Text-Showing Operators
The text-showing operators (Table 5.6) show text on the page, repositioning text
space as they do so. All of the operators interpret the text string and apply the text
state parameters as described below.
TABLE 5.6 Text-showing operators
OPERANDS OPERATOR DESCRIPTION
string Tj Show a text string.
string
'
Move to the next line and show a text string. This operator has the same effect as
the code
T*
string Tj
a
w
a
c
string " Move to the next line and show a text string, using a
w
as the word spacing and a
c
as the character spacing (setting the corresponding parameters in the text state).
a
w
and a
c
are numbers expressed in unscaled text space units. This operator has
the same effect as the following code:
a
w
Tw
a
c
Tc
string '
TextCHAPTER 5
378
FIGURE 5.11 Operation of the TJ operator in horizontal writing
Note: The text-showing operators can appear only within text objects.
A string operand of a text-showing operator is interpreted as a sequence of char-
acter codes identifying the glyphs to be painted. With most font types, each byte
of the string is treated as a separate character code. The character code is then
looked up in the font’s encoding to select the glyph, as described in Section 5.5.5,
“Character Encoding.”
Beginning with PDF 1.2, a string may be shown in a composite font that uses
multiple-byte codes to select some of its glyphs. In that case, one or more consec-
utive bytes of the string are treated as a single character code. The code lengths
and the mappings from codes to glyphs are defined in a data structure called a
CMap, described in Section 5.6, “Composite Fonts.”
The strings must conform to the syntax for string objects. When a string is writ-
ten by enclosing the data in parentheses, bytes whose values are the same as those
array
TJ
Show one or more text strings, allowing individual glyph positioning (see imple-
mentation note 57 in Appendix H). Each element of
array can be a string or a
number. If the element is a string, this operator shows the string. If it is a num-
ber, the operator adjusts the text position by that amount; that is, it translates the
text matrix, T
m
. The number is expressed in thousandths of a unit of text space
(see Section 5.3.3, “Text Space Details,” and implementation note 58 in Appendix
H). This amount is subtracted from the current horizontal or vertical coordinate,
depending on the writing mode. In the default coordinate system, a positive ad-
justment has the effect of moving the next glyph painted either to the left or
down by the given amount. Figure 5.11 shows an example of the effect of passing
offsets to
TJ.
OPERANDS OPERATOR DESCRIPTION
[ (AWAY again) ] TJ
AWAY again
[ (A) 120 (W) 120 (A) 95 (Y again) ] TJ
AWAY again
Text O b j ectsSECTION 5.3
379
of the ASCII characters left parenthesis (40), right parenthesis (41), and backslash
(92) must be preceded by a backslash character. All other byte values between 0
and 255 may be used in a string object. These rules apply to each individual byte
in a string object, whether the string is interpreted by the text-showing operators
as single-byte or multiple-byte character codes.
Strings presented to the text-showing operators may be of any length—even a
single character code per string—and may be placed on the page in any order.
The grouping of glyphs into strings has no significance for the display of text.
Showing multiple glyphs with one invocation of a text-showing operator such as
Tj produces the same results as showing them with a separate invocation for each
glyph. However, the performance of text searching (and other text extraction op-
erations) is significantly better if the text strings are as long as possible and are
shown in natural reading order.
Note: In some cases, the text that is extracted can vary depending on the grouping of
glyphs into strings. See, for example, “Reverse-Order Show Strings” on page 818.
5.3.3 Text Space Details
As stated in Section 5.3.1, “Text-Positioning Operators,” text is shown in text
space, which is defined by the combination of the text matrix, T
m
, and the text
state parameters T
fs
, T
h
, and T
rise
. This determines how text coordinates are
transformed into user space. Both the glyph’s shape and its displacement (hori-
zontal or vertical) are interpreted in text space.
Note: Glyphs are actually defined in glyph space, whose definition varies according
to the font type as discussed in Section 5.1.3, “Glyph Positioning and Metrics.” Glyph
coordinates are first transformed from glyph space to text space before being subject-
ed to the transformations described below.
TextCHAPTER 5
380
The entire transformation from text space to device space can be represented by a
text rendering matrix, T
rm
:
T
rm
is a temporary matrix; conceptually, it is recomputed before each glyph is
painted during a text-showing operation.
After the glyph is painted, the text matrix is updated according to the glyph dis-
placement and any spacing parameters that apply. First, a combined displacement
is computed, denoted by t
x
in horizontal writing mode or t
y
in vertical writing
mode (the variable corresponding to the other writing mode is set to 0):
where
w0 and w1 are the glyph’s horizontal and vertical displacements
T
j
is a position adjustment specified by a number in a TJ array, if any
T
fs
and T
h
are the current text font size and horizontal scaling parameters in the
graphics state
T
c
and T
w
are the current character- and word-spacing parameters in the
graphics state, if applicable
The text matrix is then updated as follows:
T
rm
T
fs
T
h
× 00
0 T
fs
0
0 T
rise
1
T
m
CTM××=
t
x
w0
T
j
1000
-----------–
T
fs
× T
c
T
w
++
T
h
×=
t
y
w1
T
j
1000
-----------–
T
fs
× T
c
T
w
++=
T
m
100
010
t
x
t
y
1
T
m
×=
Introduction to Font Data StructuresSECTION 5.4
381
5.4 Introduction to Font Data Structures
A font is represented in PDF as a dictionary specifying the type of font, its Post-
Script name, its encoding, and information that can be used to provide a substi-
tute when the font program is not available. Optionally, the font program can be
embedded as a stream object in the PDF file.
The font types are distinguished by the
Subtype entry in the font dictionary.
Table 5.7 lists the font types defined in PDF. Type 0 fonts are called composite
fonts; other types of fonts are called simple fonts. In addition to fonts, PDF sup-
ports two classes of font-related objects, called CIDFonts and CMaps, described in
Section 5.6.1, “CID-Keyed Fonts Overview.” CIDFonts are listed in Table 5.7 be-
cause, like fonts, they are collections of glyphs; however, a CIDFont is never used
directly but only as a component of a Type 0 font.
TABLE 5.7 Font types
For all font types, the term font dictionary refers to a PDF dictionary containing
information about the font; likewise, a CIDFont dictionary contains information
about a CIDFont. Except for Type 3, this dictionary is distinct from the font pro-
TYPE SUBTYPE VALUE DESCRIPTION
Type 0 Type0 (PDF 1.2) A composite font—a font composed of glyphs from a descendant
CIDFont (see Section 5.6, “Composite Fonts”)
Type 1
Type1 A font that defines glyph shapes using Type 1 font technology (see Section
5.5.1, “Type 1 Fonts”).
MMType1 A multiple master font—an extension of the Type 1 font that allows the gen-
eration of a wide variety of typeface styles from a single font (see “Multiple
Master Fonts” on page 386)
Type 3
Type3 A font that defines glyphs with streams of PDF graphics operators (see Sec-
tion 5.5.4, “Type 3 Fonts”)
TrueType
TrueType A font based on the TrueType font format (see Section 5.5.2, “TrueType
Fonts”)
CIDFont
CIDFontType0 (PDF 1.2) A CIDFont whose glyph descriptions are based on Type 1 font
technology (see Section 5.6.3, “CIDFonts”)
CIDFontType2 (PDF 1.2) A CIDFont whose glyph descriptions are based on TrueType font
technology (see Section 5.6.3, “CIDFonts”)
TextCHAPTER 5
382
gram that defines the font’s glyphs. That font program may be embedded in the
PDF file as a stream object or be obtained from some external source.
Note: This terminology differs from that used in the PostScript language. In Post-
Script, a font dictionary is a PostScript data structure that is created as a direct re-
sult of interpreting a font program. In PDF, a font program is always treated as if it
were a separate file, even if its contents are embedded in the PDF file. The font pro-
gram is interpreted by a specialized font interpreter when necessary; its contents
never materialize as PDF objects.
Most font programs (and related programs, such as CIDFonts and CMaps) con-
form to external specifications, such as the Adobe Type 1 Font Format. This book
does not include those specifications. See the Bibliography for more information
about the specifications mentioned in this chapter.
The most predictable and dependable results are produced when all font
programs used to show text are embedded in the PDF file. The following sections
describe precisely how to do so. If a PDF file refers to font programs that are not
embedded, the results depend on the availability of fonts in the consumer appli-
cation’s environment. The following sections specify some conventions for refer-
ring to external font programs. However, some details of font naming, font
substitution, and glyph selection are implementation-dependent and may vary
among different applications and operating system environments.
5.5 Simple Fonts
There are several types of simple fonts, all of which have the following properties:
• Glyphs in the font are selected by single-byte character codes obtained from a
string that is shown by the text-showing operators. Logically, these codes index
into a table of 256 glyphs; the mapping from codes to glyphs is called the font’s
encoding. Each font program has a built-in encoding. Under some circum-
stances, the encoding can be altered by means described in Section 5.5.5,
“Character Encoding.”
• Each glyph has a single set of metrics, including a horizontal displacement or
width, as described in Section 5.1.3, “Glyph Positioning and Metrics;” that is,
simple fonts support only horizontal writing mode.
• Except for Type 0 fonts, Type 3 fonts in non-Tagged PDF documents, and cer-
tain standard Type 1 fonts, every font dictionary contains a subsidiary dictio-
Simple FontsSECTION 5.5
383
nary, the font descriptor, containing font-wide metrics and other attributes of
the font; see Section 5.7, “Font Descriptors.” Among those attributes is an op-
tional font file stream containing the font program.
5.5.1 Type 1 Fonts
A Type 1 font program is a stylized PostScript program that describes glyph
shapes. It uses a compact encoding for the glyph descriptions, and it includes hint
information that enables high-quality rendering even at small sizes and low reso-
lutions. Details on this format are provided in a separate book, Adobe Type 1 Font
Format. An alternative, more compact but functionally equivalent representation
of a Type 1 font program is documented in Adobe Technical Note #5176, The
Compact Font Format Specification.
Note: Although a Type 1 font program uses PostScript language syntax, using it does
not require a full PostScript interpreter; a specialized Type 1 font interpreter suffices.
A Type 1 font dictionary contains the entries listed in Table 5.8. Some entries are
optional for the standard 14 fonts listed under “Standard Type 1 Fonts” on page
385, but are required otherwise.
TABLE 5.8 Entries in a Type 1 font dictionary
KEY TYPE VALUE
Type name (Required) The type of PDF object that this dictionary describes; must be
Font for a font dictionary.
Subtype name (Required) The type of font; must be Type1 for a Type 1 font.
Name name (Required in PDF 1.0; optional otherwise) The name by which this font is ref-
erenced in the
Font subdictionary of the current resource dictionary.
Note: This entry is obsolescent and its use is no longer recommended. (See
implementation note 59 in Appendix H.)
BaseFont name (Required) The PostScript name of the font. For Type 1 fonts, this is usually
the value of the
FontName entry in the font program; for more information,
see Section 5.2 of the PostScript Language Reference, Third Edition. The Post-
Script name of the font can be used to find the font’s definition in the con-
sumer application or its environment. It is also the name that is used when
printing to a PostScript output device.
TextCHAPTER 5
384
Example 5.6 shows the font dictionary for the Adobe Garamond® Semibold font.
The font has an encoding dictionary (object 25), although neither the encoding
dictionary nor the font descriptor (object 7) is shown in the example.
FirstChar integer (Required except for the standard 14 fonts) The first character code defined in
the font’s
Widths array.
LastChar integer (Required except for the standard 14 fonts) The last character code defined in
the font’s
Widths array.
Widths array (Required except for the standard 14 fonts; indirect reference preferred) An ar-
ray of (
LastChar FirstChar + 1) widths, each element being the glyph width
for the character code that equals
FirstChar plus the array index. For charac-
ter codes outside the range
FirstChar to LastChar, the value of MissingWidth
from the FontDescriptor entry for this font is used. The glyph widths are
measured in units in which 1000 units corresponds to 1 unit in text space.
These widths must be consistent with the actual widths given in the font pro-
gram. (See implementation note 60 in Appendix H.) For more information
on glyph widths and other glyph metrics, see Section 5.1.3, “Glyph Position-
ing and Metrics.”
FontDescriptor dictionary (Required except for the standard 14 fonts; must be an indirect reference) A font
descriptor describing the font’s metrics other than its glyph widths (see Sec-
tion 5.7, “Font Descriptors”).
Note: For the standard 14 fonts, the entries
FirstChar, LastChar, Widths, and
FontDescriptor must either all be present or all be absent. Ordinarily, they are
absent; specifying them enables a standard font to be overridden (see “Standard
Type 1 Fonts,” below).
Encoding name or
dictionary
(Optional) A specification of the font’s character encoding if different from its
built-in encoding. The value of
Encoding is either the name of a predefined
encoding (
MacRomanEncoding, MacExpertEncoding, or WinAnsiEncoding,
as described in Appendix D) or an encoding dictionary that specifies differ-
ences from the font’s built-in encoding or from a specified predefined encod-
ing (see Section 5.5.5, “Character Encoding”).
ToUnicode stream (Optional; PDF 1.2) A stream containing a CMap file that maps character
codes to Unicode values (see Section 5.9, “Extraction of Text Content”).
KEY TYPE VALUE
Simple FontsSECTION 5.5
385
Example 5.6
14 0 obj
<< /Type /Font
/Subtype /Type1
/BaseFont /AGaramondSemibold
/FirstChar 0
/LastChar 255
/Widths 21 0 R
/FontDescriptor 7 0 R
/Encoding 25 0 R
>>
endobj
21 0 obj
[ 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
255 280 438 510 510 868 834 248 320 320 420 510 255 320 255 347
510 510 510 510 510 510 510 510 510 510 255 255 510 510 510 330
781 627 627 694 784 580 533 743 812 354 354 684 560 921 780 792
588 792 656 504 682 744 650 968 648 590 638 320 329 320 510 500
380 420 510 400 513 409 301 464 522 268 259 484 258 798 533 492
516 503 349 346 321 520 434 684 439 448 390 320 255 320 510 255
627 627 694 580 780 792 744 420 420 420 420 420 420 402 409 409
409 409 268 268 268 268 533 492 492 492 492 492 520 520 520 520
486 400 510 510 506 398 520 555 800 800 1044 360 380 549 846 792
713 510 549 549 510 522 494 713 823 549 274 354 387 768 615 496
330 280 510 549 510 549 612 421 421 1000 255 627 627 792 1016 730
500 1000 438 438 248 248 510 494 448 590 100 510 256 256 539 539
486 255 248 438 1174 627 580 627 580 580 354 354 354 354 792 792
790 792 744 744 744 268 380 380 380 380 380 380 380 380 380 380
]
endobj
Standard Type 1 Fonts
The PostScript names of 14 Type 1 fonts, known as the standard fonts, are as
follows:
TimesRoman Helvetica Courier Symbol
TimesBold HelveticaBold CourierBold ZapfDingbats
TimesItalic HelveticaOblique CourierOblique
TimesBoldItalic HelveticaBoldOblique CourierBoldOblique
TextCHAPTER 5
386
These fonts, or their font metrics and suitable substitution fonts, must be avail-
able to the consumer application. The character sets and encodings for these
fonts are listed in Appendix D. The Adobe font metrics (AFM) files for the stan-
dard 14 fonts are available from the ASN Web site (see the Bibliography). For
more information on font metrics, see Adobe Technical Note #5004, Adobe Font
Metrics File Format Specification.
Ordinarily, a font dictionary that refers to one of the standard fonts should omit
the
FirstChar, LastChar, Widths, and FontDescriptor entries. However, it is per-
missible to override a standard font by including these entries and embedding the
font program in the PDF file. (See implementation note 61 in Appendix H.)
Multiple Master Fonts
The multiple master font format is an extension of the Type 1 font format that al-
lows the generation of a wide variety of typeface styles from a single font pro-
gram. This is accomplished through the presence of various design dimensions in
the font. Examples of design dimensions are weight (light to extra-bold) and
width (condensed to expanded). Coordinates along these design dimensions
(such as the degree of boldness) are specified by numbers. A particular choice of
numbers selects an instance of the multiple master font. Adobe Technical Note
#5015, Type 1 Font Format Supplement, describes multiple master fonts in detail.
The font dictionary for a multiple master font instance has the same entries as a
Type 1 font dictionary (Table 5.8 on page 383), with the following differences:
• The value of Subtype is MMType1.
• If the PostScript name of the instance contains spaces, the spaces are replaced
by underscores in the value of
BaseFont. For instance, as illustrated in Example
5.7, the name “MinionMM 366 465 11 ” (which ends with a space character)
becomes
/MinionMM_366_465_11_.
Simple FontsSECTION 5.5
387
Example 5.7
7 0 obj
<< /Type /Font
/Subtype /MMType1
/BaseFont /MinionMM_366_465_11_
/FirstChar 32
/LastChar 255
/Widths 19 0 R
/FontDescriptor 6 0 R
/Encoding 5 0 R
>>
endobj
19 0 obj
[ 187 235 317 430 427 717 607 168 326 326 421 619 219 317 219 282 427
…Omitted data…
569 0 569 607 607 607 239 400 400 400 400 253 400 400 400 400 400
]
endobj
This example illustrates a convention for including the numeric values of the
design coordinates as part of the instance’s
BaseFont name. This convention is
commonly used for accessing multiple master font instances from an external
source in the consumer application’s environment; it is documented in Adobe
Technical Note #5088, Font Naming Issues. However, this convention is not pre-
scribed as part of the PDF specification. In particular, if the font program for this
instance is embedded in the PDF file, it must be an ordinary Type 1 font pro-
gram, not a multiple master font program. This font program is called a snapshot
of the multiple master font instance that incorporates the chosen values of the de-
sign coordinates.
5.5.2 TrueType Fonts
The TrueType font format was developed by Apple Computer, Inc., and has been
adopted as a standard font format for the Microsoft Windows operating system.
Specifications for the TrueType font file format are available in Apple’s TrueType
Reference Manual and Microsoft’s TrueType 1.0 Font Files Technical Specification.
Note: A TrueType font program can be embedded directly in a PDF file as a stream
object. The Type 42 font format that is defined for PostScript does not apply to PDF.
TextCHAPTER 5
388
A TrueType font dictionary can contain the same entries as a Type 1 font dictio-
nary (Table 5.8 on page 383), with the following differences:
• The value of Subtype is TrueType.
• The value of BaseFont is derived differently, as described below.
• The value of Encoding is subject to limitations that are described in Section
5.5.5, “Character Encoding.”
The PostScript name for the value of
BaseFont is determined in one of two ways:
• Use the PostScript name that is an optional entry in the “name” table of the
TrueType font.
• In the absence of such an entry in the “name” table, derive a PostScript name
from the name by which the font is known in the host operating system. On a
Windows system, the name is based on the
lfFaceName field in a LOGFONT
structure; in the Mac OS, it is based on the name of the FOND resource. If the
name contains any spaces, the spaces are removed.
If the font in a source document uses a bold or italic style but there is no font data
for that style, the host operating system synthesizes the style. In this case, a com-
ma and the style name (one of
Bold, Italic, or BoldItalic) are appended to the font
name. For example, for a TrueType font that is a bold variant of the New York
font, the
BaseFont value is written as /NewYork,Bold (as illustrated in Example
5.8).
Example 5.8
17 0 obj
<< /Type /Font
/Subtype /TrueType
/BaseFont /NewYork,Bold
/FirstChar 0
/LastChar 255
/Widths 23 0 R
/FontDescriptor 7 0 R
/Encoding /MacRomanEncoding
>>
endobj
Simple FontsSECTION 5.5
389
23 0 obj
[ 0 333 333 333 333 333 333 333 0 333 333 333 333 333 333 333 333 333
…Omitted data…
803 790 803 780 780 780 340 636 636 636 636 636 636 636 636 636 636
]
endobj
Note that for CJK (Chinese, Japanese, and Korean) fonts, the host font system’s
font name is often encoded in the host operating system’s script. For instance, a
Japanese font may have a name that is written in Japanese using some (unidenti-
fied) Japanese encoding. Thus, TrueType font names may contain multiple-byte
character codes, each of which requires multiple characters to represent in a PDF
name object (using the
# notation to quote special characters as needed).
5.5.3 Font Subsets
PDF 1.1 permits documents to include subsets of Type 1 and TrueType fonts.
The font and font descriptor that describe a font subset are slightly different
from those of ordinary fonts. These differences allow an application to recog-
nize font subsets and to merge documents containing different subsets of the
same font. (For more information on font descriptors, see Section 5.7, “Font De-
scriptors.”)
For a font subset, the PostScript name of the font—the value of the font’s
BaseFont entry and the font descriptor’s FontName entry—begins with a tag
followed by a plus sign (
+). The tag consists of exactly six uppercase letters; the
choice of letters is arbitrary, but different subsets in the same PDF file must have
different tags. For example,
EOODIA+Poetica is the name of a subset of Poetica
®
, a
Type 1 font. (See implementation note 62 in Appendix H.)
5.5.4 Type 3 Fonts
Type 3 fonts differ from the other fonts supported by PDF. A Type 3 font dictio-
nary defines the font; font dictionaries for other fonts simply contain information
about the font and refer to a separate font program for the actual glyph descrip-
tions. In Type 3 fonts, glyphs are defined by streams of PDF graphics operators.
These streams are associated with character names. A separate encoding entry
maps character codes to the appropriate character names for the glyphs.
TextCHAPTER 5
390
Type 3 fonts are more flexible than Type 1 fonts because the glyph descriptions
may contain arbitrary PDF graphics operators. However, Type 3 fonts have no
hinting mechanism for improving output at small sizes or low resolutions. A Type
3 font dictionary contains the entries listed in Table 5.9.
TABLE 5.9 Entries in a Type 3 font dictionary
KEY TYPE VALUE
Type name (Required) The type of PDF object that this dictionary describes; must be
Font for a font dictionary.
Subtype name (Required) The type of font; must be Type3 for a Type 3 font.
Name name (Required in PDF 1.0; optional otherwise) See Table 5.8 on page 383.
FontBBox rectangle (Required) A rectangle (see Section 3.8.4, “Rectangles”) expressed in the
glyph coordinate system, specifying the font bounding box. This is the small-
est rectangle enclosing the shape that would result if all of the glyphs of the
font were placed with their origins coincident and then filled.
If all four elements of the rectangle are zero, no assumptions are made based
on the font bounding box. If any element is nonzero, it is essential that the
font bounding box be accurate. If any glyph’s marks fall outside this bounding
box, incorrect behavior may result.
FontMatrix array (Required) An array of six numbers specifying the font matrix, mapping glyph
space to text space (see Section 5.1.3, “Glyph Positioning and Metrics”). A
common practice is to define glyphs in terms of a 1000-unit glyph coordinate
system, in which case the font matrix is
[0.001 0 0 0.001 0 0].
CharProcs dictionary (Required) A dictionary in which each key is a character name and the value
associated with that key is a content stream that constructs and paints the
glyph for that character. The stream must include as its first operator either
d0 or d1, followed by operators describing one or more graphics objects,
which may include path, text, or image objects. See below for more details
about Type 3 glyph descriptions.
Encoding name or
dictionary
(Required) An encoding dictionary whose Differences array specifies the
complete character encoding for this font (see Section 5.5.5, “Character
Encoding”; also see implementation note 63 in Appendix H).
FirstChar integer (Required) The first character code defined in the font’s Widths array.
LastChar integer (Required) The last character code defined in the font’s Widths array.
Simple FontsSECTION 5.5
391
For each character code shown by a text-showing operator that uses a Type 3
font, the consumer application does the following:
1. Looks up the character code in the font’s
Encoding entry, as described in Sec-
tion 5.5.5, “Character Encoding,” to obtain a character name.
2. Looks up the character name in the font’s
CharProcs dictionary to obtain a
stream object containing a glyph description. (If the name is not present as a
key in
CharProcs, no glyph is painted.)
3. Invokes the glyph description, as described below. The graphics state is saved
before this invocation and restored afterward; therefore, any changes the glyph
description makes to the graphics state do not persist after it finishes.
When the glyph description begins execution, the current transformation matrix
(CTM) is the concatenation of the font matrix (FontMatrix in the current font
dictionary) and the text space that was in effect at the time the text-showing op-
erator was invoked (see Section 5.3.3, “Text Space Details”). This means that
Widths array (Required; indirect reference preferred) An array of (LastChar FirstChar + 1)
widths, each element being the glyph width for the character code that equals
FirstChar plus the array index. For character codes outside the range FirstChar
to LastChar, the width is 0. These widths are interpreted in glyph space as
specified by
FontMatrix (unlike the widths of a Type 1 font, which are in
thousandths of a unit of text space).
Note: If
FontMatrix specifies a rotation, only the horizontal component of the
transformed width is used. That is, the resulting displacement is always hori-
zontal in text space, as is the case for all simple fonts.
FontDescriptor
dictionary (Required in Tagged PDF documents; must be an indirect reference) A font de-
scriptor describing the font’s default metrics other than its glyph widths (see
Section 5.7, “Font Descriptors”).
Resources dictionary (Optional but strongly recommended; PDF 1.2) A list of the named resources,
such as fonts and images, required by the glyph descriptions in this font (see
Section 3.7.2, “Resource Dictionaries”). If any glyph descriptions refer to
named resources but this dictionary is absent, the names are looked up in the
resource dictionary of the page on which the font is used. (See implementa-
tion note 64 in Appendix H.)
ToUnicode stream (Optional; PDF 1.2) A stream containing a CMap file that maps character
codes to Unicode values (see Section 5.9, “Extraction of Text Content”).
KEY TYPE VALUE
TextCHAPTER 5
392
shapes described in the glyph coordinate system are transformed into the user
coordinate system and appear in the appropriate size and orientation on the page.
The glyph description should describe the glyph in terms of absolute coordinates
in the glyph coordinate system, placing the glyph origin at (0, 0) in this space. It
should make no assumptions about the initial text position.
Aside from the CTM, the graphics state is inherited from the environment of the
text-showing operator that caused the glyph description to be invoked. To ensure
predictable results, the glyph description must initialize any graphics state
parameters on which it depends. In particular, if it invokes the
S (stroke) opera-
tor, it should explicitly set the line width, line join, line cap, and dash pattern to
appropriate values. Normally, it is unnecessary and undesirable to initialize the
current color parameter because the text-showing operators are designed to paint
glyphs with the current color.
The glyph description must execute one of the operators described in Table 5.10
to pass width and bounding box information to the font machinery. This must
precede the execution of any path construction or path-painting operators de-
scribing the glyph.
Note: Type 3 fonts in PDF are very similar to those in PostScript. Some of the in-
formation provided in Type 3 font dictionaries and glyph descriptions, while seem-
ingly redundant or unnecessary, is nevertheless required for correct results when a
PDF consumer application prints to a PostScript output device. This applies par-
ticularly to the operands of the
d0 and d1 operators, which in PostScript are
named
setcharwidth and setcachedevice. For further explanation, see Section 5.7
of the PostScript Language Reference, Third Edition.
TABLE 5.10 Type 3 font operators
OPERANDS OPERATOR DESCRIPTION
w
x
w
y
d0 Set width information for the glyph and declare that the glyph descrip-
tion specifies both its shape and its color. (Note that this operator name
ends in the digit
0.) w
x
specifies the horizontal displacement in the glyph
coordinate system; it must be consistent with the corresponding width
in the font’s
Widths array. w
y
must be 0 (see Section 5.1.3, “Glyph Posi-
tioning and Metrics”).
This operator is permitted only in a content stream appearing in a
Type 3 font’s
CharProcs dictionary. It is typically used only if the glyph
description executes operators to set the color explicitly.
Simple FontsSECTION 5.5
393
Example of a Type 3 Font
Example shows the definition of a Type 3 font with only two glyphs—a filled
square and a filled triangle, selected by the character codes
a and b. Figure 5.12
shows the result of showing the string
(ababab) using this font.
w
x
w
y
ll
x
ll
y
ur
x
ur
y
d1 Set width and bounding box information for the glyph and declare that
the glyph description specifies only shape, not color. (Note that this
operator name ends in the digit
1.) w
x
specifies the horizontal displace-
ment in the glyph coordinate system; it must be consistent with the
corresponding width in the font’s
Widths array. w
y
must be 0 (see Section
5.1.3, “Glyph Positioning and Metrics”).
ll
x
and ll
y
are the coordinates of the lower-left corner, and ur
x
and ur
y
the
upper-right corner, of the glyph bounding box. The glyph bounding box
is the smallest rectangle, oriented with the axes of the glyph coordinate
system, that completely encloses all marks placed on the page as a result
of executing the glyph’s description. The declared bounding box must be
correct—in other words, sufficiently large to enclose the entire glyph. If
any marks fall outside this bounding box, the result is unpredictable.
A glyph description that begins with the
d1 operator should not execute
any operators that set the color (or other color-related parameters) in the
graphics state; any use of such operators is ignored. The glyph descrip-
tion is executed solely to determine the glyph’s shape. Its color is deter-
mined by the graphics state in effect each time this glyph is painted by a
text-showing operator. For the same reason, the glyph description may
not include an image; however, an image mask is acceptable, since it
merely defines a region of the page to be painted with the current color.
This operator is permitted only in a content stream appearing in a
Type 3 font’s
CharProcs dictionary.
OPERANDS OPERATOR DESCRIPTION
TextCHAPTER 5
394
FIGURE 5.12 Output from Example
4 0 obj
<< /Type /Font
/Subtype /Type3
/FontBBox [0 0 750 750]
/FontMatrix [0.001 0 0 0.001 0 0]
/CharProcs 10 0 R
/Encoding 9 0 R
/FirstChar 97
/LastChar 98
/Widths [1000 1000]
>>
endobj
9 0 obj
<< /Type /Encoding
/Differences [97 /square /triangle]
>>
endobj
10 0 obj
<< /square 11 0 R
/triangle 12 0 R
>>
endobj
Simple FontsSECTION 5.5
395
11 0 obj
<< /Length 39 >>
stream
1000 0 0 0 750 750 d1
0 0 750 750 re
f
endstream
endobj
12 0 obj
<< /Length 48 >>
stream
1000 0 0 0 750 750 d1
00m
375 750 l
750 0 l
f
endstream
endobj
5.5.5 Character Encoding
A font’s encoding is the association between character codes (obtained from text
strings that are shown) and glyph descriptions. This section describes the charac-
ter encoding scheme used with simple PDF fonts. Composite fonts (Type 0) use a
different character mapping algorithm, as discussed in Section 5.6, “Composite
Fonts.”
Except for Type 3 fonts, every font program has a built-in encoding. Under cer-
tain circumstances, a PDF font dictionary can change a font’s built-in encoding to
match the requirements of the application generating the text being shown. This
flexibility in character encoding is valuable for two reasons:
• It permits showing text that is encoded according to any of the various existing
conventions. For example, the Microsoft Windows and Apple Mac OS oper-
ating systems use different standard encodings for Latin text, and many appli-
cations use their own special-purpose encodings.
• It permits applications to specify how characters selected from a large character
set are to be encoded. Some character sets consist of more than 256 characters,
including ligatures, accented characters, and other symbols required for high-
TextCHAPTER 5
396
quality typography or non-Latin writing systems. Different encodings can se-
lect different subsets of the same character set.
Latin-text font programs produced by Adobe Systems use the Adobe standard
encoding, often referred to as
StandardEncoding. The name StandardEncoding
has no special meaning in PDF, but this encoding does play a role as a default en-
coding (as shown in Table 5.11 below). The regular encodings used for Latin-text
fonts on Mac OS and Windows systems are named
MacRomanEncoding and
WinAnsiEncoding, respectively. An encoding named MacExpertEncoding is used
with “expert” fonts that contain additional characters useful for sophisticated ty-
pography. Complete details of these encodings and of the characters present in
typical fonts are provided in Appendix D.
In PDF, a font is classified as either nonsymbolic or symbolic according to whether
all of its characters are members of the Adobe standard Latin character set. This is
indicated by flags in the font descriptor; see Section 5.7.1, “Font Descriptor Flags.”
Symbolic fonts contain other character sets, to which the encodings mentioned
above ordinarily do not apply. Such font programs have built-in encodings that
are usually unique to each font. The standard 14 fonts include two symbolic fonts,
Symbol and ZapfDingbats, whose encodings and character sets are documented
in Appendix D.
A font program’s built-in encoding can be overridden or altered by including an
Encoding entry in the PDF font dictionary. The possible encoding modifications
depend on the font type, as discussed below. The value of the
Encoding entry is
either a named encoding (the name of one of the predefined encodings
MacRomanEncoding, MacExpertEncoding, or WinAnsiEncoding) or an encoding
dictionary. An encoding dictionary contains the entries listed in Table 5.11.
Simple FontsSECTION 5.5
397
TABLE 5.11 Entries in an encoding dictionary
The value of the Differences entry is an array of character codes and character
names organized as follows:
code
1
name
1,1
name
1,2
…
code
2
name
2,1
name
2,2
…
…
code
n
name
n,1
name
n,2
…
Each code is the first index in a sequence of character codes to be changed. The
first character name after the code becomes the name corresponding to that code.
Subsequent names replace consecutive code indices until the next code appears
in the array or the array ends. These sequences may be specified in any order but
should not overlap.
For example, in the encoding dictionary in Example 5.9, the name
quotesingle (')
is associated with character code 39,
Adieresis (Ä) with code 128, Aring (Å) with
129, and
trademark (™) with 170.
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if present, must
be
Encoding for an encoding dictionary.
BaseEncoding name (Optional) The base encoding—that is, the encoding from which the Differences
entry (if present) describes differences—specified as the name of a predefined
encoding
MacRomanEncoding, MacExpertEncoding, or WinAnsiEncoding (see
Appendix D).
If this entry is absent, the
Differences entry describes differences from an im-
plicit base encoding. For a font program that is embedded in the PDF file, the
implicit base encoding is the font program’s built-in encoding, as described
above and further elaborated in the sections on specific font types below. Other-
wise, for a nonsymbolic font, it is
StandardEncoding, and for a symbolic font, it
is the font’s built-in encoding.
Differences array (Optional; not recommended with TrueType fonts) An array describing the differ-
ences from the encoding specified by
BaseEncoding or, if BaseEncoding is ab-
sent, from an implicit base encoding. The
Differences array is described below.
TextCHAPTER 5
398
Example 5.9
25 0 obj
<< /Type /Encoding
/Differences
[ 39 /quotesingle
96 /grave
128 /Adieresis /Aring /Ccedilla /Eacute /Ntilde /Odieresis /Udieresis
/aacute /agrave /acircumflex /adieresis /atilde /aring /ccedilla
/eacute /egrave /ecircumflex /edieresis /iacute /igrave /icircumflex
/idieresis /ntilde /oacute /ograve /ocircumflex /odieresis /otilde
/uacute /ugrave /ucircumflex /udieresis /dagger /degree /cent
/sterling /section /bullet /paragraph /germandbls /registered
/copyright /trademark /acute /dieresis
174 /AE /Oslash
177 /plusminus
180 /yen /mu
187 /ordfeminine /ordmasculine
190 /ae /oslash /questiondown /exclamdown /logicalnot
196 /florin
199 /guillemotleft /guillemotright /ellipsis
203 /Agrave /Atilde /Otilde /OE /oe /endash /emdash /quotedblleft
/quotedblright /quoteleft /quoteright /divide
216 /ydieresis /Ydieresis /fraction /currency /guilsinglleft /guilsinglright
/fi /fl /daggerdbl /periodcentered /quotesinglbase /quotedblbase
/perthousand /Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave
/Iacute /Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex
241 /Ograve /Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde
/macron /breve /dotaccent /ring /cedilla /hungarumlaut /ogonek
/caron
]
>>
endobj
By convention, the name .notdef can be used to indicate that no character name
is associated with a given character code.
Encodings for Type 1 Fonts
A Type 1 font program’s glyph descriptions are keyed by character names, not by
character codes. Character names are ordinary PDF name objects. Descriptions of
Latin alphabetic characters are normally associated with names consisting of
single letters, such as
A or a. Other characters are associated with names com-
Simple FontsSECTION 5.5
399
posed of words, such as three, ampersand, or parenleft. A Type 1 font’s built-in
encoding is defined by an
Encoding array that is part of the font program, not to
be confused with the
Encoding entry in the PDF font dictionary.
An
Encoding entry can alter a Type 1 font’s mapping from character codes to
character names. The
Differences array can map a code to the name of any glyph
description that exists in the font program, regardless of whether that glyph is ref-
erenced by the font’s built-in encoding or by the encoding specified in the
BaseEncoding entry.
All Type 1 font programs contain an actual glyph named
.notdef. The effect pro-
duced by showing the
.notdef glyph is at the discretion of the font designer; in
Type 1 font programs produced by Adobe, it is the same as the space character. If
an encoding maps to a character name that does not exist in the Type 1 font pro-
gram, the
.notdef glyph is substituted.
Encodings for Type 3 Fonts
A Type 3 font, like a Type 1 font, contains glyph descriptions that are keyed by
character names; in this case, they appear as explicit keys in the font’s
CharProcs
dictionary. A Type 3 font’s mapping from character codes to character names is
entirely defined by its
Encoding entry, which is required in this case.
Encodings for TrueType Fonts
A TrueType font program’s built-in encoding maps directly from character codes
to glyph descriptions by means of an internal data structure called a “cmap” (not
to be confused with the CMap described in Section 5.6.4, “CMaps”). This section
describes how the PDF font dictionary’s
Encoding entry is used in conjunction
with a “cmap” to map from a character code in a string to a glyph description in a
TrueType font program.
A “cmap” table may contain one or more subtables that represent multiple encod-
ings intended for use on different platforms (such as Mac OS and Windows).
Each subtable is identified by the two numbers, such as (3, 1), that represent a
combination of a platform ID and a platform-specific encoding ID, respectively.
Glyph names are not mandatory in TrueType fonts, although some font programs
have an optional “post” table listing glyph names for the glyphs. If the consumer
TextCHAPTER 5
400
application needs to select glyph descriptions by name, it translates from glyph
names to codes in one of the encodings given in the font program’s “cmap” table.
When there is no character code in the “cmap” that corresponds to a glyph name,
the “post” table is used to select a glyph description directly from the glyph name.
Because some aspects of TrueType glyph selection are dependent on the consum-
er implementation or the operating system, PDF files that use TrueType fonts
should follow certain guidelines to ensure predictable behavior across all applica-
tions:
• The font program should be embedded.
• A nonsymbolic font should specify MacRomanEncoding or WinAnsiEncoding
as the value of its Encoding entry, with no Differences array.
• A font that is used to display glyphs that do not use MacRomanEncoding or
WinAnsiEncoding should not specify an Encoding entry. The font descriptor’s
Symbolic flag (see Table 5.20) should be set, and its font program’s “cmap” table
should contain a (1, 0) subtable. It may also contain a (3, 0) subtable; if present,
this subtable should map from character codes in the range 0xF000 to 0xF0FF
by prepending the single-byte codes in the (1, 0) subtable with 0xF0 and map-
ping to the corresponding glyph descriptions.
Note: Some popular TrueType font programs contain incorrect encoding informa-
tion. Implementations of TrueType font interpreters have evolved heuristics for deal-
ing with such problems; those heuristics are not described here. For maximum
portability, only well-formed TrueType font programs should be used in PDF files.
Therefore, a TrueType font program in a PDF file may need to be modified to con-
form to the guidelines described above.
The following paragraphs describe the treatment of TrueType font encodings be-
ginning with PDF 1.3, as implemented in Acrobat 5.0 and later viewers. This in-
formation does not necessarily apply to earlier versions or implementations.
Simple FontsSECTION 5.5
401
If the font has a named Encoding entry of either MacRomanEncoding or
WinAnsiEncoding, or if the font descriptor’s Nonsymbolic flag (see Table 5.20) is
set, the viewer creates a table that maps from character codes to glyph names:
• If the Encoding entry is one of the names MacRomanEncoding or WinAnsiEn-
coding
, the table is initialized with the mappings described in Appendix D.
• If the Encoding entry is a dictionary, the table is initialized with the entries
from the dictionary’s
BaseEncoding entry (see Table 5.11). Any entries in the
Differences array are used to update the table. Finally, any undefined entries in
the table are filled using
StandardEncoding.
If a (3, 1) “cmap” subtable (Microsoft Unicode) is present:
• A character code is first mapped to a glyph name using the table described
above.
• The glyph name is then mapped to a Unicode value by consulting the Adobe
Glyph List (see the Bibliography).
• Finally, the Unicode value is mapped to a glyph description according to the
(3, 1) subtable.
If no (3, 1) subtable is present but a (1, 0) subtable (Macintosh
®
Roman) is
present:
• A character code is first mapped to a glyph name using the table described
above.
• The glyph name is then mapped back to a character code according to the stan-
dard Roman encoding used on Mac OS (see note below).
• Finally, the code is mapped to a glyph description according to the (1, 0) sub-
table.
In either of the cases above, if the glyph name cannot be mapped as specified, the
glyph name is looked up in the font program’s “post” table (if one is present) and
the associated glyph description is used.
Note: The standard Roman encoding that is used on Mac OS is the same as the
MacRomanEncoding described in Appendix D, with the addition of following 15 en-
tries and the replacement of the currency glyph with the Euro glyph, as shown in Ta-
ble 5.12.
TextCHAPTER 5
402
TABLE 5.12 Differences between MacRomanEncoding and Mac OS Roman encoding
When the font has no Encoding entry, or the font descriptor’s Symbolic flag is set
(in which case the
Encoding entry is ignored), the following occurs:
• If the font contains a (3, 0) subtable, the range of character codes must be one
of the following: 0x0000 - 0x00FF, 0xF000 - 0xF0FF, 0xF100 - 0xF1FF, or
0xF200 - 0xF2FF. Depending on the range of codes, each byte from the string is
prepended with the high byte of the range, to form a two-byte character, which
is used to select the associated glyph description from the subtable.
• Otherwise, if the font contains a (1, 0) subtable, single bytes from the string are
used to look up the associated glyph descriptions from the subtable.
NAME CODE (OCTAL) CODE (DECIMAL)
notequal 255 173
infinity 260 176
lessequal 262 178
greaterequal 263 179
partialdiff 266 182
summation 267 183
product 270 184
pi 271 185
integral 272 186
Omega 275 189
radical 303 195
approxequal 305 197
Delta 306 198
lozenge 327 215
Euro 333 219
apple 360 240
Composite FontsSECTION 5.6
403
If a character cannot be mapped in any of the ways described above, the results
are implementation-dependent.
5.6 Composite Fonts
A composite font, also called a Type 0 font, is one whose glyphs are obtained from
a fontlike object called a CIDFont. A composite font is represented by a font dic-
tionary whose
Subtype value is Type0. The Type 0 font is known as the root font,
and its associated CIDFont is called its descendant.
Note: Composite fonts in PDF are analogous to composite fonts in PostScript but
with some limitations. In particular, PDF requires that the character encoding be
defined by a CMap (described below), which is only one of several encoding meth-
ods available in PostScript.Also, PostScript allows a Type 0 font to have multiple de-
scendants, which might also be Type 0 fonts. PDF supports only a single descendant,
which must be a CIDFont.
When the current font is composite, the text-showing operators behave different-
ly than with simple fonts. For simple fonts, each byte of a string to be shown se-
lects one glyph, whereas for composite fonts, a sequence of one or more bytes can
be decoded to select a glyph from the descendant CIDFont. This facility supports
the use of very large character sets, such as those for the Chinese, Japanese, and
Korean languages. It also simplifies the organization of fonts that have complex
encoding requirements.
This section first introduces the architecture of CID-keyed fonts, which are the
only kind of composite font supported in PDF. Then it describes the CIDFont and
CMap dictionaries, which are the PDF objects that represent the correspondingly
named components of a CID-keyed font. Finally, it describes the Type 0 font dic-
tionary, which combines a CIDFont and a CMap to produce a font whose glyphs
can be accessed by means of variable-length character codes in a string to be
shown.
5.6.1 CID-Keyed Fonts Overview
CID-keyed fonts provide a convenient and efficient method for defining
multiple-byte character encodings, fonts with a large number of glyphs, and fonts
that incorporate glyphs obtained from other fonts. These capabilities provide
TextCHAPTER 5
404
great flexibility for representing text in writing systems for languages with large
character sets, such as Chinese, Japanese, and Korean (CJK).
The CID-keyed font architecture specifies the external representation of certain
font programs, called CMap and CIDFont files, along with some conventions for
combining and using those files. As mentioned earlier, PDF does not support the
entire CID-keyed font architecture, which is independent of PDF; CID-keyed
fonts can be used in other environments. For complete documentation on the ar-
chitecture and the file formats, see Adobe Technical Notes #5092, CID-Keyed
Font Technology Overview, and #5014, Adobe CMap and CIDFont Files Specifica-
tion. This section describes only the PDF objects that represent these font pro-
grams.
The term CID-keyed font reflects the fact that CID (character identifier) numbers
are used to index and access the glyph descriptions in the font. This method is
more efficient for large fonts than the method of accessing by character name, as
is used for some simple fonts. CIDs range from 0 to a maximum value that is sub-
ject to an implementation limit (see Table C.1 on page 920).
A character collection is an ordered set of all glyphs needed to support one or
more popular character sets for a particular language. The order of the glyphs in
the character collection determines the CID number for each glyph. Each CID-
keyed font must explicitly reference the character collection on which its CID
numbers are based; see Section 5.6.2, “CIDSystemInfo Dictionaries.”
A CMap (character map) file specifies the correspondence between character
codes and the CID numbers used to identify glyphs. It is equivalent to the con-
cept of an encoding in simple fonts. Whereas a simple font allows a maximum of
256 glyphs to be encoded and accessible at one time, a CMap can describe a map-
ping from multiple-byte codes to thousands of glyphs in a large CID-keyed font.
For example, it can describe Shift-JIS, one of several widely used encodings for
Japanese.
A CMap can reference an entire character collection, a subset, or multiple charac-
ter collections. It can also reference characters in other fonts by character code or
character name. The CMap mapping yields a font number (which in PDF is al-
ways 0) and a character selector (which in PDF is always a CID). Furthermore, a
CMap can incorporate another CMap by reference, without having to duplicate it.
These features enable character collections to be combined or supplemented and
Composite FontsSECTION 5.6
405
make all the constituent characters accessible to text-showing operations through
a single encoding.
A CIDFont file contains the glyph descriptions for a character collection. The
glyph descriptions themselves are typically in a format similar to those used in
simple fonts, such as Type 1. However, they are identified by CIDs rather than by
names, and they are organized differently.
In PDF, the CMap and CIDFont are represented by PDF objects, which are de-
scribed below. The CMap and CIDFont programs themselves can be either refer-
enced by name or embedded as stream objects in the PDF file. As stated earlier,
the external file formats are documented in Adobe Technical Note #5014, Adobe
CMap and CIDFont Files Specification.
A CID-keyed font, then, is the combination of a CMap with a CIDFont contain-
ing glyph descriptions. It is represented as a Type 0 font. It contains an
Encoding
entry whose value is a CMap dictionary, and its DescendantFonts entry refer-
ences the CIDFont dictionary with which the CMap has been combined.
5.6.2 CIDSystemInfo Dictionaries
CIDFont and CMap dictionaries contain a CIDSystemInfo entry specifying the
character collection assumed by the CIDFont associated with the CMap—that is,
the interpretation of the CID numbers used by the CIDFont. A character collec-
tion is uniquely identified by the
Registry, Ordering, and Supplement entries in
the
CIDSystemInfo dictionary, as described in Table 5.13. Character collections
whose
Registry and Ordering values are the same are compatible.
The
CIDSystemInfo entry in a CIDFont is a dictionary that specifies the
CIDFont’s character collection. The CIDFont need not contain glyph descriptions
for all the CIDs in a collection; it can contain a subset. The
CIDSystemInfo entry
in a CMap is either a single dictionary or an array of dictionaries, depending on
whether it associates codes with a single character collection or with multiple
character collections; see Section 5.6.4, “CMaps.”
For proper behavior, the
CIDSystemInfo entry of a CMap should be compatible
with that of the CIDFont or CIDFonts with which it is used. If they are incompat-
ible, the effects produced are unpredictable.
TextCHAPTER 5
406
TABLE 5.13 Entries in a CIDSystemInfo dictionary
5.6.3 CIDFonts
A CIDFont program contains glyph descriptions that are accessed using a CID as
the character selector. There are two types of CIDFonts:
• A Type 0 CIDFont contains glyph descriptions based on the Adobe Type 1 font
format
Note: The term “Type 0” when applied to a CIDFont has a different meaning than
for a “Type 0 font”.
• A Type 2 CIDFont contains glyph descriptions based on the TrueType font for-
mat
A CIDFont dictionary is a PDF object that contains information about a CIDFont
program. Although its
Type value is Font, a CIDFont is not actually a font. It does
not have an
Encoding entry, it cannot be listed in the Font subdictionary of a re-
source dictionary, and it cannot be used as the operand of the
Tf operator. It is
used only as a descendant of a Type 0 font. The CMap in the Type 0 font is what
defines the encoding that maps character codes to CIDs in the CIDFont. Table
5.14 lists the entries in a CIDFont dictionary.
KEY TYPE VALUE
Registry string (Required) A string identifying the issuer of the character collection—for example,
Adobe. For information about assigning a registry identifier, contact the Adobe
Solutions Network or consult the ASN Web site (see the Bibliography).
Ordering string (Required) A string that uniquely names the character collection within the speci-
fied registry—for example,
Japan1.
Supplement integer (Required) The supplement number of the character collection. An original charac-
ter collection has a supplement number of 0. Whenever additional CIDs are
assigned in a character collection, the supplement number is increased. Supple-
ments do not alter the ordering of existing CIDs in the character collection. This
value is not used in determining compatibility between character collections.
Composite FontsSECTION 5.6
407
TABLE 5.14 Entries in a CIDFont dictionary
KEY TYPE VALUE
Type name (Required) The type of PDF object that this dictionary describes; must be
Font for a CIDFont dictionary.
Subtype name (Required) The type of CIDFont; CIDFontType0 or CIDFontType2.
BaseFont name (Required) The PostScript name of the CIDFont. For Type 0 CIDFonts, this
is usually the value of the
CIDFontName entry in the CIDFont program. For
Type 2 CIDFonts, it is derived the same way as for a simple TrueType font;
see Section 5.5.2, “TrueType Fonts.” In either case, the name can have a sub-
set prefix if appropriate; see Section 5.5.3, “Font Subsets.”
CIDSystemInfo dictionary (Required) A dictionary containing entries that define the character collec-
tion of the CIDFont. See Table 5.13 on page 406.
FontDescriptor dictionary (Required; must be an indirect reference) A font descriptor describing the
CIDFont’s default metrics other than its glyph widths (see Section 5.7, “Font
Descriptors”).
DW integer (Optional) The default width for glyphs in the CIDFont (see “Glyph Metrics
in CIDFonts” on page 409). Default value: 1000.
W array (Optional) A description of the widths for the glyphs in the CIDFont. The
array’s elements have a variable format that can specify individual widths
for consecutive CIDs or one width for a range of CIDs (see “Glyph Metrics
in CIDFonts” on page 409). Default value: none (the
DW value is used for all
glyphs).
DW2 array (Optional; applies only to CIDFonts used for vertical writing) An array of two
numbers specifying the default metrics for vertical writing (see “Glyph Met-
rics in CIDFonts” on page 409). Default value:
[880 1000].
W2 array (Optional; applies only to CIDFonts used for vertical writing) A description
of the metrics for vertical writing for the glyphs in the CIDFont (see “Glyph
Metrics in CIDFonts” on page 409). Default value: none (the
DW2 value is
used for all glyphs).
TextCHAPTER 5
408
Glyph Selection in CIDFonts
Type 0 and Type 2 CIDFonts handle the mapping from CIDs to glyph descrip-
tions in somewhat different ways.
For Type 0, the CIDFont program contains glyph descriptions that are identified
by CIDs. The CIDFont program identifies the character collection by a
CIDSystemInfo dictionary, which should simply be copied into the PDF CIDFont
dictionary. CIDs are interpreted uniformly in all CIDFont programs supporting a
given character collection, whether the program is embedded in the PDF file or
obtained from an external source.
When the CIDFont contains an embedded font program that is represented in
the Compact Font Format (CFF), the
FontFile3 entry in the font descriptor (see
Table 5.23) can be
CIDFontType0C or OpenType. There are two cases, depending
on the contents of the font program:
• The “CFF” font program has a Top DICT that uses CIDFont operators: The CIDs
are used to determine the GID value for the glyph procedure using the
charset
table in the CFF program. The GID value is then used to look up the glyph pro-
cedure using the CharStrings
INDEX table. Although in many fonts the CID val-
ue and GID value are the same, the CID and GID values may differ.
• The “CFF” font program has a Top DICT that does not use CIDFont operators:
The CIDs are used directly as GID values, and the glyph procedure is retrieved
using the CharStrings
INDEX.
For Type 2, the CIDFont program is actually a TrueType font program, which has
no native notion of CIDs. In a TrueType font program, glyph descriptions are
CIDToGIDMap stream
or name
(Optional; Type 2 CIDFonts only) A specification of the mapping from CIDs
to glyph indices. If the value is a stream, the bytes in the stream contain the
mapping from CIDs to glyph indices: the glyph index for a particular CID
value c is a 2-byte value stored in bytes 2 × c and 2 × c + 1, where the first
byte is the high-order byte. If the value of
CIDToGIDMap is a name, it must
be
Identity, indicating that the mapping between CIDs and glyph indices is
the identity mapping. Default value:
Identity.
This entry may appear only in a Type 2 CIDFont whose associated True-
Type font program is embedded in the PDF file (see the next section).
KEY TYPE VALUE
Composite FontsSECTION 5.6
409
identified by glyph index values. Glyph indices are internal to the font and are not
defined consistently from one font to another. Instead, a TrueType font program
contains a “cmap” table that provides mappings directly from character codes to
glyph indices for one or more predefined encodings.
TrueType font programs are integrated with the CID-keyed font architecture in
one of two ways, depending on whether the font program is embedded in the
PDF file:
• If the TrueType font program is embedded, the Type 2 CIDFont dictionary
must contain a
CIDToGIDMap entry that maps CIDs to the glyph indices for the
appropriate glyph descriptions in that font program.
• If the TrueType font program is not embedded but is referenced by name, the
Type 2 CIDFont dictionary must not contain a
CIDToGIDMap entry, since it is
not meaningful to refer to glyph indices in an external font program. In this
case, CIDs do not participate in glyph selection, and only predefined CMaps
may be used with this CIDFont (see Section 5.6.4, “CMaps”). The consumer ap-
plication selects glyphs by translating characters from the encoding specified
by the predefined CMap to one of the encodings in the TrueType font’s “cmap”
table. The means by which this is accomplished are implementation-depen-
dent.
Even though the CIDs are sometimes not used to select glyphs in a Type 2
CIDFont, they are always used to determine the glyph metrics, as described in the
next section.
Every CIDFont must contain a glyph description for CID 0, which is analogous to
the
.notdef character name in simple fonts (see “Handling Undefined Characters”
on page 425).
Glyph Metrics in CIDFonts
As discussed in Section 5.1.3, “Glyph Positioning and Metrics,” the width of a
glyph refers to the horizontal displacement between the origin of the glyph and
the origin of the next glyph when writing in horizontal mode. In this mode, the
vertical displacement between origins is always 0. Widths for a CIDFont are de-
fined using the
DW and W entries in the CIDFont dictionary. These widths must
be consistent with the actual widths given in the CIDFont program. (See imple-
mentation note 60 in Appendix H.)
TextCHAPTER 5
410
The DW entry defines the default width, which is used for all glyphs whose widths
are not specified individually. This entry is particularly useful for Chinese, Japa-
nese, and Korean fonts, in which many of the glyphs have the same width.
The
W array allows the definition of widths for individual CIDs. The elements of
the array are organized in groups of two or three, where each group is in one of
the following two formats:
c [w
1
w
2
… w
n
]
c
first
c
last
w
In the first format, c is an integer specifying a starting CID value; it is followed by
an array of n numbers that specify the widths for n consecutive CIDs, starting
with
c. The second format defines the same width, w, for all CIDs in the range
c
first
to c
last
.
The following is an example of a
W entry:
/W [ 120 [400 325 500]
7080 8032 1000
]
In this example, the glyphs having CIDs 120, 121, and 122 are 400, 325, and 500
units wide, respectively. CIDs in the range 7080 through 8032 all have a width of
1000 units.
Glyphs from a CIDFont can be shown in vertical writing mode. (This is selected
by the
WMode entry in the associated CMap dictionary; see Section 5.6.4,
“CMaps.”) To be used in this way, the CIDFont must define the vertical dis-
placement for each glyph and the position vector that relates the horizontal and
vertical writing origins.
The default position vector and vertical displacement vector are specified by the
DW2 entry in the CIDFont dictionary. DW2 is an array of two values: the vertical
component of the position vector v and the vertical component of the displace-
ment vector w1 (see Figure 5.5 on page 366). The horizontal component of the
position vector is always half the glyph width, and that of the displacement vector
is always 0. For example, if the
DW2 entry is
/DW2 [880 1000]
Composite FontsSECTION 5.6
411
then a glyph’s position vector and vertical displacement vector are
where w0 is the width (horizontal displacement) for the same glyph. Note that a
negative value for the vertical component places the origin of the next glyph be-
low the current glyph because vertical coordinates in a standard coordinate sys-
tem increase from bottom to top.
The
W2 array allows the definition of vertical metrics for individual CIDs. The
elements of the array are organized in groups of two or five, where each group is
in one of the following two formats:
c [w1
1y
v
1x
v
1y
w1
2y
v
2x
v
2y
…]
c
first
c
last
w1
1y
v
1x
v
1y
In the first format, c is a starting CID and is followed by an array containing
numbers interpreted in groups of three. Each group consists of the vertical com-
ponent of the vertical displacement vector
w1 (whose horizontal component is al-
ways 0) followed by the horizontal and vertical components for the position
vector
v. Successive groups define the vertical metrics for consecutive CIDs start-
ing with
c. The second format defines a range of CIDs from c
first
to c
last
, followed
by three numbers that define the vertical metrics for all CIDs in this range. For
example:
/W2 [ 120 [1000 250 772]
7080 8032 1000 500 900
]
This W2 entry defines the vertical displacement vector for the glyph with CID
120 as (0, 1000) and the position vector as (250, 772). It also defines the dis-
placement vector for CIDs in the range 7080 through 8032 as (0, 1000) and the
position vector as (500, 900).
5.6.4 CMaps
A CMap specifies the mapping from character codes to character selectors. In
PDF, the character selectors are always CIDs in a CIDFont (as mentioned earlier,
PostScript CMaps may use names or codes as well). A CMap serves a function
vw02÷ 880(,)=
w1 0 1000–(, )=
TextCHAPTER 5
412
analogous to the Encoding dictionary for a simple font. The CMap does not refer
directly to a specific CIDFont; instead, it is combined with it as part of a CID-
keyed font, represented in PDF as a Type 0 font dictionary (see Section 5.6.5,
“Type 0 Font Dictionaries”). Within the CMap, the character mappings refer to
the associated CIDFont by font number, which in PDF is always 0.
Note: PDF also uses a special type of CMap to map character codes to Unicode val-
ues (see Section 5.9.2, “ToUnicode CMaps”).
A CMap also specifies the writing mode—horizontal or vertical—for any
CIDFont with which the CMap is combined. The writing mode determines
which metrics are to be used when glyphs are painted from that font. (Writing
mode is specified as part of the CMap because, in some cases, different shapes are
used when writing horizontally and vertically. In such cases, the horizontal and
vertical variants of a CMap specify different CIDs for a given character code.)
A CMap may be specified in two ways:
• As a name object identifying a predefined CMap, whose definition is known to
the consumer application
• As a stream object whose contents are a CMap file (see implementation note 65
in Appendix H)
Predefined CMaps
Table 5.15 lists the names of the predefined CMaps. These CMaps map character
codes to CIDs in a single descendant CIDFont. CMaps whose names end in
H
specify horizontal writing mode; those ending in V specify vertical writing mode.
Note: Several of the CMaps define mappings from Unicode encodings to character
collections. Unicode values appearing in a text string are represented in big-endian
order (high-order byte first). CMap names containing
"UCS2" use UCS-2 encoding;
names containing "
UTF16" use UTF-16BE (big-endian) encoding.
TABLE 5.15 Predefined CJK CMap names
NAME DESCRIPTION
Chinese (Simplified)
GBEUCH
Microsoft Code Page 936 (lfCharSet 0x86), GB 2312-80 character set, EUC-CN encoding
Composite FontsSECTION 5.6
413
GBEUCV
Vertical version of GBEUCH
GBpcEUCH
Mac OS, GB 2312-80 character set, EUC-CN encoding, Script Manager code 19
GBpcEUCV
Vertical version of GBpcEUCH
GBKEUCH
Microsoft Code Page 936 (lfCharSet 0x86), GBK character set, GBK encoding
GBKEUCV
Vertical version of GBKEUCH
GBKpEUCH
Same as GBKEUCH but replaces half-width Latin characters with proportional forms
and maps character code 0x24 to a dollar sign ($) instead of a yuan symbol (¥)
GBKpEUCV
Vertical version of GBKpEUCH
GBK2KH
GB 18030-2000 character set, mixed 1-, 2-, and 4-byte encoding
GBK2KV
Vertical version of GBK2KH
UniGBUCS2H
Unicode (UCS-2) encoding for the Adobe-GB1 character collection
UniGBUCS2V
Vertical version of UniGBUCS2H
UniGBUTF16H
Unicode (UTF-16BE) encoding for the Adobe-GB1 character collection; contains map-
pings for all characters in the GB18030-2000 character set
UniGBUTF16V
Vertical version of UniGBUTF16H
Chinese (Traditional)
B5pcH
Mac OS, Big Five character set, Big Five encoding, Script Manager code 2
B5pcV
Vertical version of B5pcH
HKscsB5H
Hong Kong SCS, an extension to the Big Five character set and encoding
HKscsB5V
Vertical version of HKscsB5H
ETenB5H
Microsoft Code Page 950 (lfCharSet 0x88), Big Five character set with ETen extensions
ETenB5V
Vertical version of ETenB5H
ETenmsB5H
Same as ETenB5H but replaces half-width Latin characters with proportional forms
ETenmsB5V
Vertical version of ETenmsB5H
CNSEUCH
CNS 11643-1992 character set, EUC-TW encoding
NAME DESCRIPTION
TextCHAPTER 5
414
CNSEUCV
Vertical version of CNSEUCH
UniCNSUCS2H
Unicode (UCS-2) encoding for the Adobe-CNS1 character collection
UniCNSUCS2V
Vertical version of UniCNSUCS2H
UniCNSUTF16H
Unicode (UTF-16BE) encoding for the Adobe-CNS1 character collection; contains map-
pings for all the characters in the HKSCS-2001 character set and contains both 2- and 4-
byte character codes
UniCNSUTF16V
Vertical version of UniCNSUTF16H
Japanese
83pvRKSJH
Mac OS, JIS X 0208 character set with KanjiTalk6 extensions, Shift-JIS encoding, Script
Manager code 1
90msRKSJH
Microsoft Code Page 932 (lfCharSet 0x80), JIS X 0208 character set with NEC and IBM
®
extensions
90msRKSJV
Vertical version of 90msRKSJH
90mspRKSJH
Same as 90msRKSJH but replaces half-width Latin characters with proportional forms
90mspRKSJV
Vertical version of 90mspRKSJH
90pvRKSJH
Mac OS, JIS X 0208 character set with KanjiTalk7 extensions, Shift-JIS encoding, Script
Manager code 1
AddRKSJH
JIS X 0208 character set with Fujitsu FMR extensions, Shift-JIS encoding
AddRKSJV
Vertical version of AddRKSJH
EUCH
JIS X 0208 character set, EUC-JP encoding
EUCV
Vertical version of EUCH
ExtRKSJH
JIS C 6226 (JIS78) character set with NEC extensions, Shift-JIS encoding
ExtRKSJV
Vertical version of ExtRKSJH
H
JIS X 0208 character set, ISO-2022-JP encoding
V
Vertical version of H
UniJISUCS2H
Unicode (UCS-2) encoding for the Adobe-Japan1 character collection
NAME DESCRIPTION
Composite FontsSECTION 5.6
415
UniJISUCS2V
Vertical version of UniJISUCS2H
UniJISUCS2HWH
Same as UniJISUCS2H but replaces proportional Latin characters with half-width
forms
UniJISUCS2HWV
Vertical version of UniJISUCS2HWH
UniJISUTF16-H
Unicode (UTF-16BE) encoding for the Adobe-Japan1 character collection; contains
mappings for all characters in the JIS X 0213:1000 character set
UniJISUTF16-V
Vertical version of UniJISUTF16-H
Korean
KSCEUCH
KS X 1001:1992 character set, EUC-KR encoding
KSCEUCV
Vertical version of KSCEUCH
KSCmsUHCH
Microsoft Code Page 949 (lfCharSet 0x81), KS X 1001:1992 character set plus 8822 addi-
tional hangul, Unified Hangul Code (UHC) encoding
KSCmsUHCV
Vertical version of KSCmsUHCH
KSCmsUHCHWH
Same as KSCmsUHCH but replaces proportional Latin characters with half-width forms
KSCmsUHCHWV
Vertical version of KSCmsUHCHWH
KSCpcEUCH
Mac OS, KS X 1001:1992 character set with Mac OS KH extensions, Script Manager
Code 3
UniKSUCS2H
Unicode (UCS-2) encoding for the Adobe-Korea1 character collection
UniKSUCS2V
Vertical version of UniKSUCS2H
UniKSUTF16H
Unicode (UTF-16BE) encoding for the Adobe-Korea1 character collection
UniKSUTF16V
Vertical version of UniKSUTF16H
Generic
IdentityH
The horizontal identity mapping for 2-byte CIDs; may be used with CIDFonts using any
Registry, Ordering, and Supplement values. It maps 2-byte character codes ranging from
0 to 65,535 to the same 2-byte CID value, interpreted high-order byte first (see below).
IdentityV
Vertical version of IdentityH. The mapping is the same as for IdentityH.
NAME DESCRIPTION
TextCHAPTER 5
416
The IdentityH and IdentityV CMaps can be used to refer to glyphs directly by
their CIDs when showing a text string. When the current font is a Type 0 font
whose
Encoding entry is IdentityH or IdentityV, the string to be shown is inter-
preted as pairs of bytes representing CIDs, high-order byte first. This works with
any CIDFont, independently of its character collection. Additionally, when used
in conjunction with a Type 2 CIDFont whose
CIDToGIDMap entry is Identity, the
2-byte CID values represent glyph indices for the glyph descriptions in the True-
Type font program. This works only if the TrueType font program is embedded in
the PDF file.
Table 5.16 lists the character collections referenced by the predefined CMaps for
the different versions of PDF. A dash (—) indicates that the CMap is not pre-
defined in that PDF version.
TABLE 5.16 Character collections for predefined CMaps, by PDF version
CMAP PDF 1.2 PDF 1.3 PDF 1.4 PDF 1.5
Chinese (Simplified)
GBEUCH/V
Adobe-GB1-0 Adobe-GB1-0 Adobe-GB1-0 Adobe-GB1-0
GBpcEUCH
Adobe-GB1-0 Adobe-GB1-0 Adobe-GB1-0 Adobe-GB1-0
GBpcEUCV
— Adobe-GB1-0 Adobe-GB1-0 Adobe-GB1-0
GBKEUCH/V
— Adobe-GB1-2 Adobe-GB1-2 Adobe-GB1-2
GBKpEUCH/V
— — Adobe-GB1-2 Adobe-GB1-2
GBK2KH/V
— — Adobe-GB1-4 Adobe-GB1-4
UniGBUCS2H/V
— Adobe-GB1-2 Adobe-GB1-4 Adobe-GB1-4
UniGBUTF16-H/V
— — — Adobe-GB1-4
Chinese (Traditional)
B5pcH/V
Adobe-CNS1-0 Adobe-CNS1-0 Adobe-CNS1-0 Adobe-CNS1-0
HKscsB5H/V
— — Adobe-CNS1-3 Adobe-CNS1-3
ETenB5H/V
Adobe-CNS1-0 Adobe-CNS1-0 Adobe-CNS1-0 Adobe-CNS1-0
ETenmsB5H/V
— Adobe-CNS1-0 Adobe-CNS1-0 Adobe-CNS1-0
CNSEUCH/V
Adobe-CNS1-0 Adobe-CNS1-0 Adobe-CNS1-0 Adobe-CNS1-0
Composite FontsSECTION 5.6
417
UniCNSUCS2H/V
— Adobe-CNS1-0 Adobe-CNS1-3 Adobe-CNS1-3
UniCNSUTF16-H/V
— — — Adobe-CNS1-4
Japanese
83pvRKSJH
Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1
90msRKSJH/V
Adobe-Japan1-2 Adobe-Japan1-2 Adobe-Japan1-2 Adobe-Japan1-2
90mspRKSJH/V
— Adobe-Japan1-2 Adobe-Japan1-2 Adobe-Japan1-2
90pvRKSJH
Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1
AddRKSJH/V
Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1
EUCH/V
— Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1
ExtRKSJH/V
Adobe-Japan1-2 Adobe-Japan1-2 Adobe-Japan1-2 Adobe-Japan1-2
H/V
Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1 Adobe-Japan1-1
UniJISUCS2H/V
— Adobe-Japan1-2 Adobe-Japan1-4 Adobe-Japan1-4
UniJISUCS2HWH/V
— Adobe-Japan1-2 Adobe-Japan1-4 Adobe-Japan1-4
UniJISUTF16H/V
— — — Adobe-Japan1-5
Korean
KSCEUCH/V
Adobe-Korea1-0 Adobe-Korea1-0 Adobe-Korea1-0 Adobe-Korea1-0
KSCmsUHCH/V
Adobe-Korea1-1 Adobe-Korea1-1 Adobe-Korea1-1 Adobe-Korea1-1
KSCmsUHCHWH/V
— Adobe-Korea1-1 Adobe-Korea1-1 Adobe-Korea1-1
KSCpcEUCH
Adobe-Korea1-0 Adobe-Korea1-0 Adobe-Korea1-0 Adobe-Korea1-0
UniKSUCS2H/V
— Adobe-Korea1-1 Adobe-Korea1-1 Adobe-Korea1-1
UniKSUTF16H/V
— — — Adobe-Korea1-2
Generic
IdentityH/V
Adobe-Identity-0 Adobe-Identity-0 Adobe-Identity-0 Adobe-Identity-0
CMAP PDF 1.2 PDF 1.3 PDF 1.4 PDF 1.5
TextCHAPTER 5
418
As noted in Section 5.6.2, “CIDSystemInfo Dictionaries,” a character collection is
identified by registry, ordering, and supplement number, and supplements are
cumulative; that is, a higher-numbered supplement includes the CIDs contained
in lower-numbered supplements, as well as some additional CIDs. Consequently,
text encoded according to the predefined CMaps for a given PDF version is valid
when interpreted by a consumer application supporting the same or a later PDF
version. When interpreted by an application supporting an earlier PDF version,
such text causes an error if a CMap is encountered that is not predefined for that
PDF version. If character codes are encountered that were added in a higher-
numbered supplement than the one corresponding to the supported PDF ver-
sion, no characters are displayed for those codes; see “Handling Undefined Char-
acters” on page 425. See also implementation note 66 in Appendix H.
Note: If an application producing a PDF file encounters text to be included that
uses CIDs from a higher-numbered supplement than the one corresponding to the
PDF version being generated, the application should embed the CMap for the
higher-numbered supplement rather than refer to the predefined CMap (see the
next section).
The CMap programs that define the predefined CMaps are available through the
ASN Web site and are also provided in conjunction with the book CJKV Informa-
tion Processing by Ken Lunde. Details on the character collections, including sam-
ple glyphs for all the CIDs, can be found in a number of Adobe Technical Notes.
For more information about these Notes and the aforementioned book, see the
Bibliography.
Embedded CMap Files
For character encodings that are not predefined, the PDF file must contain a
stream that defines the CMap. In addition to the standard entries for streams
(listed in Table 3.4 on page 38), the CMap stream dictionary contains the entries
listed in Table 5.17. The data in the stream defines the mapping from character
codes to a font number and a character selector. The data must follow the syntax
defined in Adobe Technical Note #5014, Adobe CMap and CIDFont Files Specifi-
cation.
Composite FontsSECTION 5.6
419
TABLE 5.17 Additional entries in a CMap dictionary
CMap Example and Operator Summary
CMap files are fully documented in Adobe Technical Note #5014, Adobe CMap
and CIDFont Files Specification. The following example of a CMap stream object
illustrates and partially explains the contents of a CMap file. There are several
reasons for including this material here:
• It documents some restrictions on the contents of a CMap file that can be
embedded in a PDF file.
• It provides background to aid in understanding subsequent material, particu-
larly “CMap Mapping” on page 424.
KEY TYPE VALUE
Type name (Required) The type of PDF object that this dictionary describes; must be
CMap for a CMap dictionary. (Although this object is the value of an entry
named
Encoding in a Type 0 font, its type is CMap.)
CMapName name (Required) The PostScript name of the CMap. It should be the same as the
value of
CMapName in the CMap file.
CIDSystemInfo dictionary (Required) A dictionary (see Section 5.6.2, “CIDSystemInfo Dictionaries”)
containing entries that define the character collection for the CIDFont or
CIDFonts associated with the CMap.
The value of this entry should be the same as the value of
CIDSystemInfo in
the CMap file. (However, it does not need to match the values of
CIDSystemInfo for the Identity-H or Identity-V CMaps.)
WMode integer (Optional) A code that determines the writing mode for any CIDFont with
which this CMap is combined. The possible values are 0 for horizontal and 1
for vertical. Default value: 0.
The value of this entry should be the same as the value of
WMode in the
CMap file.
UseCMap name or
stream
(Optional) The name of a predefined CMap, or a stream containing a CMap,
that is to be used as the base for this CMap. This base allows the CMap to be
defined differentially, specifying only the character mappings that differ from
the base CMap.
TextCHAPTER 5
420
• It is the basis for a PDF feature, the ToUnicode CMap, which is a minor exten-
sion of the CMap file format. This extension is described in Section 5.9,
“Extraction of Text Content.”
Example 5.10 is a sample CMap for a Japanese Shift-JIS encoding. Character
codes in this encoding can be either 1 or 2 bytes in length. This CMap could be
used with a CIDFont that uses the same CID ordering as specified in the
CIDSystemInfo entry. Note that several of the entries in the stream dictionary are
also replicated in the stream data.
Example 5.10
22 0 obj
<< /Type /CMap
/CMapName /90msRKSJH
/CIDSystemInfo << /Registry (Adobe)
/Ordering (Japan1)
/Supplement 2
>>
/WMode 0
/Length 23 0 R
>>
stream
%!PSAdobe3.0 ResourceCMap
%%DocumentNeededResources: ProcSet (CIDInit)
%%IncludeResource: ProcSet (CIDInit)
%%BeginResource: CMap (90msRKSJH)
%%Title: (90msRKSJH Adobe Japan1 2)
%%Version: 10.001
%%Copyright: Copyright 19902001 Adobe Systems Inc.
%%Copyright: All Rights Reserved.
%%EndComments
/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo
3 dict dup begin
/Registry (Adobe) def
/Ordering (Japan1) def
/Supplement 2 def
end def
Composite FontsSECTION 5.6
421
/CMapName /90msRKSJHdef
/CMapVersion 10.001 def
/CMapType 1 def
/UIDOffset 950 def
/XUID [1 10 25343] def
/WMode 0 def
4 begincodespacerange
<00> <80>
<8140> <9FFC>
<A0> <DF>
<E040> <FCFC>
endcodespacerange
1 beginnotdefrange
<00> <1F> 231
endnotdefrange
100 begincidrange
<20> <7D> 231
<7E> <7E> 631
<8140> <817E> 633
<8180> <81AC> 696
<81B8> <81BF> 741
<81C8> <81CE> 749
…Additional ranges…
<FB40> <FB7E> 8518
<FB80> <FBFC> 8581
<FC40> <FC4B> 8706
endcidrange
endcmap
CMapName currentdict /CMap defineresource pop
end
end
%%EndResource
%%EOF
endstream
endobj
As can be seen from this example, a CMap file conforms to PostScript language
syntax; however, a full PostScript interpreter is not needed to interpret it. Aside
from some required boilerplate, the CMap file consists of one or more occur-
TextCHAPTER 5
422
rences of several special CMap construction operators, invoked in a specific
order. Following is a summary of these operators:
• begincmap and endcmap enclose the CMap definition.
• usecmap incorporates the code mappings from another CMap file. In PDF, the
other CMap must also be identified in the
UseCMap entry in the CMap dictio-
nary (see Table 5.17 on page 419).
• begincodespacerange and endcodespacerange define codespace ranges—the
valid input character code ranges—by specifying a pair of codes of some partic-
ular length giving the lower and upper bounds of each range; see “CMap Map-
ping” on page 424.
• usefont specifies a font number that is an implicit operand of all the character
code mapping operations that follow. In PDF, the font number must be 0;
therefore,
usefont typically does not actually appear.
• beginbfchar and endbfchar define mappings of individual input character
codes to character codes or character names in the associated font.
beginbfrange and endbfrange do the same for ranges of input codes. In PDF,
these operators may not appear in a CMap that is used as the
Encoding entry of
a Type 0 font; however, they may appear in the definition of a
ToUnicode CMap
(see Section 5.9, “Extraction of Text Content”).
• begincidchar and endcidchar define mappings of individual input character
codes to CIDs in the associated CIDFont.
begincidrange and endcidrange do
the same, but for ranges of input codes.
• beginnotdefchar, endnotdefchar, beginnotdefrange, and endnotdefrange
define notdef mappings from character codes to CIDs. As described in the
section “Handling Undefined Characters” on page 425, a notdef mapping is
used if the normal mapping produces a CID for which no glyph is present in
the associated CIDFont.
The
beginrearrangedfont, endrearrangedfont, beginusematrix, and
endusematrix operators, described in Adobe Technical Note #5014, Adobe CMap
and CIDFont Files Specification, cannot be used in CMap files embedded in a
PDF file.
5.6.5 Type 0 Font Dictionaries
A Type 0 font dictionary contains the entries listed in Table 5.18.
Composite FontsSECTION 5.6
423
Example 5.11 shows a Type 0 font that refers to a single CIDFont. The CMap used
is one of the predefined CMaps listed in Table 5.15 on page 412 and is referenced
by name.
TABLE 5.18 Entries in a Type 0 font dictionary
Example 5.11
14 0 obj
<< /Type /Font
/Subtype /Type0
/BaseFont /HeiseiMinW590msRKSJH
/Encoding /90msRKSJH
/DescendantFonts [15 0 R]
>>
endobj
KEY TYPE VALUE
Type name (Required) The type of PDF object that this dictionary describes; must be
Font for a font dictionary.
Subtype name (Required) The type of font; must be Type0 for a Type 0 font.
BaseFont name (Required) The PostScript name of the font. In principle, this is an arbitrary
name, since there is no font program associated directly with a Type 0 font
dictionary. The conventions described here ensure maximum compatibility
with existing Acrobat products.
If the descendant is a Type 0 CIDFont, this name should be the concatenation
of the CIDFont’s
BaseFont name, a hyphen, and the CMap name given in the
Encoding entry (or the CMapName entry in the CMap). If the descendant is a
Type 2 CIDFont, this name should be the same as the CIDFont’s
BaseFont
name.
Encoding name or
stream
(Required) The name of a predefined CMap, or a stream containing a CMap
that maps character codes to font numbers and CIDs. If the descendant is a
Type 2 CIDFont whose associated TrueType font program is not embedded
in the PDF file, the
Encoding entry must be a predefined CMap name (see
“Glyph Selection in CIDFonts” on page 408).
DescendantFonts array (Required) A one-element array specifying the CIDFont dictionary that is the
descendant of this Type 0 font.
ToUnicode stream (Optional) A stream containing a CMap file that maps character codes to
Unicode values (see Section 5.9, “Extraction of Text Content”).
TextCHAPTER 5
424
CMap Mapping
The Encoding entry of a Type 0 font dictionary specifies a CMap that determines
how text-showing operators (such as
Tj) interpret the bytes in the string to be
shown when the current font is the Type 0 font. The following paragraphs
describe how the characters in the string are decoded and mapped into character
selectors (which in PDF must always be CIDs).
The codespace ranges in the CMap (delimited by
begincodespacerange and
endcodespacerange) determine how many bytes are extracted from the string for
each successive character code. A codespace range is specified by a pair of codes
of some particular length giving the lower and upper bounds of that range. A
code is considered to match the range if it is the same length as the bounding
codes and the value of each of its bytes lies between the corresponding bytes of
the lower and upper bounds. The code length cannot exceed the number of bytes
representable in an integer (see Appendix C).
A sequence of one or more bytes is extracted from the string and matched against
the codespace ranges in the CMap. That is, the first byte is matched against 1-byte
codespace ranges; if no match is found, a second byte is extracted, and the 2-byte
code is matched against 2-byte codespace ranges. This process continues for suc-
cessively longer codes until a match is found or all codespace ranges have been
tested. There will be at most one match because codespace ranges do not overlap.
The code extracted from the string is looked up in the character code mappings
for codes of that length. (These are the mappings defined by
beginbfchar,
endbfchar, begincidchar, endcidchar, and corresponding operators for ranges.)
Failing that, it is looked up in the notdef mappings, as described in the next
section.
The results of the CMap mapping algorithm are a font number and a character
selector. The font number is used as an index into the Type 0 font’s
DescendantFonts array to select a CIDFont. In PDF, the font number is always 0
and the character selector is always a CID; this is the only case described here.
The CID is then used to select a glyph in the CIDFont. If the CIDFont contains
no glyph for that CID, the notdef mappings are consulted, as described in the
next section.
Composite FontsSECTION 5.6
425
Handling Undefined Characters
A CMap mapping operation can fail to select a glyph for a variety of reasons. This
section describes those reasons and what happens when they occur.
If a code maps to a CID for which no such glyph exists in the descendant
CIDFont, the notdef mappings in the CMap are consulted to obtain a substitute
character selector. These mappings (so called by analogy with the
.notdef charac-
ter mechanism in simple fonts) are delimited by the operators
beginnotdefchar,
endnotdefchar, beginnotdefrange, and endnotdefrange. They always map to a
CID. If a matching notdef mapping is found, the CID selects a glyph in the associ-
ated descendant, which must be a CIDFont. If no glyph exists for that CID, the
glyph for CID 0 (which is required to be present) is substituted.
If the CMap does not contain either a character mapping or a notdef mapping for
the code, descendant 0 is selected and the glyph for CID 0 is substituted from the
associated CIDFont.
If the code is invalid—that is, the bytes extracted from the string to be shown do
not match any codespace range in the CMap—a substitute glyph is chosen as just
described. The character mapping algorithm is reset to its original position in the
string, and a modified mapping algorithm chooses the best partially matching
codespace range:
1. If the first byte extracted from the string to be shown does not match the first
byte of any codespace range, the range having the shortest codes is chosen.
2. Otherwise (that is, if there is a partial match), for each additional byte extract-
ed, the code accumulated so far is matched against the beginnings of all longer
codespace ranges until the longest such partial match has been found. If multi-
ple codespace ranges have partial matches of the same length, the one having
the shortest codes is chosen.
The length of the codes in the chosen codespace range determines the total num-
ber of bytes to consume from the string for the current mapping operation.
TextCHAPTER 5
426
5.7 Font Descriptors
A font descriptor specifies metrics and other attributes of a simple font or a
CIDFont as a whole, as distinct from the metrics of individual glyphs. These font
metrics provide information that enables a consumer application to synthesize a
substitute font or select a similar font when the font program is unavailable. The
font descriptor may also be used to embed the font program in the PDF file.
Font descriptors are not used with Type 0 fonts. Beginning with PDF 1.5, font de-
scriptors may be used with Type 3 fonts in Tagged PDF documents (see Section
10.7, “Tagged PDF”).
A font descriptor is a dictionary whose entries specify various font attributes. The
entries common to all font descriptors—for both simple fonts and CIDFonts—are
listed in Table 5.19. Additional entries in the font descriptor for a CIDFont are de-
scribed in Section 5.7.2, “Font Descriptors for CIDFonts.” All integer values are
units in glyph space. The conversion from glyph space to text space is described
in Section 5.1.3, “Glyph Positioning and Metrics.”
TABLE 5.19 Entries common to all font descriptors
KEY TYPE VALUE
Type name (Required) The type of PDF object that this dictionary describes; must be
FontDescriptor for a font descriptor.
FontName name (Required) The PostScript name of the font. This name should be the same as
the value of
BaseFont in the font or CIDFont dictionary that refers to this font
descriptor.
FontFamily
string (Optional; PDF 1.5; strongly recommended for Type 3 fonts in Tagged PDF doc-
uments) A string specifying the preferred font family name. For example, for
the font Times Bold Italic, the
FontFamily is Times.
FontStretch
name (Optional; PDF 1.5; strongly recommended for Type 3 fonts in Tagged PDF doc-
uments) The font stretch value. It must be one of the following names (or-
dered from narrowest to widest):
UltraCondensed, ExtraCondensed,
Condensed, SemiCondensed, Normal, SemiExpanded, Expanded, ExtraExpand-
ed
or UltraExpanded.
Note: The specific interpretation of these values varies from font to font. For ex-
ample,
Condensed in one font may appear most similar to Normal in another.
Font DescriptorsSECTION 5.7
427
FontWeight
number (Optional; PDF 1.5; strongly recommended for Type 3 fonts in Tagged PDF doc-
uments) The weight (thickness) component of the fully-qualified font name
or font specifier. The possible values are 100, 200, 300, 400, 500, 600, 700,
800, or 900, where each number indicates a weight that is at least as dark as its
predecessor. A value of 400 indicates a normal weight; 700 indicates bold.
Note: The specific interpretation of these values varies from font to font. For ex-
ample, 300 in one font may appear most similar to 500 in another.
Flags integer (Required) A collection of flags defining various characteristics of the font
(see Section 5.7.1, “Font Descriptor Flags”).
FontBBox rectangle (Required, except for Type 3 fonts) A rectangle (see Section 3.8.4, “Rectan-
gles”), expressed in the glyph coordinate system, specifying the font bounding
box. This is the smallest rectangle enclosing the shape that would result if all
of the glyphs of the font were placed with their origins coincident and then
filled.
ItalicAngle number (Required) The angle, expressed in degrees counterclockwise from the verti-
cal, of the dominant vertical strokes of the font. (For example, the 9-o’clock
position is 90 degrees, and the 3-o’clock position is –90 degrees.) The value is
negative for fonts that slope to the right, as almost all italic fonts do.
Ascent number (Required, except for Type 3 fonts) The maximum height above the baseline
reached by glyphs in this font, excluding the height of glyphs for accented
characters.
Descent number (Required, except for Type 3 fonts) The maximum depth below the baseline
reached by glyphs in this font. The value is a negative number.
Leading number (Optional) The spacing between baselines of consecutive lines of text. Default
value: 0.
CapHeight number (Required for fonts that have Latin characters, except for Type 3 fonts) The ver-
tical coordinate of the top of flat capital letters, measured from the baseline.
XHeight number (Optional) The font’s x height: the vertical coordinate of the top of flat non-
ascending lowercase letters (like the letter x), measured from the baseline, in
fonts that have Latin characters. Default value: 0.
StemV number (Required, except for Type 3 fonts) The thickness, measured horizontally, of
the dominant vertical stems of glyphs in the font.
StemH number (Optional) The thickness, measured vertically, of the dominant horizontal
stems of glyphs in the font. Default value: 0.
KEY TYPE VALUE
TextCHAPTER 5
428
AvgWidth number (Optional) The average width of glyphs in the font. Default value: 0.
MaxWidth number (Optional) The maximum width of glyphs in the font. Default value: 0.
MissingWidth number (Optional) The width to use for character codes whose widths are not speci-
fied in a font dictionary’s
Widths array. This has a predictable effect only if all
such codes map to glyphs whose actual widths are the same as the value of the
MissingWidth entry. Default value: 0.
FontFile stream (Optional) A stream containing a Type 1 font program (see Section 5.8,
“Embedded Font Programs”).
FontFile2 stream (Optional; PDF 1.1) A stream containing a TrueType font program (see Sec-
tion 5.8, “Embedded Font Programs”).
FontFile3 stream (Optional; PDF 1.2) A stream containing a font program whose format is
specified by the
Subtype entry in the stream dictionary (see Table 5.23 and
implementation note 67 in Appendix H).
At most, only one of the
FontFile, FontFile2, and FontFile3 entries may be
present.
CharSet string (Optional; meaningful only in Type 1 fonts; PDF 1.1) A string listing the char-
acter names defined in a font subset. The names in this string must be in PDF
syntax—that is, each name preceded by a slash (
/). The names can appear in
any order. The name
.notdef should be omitted; it is assumed to exist in the
font subset. If this entry is absent, the only indication of a font subset is the
subset tag in the
FontName entry (see Section 5.5.3, “Font Subsets”).
KEY TYPE VALUE
Font DescriptorsSECTION 5.7
429
5.7.1 Font Descriptor Flags
The value of the Flags entry in a font descriptor is an unsigned 32-bit integer con-
taining flags specifying various characteristics of the font. Bit positions within the
flag word are numbered from 1 (low-order) to 32 (high-order). Table 5.20 shows
the meanings of the flags; all undefined flag bits are reserved and must be set to 0.
Figure 5.13 shows examples of fonts with these characteristics.
TABLE 5.20 Font flags
The Nonsymbolic flag (bit 6 in the Flags entry) indicates that the font’s character
set is the Adobe standard Latin character set (or a subset of it) and that it uses the
standard names for those glyphs. This character set is shown in Section D.1, “Lat-
in Character Set and Encodings.” If the font contains any glyphs outside this set,
the Symbolic flag should be set and the Nonsymbolic flag clear. In other words,
any font whose character set is not a subset of the Adobe standard character set is
BIT POSITION NAME MEANING
1 FixedPitch All glyphs have the same width (as opposed to proportional or variable-pitch
fonts, which have different widths).
2 Serif Glyphs have serifs, which are short strokes drawn at an angle on the top and
bottom of glyph stems. ( Sans serif fonts do not have serifs.)
3 Symbolic Font contains glyphs outside the Adobe standard Latin character set. This
flag and the Nonsymbolic flag cannot both be set or both be clear (see below).
4 Script Glyphs resemble cursive handwriting.
6 Nonsymbolic Font uses the Adobe standard Latin character set or a subset of it (see below).
7 Italic Glyphs have dominant vertical strokes that are slanted.
17 AllCap Font contains no lowercase letters; typically used for display purposes, such
as for titles or headlines.
18 SmallCap Font contains both uppercase and lowercase letters. The uppercase letters are
similar to those in the regular version of the same typeface family. The glyphs
for the lowercase letters have the same shapes as the corresponding uppercase
letters, but they are sized and their proportions adjusted so that they have the
same size and stroke weight as lowercase glyphs in the same typeface family.
19 ForceBold See below.
TextCHAPTER 5
430
considered to be symbolic. This influences the font’s implicit base encoding and
may affect a consumer application’s font substitution strategies.
FIGURE 5.13 Characteristics represented in the Flags entry of a font descriptor
Note: This classification of nonsymbolic and symbolic fonts is peculiar to PDF. A
font may contain additional characters that are used in Latin writing systems but
are outside the Adobe standard Latin character set; PDF considers such a font to
be symbolic. The use of two flags to represent a single binary choice is a historical
accident.
The ForceBold flag (bit 19) determines whether bold glyphs are painted with
extra pixels even at very small text sizes. Typically, when glyphs are painted at
small sizes on very low-resolution devices such as display screens, features of bold
glyphs may appear only 1 pixel wide. Because this is the minimum feature width
on a pixel-based device, ordinary (nonbold) glyphs also appear with 1-pixel-wide
features and therefore cannot be distinguished from bold glyphs. If the ForceBold
flag is set, features of bold glyphs may be thickened at small text sizes.
Example 5.12 illustrates a font descriptor whose
Flags entry has the Serif,
Nonsymbolic, and ForceBold flags (bits 2, 6, and 19) set.
The quick brown fox jumped.
The quick brown fox jumped.
The quick brown fox jumped.
✴❈❅ ❑◆❉❃❋ ❂❒❏◗■ ❆❏❘ ❊◆❍❐❅❄✎
The quick brown fox jumped.
The quick brown fox jumped.
The quick brown fox jumped
The quick brown fox jumped.
Fixed-pitch font
Serif font
Sans serif font
Symbolic font
Script font
Italic font
All-cap font
Small-cap font
Font DescriptorsSECTION 5.7
431
Example 5.12
7 0 obj
<< /Type /FontDescriptor
/FontName /AGaramondSemibold
/Flags 262178 % Bits 2, 6, and 19
/FontBBox [177 269 1123 866]
/MissingWidth 255
/StemV 105
/StemH 45
/CapHeight 660
/XHeight 394
/Ascent 720
/Descent 270
/Leading 83
/MaxWidth 1212
/AvgWidth 478
/ItalicAngle 0
>>
endobj
5.7.2 Font Descriptors for CIDFonts
In addition to the entries in Table 5.19 on page 426, the FontDescriptor dictionar-
ies of CIDFonts may contain the entries listed in Table 5.21.
TABLE 5.21 Additional font descriptor entries for CIDFonts
KEY TYPE VALUE
Style dictionary (Optional) A dictionary containing entries that describe the style of the glyphs in
the font (see “Style” on page 432).
Lang name (Optional) A name specifying the language of the font, used for encodings where
the language is not implied by the encoding itself. The possible values are the codes
defined by Internet RFC 3066, Tags for the Identification of Languages (see the Bibli-
ography). If this entry is absent, the language is considered to be unknown.
Note: This specification for the allowable language codes is introduced in PDF 1.5.
Prior versions supported a subset: the 2-character language codes defined by ISO 639
(see the Bibliography).
TextCHAPTER 5
432
Style
The Style dictionary contains entries that define style attributes and values for the
CIDFont. Currently, only the
Panose entry is defined. The value of Panose is a
12-byte string consisting of the following elements:
• The font family class and subclass ID bytes, given in the sFamilyClass field of the
“OS/2” table in a TrueType font. This field is documented in Microsoft’s True-
Type 1.0 Font Files Technical Specification.
• Ten bytes for the PANOSE classification number for the font. The PANOSE
classification system is documented in Hewlett-Packard Company’s PANOSE
Classification Metrics Guide.
See the Bibliography for more information about these documents.
The following is an example of a
Style entry in the font descriptor:
/Style << /Panose <01 05 02 02 03 00 00 00 00 00 00 00> >>
FD
A CIDFont may be made up of different classes of glyphs, each class requiring
different sets of the font-wide attributes that appear in font descriptors. Latin
glyphs, for example, may require different attributes than kanji glyphs. The font
FD dictionary (Optional) A dictionary whose keys identify a class of glyphs in a CIDFont. Each
value is a dictionary containing entries that override the corresponding values in
the main font descriptor dictionary for that class of glyphs (see “FD” on page 432).
CIDSet stream (Optional) A stream identifying which CIDs are present in the CIDFont file. If this
entry is present, the CIDFont contains only a subset of the glyphs in the character
collection defined by the
CIDSystemInfo dictionary. If it is absent, the only indica-
tion of a CIDFont subset is the subset tag in the
FontName entry (see Section 5.5.3,
“Font Subsets”).
The stream’s data is organized as a table of bits indexed by CID. The bits should be
stored in bytes with the high-order bit first. Each bit corresponds to a CID. The
most significant bit of the first byte corresponds to CID 0, the next bit to CID 1, and
so on.
KEY TYPE VALUE
Font DescriptorsSECTION 5.7
433
descriptor defines a set of default attributes that apply to all glyphs in the
CIDFont. The
FD entry in the font descriptor contains exceptions to these de-
faults.
The key for each entry in an
FD dictionary is the name of a class of glyphs—that
is, a particular subset of the CIDFont’s character collection. The entry’s value is a
font descriptor whose contents are to override the font-wide attributes for that
class only. This font descriptor should contain entries for metric information
only; it should not include
FontFile, FontFile2, FontFile3, or any of the entries list-
ed in Table 5.21.
It is strongly recommended that the
FD dictionary contain at least the metrics for
the proportional Latin glyphs. With the information for these glyphs, a more ac-
curate substitution font can be created.
The names of the glyph classes depend on the character collection, as identified
by the
Registry, Ordering, and Supplement entries in the CIDSystemInfo
dictionary. Table 5.22 lists the valid keys for the Adobe-GB1, Adobe-CNS1, Ado-
be-Japan1, Adobe-Japan2, and Adobe-Korea1 character collections.
TABLE 5.22 Glyph classes in CJK fonts
CHARACTER COLLECTION CLASS GLYPHS IN CLASS
Adobe-GB1
Alphabetic
Dingbats
Generic
Hanzi
HRoman
HRomanRot
Kana
Proportional
ProportionalRot
Full-width Latin, Greek, and Cyrillic glyphs
Special symbols
Typeface-independent glyphs, such as line-drawing
Full-width hanzi (Chinese) glyphs
Half-width Latin glyphs
Same as
HRoman but rotated for use in vertical writing
Japanese kana (katakana and hiragana) glyphs
Proportional Latin glyphs
Same as
Proportional but rotated for use in vertical writing
Adobe-CNS1
Alphabetic
Dingbats
Generic
Hanzi
HRoman
HRomanRot
Kana
Proportional
ProportionalRot
Full-width Latin, Greek, and Cyrillic glyphs
Special symbols
Typeface-independent glyphs, such as line-drawing
Full-width hanzi (Chinese) glyphs
Half-width Latin glyphs
Same as
HRoman but rotated for use in vertical writing
Japanese kana (katakana and hiragana) glyphs
Proportional Latin glyphs
Same as
Proportional but rotated for use in vertical writing
TextCHAPTER 5
434
Adobe-Japan1
Alphabetic
AlphaNum
Dingbats
DingbatsRot
Generic
GenericRot
HKana
HKanaRot
HRoman
HRomanRot
Kana
Kanji
Proportional
ProportionalRot
Ruby
Full-width Latin, Greek, and Cyrillic glyphs
Numeric glyphs
Special symbols
Same as
Dingbats but rotated for use in vertical writing
Typeface-independent glyphs, such as line-drawing
Same as
Generic but rotated for use in vertical writing
Half-width kana (katakana and hiragana) glyphs
Same as
HKana but rotated for use in vertical writing
Half-width Latin glyphs
Same as
HRoman but rotated for use in vertical writing
Full-width kana (katakana and hiragana) glyphs
Full-width kanji (Chinese) glyphs
Proportional Latin glyphs
Same as
Proportional but rotated for use in vertical writing
Glyphs used for setting ruby (small glyphs that serve to annotate
other glyphs with meanings or readings)
Adobe-Japan2
Alphabetic
Dingbats
HojoKanji
Full-width Latin, Greek, and Cyrillic glyphs
Special symbols
Full-width kanji glyphs
Adobe-Korea1
Alphabetic
Dingbats
Generic
Hangul
Hanja
HRoman
HRomanRot
Kana
Proportional
ProportionalRot
Full-width Latin, Greek, and Cyrillic glyphs
Special symbols
Typeface-independent glyphs, such as line-drawing
Hangul and jamo glyphs
Full-width hanja (Chinese) glyphs
Half-width Latin glyphs
Same as
HRoman but rotated for use in vertical writing
Japanese kana (katakana and hiragana) glyphs
Proportional Latin glyphs
Same as
Proportional but rotated for use in vertical writing
CHARACTER COLLECTION CLASS GLYPHS IN CLASS
Font DescriptorsSECTION 5.7
435
Example 5.13 illustrates an FD dictionary containing two entries.
Example 5.13
/FD << /Proportional 25 0 R
/HKana 26 0 R
>>
25 0 obj
<< /Type /FontDescriptor
/FontName /HeiseiMinW3Proportional
/Flags 2
/AvgWidth 478
/MaxWidth 1212
/MissingWidth 250
/StemV 105
/StemH 45
/CapHeight 660
/XHeight 394
/Ascent 720
/Descent 270
/Leading 83
>>
endobj
26 0 obj
<< /Type /FontDescriptor
/FontName /HeiseiMinW3HKana
/Flags 3
/AvgWidth 500
/MaxWidth 500
/MissingWidth 500
/StemV 50
/StemH 75
/Ascent 720
/Descent 0
/Leading 83
>>
endobj
TextCHAPTER 5
436
5.8 Embedded Font Programs
A font program can be embedded in a PDF file as data contained in a PDF stream
object. Such a stream object is also called a font file by analogy with font programs
that are available from sources external to the consumer application. (See also
implementation note 68 in Appendix H.)
Font programs are subject to copyright, and the copyright owner may impose
conditions under which a font program can be used. These permissions are re-
corded either in the font program or as part of a separate license. One of the con-
ditions may be that the font program cannot be embedded, in which case it
should not be incorporated into a PDF file. A font program may allow embedding
for the sole purpose of viewing and printing the document but not for creating
new or modified text that uses the font (in either the same document or other
documents). The latter operation would require the user performing the opera-
tion to have a licensed copy of the font program, not a copy extracted from the
PDF file. In the absence of explicit information to the contrary, a PDF consumer
should assume that any embedded font programs are to be used only to view and
print the document and not for any other purposes.
Table 5.23 summarizes the ways in which font programs are embedded in a PDF
file, depending on the representation of the font program. The key is the name
used in the font descriptor to refer to the font file stream; the subtype is the value
of the
Subtype key, if present, in the font file stream dictionary. Further details of
specific font program representations are given below.
TABLE 5.23 Embedded font organization for various font types
KEY SUBTYPE DESCRIPTION
FontFile — Type 1 font program, in the original (noncompact) format described in
Adobe Type 1 Font Format. This entry can appear in the font descriptor for
a
Type1 or MMType1 font dictionary.
FontFile2 — (PDF 1.1) TrueType font program, as described in the TrueType Reference
Manual. This entry can appear in the font descriptor for a
TrueType font
dictionary or (in PDF 1.3) for a
CIDFontType2 CIDFont dictionary.
FontFile3
Type1C
(PDF 1.2) Type 1–equivalent font program represented in the Compact
Font Format (CFF), as described in Adobe Technical Note #5176, The
Compact Font Format Specification. This entry can appear in the font de-
scriptor for a
Type1 or MMType1 font dictionary.
Embedded Font ProgramsSECTION 5.8
437
The stream dictionary for a font file contains the normal entries for a stream,
such as
Length and Filter (listed in Table 3.4 on page 38), plus the additional
entries listed in Table 5.24.
TABLE 5.24 Additional entries in an embedded font stream dictionary
CIDFontType0C
(PDF 1.3) Type 0 CIDFont program represented in the Compact Font For-
mat (CFF), as described in Adobe Technical Note #5176, The Compact
Font Format Specification. This entry can appear in the font descriptor for
a
CIDFontType0 CIDFont dictionary.
OpenType
(PDF 1.6) OpenType font program, as described in the OpenType Font
Specification (see the Bibliography). OpenType is an extension of True-
Type that allows inclusion of font programs that use the Compact Font
Format (CFF).
This entry can appear in the font descriptor for the following types of font
dictionaries:
• A TrueType font dictionary or a CIDFontType2 CIDFont dictionary, if
the embedded font program contains a “glyf” table.
• A CIDFontType0 CIDFont dictionary, if the embedded font program
contains a “CFF” table with a
Top DICT that uses CIDFont operators
(this is equivalent to subtype
CIDFontType0C above).
• A Type1 font dictionary or CIDFontType0 CIDFont dictionary, if the
embedded font program contains a “CFF” table without CIDFont oper-
ators.
KEY TYPE VALUE
Length1 integer (Required for Type 1 and TrueType fonts) The length in bytes of the clear-text portion
of the Type 1 font program (see below), or the entire TrueType font program, after it
has been decoded using the filters specified by the stream’s
Filter entry, if any.
Length2 integer (Required for Type 1 fonts) The length in bytes of the encrypted portion of the Type 1
font program (see below) after it has been decoded using the filters specified by the
stream’s
Filter entry.
Length3 integer (Required for Type 1 fonts) The length in bytes of the fixed-content portion of the
Type 1 font program (see below) after it has been decoded using the filters specified
by the stream’s
Filter entry. If Length3 is 0, it indicates that the 512 zeros and
cleartomark have not been included in the FontFile font program and must be added.
KEY SUBTYPE DESCRIPTION
TextCHAPTER 5
438
A standard Type 1 font program, as described in the Adobe Type 1 Font Format
specification, consists of three parts: a clear-text portion (written using PostScript
syntax), an encrypted portion, and a fixed-content portion. The fixed-content
portion contains 512 ASCII zeros followed by a
cleartomark operator, and per-
haps followed by additional data. Although the encrypted portion of a standard
Type 1 font may be in binary or ASCII hexadecimal format, PDF supports only
the binary format. However, the entire font program may be encoded using any
filters.
Example 5.14 shows the structure of an embedded standard Type 1 font.
Example 5.14
12 0 obj
<< /Filter /ASCII85Decode
/Length 41116
/Length1 2526
/Length2 32393
/Length3 570
>>
stream
,p>`rDKJj'E+LaU0eP.@+AH9dBOu$hFD55nC
…Omitted data…
JJQ&Nt')<=^p&mGf(%:%h1%9c//K(/*o=.C>UXkbVGTrr~>
endstream
endobj
As noted in Table 5.23, a Type 1–equivalent font program or a Type 0 CIDFont
program can be represented in the Compact Font Format (CFF). The
Length1,
Length2, and Length3 entries are not needed in that case. Although CFF enables
multiple font or CIDFont programs to be bundled together in a single file, an em-
Subtype name (Required if referenced from FontFile3; PDF 1.2) A name specifying the format of the
embedded font program. The name must be
Type1C for Type 1 compact fonts,
CIDFontType0C for Type 0 compact CIDFonts, or OpenType for OpenType fonts.
When additional font formats are added to PDF, more values will be defined for
Subtype.
Metadata stream (Optional; PDF 1.4) A metadata stream containing metadata for the embedded font
program (see Section 10.2.2, “Metadata Streams”).
KEY TYPE VALUE
Embedded Font ProgramsSECTION 5.8
439
bedded CFF font file in PDF must consist of exactly one font or CIDFont (as ap-
propriate for the associated font dictionary).
Note: According to the Adobe Type 1 Font Format specification, a Type 1 font pro-
gram may contain a
PaintType entry specifying whether the glyphs’ outlines are to
be filled or stroked. For fonts embedded in a PDF file, this entry is ignored; the deci-
sion whether to fill or stroke glyph outlines is entirely determined by the PDF text
rendering mode parameter (see Section 5.2.5, “Text Rendering Mode”). This also
applies to Type 1 compact fonts and Type 0 compact CIDFonts.
A TrueType font program may be used as part of either a font or a CIDFont.
Although the basic font file format is the same in both cases, there are different
requirements for what information must be present in the font program. The fol-
lowing TrueType tables are always required: “head,” “hhea,” “loca,” “maxp,” “cvt ,”
“prep,” “glyf,” “hmtx,” and “fpgm.” If used with a simple font dictionary, the font
program must additionally contain a “cmap” table defining one or more encod-
ings, as discussed in “Encodings for TrueType Fonts” on page 399. If used with a
CIDFont dictionary, the “cmap” table is not needed, since the mapping from char-
acter codes to glyph descriptions is provided separately.
Note: The “vhea” and “vmtx” tables that specify vertical metrics are never used by a
PDF consumer application. The only way to specify vertical metrics in PDF is by
means of the
DW2 and W2 entries in a CIDFont dictionary.
Beginning with PDF 1.6, font programs may be embedded using the OpenType
format, which is an extension of the TrueType format that allows inclusion of font
programs using the Compact Font Format (CFF). It also allows inclusion of data
to describe glyph substitutions, kerning, and baseline adjustments. In addition to
rendering glyphs, applications can use the data in OpenType fonts to do ad-
vanced line layout, automatically substitute ligatures, provide selections of alter-
nate glyphs to users, and handle complicated writing scripts.
Like TrueType, OpenType font programs contain a number of tables, as defined
in the OpenType Font Specification (see the Bibliography). For OpenType fonts
based on TrueType, the “glyf” table contains the glyph descriptions. For Open-
Type fonts based on CFF, the “CFF” table is a complete font program containing
the glyph descriptions. These tables, as well as the “cmap” table, are required to be
present when embedding fonts. In addition, for OpenType fonts based on True-
Type, the “head,” “hhea,” “loca,” “maxp,” “cvt ,” “prep,” “hmtx,” and “fpgm” tables
are required.
TextCHAPTER 5
440
Note: Other tables, such as those used for advanced line layout, need not be present;
however, their absence may prevent editing of text containing the font.
The process of finding glyph descriptions in OpenType fonts is the following:
• For Type 1 fonts using “CFF” tables, the process is as described in “Encodings
for Type 1 Fonts” on page 398.
• For TrueType fonts using “glyf” tables, the process is as described in “Encod-
ings for TrueType Fonts” on page 399. Since this process sometimes produces
ambiguous results, it is strongly recommended that PDF creators, instead of us-
ing a simple font, use a Type 0 font with an
Identity-H encoding and use the
glyph indices as character codes, as described following Table 5.15 on page 412.
• For CIDFontType0 fonts using “CFF” tables, the process is as described in the
discussion of embedded Type 0 CIDFonts in “Glyph Selection in CIDFonts” on
page 408.
• For CIDFontType2 fonts using “glyf” tables, the process is as described in the
discussion of embedded Type 2 CIDFonts in “Glyph Selection in CIDFonts” on
page 408.
As discussed in Section 5.5.3, “Font Subsets,” an embedded font program may
contain only the subset of glyphs that are used in the PDF document. This may be
indicated by the presence of a
CharSet or CIDSet entry in the font descriptor that
refers to the font file, although subset fonts are not always so identified.
5.9 Extraction of Text Content
The preceding sections describe all the facilities for showing text and causing
glyphs to be painted on the page. In addition to displaying text, consumer appli-
cations sometimes need to determine the information content of text—that is, its
meaning according to some standard character identification as opposed to its
rendered appearance. This need arises during operations such as searching, in-
dexing, and exporting of text to other applications.
The Unicode standard defines a system for numbering all of the common charac-
ters used in a large number of languages. It is a suitable scheme for representing
the information content of text, but not its appearance, since Unicode values
identify characters, not glyphs. For information about Unicode, see the Unicode
Standard by the Unicode Consortium (see the Bibliography).
Extraction of Text ContentSECTION 5.9
441
When extracting character content, a consumer application can easily convert
text to Unicode values if a font’s characters are identified according to a standard
character set that is known to the application. This character identification can
occur if either the font uses a standard named encoding or the characters in the
font are identified by standard character names or CIDs in a well-known collec-
tion. Section 5.9.1, “Mapping Character Codes to Unicode Values,” describes in
detail the overall algorithm for mapping character codes to Unicode values.
If a font is not defined in one of these ways, the glyphs can still be shown, but the
characters cannot be converted to Unicode values without additional informa-
tion:
• This information can be provided as an optional ToUnicode entry in the font
dictionary (PDF 1.2; see Section 5.9.2, “ToUnicode CMaps”), whose value is a
stream object containing a special kind of CMap file that maps character codes
to Unicode values.
• An ActualText entry for a structure element or marked-content sequence (see
Section 10.8.3, “Replacement Text”) can be used to specify the text content di-
rectly.
5.9.1 Mapping Character Codes to Unicode Values
A consumer application can use the following methods, in the priority given, to
map a character code to a Unicode value. Tagged PDF documents, in particular,
must provide at least one of these methods (see “Unicode Mapping in Tagged
PDF” on page 820):
• If the font dictionary contains a ToUnicode CMap (see Section 5.9.2,
“ToUnicode CMaps”), use that CMap to convert the character code to Unicode.
• If the font is a simple font that uses one of the predefined encodings
MacRomanEncoding, MacExpertEncoding, or WinAnsiEncoding, or that has an
encoding whose
Differences array includes only character names taken from
the Adobe standard Latin character set and the set of named characters in the
Symbol font (see Appendix D):
1. Map the character code to a character name according to Table D.1 on
page 924 and the font’s
Differences array.
2. Look up the character name in the Adobe Glyph List (see the Bibliography)
to obtain the corresponding Unicode value.
TextCHAPTER 5
442
• If the font is a composite font that uses one of the predefined CMaps listed in
Table 5.15 on page 412 (except
Identity–H and Identity–V) or whose descendant
CIDFont uses the Adobe-GB1, Adobe-CNS1, Adobe-Japan1, or Adobe-Korea1
character collection:
1. Map the character code to a character identifier (CID) according to the
font’s CMap.
2. Obtain the registry and ordering of the character collection used by the
font’s CMap (for example,
Adobe and Japan1) from its CIDSystemInfo dic-
tionary.
3. Construct a second CMap name by concatenating the registry and order-
ing obtained in step 2 in the format
registry–ordering–UCS2 (for example,
Adobe–Japan1–UCS2).
4. Obtain the CMap with the name constructed in step 3 (available from the
ASN Web site; see the Bibliography).
5. Map the CID obtained in step 1 according to the CMap obtained in step 4,
producing a Unicode value.
Note: Type 0 fonts whose descendant CIDFonts use the Adobe-GB1, Adobe-CNS1,
Adobe-Japan1, or Adobe-Korea1 character collection (as specified in the
CIDSystemInfo dictionary) must have a supplement number corresponding to the
version of PDF supported by the application. See Table 5.16 on page 416 for a list of
the character collections corresponding to a given PDF version. (Other supplements
of these character collections can be used, but if the supplement is higher-numbered
than the one corresponding to the supported PDF version, only the CIDs in the latter
supplement are considered to be standard CIDs.)
If these methods fail to produce a Unicode value, there is no way to determine
what the character code represents.
5.9.2 ToUnicode CMaps
The CMap defined in the ToUnicode entry of the font dictionary must follow the
syntax for CMaps introduced in Section 5.6.4, “CMaps” and fully documented in
Adobe Technical Note #5014, Adobe CMap and CIDFont Files Specification. Addi-
tional guidance regarding the CMap defined in this entry is provided in Adobe
Extraction of Text ContentSECTION 5.9
443
Technical Note #5411, ToUnicode Mapping File Tutorial. This CMap differs from
an ordinary one in the following ways:
• The only pertinent entry in the CMap stream dictionary (see Table 5.17 on
page 419) is
UseCMap, which may be used if the CMap is based on another
ToUnicode CMap.
• The CMap file must contain begincodespacerange and endcodespacerange
operators that are consistent with the encoding that the font uses. In particular,
for a simple font, the codespace must be one byte long.
• It must use the beginbfchar, endbfchar, beginbfrange, and endbfrange opera-
tors to define the mapping from character codes to Unicode character sequenc-
es expressed in UTF-16BE encoding.
Example 5.15 illustrates a Type 0 font that uses the
IdentityH CMap to map from
character codes to CIDs and whose descendant CIDFont uses the
Identity map-
ping from CIDs to TrueType glyph indices. Text strings shown using this font
simply use a 2-byte glyph index for each glyph. In the absence of a
ToUnicode en-
try, no information would be available about what the glyphs mean.
Example 5.15
14 0 obj
<< /Type /Font
/Subtype /Type0
/BaseFont /RyuminLight
/Encoding /IdentityH
/DescendantFonts [15 0 R]
/ToUnicode 16 0 R
>>
endobj
15 0 obj
<< /Type /Font
/Subtype /CIDFontType2
/BaseFont /RyuminLight
/CIDSystemInfo 17 0 R
/FontDescriptor 18 0 R
/CIDToGIDMap /Identity
>>
endobj
TextCHAPTER 5
444
The value of the ToUnicode entry is a stream object that contains the definition of
the CMap, as shown in Example 5.16.
Example 5.16
16 0 obj
<< /Length 433 >>
stream
/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo
<< /Registry (Adobe)
/Ordering (UCS)
/Supplement 0
>> def
/CMapName /AdobeIdentityUCS def
/CMapType 2 def
1 begincodespacerange
<0000> <FFFF>
endcodespacerange
2 beginbfrange
<0000> <005E> <0020>
<005F> <0061> [<00660066> <00660069> <00660066006C>]
endbfrange
1 beginbfchar
<3A51> <D840DC3E>
endbfchar
endcmap
CMapName currentdict /CMap defineresource pop
end
end
endstream
endobj
The begincodespacerange and endcodespacerange operators in Example 5.16
define the source character code range to be the 2-byte character codes from
<00 00> to <FF FF>. The specific mappings for several of the character codes are
shown. For example,
<00 00> to <00 5E> are mapped to the Unicode values
U+0020 to U+007E (where Unicode values are conventionally written as U+ fol-
Extraction of Text ContentSECTION 5.9
445
lowed by four to six hexadecimal digits). This is followed by the definition of a
mapping where each character code represents more than one Unicode value:
<005F> <0061> [<00660066> <00660069> <00660066006C >]
In this case, the original character codes are the glyph indices for the ligatures ff,
fi, and ffl. The entry defines the mapping from the character codes <00 5F>,
<00 60>, and <00 61> to the strings of Unicode values with a Unicode scalar val-
ue for each character in the ligature:
U+0066 U+0066 are the Unicode values for
the character sequence
f f, U+0066 U+0069 for f i, and U+0066 U+0066 U+006c for
f f l.
Finally, the character code
<3A 51> is mapped to the Unicode value U+2003E,
which is expressed by the byte sequence
<D840DC3E> in UTF-16BE encoding.
Example 5.16 illustrates several extensions to the way destination values can be
defined. To support mappings from a source code to a string of destination codes,
the following extension has been made to the ranges defined after a
beginbfchar
operator:
n beginbfchar
srcCode dstString
endbfchar
where dstString can be a string of up to 512 bytes. Likewise, mappings after the
beginbfrange operator may be defined as
n beginbfrange
srcCode
1
srcCode
2
dstString
endbfrange
In this case, the last byte of the string is incremented for each consecutive code in
the source code range. When defining ranges of this type, care must be taken to
ensure that the value of the last byte in the string is less than or equal to
255 (
srcCode
2
srcCode
1
). This ensures that the last byte of the string is not in-
cremented past 255; otherwise, the result of mapping is undefined and an error
occurs.
To support more compact representations of mappings from a range of source
character codes to a discontiguous range of destination codes, the CMaps used
TextCHAPTER 5
446
for the ToUnicode entry may use the following syntax for the mappings following
a
beginbfrange definition:
n beginbfrange
srcCode
1
srcCode
n
[dstString
1
dstString
2
… dstString
n
]
endbfrange
Consecutive codes starting with srcCode
1
and ending with srcCode
n
are mapped to
the destination strings in the array starting with
dstString
1
and ending with
dstString
n
.
447
CHAPTER 6
6Rendering
The Adobe imaging model separates graphics (the specification of shapes and col-
ors) from rendering (controlling a raster output device). Figures 4.12 and 4.13 on
pages 208 and 209 illustrate this division. Chapter 4 describes the facilities for
specifying the appearance of pages in a device-independent way. This chapter de-
scribes the facilities for controlling how shapes and colors are rendered on the
raster output device. All of the facilities discussed here depend on the specific
characteristics of the output device. PDF documents that are intended to be de-
vice-independent should limit themselves to the general graphics facilities de-
scribed in Chapter 4.
Nearly all of the rendering facilities that are under the control of a PDF document
pertain to the reproduction of color. Colors are rendered by a multiple-step pro-
cess outlined below. (Depending on the current color space and on the character-
istics of the device, it is not always necessary to perform every step.)
1. If a color has been specified in a CIE-based color space (see Section 4.5.4,
“CIE-Based Color Spaces”), it must first be transformed to the native color
space of the raster output device (also called its process color model).
2. If a color has been specified in a device color space that is inappropriate for the
output device (for example, RGB color with a CMYK or grayscale device), a
color conversion function is invoked.
3. The device color values are now mapped through transfer functions, one for
each color component. The transfer functions compensate for peculiarities of
the output device, such as nonlinear gray-level response. This step is some-
times called gamma correction.
4. If the device cannot reproduce continuous tones, but only certain discrete
colors such as black and white pixels, a halftone function is invoked, which
approximates the desired colors by means of patterns of pixels.
RenderingCHAPTER 6
448
5. Finally, scan conversion is performed to mark the appropriate pixels of the ras-
ter output device with the requested colors.
Once these operations have been performed for all graphics objects on the page,
the resulting raster data is used to mark the physical output medium, such as
pixels on a display or ink on a printed page. A PDF document specifies very little
about the properties of the physical medium on which the output will be pro-
duced; that information is obtained from the following sources:
• The media box and a few other entries in the page dictionary (see Section
10.10.1, “Page Boundaries”).
• An interactive dialog conducted when the user requests viewing or printing.
• A job ticket, either embedded in the PDF file or provided separately, specifying
detailed instructions for imposing PDF pages onto media and for controlling
special features of the output device. Various standards exist for the format of
job tickets. Two of them, JDF (Job Definition Format) and PJTF (Portable Job
Ticket Format), are described in the CIP4 document JDF Specification and in
Adobe Technical Note #5620, Portable Job Ticket Format (see the Bibliography).
Some of the rendering facilities described in this chapter are controlled by device-
dependent graphics state parameters, listed in Table 4.3 on page 182. These pa-
rameters can be changed by invoking the
gs operator with a parameter dictionary
containing entries shown in Table 4.8 on page 190.
6.1 CIE-Based Color to Device Color
To render CIE-based colors on an output device, the consumer application must
convert from the specified CIE-based color space to the device’s native color
space (typically
DeviceGray, DeviceRGB, or DeviceCMYK), taking into account the
known properties of the device. As discussed in Section 4.5.4, “CIE-Based Color
Spaces,” CIE-based color is based on a model of human color perception. The
goal of CIE-based color rendering is to produce output in the device’s native color
space that accurately reproduces the requested CIE-based color values as per-
ceived by a human observer. CIE-based color specification and rendering are a
feature of PDF 1.1 (
CalGray, CalRGB, and Lab) and PDF 1.3 (ICCBased).
The conversion from CIE-based color to device color is complex, and the theory
on which it is based is beyond the scope of this book; see the Bibliography for
sources of further information. The algorithm has many parameters, including an
CIE-Based Color to Device ColorSECTION 6.1
449
optional, full three-dimensional color lookup table. The color fidelity of the out-
put depends on having these parameters properly set, usually by a method that
includes some form of calibration. The colors that a device can produce are char-
acterized by a device profile, which is usually specified by an ICC profile associat-
ed with the device (and entirely separate from the profile that is specified in an
ICCBased color space).
Note: PDF has no equivalent of the PostScript color rendering dictionary. The
means by which a device profile is associated with a consumer application’s output
device are implementation-dependent and cannot be specified in a PDF file. Typi-
cally, this is done through a color management system (CMS) that is provided by the
operating system. Beginning with PDF 1.4, a PDF document can also specify one or
more output intents providing possible profiles that might be used to process the
document (see Section 10.10.4, “Output Intents”).
Conversion from a CIE-based color value to a device color value requires two
main operations:
1. Adjust the CIE-based color value according to a CIE-based gamut mapping
function. A gamut is a subset of all possible colors in some color space. A page
description has a source gamut consisting of all the colors it uses. An output
device has a device gamut consisting of all the colors it can reproduce. This
step transforms colors from the source gamut to the device gamut in a way that
attempts to preserve color appearance, visual contrast, or some other explicitly
specified rendering intent (see “Rendering Intents” on page 230).
2. Generate a corresponding device color value according to a CIE-based color
mapping function. For a given CIE-based color value, this function computes a
color value in the device’s native color space.
The CIE-based gamut and color mapping functions are applied only to color
values presented in a CIE-based color space. By definition, color values in device
color spaces directly control the device color components (though this can be al-
tered by the
DefaultGray, DefaultRGB, and DefaultCMYK color space resources;
see “Default Color Spaces” on page 227).
The source gamut is specified by a page description when it selects a CIE-based
color space. This specification is device-independent. The corresponding proper-
ties of the output device are given in the device profile associated with the device.
The gamut mapping and color mapping functions are part of the implementation
of the consumer application.
RenderingCHAPTER 6
450
6.2 Conversions among Device Color Spaces
Each raster output device has a native color space, which typically is one of the
standard device color spaces (
DeviceGray, DeviceRGB, or DeviceCMYK). In other
words, most devices support reproduction of colors according to a grayscale
(monochrome), RGB (red-green-blue), or CMYK (cyan-magenta-yellow-black)
model. If the device supports continuous-tone output, reproduction occurs di-
rectly. Otherwise, it is accomplished by means of halftoning.
A device’s native color space is also called its process color model. Process colors
are ones that are produced by combinations of one or more standard process
colorants. Colors specified in any device or CIE-based color space are rendered as
process colors. (A device can also support additional spot colorants, which can be
painted only by means of
Separation or DeviceN color spaces. They are not in-
volved in the rendering of device or CIE-based color spaces, nor are they subject
to the conversions described below.)
Note: Some devices provide a native color space that is not one of the three named
above but consists of a different combination of colorants. In that case, conversion
from the standard device color spaces to the device’s native color space is performed
by device-dependent means.
Knowing the native color space and other output capabilities of the device, the
consumer application can automatically convert the color values specified in a
document to those appropriate for the device’s native color space. For example, if
a document specifies colors in the
DeviceRGB color space but the device supports
grayscale (such as a monochrome display) or CMYK (such as a color printer), the
consumer application performs the necessary conversions. If the document spec-
ifies colors directly in the device’s native color space, no conversions are neces-
sary.
The algorithms used to convert among device color spaces are very simple. As
perceived by a human viewer, the conversions produce only crude approxima-
tions of the original colors. More sophisticated control over color conversion can
be achieved by means of CIE-based color specification and rendering. Addition-
ally, device color spaces can be remapped into CIE-based color spaces (see
“Default Color Spaces” on page 227).
Conversions among Device Color SpacesSECTION 6.2
451
6.2.1 Conversion between DeviceGray and DeviceRGB
Black, white, and intermediate shades of gray can be considered special cases of
RGB color. A grayscale value is described by a single number: 0.0 corresponds to
black, 1.0 to white, and intermediate values to different gray levels.
A gray level is equivalent to an RGB value with all three components the same. In
other words, the RGB color value equivalent to a specific gray value is simply
The gray value for a given RGB value is computed according to the NTSC video
standard, which determines how a color television signal is rendered on a black-
and-white television set:
6.2.2 Conversion between DeviceGray and DeviceCMYK
Nominally, a gray level is the complement of the black component of CMYK.
Therefore, the CMYK color value equivalent to a specific gray level is simply
To obtain the equivalent gray level for a given CMYK value, the contributions of
all components must be taken into account:
The interactions between the black component and the other three are elaborated
below.
6.2.3 Conversion from DeviceRGB to DeviceCMYK
Conversion of a color value from RGB to CMYK is a two-step process. The first
step is to convert the red-green-blue value to equivalent cyan, magenta, and yel-
red gray=
green gray=
blue gray=
gray 0.3 red× 0.59 green× 0.11 blue×++=
cyan 0.0=
magenta 0.0=
yellow 0.0=
black 1.0 gray–=
gray 1.0 min(1.0
˙
0.3 cyan× 0.59 magenta× 0.11 yellow× black+++),–=
RenderingCHAPTER 6
452
low components. The second step is to generate a black component and alter the
other components to produce a better approximation of the original color.
The subtractive color primaries cyan, magenta, and yellow are the complements
of the additive primaries red, green, and blue. For example, a cyan ink subtracts
the red component of white light. In theory, the conversion is very simple:
For example, a color that is 0.2 red, 0.7 green, and 0.4 blue can also be expressed
as 1.0 0.2 = 0.8 cyan, 1.0 0.7 = 0.3 magenta, and 1.0 0.4 = 0.6 yellow.
Logically, only cyan, magenta, and yellow are needed to generate a printing color.
An equal level of cyan, magenta, and yellow should create the equivalent level of
black. In practice, however, colored printing inks do not mix perfectly; such com-
binations often form dark brown shades instead of true black. To obtain a truer
color rendition on a printer, true black ink is often substituted for the mixed-
black portion of a color. Most color printers support a black component (the K
component of CMYK). Computing the quantity of this component requires some
additional steps:
1. Black generation calculates the amount of black to be used when trying to re-
produce a particular color.
2. Undercolor removal reduces the amounts of the cyan, magenta, and yellow
components to compensate for the amount of black that was added by black
generation.
The complete conversion from RGB to CMYK is as follows, where BG(k) and
UCR(k) are invocations of the black-generation and undercolor-removal func-
tions, respectively:
cyan 1.0 re
d
–=
magenta 1.0 green–=
yellow 1.0 blue–=
c 1.0 re
d
–=
m 1.0 green–=
y 1.0 blue–=
k min cmy,,()=
cyan min 1.0 max 0.0 c UCR k()–,(), )(=
magenta min 1.0 max 0.0 m UCR k()–,(), )(=
yellow min 1.0 max 0.0 y UCR k()–,(), )(=
black min 1.0 max 0.0 BG k(),(), )(=
Conversions among Device Color SpacesSECTION 6.2
453
In PDF 1.2, the black-generation and undercolor-removal functions are defined
as PDF function dictionaries (see Section 3.9, “Functions”) that are parameters in
the graphics state. They are specified as the values of the
BG and UCR (or BG2 and
UCR2) entries in a graphics state parameter dictionary (see Table 4.8 on page
190). Each function is called with a single numeric operand and is expected to
return a single numeric result.
The input of both the black-generation and undercolor-removal functions is k,
the minimum of the intermediate c, m, and y values that have been computed by
subtracting the original red, green, and blue components from 1.0. Nominally, k is
the amount of black that can be removed from the cyan, magenta, and yellow
components and substituted as a separate black component.
The black-generation function computes the black component as a function of
the nominal k value. It can simply return its k operand unchanged, or it can re-
turn a larger value for extra black, a smaller value for less black, or 0.0 for no
black at all.
The undercolor-removal function computes the amount to subtract from each of
the intermediate c, m, and y values to produce the final cyan, magenta, and yellow
components. It can simply return its k operand unchanged, or it can return 0.0
(so that no color is removed), some fraction of the black amount, or even a nega-
tive amount, thereby adding to the total amount of colorant.
The final component values that result after applying black generation and un-
dercolor removal are expected to be in the range 0.0 to 1.0. If a value falls outside
this range, the nearest valid value is substituted automatically without error indi-
cation. This substitution is indicated explicitly by the min and max operations in
the formulas above.
The correct choice of black-generation and undercolor-removal functions de-
pends on the characteristics of the output device—for example, how inks mix.
Each device is configured with default values that are appropriate for that device.
See Section 7.6.4, “Rendering Parameters and Transparency,” and in particular,
“Rendering Intent and Color Conversions” on page 543, for further discussion of
the role of black-generation and undercolor-removal functions in the transparent
imaging model.
RenderingCHAPTER 6
454
6.2.4 Conversion from DeviceCMYK to DeviceRGB
Conversion of a color value from CMYK to RGB is a simple operation that does
not involve black generation or undercolor removal:
In other words, the black component is simply added to each of the other compo-
nents, which are then converted to their complementary colors by subtracting
them each from 1.0.
6.3 Transfer Functions
In PDF 1.2, a transfer function adjusts the values of color components to compen-
sate for nonlinear response in an output device and in the human eye. Each com-
ponent of a device color space—for example, the red component of the
DeviceRGB space—is intended to represent the perceived lightness or intensity of
that color component in proportion to the component’s numeric value. Many de-
vices do not actually behave this way, however; the purpose of a transfer function
is to compensate for the device’s actual behavior. This operation is sometimes
called gamma correction (not to be confused with the CIE-based gamut mapping
function performed as part of CIE-based color rendering).
In the sequence of steps for processing colors, the consumer application applies
the transfer function after performing any needed conversions between color
spaces, but before applying a halftone function, if necessary. Each color compo-
nent has its own separate transfer function; there is no interaction between com-
ponents.
Transfer functions always operate in the native color space of the output device,
regardless of the color space in which colors were originally specified. (For exam-
ple, for a CMYK device, the transfer functions apply to the device’s cyan, magen-
ta, yellow, and black color components, even if the colors were originally
specified in, for example, a
DeviceRGB or CalRGB color space.) The transfer func-
tion is called with a numeric operand in the range 0.0 to 1.0 and must return a
number in the same range. The input is the value of a color component in the de-
vice’s native color space, either specified directly or produced by conversion from
red 1.0 min 1.0 cyan black+,)(–=
green 1.0 min 1.0 magenta black+,)(–=
blue 1.0 min 1.0 yellow black+,)(–=
Transfer FunctionsSECTION 6.3
455
some other color space. The output is the transformed component value to be
transmitted to the device (after halftoning, if necessary).
Both the input and the output of a transfer function are always interpreted as if
the corresponding color component were additive (red, green, blue, or gray): the
greater the numeric value, the lighter the color. If the component is subtractive
(cyan, magenta, yellow, black, or a spot color), it is converted to additive form by
subtracting it from 1.0 before it is passed to the transfer function. The output of
the function is always in additive form and is passed on to the halftone function
in that form.
In PDF 1.2, transfer functions are defined as PDF function objects (see Section
3.9, “Functions”). There are two ways to specify transfer functions:
• The current transfer function parameter in the graphics state consists of either a
single transfer function or an array of four separate transfer functions, one each
for red, green, blue, and gray or their complements cyan, magenta, yellow, and
black. (If only a single function is specified, it applies to all components.) An
RGB device uses the first three, a monochrome device uses the gray transfer
function only, and a CMYK device uses all four. The current transfer function
can be specified as the value of the
TR or TR2 entry in a graphics state parameter
dictionary; see Table 4.8 on page 190.
• The current halftone parameter in the graphics state can specify transfer func-
tions as optional entries in halftone dictionaries (see Section 6.4.4, “Halftone
Dictionaries”). This is the only way to set transfer functions for nonprimary
color components or for any component in devices whose native color space
uses components other than the ones listed above. A transfer function specified
in a halftone dictionary overrides the corresponding one specified by the cur-
rent transfer function parameter in the graphics state.
In addition to their intended use for gamma correction, transfer functions can be
used to produce a variety of special, device-dependent effects. For example, on a
monochrome device, the PostScript calculator function
{1 exch sub}
inverts the output colors, producing a negative rendition of the page. In general,
this method does not work for color devices; inversion can be more complicated
than merely inverting each of the components. Because transfer functions pro-
RenderingCHAPTER 6
456
duce device-dependent effects, a page description that is intended to be device-
independent should not alter them.
Note: When the current color space is
DeviceGray and the output device’s native
color space is
DeviceCMYK, the interpreter uses only the gray transfer function. The
normal conversion from
DeviceGray to DeviceCMYK produces 0.0 for the cyan,
magenta, and yellow components. These components are not passed through their
respective transfer functions but are rendered directly, producing output containing
no colored inks. This special case exists for compatibility with existing applications
that use a transfer function to obtain special effects on monochrome devices, and
applies only to colors specified in the
DeviceGray color space.
See Section 7.6.4, “Rendering Parameters and Transparency,” and in particular,
“Halftone and Transfer Function” on page 542, for further discussion of the role
of transfer functions in the transparent imaging model.
6.4 Halftones
Halftoning is a process by which continuous-tone colors are approximated on an
output device that can achieve only a limited number of discrete colors. Colors
that the device cannot produce directly are simulated by using patterns of pixels
in the colors available. Perhaps the most familiar example is the rendering of gray
tones with black and white pixels, as in a newspaper photograph.
Some output devices can reproduce continuous-tone colors directly. Halftoning is
not required for such devices; after gamma correction by the transfer functions,
the color components are transmitted directly to the device. On devices that do
require halftoning, it occurs after all color components have been transformed by
the applicable transfer functions. The input to the halftone function consists of
continuous-tone, gamma-corrected color components in the device’s native color
space. Its output consists of pixels in colors the device can reproduce.
PDF provides a high degree of control over details of the halftoning process. For
example, in color printing, independent halftone screens can be specified for each
of several colorants. When rendering on low-resolution displays, fine control over
halftone patterns is needed to achieve the best approximations of gray levels or
colors and to minimize visual artifacts.
Note: Remember that everything pertaining to halftones is, by definition, device-
dependent. In general, when a PDF document provides its own halftone specifica-
HalftonesSECTION 6.4
457
tions, it sacrifices portability. Associated with every output device is a default half-
tone definition that is appropriate for most purposes. Only relatively sophisticated
documents need to define their own halftones to achieve special effects.
All halftones are defined in device space, unaffected by the current transforma-
tion matrix. For correct results, a PDF document that defines a new halftone
must make assumptions about the resolution and orientation of device space. The
best choice of halftone parameters often depends on specific physical properties
of the output device, such as pixel shape, overlap between pixels, and the effects of
electronic or mechanical noise.
6.4.1 Halftone Screens
In general, halftoning methods are based on the notion of a halftone screen, which
divides the array of device pixels into cells that can be modified to produce the
desired halftone effects. A screen is defined by conceptually laying a uniform
rectangular grid over the device pixel array. Each pixel belongs to one cell of the
grid; a single cell typically contains many pixels. The screen grid is defined entire-
ly in device space and is unaffected by modifications to the current transforma-
tion matrix. This property is essential to ensure that adjacent areas colored by
halftones are properly stitched together without visible seams.
On a bilevel (black-and-white) device, each cell of a screen can be made to ap-
proximate a shade of gray by painting some of the cell’s pixels black and some
white. Numerically, the gray level produced within a cell is the ratio of white pix-
els to the total number of pixels in the cell. A cell containing n pixels can render
n + 1 different gray levels, ranging from all pixels black to all pixels white. A gray
value g in the range 0.0 to 1.0 is produced by making i pixels white, where
i = floor(g × n).
The foregoing description also applies to color output devices whose pixels con-
sist of primary colors that are either completely on or completely off. Most color
printers, but not color displays, work this way. Halftoning is applied to each color
component independently, producing shades of that color.
Color components are presented to the halftoning machinery in additive form,
regardless of whether they were originally specified additively (RGB or gray) or
subtractively (CMYK or tint). Larger values of a color component represent light-
er colors—greater intensity in an additive device such as a display or less ink in a
RenderingCHAPTER 6
458
subtractive device such as a printer. Transfer functions produce color values in
additive form; see Section 6.3, “Transfer Functions.”
6.4.2 Spot Functions
A common way of defining a halftone screen is by specifying a frequency, angle,
and spot function. The frequency is the number of halftone cells per inch; the
angle indicates the orientation of the grid lines relative to the device coordinate
system. As a cell’s desired gray level varies from black to white, individual pixels
within the cell change from black to white in a well-defined sequence: if a partic-
ular gray level includes certain white pixels, lighter grays will include the same
white pixels along with some additional ones. The order in which pixels change
from black to white for increasing gray levels is determined by a spot function,
which specifies that order in an indirect way that minimizes interactions with the
screen frequency and angle.
Consider a halftone cell to have its own coordinate system: the center of the cell is
the origin and the corners are at coordinates ±1.0 horizontally and vertically.
Each pixel in the cell is centered at horizontal and vertical coordinates that both
lie in the range 1.0 to +1.0. For each pixel, the spot function is invoked with the
pixel’s coordinates as input and must return a single number in the range 1.0 to
+1.0, defining the pixel’s position in the whitening order.
The specific values the spot function returns are not significant; all that matters
are the relative values returned for different pixels. As a cell’s gray level varies
from black to white, the first pixel whitened is the one for which the spot function
returns the lowest value, the next pixel is the one with the next higher spot func-
tion value, and so on. If two pixels have the same spot function value, their rela-
tive order is chosen arbitrarily.
PDF provides built-in definitions for many of the most commonly used spot
functions. A halftone can simply specify any of these predefined spot functions
by name instead of giving an explicit function definition. For example, the name
SimpleDot designates a spot function whose value is inversely related to a pixel’s
distance from the center of the halftone cell. This produces a “dot screen” in
which the black pixels are clustered within a circle whose area is inversely pro-
portional to the gray level. The predefined function
Line is a spot function whose
value is the distance from a given pixel to a line through the center of the cell,
producing a “line screen” in which the white pixels grow away from that line.
HalftonesSECTION 6.4
459
Table 6.1 shows the predefined spot functions. The table gives the mathematical
definition of each function along with the corresponding PostScript language
code as it would be defined in a PostScript calculator function (see Section 3.9.4,
“Type 4 (PostScript Calculator) Functions”). The image accompanying each
function shows how the relative values of the function are distributed over the
halftone cell, indicating the approximate order in which pixels are whitened. Pix-
els corresponding to darker points in the image are whitened later than those cor-
responding to lighter points. (See implementation note 69 in Appendix H.)
TABLE 6.1 Predefined spot functions
NAME APPEARANCE DEFINITION
SimpleDot
1 (x
2
+ y
2
)
{ dup mul exch dup mul add 1 exch sub }
InvertedSimpleDot
x
2
+ y
2
1
{ dup mul exch dup mul add 1 sub }
DoubleDot
{ 360 mul sin 2 div exch 360 mul sin 2 div add }
InvertedDoubleDot
{ 360 mul sin 2 div exch 360 mul sin 2 div add neg }
360 x×()sin
2
------------------------------
360 y×()sin
2
------------------------------+
360 x×()sin
2
------------------------------
360 y×()sin
2
------------------------------+
–
RenderingCHAPTER 6
460
CosineDot
{ 180 mul cos exch 180 mul cos add 2 div }
Double
{ 360 mul sin 2 div exch 2 div 360 mul sin 2 div add }
InvertedDouble
{ 360 mul sin 2 div exch 2 div 360 mul sin 2 div add neg }
Line
|y|
{ exch pop abs neg }
LineX
x
{ pop }
NAME APPEARANCE DEFINITION
180 x×()
c
os
2
-
------------------------------
180 y×()cos
2
-------------------------------+
360
x
2
--
×
sin
2
-
------------------------------
360 y×()sin
2
------------------------------+
360
x
2
--
×
sin
2
-------------------------------
360 y×()sin
2
------------------------------+
–
HalftonesSECTION 6.4
461
LineY
y
{ exch pop }
Round
if |x| + |y| 1 then 1 (x
2
+ y
2
)
else (|x| 1)
2
+ (|y| 1)
2
1
{ abs exch abs
2 copy add 1 le
{ dup mul exch dup mul add 1 exch sub }
{ 1 sub dup mul exch 1 sub dup mul add 1 sub }
ifelse }
Ellipse
let w = (3 × |x|) + (4 × |y|) 3
if w < 0 then
else if w > 1 then
else 0.5 w
{ abs exch abs 2 copy 3 mul exch 4 mul add 3 sub dup 0 lt
{ pop dup mul exch 0.75 div dup mul add
4 div 1 exch sub }
{ dup 1 gt
{ pop 1 exch sub dup mul
exch 1 exch sub 0.75 div dup mul add
4 div 1 sub }
{ 0.5 exch sub exch pop exch pop }
ifelse }
ifelse }
NAME APPEARANCE DEFINITION
1
x
2
y
0.75
----------
2
+
4
------------------------------–
1 x–()
2
1 y–
0.75
---------------
2
+
4
----------------------------------------------------- 1–
RenderingCHAPTER 6
462
EllipseA
1 (x
2
+ 0.9 × y
2
)
{ dup mul 0.9 mul exch dup mul add 1 exch sub }
InvertedEllipseA
x
2
+ 0.9 × y
2
1
{ dup mul 0.9 mul exch dup mul add 1 sub }
EllipseB
{ dup 5 mul 8 div mul exch dup mul exch add sqrt
1 exch sub }
EllipseC
1 (0.9 × x
2
+ y
2
)
{ dup mul exch dup mul 0.9 mul add 1 exch sub }
InvertedEllipseC
0.9 × x
2
+ y
2
1
{ dup mul exch dup mul 0.9 mul add 1 sub }
NAME APPEARANCE DEFINITION
1 x
2
5
8
--
y
2
×+–
HalftonesSECTION 6.4
463
Figure 6.1 illustrates the effects of some of the predefined spot functions.
Square
max(|x|, |y|)
{ abs exch abs 2 copy lt
{ exch }
if
pop neg }
Cross
min(|x|, |y|)
{ abs exch abs 2 copy gt
{ exch }
if
pop neg }
Rhomboid
{ abs exch abs 0.9 mul add 2 div }
Diamond
if |x| + |y| 0.75 then 1 (x
2
+ y
2
)
else if |x| + |y| 1.23 then 1 (0.85 × |x| + |y|)
else (|x| – 1)
2
+ (|y| – 1)
2
– 1
{ abs exch abs 2 copy add 0.75 le
{ dup mul exch dup mul add 1 exch sub }
{ 2 copy add 1.23 le
{ 0.85 mul add 1 exch sub }
{ 1 sub dup mul exch 1 sub dup mul add 1 sub }
ifelse }
ifelse }
NAME APPEARANCE DEFINITION
0.9 x× y+
2
---------------------------------
RenderingCHAPTER 6
464
FIGURE 6.1 Various halftoning effects
6.4.3 Threshold Arrays
Another way to define a halftone screen is with a threshold array that directly
controls individual device pixels in a halftone cell. This technique provides a high
degree of control over halftone rendering. It also permits halftone cells to be arbi-
trary rectangles, whereas those controlled by a spot function are always square.
A threshold array is much like a sampled image—a rectangular array of pixel
values—but is defined entirely in device space. Depending on the halftone type,
the threshold values occupy 8 or 16 bits each. Threshold values nominally repre-
sent gray levels in the usual way, from 0 for black up to the maximum (255 or
65,535) for white. The threshold array is replicated to tile the entire device space:
each pixel in device space is mapped to a particular sample in the threshold array.
On a bilevel device, where each pixel is either black or white, halftoning with a
threshold array proceeds as follows:
1. For each device pixel that is to be painted with some gray level, consult the
corresponding threshold value from the threshold array.
2. If the requested gray level is less than the threshold value, paint the device pix-
el black; otherwise, paint it white. Gray levels in the range 0.0 to 1.0 corre-
spond to threshold values from 0 to the maximum available (255 or 65,535).
150 per inch at 45°
Round dot screen
100 per inch at 45°
Round dot screen
50 per inch at 45°
Round dot screen
75 per inch at 45°
Line screen
HalftonesSECTION 6.4
465
Note: A threshold value of 0 is treated as if it were 1; therefore, a gray level of 0.0
paints all pixels black, regardless of the values in the threshold array.
This scheme easily generalizes to monochrome devices with multiple bits per
pixel. For example, if there are 2 bits per pixel, each pixel can directly represent
one of four different gray levels: black, dark gray, light gray, or white, encoded as
0, 1, 2, and 3, respectively. For any device pixel that is specified with some in-
between gray level, the halftoning algorithm consults the corresponding value in
the threshold array to determine whether to use the next-lower or next-higher
representable gray level. In this situation, the threshold values do not represent
absolute gray levels, but rather gradations between any two adjacent represent-
able gray levels.
A halftone defined in this way can also be used with color displays that have a
limited number of values for each color component. The red, green, and blue
components are simply treated independently as gray levels, applying the ap-
propriate threshold array to each. (This technique also works for a screen defined
as a spot function, since the spot function is used to compute a threshold array
internally.)
6.4.4 Halftone Dictionaries
In PDF 1.2, the graphics state includes a current halftone parameter, which deter-
mines the halftoning process to be used by the painting operators. The current
halftone can be specified as the value of the
HT entry in a graphics state parameter
dictionary; see Table 4.8 on page 190. It may be defined by either a dictionary or a
stream, depending on the type of halftone; the term halftone dictionary is used
generically throughout this section to refer to either a dictionary object or the
dictionary portion of a stream object. (The halftones that are defined by streams
are specifically identified as such in the descriptions of particular halftone types;
unless otherwise stated, they are understood to be defined by simple dictionaries
instead.)
Every halftone dictionary must have a
HalftoneType entry whose value is an inte-
ger specifying the overall type of halftone definition. The remaining entries in the
dictionary are interpreted according to this type. PDF supports the halftone types
listed in Table 6.2.
RenderingCHAPTER 6
466
TABLE 6.2 PDF halftone types
The dictionaries representing these halftone types contain the same entries as the
corresponding PostScript language halftone dictionaries (as described in Section
7.4 of the PostScript Language Reference, Third Edition), with the following ex-
ceptions:
• The PDF dictionaries may contain a Type entry with the value Halftone, identi-
fying the type of PDF object that the dictionary describes.
• Spot functions and transfer functions are represented by function objects in-
stead of PostScript procedures.
• Threshold arrays are specified as streams instead of files.
• In type 5 halftone dictionaries, the keys for colorants must be name objects;
they may not be strings as they may in PostScript.
Halftone dictionaries have an optional entry,
HalftoneName, that identifies the
halftone by name. In PDF 1.3, if this entry is present, all other entries, including
HalftoneType, are optional. At rendering time, if the output device has a halftone
with the specified name, that halftone is used, overriding any other halftone pa-
rameters specified in the dictionary. This provides a way for PDF documents to
select the proprietary halftones supplied by some device manufacturers, which
would not otherwise be accessible because they are not explicitly defined in PDF.
TYPE MEANING
1 Defines a single halftone screen by a frequency, angle, and spot function.
5 Defines an arbitrary number of halftone screens, one for each colorant or color
component (including both primary and spot colorants). The keys in this dic-
tionary are names of colorants; the values are halftone dictionaries of other
types, each defining the halftone screen for a single colorant.
6 Defines a single halftone screen by a threshold array containing 8-bit sample
values.
10 Defines a single halftone screen by a threshold array containing 8-bit sample
values, representing a halftone cell that may have a nonzero screen angle.
16 (PDF 1.3) Defines a single halftone screen by a threshold array containing 16-
bit sample values, representing a halftone cell that may have a nonzero screen
angle.
HalftonesSECTION 6.4
467
If there is no HalftoneName entry, or if the requested halftone name does not ex-
ist on the device, the halftone’s parameters are defined by the other entries in the
dictionary, if any. If no other entries are present, the default halftone is used.
See Section 7.6.4, “Rendering Parameters and Transparency,” and in particular,
“Halftone and Transfer Function” on page 542, for further discussion of the role
of halftones in the transparent imaging model.
Type 1 Halftones
Table 6.3 describes the contents of a halftone dictionary of type 1, which defines a
halftone screen in terms of its frequency, angle, and spot function.
TABLE 6.3 Entries in a type 1 halftone dictionary
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if
present, must be
Halftone for a halftone dictionary.
HalftoneType integer (Required) A code identifying the halftone type that this dictionary
describes; must be 1 for this type of halftone.
HalftoneName string (Optional) The name of the halftone dictionary.
Frequency number (Required) The screen frequency, measured in halftone cells per inch in
device space.
Angle number (Required) The screen angle, in degrees of rotation counterclockwise
with respect to the device coordinate system. (Most output devices
have left-handed device spaces. On such devices, a counterclockwise
angle in device space corresponds to a clockwise angle in default user
space and on the physical medium.)
SpotFunction function or name (Required) A function object defining the order in which device pixels
within a screen cell are adjusted for different gray levels, or the name of
one of the predefined spot functions (see Table 6.1 on page 459).
AccurateScreens boolean (Optional) A flag specifying whether to invoke a special halftone al-
gorithm that is extremely precise but computationally expensive; see
below for further discussion. Default value:
false.
RenderingCHAPTER 6
468
If the AccurateScreens entry has a value of true, a highly precise halftoning algo-
rithm is substituted in place of the standard one. If
AccurateScreens is false or not
present, ordinary halftoning is used. Accurate halftoning achieves the requested
screen frequency and angle with very high accuracy, whereas ordinary halftoning
adjusts them so that a single screen cell is quantized to device pixels. High accura-
cy is important mainly for making color separations on high-resolution devices.
However, it may be computationally expensive and therefore is ordinarily dis-
abled.
In principle, PDF permits the use of halftone screens with arbitrarily large cells—
in other words, arbitrarily low frequencies. However, cells that are very large
relative to the device resolution or that are oriented at unfavorable angles may ex-
ceed the capacity of available memory. If this happens, an error occurs. The
AccurateScreens feature often requires very large amounts of memory to achieve
the highest accuracy.
Example 6.1 shows a halftone dictionary for a type 1 halftone.
Example 6.1
28 0 obj
<< /Type /Halftone
/HalftoneType 1
/Frequency 120
/Angle 30
/SpotFunction /CosineDot
/TransferFunction /Identity
>>
endobj
TransferFunction
function or name (Optional) A transfer function, which overrides the current transfer
function in the graphics state for the same component. This entry is re-
quired if the dictionary is a component of a type 5 halftone (see “Type
5 Halftones” on page 475) and represents either a nonprimary or non-
standard primary color component (see Section 6.3, “Transfer Func-
tions”). The name
Identity may be used to specify the identity
function.
KEY TYPE VALUE
HalftonesSECTION 6.4
469
Type 6 Halftones
A type 6 halftone defines a halftone screen with a threshold array. The halftone is
represented as a stream containing the threshold values; the parameters defining
the halftone are specified by entries in the stream dictionary. This dictionary can
contain the entries shown in Table 6.4 in addition to the usual entries common to
all streams (see Table 3.4 on page 38). The
Width and Height entries specify the
dimensions of the threshold array in device pixels; the stream must contain
Width × Height bytes, each representing a single threshold value. Threshold val-
ues are defined in device space in the same order as image samples in image space
(see Figure 4.26 on page 308), with the first value at device coordinates (0, 0) and
horizontal coordinates changing faster than vertical coordinates.
Type 10 Halftones
Although type 6 halftones can be used to specify a threshold array with a zero
screen angle, they make no provision for other angles. The type 10 halftone re-
moves this restriction and allows the use of threshold arrays for halftones with
nonzero screen angles as well.
TABLE 6.4 Additional entries specific to a type 6 halftone dictionary
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if
present, must be
Halftone for a halftone dictionary.
HalftoneType integer (Required) A code identifying the halftone type that this dictionary
describes; must be 6 for this type of halftone.
HalftoneName string (Optional) The name of the halftone dictionary.
Width integer (Required) The width of the threshold array, in device pixels.
Height integer (Required) The height of the threshold array, in device pixels.
TransferFunction function or name (Optional) A transfer function, which overrides the current transfer
function in the graphics state for the same component. This entry is re-
quired if the dictionary is a component of a type 5 halftone (see “Type
5 Halftones” on page 475) and represents either a nonprimary or non-
standard primary color component (see Section 6.3, “Transfer Func-
tions”). The name
Identity may be used to specify the identity
function.
RenderingCHAPTER 6
470
Halftone cells at nonzero angles can be difficult to specify because they may not
line up well with scan lines and because it may be difficult to determine where a
given sampled point goes. The type 10 halftone addresses these difficulties by
dividing the halftone cell into a pair of squares that line up at zero angles with the
output device’s pixel grid. The squares contain the same information as the origi-
nal cell but are much easier to store and manipulate. In addition, they can be
mapped easily into the internal representation used for all rendering.
Figure 6.2 shows a halftone cell with a frequency of 38.4 cells per inch and an
angle of 50.2 degrees, represented graphically in device space at a resolution of
300 dots per inch. Each asterisk in the figure represents a location in device space
that is mapped to a specific location in the threshold array.
FIGURE 6.2 Halftone cell with a nonzero angle
Figure 6.3 shows how the halftone cell can be divided into two squares. If the
squares and the original cell are tiled across device space, the area to the right of
the upper square maps exactly into the empty area of the lower square, and vice
versa (see Figure 6.4). The last row in the first square is immediately adjacent to
the first row in the second square and starts in the same column.
**********
********
******
****
**
**********
********
******
****
**
*
HalftonesSECTION 6.4
471
FIGURE 6.3 Angled halftone cell divided into two squares
FIGURE 6.4 Halftone cell and two squares tiled across device space
**********
********
******
****
**
**********
********
******
****
**
*
X
Y
aaaaaaaaaa
aaaaaaaa
aaaaaa
aaaa
aa
aaaaaaaaaa
aaaaaaaa
aaaaaa
aaaa
aa
a
bbbbb
*
bbbb
bbbbbbbb
bbbbbb
bbbb
bb
bbbbbbbbbb
bbbbbbbb
bbbbbb
bbbb
bb
b
ccccc
*
cccc
cccccccc
cccccc
cccc
cc
cccccccccc
cccccccc
cccccc
cccc
cc
c
X
X
X
Y
Y
Y
Y
RenderingCHAPTER 6
472
Any halftone cell can be divided in this way. The side of the upper square (X) is
equal to the horizontal displacement from a point in one halftone cell to the cor-
responding point in the adjacent cell, such as those marked by asterisks in Figure
6.4. The side of the lower square (Y) is the vertical displacement between the
same two points. The frequency of a halftone screen constructed from squares
with sides X and Y is thus given by
and the angle by
Like a type 6 halftone, a type 10 halftone is represented as a stream containing
the threshold values, with the parameters defining the halftone specified by en-
tries in the stream dictionary. This dictionary can contain the entries shown in
Table 6.5 in addition to the usual entries common to all streams (see Table 3.4 on
page 38). The
Xsquare and Ysquare entries replace the type 6 halftone’s Width
and Height entries.
TABLE 6.5 Additional entries specific to a type 10 halftone dictionary
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if
present, must be
Halftone for a halftone dictionary.
HalftoneType integer (Required) A code identifying the halftone type that this dictionary
describes; must be 10 for this type of halftone.
HalftoneName string (Optional) The name of the halftone dictionary.
Xsquare integer (Required) The side of square X, in device pixels; see below.
Ysquare integer (Required) The side of square Y, in device pixels; see below.
TransferFunction function or
name
(Optional) A transfer function, which overrides the current transfer func-
tion in the graphics state for the same component. This entry is required
if the dictionary is a component of a type 5 halftone (see “Type 5 Half-
tones” on page 475) and represents either a nonprimary or nonstandard
primary color component (see Section 6.3, “Transfer Functions”). The
name
Identity may be used to specify the identity function.
frequency
resolution
X
2
Y
2
+
-----------------------=
angle
Y
X
---
atan=
HalftonesSECTION 6.4
473
The Xsquare and Ysquare entries specify the dimensions of the two squares in
device pixels. The stream must contain
Xsquare
2
+ Ysquare
2
bytes, each repre-
senting a single threshold value. The contents of square X are specified first,
followed by those of square Y. Threshold values within each square are defined in
device space in the same order as image samples in image space (see Figure 4.26
on page 308), with the first value at device coordinates (0, 0) and horizontal coor-
dinates changing faster than vertical coordinates.
Type 16 Halftones
Like type 10, a type 16 halftone (PDF 1.3) defines a halftone screen with a thresh-
old array and allows nonzero screen angles. In type 16, however, each element of
the threshold array is 16 bits wide instead of 8. This allows the threshold array to
distinguish 65,536 levels of color rather than only 256 levels. The threshold array
can consist of either one rectangle or two rectangles. If two rectangles are speci-
fied, they tile the device space as shown in Figure 6.5. The last row in the first
rectangle is immediately adjacent to the first row in the second and starts in the
same column.
FIGURE 6.5 Tiling of device space in a type 16 halftone
A type 16 halftone, like type 6 and type 10, is represented as a stream containing
the threshold values, with the parameters defining the halftone specified by en-
tries in the stream dictionary. This dictionary can contain the entries shown in
Table 6.6 in addition to the usual entries common to all streams (see Table 3.4 on
page 38). The dictionary’s
Width and Height entries define the dimensions of the
first (or only) rectangle. The dimensions of the second, optional rectangle are de-
fined by the optional entries
Width2 and Height2. Each threshold value is repre-
Width × Height
Height
Height2
Width
Width2 ×
Height2
Width2
RenderingCHAPTER 6
474
sented as 2 bytes, with the high-order byte first. The stream must therefore
contain 2 ×
Width × Height bytes if there is only one rectangle or
2 × (
Width × Height + Width2 × Height2) bytes if there are two rectangles. The
contents of the first rectangle are specified first, followed by those of the second
rectangle. Threshold values within each rectangle are defined in device space in
the same order as image samples in image space (see Figure 4.26 on page 308),
with the first value at device coordinates (0, 0) and horizontal coordinates chang-
ing faster than vertical coordinates.
TABLE 6.6 Additional entries specific to a type 16 halftone dictionary
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if
present, must be
Halftone for a halftone dictionary.
HalftoneType integer (Required) A code identifying the halftone type that this dictionary
describes; must be 16 for this type of halftone.
HalftoneName string (Optional) The name of the halftone dictionary.
Width integer (Required) The width of the first (or only) rectangle in the threshold
array, in device pixels.
Height integer (Required) The height of the first (or only) rectangle in the threshold
array, in device pixels.
Width2 integer (Optional) The width of the optional second rectangle in the threshold
array, in device pixels. If this entry is present, the
Height2 entry must
be present as well. If this entry is absent, the
Height2 entry must also be
absent, and the threshold array has only one rectangle.
Height2 integer (Optional) The height of the optional second rectangle in the threshold
array, in device pixels.
TransferFunction function or name (Optional) A transfer function, which overrides the current transfer
function in the graphics state for the same component. This entry is re-
quired if the dictionary is a component of a type 5 halftone (see “Type
5 Halftones,” below) and represents either a nonprimary or nonstand-
ard primary color component (see Section 6.3, “Transfer Functions”).
The name
Identity may be used to specify the identity function.
HalftonesSECTION 6.4
475
Type 5 Halftones
Some devices, particularly color printers, require separate halftones for each indi-
vidual colorant. Also, devices that can produce named separations may require
individual halftones for each separation. Halftone dictionaries of type 5 allow
individual halftones to be specified for an arbitrary number of colorants or color
components.
A type 5 halftone dictionary (Table 6.7) is a composite dictionary containing
independent halftone definitions for multiple colorants. Its keys are name objects
representing the names of individual colorants or color components. The values
associated with these keys are other halftone dictionaries, each defining the half-
tone screen and transfer function for a single colorant or color component. The
component halftone dictionaries may be of any supported type except 5.
TABLE 6.7 Entries in a type 5 halftone dictionary
KEY TYPE VALUE
Type name (Optional) The type of PDF object that this dictionary describes; if present,
must be
Halftone for a halftone dictionary.
HalftoneType number (Required) A code identifying the halftone type that this dictionary describes;
must be 5 for this type of halftone.
HalftoneName string (Optional) The name of the halftone dictionary.
any colorant
name
dictionary
or stream
(Required, one per colorant) The halftone corresponding to the colorant or
color component named by the key. The halftone may be of any type other
than 5. Note that the key must be a name object; strings are not permitted, as
they are in type 5 PostScript halftone dictionaries.
Default dictionary
or stream
(Required) A halftone to be used for any colorant or color component that
does not have an entry of its own. The value may not be a type 5 halftone. If
there are any nonprimary colorants, the default halftone must have a transfer
function.
RenderingCHAPTER 6
476
The colorants or color components represented in a type 5 halftone dictionary
fall into two categories:
• Primary color components for the standard native device color spaces (Gray for
DeviceGray; Red, Green, and Blue for DeviceRGB; Cyan, Magenta, Yellow, and
Black for DeviceCMYK;).
• Nonstandard color components for use as spot colorants in Separation and
DeviceN color spaces. Some of these may also be used as process colorants if
the native color space is nonstandard.
The dictionary must also contain an entry whose key is
Default. The value of this
entry is a halftone dictionary to be used for any color component that does not
have an entry of its own.
When a halftone dictionary of some other type appears as the value of an entry in
a type 5 halftone dictionary, it applies only to the single colorant or color com-
ponent named by that entry’s key. This is in contrast to such a dictionary’s being
used as the current halftone parameter in the graphics state, which applies to all
color components. If nonprimary colorants are requested when the current half-
tone is defined by any means other than a type 5 halftone dictionary, the gray
halftone screen and transfer function are used for all such colorants.
Example 6.2 shows a type 5 halftone dictionary with the primary color compo-
nents for a CMYK device. In this example, the halftone dictionaries for the color
components and for the default all use the same spot function.
Example 6.2
27 0 obj
<< /Type /Halftone
/HalftoneType 5
/Cyan 31 0 R
/Magenta 32 0 R
/Yellow 33 0 R
/Black 34 0 R
/Default 35 0 R
>>
endobj
HalftonesSECTION 6.4
477
31 0 obj
<< /Type /Halftone
/HalftoneType 1
/Frequency 89.827
/Angle 15
/SpotFunction /Round
/AccurateScreens true
>>
endobj
32 0 obj
<< /Type /Halftone
/HalftoneType 1
/Frequency 89.827
/Angle 75
/SpotFunction /Round
/AccurateScreens true
>>
endobj
33 0 obj
<< /Type /Halftone
/HalftoneType 1
/Frequency 90.714
/Angle 0
/SpotFunction /Round
/AccurateScreens true
>>
endobj
34 0 obj
<< /Type /Halftone
/HalftoneType 1
/Frequency 89.803
/Angle 45
/SpotFunction /Round
/AccurateScreens true
>>
endobj
RenderingCHAPTER 6
478
35 0 obj
<< /Type /Halftone
/HalftoneType 1
/Frequency 90.000
/Angle 45
/SpotFunction /Round
/AccurateScreens true
>>
endobj
6.5 Scan Conversion Details
The final step of rendering is scan conversion. As discussed in Section 2.1.4, “Scan
Conversion,” the application executes a scan conversion algorithm to paint
graphics, text, and images in the raster memory of the output device.
The specifics of the scan conversion algorithm are not defined as part of PDF.
Different implementations can perform scan conversion in different ways; tech-
niques that are appropriate for one device may be inappropriate for another. Still,
it is useful to have a general understanding of how scan conversion works, partic-
ularly when creating PDF documents intended for viewing on a display. At the
low resolutions typical of displays, variations of even one pixel’s width can have a
noticeable effect on the appearance of painted shapes.
The following sections describe the scan conversion algorithms that are typical of
Acrobat products. (These details also apply to PostScript products, yielding con-
sistent results when an application prints a document on a PostScript printer.)
Most scan conversion details are not under program control, but a few are; the
parameters for controlling them are described here.
6.5.1 Flatness Tolerance
The flatness tolerance controls the maximum permitted distance in device pixels
between the mathematically correct path and an approximation constructed
from straight line segments, as shown in Figure 6.6. Flatness can be specified as
the operand of the
i operator (see Table 4.7 on page 189) or as the value of the FL
entry in a graphics state parameter dictionary (see Table 4.8 on page 190). It must
be a positive number; smaller values yield greater precision at the cost of more
computation.
Scan Conversion DetailsSECTION 6.5
479
Note: Although the figure exaggerates the difference between the curved and flat-
tened paths for the sake of clarity, the purpose of the flatness tolerance is to control
the precision of curve rendering, not to draw inscribed polygons. If the parameter’s
value is large enough to cause visible straight line segments to appear, the result is
unpredictable.
FIGURE 6.6 Flatness tolerance
6.5.2 Smoothness Tolerance
The smoothness tolerance (PDF 1.3) controls the quality of smooth shading
(type 2 patterns and the
sh operator) and thus indirectly controls the rendering
performance. Smoothness is the allowable color error between a shading approx-
imated by piecewise linear interpolation and the true value of a (possibly non-
linear) shading function. The error is measured for each color component, and
the maximum error is used. The allowable error (or tolerance) is expressed as a
fraction of the range of the color component, from 0.0 to 1.0. Thus, a smoothness
tolerance of 0.1 represents a tolerance of 10 percent in each color component.
Smoothness can be specified as the value of the
SM entry in a graphics state
parameter dictionary (see Table 4.8 on page 190).
Each output device may have internal limits on the maximum and minimum
tolerances attainable. For example, setting smoothness to 1.0 may result in an in-
ternal smoothness of 0.5 on a high-quality color device, while setting it to 0.0 on
the same device may result in an internal smoothness of 0.01 if an error of that
magnitude is imperceptible on the device.
Flatness error
tolerance
RenderingCHAPTER 6
480
The smoothness tolerance may also interact with the accuracy of color conver-
sion. In the case of a color conversion defined by a sampled function, the con-
version function is unknown. Thus the error may be sampled at too low a
frequency, in which case the accuracy defined by the smoothness tolerance can-
not be guaranteed. In most cases, however, where the conversion function is
smooth and continuous, the accuracy should be within the specified tolerance.
The effect of the smoothness tolerance is similar to that of the flatness tolerance.
Note, however, that flatness is measured in device-dependent units of pixel width,
whereas smoothness is measured as a fraction of color component range.
6.5.3 Scan Conversion Rules
The following rules determine which device pixels a painting operation affects.
All references to coordinates and pixels are in device space. A shape is a path to be
painted with the current color or with an image. Its coordinates are mapped into
device space but not rounded to device pixel boundaries. At this level, curves
have been flattened to sequences of straight lines, and all “insideness” computa-
tions have been performed.
Pixel boundaries always fall on integer coordinates in device space. A pixel is a
square region identified by the location of its corner with minimum horizontal
and vertical coordinates. The region is half-open, meaning that it includes its
lower but not its upper boundaries. More precisely, for any point whose real-
number coordinates are (x, y), let i = floor(x) and j = floor(y). The pixel that con-
tains this point is the one identified as (i, j). The region belonging to that pixel is
defined to be the set of points (x, y ) such that i x < i + 1 and j y < j + 1.
Like pixels, shapes to be painted by filling and stroking operations are also treated
as half-open regions that include the boundaries along their “floor” sides, but not
along their “ceiling” sides.
A shape is scan-converted by painting any pixel whose square region intersects
the shape, no matter how small the intersection is. This ensures that no shape
ever disappears as a result of unfavorable placement relative to the device pixel
grid, as might happen with other possible scan conversion rules. The area covered
by painted pixels is always at least as large as the area of the original shape. This
rule applies both to fill operations and to strokes with nonzero width. Zero-width
strokes are done in a device-dependent manner that may include fewer pixels
than the rule implies.
Scan Conversion DetailsSECTION 6.5
481
Note: Normally, the intersection of two regions is defined as the intersection of their
interiors. However, for purposes of scan conversion, a filling region is considered to
intersect every pixel through which its boundary passes, even if the interior of the
filling region is empty. Thus, for example, a zero-width or zero-height rectangle
paints a line 1 pixel wide.
The region of device space to be painted by a sampled image is determined simi-
larly to that of a filled shape, though not identically. The application transforms
the image’s source rectangle into device space and defines a half-open region, just
as for fill operations. However, only those pixels whose centers lie within the re-
gion are painted. The position of the center of such a pixel—in other words, the
point whose coordinate values have fractional parts of one-half—is mapped back
into source space to determine how to color the pixel. There is no averaging over
the pixel area; if the resolution of the source image is higher than that of device
space, some source samples are not used.
For clipping, the clipping region consists of the set of pixels that would be in-
cluded by a fill operation. Subsequent painting operations affect a region that is
the intersection of the set of pixels defined by the clipping region with the set of
pixels for the region to be painted.
Scan conversion of character glyphs is performed by a different algorithm from
the one above. That font rendering algorithm uses hints in the glyph descriptions
and techniques that are specialized to glyph rasterization.
6.5.4 Automatic Stroke Adjustment
When a stroke is drawn along a path, the scan conversion algorithm may produce
lines of nonuniform thickness because of rasterization effects. In general, the line
width and the coordinates of the endpoints, transformed into device space, are
arbitrary real numbers not quantized to device pixels. A line of a given width can
intersect with different numbers of device pixels, depending on where it is posi-
tioned. Figure 6.7 illustrates this effect.
For best results, it is important to compensate for the rasterization effects to pro-
duce strokes of uniform thickness. This is especially important in low-resolution
display applications. To meet this need, PDF 1.2 provides an optional automatic
stroke adjustment feature. When stroke adjustment is enabled, the line width and
the coordinates of a stroke are automatically adjusted as necessary to produce
RenderingCHAPTER 6
482
lines of uniform thickness. The thickness is as near as possible to the requested
line width—no more than half a pixel different.
FIGURE 6.7 Rasterization without stroke adjustment
Note: If stroke adjustment is enabled and the requested line width, transformed into
device space, is less than half a pixel, the stroke is rendered as a single-pixel line.
This is the thinnest line that can be rendered at device resolution. It is equivalent to
the effect produced by setting the line width to 0 (see Section 6.5.3, “Scan Conversion
Rules”).
Because automatic stroke adjustment can have a substantial effect on the appear-
ance of lines, a PDF document must be able to control whether the adjustment is
to be performed. This can be specified with the stroke adjustment parameter in
the graphics state, set by means of the
SA entry in a graphics state parameter dic-
tionary (see Section 4.3.4, “Graphics State Parameter Dictionaries”); see imple-
mentation note 70 in Appendix H.
Path
Resulting line
Line width
Resulting line
Line width
Path
1
pixel
483
CHAPTER 7
7Transparency
PDF 1.4 extends the Adobe imaging model to include the notion of transparency.
Transparent objects do not necessarily obey a strict opaque painting model but
can blend (composite) in interesting ways with other overlapping objects. This
chapter describes the general transparency model but does not cover how it is im-
plemented. Implementation-like descriptions are used at various points to de-
scribe how things work, for the purpose of elucidating the behavior of the model.
The actual implementation will almost certainly be different from what these de-
scriptions might imply.
The chapter is organized as follows:
• Section 7.1, “Overview of Transparency,” introduces the basic concepts of the
transparency model and its associated terminology.
• Section 7.2, “Basic Compositing Computations,” describes the mathematics
involved in compositing a single object with its backdrop.
• Section 7.3, “Transparency Groups,” introduces the concept of transparency
groups and describes their properties and behavior.
• Section 7.4, “Soft Masks,” covers the creation and use of masks to specify
position-dependent shape and opacity.
• Section 7.5, “Specifying Transparency in PDF,” describes how transparency
properties are represented in a PDF document.
• Section 7.6, “Color Space and Rendering Issues,” deals with some specific inter-
actions between transparency and other aspects of color specification and
rendering.
TransparencyCHAPTER 7
484
7.1 Overview of Transparency
The original Adobe imaging model paints objects (fills, strokes, text, and images),
possibly clipped by a path, opaquely onto a page. The color of the page at any
point is that of the topmost enclosing object, disregarding any previous objects it
may overlap. This effect can be—and often is—realized simply by rendering ob-
jects directly to the page in the order in which they are specified, with each object
completely overwriting any others that it overlaps.
Under the transparent imaging model, all of the objects on a page can potentially
contribute to the result. Objects at a given point can be thought of as forming a
transparency stack (or stack for short). The objects are arranged from bottom to
top in the order in which they are specified. The color of the page at each point is
determined by combining the colors of all enclosing objects in the stack accord-
ing to compositing rules defined by the transparency model.
Note: The order in which objects are specified determines the stacking order but not
necessarily the order in which the objects are actually painted onto the page. In
particular, the transparency model does not require a consumer application to ras-
terize objects immediately or to commit to a raster representation at any time before
rendering the entire stack onto the page. This is important, since rasterization often
causes significant loss of information and precision that is best avoided during inter-
mediate stages of the transparency computation.
A given object is composited with a backdrop. Ordinarily, the backdrop consists
of the stack of all objects that have been specified previously. The result of com-
positing is then treated as the backdrop for the next object. However, within cer-
tain kinds of transparency groups (see below), a different backdrop is chosen.
When an object is composited with its backdrop, the color at each point is com-
puted using a specified blend mode, which is a function of both the object’s color
and the backdrop color. The blend mode determines how colors interact; differ-
ent blend modes can be used to achieve a variety of useful effects. A single blend
mode is in effect for compositing all of a given object, but different blend modes
can be applied to different objects.
Compositing of an object with its backdrop is mediated by two scalar quantities
called shape and opacity. Conceptually, for each object, these quantities are de-
fined at every point in the plane, just as if they were additional color components.
Overview of TransparencySECTION 7.1
485
(In actual practice, they are often obtained from auxiliary sources rather than be-
ing intrinsic to the object.)
Both shape and opacity vary from 0.0 (no contribution) to 1.0 (maximum contri-
bution). At any point where either the shape or the opacity of an object is 0.0, its
color is undefined. At points where the shape is 0.0, the opacity is also undefined.
The shape and opacity are subject to compositing rules; therefore, the stack as a
whole also has a shape and opacity at each point.
An object’s opacity, in combination with the backdrop’s opacity, determines the
relative contributions of the backdrop color, the object’s color, and the blended
color to the resulting composite color. The object’s shape then determines the de-
gree to which the composite color replaces the backdrop color. Shape values of
0.0 and 1.0 identify points that lie outside and inside a conventional sharp-edged
object; intermediate values are useful in defining soft-edged objects.
Shape and opacity are conceptually very similar. In fact, they can usually be com-
bined into a single value, called alpha, which controls both the color compositing
computation and the fading between an object and its backdrop. However, there
are a few situations in which they must be treated separately; see Section 7.3.5,
“Knockout Groups.” Moreover, raster-based implementations must maintain a
separate shape parameter to do anti-aliasing properly; it is therefore convenient
to have it be an explicit part of the model.
One or more consecutive objects in a stack can be collected together into a trans-
parency group (often referred to hereafter simply as a group). The group as a
whole can have various properties that modify the compositing behavior of ob-
jects within the group and their interactions with its backdrop. An additional
blend mode, shape, and opacity can also be associated with the group as a whole
and used when compositing it with its backdrop. Groups can be nested within
other groups, forming a tree-structured hierarchy.
Note: The concept of a transparency group is independent of existing notions of
group or layer in applications such as Adobe Illustrator
®
. Those groupings reflect
logical relationships among objects that are meaningful when editing those objects,
but they are not part of the imaging model.
Plate 16 illustrates the effects of transparency grouping. In the upper two figures,
three colored circles are painted as independent objects with no grouping. At the
upper left, the three objects are painted opaquely (opacity = 1.0); each object
TransparencyCHAPTER 7
486
completely replaces its backdrop (including previously painted objects) with its
own color. At the upper right, the same three independent objects are painted
with an opacity of 0.5, causing them to composite with each other and with the
gray and white backdrop. In the lower two figures, the three objects are combined
as a transparency group. At the lower left, the individual objects have an opacity
of 1.0 within the group, but the group as a whole is painted in the
Normal blend
mode with an opacity of 0.5. The objects thus completely overwrite each other
within the group, but the resulting group then composites transparently with the
gray and white backdrop. At the lower right, the objects have an opacity of 0.5
within the group and thus composite with each other. The group as a whole is
painted against the backdrop with an opacity of 1.0 but in a different blend mode
(
HardLight), producing a different visual effect.
The color result of compositing a group can be converted to a single-component
luminosity value and treated as a soft mask. Such a mask can then be used as an
additional source of shape or opacity values for subsequent compositing opera-
tions. When the mask is used as a shape, this technique is known as soft clipping;
it is a generalization of the current clipping path in the opaque imaging model
(see Section 4.4.3, “Clipping Path Operators”).
The notion of current page is generalized to refer to a transparency group consist-
ing of the entire stack of objects placed on the page, composited with a backdrop
that is pure white and fully opaque. Logically, this entire stack is then rasterized
to determine the actual pixel values to be transmitted to the output device.
Note: In contexts where a PDF page is treated as a piece of artwork to be placed on
some other page—such as an Illustrator artboard or an Encapsulated PostScript
(EPS) file—it is treated not as a page but as a group, whose backdrop may be de-
fined differently from that of a page.
7.2 Basic Compositing Computations
This section describes the basic computations for compositing a single object
with its backdrop. These computations are extended in Section 7.3, “Transparen-
cy Groups,” to cover groups consisting of multiple objects.
Basic Compositing ComputationsSECTION 7.2
487
7.2.1 Basic Notation for Compositing Computations
In general, variable names in this chapter consisting of a lowercase letter denote a
scalar quantity, such as an opacity. Uppercase letters denote a value with multiple
scalar components, such as a color. In the descriptions of the basic color compos-
iting computations, color values are generally denoted by the letter C, with a
mnemonic subscript indicating which of several color values is being referred to;
for instance, C
s
stands for “source color.” Shape and opacity values are denoted re-
spectively by the letters f (for “form factor”) and q (for “opaqueness”)—again with
a mnemonic subscript, such as q
s
for “source opacity.” The symbol
(alpha)
stands for a product of shape and opacity values.
In certain computations, one or more variables may have undefined values; for
instance, when opacity is zero, the corresponding color is undefined. A quantity
can also be undefined if it results from division by zero. In any formula that uses
such an undefined quantity, the quantity has no effect on the ultimate result
because it is subsequently multiplied by zero or otherwise canceled out. The sig-
nificant point is that while any arbitrary value can be chosen for such an unde-
fined quantity, the computation must not malfunction because of exceptions
caused by overflow or division by zero. It is convenient to adopt the further con-
vention that 0 ÷ 0 = 0.
7.2.2 Basic Compositing Formula
The primary change in the imaging model to accommodate transparency is in
how colors are painted. In the transparent model, the result of painting (the result
color) is a function of both the color being painted (the source color) and the color
it is painted over (the backdrop color). Both of these colors may vary as a function
of position on the page; however, this section focuses on some fixed point on the
page and assumes a fixed backdrop and source color.
Other parameters in this computation are the alpha, which controls the relative
contributions of the backdrop and source colors, and the blend function, which
specifies how they are combined in the painting operation. The resulting basic
TransparencyCHAPTER 7
488
color compositing formula (or just basic compositing formula for short) determines
the result color produced by the painting operation:
where the variables have the meanings shown in Table 7.1.
TABLE 7.1 Variables used in the basic compositing formula
This formula is actually a simplified form of the compositing formula in which
the shape and opacity values are combined and represented as a single alpha val-
ue; the more general form is presented later. This function is based on the
over
operation defined in the article “Compositing Digital Images,” by Porter and Duff
(see the Bibliography), extended to include a blend mode in the region of over-
lapping coverage. The following sections elaborate on the meaning and implica-
tions of this formula.
7.2.3 Blending Color Space
The compositing formula shown above is actually a vector function: the colors it
operates on are represented in the form of n-element vectors, where n is the num-
ber of components required by the color space in which compositing is per-
formed. The ith component of the result color C
r
is obtained by applying the
compositing formula to the ith components of the constituent colors C
b
, C
s
, and
VARIABLE MEANING
Backdrop color
Source color
Result color
Backdrop alpha
Source alpha
Result alpha
Blend function
C
r
1
s
r
-----–
C
b
×
s
r
-----
1
b
–()C
s
×
b
BC
b
C
s
,()×+[]×+=
C
b
C
s
C
r
b
s
r
BC
b
C
s
,()
Basic Compositing ComputationsSECTION 7.2
489
B(C
b
, C
s
). The result of the computation thus depends on the color space in
which the colors are represented. For this reason, the color space used for com-
positing, called the blending color space, is explicitly made part of the transparent
imaging model. When necessary, backdrop and source colors are converted to the
blending color space before the compositing computation.
Of the PDF color spaces described in Section 4.5, “Color Spaces,” the following
are supported as blending color spaces:
• DeviceGray
• DeviceRGB
• DeviceCMYK
• CalGray
• CalRGB
• ICCBased color spaces equivalent to those above (including calibrated CMYK)
The
Lab space and ICCBased spaces that represent lightness and chromaticity sep-
arately (such as L*a*b*, L*u*v*, and HSV) are not allowed as blending color spac-
es because the compositing computations in such spaces do not give meaningful
results when applied separately to each component. In addition, an
ICCBased
space used as a blending color space must be bidirectional; that is, the ICC profile
must contain both AToB and BToA transformations.
The blending color space is consulted only for process colors. Although blending
can also be done on individual spot colors specified in a
Separation or DeviceN
color space, such colors are never converted to a blending color space (except in
the case where they first revert to their alternate color space, as described under
“Separation Color Spaces” on page 234 and “DeviceN Color Spaces” on page
238). Instead, the specified color components are blended individually with the
corresponding components of the backdrop.
The blend functions for the various blend modes assume that the range for each
color component is 0.0 to 1.0 and that the color space is additive. The former
condition is true for all of the allowed blending color spaces, but the latter condi-
tion is not true. In particular, the
DeviceCMYK, Separation, and DeviceN spaces
are subtractive. When performing blending operations in subtractive color spac-
es, it is assumed that the color component values are complemented (subtracted
from 1.0) before the blend function is applied and that the results of the function
TransparencyCHAPTER 7
490
are then complemented back before being used. This adjustment makes the ef-
fects of the various blend modes numerically consistent across all color spaces.
However, the actual visual effect produced by a given blend mode still depends
on the color space. Blending in a device color space produces device-dependent
results, whereas in a CIE-based space it produces results that are consistent
across all devices. See Section 7.6, “Color Space and Rendering Issues,” for addi-
tional details concerning color spaces.
7.2.4 Blend Mode
In principle, the blend function B(C
b
, C
s
), used in the compositing formula to
customize the blending operation, could be any function of the backdrop and
source colors that yields another color, C
r
, for the result. PDF defines a standard
set of named blend functions, or blend modes, listed in Tables 7.2 and 7.3. Plates
18 and 19 illustrate the resulting visual effects for RGB and CMYK colors, respec-
tively.
A blend mode is termed separable if each component of the result color is com-
pletely determined by the corresponding components of the constituent back-
drop and source colors—that is, if the blend mode function B is applied
separately to each set of corresponding components:
where the lowercase variables c
r
, c
b
, and c
s
denote corresponding components of
the colors C
r
, C
b
, and C
s
, expressed in additive form. (Theoretically, a blend
mode could have a different function for each color component and still be sepa-
rable; however, none of the standard PDF blend modes have this property.) A
separable blend mode can be used with any color space, since it applies indepen-
dently to any number of components. Only separable blend modes can be used
for blending spot colors.
Table 7.2 lists the standard separable blend modes available in PDF. Some of them
are defined by actual mathematical formulas; the rest are characterized only by a
general description of their intended effects.
c
r
Bc
b
c
s
,()=
Basic Compositing ComputationsSECTION 7.2
491
TABLE 7.2 Standard separable blend modes
NAME RESULT
Normal Selects the source color, ignoring the backdrop:
Multiply Multiplies the backdrop and source color values:
The result color is always at least as dark as either of the two con-
stituent colors. Multiplying any color with black produces black;
multiplying with white leaves the original color unchanged. Paint-
ing successive overlapping objects with a color other than black or
white produces progressively darker colors.
Screen Multiplies the complements of the backdrop and source color
values, then complements the result:
The result color is always at least as light as either of the two constit-
uent colors. Screening any color with white produces white; screen-
ing with black leaves the original color unchanged. The effect is
similar to projecting multiple photographic slides simultaneously
onto a single screen.
Overlay Multiplies or screens the colors, depending on the backdrop color.
Source colors overlay the backdrop while preserving its highlights
and shadows. The backdrop color is not replaced but is mixed with
the source color to reflect the lightness or darkness of the backdrop.
Darken Selects the darker of the backdrop and source colors:
The backdrop is replaced with the source where the source is dark-
er; otherwise, it is left unchanged.
Lighten Selects the lighter of the backdrop and source colors:
The backdrop is replaced with the source where the source is light-
er; otherwise, it is left unchanged.
Bc
b
c
s
,()c
s
=
Bc
b
c
s
,()c
b
c
s
×=
Bc
b
c
s
,()11c
b
–()1 c
s
–()×[]–=
c
b
c
s
c
b
c
s
×()–+=
Bc
b
c
s
,()min c
b
c
s
,()=
Bc
b
c
s
,()max c
b
c
s
,()=
TransparencyCHAPTER 7
492
Table 7.3 lists the standard nonseparable blend modes. Their effects are
described, but no mathematical formulas are given. These modes all entail con-
version to and from an intermediate HSL (hue-saturation-luminance) representa-
ColorDodge Brightens the backdrop color to reflect the source color. Painting
with black produces no change.
ColorBurn Darkens the backdrop color to reflect the source color. Painting
with white produces no change.
HardLight Multiplies or screens the colors, depending on the source color
value. If the source color is lighter than 0.5, the backdrop is light-
ened as if it were screened; this is useful for adding highlights to a
scene. If the source color is darker than 0.5, the backdrop is dark-
ened as if it were multiplied; this is useful for adding shadows to a
scene. The degree of lightening or darkening is proportional to the
difference between the source color and 0.5; if it is equal to 0.5, the
backdrop is unchanged. Painting with pure black or white produces
pure black or white. The effect is similar to shining a harsh spotlight
on the backdrop.
SoftLight Darkens or lightens the colors, depending on the source color value.
If the source color is lighter than 0.5, the backdrop is lightened as if
it were dodged; this is useful for adding highlights to a scene. If the
source color is darker than 0.5, the backdrop is darkened as if it
were burned in. The degree of lightening or darkening is propor-
tional to the difference between the source color and 0.5; if it is
equal to 0.5, the backdrop is unchanged. Painting with pure black or
white produces a distinctly darker or lighter area but does not result
in pure black or white. The effect is similar to shining a diffused
spotlight on the backdrop.
Difference Subtracts the darker of the two constituent colors from the lighter
color:
Painting with white inverts the backdrop color; painting with black
produces no change.
Exclusion Produces an effect similar to that of the Difference mode but lower
in contrast. Painting with white inverts the backdrop color; painting
with black produces no change.
NAME RESULT
Bc
b
c
s
,()c
b
c
s
–=
Basic Compositing ComputationsSECTION 7.2
493
tion. Since the nonseparable blend modes consider all color components in
combination, their computation depends on the blending color space in which
the components are interpreted.
TABLE 7.3 Standard nonseparable blend modes
Note: An additional standard blend mode, Compatible, is a vestige of an earlier de-
sign and is no longer needed but is still recognized for the sake of compatibility. Its
effect is equivalent to that of the
Normal blend mode. See “Compatibility with
Opaque Overprinting” on page 536 for further discussion.
7.2.5 Interpretation of Alpha
The color compositing formula
produces a result color that is a weighted average of the backdrop color, the
source color, and the blended B(C
b
, C
s
) term, with the weighting determined by
NAME RESULT
Hue Creates a color with the hue of the source color and the saturation
and luminance of the backdrop color.
Saturation Creates a color with the saturation of the source color and the hue
and luminance of the backdrop color. Painting with this mode in an
area of the backdrop that is a pure gray (no saturation) produces no
change.
Color Creates a color with the hue and saturation of the source color and
the luminance of the backdrop color. This preserves the gray levels
of the backdrop and is useful for coloring monochrome images or
tinting color images.
Luminosity Creates a color with the luminance of the source color and the hue
and saturation of the backdrop color. This produces an inverse
effect to that of the
Color mode.
C
r
1
s
r
-----–
C
b
×
s
r
-----
1
b
–()C
s
×
b
BC
b
C
s
,()×+[]×+=
TransparencyCHAPTER 7
494
the backdrop and source alphas
b
and
s
. For the simplest blend mode, Normal,
defined by
the compositing formula collapses to a simple weighted average of the backdrop
and source colors, controlled by the backdrop and source alpha values. For more
interesting blend functions, the backdrop and source alphas control whether the
effect of the blend mode is fully realized or is toned down by mixing the result
with the backdrop and source colors.
The result alpha,
r
, is actually a computed result, described below in Section
7.2.6, “Shape and Opacity Computations.” The result color is normalized by the
result alpha, ensuring that when this color and alpha are subsequently used to-
gether in another compositing operation, the color’s contribution is correctly rep-
resented. Note that if
r
is zero, the result color is undefined.
The formula shown above is a simplification of the following formula, which pre-
sents the relative contributions of backdrop, source, and blended colors in a more
straightforward way:
(The simplification requires a substitution based on the alpha compositing for-
mula, which is presented in the next section.) Thus, mathematically, the back-
drop and source alphas control the influence of the backdrop and source colors,
respectively, while their product controls the influence of the blend function. An
alpha value of
s
= 0.0 or
b
= 0.0 results in no blend mode effect; setting
s
= 1.0
and
b
= 1.0 results in maximum blend mode effect.
7.2.6 Shape and Opacity Computations
As stated earlier, the alpha values that control the compositing process are de-
fined as the product of shape and opacity:
Bc
b
˙
c
s
,()c
s
=
r
C
r
× 1
s
–()
b
C
b
××[]1
b
–()
s
C
s
××[]
b
s
BC
b
C
s
,()××[]++=
b
f
b
q
b
×=
r
f
r
q
r
×=
s
f
s
q
s
×=
Basic Compositing ComputationsSECTION 7.2
495
This section examines the various shape and opacity values individually. Once
again, keep in mind that conceptually these values are computed for every point
on the page.
Source Shape and Opacity
Shape and opacity values can come from several sources. The transparency mod-
el provides for three independent sources for each. However, the PDF representa-
tion imposes some limitations on the ability to specify all of these sources
independently (see Section 7.5.3, “Specifying Shape and Opacity”).
• Object shape. Elementary objects such as strokes, fills, and text have an intrin-
sic shape, whose value is 1.0 for points inside the object and 0.0 outside. Simi-
larly, an image with an explicit mask (see “Explicit Masking” on page 321) has
a shape that is 1.0 in the unmasked portions and 0.0 in the masked portions.
The shape of a group object is the union of the shapes of the objects it con-
tains.
Note: Mathematically, elementary objects have “hard” edges, with a shape value
of either 0.0 or 1.0 at every point. However, when such objects are rasterized to
device pixels, the shape values along the boundaries may be anti-aliased, taking
on fractional values representing fractional coverage of those pixels. When such
anti-aliasing is performed, it is important to treat the fractional coverage as shape
rather than opacity.
• Mask shape. Shape values for compositing an object can be taken from an addi-
tional source, or soft mask, independent of the object itself. (See Section 7.4,
“Soft Masks,” for a discussion of how such a mask might be generated.) The use
of a soft mask to modify the shape of an object or group, called soft clipping, can
produce effects such as a gradual transition between an object and its backdrop,
as in a vignette.
• Constant shape. The source shape can be modified at every point by a scalar
shape constant. This is merely a convenience, since the same effect could be
achieved with a shape mask whose value is the same everywhere.
• Object opacity. Elementary objects have an opacity of 1.0 everywhere. The
opacity of a group object is the result of the opacity computations for all of the
objects it contains.
• Mask opacity. Opacity values, like shape values, can be provided by a soft mask
independent of the object being composited.
TransparencyCHAPTER 7
496
• Constant opacity. The source opacity can be modified at every point by a scalar
opacity constant. It is useful to think of this value as the “current opacity,” analo-
gous to the current color used when painting elementary objects.
All of these shape and opacity inputs range in value from 0.0 to 1.0, with a default
value of 1.0. The intent is that any of the inputs make the painting operation more
transparent as it goes toward 0.0. If more than one input goes toward 0.0, the ef-
fect is compounded. This is achieved mathematically by simply multiplying the
three inputs of each type, producing intermediate values called the source shape
and the source opacity:
where the variables have the meanings shown in Table 7.4.
TABLE 7.4 Variables used in the source shape and opacity formulas
Note: When an object is painted with a tiling pattern, the object shape and object
opacity for points in the object’s interior are determined by those of corresponding
points in the pattern, rather than being 1.0 everywhere (see Section 7.5.6, “Patterns
and Transparency”).
VARIABLE MEANING
Source shape
Object shape
Mask shape
Constant shape
Source opacity
Object opacity
Mask opacity
Constant opacity
f
s
f
j
f
m
f
k
××=
q
s
q
j
q
m
q
k
××=
f
s
f
j
f
m
f
k
q
s
q
j
q
m
q
k
Basic Compositing ComputationsSECTION 7.2
497
Result Shape and Opacity
In addition to a result color, the painting operation also computes an associated
result shape and result opacity. These computations are based on the union func-
tion
where b and s are the backdrop and source values to be composited. This is a gen-
eralization of the conventional concept of union for opaque shapes, and it can be
thought of as an “inverted multiplication”—a multiplication with the inputs and
outputs complemented. The result tends toward 1.0: if either input is 1.0, the re-
sult is 1.0.
The result shape and opacity are given by
where the variables have the meanings shown in Table 7.5.
TABLE 7.5 Variables used in the result shape and opacity formulas
VARIABLE MEANING
Result shape
Backdrop shape
Source shape
Result opacity
Backdrop opacity
Source opacity
Union bs,()11b–()1 s–()×[]–=
bs bs×()–+=
f
r
Union f
b
f
s
,()=
q
r
Union f
b
q
b
× f
s
q
s
×,()
f
r
---------------------------------------------------------=
f
r
f
b
f
s
q
r
q
b
q
s
TransparencyCHAPTER 7
498
These formulas can be interpreted as follows:
• The result shape is simply the union of the backdrop and source shapes.
• The result opacity is the union of the backdrop and source opacities, weighted
by their respective shapes. The result is then normalized by the result shape,
ensuring that when this shape and opacity are subsequently used together in
another compositing operation, the opacity’s contribution is correctly repre-
sented.
Since alpha is just the product of shape and opacity, it can easily be shown that
This formula can be used whenever the independent shape and opacity results
are not needed.
7.2.7 Summary of Basic Compositing Computations
Below is a summary of all the computations presented in this section. They are
given in an order such that no variable is used before it is computed; also, some of
the formulas have been rearranged to simplify them. See Tables 7.1, 7.4, and 7.5
above for the meanings of the variables used in these formulas.
r
Union
b
s
,()=
Union bs,()11b–()1 s–()×[]–=
bs bs×()–+=
f
s
f
j
f
m
f
k
××=
q
s
q
j
q
m
q
k
××=
f
r
Union f
b
˙
f
s
,()=
b
f
b
q
b
×=
s
f
s
q
s
×=
r
Union
b
s
,()=
q
r
r
f
r
-----=
C
r
1
s
r
-----–
C
b
×
s
r
-----
1
b
–()C
s
×
b
BC
b
C
s
,()×+[]×+=
Transparency GroupsSECTION 7.3
499
7.3 Transparency Groups
A transparency group is a sequence of consecutive objects in a transparency stack
that are collected together and composited to produce a single color, shape, and
opacity at each point. The result is then treated as if it were a single object for sub-
sequent compositing operations. This facilitates creating independent pieces of
artwork, each composed of multiple objects, and then combining them, possibly
with additional transparency effects applied during the combination. Groups can
be nested within other groups to form a tree-structured group hierarchy.
The objects contained within a group are treated as a separate transparency stack
called the group stack. The objects in the stack are composited against some initial
backdrop (discussed later), producing a composite color, shape, and opacity for
the group as a whole. The result is an object whose shape is the union of the
shapes of its constituent objects and whose color and opacity are the result of the
compositing operations. This object is then composited with the group’s back-
drop in the usual way.
In addition to its computed color, shape, and opacity, the group as a whole can
have several further attributes:
• All of the input variables that affect the compositing computation for individu-
al objects can also be applied when compositing the group with its backdrop.
These variables include mask and constant shape, mask and constant opacity,
and blend mode.
• The group can be isolated or non-isolated, determining the initial backdrop
against which its stack is composited.
• The group can be knockout or non-knockout, determining whether the objects
within its stack are composited with one another or only with the group’s back-
drop.
• An isolated group can specify its own blending color space, independent of that
of the group’s backdrop.
• Instead of being composited onto the current page, a group’s results can be used
as a source of shape or opacity values for creating a soft mask (see Section 7.4,
“Soft Masks”).
TransparencyCHAPTER 7
500
The next section introduces some notation for dealing with group compositing.
Subsequent sections describe the group compositing formulas for a non-isolated,
non-knockout group and the special properties of isolated and knockout groups.
7.3.1 Notation for Group Compositing Computations
Since we are now dealing with multiple objects at a time, it is useful to have some
notation for distinguishing among them. Accordingly, the variables introduced
earlier are altered to include a second-level subscript denoting an object’s position
in the transparency stack. Thus, for example, stands for the source color of
the ith object in the stack. The subscript 0 represents the initial backdrop; sub-
scripts 1 to n denote the bottommost to topmost objects in an n-element stack. In
addition, the subscripts b and r are dropped from the variables C
b
, f
b
, q
b
,
b
, C
r
,
f
r
, q
r
, and
r
; other variables retain their mnemonic subscripts.
These conventions permit the compositing formulas to be restated as recurrence
relations among the elements of a stack. For instance, the result of the color com-
positing computation for object i is denoted by C
i
(formerly C
r
). This computa-
tion takes as one of its inputs the immediate backdrop color, which is the result of
the color compositing computation for object i 1; this is denoted by C
i 1
(formerly C
b
).
The revised formulas for a simple n-element stack (not including any groups) are,
for i = 1, …, n:
C
s
i
f
s
i
f
j
i
f
m
i
f
k
i
××=
q
s
i
q
j
i
q
m
i
q
k
i
××=
s
i
f
s
i
q
s
i
×=
i
Union
i 1–
s
i
,()=
f
i
Union f
i 1–
f
s
i
,()=
q
i
i
f
i
-----=
Transparency GroupsSECTION 7.3
501
where the variables have the meanings shown in Table 7.6. Compare these
formulas with those shown in Section 7.2.7, “Summary of Basic Compositing
Computations.”
TABLE 7.6 Revised variables for the basic compositing formulas
VARIABLE MEANING
Source shape for object i
Object shape for object i
Mask shape for object i
Constant shape for object i
Result shape after compositing object i
Source opacity for object i
Object opacity for object i
Mask opacity for object i
Constant opacity for object i
Result opacity after compositing object i
Source alpha for object i
Result alpha after compositing object i
Source color for object i
Result color after compositing object i
Blend function for object i
C
i
1
s
i
i
-------–
C
i 1–
×
s
i
i
-------
1
i 1–
–()C
s
i
×
i 1–
B
i
C
i 1–
C
s
i
,()×+[]×+=
f
s
i
f
j
i
f
m
i
f
k
i
f
i
q
s
i
q
j
i
q
m
i
q
k
i
q
i
s
i
i
C
s
i
C
i
B
i
C
i 1–
C
s
i
,()
TransparencyCHAPTER 7
502
7.3.2 Group Structure and Nomenclature
As stated earlier, the elements of a group are treated as a separate transparency
stack, the group stack. These objects are composited against a selected initial
backdrop (to be described) and the resulting color, shape, and opacity are then
treated as if they belonged to a single object. The resulting object is in turn com-
posited with the group’s backdrop in the usual way.
This computation entails interpreting the stack as a tree. For an n-element group
that begins at position i in the stack, it treats the next n objects as an n-element
substack, whose elements are given an independent numbering of 1 to n. These
objects are then removed from the object numbering in the parent (containing)
stack and replaced by the group object, numbered i, followed by the remaining
objects to be painted on top of the group, renumbered starting at i + 1. This oper-
ation applies recursively to any nested subgroups. Henceforth, the term element
(denoted E
i
) refers to a member of some group; it can be either an individual ob-
ject or a contained subgroup.
From the perspective of a particular element in a nested group, there are three
different backdrops of interest:
• The group backdrop is the result of compositing all elements up to but not in-
cluding the first element in the group. (This definition is altered if the parent
group is a knockout group; see Section 7.3.5, “Knockout Groups.”)
• The initial backdrop is a backdrop that is selected for compositing the group’s
first element. This is either the same as the group backdrop (for a non-isolated
group) or a fully transparent backdrop (for an isolated group).
• The immediate backdrop is the result of compositing all elements in the group
up to but not including the current element.
When all elements in a group have been composited, the result is treated as if the
group were a single object, which is then composited with the group backdrop.
(This operation occurs whether the initial backdrop chosen for compositing the
elements of the group was the group backdrop or a transparent backdrop. There
is a special correction to ensure that the backdrop’s contribution to the overall re-
sult is applied only once.)
Transparency GroupsSECTION 7.3
503
7.3.3 Group Compositing Computations
The color and opacity of a group are defined by the group compositing function:
where the variables have the meanings shown in Table 7.7.
TABLE 7.7 Arguments and results of the group compositing function
Note that the opacity is not given explicitly as an argument or result of this func-
tion. Almost all of the computations use the product of shape and opacity (alpha)
rather than opacity alone; therefore, it is usually convenient to work directly with
shape and alpha rather than shape and opacity. When needed, the opacity can be
computed by dividing the alpha by the associated shape.
The result of applying the group compositing function is then treated as if it were
a single object, which in turn is composited with the group’s backdrop according
to the usual formulas. In those formulas, the color, shape, and alpha (C, f, and
)
calculated by the group compositing function are used, respectively, as the source
color C
s
, the object shape f
j
, and the object alpha
j
.
VARIABLE MEANING
The transparency group: a compound object consisting of all ele-
ments E
1
, … , E
n
of the group—the n constituent objects’ colors,
shapes, opacities, and blend modes
Color of the group’s backdrop
Computed color of the group, to be used as the source color when
the group is treated as an object
Computed shape of the group, to be used as the object shape when
the group is treated as an object
Alpha of the group’s backdrop
Computed alpha of the group, to be used as the object alpha when
the group is treated as an object
Cf
,,Composite C
0
0
G,,()=
G
C
0
C
f
0
TransparencyCHAPTER 7
504
The group compositing formulas for a non-isolated, non-knockout group are de-
fined as follows:
• Initialization:
• For each group element E
i
G (i = 1, …, n):
• Result:
where the variables have the meanings shown in Table 7.8 (in addition to those in
Table 7.7 above).
For an element E
i
that is an elementary object, the color, shape, and alpha
values , , and are intrinsic attributes of the object. For an element that is
a group, the group compositing function is applied recursively to the subgroup
and the resulting C, f, and
values are used for its , , and in the calcula-
tions for the parent group.
f
g
0
g
0
0.0==
C
s
i
f
j
i
j
i
,,
Composite C
i 1–
i 1–
E
i
,,()
intrinsic color, shape, and shape opacity×() of E
i
=
if E
i
is a group
otherwise
f
s
i
f
j
i
f
m
i
f
k
i
××=
s
i
j
i
f
m
i
q
m
i
×()f
k
i
q
k
i
×()××=
f
g
i
Union f
g
i 1–
f
s
i
,()=
g
i
Union
g
i 1–
s
i
,()=
i
Union
0
g
i
,()=
C
i
1
s
i
i
-------–
C
i 1–
×
s
i
i
-------
1
i 1–
–()C
s
i
×
i 1–
B
i
C
i 1–
C
s
i
,()×+()×+=
CC
n
C
n
C
0
–()
0
g
n
--------
0
–
×+=
ff
g
n
=
g
n
=
C
s
i
f
j
i
j
i
C
s
i
f
j
i
j
i
Transparency GroupsSECTION 7.3
505
TABLE 7.8 Variables used in the group compositing formulas
Note that the elements of a group are composited onto a backdrop that includes
the group’s initial backdrop. This is done to achieve the correct effects of the
blend modes, most of which are dependent on both the backdrop and source col-
VARIABLE MEANING
Element i of the group: a compound variable representing the ele-
ment’s color, shape, opacity, and blend mode
Source shape for element E
i
Object shape for element E
i
Mask shape for element E
i
Constant shape for element E
i
Group shape: the accumulated source shapes of group elements E
1
to E
i
, excluding the initial backdrop
Mask opacity for element E
i
Constant opacity for element E
i
Source alpha for element E
i
Object alpha for element E
i
: the product of its object shape and ob-
ject opacity
Group alpha: the accumulated source alphas of group elements E
1
to E
i
, excluding the initial backdrop
Accumulated alpha after compositing element E
i
, including the ini-
tial backdrop
Source color for element E
i
Accumulated color after compositing element E
i
, including the ini-
tial backdrop
Blend function for element E
i
E
i
f
s
i
f
j
i
f
m
i
f
k
i
f
g
i
q
m
i
q
k
i
s
i
j
i
g
i
i
C
s
i
C
i
B
i
C
i 1–
C
s
i
,()
TransparencyCHAPTER 7
506
ors being blended. (This feature is what distinguishes non-isolated groups from
isolated groups, discussed in the next section.)
Special attention should be directed to the formulas at the end that compute the
final results, C, f, and
, of the group compositing function. Essentially, these for-
mulas remove the contribution of the group backdrop from the computed results.
This ensures that when the group is subsequently composited with that backdrop
(possibly with additional shape or opacity inputs or a different blend mode), the
backdrop’s contribution is included only once.
For color, the backdrop removal is accomplished by an explicit calculation, whose
effect is essentially the reverse of compositing with the
Normal blend mode. The
formula is a simplification of the following formulas, which present this opera-
tion more intuitively:
where
b
is the backdrop fraction, the relative contribution of the backdrop color
to the overall color.
For shape and alpha, backdrop removal is accomplished by maintaining two sets
of variables to hold the accumulated values. The group shape and alpha,
and , accumulate only the shape and alpha of the group elements, exclud-
ing the group backdrop. Their final values become the group results returned by
the group compositing function. The complete alpha,
i
, includes the backdrop
contribution as well; its value is used in the color compositing computations.
(There is never any need to compute the corresponding complete shape, f
i
, that
includes the backdrop contribution.)
b
1
g
n
–()
0
×
Union
0
g
n
,()
---------------------------------------=
C
C
n
b
C
0
×–
1
b
–
-------------------------------=
f
g
i
g
i
Transparency GroupsSECTION 7.3
507
As a result of these corrections, the effect of compositing objects as a group is the
same as that of compositing them separately (without grouping) if the following
conditions hold:
• The group is non-isolated and has the same knockout attribute as its parent
group (see Sections 7.3.4, “Isolated Groups,” and 7.3.5, “Knockout Groups”).
• When compositing the group’s results with the group backdrop, the Normal
blend mode is used, and the shape and opacity inputs are always 1.0.
7.3.4 Isolated Groups
An isolated group is one whose elements are composited onto a fully transparent
initial backdrop rather than onto the group’s backdrop. The resulting source
color, object shape, and object alpha for the group are therefore independent of
the group backdrop. The only interaction with the group backdrop occurs when
the group’s computed color, shape, and alpha are then composited with it.
In particular, the special effects produced by the blend modes of objects within
the group take into account only the intrinsic colors and opacities of those ob-
jects; they are not influenced by the group’s backdrop. For example, applying the
Multiply blend mode to an object in the group produces a darkening effect on
other objects lower in the group’s stack but not on the group’s backdrop.
Plate 17 illustrates this effect for a group consisting of four overlapping circles in a
light gray color (C = M = Y = 0.0; K = 0.15). The circles are painted within the
group with opacity 1.0 in the
Multiply blend mode; the group itself is painted
against its backdrop in
Normal blend mode. In the top row, the group is isolated
and thus does not interact with the rainbow backdrop. In the bottom row, the
group is non-isolated and composites with the backdrop. The plate also illustrates
the difference between knockout and non-knockout groups (see Section 7.3.5,
“Knockout Groups”).
The effect of an isolated group can be represented by a simple object that directly
specifies a color, shape, and opacity at each point. This flattening of an isolated
group is sometimes useful for importing and exporting fully composited artwork
in applications. Furthermore, a group that specifies an explicit blending color
space must be an isolated group.
TransparencyCHAPTER 7
508
For an isolated group, the group compositing formulas are altered by simply add-
ing one statement to the initialization:
That is, the initial backdrop on which the elements of the group are composited is
transparent rather than inherited from the group’s backdrop. This substitution
also makes C
0
undefined, but the normal compositing formulas take care of that.
Also, the result computation for C automatically simplifies to C = C
n
, since there
is no backdrop contribution to be factored out.
7.3.5 Knockout Groups
In a knockout group, each individual element is composited with the group’s
initial backdrop rather than with the stack of preceding elements in the group.
When objects have binary shapes (1.0 for inside, 0.0 for outside), each object
overwrites (knocks out) the effects of any earlier elements it overlaps within the
same group. At any given point, only the topmost object enclosing the point con-
tributes to the result color and opacity of the group as a whole.
Plate 17, already discussed above in Section 7.3.4, “Isolated Groups,” illustrates
the difference between knockout and non-knockout groups. In the left column,
the four overlapping circles are defined as a knockout group and therefore do not
composite with each other within the group. In the right column, the circles form
a non-knockout group and thus do composite with each other. In each column,
the upper and lower figures depict an isolated and a non-isolated group, respec-
tively.
This model is similar to the opaque imaging model, except that the “topmost
object wins” rule applies to both the color and the opacity. Knockout groups are
useful in composing a piece of artwork from a collection of overlapping objects,
where the topmost object in any overlap completely obscures those beneath. At
the same time, the topmost object interacts with the group’s initial backdrop in
the usual way, with its opacity and blend mode applied as appropriate.
The concept of knockout is generalized to accommodate fractional shape values.
In that case, the immediate backdrop is only partially knocked out and replaced
by only a fraction of the result of compositing the object with the initial backdrop.
0
0.0= if the group is isolated
Transparency GroupsSECTION 7.3
509
The restated group compositing formulas deal with knockout groups by intro-
ducing a new variable, b, which is a subscript that specifies which previous result
to use as the backdrop in the compositing computations: 0 in a knockout group
or i 1 in a non-knockout group. When b = i 1, the formulas simplify to the
ones given in Section 7.3.3, “Group Compositing Computations.”
In the general case, the computation proceeds in two stages:
1. Composite the object with the group’s initial backdrop, disregarding the ob-
ject’s shape and using a source shape value of 1.0 everywhere. This produces
unnormalized temporary alpha and color results,
t
and C
t
. (For color, this
computation is essentially the same as the unsimplified color compositing for-
mula given in Section 7.2.5, “Interpretation of Alpha,” but using a source shape
of 1.0.)
2. Compute a weighted average of this result with the object’s immediate back-
drop, using the source shape as the weighting factor. Then normalize the result
color by the result alpha:
This averaging computation is performed for both color and alpha. The formulas
above show this averaging directly. The formulas in Section 7.3.7, “Summary of
Group Compositing Computations,” are slightly altered to use source shape and
alpha rather than source shape and opacity, avoiding the need to compute a
source opacity value explicitly. (Note that C
t
there is slightly different from C
t
above: it is premultiplied by .)
The extreme values of the source shape produce the straightforward knockout
effect. That is, a shape value of 1.0 (inside) yields the color and opacity that result
from compositing the object with the initial backdrop. A shape value of 0.0 (out-
side) leaves the previous group results unchanged. The existence of the knockout
t
Union
g
b
q
s
i
,()=
C
t
1 q
s
i
–()
b
C
b
×× q
s
i
1
b
–()C
s
i
×
b
B
i
C
b
C
s
i
,()×+()×+=
g
i
1 f
s
i
–()
g
i 1–
× f
s
i
t
×+=
i
Union
0
g
i
,()=
C
i
1 f
s
i
–()
i 1–
C
i 1–
×× f
s
i
C
t
×+
i
----------------------------------------------------------------------------------=
f
s
i
TransparencyCHAPTER 7
510
feature is the main reason for maintaining a separate shape value rather than only
a single alpha that combines shape and opacity. The separate shape value must be
computed in any group that is subsequently used as an element of a knockout
group.
A knockout group can be isolated or non-isolated; that is, isolated and knockout
are independent attributes. A non-isolated knockout group composites its top-
most enclosing element with the group’s backdrop. An isolated knockout group
composites the element with a transparent backdrop.
Note: When a non-isolated group is nested within a knockout group, the initial
backdrop of the inner group is the same as that of the outer group; it is not the im-
mediate backdrop of the inner group. This behavior, although perhaps unexpected,
is a consequence of the group compositing formulas when b
=
0.
7.3.6 Page Group
All of the elements painted directly onto a page—both top-level groups and top-
level objects that are not part of any group—are treated as if they were contained
in a transparency group P, which in turn is composited with a context-dependent
backdrop. This group is called the page group.
The page group can be treated in two distinctly different ways:
• Ordinarily, the page is imposed directly on an output medium, such as paper or
a display screen. The page group is treated as an isolated group, whose results
are then composited with a backdrop color appropriate for the medium. The
backdrop is nominally white, although varying according to the actual proper-
ties of the medium. However, some applications may choose to provide a dif-
ferent backdrop, such as a checkerboard or grid to aid in visualizing the effects
of transparency in the artwork.
• A “page” of a PDF file can be treated as a graphics object to be used as an ele-
ment of a page of some other document. This case arises, for example, when
placing a PDF file containing a piece of artwork produced by Illustrator into a
page layout produced by InDesign®. In this situation, the PDF “page” is not
composited with the media color; instead, it is treated as an ordinary transpar-
ency group, which can be either isolated or non-isolated and is composited
with its backdrop in the normal way.
Transparency GroupsSECTION 7.3
511
The remainder of this section pertains only to the first use of the page group,
where it is to be imposed directly on the medium.
The color C of the page at a given point is defined by a simplification of the gen-
eral group compositing formula:
where the variables have the meanings shown in Table 7.9. The first formula com-
putes the color and alpha for the group given a transparent backdrop—in effect,
treating P as an isolated group. The second formula composites the results with
the context-dependent backdrop (using the equivalent of the
Normal blend
mode).
TABLE 7.9 Variables used in the page group compositing formulas
If not otherwise specified, the page group’s color space is inherited from the
native color space of the output device—that is, a device color space, such as
DeviceRGB or DeviceCMYK. It is often preferable to specify an explicit color space,
particularly a CIE-based space, to ensure more predictable results of the compos-
iting computations within the page group. In this case, all page-level compositing
is done in the specified color space, with the entire result then converted to the
VARIABLE MEANING
The page group, consisting of all elements E
1
, … , E
n
in the page’s
top-level stack
Computed color of the page group
Computed shape of the page group
Computed alpha of the page group
Computed color of the page
Initial color of the page (nominally white but may vary depending
on the properties of the medium or the needs of the application)
An undefined color (which is not used, since the
0
argument of
Composite is 0)
C
g
f
g
g
,,Composite U
˙
0 P,,()=
C 1
g
–()W×
g
C
g
×+=
P
C
g
f
g
g
C
W
U
TransparencyCHAPTER 7
512
native color space of the output device before being composited with the context-
dependent backdrop. This case also arises when the page is not actually being
rendered but is converted to a flattened representation in an opaque imaging
model, such as PostScript.
7.3.7 Summary of Group Compositing Computations
The following restatement of the group compositing formulas also takes isolated
groups and knockout groups into account. See Tables 7.7 and 7.8 on pages 503
and 505 for the meanings of the variables.
• Initialization:
• For each group element E
i
G (i = 1, …, n):
Cf
,,Composite C
0
0
G,,()=
f
g
0
g
0
0==
0
0 if the group is isolated=
b
0
i 1–
=
if the group is knockout
otherwise
C
s
i
f
j
i
j
i
,,
Composite C
b
b
E
i
,,()
intrinsic color, shape, and shape opacity×() of E
i
=
if E
i
is a group
otherwise
f
s
i
f
j
i
f
m
i
f
k
i
××=
s
i
j
i
f
m
i
q
m
i
×()f
k
i
q
k
i
×()××=
f
g
i
Union f
g
i 1–
f
s
i
,()=
g
i
1 f
s
i
–()
g
i 1–
× f
s
i
s
i
–()
g
b
×
s
i
++=
i
Union
0
g
i
,()=
C
t
f
s
i
s
i
–()
b
C
b
××
s
i
1
b
–()C
s
i
×
b
B
i
C
b
C
s
i
,()×+()×+=
Soft MasksSECTION 7.4
513
• Result:
Note: Once again, keep in mind that these formulas are in their most general form.
They can be significantly simplified when some sources of shape and opacity are not
present or when shape and opacity need not be maintained separately. Furthermore,
in each specific type of group (isolated or not, knockout or not), some terms of these
formulas cancel or drop out. An efficient implementation should use the simplified
derived formulas.
7.4 Soft Masks
As stated in earlier sections, the shape and opacity values used in compositing an
object can include components called the mask shape (f
m
) and mask opacity
(q
m
), which originate from a source independent of the object. Such an indepen-
dent source, called a soft mask, defines values that can vary across different points
on the page. The word soft emphasizes that the mask value at a given point is not
limited to just 0.0 or 1.0 but can take on intermediate fractional values as well.
Such a mask is typically the only means of providing position-dependent opacity
values, since elementary objects do not have intrinsic opacity of their own.
A mask used as a source of shape values is also called a soft clip, by analogy with
the “hard” clipping path of the opaque imaging model (see Section 4.4.3, “Clip-
ping Path Operators”). The soft clip is a generalization of the hard clip: a hard clip
can be represented as a soft clip having shape values of 1.0 inside and 0.0 outside
the clipping path. Everywhere inside a hard clipping path, the source object’s col-
or replaces the backdrop; everywhere outside, the backdrop shows through un-
changed. With a soft clip, by contrast, a gradual transition can be created between
an object and its backdrop, as in a vignette.
C
i
1 f
s
i
–()
i 1–
C
i 1–
×× C
t
+
i
------------------------------------------------------------------------=
CC
n
C
n
C
0
–()
0
g
n
--------
0
–
×+=
ff
g
n
=
g
n
=
TransparencyCHAPTER 7
514
A mask can be defined by creating a transparency group and painting objects into
it, thereby defining color, shape, and opacity in the usual way. The resulting group
can then be used to derive the mask in either of two ways, as described in the fol-
lowing sections.
7.4.1 Deriving a Soft Mask from Group Alpha
In the first method of defining a soft mask, the color, shape, and opacity of a
transparency group G are first computed by the usual formula
where C
0
and
0
represent an arbitrary backdrop whose value does not contrib-
ute to the eventual result. The C, f, and
results are the group’s color, shape, and
alpha, respectively, with the backdrop factored out.
The mask value at each point is then derived from the alpha of the group. Since
the group’s color is not used in this case, there is no need to compute it. The alpha
value is passed through a separately specified transfer function, allowing the
masking effect to be customized.
7.4.2 Deriving a Soft Mask from Group Luminosity
The second method of deriving a soft mask from a transparency group begins by
compositing the group with a fully opaque backdrop of some selected color. The
mask value at any given point is then defined to be the luminosity of the resulting
color. This allows the mask to be derived from the shape and color of an arbitrary
piece of artwork drawn with ordinary painting operators.
The color C used to create the mask from a group G is defined by
where C
0
is the selected backdrop color.
Cf
,,Composite C
0
0
G,,()=
C
g
f
g
g
,,Composite C
0
˙
1 G,,()=
C 1
g
–()C
0
×
g
C
g
×+=
Specifying Transparency in PDFSECTION 7.5
515
G can be any kind of group—isolated or not, knockout or not—producing vari-
ous effects on the C result in each case. The color C is then converted to luminos-
ity in one of the following ways, depending on the group’s color space:
• For CIE-based spaces, convert to the CIE 1931 XYZ space and use the Y com-
ponent as the luminosity. This produces a colorimetrically correct luminosity.
In the case of a PDF
CalRGB space, the formula is
using components of the
Gamma and Matrix entries of the color space dictio-
nary (see Table 4.14 on page 218). An analogous computation applies to other
CIE-based color spaces.
• For device color spaces, convert the color to DeviceGray by device-dependent
means and use the resulting gray value as the luminosity, with no compensa-
tion for gamma or other color calibration. This method makes no pretense of
colorimetric correctness; it merely provides a numerically simple means to pro-
duce continuous-tone mask values. Here are some recommended formulas for
converting from
DeviceRGB and DeviceCMYK, respectively:
Following this conversion, the result is passed through a separately specified
transfer function, allowing the masking effect to be customized.
The backdrop color most likely to be useful is black, which causes any areas out-
side the group’s shape to have zero luminosity values in the resulting mask. If the
contents of the group are viewed as a positive mask, this produces the results that
would be expected with respect to points outside the shape.
7.5 Specifying Transparency in PDF
The preceding sections have presented the transparent imaging model at an
abstract level, with little mention of its representation in PDF. This section
describes the facilities available for specifying transparency in PDF 1.4.
YY
A
A
G
R
× Y
B
B
G
G
× Y
C
C
G
B
×++=
Y 0.30 R× 0.59 G× 0.11 B×++=
Y 0.30 1 C–()× 1 K–()×=
0.59 1 M–()× 1 K–()×+
0.11 1 Y–()× 1 K–()×+
TransparencyCHAPTER 7
516
7.5.1 Specifying Source and Backdrop Colors
Single graphics objects, as defined in Section 4.1, “Graphics Objects,” are treated
as elementary objects for transparency compositing purposes (subject to special
treatment for text objects, as described in Section 5.2.7, “Text Knockout”). That
is, all of a given object is considered to be one element of a transparency stack.
Portions of an object are not composited with one another, even if they are de-
scribed in a way that would seem to cause overlaps (such as a self-intersecting
path, combined fill and stroke of a path, or a shading pattern containing an
overlap or fold-over). An object’s source color C
s
, used in the color compositing
formula, is specified in the same way as in the opaque imaging model: by means
of the current color in the graphics state or the source samples in an image. The
backdrop color C
b
is the result of previous painting operations.
7.5.2 Specifying Blending Color Space and Blend Mode
The blending color space is an attribute of the transparency group within which
an object is painted; its specification is described in Section 7.5.5, “Transparency
Group XObjects.” The page as a whole is also treated as a group, the page group
(see Section 7.3.6, “Page Group”), with a color space attribute of its own. If not
otherwise specified, the page group’s color space is inherited from the native color
space of the output device.
The blend mode B(C
b
, C
s
) is determined by the current blend mode parameter in
the graphics state (see Section 4.3, “Graphics State”), which is specified by the
BM
entry in a graphics state parameter dictionary (Section 4.3.4, “Graphics State Pa-
rameter Dictionaries”). Its value is either a name object, designating one of the
standard blend modes listed in Tables 7.2 and 7.3 on pages 491 and 493, or an ar-
ray of such names. In the latter case, the application should use the first blend
mode in the array that it recognizes (or
Normal if it recognizes none of them).
Therefore, new blend modes can be introduced in the future, and applications
that do not recognize them have reasonable fallback behavior. (See implementa-
tion note 71 in Appendix H.)
Note: The current blend mode always applies to process color components but only
sometimes to spot colorants; see “Blend Modes and Overprinting” on page 534 for
details.
Specifying Transparency in PDFSECTION 7.5
517
7.5.3 Specifying Shape and Opacity
As discussed under “Source Shape and Opacity” on page 495, the shape (f) and
opacity (q) values used in the compositing computation can come from a variety
of sources:
• The intrinsic shape (f
j
) and opacity (q
j
) of the object being composited
• A separate shape (f
m
) or opacity (q
m
) mask independent of the object itself
• A scalar shape (f
k
) or opacity (q
k
) constant to be added at every point
The following sections describe how each of these shape and opacity sources are
specified in PDF.
Object Shape and Opacity
The shape value f
j
of an object painted with PDF painting operators is defined as
follows:
• For objects defined by a path or a glyph and painted in a uniform color with a
path-painting or text-showing operator (Sections 4.4.2, “Path-Painting Opera-
tors,” and 5.3.2, “Text-Showing Operators”), the shape is always 1.0 inside and
0.0 outside the path.
• For images (Section 4.8, “Images”), the shape is nominally 1.0 inside the image
rectangle and 0.0 outside it. This can be further modified by an explicit or color
key mask (“Explicit Masking” on page 321 and “Color Key Masking” on page
321).
• For image masks (“Stencil Masking” on page 320), the shape is 1.0 for painted
areas and 0.0 for masked areas.
• For objects painted with a tiling pattern (Section 4.6.2, “Tiling Patterns”) or a
shading pattern (Section 4.6.3, “Shading Patterns), the shape is further con-
strained by the objects that define the pattern (see Section 7.5.6, “Patterns and
Transparency”).
• For objects painted with the sh operator (“Shading Operator” on page 273), the
shape is 1.0 inside and 0.0 outside the bounds of the shading’s painting
geometry, disregarding the
Background entry in the shading dictionary (see
“Shading Dictionaries” on page 274).
TransparencyCHAPTER 7
518
All elementary objects have an intrinsic opacity q
j
of 1.0 everywhere. Any desired
opacity less than 1.0 must be applied by means of an opacity mask or constant, as
described in the following sections.
Mask Shape and Opacity
At most one mask input—called a soft mask, or alpha mask—can be provided to
any PDF compositing operation. The mask can serve as a source of either shape
(f
m
) or opacity (q
m
) values, depending on the setting of the alpha source parame-
ter in the graphics state (see Section 4.3, “Graphics State”). This is a boolean flag,
set with the
AIS (“alpha is shape”) entry in a graphics state parameter dictionary
(Section 4.3.4, “Graphics State Parameter Dictionaries”):
true if the soft mask
contains shape values,
false for opacity.
The soft mask can be specified in one of the following ways:
• The current soft mask parameter in the graphics state, set with the SMask entry
in a graphics state parameter dictionary, contains a soft-mask dictionary (see
“Soft-Mask Dictionaries” on page 520) defining the contents of the mask. The
name
None may be specified in place of a soft-mask dictionary, denoting the
absence of a soft mask. In this case, the mask shape or opacity is implicitly 1.0
everywhere. (See implementation note 71 in Appendix H.)
• An image XObject can contain its own soft-mask image in the form of a subsid-
iary image XObject in the
SMask entry of the image dictionary (see Section
4.8.4, “Image Dictionaries”). This mask, if present, overrides any explicit or col-
or key mask specified by the image dictionary’s
Mask entry. Either form of
mask in the image dictionary overrides the current soft mask in the graphics
state. (See implementation note 72 in Appendix H.)
• An image XObject that has a JPXDecode filter as its data source can specify an
SMaskInData entry, indicating that the soft mask is embedded in the data
stream (see Section 3.3.8, “JPXDecode Filter”).
Note: The current soft mask in the graphics state is intended to be used to clip only a
single object at a time (either an elementary object or a transparency group). If a
soft mask is applied when painting two or more overlapping objects, the effect of the
mask multiplies with itself in the area of overlap (except in a knockout group), pro-
ducing a result shape or opacity that is probably not what is intended. To apply a
soft mask to multiple objects, it is usually best to define the objects as a transparency
Specifying Transparency in PDFSECTION 7.5
519
group and apply the mask to the group as a whole. These considerations also apply
to the current alpha constant (see the next section).
Constant Shape and Opacity
The current alpha constant parameter in the graphics state (see Section 4.3,
“Graphics State”) specifies two scalar values—one for strokes and one for all
other painting operations—to be used for the constant shape (f
k
) or constant
opacity (q
k
) component in the color compositing formulas. This parameter can
be thought of as analogous to the current color used when painting elementary
objects. (Note, however, that the nonstroking alpha constant is also applied when
painting a transparency group’s results onto its backdrop; see also implementa-
tion note 71 in Appendix H.)
The stroking and nonstroking alpha constants are set, respectively, by the
CA and
ca entries in a graphics state parameter dictionary (see Section 4.3.4, “Graphics
State Parameter Dictionaries”). As described above for the soft mask, the alpha
source flag in the graphics state determines whether the alpha constants are inter-
preted as shape values (
true) or opacity values (false).
Note: The note at the end of “Mask Shape and Opacity,” above, applies to the cur-
rent alpha constant parameter as well as the current soft mask.
7.5.4 Specifying Soft Masks
As noted under “Mask Shape and Opacity” on page 518, soft masks for use in
compositing computations can be specified in one of the following ways:
• As a soft-mask dictionary in the current soft mask parameter of the graphics
state; see “Soft-Mask Dictionaries,” below, for more details.
• As a soft-mask image associated with a sampled image; see “Soft-Mask Images”
on page 522 for more details.
• (In PDF 1.5) as a mask channel embedded in JPEG2000 encoded data; see Sec-
tion 3.3.8, “JPXDecode Filter,” and the
SMaskInData entry of Table 4.39 for
more details.
TransparencyCHAPTER 7
520
Soft-Mask Dictionaries
The most common way of defining a soft mask is with a soft-mask dictionary
specified as the current soft mask in the graphics state (see Section 4.3, “Graphics
State”). Table 7.10 shows the contents of this type of dictionary. (See implementa-
tion note 71 in Appendix H.)
The mask values are derived from those of a transparency group, using one of the
two methods described in Sections 7.4.1, “Deriving a Soft Mask from Group
Alpha,” and 7.4.2, “Deriving a Soft Mask from Group Luminosity.” The group is
defined by a transparency group XObject (see Section 7.5.5, “Transparency
Group XObjects”) designated by the
G entry in the soft-mask dictionary. The S
(subtype) entry specifies which of the two derivation methods to use:
• If the subtype is Alpha, the transparency group XObject G is evaluated to com-
pute a group alpha only. The colors of the constituent objects are ignored and
the color compositing computations are not performed. The transfer function
TR is then applied to the computed group alpha to produce the mask values.
Outside the bounding box of the transparency group, the mask value is the re-
sult of applying the transfer function to the input value 0.0.
• If the subtype is Luminosity, the transparency group XObject G is composited
with a fully opaque backdrop whose color is everywhere defined by the soft-
mask dictionary’s
BC entry. The computed result color is then converted to a
single-component luminosity value, and the transfer function
TR is applied to
this luminosity to produce the mask values. Outside the transparency group’s
bounding box, the mask value is derived by transforming the
BC color to lumi-
nosity and applying the transfer function to the result.
The mask’s coordinate system is defined by concatenating the transformation
matrix specified by the
Matrix entry in the transparency group’s form dictio-
nary (see Section 4.9.1, “Form Dictionaries”) with the current transformation
matrix at the moment the soft mask is established in the graphics state with the
gs operator.
Note: In a transparency group XObject that defines a soft mask, spot color compo-
nents are never available, even if they are available in the group or page on which
the soft mask is used. If the group XObject’s content stream specifies a
Separation or
DeviceN color space that uses spot color components, the alternate color space is
substituted (see “Separation Color Spaces” on page 234 and “DeviceN Color Spaces”
on page 238).
Specifying Transparency in PDFSECTION 7.5
521
TABLE 7.10 Entries in a soft-mask dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
Mask for a soft-mask dictionary.
S
name (Required) A subtype specifying the method to be used in deriving the mask
values from the transparency group specified by the
G entry:
Alpha Use the group’s computed alpha, disregarding its color (see
Section 7.4.1, “Deriving a Soft Mask from Group Alpha”).
Luminosity Convert the group’s computed color to a single-component
luminosity value (see Section 7.4.2, “Deriving a Soft Mask
from Group Luminosity”).
G
stream (Required) A transparency group XObject (see Section 7.5.5, “Transparency
Group XObjects”) to be used as the source of alpha or color values for deriv-
ing the mask. If the subtype
S is Luminosity, the group attributes dictionary
must contain a
CS entry defining the color space in which the compositing
computation is to be performed.
BC
array (Optional) An array of component values specifying the color to be used as
the backdrop against which to composite the transparency group XObject
G.
This entry is consulted only if the subtype
S is Luminosity. The array consists
of n numbers, where n is the number of components in the color space speci-
fied by the
CS entry in the group attributes dictionary (see Section 7.5.5,
“Transparency Group XObjects”). Default value: the color space’s initial
value, representing black.
TR
function or name (Optional) A function object (see Section 3.9, “Functions”) specifying the
transfer function to be used in deriving the mask values. The function ac-
cepts one input, the computed group alpha or luminosity (depending on the
value of the subtype
S), and returns one output, the resulting mask value.
Both the input and output must be in the range 0.0 to 1.0; if the computed
output falls outside this range, it is forced to the nearest valid value. The name
Identity may be specified in place of a function object to designate the identi-
ty function. Default value:
Identity.
TransparencyCHAPTER 7
522
Soft-Mask Images
The second way to define a soft mask is by associating a soft-mask image with an
image XObject. This is a subsidiary image XObject specified in the
SMask entry
of the parent XObject’s image dictionary (see Section 4.8.4, “Image Dictionaries”;
see also implementation note 72 in Appendix H). Entries in the subsidiary image
dictionary for such a soft-mask image have the same format and meaning as in
that of an ordinary image XObject (as described in Table 4.39 on page 310), sub-
ject to the restrictions listed in Table 7.11. This type of image dictionary can also
optionally contain an additional entry,
Matte, discussed below.
When an image is accompanied by a soft-mask image, it is sometimes advanta-
geous for the image data to be preblended with some background color, called the
matte color. Each image sample represents a weighted average of the original
source color and the matte color, using the corresponding mask sample as the
weighting factor. (This is a generalization of a technique commonly called pre-
multiplied alpha.)
If the image data is preblended, the matte color must be specified by a
Matte
entry in the soft-mask image dictionary (see Table 7.12). The preblending com-
putation, performed independently for each component, is
where
c is the value to be provided in the image source data
c is the original image component value
m is the matte color component value
is the corresponding mask sample
Note: This computation uses actual color component values, with the effects of the
Filter and Decode transformations already performed. The computation is the same
whether the color space is additive or subtractive.
c' m
cm–()×+=
Specifying Transparency in PDFSECTION 7.5
523
TABLE 7.11 Restrictions on the entries in a soft-mask image dictionary
KEY RESTRICTION
Type
If present, must be XObject.
Subtype
Must be Image.
Width
If a Matte entry (see Table 7.12, below) is present, must be the
same as the
Width value of the parent image; otherwise inde-
pendent of it. Both images are mapped to the unit square in
user space (as are all images), regardless of whether the sam-
ples coincide individually.
Height
Same considerations as for Width.
ColorSpace
Required; must be DeviceGray.
BitsPerComponent
Required.
Intent
Ignored.
ImageMask
Must be false or absent.
Mask
Must be absent.
SMask
Must be absent.
Decode
Default value: [0 1].
Interpolate
Optional.
Alternates
Ignored.
Name
Ignored.
StructParent
Ignored.
ID
Ignored.
OPI
Ignored.
TransparencyCHAPTER 7
524
TABLE 7.12 Additional entry in a soft-mask image dictionary
When preblended image data is used in transparency blending and compositing
computations, the results are the same as if the original, unblended image data
were used and no matte color were specified. In particular, the inputs to the blend
function are the original color values. To derive c from c, the application may
sometimes need to invert the formula shown above. If the resulting c value lies
outside the range of color component values for the image color space, the results
are unpredictable.
The preblending computation is done in the color space specified by the parent
image’s
ColorSpace entry. This is independent of the group color space into which
the image may be painted. If a color conversion is required, inversion of the preb-
lending must precede the color conversion. If the image color space is an
Indexed
space (see “Indexed Color Spaces” on page 232), the color values in the color table
(not the index values themselves) are preblended.
7.5.5 Transparency Group XObjects
A transparency group is represented in PDF as a special type of group XObject
(see Section 4.9.2, “Group XObjects”) called a transparency group XObject. A
group XObject is in turn a type of form XObject, distinguished by the presence of
a
Group entry in its form dictionary (see Section 4.9.1, “Form Dictionaries”). The
value of this entry is a subsidiary group attributes dictionary defining the proper-
ties of the group. The format and meaning of the dictionary’s contents are deter-
mined by its group subtype, which is specified by the dictionary’s
S entry. The
entries for a transparency group (subtype
Transparency) are shown in Table 7.13.
Note: A page object (see “Page Objects” on page 119) may also have a
Group entry,
whose value is a group attributes dictionary specifying the attributes of the page
group (see Section 7.3.6, “Page Group”). Some of the dictionary entries are inter-
KEY TYPE VALUE
Matte
array (Optional; PDF 1.4) An array of component values specifying the matte color with
which the image data in the parent image has been preblended. The array consists of n
numbers, where n is the number of components in the color space specified by the
ColorSpace entry in the parent image’s image dictionary; the numbers must be valid
color components in that color space. If this entry is absent, the image data is not
preblended.
Specifying Transparency in PDFSECTION 7.5
525
preted slightly differently for a page group than for a transparency group XObject;
see their descriptions in the table for details.
TABLE 7.13 Additional entries specific to a transparency group attributes dictionary
KEY TYPE VALUE
S
name (Required) The group subtype, which identifies the type of group whose at-
tributes this dictionary describes; must be
Transparency for a transparency
group.
CS
name or array (Sometimes required, as discussed below) The group color space, which is used for
the following purposes:
• As the color space into which colors are converted when painted into the
group
• As the blending color space in which objects are composited within the group
(see Section 7.2.3, “Blending Color Space”)
• As the color space of the group as a whole when it in turn is painted as an ob-
ject onto its backdrop
The group color space may be any device or CIE-based color space that treats its
components as independent additive or subtractive values in the range 0.0 to 1.0,
subject to the restrictions described in Section 7.2.3, “Blending Color Space.”
These restrictions exclude
Lab and lightness-chromaticity ICCBased color spac-
es, as well as the special color spaces
Pattern, Indexed, Separation, and DeviceN.
Device color spaces are subject to remapping according to the
DefaultGray,
DefaultRGB, and DefaultCMYK entries in the ColorSpace subdictionary of the
current resource dictionary (see “Default Color Spaces” on page 227).
Ordinarily, the
CS entry is allowed only for isolated transparency groups (those
for which
I, below, is true), and even then it is optional. However, this entry is re-
quired in the group attributes dictionary for any transparency group XObject
that has no parent group or page from which to inherit—in particular, one that is
the value of the
G entry in a soft-mask dictionary of subtype Luminosity (see
“Soft-Mask Dictionaries” on page 520).
In addition, it is always permissible to specify CS in the group attributes dictio-
nary associated with a page object, even if
I is false or absent. In the normal case
in which the page is imposed directly on the output medium, the page group is
effectively isolated regardless of the
I value, and the specified CS value is there-
fore honored. But if the page is in turn used as an element of some other page
and if the group is non-isolated,
CS is ignored and the color space is inherited
from the actual backdrop with which the page is composited (see Section 7.3.6,
“Page Group”).
TransparencyCHAPTER 7
526
The transparency group XObject’s content stream defines the graphics objects be-
longing to the group. Invoking the
Do operator on the XObject executes its con-
tent stream and composites the resulting group color, shape, and opacity into the
group’s parent group or page as if they had come from an elementary graphics ob-
ject. When applied to a transparency group XObject,
Do performs the following
actions in addition to the normal ones for a form XObject (as described in Sec-
tion 4.9, “Form XObjects”):
• If the transparency group is non-isolated (the value of the I entry in its group
attributes dictionary is
false), its initial backdrop, within the bounding box
specified by the XObject’s
BBox entry, is defined to be the accumulated color
and alpha of the parent group or page—that is, the result of everything that has
been painted in the parent up to that point. (However, if the parent is a knock-
out group, the initial backdrop is the same as that of the parent.) If the group is
isolated (
I is true), its initial backdrop is defined to be transparent.
Default value: the color space of the parent group or page into which this trans-
parency group is painted. (The parent’s color space in turn can be either explicit-
ly specified or inherited.)
Note: For a transparency group XObject used as an annotation appearance (see
Section 8.4.4, “Appearance Streams”), the default color space is inherited from the
page on which the annotation appears.
I
boolean (Optional) A flag specifying whether the transparency group is isolated (see Sec-
tion 7.3.4, “Isolated Groups”). If this flag is
true, objects within the group are
composited against a fully transparent initial backdrop; if
false, they are com-
posited against the group’s backdrop. Default value:
false.
In the group attributes dictionary for a page, the interpretation of this entry is
slightly altered. In the normal case in which the page is imposed directly on the
output medium, the page group is effectively isolated and the specified
I value is
ignored. But if the page is in turn used as an element of some other page, it is
treated as if it were a transparency group XObject; the
I value is interpreted in
the normal way to determine whether the page group is isolated.
K
boolean (Optional) A flag specifying whether the transparency group is a knockout group
(see Section 7.3.5, “Knockout Groups”). If this flag is
false, later objects within
the group are composited with earlier ones with which they overlap; if
true, they
are composited with the group’s initial backdrop and overwrite (“knock out”)
any earlier overlapping objects. Default value:
false.
KEY TYPE VALUE
Specifying Transparency in PDFSECTION 7.5
527
• Before execution of the transparency group XObject’s content stream, the cur-
rent blend mode in the graphics state is initialized to
Normal, the current strok-
ing and nonstroking alpha constants to 1.0, and the current soft mask to
None.
Note: The purpose of initializing these graphics state parameters at the beginning
of execution is to ensure that they are not applied twice: once when member ob-
jects are painted into the group and again when the group is painted into the par-
ent group or page.
• Objects painted by operators in the transparency group XObject’s content
stream are composited into the group according to the rules described in Sec-
tion 7.2.2, “Basic Compositing Formula.” The knockout flag (
K) in the group at-
tributes dictionary and the transparency-related parameters of the graphics
state contribute to this computation.
• If a group color space (CS) is specified in the group attributes dictionary, all
painting operators convert source colors to that color space before compositing
objects into the group, and the resulting color at each point is interpreted in
that color space. If no group color space is specified, the prevailing color space
is dynamically inherited from the parent group or page. (If not otherwise spec-
ified, the page group’s color space is inherited from the native color space of the
output device.)
• After execution of the transparency group XObject’s content stream, the graph-
ics state reverts to its former state before the invocation of the
Do operator (as it
does for any form XObject). The group’s shape—the union of all objects paint-
ed into the group, clipped by the group XObject’s bounding box—is then paint-
ed into the parent group or page, using the group’s accumulated color and
opacity at each point.
Note: If the
Do operator is invoked more than once for a given transparency group
XObject, each invocation is treated as a separate transparency group. That is, the
result is as if the group were independently composited with the backdrop on each
invocation. Applications that perform caching of rendered form XObjects must take
this requirement into account.
The actions described above occur only for a transparency group XObject—a
form XObject having a
Group entry that designates a group attributes subdic-
tionary whose group subtype (
S) is Transparency. An ordinary form XObject—
one having no
Group entry—is not subject to any grouping behavior for transpar-
ency purposes. That is, the graphics objects it contains are composited individu-
ally, just as if they were painted directly into the parent group or page.
TransparencyCHAPTER 7
528
7.5.6 Patterns and Transparency
In the transparent imaging model, the graphics objects making up the pattern cell
of a tiling pattern (see Section 4.6.2, “Tiling Patterns”) can include transparent
objects and transparency groups. Transparent compositing can occur both within
the pattern cell and between it and the backdrop wherever the pattern is painted.
Similarly, a shading pattern (Section 4.6.3, “Shading Patterns”) composites with
its backdrop as if the shading dictionary were applied with the
sh operator.
In both cases, the pattern definition is treated as if it were implicitly enclosed in a
non-isolated transparency group: a non-knockout group for tiling patterns, a
knockout group for shading patterns. The definition does not inherit the current
values of the graphics state parameters at the time it is evaluated; these take effect
only when the resulting pattern is later used to paint an object. Instead, the
graphics state parameters are initialized as follows:
• As always for transparency groups, those parameters related to transparency
(blend mode, soft mask, and alpha constant) are initialized to their standard
default values.
• All other parameters are initialized to their values at the beginning of the con-
tent stream (such as a page or a form XObject) in which the pattern is defined
as a resource. This is the normal behavior for all patterns, in both the opaque
and transparent imaging models.
• In the case of a shading pattern, the parameter values may be augmented by the
contents of the
ExtGState entry in the pattern dictionary (see Section 4.6.3,
“Shading Patterns”). Only those parameters that affect the
sh operator, such as
the current transformation matrix and rendering intent, are used. Parameters
that affect path-painting operators are not used, since the execution of
sh does
not entail painting a path.
• If the shading dictionary has a Background entry, the pattern’s implicit trans-
parency group is filled with the specified background color before the
sh oper-
ator is invoked.
When the pattern is later used to paint a graphics object, the color, shape, and
opacity values resulting from the evaluation of the pattern definition are used as
the object’s source color (C
s
), object shape (f
j
), and object opacity (q
j
) in the
transparency compositing formulas. This painting operation is subject to the val-
ues of the graphics state parameters in effect at the time, just as in painting an ob-
ject with a constant color.
Color Space and Rendering IssuesSECTION 7.6
529
Unlike the opaque imaging model, in which the pattern cell of a tiling pattern can
be evaluated once and then replicated indefinitely to fill the painted area, the
effect in the general transparent case is as if the pattern definition were reexecut-
ed independently for each tile, taking into account the color of the backdrop at
each point. However, in the common case in which the pattern consists entirely of
objects painted with the
Normal blend mode, this behavior can be optimized by
treating the pattern cell as if it were an isolated group. Since in this case the results
depend only on the color, shape, and opacity of the pattern cell and not on those
of the backdrop, the pattern cell can be evaluated once and then replicated, just as
in opaque painting.
Note: In a raster-based implementation of tiling, it is important that all tiles togeth-
er be treated as a single transparency group. This avoids artifacts due to multiple
marking of pixels along the boundaries between adjacent tiles.
The foregoing discussion applies to both colored (
PaintType 1) and uncolored
(
PaintType 2) tiling patterns. In the latter case, the restriction that an uncolored
pattern’s definition may not specify colors extends as well to any transparency
group that the definition may include. There are no corresponding restrictions,
however, on specifying transparency-related parameters in the graphics state.
7.6 Color Space and Rendering Issues
This section describes the interactions between transparency and other aspects of
color specification and rendering in the Adobe imaging model.
7.6.1 Color Spaces for Transparency Groups
As discussed in Section 7.5.5, “Transparency Group XObjects,” a transparency
group can either have an explicitly declared color space of its own or inherit that
of its parent group. In either case, the colors of source objects within the group
are converted to the group’s color space, if necessary, and all blending and com-
positing computations are done in that space (see Section 7.2.3, “Blending Color
Space”). The resulting colors are then interpreted in that color space when the
group is subsequently composited with its backdrop.
Under this arrangement, it is envisioned that all or most of a given piece of art-
work will be created in a single color space—most likely, the working color space
of the application generating it. The use of multiple color spaces typically will
TransparencyCHAPTER 7
530
arise only when assembling independently produced artwork onto a page. After
all the artwork has been placed on the page, the conversion from the group’s color
space to the page’s device color space will be done as the last step, without any
further transparency compositing. The transparent imaging model does not re-
quire that this convention be followed, however; the reason for adopting it is to
avoid the loss of color information and the introduction of errors resulting from
unnecessary color space conversions.
Only an isolated group may have an explicitly declared color space of its own.
Non-isolated groups must inherit their color space from the parent group (sub-
ject to special treatment for the page group, as described in Section 7.3.6, “Page
Group”). This is because the use of an explicit color space in a non-isolated group
would require converting colors from the backdrop’s color space to that of the
group in order to perform the compositing computations. Such conversion may
not be possible (since some color conversions can be performed only in one
direction), and even if possible, it would entail an excessive number of color con-
versions.
The choice of a group color space has significant effects on the results that are
produced:
• As noted in Section 7.2.3, “Blending Color Space,” the results of compositing in
a device color space is device-dependent. For the compositing computations to
work in a device-independent way, the group’s color space must be CIE-based.
• A consequence of choosing a CIE-based group color space is that only CIE-
based spaces can be used to specify the colors of objects within the group. This
is because conversion from device to CIE-based colors is not possible in gener-
al; the defined conversions work only in the opposite direction. See below for
further discussion.
• The compositing computations and blend functions generally compute linear
combinations of color component values, on the assumption that the compo-
nent values themselves are linear. For this reason, it is usually best to choose a
group color space that has a linear gamma function. If a nonlinear color space
is chosen, the results are still well-defined, but the appearance may not match
the user’s expectations. Note, in particular, that the CIE-based sRGB color
space (see page 226) is nonlinear and hence may be unsuitable for use as a
group color space.
Color Space and Rendering IssuesSECTION 7.6
531
Note: Implementations of the transparent imaging model are advised to use as
much precision as possible in representing colors during compositing computations
and in the accumulated group results. To minimize the accumulation of roundoff er-
rors and avoid additional errors arising from the use of linear group color spaces,
more precision is needed for intermediate results than is typically used to represent
either the original source data or the final rasterized results.
If a group’s color space—whether specified explicitly or inherited from the parent
group—is CIE-based, any use of device color spaces for painting objects is subject
to special treatment. Device colors cannot be painted directly into such a group,
since there is no generally defined method for converting them to the CIE-based
color space. This problem arises in the following cases:
• DeviceGray, DeviceRGB, and DeviceCMYK color spaces, unless remapped to de-
fault CIE-based color spaces (see “Default Color Spaces” on page 227)
• Operators (such as rg) that specify a device color space implicitly, unless that
space is remapped
• Special color spaces whose base or underlying space is a device color space, un-
less that space is remapped
It is recommended that the default color space remapping mechanism always be
employed when defining a transparency group whose color space is CIE-based. If
a device color is specified and is not remapped, it is converted to the CIE-based
color space in an implementation-dependent fashion, producing unpredictable
results.
Note: The foregoing restrictions do not apply if the group’s color space is implicitly
converted to
DeviceCMYK, as discussed in “Implicit Conversion of CIE-Based Color
Spaces” on page 228.
TransparencyCHAPTER 7
532
7.6.2 Spot Colors and Transparency
The foregoing discussion of color spaces has been concerned with process col-
ors—those produced by combinations of an output device’s process colorants.
Process colors may be specified directly in the device’s native color space (such as
DeviceCMYK), or they may be produced by conversion from some other color
space, such as a CIE-based (
CalRGB or ICCBased) space. Whatever means is used
to specify them, process colors are subject to conversion to and from the group’s
color space.
A spot color is an additional color component, independent of those used to pro-
duce process colors. It may represent either an additional separation to be
produced or an additional colorant to be applied to the composite page (see “Sep-
aration Color Spaces” on page 234 and “DeviceN Color Spaces” on page 238).
The color component value, or tint, for a spot color specifies the concentration of
the corresponding spot colorant. Tints are conventionally represented as subtrac-
tive, rather than additive, values.
Spot colors are inherently device-dependent and are not always available. In the
opaque imaging model, each use of a spot color component in a
Separation or
DeviceN color space is accompanied by an alternate color space and a tint transfor-
mation function for mapping tint values into that space. This enables the color to
be approximated with process colorants when the corresponding spot colorant is
not available on the device.
Spot colors can be accommodated straightforwardly in the transparent imaging
model (except for issues relating to overprinting, discussed in Section 7.6.3,
“Overprinting and Transparency”). When an object is painted transparently with
a spot color component that is available in the output device, that color is com-
posited with the corresponding spot color component of the backdrop, indepen-
dently of the compositing that is performed for process colors. A spot color
retains its own identity; it is not subject to conversion to or from the color space
of the enclosing transparency group or page. If the object is an element of a trans-
parency group, one of two things can happen:
• The group maintains a separate color value for each spot color component,
independently of the group’s color space. In effect, the spot color passes directly
through the group hierarchy to the device, with no color conversions per-
Color Space and Rendering IssuesSECTION 7.6
533
formed. However, it is still subject to blending and compositing with other ob-
jects that use the same spot color.
• The spot color is converted to its alternate color space. The resulting color is
then subject to the usual compositing rules for process colors. In particular,
spot colors are never available in a transparency group XObject that is used to
define a soft mask; the alternate color space is always substituted in that case.
Only a single shape value and opacity value are maintained at each point in the
computed group results; they apply to both process and spot color components.
In effect, every object is considered to paint every existing color component, both
process and spot. Where no value has been explicitly specified for a given com-
ponent in a given object, an additive value of 1.0 (or a subtractive tint value of
0.0) is assumed. For instance, when painting an object with a color specified in a
DeviceCMYK or ICCBased color space, the process color components are painted
as specified and the spot color components are painted with an additive value of
1.0. Likewise, when painting an object with a color specified in a
Separation color
space, the named spot color is painted as specified and all other components
(both process colors and other spot colors) are painted with an additive value of
1.0. The consequences of this are discussed in Section 7.6.3, “Overprinting and
Transparency.”
The opaque imaging model also allows process color components to be addressed
individually, as if they were spot colors. For instance, it is possible to specify a
Separation color space named Cyan, which paints just the cyan component on a
CMYK output device. However, this capability is very difficult to extend to trans-
parency groups. In general, the color components in a group are not the process
colorants themselves, but are converted to process colorants only after the com-
pletion of all color compositing computations for the group (and perhaps some of
its parent groups as well). For instance, if the group’s color space is
ICCBased, the
group has no
Cyan component to be painted. Consequently, treating a process
color component as if it were a spot color is permitted only within a group that
inherits the native color space of the output device (or is implicitly converted to
DeviceCMYK, as discussed in “Implicit Conversion of CIE-Based Color Spaces”
on page 228). Attempting to do so in a group that specifies its own color space re-
sults in conversion of the requested spot color to its alternate color space.
TransparencyCHAPTER 7
534
7.6.3 Overprinting and Transparency
In the opaque imaging model, overprinting is controlled by two parameters of the
graphics state: the overprint parameter and the overprint mode (see Section 4.5.6,
“Overprint Control”). Painting an object causes some specific set of device colo-
rants to be marked, as determined by the current color space and current color in
the graphics state. The remaining colorants are either erased or left unchanged,
depending on whether the overprint parameter is
false or true. When the current
color space is
DeviceCMYK, the overprint mode parameter additionally enables
this selective marking of colorants to be applied to individual color components
according to whether the component value is zero or nonzero.
Because this model of overprinting deals directly with the painting of device
colorants, independently of the color space in which source colors have been
specified, it is highly device-dependent and primarily addresses production
needs rather than design intent. Overprinting is usually reserved for opaque colo-
rants or for very dark colors, such as black. It is also invoked during late-stage
production operations such as trapping (see Section 10.10.5, “Trapping Sup-
port”), when the actual set of device colorants has already been determined.
Consequently, it is best to think of transparency as taking place in appearance
space, but overprinting of device colorants in device space. This means that colo-
rant overprint decisions should be made at output time, based on the actual re-
sultant colorants of any transparency compositing operation. On the other hand,
effects similar to overprinting can be achieved in a device-independent manner
by taking advantage of blend modes, as described in the next section.
Blend Modes and Overprinting
As stated in Section 7.6.2, “Spot Colors and Transparency,” each graphics object
that is painted affects all existing color components: all process colorants in the
transparency group’s color space as well as any available spot colorants. For color
components whose value has not been specified, a source color value of 1.0 is
assumed; when objects are fully opaque and the
Normal blend mode is used, this
has the effect of erasing those components. This treatment is consistent with the
behavior of the opaque imaging model with the overprint parameter set to
false.
Color Space and Rendering IssuesSECTION 7.6
535
The transparent imaging model defines some blend modes, such as Darken, that
can be used to achieve effects similar to overprinting. The blend function for
Darken is
In this blend mode, the result of compositing is always the same as the backdrop
color when the source color is 1.0, as it is for all unspecified color components.
When the backdrop is fully opaque, this leaves the result color unchanged from
that of the backdrop. This is consistent with the behavior of the opaque imaging
model with the overprint parameter set to
true.
If the object or backdrop is not fully opaque, the actions described above are al-
tered accordingly. That is, the erasing effect is reduced, and overprinting an ob-
ject with a color value of 1.0 may affect the result color. While these results may or
may not be useful, they lie outside the realm of the overprinting and erasing be-
havior defined in the opaque imaging model.
When process colors are overprinted or erased (because a spot color is being
painted), the blending computations described above are done independently for
each component in the group’s color space. If that space is different from the
native color space of the output device, its components are not the device’s actual
process colorants; the blending computations affect the process colorants only
after the group’s results are converted to the device color space. Thus the effect is
different from that of overprinting or erasing the device’s process colorants
directly. On the other hand, this is a fully general operation that works uniformly,
regardless of the type of object or of the computations that produced the source
color.
The discussion so far has focused on those color components whose values are
not specified and that are to be either erased or left unchanged. However, the
Normal or Darken blend modes used for these purposes may not be suitable for
use on those components whose color values are specified. In particular, using
the
Darken blend mode for such components would preclude overprinting a dark
color with a lighter one. Moreover, some other blend mode may be specifically
desired for those components.
The PDF graphics state specifies only one current blend mode parameter, which
always applies to process colorants and sometimes to spot colorants as well.
Specifically, only separable, white-preserving blend modes can be used for spot
Bc
b
c
s
,()min c
b
c
s
,()=
TransparencyCHAPTER 7
536
colors. A blend mode is white-preserving if its blend function B has the property
that B(1.0, 1.0) = 1.0. (Of the standard separable blend modes listed in Table 7.2
on page 491, all except
Difference and Exclusion are white-preserving.) If the
specified blend mode is not separable and white-preserving, it applies only to
process color components; the
Normal blend mode is substituted for spot colors.
This ensures that when objects accumulate in an isolated transparency group, the
accumulated values for unspecified components remain 1.0 as long as only white-
preserving blend modes are used. The group’s results can then be overprinted us-
ing
Darken (or other useful modes) while avoiding unwanted interactions with
components whose values were never specified within the group.
Compatibility with Opaque Overprinting
Because the use of blend modes to achieve effects similar to overprinting does not
make direct use of the overprint control parameters in the graphics state, such
methods are usable only by transparency-aware applications. For compatibility
with the methods of overprint control used in the opaque imaging model, a spe-
cial blend mode, CompatibleOverprint, is provided that consults the overprint-
related graphics state parameters to compute its result. This mode applies only
when painting elementary graphics objects (fills, strokes, text, images, and shad-
ings). It is never invoked explicitly and is not identified by any PDF name object;
rather, it is implicitly invoked whenever an elementary graphics object is painted
while overprinting is enabled (that is, when the overprint parameter in the graph-
ics state is
true).
Note: Earlier designs of the transparent imaging model included an additional
blend mode named
Compatible, which explicitly invoked the CompatibleOverprint
blend mode described here. Because CompatibleOverprint is now invoked implicitly
whenever appropriate, it is never necessary to specify the
Compatible blend mode
for use in compositing. It is still recognized as a valid blend mode for the sake of
compatibility but is simply treated as equivalent to
Normal.
The value of the blend function B(c
b
, c
s
) in the CompatibleOverprint mode is
either c
b
or c
s
, depending on the setting of the overprint mode parameter, the
current and group color spaces, and the source color value c
s
:
• If the overprint mode is 1 (nonzero overprint mode) and the current color
space and group color space are both
DeviceCMYK, then only process color
components with nonzero values replace the corresponding component values
of the backdrop. All other component values leave the existing backdrop value
Color Space and Rendering IssuesSECTION 7.6
537
unchanged. That is, the value of the blend function B(c
b
, c
s
) is the source com-
ponent c
s
for any process (DeviceCMYK) color component whose (subtractive)
color value is nonzero; otherwise it is the backdrop component c
b
. For spot col-
or components, the value is always c
b
.
• In all other cases, the value of B(c
b
, c
s
) is c
s
for all color components specified
in the current color space, otherwise c
b
. For instance, if the current color space
is
DeviceCMYK or CalRGB, the value of the blend function is c
s
for process color
components and c
b
for spot components. On the other hand, if the current col-
or space is a
Separation space representing a spot color component, the value is
c
s
for that spot component and c
b
for all process components and all other spot
components.
Note: In the descriptions above, the term current color space refers to the color
space used for a painting operation. This may be specified by the current color space
parameter in the graphics state (see Section 4.5.1, “Color Values”), implicitly by col-
or operators such as
rg (Section 4.5.7, “Color Operators”), or by the ColorSpace en-
try of an image XObject (Section 4.8.4, “Image Dictionaries”). In the case of an
Indexed space, it refers to the base color space (see “Indexed Color Spaces” on page
232); likewise for
Separation and DeviceN spaces that revert to their alternate color
space, as described under “Separation Color Spaces” on page 234 and “DeviceN
Color Spaces” on page 238.
If the current blend mode when CompatibleOverprint is invoked is any mode
other than
Normal, the object being painted is implicitly treated as if it were
defined in a non-isolated, non-knockout transparency group and painted using
the CompatibleOverprint blend mode. The group’s results are then painted using
the current blend mode in the graphics state.
Note: It is not necessary to create such an implicit transparency group if the current
blend mode is
Normal; simply substituting the CompatibleOverprint blend mode
while painting the object produces equivalent results. There are some additional
cases in which the implicit transparency group can be optimized out.
Plate 20 shows the effects of all four possible combinations of blending and over-
printing, using the
Screen blend mode in the DeviceCMYK color space. The label
“overprint enabled” means that the overprint parameter in the graphics state is
true and the overprint mode is 1. In the upper half of the figure, a light green oval
is painted opaquely (opacity = 1.0) over a backdrop shading from pure yellow to
pure magenta. In the lower half, the same object is painted with transparency
(opacity = 0.5).
TransparencyCHAPTER 7
538
Special Path-Painting Considerations
The overprinting considerations discussed above also affect those path-painting
operations that combine filling and stroking a path in a single operation. These
include the
B, B*, b, and b* operators (see Section 4.4.2, “Path-Painting Opera-
tors”) and the painting of glyphs with text rendering mode 2 or 6 (Section 5.2.5,
“Text Rendering Mode”). For transparency compositing purposes, the combined
fill and stroke are treated as a single graphics object, as if they were enclosed in a
transparency group. This implicit group is established and used as follows:
• If overprinting is enabled (the overprint parameter in the graphics state is true)
and the current stroking and nonstroking alpha constants are equal, a non-
isolated, non-knockout transparency group is established. Within the group,
the fill and stroke are performed with an alpha value of 1.0 but with the Com-
patibleOverprint blend mode. The group results are then composited with the
backdrop, using the originally specified alpha and blend mode.
• In all other cases, a non-isolated knockout group is established. Within the
group, the fill and stroke are performed with their respective prevailing alpha
constants and the prevailing blend mode. The group results are then composit-
ed with the backdrop, using an alpha value of 1.0 and the
Normal blend mode.
Note that in the case of showing text with the combined filling and stroking text
rendering modes, this behavior is independent of the text knockout parameter in
the graphics state (see Section 5.2.7, “Text Knockout”).
The purpose of these rules is to avoid having a non-opaque stroke composite with
the result of the fill in the region of overlap, which would produce a double bor-
der effect that is usually undesirable. The special case that applies when the over-
print parameter is
true is for backward compatibility with the overprinting
behavior of the opaque imaging model. If a desired effect cannot be achieved with
a combined filling and stroking operator or text rendering mode, it can be
achieved by specifying the fill and stroke with separate path objects and an ex-
plicit transparency group.
Note: Overprinting of the stroke over the fill does not work in the second case de-
scribed above (although either the fill or the stroke can still overprint the backdrop).
Furthermore, if the overprint graphics state parameter is
true, the results are discon-
tinuous at the transition between equal and unequal values of the stroking and non-
stroking alpha constants. For this reason, it is best not to use overprinting for
Color Space and Rendering IssuesSECTION 7.6
539
combined filling and stroking operations if the stroking and nonstroking alpha con-
stants are being varied independently.
Summary of Overprinting Behavior
Tables 7.14 and 7.15 summarize the overprinting and erasing behavior in the
opaque and transparent imaging models, respectively. Table 7.14 shows the over-
printing rules used in the opaque model, as described in Section 4.5.6, “Overprint
Control.” Table 7.15 shows the equivalent rules as implemented by the Compatib-
leOverprint blend mode in the transparent model. The names
OP and OPM in the
tables refer to the overprint and overprint mode parameters of the graphics state.
TABLE 7.14 Overprinting behavior in the opaque imaging model
SOURCE COLOR SPACE AFFECTED COLOR
COMPONENT
EFFECT ON COLOR COMPONENT
OP FALSE OP TRUE, OPM 0 OP TRUE, OPM 1
DeviceCMYK,
specified directly,
not in a sampled image
C, M, Y, or K Paint source Paint source Paint source if 0.0
Do not paint if = 0.0
Process colorant
other than CMYK
Paint source Paint source Paint source
Spot colorant Paint 0.0 Do not paint Do not paint
Any process color
space (including other
cases of
DeviceCMYK)
Process colorant Paint source Paint source Paint source
Spot colorant Paint 0.0 Do not paint Do not paint
Separation or
DeviceN
Process colorant Paint 0.0 Do not paint Do not paint
Spot colorant
named in source
space
Paint source Paint source Paint source
Spot colorant not
named in source
space
Paint 0.0 Do not paint Do not paint
TransparencyCHAPTER 7
540
TABLE 7.15 Overprinting behavior in the transparent imaging model
Color component values are represented in these tables as subtractive tint values
because overprinting is typically applied to subtractive colorants such as inks
rather than to additive ones such as phosphors on a display screen. The Compati-
bleOverprint blend mode is therefore described as if it took subtractive argu-
ments and returned subtractive results. In reality, however, CompatibleOverprint
(like all blend modes) treats color components as additive values; subtractive
components must be complemented before and after application of the blend
function.
SOURCE COLOR SPACE
AFFECTED COLOR
COMPONENT OF
GROUP COLOR SPACE
VALUE OF BLEND FUNCTION B(c
b
, c
s
) EXPRESSED AS TINT
OP FALSE OP TRUE, OPM 0 OP TRUE, OPM 1
DeviceCMYK,
specified directly,
not in a sampled image
C, M, Y, or Kc
s
c
s
c
s
if c
s
0.0
c
b
if c
s
= 0.0
Process color
component other
than CMYK
c
s
c
s
c
s
Spot colorant c
s
(= 0.0) c
b
c
b
Any process color
space (including other
cases of
DeviceCMYK)
Process color
component
c
s
c
s
c
s
Spot colorant c
s
(= 0.0) c
b
c
b
Separation or
DeviceN
Process color
component
c
s
(= 0.0) c
b
c
b
Spot colorant
named in source
space
c
s
c
s
c
s
Spot colorant not
named in source
space
c
s
(= 0.0) c
b
c
b
A group (not an
elementary object)
All color
components
c
s
c
s
c
s
Color Space and Rendering IssuesSECTION 7.6
541
Note an important difference between the two tables. In Table 7.14, the process
color components being discussed are the actual device colorants—the color
components of the output device’s native color space (
DeviceGray, DeviceRGB, or
DeviceCMYK). In Table 7.15, the process color components are those of the
group’s color space, which is not necessarily the same as that of the output device
(and can even be something like
CalRGB or ICCBased). For this reason, the pro-
cess color components of the group color space cannot be treated as if they were
spot colors in a
Separation or DeviceN color space (see Section 7.6.2, “Spot Colors
and Transparency”). This difference between opaque and transparent overprint-
ing and erasing rules arises only within a transparency group (including the page
group, if its color space is different from the native color space of the output de-
vice). There is no difference in the treatment of spot color components.
Table 7.15 has one additional row at the bottom. It applies when painting an ob-
ject that is a transparency group rather than an elementary object (fill, stroke,
text, image, or shading). As stated in Section 7.6.2, “Spot Colors and Transparen-
cy,” a group is considered to paint all color components, both process and spot.
Color components that were not explicitly painted by any object in the group
have an additive color value of 1.0 (subtractive tint 0.0). Since no information is
retained about which components were actually painted within the group, com-
patible overprinting is not possible in this case; the CompatibleOverprint blend
mode reverts to
Normal, with no consideration of the overprint and overprint
mode parameters. (A transparency-aware application can choose a more suitable
blend mode, such as
Darken, to produce an effect similar to overprinting.)
7.6.4 Rendering Parameters and Transparency
The opaque imaging model has several graphics state parameters dealing with the
rendering of color: the current halftone (see Section 6.4.4, “Halftone Diction-
aries”), transfer functions (Section 6.3, “Transfer Functions”), rendering intent
(“Rendering Intents” on page 230), and black-generation and undercolor-removal
functions (Section 6.2.3, “Conversion from DeviceRGB to DeviceCMYK”). All of
these rendering parameters can be specified on a per-object basis; they control
how a particular object is rendered. When all objects are opaque, it is easy to define
what this means. But when they are transparent, more than one object can con-
tribute to the color at a given point; it is unclear which rendering parameters to ap-
ply in an area where transparent objects overlap. At the same time, the transparent
imaging model should be consistent with the opaque model when only opaque ob-
jects are painted.
TransparencyCHAPTER 7
542
Furthermore, some of the rendering parameters—the halftone and transfer func-
tions, in particular—can be applied only when the final color at a given point is
known. In the presence of transparency, these parameters must be treated some-
what differently from those (rendering intent, black generation, and undercolor
removal) that apply whenever colors must be converted from one color space to
another. When objects are transparent, the rendering of an object does not occur
when the object is specified but at some later time. Hence, for rendering param-
eters in the former category, the implementation must keep track of the rendering
parameters at each point from the time they are specified until the time the ren-
dering actually occurs. This means that these rendering parameters must be asso-
ciated with regions of the page rather than with individual objects.
Halftone and Transfer Function
The halftone and transfer function to be used at any given point on the page are
those in effect at the time of painting the last (topmost) elementary graphics ob-
ject enclosing that point, but only if the object is fully opaque. (Only elementary
objects are relevant; the rendering parameters associated with a group object are
ignored.) The topmost object at any point is defined to be the topmost elementary
object in the entire page stack that has a nonzero object shape value (f
j
) at that
point (that is, for which the point is inside the object). An object is considered to
be fully opaque if all of the following conditions hold at the time the object is
painted:
• The current alpha constant in the graphics state (stroking or nonstroking, de-
pending on the painting operation) is 1.0.
• The current blend mode in the graphics state is Normal (or Compatible, which
is treated as equivalent to
Normal).
• The current soft mask in the graphics state is None. If the object is an image
XObject, there is no
SMask entry in its image dictionary.
• The foregoing three conditions were also true at the time the Do operator was
invoked for the group containing the object, as well as for any direct ancestor
groups.
• If the current color is a tiling pattern, all objects in the definition of its pattern
cell also satisfy the foregoing conditions.
Together, these conditions ensure that only the object itself contributes to the col-
or at the given point, completely obscuring the backdrop. For portions of the page
Color Space and Rendering IssuesSECTION 7.6
543
whose topmost object is not fully opaque or that are never painted at all, the de-
fault halftone and transfer function for the page are used.
Note: If a graphics object is painted with overprinting enabled—that is, if the applic-
able (stroking or nonstroking) overprint parameter in the graphics state is
true—the
halftone and transfer function to use at a given point must be determined indepen-
dently for each color component. Overprinting implicitly invokes the Compatible-
Overprint blend mode (see “Compatibility with Opaque Overprinting” on page
536). An object is considered opaque for a given component only if Compatible-
Overprint yields the source color (not the backdrop color) for that component.
Rendering Intent and Color Conversions
The rendering intent, black-generation, and undercolor-removal parameters
need to be handled somewhat differently. The rendering intent influences the
conversion from a CIE-based color space to a target color space, taking into ac-
count the target space’s color gamut (the range of colors it can reproduce).
Whereas in the opaque imaging model the target space is always the native color
space of the output device, in the transparent model it may instead be the group
color space of a transparency group into which an object is being painted.
The rendering intent is needed at the moment such a conversion must be per-
formed—that is, when painting an elementary or group object specified in a CIE-
based color space into a parent group having a different color space. This differs
from the current halftone and transfer function, whose values are used only when
all color compositing has been completed and rasterization is being performed.
In all cases, the rendering intent to use for converting an object’s color (whether
that of an elementary object or of a transparency group) is determined by the ren-
dering intent parameter associated with the object. In particular:
• When painting an elementary object with a CIE-based color into a transpar-
ency group having a different color space, the rendering intent used is the cur-
rent rendering intent in effect in the graphics state at the time of the painting
operation.
• When painting a transparency group whose color space is CIE-based into a
parent group having a different color space, the rendering intent used is the
current rendering intent in effect at the time the
Do operator is applied to the
group.
TransparencyCHAPTER 7
544
• When the color space of the page group is CIE-based, the rendering intent used
to convert colors to the native color space of the output device is the default
rendering intent for the page.
Note: Since there may be one or more nested transparency groups having different
CIE-based color spaces, the color of an elementary source object may be converted
to the device color space in multiple stages, controlled by the rendering intent in ef-
fect at each stage. The proper choice of rendering intent at each stage depends on the
relative gamuts of the source and target color spaces. It is specified explicitly by the
document producer, not prescribed by the PDF specification, since no single policy
for managing rendering intents is appropriate for all situations.
A similar approach works for the black-generation and undercolor-removal func-
tions, which are applied only during conversion from
DeviceRGB to DeviceCMYK
color spaces:
• When painting an elementary object with a DeviceRGB color directly into a
transparency group whose color space is
DeviceCMYK, the functions used are
the current black-generation and undercolor-removal functions in effect in the
graphics state at the time of the painting operation.
• When painting a transparency group whose color space is DeviceRGB into a
parent group whose color space is
DeviceCMYK, the functions used are the ones
in effect at the time the
Do operator is applied to the group.
• When the color space of the page group is DeviceRGB and the native color
space of the output device is
DeviceCMYK, the functions used to convert colors
to the device’s color space are the default functions for the page.
7.6.5 PostScript Compatibility
Because the PostScript language does not support the transparent imaging
model, PDF 1.4 consumer applications must have some means for converting the
appearance of a document that uses transparency to a purely opaque description
for printing on PostScript output devices. Similar techniques can also be used to
convert such documents to a form that can be correctly viewed by PDF 1.3 and
earlier consumers.
Converting the contents of a page from transparent to opaque form entails some
combination of shape decomposition and prerendering to flatten the stack of
transparent objects on the page, perform all the needed transparency computa-
Color Space and Rendering IssuesSECTION 7.6
545
tions, and describe the final appearance using opaque objects only. Whether the
page contains transparent content needing to be flattened can be determined by
straightforward analysis of the page’s resources; it is not necessary to analyze the
content stream itself. The conversion to opaque form is irreversible, since all in-
formation about how the transparency effects were produced is lost.
To perform the transparency computations properly, the application needs to
know the native color space of the output device. This is no problem when the ap-
plication controls the output device directly. However, when generating Post-
Script output, the application has no way of knowing the native color space of the
PostScript output device. An incorrect assumption will ruin the calibration of any
CIE-based colors appearing on the page. This problem can be addressed in either
of two ways:
• If the entire page consists of CIE-based colors, flatten the colors to a single CIE-
based color space rather than to a device color space. The preferred color space
for this purpose can easily be determined if the page has a group attributes dic-
tionary (
Group entry in the page object) specifying a CIE-based color space
(see Section 7.5.5, “Transparency Group XObjects”).
• Otherwise, flatten the colors to some assumed device color space with pre-
determined calibration. In the generated PostScript output, paint the flattened
colors in a CIE-based color space having that calibration.
Because the choice between using spot colorants and converting them to an alter-
nate color space affects the flattened results of process colors, a decision must also
be made during PostScript conversion about the set of available spot colorants to
assume. (This differs from strictly opaque painting, where the decision can be
deferred until the generated PostScript code is executed.)
TransparencyCHAPTER 7
546
547
CHAPTER 8
8Interactive Features
This chapter describes the PDF features that allow a user to interact with a docu-
ment on the screen, using the mouse and keyboard (with the exception of multi-
media features, which are described in Chapter 9, “Multimedia Features”):
• Preference settings to control the way the document is presented on the screen
(Section 8.1, “Viewer Preferences”)
• Navigation facilities for moving through the document in a variety of ways
(Sections 8.2, “Document-Level Navigation,” and 8.3, “Page-Level Navigation”)
• Annotations for adding text notes, sounds, movies, and other ancillary infor-
mation to the document (Section 8.4, “Annotations”)
• Actions that can be triggered by specified events (Section 8.5, “Actions”)
• Interactive forms for gathering information from the user (Section 8.6, “Interac-
tive Forms”)
• Digital signatures that authenticate the identity of a user and the validity of the
document’s contents (Section 8.7, “Digital Signatures”)
• Measurement properties that enable the display of real-world units correspond-
ing to objects on a page (Section 8.8, “Measurement Properties”)
8.1 Viewer Preferences
The ViewerPreferences entry in a document’s catalog (see Section 3.6.1, “Docu-
ment Catalog”) designates a viewer preferences dictionary (PDF 1.2) controlling
the way the document is to be presented on the screen or in print. If no such dic-
tionary is specified, viewing and printing applications should behave in accor-
dance with their own current user preference settings. Table 8.1 shows the
Interactive FeaturesCHAPTER 8
548
contents of the viewer preferences dictionary. (See implementation note 73 in
Appendix H.)
TABLE 8.1 Entries in a viewer preferences dictionary
KEY TYPE VALUE
HideToolbar boolean (Optional) A flag specifying whether to hide the viewer application’s tool
bars when the document is active. Default value:
false.
HideMenubar boolean (Optional) A flag specifying whether to hide the viewer application’s
menu bar when the document is active. Default value:
false.
HideWindowUI boolean (Optional) A flag specifying whether to hide user interface elements in
the document’s window (such as scroll bars and navigation controls),
leaving only the document’s contents displayed. Default value:
false.
FitWindow boolean (Optional) A flag specifying whether to resize the document’s window to
fit the size of the first displayed page. Default value:
false.
CenterWindow boolean (Optional) A flag specifying whether to position the document’s window
in the center of the screen. Default value:
false.
DisplayDocTitle boolean (Optional; PDF 1.4) A flag specifying whether the window’s title bar
should display the document title taken from the
Title entry of the docu-
ment information dictionary (see Section 10.2.1, “Document Informa-
tion Dictionary”). If
false, the title bar should instead display the name
of the PDF file containing the document. Default value:
false.
NonFullScreenPageMode name (Optional) The document’s page mode, specifying how to display the
document on exiting full-screen mode:
UseNone Neither document outline nor thumbnail images
visible
UseOutlines Document outline visible
UseThumbs Thumbnail images visible
UseOC Optional content group panel visible
This entry is meaningful only if the value of the
PageMode entry in the
catalog dictionary (see Section 3.6.1, “Document Catalog”) is
FullScreen;
it is ignored otherwise. Default value:
UseNone.
Viewer PreferencesSECTION 8.1
549
Direction name (Optional; PDF 1.3) The predominant reading order for text:
L2R Left to right
R2L Right to left (including vertical writing systems, such
as Chinese, Japanese, and Korean)
This entry has no direct effect on the document’s contents or page num-
bering but can be used to determine the relative positioning of pages
when displayed side by side or printed n-up. Default value:
L2R.
ViewArea name (Optional; PDF 1.4) The name of the page boundary representing the
area of a page to be displayed when viewing the document on the screen.
The value is the key designating the relevant page boundary in the page
object (see “Page Objects” on page 119 and Section 10.10.1, “Page
Boundaries”). If the specified page boundary is not defined in the page
object, its default value is used, as specified in Table 3.27 on page 119.
Default value:
CropBox.
Note: This entry is intended primarily for use by prepress applications that
interpret or manipulate the page boundaries as described in Section
10.10.1, “Page Boundaries.” Most PDF consumer applications disregard it.
ViewClip name (Optional; PDF 1.4) The name of the page boundary to which the con-
tents of a page are to be clipped when viewing the document on the
screen. The value is the key designating the relevant page boundary in
the page object (see “Page Objects” on page 119 and Section 10.10.1,
“Page Boundaries”). If the specified page boundary is not defined in the
page object, its default value is used, as specified in Table 3.27 on page
119. Default value:
CropBox.
Note: This entry is intended primarily for use by prepress applications that
interpret or manipulate the page boundaries as described in Section
10.10.1, “Page Boundaries.” Most PDF consumer applications disregard it.
PrintArea name (Optional; PDF 1.4) The name of the page boundary representing the
area of a page to be rendered when printing the document. The value is
the key designating the relevant page boundary in the page object (see
“Page Objects” on page 119 and Section 10.10.1, “Page Boundaries”). If
the specified page boundary is not defined in the page object, its default
value is used, as specified in Table 3.27 on page 119. Default value:
CropBox.
Note: This entry is intended primarily for use by prepress applications that
interpret or manipulate the page boundaries as described in Section
10.10.1, “Page Boundaries.” Most PDF consumer applications disregard it.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
550
8.2 Document-Level Navigation
The features described in this section allow a PDF viewer application to present
the user with an interactive, global overview of a document in either of two forms:
• As a hierarchical outline showing the document’s internal structure
• As a collection of thumbnail images representing the pages of the document in
miniature form
Each item in the outline or each thumbnail image can be associated with a corre-
sponding destination in the document, so that the user can jump directly to the
destination by clickingwith the mouse.
PrintClip name (Optional; PDF 1.4) The name of the page boundary to which the con-
tents of a page are to be clipped when printing the document. The value
is the key designating the relevant page boundary in the page object (see
“Page Objects” on page 119 and Section 10.10.1, “Page Boundaries”). If
the specified page boundary is not defined in the page object, its default
value is used, as specified in Table 3.27 on page 119. Default value:
CropBox.
Note: This entry is intended primarily for use by prepress applications that
interpret or manipulate the page boundaries as described in Section
10.10.1, “Page Boundaries.” Most PDF consumer applications disregard it.
PrintScaling
name (Optional; PDF 1.6) The page scaling option to be selected when a print
dialog is displayed for this document. Valid values are
None, which indi-
cates that the print dialog should reflect no page scaling, and
AppDefault,
which indicates that applications should use the current print scaling. If
this entry has an unrecognized value, applications should use the cur-
rent print scaling. Default value:
AppDefault.
Note: If the print dialog is suppressed and its parameters are provided di-
rectly by the application, the value of this entry should still be used.
KEY TYPE VALUE
Document-Level NavigationSECTION 8.2
551
8.2.1 Destinations
A destination defines a particular view of a document, consisting of the following
items:
• The page of the document to be displayed
• The location of the document window on that page
• The magnification (zoom) factor to use when displaying the page
Destinations may be associated with outline items (see Section 8.2.2, “Document
Outline”), annotations (“Link Annotations” on page 587), or actions (“Go-To Ac-
tions” on page 616 and “Remote Go-To Actions” on page 617). In each case, the
destination specifies the view of the document to be presented when the outline
item or annotation is opened or the action is performed. In addition, the optional
OpenAction entry in a document’s catalog (Section 3.6.1, “Document Catalog”)
may specify a destination to be displayed when the document is opened. A desti-
nation may be specified either explicitly by an array of parameters defining its
properties or indirectly by name.
Explicit Destinations
Table 8.2 shows the allowed syntactic forms for specifying a destination explicitly
in a PDF file. In each case,
page is an indirect reference to a page object. All coor-
dinate values (
left, right, top, and bottom) are expressed in the default user space
coordinate system. The page’s bounding box is the smallest rectangle enclosing all
of its contents. (If any side of the bounding box lies outside the page’s crop box,
the corresponding side of the crop box is used instead; see Section 10.10.1, “Page
Boundaries,” for further discussion of the crop box.)
Note: No page object can be specified for a destination associated with a remote go-
to action (see “Remote Go-To Actions” on page 617) because the destination page is
in a different PDF document. In this case, the
page parameter specifies a page num-
ber within the remote document instead of a page object in the current document.
Interactive FeaturesCHAPTER 8
552
TABLE 8.2 Destination syntax
SYNTAX MEANING
[page /XYZ left top zoom]
Display the page designated by page, with the coordinates (left, top) posi-
tioned at the upper-left corner of the window and the contents of the page
magnified by the factor
zoom. A null value for any of the parameters left, top,
or
zoom specifies that the current value of that parameter is to be retained un-
changed. A
zoom value of 0 has the same meaning as a null value.
[page /Fit]
Display the page designated by page, with its contents magnified just enough
to fit the entire page within the window both horizontally and vertically. If
the required horizontal and vertical magnification factors are different, use
the smaller of the two, centering the page within the window in the other
dimension.
[page /FitH top]
Display the page designated by page, with the vertical coordinate top posi-
tioned at the top edge of the window and the contents of the page magnified
just enough to fit the entire width of the page within the window.
[page /FitV left]
Display the page designated by page, with the horizontal coordinate left posi-
tioned at the left edge of the window and the contents of the page magnified
just enough to fit the entire height of the page within the window.
[page /FitR left bottom right top]
Display the page designated by page, with its contents magnified just enough
to fit the rectangle specified by the coordinates
left, bottom, right, and top
entirely within the window both horizontally and vertically. If the required
horizontal and vertical magnification factors are different, use the smaller of
the two, centering the rectangle within the window in the other dimension.
[page /FitB]
(PDF 1.1) Display the page designated by page, with its contents magnified
just enough to fit its bounding box entirely within the window both hori-
zontally and vertically. If the required horizontal and vertical magnification
factors are different, use the smaller of the two, centering the bounding box
within the window in the other dimension.
[page /FitBH top]
(PDF 1.1) Display the page designated by page, with the vertical coordinate
top positioned at the top edge of the window and the contents of the page
magnified just enough to fit the entire width of its bounding box within the
window.
[page /FitBV left]
(PDF 1.1) Display the page designated by page, with the horizontal coordi-
nate
left positioned at the left edge of the window and the contents of the page
magnified just enough to fit the entire height of its bounding box within the
window.
Document-Level NavigationSECTION 8.2
553
Named Destinations
Instead of being defined directly with the explicit syntax shown in Table 8.2, a
destination may be referred to indirectly by means of a name object (PDF 1.1) or
a string (PDF 1.2). This capability is especially useful when the destination is lo-
cated in another PDF document. For example, a link to the beginning of Chapter
6 in another document might refer to the destination by a name, such as
Chap6.begin, instead of by an explicit page number in the other document. Then,
the location of the chapter in the other document could change without invalidat-
ing the link. If an annotation or outline item that refers to a named destination
has an associated action, such as a remote go-to action (see “Remote Go-To Ac-
tions” on page 617) or a thread action (“Thread Actions” on page 623), the desti-
nation is in the file specified by the action’s
F entry, if any; if there is no F entry,
the destination is in the current file.
In PDF 1.1, the correspondence between name objects and destinations is
defined by the
Dests entry in the document catalog (see Section 3.6.1, “Docu-
ment Catalog”). The value of this entry is a dictionary in which each key is a des-
tination name and the corresponding value is either an array defining the
destination, using the syntax shown in Table 8.2, or a dictionary with a
D entry
whose value is such an array. The latter form allows additional attributes to be
associated with the destination, as well as enabling a go-to action (see “Go-To
Actions” on page 616) to be used as the target of a named destination.
In PDF 1.2, the correspondence between strings and destinations is defined by
the
Dests entry in the document’s name dictionary (see Section 3.6.3, “Name Dic-
tionary”). The value of this entry is a name tree (Section 3.8.5, “Name Trees”)
mapping name strings to destinations. (The keys in the name tree may be treated
as text strings for display purposes.) The destination value associated with a key
in the name tree may be either an array or a dictionary, as described in the pre-
ceding paragraph.
Note: The use of strings as destination names is a PDF 1.2 feature. If compatibility
with earlier versions of PDF is required, only name objects may be used to refer to
named destinations. A document that supports PDF 1.2 can contain both types.
However, if backward compatibility is not a consideration, applications should use
the string form of representation in the
Dests name tree.
Interactive FeaturesCHAPTER 8
554
8.2.2 Document Outline
A PDF document may optionally display a document outline on the screen, allow-
ing the user to navigate interactively from one part of the document to another.
The outline consists of a tree-structured hierarchy of outline items (sometimes
called bookmarks), which serve as a visual table of contents to display the docu-
ment’s structure to the user. The user can interactively open and close individual
items by clicking them with the mouse. When an item is open, its immediate chil-
dren in the hierarchy become visible on the screen; each child may in turn be
open or closed, selectively revealing or hiding further parts of the hierarchy.
When an item is closed, all of its descendants in the hierarchy are hidden. Click-
ing the text of any visible item activates the item, causing the viewer application to
jump to a destination or trigger an action associated with the item.
The root of a document’s outline hierarchy is an outline dictionary specified by
the
Outlines entry in the document catalog (see Section 3.6.1, “Document Cata-
log”). Table 8.3 shows the contents of this dictionary. Each individual outline item
within the hierarchy is defined by an outline item dictionary (Table 8.4). The
items at each level of the hierarchy form a linked list, chained together through
their
Prev and Next entries and accessed through the First and Last entries in the
parent item (or in the outline dictionary in the case of top-level items). When dis-
played on the screen, the items at a given level appear in the order in which they
occur in the linked list. (See also implementation note 74 in Appendix H.)
TABLE 8.3 Entries in the outline dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
Outlines for an outline dictionary.
First
dictionary (Required if there are any open or closed outline entries; must be an indirect ref-
erence) An outline item dictionary representing the first top-level item in the
outline.
Last
dictionary (Required if there are any open or closed outline entries; must be an indirect ref-
erence) An outline item dictionary representing the last top-level item in the
outline.
Count
integer (Required if the document has any open outline entries) The total number of
open items at all levels of the outline. This entry should be omitted if there are
no open outline items.
Document-Level NavigationSECTION 8.2
555
TABLE 8.4 Entries in an outline item dictionary
KEY TYPE VALUE
Title
text string (Required) The text to be displayed on the screen for this item.
Parent
dictionary (Required; must be an indirect reference) The parent of this item in the outline
hierarchy. The parent of a top-level item is the outline dictionary itself.
Prev
dictionary (Required for all but the first item at each level; must be an indirect reference)
The previous item at this outline level.
Next
dictionary (Required for all but the last item at each level; must be an indirect reference)
The next item at this outline level.
First
dictionary (Required if the item has any descendants; must be an indirect reference) The
first of this item’s immediate children in the outline hierarchy.
Last
dictionary (Required if the item has any descendants; must be an indirect reference) The
last of this item’s immediate children in the outline hierarchy.
Count
integer (Required if the item has any descendants) If the item is open, the total num-
ber of its open descendants at all lower levels of the outline hierarchy. If the
item is closed, a negative integer whose absolute value specifies how many
descendants would appear if the item were reopened.
Dest
name, string, or
array
(Optional; not permitted if an A entry is present) The destination to be dis-
played when this item is activated (see Section 8.2.1, “Destinations”; see also
implementation note 75 in Appendix H).
A
dictionary (Optional; PDF 1.1; not permitted if a Dest entry is present) The action to be
performed when this item is activated (see Section 8.5, “Actions”).
SE
dictionary (Optional; PDF 1.3; must be an indirect reference) The structure element to
which the item refers (see Section 10.6.1, “Structure Hierarchy”).
Note: The ability to associate an outline item with a structure element (such as
the beginning of a chapter) is a PDF 1.3 feature. For backward compatibility
with earlier PDF versions, such an item should also specify a destination (
Dest)
corresponding to an area of a page where the contents of the designated struc-
ture element are displayed.
C
array (Optional; PDF 1.4) An array of three numbers in the range 0.0 to 1.0, repre-
senting the components in the
DeviceRGB color space of the color to be used
for the outline entry’s text. Default value:
[0.0 0.0 0.0].
Interactive FeaturesCHAPTER 8
556
The value of the outline item dictionary’s F entry (PDF 1.4) is an unsigned 32-bit
integer containing flags specifying style characteristics for displaying the item. Bit
positions within the flag word are numbered from 1 (low-order) to 32 (high-
order). Table 8.5 shows the meanings of the flags; all undefined flag bits are
reserved and must be set to 0.
TABLE 8.5 Outline item flags
Example 8.1 shows a typical outline dictionary and outline item dictionary. See
Appendix G for an example of a complete outline hierarchy.
Example 8.1
21 0 obj
<< /Count 6
/First 22 0 R
/Last 29 0 R
>>
endobj
22 0 obj
<< /Title (Chapter 1)
/Parent 21 0 R
/Next 26 0 R
/First 23 0 R
/Last 25 0 R
/Count 3
/Dest [3 0 R /XYZ 0 792 0]
>>
endobj
F
integer (Optional; PDF 1.4) A set of flags specifying style characteristics for display-
ing the outline item’s text (see Table 8.5). Default value: 0.
BIT POSITION NAME MEANING
1 Italic If set, display the item in italic.
2 Bold If set, display the item in bold.
KEY TYPE VALUE
Document-Level NavigationSECTION 8.2
557
8.2.3 Thumbnail Images
A PDF document can define thumbnail images representing the contents of its
pages in miniature form. A viewer application can display these images on the
screen, allowing the user to navigate to a page by clicking its thumbnail image:
Note: Thumbnail images are not required, and may be included for some pages and
not for others.
The thumbnail image for a page is an image XObject specified by the
Thumb
entry in the page object (see “Page Objects” on page 119). It has the usual struc-
ture for an image dictionary (Section 4.8.4, “Image Dictionaries”), but only the
Width, Height, ColorSpace, BitsPerComponent, and Decode entries are signifi-
cant; all of the other entries listed in Table 4.39 on page 310 are ignored if present.
(If a
Subtype entry is specified, its value must be Image.) The image’s color space
must be either
DeviceGray or DeviceRGB, or an Indexed space based on one of
these. Example 8.2 shows a typical thumbnail image definition.
Example 8.2
12 0 obj
<< /Width 76
/Height 99
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Length 13 0 R
/Filter [/ASCII85Decode /DCTDecode]
>>
stream
s4IA>!"M;*Ddm8XA,lT0!!3,S!/(=R!<E3%!<N<(!WrK*!WrN,
…Omitted data…
endstream
endobj
13 0 obj % Length of stream
…
endobj
Interactive FeaturesCHAPTER 8
558
8.3 Page-Level Navigation
This section describes PDF facilities that enable the user to navigate from page to
page within a document:
• Page labels for numbering or otherwise identifying individual pages (see Sec-
tion 8.3.1)
• Article threads, which chain together items of content within the document that
are logically connected but not physically sequential (see Section 8.3.2)
• Presentations that display the document in the form of a slide show, advancing
from one page to the next either automatically or under user control (see Sec-
tion 8.3.3)
For another important form of page-level navigation, see “Link Annotations” on
page 587.
8.3.1 Page Labels
Each page in a PDF document is identified by an integer page index that expresses
the page’s relative position within the document. In addition, a document may
optionally define page labels (PDF 1.3) to identify each page visually on the screen
or in print. Page labels and page indices need not coincide: the indices are fixed,
running consecutively through the document starting from 0 for the first page,
but the labels can be specified in any way that is appropriate for the particular
document. For example, if the document begins with 12 pages of front matter
numbered in roman numerals and the remainder of the document is numbered
in arabic, the first page would have a page index of 0 and a page label of
i, the
twelfth page would have index 11 and label
xii, and the thirteenth page would
have index 12 and label
1.
For purposes of page labeling, a document can be divided into labeling ranges,
each of which is a series of consecutive pages using the same numbering system.
Pages within a range are numbered sequentially in ascending order. A page’s label
consists of a numeric portion based on its position within its labeling range,
optionally preceded by a label prefix denoting the range itself. For example, the
pages in an appendix might be labeled with decimal numeric portions prefixed
with the string
A; the resulting page labels would be A1, A2, and so on.
Page-Level NavigationSECTION 8.3
559
A document’s labeling ranges are defined by the PageLabels entry in the docu-
ment catalog (see Section 3.6.1, “Document Catalog”). The value of this entry is a
number tree (Section 3.8.6, “Number Trees”), each of whose keys is the page
index of the first page in a labeling range. The corresponding value is a page label
dictionary defining the labeling characteristics for the pages in that range. The
tree must include a value for page index 0. Table 8.6 shows the contents of a page
label dictionary. (See implementation note 76 in Appendix H.)
Example 8.3 shows a document with pages labeled
i, ii, iii, iv, 1, 2, 3, A8, A9, …
Example 8.3
1 0 obj
<< /Type /Catalog
/PageLabels << /Nums [ 0 << /S /r >> % A number tree containing
4 << /S /D >> % three page label dictionaries
7<</S/D
/P (A)
/St 8
>>
]
>>
…
>>
endobj
TABLE 8.6 Entries in a page label dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
PageLabel for a page label dictionary.
Interactive FeaturesCHAPTER 8
560
8.3.2 Articles
Some types of documents may contain sequences of content items that are logi-
cally connected but not physically sequential. For example, a news story may be-
gin on the first page of a newsletter and run over onto one or more
nonconsecutive interior pages. To represent such sequences of physically discon-
tiguous but logically related items, a PDF document may define one or more arti-
cles (PDF 1.1). The sequential flow of an article is defined by an article thread; the
individual content items that make up the article are called beads on the thread.
PDF viewer applications can provide navigation facilities to allow the user to fol-
low a thread from one bead to the next.
The optional
Threads entry in the document catalog (see Section 3.6.1, “Docu-
ment Catalog”) holds an array of thread dictionaries (Table 8.7) defining the doc-
ument’s articles. Each individual bead within a thread is represented by a bead
dictionary (Table 8.8). The thread dictionary’s
F entry points to the first bead in
the thread; the beads are chained together sequentially in a doubly linked list
through their
N (next) and V (previous) entries. In addition, for each page on
which article beads appear, the page object (see “Page Objects” on page 119)
should contain a
B entry whose value is an array of indirect references to the
beads on the page, in drawing order.
S
name (Optional) The numbering style to be used for the numeric portion of each page label:
D Decimal arabic numerals
R Uppercase roman numerals
r Lowercase roman numerals
A Uppercase letters (A to Z for the first 26 pages, AA to ZZ for the next 26, and so on)
a Lowercase letters (a to z for the first 26 pages, aa to zz for the next 26, and so on)
There is no default numbering style; if no
S entry is present, page labels consist solely of a
label prefix with no numeric portion. For example, if the
P entry (below) specifies the label
prefix
Contents, each page is simply labeled Contents with no page number. (If the P entry
is also missing or empty, the page label is an empty string.)
P
text string (Optional) The label prefix for page labels in this range.
St
integer (Optional) The value of the numeric portion for the first page label in the range. Sub-
sequent pages are numbered sequentially from this value, which must be greater than or
equal to 1. Default value: 1.
KEY TYPE VALUE
Page-Level NavigationSECTION 8.3
561
TABLE 8.7 Entries in a thread dictionary
TABLE 8.8 Entries in a bead dictionary
Example 8.4 shows a thread with three beads.
Example 8.4
22 0 obj
<< /F 23 0 R
/I << /Title (Man Bites Dog) >>
>>
endobj
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
Thread for a thread dictionary.
F
dictionary (Required; must be an indirect reference) The first bead in the thread.
I
dictionary (Optional) A thread information dictionary containing information about the thread,
such as its title, author, and creation date. The contents of this dictionary are similar
to those of the document information dictionary (see Section 10.2.1, “Document In-
formation Dictionary”).
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
Bead for a bead dictionary.
T
dictionary (Required for the first bead of a thread; optional for all others; must be an indirect refer-
ence) The thread to which this bead belongs.
Note: In PDF 1.1, this entry is permitted only for the first bead of a thread. In PDF 1.2
and higher, it is permitted for any bead but required only for the first.
N
dictionary (Required; must be an indirect reference) The next bead in the thread. In the last bead,
this entry points to the first.
V
dictionary (Required; must be an indirect reference) The previous bead in the thread. In the first
bead, this entry points to the last.
P
dictionary (Required; must be an indirect reference) The page object representing the page on
which this bead appears.
R
rectangle (Required) A rectangle specifying the location of this bead on the page.
Interactive FeaturesCHAPTER 8
562
23 0 obj
<< /T 22 0 R
/N 24 0 R
/V 25 0 R
/P 8 0 R
/R [158 247 318 905]
>>
endobj
24 0 obj
<< /T 22 0 R
/N 25 0 R
/V 23 0 R
/P 8 0 R
/R [322 246 486 904]
>>
endobj
25 0 obj
<< /T 22 0 R
/N 23 0 R
/V 24 0 R
/P 10 0 R
/R [157 254 319 903]
>>
endobj
8.3.3 Presentations
Some PDF viewer applications may allow a document to be displayed in the form
of a presentation or slide show, advancing from one page to the next either auto-
matically or under user control. In addition, PDF 1.5 introduces the ability to ad-
vance between different states of the same page (see “Sub-page Navigation” on
page 566).
Note: PDF 1.4 introduces a different mechanism, known as alternate presentations,
for slide show displays, described in Section 9.4, “Alternate Presentations.”
A page object (see “Page Objects” on page 119) may contain two optional entries,
Dur and Trans (PDF 1.1), to specify how to display that page in presentation
mode. The
Trans entry contains a transition dictionary describing the style and
duration of the visual transition to use when moving from another page to the
given page during a presentation. Table 8.9 shows the contents of the transition
Page-Level NavigationSECTION 8.3
563
dictionary. (Some of the entries shown are needed only for certain transition
styles, as indicated in the table.)
The
Dur entry in the page object specifies the page’s display duration (also called
its advance timing): the maximum length of time, in seconds, that the page is dis-
played before the presentation automatically advances to the next page. (The user
can advance the page manually before the specified time has expired.) If no
Dur
entry is specified in the page object, the page does not advance automatically.
TABLE 8.9 Entries in a transition dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
Trans for a transition dictionary.
S
name (Optional) The transition style to use when moving to this page from another during a
presentation. Default value:
R.
Split Two lines sweep across the screen, revealing the new page. The lines may
be either horizontal or vertical and may move inward from the edges of
the page or outward from the center, as specified by the
Dm and M
entries, respectively.
Blinds Multiple lines, evenly spaced across the screen, synchronously sweep in
the same direction to reveal the new page. The lines may be either hori-
zontal or vertical, as specified by the
Dm entry. Horizontal lines move
downward; vertical lines move to the right.
Box A rectangular box sweeps inward from the edges of the page or outward
from the center, as specified by the
M entry, revealing the new page.
Wipe A single line sweeps across the screen from one edge to the other in the
direction specified by the
Di entry, revealing the new page.
Dissolve The old page dissolves gradually to reveal the new one.
Glitter Similar to Dissolve, except that the effect sweeps across the page in a
wide band moving from one side of the screen to the other in the direc-
tion specified by the
Di entry.
R The new page simply replaces the old one with no special transition ef-
fect; the
D entry is ignored.
Fly (PDF 1.5) Changes are flown out or in (as specified by M), in the direc-
tion specified by
Di, to or from a location that is offscreen except when
Di is None.
Interactive FeaturesCHAPTER 8
564
Push (PDF 1.5) The old page slides off the screen while the new page slides in,
pushing the old page out in the direction specified by
Di.
Cover (PDF 1.5) The new page slides on to the screen in the direction specified
by
Di, covering the old page.
Uncover (PDF 1.5) The old page slides off the screen in the direction specified by
Di, uncovering the new page in the direction specified by Di.
Fade (PDF 1.5) The new page gradually becomes visible through the old one.
D
number (Optional) The duration of the transition effect, in seconds. Default value: 1.
Dm
name (Optional; Split and Blinds transition styles only) The dimension in which the specified
transition effect occurs:
H Horizontal
V Ve rti ca l
Default value:
H.
M
name (Optional; Split, Box and Fly transition styles only) The direction of motion for the speci-
fied transition effect:
I Inward from the edges of the page
O Outward from the center of the page
Default value:
I.
Di
number or
name
(Optional; Wipe, Glitter, Fly, Cover, Uncover and Push transition styles only) The direction
in which the specified transition effect moves, expressed in degrees counterclockwise
starting from a left-to-right direction. (This differs from the page object’s
Rotate entry,
which is measured clockwise from the top.)
The following numeric values are valid:
0 Left to right
90 Bottom to top (
Wipe only)
180 Right to left (
Wipe only)
270 Top to bottom
315 Top-left to bottom-right (
Glitter only)
The only valid name value is
None, which is relevant only for the Fly transition when
the value of
SS is not 1.0.
Default value: 0.
KEY TYPE VALUE
Page-Level NavigationSECTION 8.3
565
Figure 8.1 illustrates the relationship between transition duration (D in the transi-
tion dictionary) and display duration (
Dur in the page object). Note that the tran-
sition duration specified for a page (page 2 in the figure) governs the transition to
that page from another page; the transition from the page is governed by the next
page’s transition duration.
FIGURE 8.1 Presentation timing
Example 8.5 shows the presentation parameters for a page to be displayed for 5
seconds. Before the page is displayed, there is a 3.5-second transition in which
two vertical lines sweep outward from the center to the edges of the page.
SS
number (Optional; PDF 1.5; Fly transition style only) The starting or ending scale at which the
changes are drawn. If
M specifies an inward transition, the scale of the changes drawn
progresses from
SS to 1.0 over the course of the transition. If M specifies an outward
transition, the scale of the changes drawn progresses from 1.0 to
SS over the course of
the transition
Default: 1.0.
B
boolean (Optional; PDF 1.5; Fly transition style only) If true, the area to be flown in is rectangu-
lar and opaque. Default:
false.
KEY TYPE VALUE
Transition from
page 1 to page 2 Page 2 displayed
Transition from
page 2 to page 3
Transition duration
for page 2
Display duration for page 2 Transition duration
for page 3
. . .. . .
Interactive FeaturesCHAPTER 8
566
Example 8.5
10 0 obj
<< /Type /Page
/Parent 4 0 R
/Contents 16 0 R
/Dur 5
/Trans << /Type /Trans
/D 3.5
/S /Split
/Dm /V
/M /O
>>
>>
endobj
Sub-page Navigation
Sub-page navigation (PDF 1.5) allows navigating not only between pages but also
between different states of the same page. For example, a single page in a PDF
presentation could have a series of bullet points that could be individually turned
on and off. In such an example, the bullets would be represented by optional con-
tent (see Section 4.10, “Optional Content”), and each state of the page would be
represented as a navigation node.
Note: Viewer applications should save the state of optional content groups when a
user enters presentation mode and restore it when presentation mode ends. This en-
sures, for example, that transient changes to bullets do not affect the printing of the
document.
A navigation node dictionary (see Table 8.10) specifies actions to execute when
the user makes a navigation request; for example, by pressing an arrow key. The
navigation nodes on a page form a doubly linked list by means of their
Next and
Prev entries. The primary node on a page is determined by the optional PresSteps
entry in a page dictionary (see Table 3.27).
Note: It is recommended that a viewer application respect navigation nodes only
when in presentation mode (see Section 8.3.3, “Presentations”).
Page-Level NavigationSECTION 8.3
567
TABLE 8.10 Entries in a navigation node dictionary
A viewer application should support the notion of a current navigation node.
When a user navigates to a page, if the page dictionary has a
PresSteps entry, the
node specified by that entry becomes the current node. (Otherwise, there is no
current node.) If there is a request to navigate forward (such as an arrow key
press) and there is a current navigation node, the following occurs:
1. The sequence of actions specified by
NA (if present) is executed.
Note: If
NA specifies an action that navigates to another page, the actions de-
scribed below for navigating to another page take place, and
Next should not be
present.
2. The node specified by
Next (if present) becomes the new current navigation
node.
Similarly, if there is a request to navigate backward and there is a current naviga-
tion node, the following occurs:
1. The sequence of actions specified by
PA (if present) is executed.
Note: If
PA specifies an action that navigates to another page, the actions de-
scribed below for navigating to another page take place, and
Prev should not be
present.
2. The node specified by
Prev (if present) becomes the new current navigation
node.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; must be NavNode
for a navigation node dictionary.
NA
dictionary (Optional) The sequence of actions to execute when a user navigates forward.
PA
dictionary (Optional) The sequence of actions to execute when a user navigates backward.
Next
dictionary (Optional) The next navigation node, if any.
Prev
dictionary (Optional) The previous navigation node, if any.
Dur
number (Optional) The maximum number of seconds before the viewer application should
automatically advance forward to the next navigation node. If this entry is not spec-
ified, no automatic advance should occur.
Interactive FeaturesCHAPTER 8
568
When navigating between nodes, it is possible to specify transition effects. These
effects are similar to the page transitions specified in the previous section. How-
ever, they use a different mechanism; see “Transition Actions” on page 632.
Note: “Forward” and “backward” are determined by user actions, such as pressing
right or left arrow keys, not by the actual page that is the destination of an action.
If there is a request to navigate to another page (regardless of whether there is a
current node) and that page’s dictionary contains a
PresSteps entry, the following
occurs:
1. The navigation node represented by
PresSteps becomes the current node.
2. If the navigation request was forward, or if the navigation request was for ran-
dom access (such as by clicking on a link), the actions specified by
NA are exe-
cuted and the node specified by
Next becomes the new current node, as
described above.
If the navigation request was backward, the actions specified by
PA are execut-
ed and the node specified by
Prev becomes the new current node, as described
above.
3. The viewer application makes the new page the current page and displays it.
Any page transitions specified by the
Trans entry of the page dictionary are
performed.
8.4 Annotations
An annotation associates an object such as a note, sound, or movie with a location
on a page of a PDF document, or provides a way to interact with the user by
means of the mouse and keyboard. PDF includes a wide variety of standard an-
notation types, described in detail in Section 8.4.5, “Annotation Types.”
Many of the standard annotation types may be displayed in either the open or the
closed state. When closed, they appear on the page in some distinctive form, such
as an icon, a box, or a rubber stamp, depending on the specific annotation type.
When the user activates the annotation by clicking it, it exhibits its associated ob-
ject, such as by opening a pop-up window displaying a text note (Figure 8.2) or by
playing a sound or a movie.
AnnotationsSECTION 8.4
569
FIGURE 8.2 Open annotation
Viewer applications may permit the user to navigate through the annotations on a
page by using the keyboard (in particular, the tab key); see implementation note
77 in Appendix H. Beginning with PDF 1.5, PDF producers may make the navi-
gation order explicit with the optional
Tabs entry in a page object (see Table 3.27).
The following are the possible values for this entry:
• R (row order): Annotations are visited in rows running horizontally across the
page. The direction within a row is determined by the
Direction entry in the
viewer preferences dictionary (see Section 8.1, “Viewer Preferences”). The first
annotation visited is the first annotation in the topmost row. When the end of a
row is encountered, the first annotation in the next row is visited.
• C (column order): Annotations are visited in columns running vertically up and
down the page. Columns are ordered by the
Direction entry in the viewer pref-
erences dictionary (see Section 8.1, “Viewer Preferences”). The first annotation
visited is the one at the top of the first column. When the end of a column is en-
countered, the first annotation in the next column is visited.
W
E HAVE BEEN TRACKING GREAT EMPLOYEES SINCE
1981,
when we began research on our book The 100 Best
Companies to Work for in America. From our database of
more than 1,000 companies, we selected 238 as the most
viable candidates for this list. Of this group, 161 agreed to
participate. (To be eligible, a company must be at least ten
years old and have a minimum of 500 employees.)
We asked each candidate company to distribute to 225
randomly selected employees the Great Place to Work
Trust Index. This employee survey was designed by the
Great Place to Work Institute of San Francisco to evaluate
trust in management, pride in work/company, and
camaraderie. Responses were returned directly to us.
Each company was also required to fill out the Hewitt
People Practices Inventory, a comprehensive 29-page
questionnaire designed by our partner in this project,
Hewitt Associates of Lincolnshire, Ill., a leading
management consulting firm. Finally we asked each of our
candidates to send us additional corporate materials, such
This is the text associated with the
highlight annotation.
Comment
Interactive FeaturesCHAPTER 8
570
• S (structure order): Annotations are visited in the order in which they appear in
the structure tree (see Section 10.6, “Logical Structure”). The order for annota-
tions that are not included in the structure tree is application-dependent.
Note: The descriptions above assume the page is being viewed in the orientation
specified by the
Rotate entry.
The behavior of each annotation type is implemented by a software module
called an annotation handler. Handlers for the standard annotation types are built
directly into the PDF viewer application; handlers for additional types can be
supplied as plug-in extensions.
8.4.1 Annotation Dictionaries
The optional Annots entry in a page object (see “Page Objects” on page 119)
holds an array of annotation dictionaries, each representing an annotation associ-
ated with the given page. Table 8.11 shows the required and optional entries that
are common to all annotation dictionaries. The dictionary may contain addition-
al entries specific to a particular annotation type; see the descriptions of individu-
al annotation types in Section 8.4.5, “Annotation Types,” for details.
Note: A given annotation dictionary may be referenced from the
Annots array of
only one page. Attempting to share an annotation dictionary among multiple pages
produces unpredictable behavior. This requirement applies only to the annotation
dictionary itself, not to subsidiary objects, which can be shared among multiple an-
notations without causing any difficulty.
TABLE 8.11 Entries common to all annotation dictionaries
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
Annot for an annotation dictionary.
Subtype
name (Required) The type of annotation that this dictionary describes; see Table
8.16 on page 580 for specific values.
Rect
rectangle (Required) The annotation rectangle, defining the location of the annotation
on the page in default user space units.
AnnotationsSECTION 8.4
571
Contents
text string (Optional) Text to be displayed for the annotation or, if this type of annota-
tion does not display text, an alternate description of the annotation’s con-
tents in human-readable form. In either case, this text is useful when
extracting the document’s contents in support of accessibility to users with
disabilities or for other purposes (see Section 10.8.2, “Alternate Descrip-
tions”). See Section 8.4.5, “Annotation Types” for more details on the mean-
ing of this entry for each annotation type.
P
dictionary (Optional; PDF 1.3; not used in FDF files) An indirect reference to the page
object with which this annotation is associated.
Note: This entry is required for screen annotations associated with rendition ac-
tions (PDF 1.5; see “Screen Annotations” on page 602 and “Rendition Actions”
on page 630).
NM
text string (Optional; PDF 1.4) The annotation name, a text string uniquely identifying it
among all the annotations on its page.
M
date or string (Optional; PDF 1.1) The date and time when the annotation was most
recently modified. The preferred format is a date string as described in Sec-
tion 3.8.3, “Dates,” but viewer applications should be prepared to accept and
display a string in any format. (See implementation note 78 in Appendix H.)
F
integer (Optional; PDF 1.1) A set of flags specifying various characteristics of the an-
notation (see Section 8.4.2, “Annotation Flags”). Default value: 0.
BS
dictionary (Optional; PDF 1.2) A border style dictionary specifying the characteristics of
the annotation’s border (see Section 8.4.3, “Border Styles”; see also implemen-
tation notes 79 and 86 in Appendix H).
Note: This entry also specifies the width and dash pattern for the lines drawn by
line, square, circle, and ink annotations. See the note under
Border (below) for
additional information.
AP
dictionary (Optional; PDF 1.2) An appearance dictionary specifying how the annotation
is presented visually on the page (see Section 8.4.4, “Appearance Streams” and
also implementation notes 79 and 80 in Appendix H). Individual annotation
handlers may ignore this entry and provide their own appearances.
AS
name (Required if the appearance dictionary AP contains one or more subdictionaries;
PDF 1.2) The annotation’s appearance state, which selects the applicable
appearance stream from an appearance subdictionary (see Section 8.4.4, “Ap-
pearance Streams” and also implementation note 79 in Appendix H).
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
572
Border
array (Optional) An array specifying the characteristics of the annotation’s border.
The border is specified as a rounded rectangle.
In PDF 1.0, the array consists of three numbers defining the horizontal cor-
ner radius, vertical corner radius, and border width, all in default user space
units. If the corner radii are 0, the border has square (not rounded) corners; if
the border width is 0, no border is drawn. (See implementation note 81 in
Appendix H.)
In PDF 1.1, the array may have a fourth element, an optional dash array
defining a pattern of dashes and gaps to be used in drawing the border. The
dash array is specified in the same format as in the line dash pattern parame-
ter of the graphics state (see “Line Dash Pattern” on page 187). For example, a
Border value of [0 0 1 [3 2]] specifies a border 1 unit wide, with square cor-
ners, drawn with 3-unit dashes alternating with 2-unit gaps. Note that no
dash phase is specified; the phase is assumed to be 0. (See implementation
note 82 in Appendix H.)
Note: In PDF 1.2 or later, this entry may be ignored in favor of the
BS entry (see
above); see implementation note 86 in Appendix H.
Default value:
[0 0 1].
C
array (Optional; PDF 1.1) An array of three numbers in the range 0.0 to 1.0, repre-
senting the components of a color in the
DeviceRGB color space. This color is
used for the following purposes:
• The background of the annotation’s icon when closed
• The title bar of the annotation’s pop-up window
• The border of a link annotation
A
dictionary (Optional; PDF 1.1) An action to be performed when the annotation is acti-
vated (see Section 8.5, “Actions”).
Note: This entry is not permitted in link annotations if a
Dest entry is present
(see “Link Annotations” on page 587). Also note that the
A entry in movie anno-
tations has a different meaning (see “Movie Annotations” on page 601).
AA
dictionary (Optional; PDF 1.2) An additional-actions dictionary defining the anno-
tation’s behavior in response to various trigger events (see Section 8.5.2,
“Trigger Events”). At the time of publication, this entry is used only by widget
annotations.
KEY TYPE VALUE
AnnotationsSECTION 8.4
573
8.4.2 Annotation Flags
The value of the annotation dictionary’s F entry is an unsigned 32-bit integer con-
taining flags specifying various characteristics of the annotation. Bit positions
within the flag word are numbered from 1 (low-order) to 32 (high-order). Table
8.12 shows the meanings of the flags; all undefined flag bits are reserved and must
be set to 0.
TABLE 8.12 Annotation flags
StructParent
integer (Required if the annotation is a structural content item; PDF 1.3) The integer
key of the annotation’s entry in the structural parent tree (see “Finding Struc-
ture Elements from Content Items” on page 797).
OC
dictionary (Optional; PDF 1.5) An optional content group or optional content member-
ship dictionary (see Section 4.10, “Optional Content”) specifying the optional
content properties for the annotation. Before the annotation is drawn, its vis-
ibility is determined based on this entry as well as the annotation flags speci-
fied in the
F entry (see Section 8.4.2, “Annotation Flags”). If it is determined
to be invisible, the annotation is skipped, as if it were not in the document.
BIT POSITION NAME MEANING
1 Invisible If set, do not display the annotation if it does not belong to one of the standard
annotation types and no annotation handler is available. If clear, display such an
unknown annotation using an appearance stream specified by its appearance
dictionary, if any (see Section 8.4.4, “Appearance Streams”).
2Hidden(PDF 1.2) If set, do not display or print the annotation or allow it to interact
with the user, regardless of its annotation type or whether an annotation
handler is available. In cases where screen space is limited, the ability to hide
and show annotations selectively can be used in combination with appearance
streams (see Section 8.4.4, “Appearance Streams”) to display auxiliary pop-up
information similar in function to online help systems. (See implementation
note 83 in Appendix H.)
3Print(PDF 1.2) If set, print the annotation when the page is printed. If clear, never
print the annotation, regardless of whether it is displayed on the screen. This
can be useful, for example, for annotations representing interactive pushbut-
tons, which would serve no meaningful purpose on the printed page. (See
implementation note 83 in Appendix H.)
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
574
If the NoZoom flag is set, the annotation always maintains the same fixed size on
the screen and is unaffected by the magnification level at which the page itself is
displayed. Similarly, if the NoRotate flag is set, the annotation retains its original
orientation on the screen when the page is rotated (by changing the
Rotate entry
in the page object; see “Page Objects” on page 119).
In either case, the annotation’s position is determined by the coordinates of the
upper-left corner of its annotation rectangle, as defined by the
Rect entry in the
annotation dictionary and interpreted in the default user space of the page. When
the default user space is scaled or rotated, the positions of the other three corners
4 NoZoom (PDF 1.3) If set, do not scale the annotation’s appearance to match the magnifi-
cation of the page. The location of the annotation on the page (defined by the
upper-left corner of its annotation rectangle) remains fixed, regardless of the
page magnification. See below for further discussion.
5 NoRotate (PDF 1.3) If set, do not rotate the annotation’s appearance to match the rotation
of the page. The upper-left corner of the annotation rectangle remains in a fixed
location on the page, regardless of the page rotation. See below for further dis-
cussion.
6 NoView (PDF 1.3) If set, do not display the annotation on the screen or allow it to
interact with the user. The annotation may be printed (depending on the setting
of the Print flag) but should be considered hidden for purposes of on-screen
display and user interaction.
7 ReadOnly (PDF 1.3) If set, do not allow the annotation to interact with the user. The
annotation may be displayed or printed (depending on the settings of the
NoView and Print flags) but should not respond to mouse clicks or change its
appearance in response to mouse motions.
Note: This flag is ignored for widget annotations; its function is subsumed by the
ReadOnly flag of the associated form field (see Table 8.66 on page 638).
8Locked(PDF 1.4) If set, do not allow the annotation to be deleted or its properties (in-
cluding position and size) to be modified by the user. However, this flag does
not restrict changes to the annotation’s contents, such as the value of a form
field. (See implementation note 84 in Appendix H.)
9 ToggleNoView (PDF 1.5) If set, invert the interpretation of the NoView flag for certain events. A
typical use is to have an annotation that appears only when a mouse cursor is
held over it; see implementation note 85 in Appendix H.
BIT POSITION NAME MEANING
AnnotationsSECTION 8.4
575
of the annotation rectangle are different in the altered user space than they were
in the original user space. The viewer application performs this alteration auto-
matically. However, it does not actually change the annotation’s
Rect entry, which
continues to describe the annotation’s relationship with the unscaled, unrotated
user space.
For example, Figure 8.3 shows how an annotation whose NoRotate flag is set re-
mains upright when the page it is on is rotated 90 degrees clockwise. The upper-
left corner of the annotation remains at the same point in default user space; the
annotation pivots around that point.
FIGURE 8.3 Coordinate adjustment with the NoRotate flag
8.4.3 Border Styles
An annotation may optionally be surrounded by a border when displayed or
printed. If present, the border is drawn completely inside the annotation rec-
tangle. In PDF 1.1, the characteristics of the border are specified by the
Border
entry in the annotation dictionary (see Table 8.11 on page 570). Beginning with
PDF 1.2, some types of annotations may instead specify their border characteris-
tics in a border style dictionary designated by the annotation’s
BS entry; see imple-
mentation note 86 in Appendix H. Such dictionaries are also used to specify the
width and dash pattern for the lines drawn by line, square, circle, and ink annota-
Before page rotation
abcdefghijklm
nopqrstuvwxyz
(0, 0)
After page rotation
abcdefghijklm
nopqrstuvwxyz
(0, 0)
Interactive FeaturesCHAPTER 8
576
tions. Table 8.13 summarizes the contents of the border style dictionary. If neither
the
Border nor the BS entry is present, the border is drawn as a solid line with a
width of 1 point.
TABLE 8.13 Entries in a border style dictionary
Beginning with PDF 1.5, some annotations (square, circle, and polygon) may
have a
BE entry, which is a border effect dictionary that specifies an effect to be ap-
plied to the border of the annotations. Its entries are listed in Table 8.14.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
Border for a border style dictionary.
W
number (Optional) The border width in points. If this value is 0, no border is drawn. Default
value: 1.
S
name (Optional) The border style:
S (Solid) A solid rectangle surrounding the annotation.
D (Dashed) A dashed rectangle surrounding the annotation. The dash pattern
is specified by the
D entry (see below).
B (Beveled) A simulated embossed rectangle that appears to be raised above the
surface of the page.
I (Inset) A simulated engraved rectangle that appears to be recessed below the
surface of the page.
U (Underline) A single line along the bottom of the annotation rectangle.
Other border styles may be defined in the future. (See implementation note 86 in
Appendix H.) Default value:
S.
D
array (Optional) A dash array defining a pattern of dashes and gaps to be used in drawing a
dashed border (border style
D above). The dash array is specified in the same format
as in the line dash pattern parameter of the graphics state (see “Line Dash Pattern” on
page 187). The dash phase is not specified and is assumed to be 0. For example, a
D
entry of [3 2] specifies a border drawn with 3-point dashes alternating with 2-point
gaps. Default value:
[3].
AnnotationsSECTION 8.4
577
TABLE 8.14 Entries in a border effect dictionary
8.4.4 Appearance Streams
Beginning with PDF 1.2, an annotation can specify one or more appearance
streams as an alternative to the simple border and color characteristics available
in earlier versions. Appearance streams enable the annotation to be presented vi-
sually in different ways to reflect its interactions with the user. Each appearance
stream is a form XObject (see Section 4.9, “Form XObjects”): a self-contained
content stream to be rendered inside the annotation rectangle.
The following method is used to map from the coordinate system of the appear-
ance XObject (as defined by its
Matrix entry; see Table 4.45) to the annotation’s
rectangle in default user space:
Algorithm 8.1
1. The appearance’s bounding box (specified by its BBox entry) is transformed, using
Matrix, to produce a quadrilateral with arbitrary orientation. The transformed ap-
pearance box is the smallest upright rectangle that encompasses this quadrilateral.
2. A matrix
A is computed that scales and translates the transformed appearance box
to align with the edges of the annotation’s rectangle (specified by the
Rect entry). A
maps the lower-left corner (the corner with the smallest x and y coordinates) and
the upper-right corner (the corner with the greatest x and y coordinates) of the
transformed appearance box to the corresponding corners of the annotation’s
rectangle.
3.
Matrix is concatenated with A to form a matrix AA that maps from the appearance’s
coordinate system to the annotation’s rectangle in default user space:
AA = A × Matrix
KEY TYPE VALUE
S
name (Optional) A name representing the border effect to apply. Possible values are:
S No effect: the border is as described by the annotation dictionary’s BS entry.
C The border should appear “cloudy”. The width and dash array specified by BS
are honored.
Default value:
S.
I
number (Optional; valid only if the value of S is C) A number describing the intensity of the ef-
fect. Suggested values range from 0 to 2. Default value: 0.
Interactive FeaturesCHAPTER 8
578
The annotation may be further scaled and rotated if either the NoZoom or
NoRotate flag is set (see Section 8.4.2, “Annotation Flags”). Any transformation
applied to the annotation as a whole is also applied to the appearance within it.
In PDF 1.4, an annotation appearance can include transparency. If the appear-
ance’s stream dictionary does not contain a
Group entry, it is treated as a non-iso-
lated, non-knockout transparency group. Otherwise, the isolated and knockout
values specified in the group dictionary (see Section 7.5.5, “Transparency Group
XObjects”) are used.
The transparency group is composited with a backdrop consisting of the page
content along with any previously painted annotations, using a blend mode of
Normal, an alpha constant of 1.0, and a soft mask of None. (See implementation
note 88 in Appendix H.)
Note: If a transparent annotation appearance is painted over an annotation that is
drawn without using an appearance stream, the effect is implementation-depen-
dent. This is because such annotations are sometimes drawn by means that do not
conform to the Adobe imaging model. Also, the effect of highlighting a transparent
annotation appearance is implementation-dependent.
An annotation can define as many as three separate appearances:
• The normal appearance is used when the annotation is not interacting with the
user. This appearance is also used for printing the annotation.
• The rollover appearance is used when the user moves the cursor into the anno-
tation’s active area without pressing the mouse button.
• The down appearance is used when the mouse button is pressed or held down
within the annotation’s active area.
Note: As used here, the term mouse denotes a generic pointing device that controls
the location of a cursor on the screen and has at least one button that can be pressed,
held down, and released. See Section 8.5.2, “Trigger Events,” for further discussion.
The normal, rollover, and down appearances are defined in an appearance
dictionary, which in turn is the value of the
AP entry in the annotation dictionary
(see Table 8.11 on page 570). Table 8.15 shows the contents of the appearance dic-
tionary.
AnnotationsSECTION 8.4
579
TABLE 8.15 Entries in an appearance dictionary
Each entry in the appearance dictionary may contain either a single appearance
stream or an appearance subdictionary. In the latter case, the subdictionary de-
fines multiple appearance streams corresponding to different appearance states of
the annotation.
For example, an annotation representing an interactive check box might have two
appearance states named
On and Off. Its appearance dictionary might be defined
as
/AP << /N << /On formXObject
1
/Off formXObject
2
>>
/D << /On formXObject
3
/Off formXObject
4
>>
>>
where formXObject
1
and formXObject
2
define the check box’s normal appearance
in its checked and unchecked states, and
formXObject
3
and formXObject
4
provide
visual feedback, such as emboldening its outline, when the user clicks it. (No
R
entry is defined because no special appearance is needed when the user moves
the cursor over the check box without pressing the mouse button.) The choice be-
tween the checked and unchecked appearance states is determined by the
AS en-
try in the annotation dictionary (see Table 8.11 on page 570).
Note: Some of the standard PDF annotation types, such as movie annotations—as
well as all custom annotation types defined by third parties—are implemented
through plug-in extensions. If the plug-in for a particular annotation type is not
available, PDF viewer applications should display the annotation with its normal
(
N) appearance. Viewer applications should also attempt to provide reasonable be-
KEY TYPE VALUE
N
stream or dictionary (Required) The annotation’s normal appearance.
R
stream or dictionary (Optional) The annotation’s rollover appearance. Default value: the value of
the
N entry.
D
stream or dictionary (Optional) The annotation’s down appearance. Default value: the value of the
N entry.
Interactive FeaturesCHAPTER 8
580
havior (such as displaying nothing) if an annotation’s AS entry designates an ap-
pearance state for which no appearance is defined in the appearance dictionary.
For convenience in managing appearance streams that are used repeatedly, the
AP
entry in a PDF document’s name dictionary (see Section 3.6.3, “Name Diction-
ary”) can contain a name tree mapping name strings to appearance streams. The
name strings have no standard meanings; no PDF objects refer to appearance
streams by name.
8.4.5 Annotation Types
PDF supports the standard annotation types listed in Table 8.16. The following
sections describe each of these types in detail. Plug-in extensions may add new
annotation types, and further standard types may be added in the future. (See im-
plementation note 89 in Appendix H.)
The values in the first column of Table 8.16 represent the value of the annotation
dictionary’s
Subtype entry. The third column indicates whether the annotation is
a markup annotation, as described in “Markup Annotations,” below. The section
also provides more information about the value of the
Contents entry for differ-
ent annotation types.
TABLE 8.16 Annotation types
ANNOTATION TYPE DESCRIPTION MARKUP? DISCUSSED IN SECTION
Text Text annotation Yes “Text Annotations” on page 586
Link Link annotation No “Link Annotations” on page 587
FreeText (PDF 1.3) Free text annotation Yes “Free Text Annotations” on page 588
Line (PDF 1.3) Line annotation Yes “Line Annotations” on page 590
Square (PDF 1.3) Square annotation Yes “Square and Circle Annotations” on page 593
Circle (PDF 1.3) Circle annotation Yes “Square and Circle Annotations” on page 593
Polygon
(PDF 1.5) Polygon annotation Yes “Polygon and Polyline Annotations” on page
595
PolyLine
(PDF 1.5) Polyline annotation Yes “Polygon and Polyline Annotations” on page
595
AnnotationsSECTION 8.4
581
Markup Annotations
As mentioned in Section 8.4.1, “Annotation Dictionaries”, the meaning of an an-
notation’s
Contents entry varies by annotation type. Typically, it is the text to be
displayed for the annotation or, if the annotation does not display text, an alter-
nate description of the annotation’s contents in human-readable form. In either
case, the
Contents entry is useful when extracting the document’s contents in
support of accessibility to users with disabilities or for other purposes (see Sec-
tion 10.8.2, “Alternate Descriptions”).
Highlight (PDF 1.3) Highlight annotation Yes “Text Markup Annotations” on page 596
Underline (PDF 1.3) Underline annotation Yes “Text Markup Annotations” on page 596
Squiggly (PDF 1.4) Squiggly-underline
annotation
Yes “Text Markup Annotations” on page 596
StrikeOut (PDF 1.3) Strikeout annotation Yes “Text Markup Annotations” on page 596
Stamp (PDF 1.3) Rubber stamp annotation Yes “Rubber Stamp Annotations” on page 598
Caret
(PDF 1.5) Caret annotation Yes “Caret Annotations” on page 597
Ink (PDF 1.3) Ink annotation Yes “Ink Annotations” on page 598
Popup (PDF 1.3) Pop-up annotation No “Pop-up Annotations” on page 599
FileAttachment (PDF 1.3) File attachment
annotation
Yes “File Attachment Annotations” on page 600
Sound (PDF 1.2) Sound annotation Yes “Sound Annotations” on page 600
Movie (PDF 1.2) Movie annotation No “Movie Annotations” on page 601
Widget (PDF 1.2) Widget annotation No “Widget Annotations” on page 603
Screen
(PDF 1.5) Screen annotation No “Screen Annotations” on page 602
PrinterMark (PDF 1.4) Printer’s mark annotation No “Printer’s Mark Annotations” on page 605
TrapNet (PDF 1.3) Trap network annotation No “Trap Network Annotations” on page 605
Watermark
(PDF 1.6) Watermark annotation No “Watermark Annotations” on page 606
3D
(PDF 1.6) 3D annotation No “3D Annotations” on page 747
ANNOTATION TYPE DESCRIPTION MARKUP? DISCUSSED IN SECTION
Interactive FeaturesCHAPTER 8
582
Many annotation types are defined as markup annotations because they are used
primarily to mark up PDF documents (see Table 8.16). These annotations have
text that appears as part of the annotation and may be displayed in other ways by
a viewer application, such as in a Comments pane.
Markup annotations can be divided into the following groups:
• Free text annotations display text directly on the page. The annotation’s
Contents entry specifies the displayed text.
• Most other markup annotations have an associated pop-up window that may
contain text. The annotation’s
Contents entry specifies the text to be displayed
when the pop-up window is opened. These include text, line, square, circle,
polygon, polyline, highlight, underline, squiggly-underline, strikeout, rubber
stamp, caret, ink, and file attachment annotations.
• Sound annotations do not have a pop-up window but may also have associated
text specified by the
Contents entry.
Note: When separating text into paragraphs, a carriage return should be used (and
not, for example, a line feed character).
Note: A subset of markup annotations are called text markup annotations (see
“Text Markup Annotations” on page 596
).
The remaining annotation types are not considered markup annotations:
• The pop-up annotation type typically does not appear by itself; it is associated
with a markup annotation that uses it to display text.
Note: The
Contents entry for a pop-up annotation is relevant only if it has no par-
ent; in that case, it represents the text of the annotation.
• For all other annotation types (Link, Movie, Widget, PrinterMark, and TrapNet),
the
Contents entry provides an alternate representation of the annotation’s con-
tents in human-readable form, which is useful when extracting the document’s
contents in support of accessibility to users with disabilities or for other pur-
poses (see Section 10.8.2, “Alternate Descriptions”).
Table 8.17 lists entries that apply to all markup annotations.
AnnotationsSECTION 8.4
583
TABLE 8.17 Additional entries specific to markup annotations
KEY TYPE VALUE
T
text string (Optional; PDF 1.1) The text label to be displayed in the title bar of the annota-
tion’s pop-up window when open and active. By convention, this entry identifies
the user who added the annotation.
Popup
dictionary (Optional; PDF 1.3) An indirect reference to a pop-up annotation for entering or
editing the text associated with this annotation.
CA
number (Optional; PDF 1.4) The constant opacity value to be used in painting the anno-
tation (see Sections 7.1, “Overview of Transparency,” and 7.2.6, “Shape and
Opacity Computations”). This value applies to all visible elements of the annota-
tion in its closed state (including its background and border) but not to the pop-
up window that appears when the annotation is opened.
The specified value is not used if the annotation has an appearance stream (see
Section 8.4.4, “Appearance Streams”); in that case, the appearance stream must
specify any transparency. (However, if the viewer regenerates the annotation’s
appearance stream, it may incorporate the
CA value into the stream’s content.)
The implicit blend mode (see Section 7.2.4, “Blend Mode”) is
Normal. Default
value: 1.0.
Note: If no explicit appearance stream is defined for the annotation, it is painted by
implementation-dependent means that do not necessarily conform to the Adobe
imaging model; in this case, the effect of this entry is implementation-dependent as
well.
RC
text string or
text stream
(Optional; PDF 1.5) A rich text string (see “Rich Text Strings” on page 642) to be
displayed in the pop-up window when the annotation is opened.
CreationDate
date (Optional; PDF 1.5) The date and time (Section 3.8.3, “Dates”) when the annota-
tion was created.
IRT
dictionary (Required if an RT entry is present, otherwise optional; PDF 1.5) A reference to the
annotation that this annotation is “in reply to.” Both annotations must be on the
same page of the document. The relationship between the two annotations is
specified by the
RT entry.
If this entry is present in an FDF file (see Section 8.6.6, “Forms Data Format”),
its type is not a dictionary but a text string containing the contents of the
NM en-
try of the annotation being replied to, to allow for a situation where the annota-
tion being replied to is not in the same FDF file.
Interactive FeaturesCHAPTER 8
584
In PDF 1.6, a set of annotations can be grouped so that they function as a single
unit when a user interacts with them. The group consists of a primary annotation,
which must not have an
IRT entry, and one or more subordinate annotations,
which must have an
IRT entry that refers to the primary annotation and an RT en-
try whose value is
Group.
Some entries in the primary annotation are treated as “group attributes” that
should apply to the group as a whole; the corresponding entries in the subordi-
nate annotations should be ignored. These entries are
Contents (or RC and DS),
M, C, T, Popup, CreationDate, Subj, and Open. Operations that manipulate any
annotation in a group, such as movement, cut, and copy, should be treated by
viewer applications as acting on the entire group.
Note: A primary annotation may have replies that are not subordinate annotations;
that is, that do not have an
RT value of Group.
Subj
text string (Optional; PDF 1.5) Text representing a short description of the subject being ad-
dressed by the annotation.
RT
name (Optional; meaningful only if IRT is present; PDF 1.6) A name specifying the rela-
tionship (the “reply type”) between this annotation and one one specified by
IRT.
Valid values are:
R The annotation is considered a reply to the annotation specified by
IRT. Viewer applications should not display replies to an annotation
individually but together in the form of threaded comments.
Group The annotation is grouped with the annotation specified by IRT; see
discussion below.
Default value:
R.
IT
name (Optional; PDF 1.6) A name describing the intent of the markup annotation. In-
tents allow viewer applications to distinguish between different uses and behav-
iors of a single markup annotation type. If this entry is not present or its value is
the same as the annotation type, the annotation has no explicit intent and should
behave in a generic manner in a viewer application.
In PDF 1.6, free text (Table 8.21), line (Table 8.21), and polygon (Table 8.21) an-
notations have defined intents, whose values are enumerated in the correspond-
ing tables.
KEY TYPE VALUE
AnnotationsSECTION 8.4
585
Annotation States
Beginning with PDF 1.5, annotations may have an author-specific state associat-
ed with them. The state is not specified in the annotation itself but in a separate
text annotation that refers to the original annotation by means of its
IRT (“in reply
to”) entry (see Table 8.20). States are grouped into a number of state models, as
shown in Table 8.18.
TABLE 8.18 Annotation states
Annotations can be thought of as initially being in the default state for each state
model. State changes made by a user are indicated in a text annotation with the
following entries:
• The T entry (see Table 8.17) specifies the user.
• The IRT entry (see Table 8.20)refers to the original annotation.
• State and StateModel (see Table 8.19) update the state of the original annota-
tion for the specified user.
Additional state changes are made by adding text annotations in reply to the pre-
vious reply for a given user.
STATE MODEL STATE DESCRIPTION
Marked Marked The annotation has been marked by the user.
Unmarked The annotation has not been marked by the user (the default).
Review Accepted The user agrees with the change.
Rejected The user disagrees with the change.
Cancelled The change has been cancelled.
Completed The change has been completed.
None The user has indicated nothing about the change (the default).
Interactive FeaturesCHAPTER 8
586
Text Annotations
A text annotation represents a “sticky note” attached to a point in the PDF docu-
ment. When closed, the annotation appears as an icon; when open, it displays a
pop-up window containing the text of the note in a font and size chosen by the
viewer application. Text annotations do not scale and rotate with the page; they
behave as if the NoZoom and NoRotate annotation flags (see Table 8.12 on page
573) were always set. Table 8.19 shows the annotation dictionary entries specific
to this type of annotation.
TABLE 8.19 Additional entries specific to a text annotation
Example 8.6 shows the definition of a text annotation.
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Tex t for
a text annotation.
Open
boolean (Optional) A flag specifying whether the annotation should initially be displayed
open. Default value:
false (closed).
Name
name (Optional) The name of an icon to be used in displaying the annotation. Viewer
applications should provide predefined icon appearances for at least the follow-
ing standard names:
Comment Key Note
Help NewParagraph Paragraph
Insert
Additional names may be supported as well. Default value: Note.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the
Name entry; see Table 8.11 on page 570 and Section 8.4.4, “Appearance Streams.”
State
text string (Optional; PDF 1.5) The state to which the original annotation should be set; see
“Annotation States,” above.
Default: “Unmarked” if
StateModel is “Marked”; “None” if StateModel is “Re-
view”.
StateModel
text string (Required if State is present, otherwise optional; PDF 1.5) The state model corre-
sponding to
State; see “Annotation States,” above.
AnnotationsSECTION 8.4
587
Example 8.6
22 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [266 116 430 204]
/Contents (The quick brown fox ate the lazy mouse.)
>>
endobj
Link Annotations
A link annotation represents either a hypertext link to a destination elsewhere in
the document (see Section 8.2.1, “Destinations”) or an action to be performed
(Section 8.5, “Actions”). Table 8.20 shows the annotation dictionary entries spe-
cific to this type of annotation.
TABLE 8.20 Additional entries specific to a link annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Link
for a link annotation.
Dest
array, name,
or string
(Optional; not permitted if an A entry is present) A destination to be displayed
when the annotation is activated (see Section 8.2.1, “Destinations”; see also im-
plementation note 90 in Appendix H).
H
name (Optional; PDF 1.2) The annotation’s highlighting mode, the visual effect to be
used when the mouse button is pressed or held down inside its active area:
N (None) No highlighting.
I (Invert) Invert the contents of the annotation rectangle.
O (Outline) Invert the annotation’s border.
P (Push) Display the annotation as if it were being pushed below the sur-
face of the page; see implementation note 91 in Appendix H.
Default value:
I.
Note: In PDF 1.1, highlighting is always done by inverting colors inside the anno-
tation rectangle.
Interactive FeaturesCHAPTER 8
588
Example 8.7 shows a link annotation that jumps to a destination elsewhere in the
document.
Example 8.7
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
Free Text Annotations
A free text annotation (PDF 1.3) displays text directly on the page. Unlike an ordi-
nary text annotation (see “Text Annotations” on page 586), a free text annotation
has no open or closed state; instead of being displayed in a pop-up window, the
text is always visible. Table 8.21 shows the annotation dictionary entries specific
PA
dictionary (Optional; PDF 1.3) A URI action (see “URI Actions” on page 624) formerly as-
sociated with this annotation. When Web Capture (Section 10.9, “Web Cap-
ture”) changes an annotation from a URI to a go-to action (“Go-To Actions” on
page 616), it uses this entry to save the data from the original URI action so
that it can be changed back in case the target page for the go-to action is subse-
quently deleted.
QuadPoints
array (Optional; PDF 1.6) An array of 8 × n numbers specifying the coordinates of n
quadrilaterals in default user space that comprise the region in which the link
should be activated. The coordinates for each quadrilateral are given in the or-
der
x
1
y
1
x
2
y
2
x
3
y
3
x
4
y
4
specifying the four vertices of the quadrilateral in counterclockwise order. For
orientation purposes, such as when applying an underline border style, the
bottom of a quadrilateral is the line formed by (x
1
, y
1
) and (x
2
, y
2
).
If this entry is not present or the viewer application does not recognize it, the
region specified by the
Rect entry should be used. QuadPoints should be ig-
nored if any coordinate in the array lies outside the region specified by
Rect.
KEY TYPE VALUE
AnnotationsSECTION 8.4
589
to this type of annotation. “Variable Text” on page 639 describes the process of
using these entries to generate the appearance of the text in these annotations.
TABLE 8.21 Additional entries specific to a free text annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
FreeText for a free text annotation.
DA
string (Required) The default appearance string to be used in formatting the text (see
“Variable Text” on page 639).
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the DA
entry; see Table 8.11 on page 570 and Section 8.4.4, “Appearance Streams.”
Q
integer (Optional; PDF 1.4) A code specifying the form of quadding (justification) to be
used in displaying the annotation’s text:
0 Left-justified
1Centered
2 Right-justified
Default value: 0 (left-justified).
RC
text string or
text stream
(Optional; PDF 1.5) A rich text string (see “Rich Text Strings” on page 642) to be
used to generate the appearance of the annotation.
DS
text string (Optional; PDF 1.5) A default style string, as described in “Rich Text Strings” on
page 642.
CL
array (Optional; PDF 1.6) An array of four or six numbers specifying a callout line at-
tached to the free text annotation. Six numbers
[x
1
y
1
x
2
y
2
x
3
y
3
] represent
the starting, knee point, and ending coordinates of the line in default user space,
as shown in Figure 8.4. Four numbers
[x
1
y
1
x
2
y
2
] represent the starting and
ending coordinates of the line.
IT
name (Optional; PDF 1.6) A name describing the intent of the free text annotation (see
also Table 8.17). Valid values in PDF 1.6 are
FreeTextCallout, which means that
the annotation is intended to function as a callout, and
FreeTextTypeWriter,
which means that the annotation is intended to function as a click-to-type or
typewriter object.
Interactive FeaturesCHAPTER 8
590
FIGURE 8.4 Free text annotation with callout
Line Annotations
A line annotation (PDF 1.3) displays a single straight line on the page. When
opened, it displays a pop-up window containing the text of the associated note.
Table 8.22 shows the annotation dictionary entries specific to this type of anno-
tation.
TABLE 8.22 Additional entries specific to a line annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Line
for a line annotation.
L
array (Required) An array of four numbers, [x
1
y
1
x
2
y
2
], specifying the starting and
ending coordinates of the line in default user space.
Note: If the
LL entry is present, this value represents the endpoints of the leader
lines rather than the endpoints of the line itself; see Figure 8.5.
BS
dictionary (Optional) A border style dictionary (see Table 8.13 on page 576) specifying the
width and dash pattern to be used in drawing the line.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the L
and BS entries; see Table 8.11 on page 570 and Section 8.4.4, “Appearance Streams.”
LE
array (Optional; PDF 1.4) An array of two names specifying the line ending styles to be
used in drawing the line. The first and second elements of the array specify the
line ending styles for the endpoints defined, respectively, by the first and second
pairs of coordinates, (
x
1
, y
1
) and (x
2
, y
2
), in the L array. Table 8.23 shows the
possible values. Default value:
[/None /None].
Free text with callouts
x
3,y3
x
2,y2
x
1,y1
AnnotationsSECTION 8.4
591
IC
array (Optional; PDF 1.4) An array of three numbers in the range 0.0 to 1.0 specifying
the components, in the
DeviceRGB color space, of the interior color with which to
fill the annotation’s line endings (see Table 8.23). If this entry is absent, the inte-
riors of the line endings are left transparent.
LL
number (Required if LLE is present, otherwise optional; PDF 1.6) The length of leader lines
in default user space that extend from each endpoint of the line perpendicular to
the line itself, as shown in Figure 8.5. A positive value means that the leader lines
appear in the direction that is clockwise when traversing the line from its start-
ing point to its ending point (as specified by
L); a negative value indicates the op-
posite direction.
Default value: 0 (no leader lines).
LLE
number (Optional; PDF 1.6) A non-negative number representing the length of leader
line extensions that extend from the line proper 180 degrees from the leader
lines, as shown in Figure 8.5.
Default value: 0 (no leader line extensions).
Cap
boolean (Optional; PDF 1.6) If true, the text specified by the Contents or RC entries
should be replicated as a caption in the appearance of the line, as shown in Fig-
ure 8.6. The text should be rendered in a manner appropriate to the content, tak-
ing into account factors such as writing direction.
Default value:
false.
IT
name (Optional; PDF 1.6) A name describing the intent of the line annotation (see also
Table 8.17). Valid values in PDF 1.6 are
LineArrow, which means that the annota-
tion is intended to function as an arrow, and
LineDimension, which means that
the annotation is intended to function as a dimension line.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
592
FIGURE 8.5 Leader lines
FIGURE 8.6 Lines with captions
/LL -50
(50 point inverse
leader line)
/LLE 10
(10 point leader line
extension)
/LLE 10
(10 point leader
line extension)
/LL 50
(50 point leader line)
This is a caption
This is a caption that is longer than the line
AnnotationsSECTION 8.4
593
TABLE 8.23 Line ending styles
Square and Circle Annotations
Square and circle annotations (PDF 1.3) display, respectively, a rectangle or an
ellipse on the page. When opened, they display a pop-up window containing the
text of the associated note. The rectangle or ellipse is inscribed within the annota-
tion rectangle defined by the annotation dictionary’s
Rect entry (see Table 8.11 on
page 570). Figure 8.7 shows two annotations, each with a border width of 18
points. Despite the names square and circle, the width and height of the annota-
tion rectangle need not be equal. Table 8.24 shows the annotation dictionary en-
tries specific to these types of annotations.
NAME APPEARANCE DESCRIPTION
Square
A square filled with the annotation’s interior color, if any
Circle
A circle filled with the annotation’s interior color, if any
Diamond
A diamond shape filled with the annotation’s interior color, if any
OpenArrow
Two short lines meeting in an acute angle to form an open arrowhead
ClosedArrow
Two short lines meeting in an acute angle as in the OpenArrow style (see
above) and connected by a third line to form a triangular closed arrowhead
filled with the annotation’s interior color, if any
None
No line ending
Butt
(PDF 1.5) A short line at the endpoint perpendicular to the line itself
ROpenArrow
(PDF 1.5) Two short lines in the reverse direction from OpenArrow
RClosedArrow
(PDF 1.5) A triangular closed arrowhead in the reverse direction from
ClosedArrow
Slash
(PDF 1.6) A short line at the endpoint approximately 30 degrees clockwise
from perpendicular to the line itself
Interactive FeaturesCHAPTER 8
594
FIGURE 8.7 Square and circle annotations
TABLE 8.24 Additional entries specific to a square or circle annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Square
or Circle for a square or circle annotation, respectively.
BS
dictionary (Optional) A border style dictionary (see Table 8.13 on page 576) specifying the
line width and dash pattern to be used in drawing the rectangle or ellipse.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the
Rect and BS entries; see Table 8.11 on page 570 and Section 8.4.4, “Appearance
Streams.”
IC
array (Optional; PDF 1.4) An array of three numbers in the range 0.0 to 1.0 specifying
the components, in the
DeviceRGB color space, of the interior color with which to
fill the annotation’s rectangle or ellipse (see Table 8.23). If this entry is absent, the
interior of the annotation is left transparent.
BE
dictionary (Optional; PDF 1.5) A border effect dictionary describing an effect applied to the
border described by the
BS entry (see Table 8.14).
18 pt 18 pt
Rect
Square annotation Circle annotation
AnnotationsSECTION 8.4
595
Polygon and Polyline Annotations
Polygon annotations (PDF 1.5) display closed polygons on the page. Such poly-
gons may have any number of vertices connected by straight lines. Polyline anno-
tations (PDF 1.5) are similar to polygons, except that the first and last vertex are
not implicitly connected.
TABLE 8.25 Additional entries specific to a polygon or polyline annotation
RD
rectangle (Optional; PDF 1.5) A set of four numbers describing the numerical differences
between two rectangles: the
Rect entry of the annotation and the actual bound-
aries of the underlying square or circle. Such a difference can occur in situations
where a border effect (described by
BE) causes the size of the Rect to increase be-
yond that of the square or circle.
The four numbers correspond to the differences in default user space between
the left, top, right, and bottom coordinates of
Rect and those of the square or cir-
cle, respectively. Each value must be greater than or equal to 0. The sum of the
top and bottom differences must be less than the height of
Rect, and the sum of
the left and right differences must be less than the width of
Rect.
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
Polygon or PolyLine for a polygon or polyline annotation, respectively.
Vertices
array (Required) An array of numbers representing the alternating horizontal and ver-
tical coordinates, respectively, of each vertex, in default user space.
LE
array (Optional; meaningful only for polyline annotations) An array of two names spec-
ifying the line ending styles. The first and second elements of the array specify
the line ending styles for the endpoints defined, respectively, by the first and last
pairs of coordinates in the
Vertices array. Table 8.23 shows the possible values.
Default value:
[/None /None].
BS
dictionary (Optional) A border style dictionary (see Table 8.13 on page 576) specifying the
width and dash pattern to be used in drawing the line.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the
Vertices and BS entries; see Table 8.11 on page 570 and Section 8.4.4, “Appearance
Streams.”
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
596
Text Markup Annotations
Text markup annotations appear as highlights, underlines, strikeouts (all PDF
1.3), or jagged (“squiggly”) underlines (PDF 1.4) in the text of a document. When
opened, they display a pop-up window containing the text of the associated note.
Table 8.26 shows the annotation dictionary entries specific to these types of an-
notations.
TABLE 8.26 Additional entries specific to text markup annotations
IC
array (Optional; PDF 1.4) An array of three numbers in the range 0.0 to 1.0 specifying
the components, in the
DeviceRGB color space, of the interior color with which to
fill the annotation’s line endings (see Table 8.23). If this entry is absent, the inte-
riors of the line endings are left transparent.
BE
dictionary (Optional; meaningful only for polygon annotations) A border effect dictionary de-
scribing an effect applied to the border described by the
BS entry (see Table
8.14).
IT
name (Optional; meaningful only for polygon annotations; PDF 1.6) A name describing
the intent of the polygon annotation (see also Table 8.17). The only valid value in
PDF 1.6 is
PolygonCloud, which means that the annotation is intended to func-
tion as a cloud object.
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
Highlight, Underline, Squiggly, or StrikeOut for a highlight, underline,
squiggly-underline, or strikeout annotation, respectively.
QuadPoints
array (Required) An array of 8 × n numbers specifying the coordinates of n quadri-
laterals in default user space. Each quadrilateral encompasses a word or
group of contiguous words in the text underlying the annotation. The coordi-
nates for each quadrilateral are given in the order
x
1
y
1
x
2
y
2
x
3
y
3
x
4
y
4
specifying the quadrilateral’s four vertices in counterclockwise order (see
Figure 8.8). The text is oriented with respect to the edge connecting points
(x
1
, y
1
) and (x
2
, y
2
). (See implementation note 92 in Appendix H.)
Note: The annotation dictionary’s
AP entry, if present, takes precedence over
QuadPoints; see Table 8.11 and Section 8.4.4, “Appearance Streams.”
KEY TYPE VALUE
AnnotationsSECTION 8.4
597
FIGURE 8.8 QuadPoints specification
Caret Annotations
A caret annotation (PDF 1.5) is a visual symbol that indicates the presence of text
edits. Table 8.27 lists the entries specific to caret annotations.
TABLE 8.27 Additional entries specific to a caret annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Caret
for a caret annotation.
RD
rectangle (Optional; PDF 1.5) A set of four numbers describing the numerical differences
between two rectangles: the
Rect entry of the annotation and the actual bound-
aries of the underlying caret. Such a difference can occur, for example, when a
paragraph symbol specified by
Sy is displayed along with the caret.
The four numbers correspond to the differences in default user space between
the left, top, right, and bottom coordinates of
Rect and those of the caret, respec-
tively. Each value must be greater than or equal to 0. The sum of the top and bot-
tom differences must be less than the height of
Rect, and the sum of the left and
right differences must be less than the width of
Rect.
Sy
name (Optional) A name specifying a symbol to be associated with the caret:
P A new paragraph symbol (¶) should be associated with the caret.
None No symbol should be associated with the caret.
Default value:
None.
Jupiter
(x
3
, y
3
)
(x
2
, y
2
)
(x
1
, y
1
)
(x
4
, y
4
)
Interactive FeaturesCHAPTER 8
598
Rubber Stamp Annotations
A rubber stamp annotation (PDF 1.3) displays text or graphics intended to look as
if they were stamped on the page with a rubber stamp. When opened, it displays a
pop-up window containing the text of the associated note. Table 8.28 shows the
annotation dictionary entries specific to this type of annotation.
TABLE 8.28 Additional entries specific to a rubber stamp annotation
Ink Annotations
An ink annotation (PDF 1.3) represents a freehand “scribble” composed of one or
more disjoint paths. When opened, it displays a pop-up window containing the
text of the associated note. Table 8.29 shows the annotation dictionary entries
specific to this type of annotation.
TABLE 8.29 Additional entries specific to an ink annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Stamp
for a rubber stamp annotation.
Name
name (Optional) The name of an icon to be used in displaying the annotation. Viewer
applications should provide predefined icon appearances for at least the follow-
ing standard names:
Approved Experimental NotApproved
AsIs Expired NotForPublicRelease
Confidential Final Sold
Departmental ForComment TopSecret
Draft ForPublicRelease
Additional names may be supported as well. Default value: Draft.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the
Name entry; see Table 8.11 on page 570 and Section 8.4.4, “Appearance Streams.”
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Ink for
an ink annotation.
AnnotationsSECTION 8.4
599
Pop-up Annotations
A pop-up annotation (PDF 1.3) displays text in a pop-up window for entry and
editing. It typically does not appear alone but is associated with a markup annota-
tion, its parent annotation, and is used for editing the parent’s text. It has no
appearance stream or associated actions of its own and is identified by the
Popup
entry in the parent’s annotation dictionary (see Table 8.17 on page 583). Table
8.30 shows the annotation dictionary entries specific to this type of annotation.
TABLE 8.30 Additional entries specific to a pop-up annotation
InkList
array (Required) An array of n arrays, each representing a stroked path. Each array is a
series of alternating horizontal and vertical coordinates in default user space,
specifying points along the path. When drawn, the points are connected by
straight lines or curves in an implementation-dependent way. (See implementa-
tion note 93 in Appendix H.)
BS
dictionary (Optional) A border style dictionary (see Table 8.13 on page 576) specifying the
line width and dash pattern to be used in drawing the paths.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the In-
kList
and BS entries; see Table 8.11 on page 570 and Section 8.4.4, “Appearance
Streams.”
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
Popup for a pop-up annotation.
Parent
dictionary (Optional; must be an indirect reference) The parent annotation with which
this pop-up annotation is associated.
Note: If this entry is present, the parent annotation’s
Contents, M, C, and T
entries (see Table 8.11 on page 570) override those of the pop-up annotation
itself.
Open
boolean (Optional) A flag specifying whether the pop-up annotation should initially
be displayed open. Default value:
false (closed).
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
600
File Attachment Annotations
A file attachment annotation (PDF 1.3) contains a reference to a file, which typi-
cally is embedded in the PDF file (see Section 3.10.3, “Embedded File Streams”);
see implementation note 95 in Appendix H. For example, a table of data might
use a file attachment annotation to link to a spreadsheet file based on that data;
activating the annotation extracts the embedded file and gives the user an oppor-
tunity to view it or store it in the file system. Table 8.31 shows the annotation dic-
tionary entries specific to this type of annotation.
The
Contents entry of the annotation dictionary may specify descriptive text re-
lating to the attached file. Viewer applications should use this entry rather than
the optional
Desc entry (PDF 1.6) in the file specification dictionary (see Table
3.40) identified by the annotation’s
FS entry; see implementation note 95 in Ap-
pendix H.
TABLE 8.31 Additional entries specific to a file attachment annotation
Sound Annotations
A sound annotation (PDF 1.2) is analogous to a text annotation except that in-
stead of a text note, it contains sound recorded from the computer’s microphone
or imported from a file. When the annotation is activated, the sound is played.
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
FileAttachment for a file attachment annotation.
FS
file specification (Required) The file associated with this annotation.
Name
name (Optional) The name of an icon to be used in displaying the annotation.
Viewer applications should provide predefined icon appearances for at least
the following standard names:
Graph PushPin
Paperclip Tag
Additional names may be supported as well. Default value: PushPin.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the
Name entry; see Table 8.11 on page 570 and Section 8.4.4, “Appearance
Streams.”
AnnotationsSECTION 8.4
601
The annotation behaves like a text annotation in most ways, with a different icon
(by default, a speaker) to indicate that it represents a sound. Table 8.32 shows the
annotation dictionary entries specific to this type of annotation. Sound objects
are discussed in Section 9.2, “Sounds.”
TABLE 8.32 Additional entries specific to a sound annotation
Movie Annotations
A movie annotation (PDF 1.2) contains animated graphics and sound to be pre-
sented on the computer screen and through the speakers. When the annotation is
activated, the movie is played. Table 8.33 shows the annotation dictionary entries
specific to this type of annotation. Movies are discussed in Section 9.3, “Movies.”
TABLE 8.33 Additional entries specific to a movie annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Sound
for a sound annotation.
Sound
stream (Required) A sound object defining the sound to be played when the annotation
is activated (see Section 9.2, “Sounds”).
Name
name (Optional) The name of an icon to be used in displaying the annotation. Viewer
applications should provide predefined icon appearances for at least the stan-
dard names
Speaker and Mic. Additional names may be supported as well. De-
fault value:
Speaker.
Note: The annotation dictionary’s
AP entry, if present, takes precedence over the
Name entry; see Table 8.11 on page 570 and Section 8.4.4, “Appearance Streams.”
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Movie
for a movie annotation.
Movie
dictionary (Required) A movie dictionary describing the movie’s static characteristics (see
Section 9.3, “Movies”).
Interactive FeaturesCHAPTER 8
602
Screen Annotations
A screen annotation (PDF 1.5) specifies a region of a page upon which media clips
may be played. It also serves as an object from which actions can be triggered.
“Rendition Actions” on page 630 discusses the relationship between screen anno-
tations and rendition actions. Table 8.34 shows the annotation dictionary entries
specific to this type of annotation.
TABLE 8.34 Additional entries specific to a screen annotation
In addition to the above entries, screen annotations use the common entries in
the annotation dictionary (see Table 8.11) in the following ways:
• The P entry is required for a screen annotation referenced by a rendition ac-
tion. It must reference a valid page object, and the annotation must be present
in the page’s
Annots array for the action to be valid.
• The AP entry refers to an appearance dictionary (see Table 8.15) whose normal
appearance provides the visual appearance for a screen annotation that is used
for printing and default display when a media clip is not being played. If
AP is
not present, the screen annotation has no default visual appearance and is not
printed.
• The AA entry refers to an additional-actions dictionary (see Table 8.40) that
contains four entries introduced in PDF 1.5 to support multimedia.
A
boolean or
dictionary
(Optional) A flag or dictionary specifying whether and how to play the movie
when the annotation is activated. If this value is a dictionary, it is a movie activa-
tion dictionary (see Section 9.3, “Movies”) specifying how to play the movie. If
the value is the boolean
true, the movie should be played using default activation
parameters. If the value is
false, the movie should not be played. Default value:
true.
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Screen
for a screen annotation.
MK
dictionary (Optional) An appearance characteristics dictionary (see Table 8.36). The I entry
of this dictionary provides the icon used in generating the appearance referred
to by the screen annotation’s
AP entry.
KEY TYPE VALUE
AnnotationsSECTION 8.4
603
Widget Annotations
Interactive forms (see Section 8.6, “Interactive Forms”) use widget annotations
(PDF 1.2) to represent the appearance of fields and to manage user interactions.
As a convenience, when a field has only a single associated widget annotation, the
contents of the field dictionary (Section 8.6.2, “Field Dictionaries”) and the anno-
tation dictionary can be merged into a single dictionary containing entries that
pertain to both a field and an annotation. (This presents no ambiguity, since the
contents of the two kinds of dictionaries do not conflict.) Table 8.35 shows the
annotation dictionary entries specific to this type of annotation; interactive forms
and fields are discussed at length in Section 8.6.
TABLE 8.35 Additional entries specific to a widget annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be Widget
for a widget annotation.
H
name (Optional) The annotation’s highlighting mode, the visual effect to be used when
the mouse button is pressed or held down inside its active area:
N (None) No highlighting.
I (Invert) Invert the contents of the annotation rectangle.
O (Outline) Invert the annotation’s border.
P (Push) Display the annotation’s down appearance, if any (see Section
8.4.4, “Appearance Streams”). If no down appearance is defined, offset
the contents of the annotation rectangle to appear as if it were being
pushed below the surface of the page.
T (Toggle) Same as P (which is preferred).
A highlighting mode other than
P overrides any down appearance defined for
the annotation. Default value:
I.
MK
dictionary (Optional) An appearance characteristics dictionary (see Table 8.36) to be used
in constructing a dynamic appearance stream specifying the annotation’s visual
presentation on the page.
The name
MK for this entry is of historical significance only and has no direct
meaning.
Interactive FeaturesCHAPTER 8
604
The MK entry can be used to provide an appearance characteristics dictionary
containing additional information for constructing the annotation’s appearance
stream. Table 8.36 shows the contents of this dictionary.
TABLE 8.36 Entries in an appearance characteristics dictionary
KEY TYPE VALUE
R
integer (Optional) The number of degrees by which the widget annotation is rotated
counterclockwise relative to the page. The value must be a multiple of 90.
Default value: 0.
BC
array (Optional) An array of numbers in the range 0.0 to 1.0 specifying the color of the
widget annotation’s border. The number of array elements determines the color
space in which the color is defined:
0 No color; transparent
1
DeviceGray
3
DeviceRGB
4
DeviceCMYK
BG
array (Optional) An array of numbers in the range 0.0 to 1.0 specifying the color of the
widget annotation’s background. The number of array elements determines the
color space, as described above for
BC.
CA
text string (Optional; button fields only) The widget annotation’s normal caption, displayed
when it is not interacting with the user.
Note: Unlike the remaining entries listed below, which apply only to widget annota-
tions associated with pushbutton fields (see “Pushbuttons” on page 648), the
CA
entry can be used with any type of button field, including check boxes (“Check Box-
es” on page 648) and radio buttons (“Radio Buttons” on page 650).
RC
text string (Optional; pushbutton fields only) The widget annotation’s rollover caption, dis-
played when the user rolls the cursor into its active area without pressing the
mouse button.
AC
text string (Optional; pushbutton fields only) The widget annotation’s alternate (down)
caption, displayed when the mouse button is pressed within its active area.
I
stream (Optional; pushbutton fields only; must be an indirect reference) A form XObject
defining the widget annotation’s normal icon, displayed when it is not interacting
with the user.
AnnotationsSECTION 8.4
605
Printer’s Mark Annotations
A printer’s mark annotation (PDF 1.4) represents a graphic symbol, such as a
registration target, color bar, or cut mark, added to a page to assist production
personnel in identifying components of a multiple-plate job and maintaining
consistent output during production. See Section 10.10.2, “Printer’s Marks,” for
further discussion.
Trap Network Annotations
A trap network annotation (PDF 1.3) defines the trapping characteristics for a
page of a PDF document. (Trapping is the process of adding marks to a page
along color boundaries to avoid unwanted visual artifacts resulting from mis-
registration of colorants when the page is printed.) A page may have at most one
trap network annotation, whose
Subtype entry has the value TrapNet and which
RI
stream (Optional; pushbutton fields only; must be an indirect reference) A form XObject
defining the widget annotation’s rollover icon, displayed when the user rolls the
cursor into its active area without pressing the mouse button.
IX
stream (Optional; pushbutton fields only; must be an indirect reference) A form XObject
defining the widget annotation’s alternate (down) icon, displayed when the
mouse button is pressed within its active area.
IF
dictionary (Optional; pushbutton fields only) An icon fit dictionary (see Table 8.93 on page
679) specifying how to display the widget annotation’s icon within its annotation
rectangle. If present, the icon fit dictionary applies to all of the annotation’s icons
(normal, rollover, and alternate).
TP
integer (Optional; pushbutton fields only) A code indicating where to position the text of
the widget annotation’s caption relative to its icon:
0 No icon; caption only
1 No caption; icon only
2 Caption below the icon
3 Caption above the icon
4 Caption to the right of the icon
5 Caption to the left of the icon
6 Caption overlaid directly on the icon
Default value: 0.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
606
is always the last element in the page object’s Annots array (see “Page Objects” on
page 119). See Section 10.10.5, “Trapping Support,” for further discussion.
Watermark Annotations
A watermark annotation (PDF 1.6) is used to represent graphics that are expected
to be printed at a fixed size and position on a page, regardless of the dimensions
of the printed page. The
FixedPrint entry of a watermark annotation dictionary
(see Table 8.37) is a dictionary that contains values for specifying the size and po-
sition of the annotation (see Table 8.38).
Watermark annotations have no pop-up window or other interactive elements.
When displaying a watermark annotation on-screen, viewer applications should
use the dimensions of the media box as the page size so that the scroll and zoom
behavior is the same as for other annotations.
Note: Since many printing devices have nonprintable margins, it is recommended
that such margins be taken into consideration when positioning watermark annota-
tions near the edge of a page.
TABLE 8.37 Additional entries specific to a watermark annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
Watermark for a watermark annotation.
FixedPrint
dictionary (Optional) A fixed print dictionary (see Table 8.38) that specifies how this anno-
tation should be drawn relative to the dimensions of the target media. If this en-
try is not present, the annotation is drawn without any special consideration for
the dimensions of the target media.
Note: If the dimensions of the target media are not known at the time of drawing,
drawing is done relative to the dimensions specified by the page’s
MediaBox entry
(see Table 3.27).
AnnotationsSECTION 8.4
607
TABLE 8.38 Entries in a fixed print dictionary
When rendering a watermark annotation with a FixedPrint entry, the following
behavior occurs:
• The annotation’s rectangle (as specified by its Rect entry) is translated to the or-
igin and transformed by the
Matrix entry of its FixedPrint dictionary to produce
a quadrilateral with arbitrary orientation.
• The transformed annotation rectangle is defined as the smallest upright rectan-
gle that encompasses this quadrilateral; it is used in place of the annotation
rectangle referred to in steps 2 and 3 of Algorithm 8.1 on page 577.
In addition, given a matrix
B that maps a scaled and rotated page into the default
user space, a new matrix is computed that cancels out
B and translates the origin
of the printed page to the origin of the default user space. This transformation is
applied to ensure the correct scaling and alignment.
Example 8.8 shows a watermark annotation that prints a text string one inch from
the left and one inch from the top of the printed page.
KEY TYPE VALUE
Type
name (Required) Must be FixedPrint.
Matrix
array (Optional) The matrix used to transform the annotation’s rectangle before ren-
dering.
Default value: the identity matrix
[100100].
Note: When positioning content near the edge of a page, it is recommended that
this entry be used to provide a reasonable offset to allow for nonprintable margins.
H
number (Optional) The amount to translate the associated content horizontally, as a per-
centage of the width of the target media (or if unknown, the width of the page’s
MediaBox). 1.0 represents 100% and 0.0 represents 0%. Negative values are not
recommended, since they may cause content to be drawn off the page.
Default value: 0.
V
number (Optional) The amount to translate the associated content vertically, as a per-
centage of the height of the target media (or if unknown, the height of the page’s
MediaBox). 1.0 represents 100% and 0.0 represents 0%. Negative values are not
recommended, since they may cause content to be drawn off the page.
Default value: 0.
Interactive FeaturesCHAPTER 8
608
Example 8.8
8 0 obj % Watermark appearance
<<
/Length ...
/Subtype /Form
/Resources ...
/BBox ...
>>
stream
...
BT
/F1 1 Tf
36 0 0 36 0 -36 Tm
(Do Not Build) Tx
ET
...
endstream
endobj
9 0 obj % Watermark annotation
<<
/Rect ...
/Type /Annot
/Subtype /Watermark
/FixedPrint 10 0 R
/AP <</N 8 0 R>>
>>
% in the page dictionary
/Annots [9 0 R]
10 0 obj % Fixed print dictionary
<<
/Type /FixedPrint
/Matrix [1 0 0 1 72 -72] % Translate one inch right and one inch down
/H 0
/V 1.0 % Translate the full height of the page vertically
>>
endobj
ActionsSECTION 8.5
609
In situations other than the usual case where the PDF page size equals the printed
page size, watermark annotations with a
FixedPrint entry should be printed in the
following manner:
• When page tiling is selected in a viewer application (that is, a single PDF page
is printed on multiple pages), the annotations are printed at the specified size
and position on each page to ensure that any enclosed content is present and
legible on each printed page.
• When n-up printing is selected (that is, multiple PDF pages are printed on a
single page), the annotations are printed at the specified size and are positioned
as if the dimensions of the printed page were limited to a single portion of the
page. This ensures that any enclosed content does not overlap content from
other pages, thus rendering it illegible. (See implementation note 96 in Appen-
dix H.)
8.5 Actions
Instead of simply jumping to a destination in the document, an annotation or
outline item can specify an action (PDF 1.1) for the viewer application to per-
form, such as launching an application, playing a sound, or changing an annota-
tion’s appearance state. The optional
A entry in the annotation or outline item
dictionary (see Tables 8.11 on page 570 and 8.4 on page 555) specifies an action
to be performed when the annotation or outline item is activated; in PDF 1.2, a
variety of other circumstances may trigger an action as well (see Section 8.5.2,
“Trigger Events”). In addition, the optional
OpenAction entry in a document’s
catalog (Section 3.6.1, “Document Catalog”) may specify an action to be per-
formed when the document is opened. PDF includes a wide variety of standard
action types, described in detail in Section 8.5.3, “Action Types.”
8.5.1 Action Dictionaries
An action dictionary defines the characteristics and behavior of an action. Table
8.39 shows the required and optional entries that are common to all action
dictionaries. The dictionary may contain additional entries specific to a particu-
lar action type; see the descriptions of individual action types in Section 8.5.3,
“Action Types,” for details.
Interactive FeaturesCHAPTER 8
610
TABLE 8.39 Entries common to all action dictionaries
The action dictionary’s Next entry (PDF 1.2) allows sequences of actions to be
chained together. For example, the effect of clicking a link annotation with the
mouse might be to play a sound, jump to a new page, and start up a movie. Note
that the
Next entry is not restricted to a single action but may contain an array of
actions, each of which in turn may have a
Next entry of its own. The actions may
thus form a tree instead of a simple linked list. Actions within each
Next array are
executed in order, each followed in turn by any actions specified in its
Next entry,
and so on recursively. Viewer applications should attempt to provide reasonable
behavior in anomalous situations. For example, self-referential actions should not
be executed more than once, and actions that close the document or otherwise
render the next action impossible should terminate the execution sequence.
Applications should also provide some mechanism for the user to interrupt and
manually terminate a sequence of actions.
PDF 1.5 introduces transition actions, which allow the control of drawing during
a sequence of actions; see “Transition Actions” on page 632.
Note: No action should modify its own action dictionary or any other in the action
tree in which it resides. The effect of such modification on subsequent execution of
actions in the tree is undefined.
8.5.2 Trigger Events
An annotation, page object, or (beginning with PDF 1.3) interactive form field
may include an entry named
AA that specifies an additional-actions dictionary
(PDF 1.2) that extends the set of events that can trigger the execution of an action.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if
present, must be
Action for an action dictionary.
S
name (Required) The type of action that this dictionary describes; see Table 8.44
on page 615 for specific values.
Next
dictionary or array (Optional; PDF 1.2) The next action or sequence of actions to be per-
formed after the action represented by this dictionary. The value is either a
single action dictionary or an array of action dictionaries to be performed
in order; see below for further discussion.
ActionsSECTION 8.5
611
In PDF 1.4, the document catalog dictionary (see Section 3.6.1, “Document Cata-
log”) may also contain an
AA entry for trigger events affecting the document as a
whole. Tables 8.40 to 8.43 show the contents of this type of dictionary. (See
implementation notes 97 and 98 in Appendix H.)
PDF 1.5 introduces four trigger events to support multimedia presentations:
• The PO and PC entries have a similar function to the O and C entries in the page
object’s additional-actions dictionary (see Table 8.41). However, associating
these triggers with annotations allows annotation objects to be self-contained
and greatly simplifies authoring. For example, annotations containing such ac-
tions can be copied or moved between pages without requiring page open/close
actions to be changed.
• The PV and PI entries allow a distinction between pages that are open and pages
that are visible. At any one time, only a single page is considered open in the
viewer application, while more than one page may be visible, depending on the
page layout.
Note: For these trigger events, the values of the flags specified by the annotation’s
F
entry (see Section 8.4.2, “Annotation Flags”) have no bearing on whether a given
trigger event occurs.
TABLE 8.40 Entries in an annotation’s additional-actions dictionary
KEY TYPE VALUE
E
dictionary (Optional; PDF 1.2) An action to be performed when the cursor enters the annotation’s
active area.
X
dictionary (Optional; PDF 1.2) An action to be performed when the cursor exits the annotation’s
active area.
D
dictionary (Optional; PDF 1.2) An action to be performed when the mouse button is pressed
inside the annotation’s active area. (The name
D stands for “down.”)
U
dictionary (Optional; PDF 1.2) An action to be performed when the mouse button is released
inside the annotation’s active area. (The name
U stands for “up.”)
Note: For backward compatibility, the
A entry in an annotation dictionary, if present,
takes precedence over this entry (see Table 8.11 on page 570).
Fo
dictionary (Optional; PDF 1.2; widget annotations only) An action to be performed when the
annotation receives the input focus.
Interactive FeaturesCHAPTER 8
612
TABLE 8.41 Entries in a page object’s additional-actions dictionary
TABLE 8.42 Entries in a form field’s additional-actions dictionary
Bl
dictionary (Optional; PDF 1.2; widget annotations only) (Uppercase B, lowercase L) An action to
be performed when the annotation loses the input focus. (The name
Bl stands for
“blurred.”)
PO
dictionary (Optional; PDF 1.5) An action to be performed when the page containing the annota-
tion is opened (for example, when the user navigates to it from the next or previous
page or by means of a link annotation or outline item). The action is executed after the
O action in the page’s additional-actions dictionary (see Table 8.41) and the
OpenAction entry in the document catalog (see Table 3.25), if such actions are present.
PC
dictionary (Optional; PDF 1.5) An action to be performed when the page containing the annota-
tion is closed (for example, when the user navigates to the next or previous page, or fol-
lows a link annotation or outline item). The action is executed before the
C action in
the page’s additional-actions dictionary (see Table 8.41), if present.
PV
dictionary (Optional; PDF 1.5) An action to be performed when the page containing the annota-
tion becomes visible in the viewer application’s user interface.
PI
dictionary (Optional; PDF 1.5) An action to be performed when the page containing the annota-
tion is no longer visible in the viewer application’s user interface.
KEY TYPE VALUE
O
dictionary (Optional; PDF 1.2) An action to be performed when the page is opened (for example,
when the user navigates to it from the next or previous page or by means of a link an-
notation or outline item). This action is independent of any that may be defined by the
OpenAction entry in the document catalog (see Section 3.6.1, “Document Catalog”)
and is executed after such an action. (See implementation note 99 in Appendix H.)
C
dictionary (Optional; PDF 1.2) An action to be performed when the page is closed (for example,
when the user navigates to the next or previous page or follows a link annotation or an
outline item). This action applies to the page being closed and is executed before any
other page is opened. (See implementation note 99 in Appendix H.)
KEY TYPE VALUE
K
dictionary (Optional; PDF 1.3) A JavaScript action to be performed when the user types a key-
stroke into a text field or combo box or modifies the selection in a scrollable list box.
This action can check the keystroke for validity and reject or modify it.
KEY TYPE VALUE
ActionsSECTION 8.5
613
TABLE 8.43 Entries in the document catalog’s additional-actions dictionary
For purposes of the trigger events E (enter), X (exit), D (down), and U (up), the
term mouse denotes a generic pointing device with the following characteristics:
• A selection button that can be pressed, held down, and released. If there is more
than one mouse button, the selection button is typically the left button.
• A notion of location—that is, an indication of where on the screen the device is
pointing. Location is typically denoted by a screen cursor.
• A notion of focus—that is, which element in the document is currently interact-
ing with the user. In many systems, this element is denoted by a blinking caret,
a focus rectangle, or a color change.
F
dictionary (Optional; PDF 1.3) A JavaScript action to be performed before the field is formatted to
display its current value. This action can modify the field’s value before formatting.
V
dictionary (Optional; PDF 1.3) A JavaScript action to be performed when the field’s value is
changed. This action can check the new value for validity. (The name
V stands for “val-
idate.”)
C
dictionary (Optional; PDF 1.3) A JavaScript action to be performed to recalculate the value of this
field when that of another field changes. (The name
C stands for “calculate.”) The order
in which the document’s fields are recalculated is defined by the
CO entry in the inter-
active form dictionary (see Section 8.6.1, “Interactive Form Dictionary”).
KEY TYPE VALUE
DC
dictionary (Optional; PDF 1.4) A JavaScript action to be performed before closing a document.
(The name
DC stands for “document close.”)
WS
dictionary (Optional; PDF 1.4) A JavaScript action to be performed before saving a document.
(The name
WS stands for “will save.”)
DS
dictionary (Optional; PDF 1.4) A JavaScript action to be performed after saving a document. (The
name
DS stands for “did save.”)
WP
dictionary (Optional; PDF 1.4) A JavaScript action to be performed before printing a document.
(The name
WP stands for “will print.”)
DP
dictionary (Optional; PDF 1.4) A JavaScript action to be performed after printing a document.
(The name
DP stands for “did print.”)
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
614
PDF viewer applications must ensure the presence of such a device for the corre-
sponding actions to be executed correctly. Mouse-related trigger events are sub-
ject to the following constraints:
• An E (enter) event can occur only when the mouse button is up.
• An X (exit) event cannot occur without a preceding E event.
• A U (up) event cannot occur without a preceding E and D event.
• In the case of overlapping or nested annotations, entering a second annotation’s
active area causes an
X event to occur for the first annotation.
Note: The field-related trigger events
K (keystroke), F (format), V (validate), and C
(calculate) are not defined for button fields (see “Button Fields” on page 647). The
effects of an action triggered by one of these events are limited only by the action it-
self and can occur outside the described scope of the event. For example, even
though the
F event is used to trigger actions that format field values prior to display,
it is possible for an action triggered by this event to perform a calculation or make
any other modification to the document.
These field-related trigger events can occur either through user interaction or pro-
grammatically, such as in response to the
NeedAppearances entry in the interactive
form dictionary (see Section 8.6.1, “Interactive Form Dictionary”), importation of
FDF data (Section 8.6.6, “Forms Data Format”), or JavaScript actions (“JavaScript
Actions” on page 668). For example, the user’s modifying a field value can trigger a
cascade of calculations and further formatting and validation for other fields in the
document.
8.5.3 Action Types
PDF supports the standard action types listed in Table 8.44. The following sec-
tions describe each of these types in detail. Plug-in extensions may add new
action types.
ActionsSECTION 8.5
615
TABLE 8.44 Action types
Note: Previous versions of the PDF specification described an action type known as
the set-state action; this type of action is now considered obsolete and its use is no
ACTION TYPE DESCRIPTION DISCUSSED IN SECTION
GoTo Go to a destination in the current document. “Go-To Actions” on page 616
GoToR (“Go-to remote”) Go to a destination in another
document.
“Remote Go-To Actions” on page 617
GoToE
(“Go-to embedded”; PDF 1.6) Go to a destination in an
embedded file.
“Embedded Go-To Actions” on page
617
Launch Launch an application, usually to open a file. “Launch Actions” on page 621
Thread Begin reading an article thread. “Thread Actions” on page 623
URI Resolve a uniform resource identifier. “URI Actions” on page 624
Sound (PDF 1.2) Play a sound. “Sound Actions” on page 625
Movie (PDF 1.2) Play a movie. “Movie Actions” on page 626
Hide (PDF 1.2) Set an annotation’s Hidden flag. “Hide Actions” on page 627
Named (PDF 1.2) Execute an action predefined by the viewer
application.
“Named Actions” on page 628
SubmitForm (PDF 1.2) Send data to a uniform resource locator. “Submit-Form Actions” on page 662
ResetForm (PDF 1.2) Set fields to their default values. “Reset-Form Actions” on page 666
ImportData (PDF 1.2) Import field values from a file. “Import-Data Actions” on page 667
JavaScript (PDF 1.3) Execute a JavaScript script. “JavaScript Actions” on page 668
SetOCGState
(PDF 1.5) Set the states of optional content groups. “Set-OCG-State Actions” on page 629
Rendition
(PDF 1.5) Controls the playing of multimedia content. “Rendition Actions” on page 630
Trans
(PDF 1.5) Updates the display of a document, using a
transition dictionary.
“Transition Actions” on page 632
GoTo3DView
(PDF 1.6) Set the current view of a 3D annotation “Go-To-3D-View Actions” on page
632
Interactive FeaturesCHAPTER 8
616
longer recommended. An additional action type, the no-op action, was defined in
PDF 1.2 but never implemented; it is no longer defined and should be ignored.
Go-To Actions
A go-to action changes the view to a specified destination (page, location, and
magnification factor). Table 8.45 shows the action dictionary entries specific to
this type of action.
TABLE 8.45 Additional entries specific to a go-to action
Specifying a go-to action in the A entry of a link annotation or outline item (see
Tables 8.20 on page 587 and 8.4 on page 555) has the same effect as specifying the
destination directly with the
Dest entry. For example, the link annotation shown
in Example 8.9, which uses a go-to action, has the same effect as the one in Exam-
ple 8.7 on page 588, which specifies the destination directly. However, the go-to
action is less compact and is not compatible with PDF 1.0; therefore, using a di-
rect destination is preferable.
Example 8.9
93 0 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
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be GoTo for a
go-to action.
D
name, string,
or array
(Required) The destination to jump to (see Section 8.2.1, “Destinations”).
ActionsSECTION 8.5
617
Remote Go-To Actions
A remote go-to action is similar to an ordinary go-to action but jumps to a desti-
nation in another PDF file instead of the current file. Table 8.46 shows the action
dictionary entries specific to this type of action.
Note: Remote go-to actions cannot be used with embedded files; see “Embedded Go-
To Actions” on page 617”.
TABLE 8.46 Additional entries specific to a remote go-to action
Embedded Go-To Actions
An embedded go-to action (PDF 1.6) is similar to a remote go-to action but allows
jumping to or from a PDF file that is embedded in another PDF file (see “Embed-
ded File Streams” on page 157). Embedded files may be associated with file at-
tachment annotations (see “File Attachment Annotations” on page 600) or with
entries in the
EmbeddedFiles name tree (see Section 3.6.3, “Name Dictionary”).
Embedded files may in turn contain embedded files. Table 8.47 shows the action
dictionary entries specific to embedded go-to actions.
Embedded go-to actions provide a complete facility for linking between a file in a
hierarchy of nested embedded files and another file in the same or different hier-
archy. The following terminology is used:
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be GoToR
for a remote go-to action.
F
file specification (Required) The file in which the destination is located.
D
name, string,
or array
(Required) The destination to jump to (see Section 8.2.1, “Destinations”). If
the value is an array defining an explicit destination (as described under
“Explicit Destinations” on page 551), its first element must be a page number
within the remote document rather than an indirect reference to a page ob-
ject in the current document. The first page is numbered 0.
NewWindow
boolean (Optional; PDF 1.2) A flag specifying whether to open the destination docu-
ment in a new window. If this flag is
false, the destination document replaces
the current document in the same window. If this entry is absent, the viewer
application should behave in accordance with the current user preference.
Interactive FeaturesCHAPTER 8
618
• The source is the document containing the embedded go-to action.
• The target is the document in which the destination lives.
The
T entry in the action dictionary is a target dictionary that locates the target
in relation to the source, in much the same way that a relative path describes
the physical relationship between two files in a file system. Target dictionaries
may be nested recursively to specify one or more intermediate targets before
reaching the final one. As the hierarchy is navigated, each intermediate target is
referred to as the current document. Initially, the source is the current docu-
ment.
Note: It is an error for a target dictionary to have an infinite cycle (for example,
one where a target dictionary refers to itself). Viewer applications should attempt
to detect such cases and refuse to execute the action if found.
• A child document is one that is embedded within another PDF file.
• The document in which a file is embedded is its parent.
• A root document is one that is not embedded in another PDF file. The target
and source may be contained in root documents or embedded documents.
TABLE 8.47 Additional entries specific to an embedded go-to action
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be GoToE
for an embedded go-to action.
F
file specification (Optional) The root document of the target relative to the root document of
the source. If this entry is absent, the source and target share the same root
document.
D
name, string,
or array
(Required) The destination in the target to jump to (see Section 8.2.1, “Desti-
nations”).
NewWindow
boolean (Optional) If true, the destination document should be opened in a new win-
dow; if
false, the destination document should replace the current document
in the same window. If this entry is absent, the viewer application should hon-
or the current user preference.
T
dictionary (Optional if F is present; otherwise required) A target dictionary (see Table 8.48)
specifying path information to the target document. Each target dictionary
specifies one element in the full path to the target and may have nested target
dictionaries specifying additional elements.
ActionsSECTION 8.5
619
TABLE 8.48 Entries specific to a target dictionary
Example 8.10 illustrates several possible relationships between source and target.
Each object shown is an action dictionary for an embedded go-to action.
Example 8.10
1 0 obj % Link to a child
<< /Type /Action
/S /GoToE
/D (Chapter 1)
/T << /R /C
/N (Embedded document) >>
>>
endobj
KEY TYPE VALUE
R
name (Required) Specifies the relationship between the current document and the
target (which may be an intermediate target). Valid values are
P (the target is
the parent of the current document) and
C (the target is a child of the current
document).
N
string (Required if the value of R is C and the target is located in the EmbeddedFiles
name tree; otherwise, it must be absent) The name of the file in the
EmbeddedFiles name tree.
P
integer or string (Required if the value of R is C and the target is associated with a file attachment
annotation; otherwise, it must be absent) If the value is an integer, it specifies
the page number (zero-based) in the current document containing the file at-
tachment annotation. If the value is a string, it specifies a named destination
in the current document that provides the page number of the file attachment
annotation.
A
integer or text
string
(Required if the value of R is C and the target is associated with a file attachment
annotation; otherwise, it must be absent) If the value is an integer, it specifies
the index (zero-based) of the annotation in the
Annots array (see Table 3.27)
of the page specified by
P . If the value is a text string, it specifies the value of
NM in the annotation dictionary (see Table 8.11).
T
dictionary (Optional) A target dictionary specifying additional path information to the
target document. If this entry is absent, the current document is the target file
containing the destination.
Interactive FeaturesCHAPTER 8
620
2 0 obj % Link to the parent
<< /Type /Action
/S /GoToE
/D (Chapter 1)
/T << /R /P >>
>>
endobj
3 0 obj % Link to a sibling
<< /Type /Action
/S /GoToE
/D (Chapter 1)
/T << /R /P
/T << /R /C
/N (Another embedded document) >>
>>
>>
endobj
4 0 obj % Link to an embedded file in an external document
<< /Type /Action
/S /GoToE
/D (Chapter 1)
/F (someFile.pdf)
/T << /R /C
/N (Embedded document) >>
>>
endobj
5 0 obj % Link from an embedded file to a normal file
<< /Type /Action
/S /GoToE
/D (Chapter 1)
/F (someFile.pdf)
>>
endobj
ActionsSECTION 8.5
621
6 0 obj % Link to a grandchild
<< /Type /Action
/S /GoToE
/D (Chapter 1)
/T << /R /C
/N (Embedded document)
/T << /R /C
/P (A destination name)
/A (annotName)
>>
>>
>>
endobj
7 0 obj % Link to a niece/nephew through the source’s parent
<< /Type /Action
/S /GoToE
/D (destination)
/T << /R /P
/T << /R /C
/N (Embedded document)
/T << /R /C
/P 3
/A (annotName)
>>
>>
>>
>>
endobj
Launch Actions
A launch action launches an application or opens or prints a document. Table
8.49 shows the action dictionary entries specific to this type of action.
The optional
Win, Mac, and Unix entries allow the action dictionary to include
platform-specific parameters for launching the designated application. If no
such entry is present for the given platform, the
F entry is used instead. Table
8.50 shows the platform-specific launch parameters for the Windows platform.
Parameters for the Mac OS and UNIX platforms are not yet defined at the time
of publication.
Interactive FeaturesCHAPTER 8
622
TABLE 8.49 Additional entries specific to a launch action
TABLE 8.50 Entries in a Windows launch parameter dictionary
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Launch
for a launch action.
F
file specification (Required if none of the entries Win, Mac, or Unix is present) The application to
be launched or the document to be opened or printed. If this entry is absent
and the viewer application does not understand any of the alternative entries,
it should do nothing.
Win
dictionary (Optional) A dictionary containing Windows-specific launch parameters (see
Table 8.50; see also implementation note 100 in Appendix H).
Mac
(undefined) (Optional) Mac OS–specific launch parameters; not yet defined.
Unix
(undefined) (Optional) UNIX-specific launch parameters; not yet defined.
NewWindow
boolean (Optional; PDF 1.2) A flag specifying whether to open the destination docu-
ment in a new window. If this flag is
false, the destination document replaces
the current document in the same window. If this entry is absent, the viewer
application should behave in accordance with the current user preference.
This entry is ignored if the file designated by the
F entry is not a PDF docu-
ment.
KEY TYPE VALUE
F
string (Required) The file name of the application to be launched or the document
to be opened or printed, in standard Windows pathname format. If the name
string includes a backslash character (
\), the backslash must itself be preceded
by a backslash.
Note: This value must be a simple string; it is not a file specification.
D
string (Optional) A string specifying the default directory in standard DOS syntax.
O
string (Optional) A string specifying the operation to perform:
open Open a document.
print Print a document.
If the
F entry designates an application instead of a document, this entry is ig-
nored and the application is launched. Default value:
open.
ActionsSECTION 8.5
623
Thread Actions
A thread action jumps to a specified bead on an article thread (see Section 8.3.2,
“Articles”), in either the current document or a different one. Table 8.51 shows
the action dictionary entries specific to this type of action.
TABLE 8.51 Additional entries specific to a thread action
P
string (Optional) A parameter string to be passed to the application designated by
the
F entry. This entry should be omitted if F designates a document.
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Thread
for a thread action.
F
file specification (Optional) The file containing the thread. If this entry is absent, the thread is
in the current file.
D
dictionary, integer,
or text string
(Required) The destination thread, specified in one of the following forms:
• An indirect reference to a thread dictionary (see Section 8.3.2, “Articles”).
In this case, the thread must be in the current file.
• The index of the thread within the Threads array of its document’s catalog
(see Section 3.6.1, “Document Catalog”). The first thread in the array has
index 0.
• The title of the thread as specified in its thread information dictionary (see
Table 8.7 on page 561). If two or more threads have the same title, the one
appearing first in the document catalog’s
Threads array is used.
B
dictionary or integer (Optional) The bead in the destination thread, specified in one of the follow-
ing forms:
• An indirect reference to a bead dictionary (see Section 8.3.2, “Articles”). In
this case, the thread must be in the current file.
• The index of the bead within its thread. The first bead in a thread has
index 0.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
624
URI Actions
A uniform resource identifier (URI) is a string that identifies (resolves to) a re-
source on the Internet—typically a file that is the destination of a hypertext link,
although it can also resolve to a query or other entity. (URIs are described in In-
ternet RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax; see the Bib-
liography.)
A URI action causes a URI to be resolved. Table 8.52 shows the action dictionary
entries specific to this type of action. (See implementation notes 101 and 102 in
Appendix H.)
TABLE 8.52 Additional entries specific to a URI action
If the IsMap flag is true and the user has triggered the URI action by clicking an
annotation, the coordinates of the mouse position at the time the action is per-
formed should be transformed from device space to user space and then offset
relative to the upper-left corner of the annotation rectangle (that is, the value of
the
Rect entry in the annotation with which the URI action is associated). For ex-
ample, if the mouse coordinates in user space are (x
m
, y
m
) and the annotation
rectangle extends from (ll
x
, ll
y
) at the lower-left to (ur
x
, ur
y
) at the upper-right,
the final coordinates (x
f
, y
f
) are as follows:
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be URI for a URI ac-
tion.
URI
string (Required) The uniform resource identifier to resolve, encoded in 7-bit ASCII.
IsMap
boolean (Optional) A flag specifying whether to track the mouse position when the URI is re-
solved (see below). Default value:
false.
This entry applies only to actions triggered by the user’s clicking an annotation; it is
ignored for actions associated with outline items or with a document’s
OpenAction
entry.
x
f
x
m
ll
x
–=()
y
f
ur
y
y
m
–=
ActionsSECTION 8.5
625
If the resulting coordinates (x
f
, y
f
) are fractional, they should be rounded to the
nearest integer values. They are then appended to the URI to be resolved, separat-
ed by commas and preceded by a question mark, as shown in this example:
http://www.adobe.com/intro?100,200
To support URI actions, a PDF document’s catalog (see Section 3.6.1, “Document
Catalog”) may include a
URI entry whose value is a URI dictionary. At the time of
publication, only one entry is defined for such a dictionary (see Table 8.53).
TABLE 8.53 Entry in a URI dictionary
The Base entry allows the URI of the document to be recorded in situations in
which the document may be accessed out of context. For example, if a document
has been moved to a new location but contains relative links to other documents
that have not been moved, the
Base entry could be used to refer such links to the
true location of the other documents, rather than that of the moved document.
Sound Actions
A sound action (PDF 1.2) plays a sound through the computer’s speakers. Table
8.54 shows the action dictionary entries specific to this type of action. Sounds are
discussed in Section 9.2, “Sounds.”
TABLE 8.54 Additional entries specific to a sound action
KEY TYPE VALUE
Base
string (Optional) The base URI to be used in resolving relative URI references. URI actions
within the document may specify URIs in partial form, to be interpreted relative to
this base address. If no base URI is specified, such partial URIs are interpreted rela-
tive to the location of the document itself. The use of this entry is parallel to that of
the body element
<BASE>, as described in the HTML 4.01 Specification (see the Bibli-
ography).
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Sound
for a sound action.
Sound
stream (Required) A sound object defining the sound to be played (see Section 9.2,
“Sounds”; see also implementation note 103 in Appendix H).
Interactive FeaturesCHAPTER 8
626
Movie Actions
A movie action (PDF 1.2) can be used to play a movie in a floating window or
within the annotation rectangle of a movie annotation (see “Movie Annotations”
on page 601 and Section 9.3, “Movies”). The movie annotation must be associated
with the page that is the destination of the link annotation or outline item con-
taining the movie action, or with the page object with which the action is
associated. (See implementation note 107 in Appendix H.)
Note: A movie action by itself does not guarantee that the page the movie is on will
be displayed before attempting to play the movie; such page change actions must be
done explicitly.
The contents of a movie action dictionary are identical to those of a movie activa-
tion dictionary (see Table 9.31 on page 742), with the additional entries shown in
Table 8.55. The contents of the activation dictionary associated with the movie
annotation provide the default values. Any information specified in the movie ac-
tion dictionary overrides these values.
Volume
number (Optional) The volume at which to play the sound, in the range 1.0 to 1.0;
see implementation note 105 in Appendix H. Default value: 1.0.
Synchronous
boolean (Optional) A flag specifying whether to play the sound synchronously or
asynchronously; see implementation note 105 in Appendix H. If this flag is
true, the viewer application retains control, allowing no further user interac-
tion other than canceling the sound, until the sound has been completely
played. Default value:
false.
Repeat
boolean (Optional) A flag specifying whether to repeat the sound indefinitely. If this
entry is present, the
Synchronous entry is ignored. Default value: false.
Mix
boolean (Optional) A flag specifying whether to mix this sound with any other sound
already playing; see implementation note 106 in Appendix H. If this flag is
false, any previously playing sound is stopped before starting this sound; this
can be used to stop a repeating sound (see
Repeat, above). Default value:
false.
KEY TYPE VALUE
ActionsSECTION 8.5
627
TABLE 8.55 Additional entries specific to a movie action
Hide Actions
A hide action (PDF 1.2) hides or shows one or more annotations on the screen by
setting or clearing their Hidden flags (see Section 8.4.2, “Annotation Flags”). This
type of action can be used in combination with appearance streams and trigger
events (Sections 8.4.4, “Appearance Streams,” and 8.5.2, “Trigger Events”) to dis-
play pop-up help information on the screen. For example, the
E (enter) and X (ex-
it) trigger events in an annotation’s additional-actions dictionary can be used to
show and hide the annotation when the user rolls the cursor in and out of its ac-
tive area on the page. This can be used to pop up a help label, or tool tip,
describing the effect of clicking at that location on the page. Table 8.56 shows the
action dictionary entries specific to this type of action. (See implementation
notes 108 and 109 in Appendix H.)
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Movie
for a movie action.
Annotation
dictionary (Optional) An indirect reference to a movie annotation identifying the movie
to be played.
T
text string (Optional) The title of a movie annotation identifying the movie to be played.
Note: The dictionary must include either an
Annotation or a T entry but not
both.
Operation
name (Optional) The operation to be performed on the movie:
Play Start playing the movie, using the play mode specified by the
dictionary’s
Mode entry (see Table 9.31 on page 742). If the
movie is currently paused, it is repositioned to the beginning
before playing (or to the starting point specified by the dic-
tionary’s
Start entry, if present).
Stop Stop playing the movie.
Pause Pause a playing movie.
Resume Resume a paused movie.
Default value:
Play.
Interactive FeaturesCHAPTER 8
628
TABLE 8.56 Additional entries specific to a hide action
Named Actions
Table 8.57 lists several named actions (PDF 1.2) that PDF viewer applications are
expected to support; further names may be added in the future. (See implementa-
tion notes 110 and 111 in Appendix H.)
TABLE 8.57 Named actions
Note: Viewer applications may support additional, nonstandard named actions, but
any document using them is not portable. If the viewer encounters a named action
that is inappropriate for a viewing platform, or if the viewer does not recognize the
name, it should take no action.
Table 8.58 shows the action dictionary entries specific to named actions.
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Hide for a hide
action.
T
dictionary,
string, or array
(Required) The annotation or annotations to be hidden or shown, specified in any
of the following forms:
• An indirect reference to an annotation dictionary
• A string giving the fully qualified field name of an interactive form field whose
associated widget annotation or annotations are to be affected (see “Field Names”
on page 638)
• An array of such dictionaries or strings
H
boolean (Optional) A flag indicating whether to hide the annotation (true) or show it (false).
Default value:
true.
NAME ACTION
NextPage
Go to the next page of the document.
PrevPage
Go to the previous page of the document.
FirstPage
Go to the first page of the document.
LastPage
Go to the last page of the document.
ActionsSECTION 8.5
629
TABLE 8.58 Additional entries specific to named actions
Set-OCG-State Actions
A set-OCG-state action (PDF 1.5) sets the state of one or more optional content
groups (see Section 4.10, “Optional Content”). Table 8.59 shows the action dictio-
nary entries specific to this type of action.
TABLE 8.59 Additional entries specific to a set-OCG-state action
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Named for a named
action.
N
name (Required) The name of the action to be performed (see Table 8.57).
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be SetOCGState
for a set-OCG-state action.
State
array (Required) An array consisting of any number of sequences beginning with a name
object (
ON, OFF, or Toggle) followed by one or more optional content group dictio-
naries. The array elements are processed from left to right; each name is applied to
the subsequent groups until the next name is encountered:
• ON sets the state of subsequent groups to ON
• OFF sets the state of subsequent groups to OFF
• Toggle reverses the state of subsequent groups.
PreserveRB
boolean (Optional) If true, indicates that radio-button state relationships between optional
content groups (as specified by the
RBGroups entry in the current configuration
dictionary; see Table 4.51 on page 346) should be preserved when the states in the
State array are applied. That is, if a group is set to ON (either by ON or Toggle) dur-
ing processing of the
State array, any other groups belonging to the same radio-but-
ton group are turned
OFF. If a group is set to OFF, there is no effect on other groups.
If
PreserveRB is false, radio-button state relationships, if any, are ignored.
Default value:
true.
Interactive FeaturesCHAPTER 8
630
When a set-OCG-state action is performed, the State array is processed from left
to right. Each name is applied to subsequent groups in the array until the next
name is encountered, as shown in the following example.
Example 8.11
<< /S /SetOCGState
/State [/OFF 2 0 R 3 0 R /Toggle 16 0 R 19 0 R /ON 5 0 R]
>>
A group can appear more than once in the State array; its state is set each time it
is encountered, based on the most recent name. For example, if the array con-
tained
[/OFF 1 0 R /Toggle 1 0 R], the group’s state would be ON after the action was
performed.
ON, OFF and Toggle sequences have no required order. More than
one sequence in the array may contain the same name.
Note: While the specification allows a group to appear more than once in the
State
array, this is not intended to implement animation or any other sequential drawing
operations. PDF processing applications are free to accumulate all state changes and
apply only the net changes simultaneously to all affected groups before redrawing.
Rendition Actions
A rendition action (PDF 1.5) controls the playing of multimedia content (see Sec-
tion 9.1, “Multimedia”). This action can be used in the following ways:
• To begin the playing of a rendition object (see Section 9.1.2, “Renditions”), as-
sociating it with a screen annotation (see “Screen Annotations” on page 602).
The screen annotation specifies where the rendition is played unless otherwise
specified.
• To stop, pause, or resume a playing rendition.
• To trigger the execution of a JavaScript script that may perform custom opera-
tions.
Table 8.60 lists the entries in a rendition action dictionary.
ActionsSECTION 8.5
631
TABLE 8.60 Additional entries specific to a rendition action
Either the JS entry or the OP entry must be present. If both are present, OP is con-
sidered a fallback to be executed if the viewer application is unable to execute
JavaScripts. If
OP has an unrecognized value and there is no JS entry, the action is
invalid.
In some situations, a pause (
OP value of 2) or resume (OP value of 3) operation
may not make sense (for example, for a JPEG image) or the player may not sup-
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Rendition for a
rendition action.
R
dictionary (Required when OP is present with a value of 0 or 4; otherwise optional) A rendition ob-
ject (see Section 9.1.2, “Renditions
”).
AN
dictionary (Required if OP is present with a value of 0, 1, 2, 3 or 4; otherwise optional) An indirect
reference to a screen annotation (see “Screen Annotations” on page 602).
OP
integer (Required if JS is not present; otherwise optional) The operation to perform when the
action is triggered. Valid values are:
0 If no rendition is associated with the annotation specified by
AN, play the ren-
dition specified by
R, associating it with the annotation. If a rendition is al-
ready associated with the annotation, it is stopped, and the new rendition is
associated with the annotation.
1 Stop any rendition being played in association with the annotation specified
by
AN, and remove the association. If no rendition is being played, there is no
effect.
2 Pause any rendition being played in association with the annotation specified
by
AN. If no rendition is being played, there is no effect.
3 Resume any rendition being played in association with the annotation speci-
fied by
AN. If no rendition is being played or the rendition is not paused, there
is no effect.
4 Play the rendition specified by
R, associating it with the annotation specified
by
AN. If a rendition is already associated with the annotation, resume the
rendition if it is paused; otherwise, do nothing.
JS
string or
stream
(Required if OP is not present; otherwise optional) A string or stream containing a Java-
Script script to be executed when the action is triggered.
Interactive FeaturesCHAPTER 8
632
port it. In such cases, the user should be notified of the failure to perform the op-
eration.
Before a rendition action is executed, the viewer application must make sure that
the
P entry of the screen annotation dictionary references a valid page object and
that the annotation is present in the page object’s
Annots array (see Table 3.27). A
rendition may play in the rectangle occupied by a screen annotation, even if the
annotation itself is not visible; for example, if its Hidden or NoView flags (see Ta-
ble 8.12) are set. If a screen annotation is not visible because its location on the
page is not being displayed by the viewer, the rendition is not visible. However, it
may become visible if the view changes, such as by scrolling.
Transition Actions
A transition action (PDF 1.5) can be used to control drawing during a sequence of
actions. As discussed in Section 8.5.1, “Action Dictionaries,” the
Next entry in an
action dictionary can specify a sequence of actions. Viewer applications should
normally suspend drawing when such a sequence begins and resume drawing
when it ends. If a transition action is present during a sequence, the viewer
should render the state of the page viewing area as it exists after completion of the
previous action and display it using a transition specified in the action dictionary
(see Table 8.61). Once this transition completes, drawing should be suspended
again.
TABLE 8.61 Additional entries specific to a transition action
Go-To-3D-View Actions
A go-to-3D-view action (PDF 1.6) identifies a 3D annotation and specifies a view
for the annotation to use (see Section 9.5, “3D Artwork”). Table 8.62 shows the
entries in a go-to-3D-view action dictionary.
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be Trans for a
transition action.
Trans
dictionary (Required) The transition to use for the update of the display (see Table 8.9).
ActionsSECTION 8.5
633
TABLE 8.62 Additional entries specific to a go-to-3D-view action
The V entry selects the view to apply to the annotation specified by TA. This view
may be one of the predefined views specified by the
VA entry of the 3D stream
(see Table 9.35) or a unique view specified here.
If the predefined view is specified by the names
N (next) or P (previous), it should
be interpreted in the following way:
• When the last view applied was specified by means of the VA array, N and P in-
dicate the next and previous entries, respectively, in the
VA array (wrapping
around if necessary).
• When the last view was not specified by means of VA, using N or P should result
in reverting to the default view.
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be GoTo3DView
for a transition action.
TA
dictionary (Required) The target annotation for which to set the view.
V
(various) (Required) The view to use. It can be one of the following types:
• A 3D view dictionary (see Section 9.5.3, “3D Views”).
• An integer specifying an index into the VA array in the 3D stream (see Table
9.35).
• A text string matching the IN entry in one of the views in the VA array (see Table
9.37).
• A name that indicates the first (F), last (L), next (N), previous (P), or default (D)
entries in the
VA array; see discussion below.
Interactive FeaturesCHAPTER 8
634
8.6 Interactive Forms
An interactive form (PDF 1.2)—sometimes referred to as an AcroForm—is a
collection of fields for gathering information interactively from the user. A PDF
document may contain any number of fields appearing on any combination of
pages, all of which make up a single, global interactive form spanning the entire
document. Arbitrary subsets of these fields can be imported or exported from the
document; see Section 8.6.4, “Form Actions.”
Note: Interactive forms should not be confused with form XObjects (see Section 4.9,
“Form XObjects”). Despite the similarity of names, the two are different, unrelated
types of objects.
Each field in a document’s interactive form is defined by a field dictionary (see
Section 8.6.2, “Field Dictionaries”). For purposes of definition and naming, the
fields can be organized hierarchically and can inherit attributes from their an-
cestors in the field hierarchy. A field’s children in the hierarchy may also include
widget annotations (see “Widget Annotations” on page 603) that define its ap-
pearance on the page. A field whose children are widget annotations is called a
terminal field.
As a convenience, when a field has only a single associated widget annotation, the
contents of the field dictionary and the annotation dictionary (Section 8.4.1, “An-
notation Dictionaries”) may be merged into a single dictionary containing entries
that pertain to both a field and an annotation. (This presents no ambiguity, since
the contents of the two kinds of dictionaries do not conflict.) If such an object de-
fines an appearance stream, the appearance must be consistent with the object’s
current value as a field.
Note: Fields containing text whose contents are not known in advance may need to
construct their appearance streams dynamically instead of defining them statically
in an appearance dictionary; see “Variable Text” on page 639.
8.6.1 Interactive Form Dictionary
The contents and properties of a document’s interactive form are defined by an
interactive form dictionary that is referenced from the
AcroForm entry in the doc-
ument catalog (see Section 3.6.1, “Document Catalog”). Table 8.63 shows the
contents of this dictionary.
Interactive FormsSECTION 8.6
635
TABLE 8.63 Entries in the interactive form dictionary
KEY TYPE VALUE
Fields
array (Required) An array of references to the document’s root fields (those
with no ancestors in the field hierarchy).
NeedAppearances
boolean (Optional) A flag specifying whether to construct appearance streams
and appearance dictionaries for all widget annotations in the docu-
ment (see “Variable Text” on page 639). Default value:
false.
SigFlags
integer (Optional; PDF 1.3) A set of flags specifying various document-level
characteristics related to signature fields (see Table 8.64, below, and
“Signature Fields” on page 658). Default value: 0.
CO
array (Required if any fields in the document have additional-actions dictio-
naries containing a
C entry; PDF 1.3) An array of indirect references to
field dictionaries with calculation actions, defining the calculation or-
der in which their values will be recalculated when the value of any
field changes (see Section 8.5.2, “Trigger Events”).
DR
dictionary (Optional) A resource dictionary (see Section 3.7.2, “Resource Diction-
aries”) containing default resources (such as fonts, patterns, or color
spaces) to be used by form field appearance streams. At a minimum,
this dictionary must contain a
Font entry specifying the resource name
and font dictionary of the default font for displaying text. (See imple-
mentation notes 112 and 113 in Appendix H.)
DA
string (Optional) A document-wide default value for the DA attribute of vari-
able text fields (see “Variable Text” on page 639).
Q
integer (Optional) A document-wide default value for the Q attribute of vari-
able text fields (see “Variable Text” on page 639).
XFA
stream or array (Optional; PDF 1.5) A stream or array containing an XFA resource,
whose format is described by the XML Data Package Specification (see
the Bibliography). The value of this entry must be either a stream rep-
resenting the entire contents of the XML Data Package or an array of
string and stream pairs representing the individual packets comprising
the XML Data Package.
See Section 8.6.7, “XFA Forms,” for more information.
Note: In the original version of the PDF 1.5 specification, the value of
this entry was defined as a stream only; see implementation note 114 in
Appendix H.
Interactive FeaturesCHAPTER 8
636
The value of the interactive form dictionary’s SigFlags entry is an unsigned 32-bit
integer containing flags specifying various document-level characteristics related
to signature fields (see “Signature Fields” on page 658). Bit positions within the
flag word are numbered from 1 (low-order) to 32 (high-order). Table 8.64 shows
the meanings of the flags; all undefined flag bits are reserved and must be set to 0.
TABLE 8.64 Signature flags
8.6.2 Field Dictionaries
Each field in a document’s interactive form is defined by a field dictionary, which
must be an indirect object. The field dictionaries may be organized hierarchically
into one or more tree structures. Many field attributes are inheritable, meaning
that if they are not explicitly specified for a given field, their values are taken from
those of its parent in the field hierarchy. Such inheritable attributes are designated
as such in the tables below. The designation (Required; inheritable) means that an
attribute must be defined for every field, whether explicitly in its own field dictio-
nary or by inheritance from an ancestor in the hierarchy. Table 8.65 shows those
entries that are common to all field dictionaries, regardless of type. Entries that
pertain only to a particular type of field are described in the relevant sections be-
low.
BIT POSITION NAME MEANING
1 SignaturesExist If set, the document contains at least one signature field. This flag allows a
viewer application to enable user interface items (such as menu items or
pushbuttons) related to signature processing without having to scan the
entire document for the presence of signature fields.
2 AppendOnly If set, the document contains signatures that may be invalidated if the file
is saved (written) in a way that alters its previous contents, as opposed to
an incremental update. Merely updating the file by appending new infor-
mation to the end of the previous version is safe (see Section G.6, “Up-
dating Example”). Viewer applications can use this flag to present a user
requesting a full save with an additional alert box warning that signatures
will be invalidated and requiring explicit confirmation before continuing
with the operation.
Interactive FormsSECTION 8.6
637
TABLE 8.65 Entries common to all field dictionaries
KEY TYPE VALUE
FT
name (Required for terminal fields; inheritable) The type of field that this dictionary
describes:
Btn Button (see “Button Fields” on page 647)
Tx Text (see “Text Fields” on page 653)
Ch Choice (see “Choice Fields” on page 656)
Sig (PDF 1.3) Signature (see “Signature Fields” on page 658)
Note: This entry may be present in a nonterminal field (one whose descendants
are fields) to provide an inheritable
FT value. However, a nonterminal field does
not logically have a type of its own; it is merely a container for inheritable at-
tributes that are intended for descendant terminal fields of any type.
Parent
dictionary (Required if this field is the child of another in the field hierarchy; absent other-
wise) The field that is the immediate parent of this one (the field, if any,
whose
Kids array includes this field). A field can have at most one parent; that
is, it can be included in the
Kids array of at most one other field.
Kids
array (Sometimes required, as described below) An array of indirect references to the
immediate children of this field.
In a non-terminal field, the
Kids array is required to refer to field dictionaries
that are immediate descendants of this field. In a terminal field, the
Kids array
ordinarily must refer to one or more separate widget annotations that are as-
sociated with this field. However, if there is only one associated widget anno-
tation, and its contents have been merged into the field dictionary,
Kids must
be omitted.
T
text string (Optional) The partial field name (see “Field Names,” below; see also imple-
mentation notes 115 and 116 in Appendix H).
TU
text string (Optional; PDF 1.3) An alternate field name to be used in place of the actual
field name wherever the field must be identified in the user interface (such as
in error or status messages referring to the field). This text is also useful when
extracting the document’s contents in support of accessibility to users with
disabilities or for other purposes (see Section 10.8.2, “Alternate Descrip-
tions”).
TM
text string (Optional; PDF 1.3) The mapping name to be used when exporting interactive
form field data from the document.
Ff
integer (Optional; inheritable) A set of flags specifying various characteristics of the
field (see Table 8.66). Default value: 0.
Interactive FeaturesCHAPTER 8
638
The value of the field dictionary’s Ff entry is an unsigned 32-bit integer contain-
ing flags specifying various characteristics of the field. Bit positions within the
flag word are numbered from 1 (low-order) to 32 (high-order). The flags shown
in Table 8.66 are common to all types of fields. Flags that apply only to specific
field types are discussed in the sections describing those types. All undefined flag
bits are reserved and must be set to 0.
TABLE 8.66 Field flags common to all field types
Field Names
The T entry in the field dictionary (see Table 8.65 on page 637) holds a text string
defining the field’s partial field name. The fully qualified field name is not explicit-
ly defined but is constructed from the partial field names of the field and all of its
V
(various) (Optional; inheritable) The field’s value, whose format varies depending on
the field type. See the descriptions of individual field types for further infor-
mation.
DV
(various) (Optional; inheritable) The default value to which the field reverts when a
reset-form action is executed (see “Reset-Form Actions” on page 666). The
format of this value is the same as that of
V.
AA
dictionary (Optional; PDF 1.2) An additional-actions dictionary defining the field’s
behavior in response to various trigger events (see Section 8.5.2, “Trigger
Events”). This entry has exactly the same meaning as the
AA entry in an
annotation dictionary (see Section 8.4.1, “Annotation Dictionaries”).
BIT POSITION NAME MEANING
1 ReadOnly If set, the user may not change the value of the field. Any associated widget
annotations will not interact with the user; that is, they will not respond to
mouse clicks or change their appearance in response to mouse motions. This
flag is useful for fields whose values are computed or imported from a data-
base.
2 Required If set, the field must have a value at the time it is exported by a submit-form
action (see “Submit-Form Actions” on page 662).
3 NoExport If set, the field must not be exported by a submit-form action (see “Submit-
Form Actions” on page 662).
KEY TYPE VALUE
Interactive FormsSECTION 8.6
639
ancestors. For a field with no parent, the partial and fully qualified names are the
same. For a field that is the child of another field, the fully qualified name is
formed by appending the child field’s partial name to the parent’s fully qualified
name, separated by a period (
.):
parent’s_full_name .child’s_partial_name
For example, if a field with the partial field name PersonalData has a child whose
partial name is
Address, which in turn has a child with the partial name ZipCode,
the fully qualified name of this last field is
PersonalData.Address.ZipCode
Thus, all fields descended from a common ancestor share the ancestor’s fully
qualified field name as a common prefix in their own fully qualified names.
It is possible for different field dictionaries to have the same fully qualified field
name if they are descendants of a common ancestor with that name and have no
partial field names (
T entries) of their own. Such field dictionaries are different
representations of the same underlying field; they should differ only in properties
that specify their visual appearance. In particular, field dictionaries with the same
fully qualified field name must have the same field type (
FT), value (V), and de-
fault value (
DV).
Variable Text
When the contents and properties of a field are known in advance, its visual ap-
pearance can be specified by an appearance stream defined in the PDF file (see
Section 8.4.4, “Appearance Streams,” and “Widget Annotations” on page 603). In
some cases, however, the field may contain text whose value is not known until
viewing time. Examples include text fields to be filled in with text typed by the
user from the keyboard and scrollable list boxes whose contents are determined
interactively at the time the document is displayed.
In such cases, the PDF document cannot provide a statically defined appearance
stream for displaying the field. Instead, the viewer application must construct an
appearance stream dynamically at viewing time. The dictionary entries shown in
Table 8.67 provide general information about the field’s appearance that can be
combined with the specific text it contains to construct an appearance stream.
Interactive FeaturesCHAPTER 8
640
TABLE 8.67 Additional entries common to all fields containing variable text
The new appearance stream becomes the normal appearance (N) in the appear-
ance dictionary associated with the field’s widget annotation (see Table 8.15 on
page 579). (If the widget annotation has no appearance dictionary, the viewer ap-
plication must create one and store it in the annotation dictionary’s
AP entry.)
In PDF 1.5, form fields that have the RichText flag set (see Table 8.73) specify for-
matting information as described in “Rich Text Strings” on page 642. For these
fields, the conventions described below are not used, and the entire annotation
appearance is regenerated each time the value is changed.
For non-rich text fields, the appearance stream—which, like all appearance
streams, is a form XObject—has the contents of its form dictionary initialized as
follows:
• The resource dictionary (Resources) is created using resources from the inter-
active form dictionary’s
DR entry (see Table 8.63); see also implementation note
117 in Appendix H.
• The lower-left corner of the bounding box (BBox) is set to coordinates (0, 0) in
the form coordinate system. The box’s top and right coordinates are taken from
KEY TYPE VALUE
DA
string (Required; inheritable) The default appearance string containing a sequence of valid
page-content graphics or text state operators that define such properties as the field’s
text size and color.
Q
integer (Optional; inheritable) A code specifying the form of quadding (justification) to be used
in displaying the text:
0 Left-justified
1Centered
2 Right-justified
Default value: 0 (left-justified).
DS
text string (Optional; PDF 1.5) A default style string, as described in “Rich Text Strings” on page
642.
RV
text string or
text stream
(Optional; PDF 1.5) A rich text string, as described in “Rich Text Strings” on page 642.
Interactive FormsSECTION 8.6
641
the dimensions of the annotation rectangle (the Rect entry in the widget anno-
tation dictionary).
• All other entries in the appearance stream’s form dictionary are set to their
default values (see Section 4.9, “Form XObjects”).
The appearance stream includes the following section of marked content, which
represents the portion of the stream that draws the text:
Example 8.12
/Tx BMC % Begin marked content with tag Tx
q % Save graphics state
…Any required graphics state changes, such as clipping …
BT % Begin text object
…Default appearance string (DA)…
…Text-positioning and text-showing operators to show the variable text…
ET % End text object
Q % Restore graphics state
EMC % End marked content
The BMC (begin marked content) and EMC (end marked content) operators are
discussed in Section 10.5, “Marked Content”.
q (save graphics state) and Q (re-
store graphics state) are discussed in Section 4.3.3, “Graphics State Operators”.
BT
(begin text object) and ET (end text object) are discussed in Section 5.3, “Text Ob-
jects.” See Example 8.16 for an example.
The default appearance string (
DA) contains any graphics state or text state oper-
ators needed to establish the graphics state parameters, such as text size and color,
for displaying the field’s variable text. Only operators that are allowed within text
objects may occur in this string (see Figure 4.1 on page 167). At a minimum, the
string must include a
Tf (text font) operator along with its two operands, font and
size. The specified font value must match a resource name in the Font entry of the
default resource dictionary (referenced from the
DR entry of the interactive form
dictionary; see Table 8.63). A zero value for
size means that the font is to be auto-
sized: its size is computed as a function of the height of the annotation rectangle.
The default appearance string should contain at most one
Tm (text matrix) opera-
tor. If this operator is present, the viewer application should replace the horizon-
tal and vertical translation components with positioning values it determines to
be appropriate, based on the field value, the quadding (
Q) attribute, and any lay-
out rules it employs. If the default appearance string contains no
Tm operator, the
Interactive FeaturesCHAPTER 8
642
viewer should insert one in the appearance stream (with appropriate horizontal
and vertical translation components) after the default appearance string and be-
fore the text-positioning and text-showing operators for the variable text.
To update an existing appearance stream to reflect a new field value, the viewer
application should first copy any needed resources from the document’s
DR dic-
tionary (see Table 8.63) into the stream’s
Resources dictionary. (If the DR and
Resources dictionaries contain resources with the same name, the one already in
the
Resources dictionary should be left intact, not replaced with the correspond-
ing value from the
DR dictionary.) The viewer application should then replace the
existing contents of the appearance stream from
/Tx BMC to the matching EMC
with the corresponding new contents as shown in Example 8.12. (If the existing
appearance stream contains no marked content with tag
Tx, the new contents
should be appended to the end of the original stream.) Also see implementation
note 118 in Appendix H.
Rich Text Strings
Beginning with PDF 1.5, the text contents of variable text form fields, as well as
markup annotations, can include formatting (style) information. These rich text
strings are fully-formed XML documents that conform to a subset of the XFA
Text Specification, which is itself a subset of the XHTML 1.0 specification, aug-
mented with a restricted set of CSS2 style attributes (see the Bibliography for ref-
erences to all these standards). This section describes the basic elements of this
specification.
Table 8.68 lists the XHTML elements that are supported in rich text strings. The
<body> element is the root element; its required attributes are listed in Table 8.69.
Other elements (
<p> and <span>) contain enclosed text that may take style at-
tributes, which are listed in Table 8.70. These style attributes are CSS inline style
property declarations of the form
name:value, with each declaration separated by
a semicolon, as illustrated in Example 8.13 on page 646.
TABLE 8.68 XHTML Elements used in rich text strings
ELEMENT DESCRIPTION
<body>
The element at the root of the XML document. Table 8.69 lists the re-
quired attributes for this element.
Interactive FormsSECTION 8.6
643
TABLE 8.69 Attributes of the <body> element
<p>
Encloses text that is interpreted as a paragraph. It may take the style at-
tributes listed in Table 8.70.
<i>
Encloses text that is displayed in an italic font.
<b>
Encloses text that is displayed in a bold font.
<span>
Groups text solely for the purpose of applying styles (using the attributes
in Table 8.70).
ATTRIBUTE DESCRIPTION
xmlns
The default namespaces for elements within the rich text string.
Must be
xmlns="http://www.w3.org/1999/xhtml"
xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0"
.
xfa:contentType
Must be "text/html".
xfa:APIVersion
A string that identifies the software used to generate the rich text
string. It must be of the form
software_name:software_version,
where
• software_name identifies the software by name. It must not con-
tain spaces.
• software_version identifies the version of the software. It consists
of a series of integers separated by decimal points. Each integer is
a version number, the leftmost value being a major version num-
ber, with values to the right increasingly minor. When comparing
strings, the versions are compared in order. For example “5.2” is
less than “5.13” because 2 is less than 13; the string is not treated as
a decimal number. When comparing strings with different num-
bers of sections, the string with fewer sections is implicitly padded
on the right with sections containing “0” to make the number of
sections equivalent.
xfa:spec
The version of the XFA specification to which the rich text string
complies. For PDF 1.5, versions 2.02 and earlier are supported. For
PDF 1.6, versions 2.2 and earlier are supported.
ELEMENT DESCRIPTION
Interactive FeaturesCHAPTER 8
644
TABLE 8.70 CSS2 style attributes used in rich text strings
ATTRIBUTE VALUE DESCRIPTION
text-align
keyword Horizontal alignment. Possible values: left, right, center.
vertical-align
decimal An amount by which to adjust the baseline of the enclosed text. A positive
value indicates a superscript; a negative value indicates a subscript. The value
is of the form
<decimal number>pt, optionally preceded by a sign, and fol-
lowed by “
pt”. E x a mp l e s : -3pt, 4pt.
font-size
decimal The font size of the enclosed text. The value is of the form
<decimal number>pt.
font-style
keyword Specifies whether the enclosed text should be displayed using a normal or
italic (oblique) font. Possible values:
normal, italic.
font-weight
keyword The weight of the font for the enclosed text. Possible values: normal, bold,
100, 200, 300, 400, 500, 600, 700, 800, 900.
Note:
normal is equivalent to 400, and bold is equivalent to 700.
font-family
list A font name or list of font names to be used to display the enclosed text. (If a
list is provided, the first one containing glyphs for the specified text is used.)
font
list A shorthand CSS font property of the form
font:<font-style> <font-weight> <font-size> <font-family>
color
RGB value The color of the enclosed text. The value is an RGB value specified in the
sRGB color space (<http://www.srgb.com>). It can be in one of two forms:
• #rrggbb with a 2-digit hexadecimal value for each component
• rgb(rrr,ggg,bbb) with a decimal value for each component.
Note: Although the values specified by the color property are interpreted as
sRGB values, they are transformed into values in a non-ICC based color space
when used to generate the annotation’s appearance.
text-decoration
keyword One of the following keywords:
• underline: The enclosed text should be underlined.
• line-through: The enclosed text should have a line drawn through it.
font-stretch
keyword Specifies a normal, condensed or extended face from a font family. Support-
ed values from narrowest to widest are
ultra-condensed, extra-condensed,
condensed, semi-condensed, normal, semi-expanded, expanded, extra-
expanded
, and ultra-expanded.
Interactive FormsSECTION 8.6
645
Rich text strings are specified by the RV entry of variable text form field dictionar-
ies (see Table 8.67) and the
RC entry of markup annotation dictionaries (see Table
8.17). Rich text strings may be packaged as text streams (see Section 3.8.2, “Text
Streams”). Form fields using rich text streams should also have the RichText flag
set (see Table 8.73).
A default style string is specified by the
DS entry for free text annotations (see Ta-
ble 8.21) or variable text form fields (see Table 8.67). This string specifies the de-
fault values for style attributes, which are used for any style attributes that are not
explicitly specified for the annotation or field. All attributes listed in Table 8.70
are legal in the default style string. This string, in addition to the
RV or RC entry, is
used to generate the appearance. The following entries are ignored by PDF 1.5-
compliant viewers: the
Contents entry for annotations, the DA entry for free text
annotations, and the
V, DA, and Q entries for form fields.
Note: Markup annotations other than free text annotations (see “Markup Annota-
tions” on page 581) do not use a default style string because their appearances are
implemented using platform controls requiring the viewer application to pick an ap-
propriate system font for display.
When a form field or annotation contains rich text strings, the flat text (character
data) of the string should also be preserved (in the
V entry for form fields and the
Contents entry for annotations). This enables older viewer applications to read
and edit the data (although with loss of formatting information). The
DA entry
should be written out as well when the file is saved.
If a document containing rich text strings is edited in a viewer that does not sup-
port PDF 1.5, the rich text strings remain unchanged (because they are unknown
to the viewer), even though the corresponding flat text may have changed. When
a viewer that supports PDF 1.5 reads a rich text string from a document, it must
check whether the corresponding flat text has changed by using the following
procedure:
1. Create a new flat text string containing the character data from the rich text
string. Character references (such as
) should be converted to their char-
acter equivalents.
Note: No attempt should be made to preserve formatting specified with markup
elements. For example, although the
<p> element implies a new line, a carriage
return should not be generated in the associated flat text.
Interactive FeaturesCHAPTER 8
646
2. If either of the values uses UTF-16 encoding, promote the other value to UTF-
16 if necessary.
3. Compare the resulting strings.
If the strings are unequal, it is assumed the field has been modified by an older
viewer, and a new rich text string should be created from the flat text.
When a rich text string specifies font attributes, the viewer application should use
font name selection as described in section 15.3 of the CSS2 specification (see the
Bibliography). It is strongly recommended that precedence be given to the fonts
in the default resources dictionary, as specified by the
DR entry in Table 8.63; see
Implementation note 119 in Appendix H.
The following example illustrates the entries in a widget annotation dictionary
for rich text. The
DS entry specifies the default font. The RV entry contains two
paragraphs of rich text: the first paragraph specifies bold and italic text in the de-
fault font; the second paragraph changes the font size.
Example 8.13
/DS (font: 18pt Arial) % Default style string using an abbreviated font
% descriptor to specify 18pt text using an Arial font
/RV (<?xml version="1.0"?><body xmlns="http://www.w3.org/1999/xtml"
xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/"
xfa:contentType="text/html" xfa:APIVersion="Acrobat:6.0.0" xfa:spec="2.0.2">
<p style="text-align:left">
<b>
<i>
Here is some bold italic text
</i>
</b>
</p>
<p style= "font-size:16pt">
This text uses default text state parameters but changes the font size to 16.
</p>
</body> )
Interactive FormsSECTION 8.6
647
8.6.3 Field Types
Interactive forms support the following field types:
• Button fields represent interactive controls on the screen that the user can
manipulate with the mouse. They include pushbuttons, check boxes, and radio
buttons.
• Text fields are boxes or spaces in which the user can enter text from the key-
board.
• Choice fields contain several text items, at most one of which may be selected as
the field value. They include scrollable list boxes and combo boxes.
• Signature fields represent electronic signatures for authenticating the identity of
a user and the validity of the document’s contents.
The following sections describe each of these field types in detail. Further types
may be added in the future.
Button Fields
A button field (field type Btn) represents an interactive control on the screen that
the user can manipulate with the mouse. There are three types of button fields:
• A pushbutton is a purely interactive control that responds immediately to user
input without retaining a permanent value (see “Pushbuttons” on page 648).
• A check box toggles between two states, on and off (see “Check Boxes” on page
648).
• Radio button fields contain a set of related buttons that can each be on or off.
Typically, at most one radio button in a set may be on at any given time, and se-
lecting any one of the buttons automatically deselects all the others. (There are
exceptions to this rule, as noted in “Radio Buttons” on page 650.)
The various types of button fields are distinguished by flags in the
Ff entry, as
shown in Table 8.71.
Interactive FeaturesCHAPTER 8
648
TABLE 8.71 Field flags specific to button fields
Pushbuttons
The simplest type of field is a pushbutton field, which has a field type of Btn and
the Pushbutton flag (see Table 8.71) set. Because this type of button retains no
permanent value, it does not use the
V and DV entries in the field dictionary (see
Table 8.65 on page 637).
Check Boxes
A check box field represents one or more check boxes that toggle between two
states, on and off, when manipulated by the user with the mouse or keyboard. Its
field type is
Btn and its Pushbutton and Radio flags (see Table 8.71) are both clear.
Each state can have a separate appearance, which is defined by an appearance
stream in the appearance dictionary of the field’s widget annotation (see Section
8.4.4, “Appearance Streams”). The appearance for the off state is optional but, if
present, must be stored in the appearance dictionary under the name
Off. The
recommended (but not required) name for the on state is
Yes.
The
V entry in the field dictionary (see Table 8.65 on page 637) holds a name ob-
ject representing the check box’s appearance state, which is used to select the ap-
propriate appearance from the appearance dictionary.
Example 8.14 shows a typical check box definition.
BIT POSITION NAME MEANING
15 NoToggleToOff (Radio buttons only) If set, exactly one radio button must be selected at all
times; clicking the currently selected button has no effect. If clear, clicking
the selected button deselects it, leaving no button selected.
16 Radio If set, the field is a set of radio buttons; if clear, the field is a check box.
This flag is meaningful only if the Pushbutton flag is clear.
17 Pushbutton If set, the field is a pushbutton that does not retain a permanent value.
26 RadiosInUnison (PDF 1.5) If set, a group of radio buttons within a radio button field that
use the same value for the on state will turn on and off in unison; that is if
one is checked, they are all checked. If clear, the buttons are mutually ex-
clusive (the same behavior as HTML radio buttons).
Interactive FormsSECTION 8.6
649
Example 8.14
1 0 obj
<< /FT /Btn
/T (Urgent)
/V /Yes
/AS /Yes
/AP << /N << /Yes 2 0 R /Off 3 0 R>>
>>
endobj
2 0 obj
<< /Resources 20 0 R
/Length 104
>>
stream
q
001rg
BT
/ZaDb 12 Tf
00Td
(8) Tj
ET
Q
endstream
endobj
3 0 obj
<< /Resources 20 0 R
/Length 104
>>
stream
q
001rg
BT
/ZaDb 12 Tf
00Td
(8) Tj
ET
Q
endstream
endobj
Interactive FeaturesCHAPTER 8
650
Beginning with PDF 1.4, the field dictionary for check boxes and radio buttons
contains an optional
Opt entry (see Table 8.72), which holds an array of text
strings representing the export value of each annotation in the field. It is used for
the following purposes:
• To represent the export values of check box and radio button fields in non-Lat-
in writing systems. Because name objects in the appearance dictionary are lim-
ited to
PDFDocEncoding, they cannot represent non-Latin text.
• To allow radio buttons or check boxes to be checked independently, even if they
have the same export value.
An example is a group of check boxes that are duplicated on more than one
page, and the desired behavior is that when a user checks a box, the corre-
sponding boxes on each of the other pages is also checked. In this case, each of
the corresponding check boxes is a widget in the
Kids array of a check box field.
Note: For radio buttons, the same behavior occurs only if the
RadiosInUnison flag
is set. If it is not set, at most one radio button in a field can be set at a time. See
implementation note 120 in Appendix H.
TABLE 8.72 Additional entry specific to check box and radio button fields
Radio Buttons
A radio button field is a set of related buttons. Like check boxes, individual radio
buttons have two states, on and off. A single radio button may not be turned off
directly but only as a result of another button being turned on. Typically, a set of
radio buttons (annotations that are children of a single radio button field) have at
KEY TYPE VALUE
Opt
array of
text strings
(Optional; inheritable; PDF 1.4) An array containing one entry for each widget annota-
tion in the
Kids array of the radio button or check box field. Each entry is a text string
representing the on state of the corresponding widget annotation.
When this entry is present, the names used to represent the on state in the
AP dictionary
of each annotation are computer-generated numbers equivalent to the numerical posi-
tion (starting with
0) of the annotation in the Kids array. This allows distinguishing be-
tween the annotations even if two or more of them have the same value in the
Opt array.
For example, two radio buttons may have the same on state, but if the RadiosInUnison
flag is not set, only one of them at a time can be checked by the user.
Interactive FormsSECTION 8.6
651
most one button in the on state at any given time; selecting any of the buttons au-
tomatically deselects all the others.
Note: An exception occurs when multiple radio buttons in a field have the same on
state and the RadiosInUnison flag is set. In that case, turning on one of the buttons
turns on all of them.
The field type is
Btn, the Pushbutton flag (see Table 8.71 on page 648) is clear, and
the Radio flag is set. This type of button field has an additional flag, NoToggle-
ToOff, which specifies, if set, that exactly one of the radio buttons must be select-
ed at all times. In this case, clicking the currently selected button has no effect; if
the NoToggleToOff flag is clear, clicking the selected button deselects it, leaving
no button selected.
The
Kids entry in the radio button field’s field dictionary (see Table 8.65 on page
637) holds an array of widget annotations representing the individual buttons in
the set. The parent field’s
V entry holds a name object corresponding to the ap-
pearance state of whichever child field is currently in the on state; the default val-
ue for this entry is
Off. Example 8.15 shows the object definitions for a set of radio
buttons.
Example 8.15
10 0 obj % Radio button field
<< /FT /Btn
/Ff … % …Radio flag = 1, Pushbutton = 0…
/T (Credit card)
/V /MasterCard
/Kids [ 11 0 R
12 0 R
]
>>
endobj
11 0 obj % First radio button
<< /Parent 10 0 R
/AS /MasterCard
/AP << /N << /MasterCard 8 0 R
/Off 9 0 R
>>
>>
>>
endobj
Interactive FeaturesCHAPTER 8
652
12 0 obj % Second radio button
<< /Parent 10 0 R
/AS /Off
/AP << /N << /Visa 8 0 R
/Off 9 0 R
>>
>>
>>
endobj
8 0 obj % Appearance stream for "on" state
<< /Resources 20 0 R
/Length 104
>>
stream
q
001rg
BT
/ZaDb 12 Tf
00Td
(8) Tj
ET
Q
endstream
endobj
9 0 obj % Appearance stream for "off" state
<< /Resources 20 0 R
/Length 104
>>
stream
q
001rg
BT
/ZaDb 12 Tf
00Td
(4) Tj
ET
Q
endstream
endobj
Like a check box field, a radio button field can use the optional Opt entry in the
field dictionary (PDF 1.4) to define export values for its constituent radio buttons,
Interactive FormsSECTION 8.6
653
using Unicode encoding for non-Latin characters (see Table 8.72). Opt holds an
array of text strings corresponding to the widget annotations representing the in-
dividual buttons in the field’s
Kids array.
Text Fields
A text field (field type Tx) is a box or space in which the user can enter text from
the keyboard. The text may be restricted to a single line or may be permitted to
span multiple lines, depending on the setting of the Multiline flag in the field dic-
tionary’s
Ff entry. Table 8.73 shows the flags pertaining to this type of field.
TABLE 8.73 Field flags specific to text fields
BIT POSITION NAME MEANING
13 Multiline If set, the field can contain multiple lines of text; if clear, the field’s text is
restricted to a single line.
14 Password If set, the field is intended for entering a secure password that should not
be echoed visibly to the screen. Characters typed from the keyboard
should instead be echoed in some unreadable form, such as asterisks or
bullet characters.
To protect password confidentiality, viewer applications should never
store the value of the text field in the PDF file if this flag is set.
21 FileSelect (PDF 1.4) If set, the text entered in the field represents the pathname of a
file whose contents are to be submitted as the value of the field.
23 DoNotSpellCheck (PDF 1.4) If set, text entered in the field is not spell-checked.
24 DoNotScroll (PDF 1.4) If set, the field does not scroll (horizontally for single-line fields,
vertically for multiple-line fields) to accommodate more text than fits
within its annotation rectangle. Once the field is full, no further text is ac-
cepted.
25 Comb (PDF 1.5) Meaningful only if the
MaxLen entry is present in the text field
dictionary (see Table 8.74) and if the Multiline, Password, and FileSelect
flags are clear. If set, the field is automatically divided into as many equally
spaced positions, or combs, as the value of
MaxLen, and the text is laid out
into those combs.
26 RichText (PDF 1.5) If set, the value of this field should be represented as a rich text
string (see “Rich Text Strings” on page 642). If the field has a value, the
RV
entry of the field dictionary (Table 8.67) specifies the rich text string.
Interactive FeaturesCHAPTER 8
654
The field’s text is held in a text string (or, beginning with PDF 1.5, a stream) in the
V (value) entry of the field dictionary. The contents of this text string or stream
are used to construct an appearance stream for displaying the field, as described
under “Variable Text” on page 639. The text is presented in a single style (font,
size, color, and so forth), as specified by the
DA (default appearance) string.
If the FileSelect flag (PDF 1.4) is set, the field functions as a file-select control. In
this case, the field’s text represents the pathname of a file whose contents are to be
submitted as the field’s value:
• For fields submitted in HTML Form format, the submission uses the MIME
content type
multipart/form-data, as described in Internet RFC 2045, Multi-
purpose
Internet Mail Extensions (MIME), Part One: Format of Internet Message
Bodies (see the Bibliography).
• For Forms Data Format (FDF) submission, the value of the V entry in the FDF
field dictionary (see “FDF Fields” on page 676) is a file specification (Section
3.10, “File Specifications”) identifying the selected file.
• XML format is not supported for file-select controls; therefore, no value is sub-
mitted in this case.
Besides the usual entries common to all fields (see Table 8.65 on page 637) and to
fields containing variable text (see Table 8.67), the field dictionary for a text field
can contain the additional entry shown in Table 8.74.
TABLE 8.74 Additional entry specific to a text field
Example 8.16 shows the object definitions for a typical text field.
KEY TYPE VALUE
MaxLen
integer (Optional; inheritable) The maximum length of the field’s text, in characters.
Interactive FormsSECTION 8.6
655
Example 8.16
6 0 obj
<< /FT /Tx
/Ff … % Set Multiline flag
/T (Silly prose)
/DA (0 0 1 rg /Ti 12 Tf)
/V (The quick brown fox ate the lazy mouse)
/AP << /N 5 0 R >>
>>
endobj
5 0 obj
<< /Resources 21 0 R
/Length 172
>>
stream
/Tx BMC
q
BT
001rg
/Ti 12 Tf
1 0 0 1 100 100 Tm
00Td
(The quick brown fox ) Tj
0 13 Td
(ate the lazy mouse.) Tj
ET
Q
EMC
endstream
endobj
Interactive FeaturesCHAPTER 8
656
Choice Fields
A choice field (field type Ch) contains several text items, one or more of which
may be selected as the field value. The items may be presented to the user in
either of two forms:
• A scrollable list box
• A combo box consisting of a drop-down list optionally accompanied by an edit-
able text box in which the user can type a value other than the predefined
choices
TABLE 8.75 Field flags specific to choice fields
The various types of choice fields are distinguished by flags in the Ff entry, as
shown in Table 8.75. Table 8.76 shows the field dictionary entries specific to
choice fields.
BIT POSITION NAME MEANING
18 Combo If set, the field is a combo box; if clear, the field is a list box.
19 Edit If set, the combo box includes an editable text box as well as a drop-
down list; if clear, it includes only a drop-down list. This flag is mean-
ingful only if the Combo flag is set.
20 Sort If set, the field’s option items should be sorted alphabetically. This flag
is intended for use by form authoring tools, not by PDF viewer appli-
cations. Viewers should simply display the options in the order in
which they occur in the
Opt array (see Table 8.76).
22 MultiSelect (PDF 1.4) If set, more than one of the field’s option items may be se-
lected simultaneously; if clear, no more than one item at a time may be
selected.
23 DoNotSpellCheck (PDF 1.4) If set, text entered in the field is not spell-checked. This flag
is meaningful only if the Combo and Edit flags are both set.
27 CommitOnSelChange (PDF 1.5) If set, the new value is committed as soon as a selection is
made with the pointing device. This option enables applications to
perform an action once a selection is made, without requiring the user
to exit the field. If clear, the new value is not committed until the user
exits the field.
Interactive FormsSECTION 8.6
657
TABLE 8.76 Additional entries specific to a choice field
The Opt array specifies the list of options in the choice field, each of which is rep-
resented by a text string to be displayed on the screen. Each element of the
Opt
array contains either this text string by itself or a two-element array, whose sec-
ond element is the text string and whose first element is a text string representing
the export value to be used when exporting interactive form field data from the
document.
The field dictionary’s
V (value) entry (see Table 8.65 on page 637) identifies the
item or items currently selected in the choice field. If the field does not allow mul-
tiple selection—that is, if the MultiSelect flag (PDF 1.4) is not set—or if multiple
selection is supported but only one item is currently selected,
V is a text string
representing the name of the selected item, as given in the field dictionary’s
Opt
array. If multiple items are selected, V is an array of such strings. (For items repre-
sented in the
Opt array by a two-element array, the name string is the second of
the two array elements.) The default value of
V is null, indicating that no item is
currently selected.
Example 8.17 shows a typical choice field definition.
KEY TYPE VALUE
Opt
array (Optional) An array of options to be presented to the user. Each element of the array is
either a text string representing one of the available options or an array consisting of two
text strings: the option’s export value and the text to be displayed as the name of the op-
tion (see implementation note 121 in Appendix H).
If this entry is not present, no choices should be presented to the user.
TI
integer (Optional) For scrollable list boxes, the top index (the index in the Opt array of the first
option visible in the list). Default value: 0.
I
array (Sometimes required, otherwise optional; PDF 1.4) For choice fields that allow multiple
selection (MultiSelect flag set), an array of integers, sorted in ascending order, represent-
ing the zero-based indices in the
Opt array of the currently selected option items. This
entry is required when two or more elements in the
Opt array have different names but
the same export value or when the value of the choice field is an array. In other cases, the
entry is permitted but not required. If the items identified by this entry differ from those
in the
V entry of the field dictionary (see below), the V entry takes precedence.
Interactive FeaturesCHAPTER 8
658
Example 8.17
<< /FT /Ch
/Ff …
/T (Body Color)
/V (Blue)
/Opt [ (Red)
(My favorite color)
(Blue)
]
>>
Signature Fields
A signature field (PDF 1.3) is a form field that contains a digital signature (see
Section 8.7, “Digital Signatures”). The field dictionary representing a signature
field may contain the additional entries listed in Table 8.77, as well as the stan-
dard entries described in Table 8.65. The field type (
FT) is Sig, and the field value
(
V) is a signature dictionary containing the signature and specifying various at-
tributes of the signature field (see Table 8.98).
Filling in (signing) the signature field entails updating at least the
V entry and
usually also the
AP entry of the associated widget annotation. Exporting a signa-
ture field typically exports the
T, V, and AP entries.
Like any other field, a signature field may actually be described by a widget anno-
tation dictionary containing entries pertaining to an annotation as well as a field
(see “Widget Annotations” on page 603). The annotation rectangle (
Rect) in such
a dictionary gives the position of the field on its page. Signature fields that are not
intended to be visible should have an annotation rectangle that has zero height
and width.
The appearance dictionary (
AP) of a signature field’s widget annotation defines
the field’s visual appearance on the page (see Section 8.4.4, “Appearance
Streams”). Information about how Acrobat handles digital signature appearances
is in the technical note Digital Signature Appearances (see the Bibliography).
Interactive FormsSECTION 8.6
659
TABLE 8.77 Additional entries specific to a signature field
The value of the SV entry in the field dictionary is a seed value dictionary whose
entries (see Table 8.79
) provide constraining information that is to be used at the
time the signature is applied.
Its Ff entry specifies whether the other entries in the
dictionary are required to be honored or whether they are merely recommenda-
tions.
Note: The seed value dictionary may include seed values for private entries belong-
ing to multiple handlers. A given handler should use only those entries that are per-
tinent to itself and ignore the others.
TABLE 8.78 Entries in a signature field lock dictionary
KEY TYPE VALUE
Lock
dictionary (Optional; must be an indirect reference; PDF 1.5) A signature field lock dictionary
that specifies a set of form fields to be locked when this signature field is signed.
Table 8.78 lists the entries in this dictionary.
SV
dictionary (Optional; must be an indirect reference; PDF 1.5) A seed value dictionary (see Table
8.79) containing information that constrains the properties of a signature that is ap-
plied to this field.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
SigFieldLock for a signature field lock dictionary.
Action
name (Required) A name which, in conjunction with Fields, indicates the set of fields that
should be locked. Valid values are:
All All fields in the document
Include All fields specified in Fields
Exclude
All fields except those specified in Fields
Fields
array (Required if the value of Action is Include or Exclude) An array of strings containing
field names.
Interactive FeaturesCHAPTER 8
660
TABLE 8.79 Entries in a signature field seed value dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
SV for a seed value dictionary.
Filter
name (Optional) The signature handler to be used to sign the signature field.
SubFilter
array (Optional) An array of names indicating acceptable encodings to use when
signing. The first name in the array that matches an encoding supported by the
signature handler should be the encoding actually that is used for signing.
V
integer (Optional) The minimum required version number of the signature handler to
be used to sign the signature field.
Cert
dictionary (Optional) A certificate seed value dictionary (see Table 8.80) containing infor-
mation about the certificate to be used when signing.
Reasons
array (Optional) An array of strings that specifying possible reasons for signing a
document.
MDP
dictionary (Optional; PDF 1.6) A dictionary containing a single entry whose key is P and
whose value is an integer between 0 and 3. A value of 0 defines the signature as
an ordinary (non-author) signature (see Section 8.7, “Digital Signatures”). The
values 1 through 3 are used for author signatures and correspond to the value
of
P in a DocMDP transform parameters dictionary (see Table 8.100).
If this entry is not present or does not contain a
P entry, no rules are defined
regarding the type of signature or its permissions.
TimeStamp
dictionary (Optional; PDF 1.6) A time stamp dictionary containing two entries:
URL A string specifying the URL of a time-stamping server, providing
a time stamp that is compliant with RFC 3161, Internet X.509 Pub-
lic Key Infrastructure Time-Stamp Protocol (see the Bibliography).
Ff An integer whose value is 1 (the signature is required to have a
time stamp) or 0 (the signature is not required to have a time
stamp). Default value: 0.
LegalAttestation
array (Optional; PDF 1.6) An array of strings specifying possible legal attestations
(see Section 8.7.4, “Legal Content Attestations”).
Interactive FormsSECTION 8.6
661
TABLE 8.80 Entries in a certificate seed value dictionary
Ff
integer (Optional) A set of bit flags specifying the interpretation of specific entries in
this dictionary. A value of 1 for the flag means that a signer is required to use
only the specified values for the entry. A value of 0 means that other values are
permissible. Bit positions are 1 (
Filter); 2 (SubFilter); 3 (V); 4 (Reasons); 5
(
LegalAttestation). Default value: 0.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
SVCert for a certificate seed value dictionary.
Subject
array (Optional) An array of strings containing DER-encoded X.509v3 certificates that are
acceptable for signing. X.509v3 certificates are described in RFC 3280, Internet X.509
Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile (see
the Bibliography).
Issuer
array (Optional) An array of strings containing DER-encoded X.509v3 certificates of ac-
ceptable issuers. If the signer’s certificate chains up to any of the specified issuers (ei-
ther directly or indirectly), the certificate is considered acceptable for signing.
OID
array (Optional) An array of strings that contain Object Identifiers (OIDs) of the certificate
policies that must be present in the signing certificate. An example of such a string is
(2.16.840.1.113733.1.7.1.1). This field is only applicable if the value of Issuer is not
empty. The certificate policies extension is described in RFC 3280 (see the Bibliogra-
phy).
URL
string (Optional) A URL that can be used to enroll for a new credential if a matching creden-
tial is not found.
Ff
integer (Optional) A set of bit flags specifying the interpretation of specific entries in this dic-
tionary. A value of 1 for the flag means that a signer is required to use only the speci-
fied values for the entry. A value of 0 means that other values are permissible. Bit
positions are 1 (
Subject); 2 (Issuer); 3 (OID).
Default value: 0.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
662
8.6.4 Form Actions
Interactive forms support four special types of actions in addition to those de-
scribed in Section 8.5.3, “Action Types”:
• Submit-form actions transmit the names and values of selected interactive form
fields to a specified uniform resource locator (URL), presumably the address of
a Web server that will process them and send back a response.
• Reset-form actions reset selected interactive form fields to their default values.
• Import-data actions import Forms Data Format (FDF) data into the document’s
interactive form from a specified file.
• JavaScript actions (PDF 1.3) cause a script to be compiled and executed by the
JavaScript interpreter.
Submit-Form Actions
A submit-form action transmits the names and values of selected interactive form
fields to a specified uniform resource locator (URL), presumably the address of a
Web server that will process them and send back a response. Table 8.81 shows the
action dictionary entries specific to this type of action.
The value of the action dictionary’s
Flags entry is an unsigned 32-bit integer con-
taining flags specifying various characteristics of the action. Bit positions within
the flag word are numbered from 1 (low-order) to 32 (high-order). Table 8.82
shows the meanings of the flags; all undefined flag bits are reserved and must be
set to 0.
TABLE 8.81 Additional entries specific to a submit-form action
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be
SubmitForm for a submit-form action.
F
file specification (Required) A URL file specification (see Section 3.10.4, “URL Speci-
fications”) giving the uniform resource locator (URL) of the script
at the Web server that will process the submission.
Interactive FormsSECTION 8.6
663
TABLE 8.82 Flags for submit-form actions
Fields
array (Optional) An array identifying which fields to include in the sub-
mission or which to exclude, depending on the setting of the
Include/Exclude flag in the
Flags entry (see Table 8.82). Each ele-
ment of the array is either an indirect reference to a field dictionary
or (PDF 1.3) a string representing the fully qualified name of a field.
Elements of both kinds may be mixed in the same array.
If this entry is omitted, the Include/Exclude flag is ignored, and all
fields in the document’s interactive form are submitted except those
whose NoExport flag (see Table 8.66 on page 638) is set. (Fields
with no values may also be excluded, depending on the setting of
the IncludeNoValueFields flag; see Table 8.82.) See the text follow-
ing Table 8.82 for further discussion.
Flags
integer (Optional; inheritable) A set of flags specifying various characteris-
tics of the action (see Table 8.82). Default value: 0.
BIT POSITION NAME MEANING
1 Include/Exclude If clear, the Fields array (see Table 8.81) specifies which fields to
include in the submission. (All descendants of the specified fields in
the field hierarchy are submitted as well.)
If set, the
Fields array tells which fields to exclude. All fields in the
document’s interactive form are submitted except those listed in the
Fields array and those whose NoExport flag (see Table 8.66 on page
638) is set.
2 IncludeNoValueFields If set, all fields designated by the
Fields array and the Include/
Exclude flag are submitted, regardless of whether they have a value
(
V entry in the field dictionary). For fields without a value, only the
field name is transmitted.
If clear, fields without a value are not submitted.
3 ExportFormat Meaningful only if the SubmitPDF and XFDF flags are clear. If set,
field names and values are submitted in HTML Form format. If
clear, they are submitted in Forms Data Format (FDF); see Section
8.6.6, “Forms Data Format.”
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
664
4 GetMethod If set, field names and values are submitted using an HTTP GET
request. If clear, they are submitted using a POST request. This flag
is meaningful only when the ExportFormat flag is set; if ExportFor-
mat is clear, this flag must also be clear.
5 SubmitCoordinates If set, the coordinates of the mouse click that caused the submit-
form action are transmitted as part of the form data. The coordinate
values are relative to the upper-left corner of the field’s widget anno-
tation rectangle. They are represented in the data in the format
name.x=xval&name.y=yval
where name is the field’s mapping name (TM in the field dictionary)
if present; otherwise,
name is the field name. If the value of the TM
entry is a single space character, both the name and the dot follow-
ing it are suppressed, resulting in the format
x=xval&y=yval
This flag is meaningful only when the ExportFormat flag is set. If
ExportFormat is clear, this flag must also be clear.
6 XFDF (PDF 1.4) Meaningful only if the SubmitPDF flags are clear. If set,
field names and values are submitted as XFDF.
7 IncludeAppendSaves (PDF 1.4) Meaningful only when the form is being submitted in
Forms Data Format (that is, when both the XFDF and ExportFor-
mat flags are clear). If set, the submitted FDF file includes the con-
tents of all incremental updates to the underlying PDF document,
as contained in the
Differences entry in the FDF dictionary (see
Table 8.89 on page 673). If clear, the incremental updates are not in-
cluded.
8 IncludeAnnotations (PDF 1.4) Meaningful only when the form is being submitted in
Forms Data Format (that is, when both the XFDF and ExportFor-
mat flags are clear). If set, the submitted FDF file includes all mark-
up annotations in the underlying PDF document (see “Markup
Annotations” on page 581). If clear, markup annotations are not in-
cluded.
9SubmitPDF(PDF 1.4) If set, the document is submitted as PDF, using the
MIME content type
application/pdf (described in Internet RFC
2045, Multipurpose Internet Mail Extensions (MIME), Part One:
Format of Internet Message Bodies; see the Bibliography). If set, all
other flags are ignored except GetMethod.
BIT POSITION NAME MEANING
Interactive FormsSECTION 8.6
665
The set of fields whose names and values are to be submitted is defined by the
Fields array in the action dictionary (Table 8.81) together with the Include/
Exclude and IncludeNoValueFields flags in the
Flags entry (Table 8.82). Each ele-
ment of the
Fields array identifies an interactive form field, either by an indirect
reference to its field dictionary or (PDF 1.3) by its fully qualified field name (see
“Field Names” on page 638). If the Include/Exclude flag is clear, the submission
consists of all fields listed in the
Fields array, along with any descendants of those
fields in the field hierarchy. If the Include/Exclude flag is set, the submission con-
sists of all fields in the document’s interactive form except those listed in the
Fields array.
10 CanonicalFormat (PDF 1.4) If set, any submitted field values representing dates are
converted to the standard format described in Section 3.8.3,
“Dates.” (The interpretation of a form field as a date is not specified
explicitly in the field itself but only in the JavaScript code that pro-
cesses it.)
11 ExclNonUserAnnots (PDF 1.4) Meaningful only when the form is being submitted in
Forms Data Format (that is, when both the XFDF and
ExportFormat flags are clear) and the IncludeAnnotations flag is
set. If set, it includes only those markup annotations whose
T entry
(see Table 8.17) matches the name of the current user, as deter-
mined by the remote server to which the form is being submitted.
(The
T entry for markup annotations specifies the text label to be
displayed in the title bar of the annotation’s pop-up window and is
assumed to represent the name of the user authoring the annota-
tion.) This allows multiple users to collaborate in annotating a sin-
gle remote PDF document without affecting one another’s
annotations.
12 ExclFKey (PDF 1.4) Meaningful only when the form is being submitted in
Forms Data Format (that is, when both the XFDF and ExportFor-
mat flags are clear). If set, the submitted FDF excludes the
F entry.
14 EmbedForm (PDF 1.5) Meaningful only when the form is being submitted in
Forms Data Format (that is, when both the XFDF and ExportFor-
mat flags are clear). If set, the
F entry of the submitted FDF is a file
specification containing an embedded file stream representing the
PDF file from which the FDF is being submitted.
BIT POSITION NAME MEANING
Interactive FeaturesCHAPTER 8
666
Note: The NoExport flag in the field dictionary’s Ff entry (see Table 8.65 on page
637 and Table 8.66 on page 638) takes precedence over the action’s
Fields array and
Include/Exclude flag. Fields whose NoExport flag is set are never included in a
submit-form action.
Field names and values may be submitted in any of the following formats, de-
pending on the settings of the action’s ExportFormat, SubmitPDF, and XFDF
flags (see the Bibliography for references):
• HTML Form format (described in the HTML 4.01 Specification)
• Forms Data Format (FDF), which is described in Section 8.6.6, “Forms Data
Format”; see also implementation note 122 in Appendix H.
• XFDF, a version of FDF based on XML. XFDF is described in the Adobe tech-
nical note XML Forms Data Format Specification, Version 2.0. XML is described
in the W3C document Extensible Markup Language (XML) 1.1)
• PDF (in this case, the entire document is submitted rather than individual
fields and values).
The name submitted for each field is its fully qualified name (see “Field Names”
on page 638), and the value is specified by the
V entry in its field dictionary.
Note: For pushbutton fields submitted in FDF, the value submitted is that of the
AP
entry in the field’s widget annotation dictionary. If the submit-form action dictio-
nary contains no
Fields entry, such pushbutton fields are not submitted at all.
Fields with no value (that is, whose field dictionary does not contain a
V entry)
are ordinarily not included in the submission. The submit-form action’s Include-
NoValueFields flag can override this behavior. If this flag is set, such valueless
fields are included in the submission by name only, with no associated value.
Reset-Form Actions
A reset-form action resets selected interactive form fields to their default values;
that is, it sets the value of the
V entry in the field dictionary to that of the DV entry
(see Table 8.65 on page 637). If no default value is defined for a field, its
V entry is
removed. For fields that can have no value (such as pushbuttons), the action has
no effect. Table 8.83 shows the action dictionary entries specific to this type of
action.
Interactive FormsSECTION 8.6
667
The value of the action dictionary’s Flags entry is an unsigned 32-bit integer con-
taining flags specifying various characteristics of the action. Bit positions within
the flag word are numbered from 1 (low-order) to 32 (high-order). At the time of
publication, only one flag is defined for this type of action; Table 8.84 shows its
meaning. All undefined flag bits are reserved and must be set to 0.
TABLE 8.83 Additional entries specific to a reset-form action
TABLE 8.84 Flag for reset-form actions
Import-Data Actions
An import-data action imports Forms Data Format (FDF) data into the docu-
ment’s interactive form from a specified file (see Section 8.6.6, “Forms Data For-
mat”). Table 8.85 shows the action dictionary entries specific to this type of action.
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be
ResetForm for a reset-form action.
Fields
array (Optional) An array identifying which fields to reset or which to exclude
from resetting, depending on the setting of the Include/Exclude flag in
the
Flags entry (see Table 8.84). Each element of the array is either an in-
direct reference to a field dictionary or (PDF 1.3) a string representing
the fully qualified name of a field. Elements of both kinds may be mixed
in the same array.
If this entry is omitted, the Include/Exclude flag is ignored; all fields in
the document’s interactive form are reset.
Flags
integer (Optional; inheritable) A set of flags specifying various characteristics of
the action (see Table 8.84). Default value: 0.
BIT POSITION NAME MEANING
1 Include/Exclude If clear, the Fields array (see Table 8.83) specifies which fields to reset.
(All descendants of the specified fields in the field hierarchy are reset as
well.) If set, the
Fields array indicates which fields to exclude from reset-
ting; that is, all fields in the document’s interactive form are reset except
those listed in the
Fields array.
Interactive FeaturesCHAPTER 8
668
TABLE 8.85 Additional entries specific to an import-data action
JavaScript Actions
A JavaScript action (PDF 1.3) causes a script to be compiled and executed by the
JavaScript interpreter. Depending on the nature of the script, various interactive
form fields in the document may update their values or change their visual ap-
pearances. Netscape Communications Corporation’s Client-Side JavaScript Refer-
ence and the Adobe Acrobat JavaScript Scripting Reference (see the Bibliography)
give details on the contents and effects of JavaScript scripts. Table 8.86 shows the
action dictionary entries specific to this type of action.
TABLE 8.86 Additional entries specific to a JavaScript action
To support the use of parameterized function calls in JavaScript scripts, the
JavaScript entry in a PDF document’s name dictionary (see Section 3.6.3, “Name
Dictionary”) can contain a name tree that maps name strings to document-level
JavaScript actions. When the document is opened, all of the actions in this name
tree are executed, defining JavaScript functions for use by other scripts in the
document.
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be ImportData
for an import-data action.
F
file specification (Required) The FDF file from which to import the data. (See implementation
notes 123 and 124 in Appendix H.)
KEY TYPE VALUE
S
name (Required) The type of action that this dictionary describes; must be JavaScript
for a JavaScript action.
JS
string or stream (Required) A string or stream containing the JavaScript script to be executed.
Note:
PDFDocEncoding or Unicode encoding (the latter identified by the Unicode
prefix
U
+
FEFF) is used to encode the contents of the string or stream. (See imple-
mentation note 125 in Appendix H.)
Interactive FormsSECTION 8.6
669
Note: The name strings associated with individual JavaScript actions in the name
dictionary serve merely as a convenient means for organizing and packaging scripts.
The names are arbitrary and need not bear any relation to the JavaScript name
space.
8.6.5 Named Pages
The optional Pages entry (PDF 1.3) in a document’s name dictionary (see Section
3.6.3, “Name Dictionary”) contains a name tree that maps name strings to indi-
vidual pages within the document. Naming a page allows it to be referenced in
two different ways:
• An import-data action can add the named page to the document into which
FDF is being imported, either as a page or as a button appearance.
• A script executed by a JavaScript action can add the named page to the current
document as a regular page.
A named page that is to be visible to the user should be left in the page tree (see
Section 3.6.2, “Page Tree”), and there should be a reference to it in the appropriate
leaf node of the name dictionary’s
Pages tree. If the page is not to be displayed by
the viewer application, it should be referenced from the name dictionary’s
Templates tree instead. Such invisible pages should have an object type of
Template rather than Page and should have no Parent or B entry (see Table 3.27
on page 119). Regardless of whether the page is named in the
Pages or Templates
tree or is added to a document by an import-data or JavaScript action, the new
copy is not itself named.
8.6.6 Forms Data Format
This section describes Forms Data Format (FDF), the file format used for inter-
active form data (PDF 1.2). FDF is used when submitting form data to a server,
receiving the response, and incorporating it into the interactive form. It can also
be used to export form data to stand-alone files that can be stored, transmitted
electronically, and imported back into the corresponding PDF interactive form.
In addition, beginning in PDF 1.3, FDF can be used to define a container for an-
notations that are separate from the PDF document to which they apply.
Interactive FeaturesCHAPTER 8
670
FDF is based on PDF; it uses the same syntax (see Section 3.1, “Lexical Conven-
tions”) and basic object types (Section 3.2, “Objects”), and has essentially the
same file structure (Section 3.4, “File Structure”). However, it differs from PDF in
the following ways:
• The cross-reference table (Section 3.4.3, “Cross-Reference Table”) is optional.
• FDF files cannot be updated (see Section 3.4.5, “Incremental Updates”). Ob-
jects can only be of generation 0, and no two objects can have the same object
number.
• The document structure is much simpler than PDF, since the body of an FDF
document consists of only one required object.
• The length of a stream may not be specified by an indirect object.
FDF uses the MIME content type
application/vnd.fdf. On the Windows and
UNIX platforms, FDF files have the extension
.fdf; on Mac OS, they have file type
'FDF '.
FDF File Structure
An FDF file is structured in essentially the same way as a PDF file but contains
only those elements required for the export and import of interactive form and
annotation data. It consists of three required elements and one optional element
(see Figure 8.9):
• A one-line header identifying the version number of the PDF specification to
which the file conforms
• A body containing the objects that make up the content of the file
• An optional cross-reference table containing information about the objects in
the file
• A trailer giving the location of various objects within the body of the file
Interactive FormsSECTION 8.6
671
FIGURE 8.9 FDF file structure
FDF Header
The first line of an FDF file is a header, originally intended to identify the version
of the PDF specification to which the file conforms. However, for historical rea-
sons, this version number is now frozen and must read
%FDF1.2
The true version number is now given by the Version entry in the FDF catalog
dictionary (see “FDF Catalog,” below; see also implementation note 126 in Ap-
pendix H).
FDF Body
The body of an FDF file consists of a sequence of indirect objects representing the
file’s catalog (see “FDF Catalog” on page 672) together with any additional objects
Header
Body
Cross-reference
table (optional)
Trailer
Interactive FeaturesCHAPTER 8
672
that the catalog may reference. The objects are of the same basic types described
in Section 3.2, “Objects.” Just as in PDF, objects in FDF can be direct or indirect.
FDF Trailer
The trailer of an FDF file enables an application reading the file to find significant
objects quickly within the body of the file. The last line of the file contains only
the end-of-file marker,
%%EOF. This marker is preceded by the FDF trailer dictio-
nary, consisting of the keyword
trailer followed by a series of one or more key-
value pairs enclosed in double angle brackets (
<<…>>). The only required key is
Root, whose value is an indirect reference to the file’s catalog dictionary (see Table
8.87). The trailer may optionally contain additional entries for objects that are
referenced from within the catalog.
TABLE 8.87 Entry in the FDF trailer dictionary
Thus, the trailer has the overall structure
trailer
<< /Root c 0 R
key
2
value
2
…
key
n
value
n
>>
%%EOF
where c is the object number of the file’s catalog dictionary.
FDF Catalog
The root node of an FDF file’s object hierarchy is the catalog dictionary, located
by means of the
Root entry in the file’s trailer dictionary (see “FDF Trailer,”
above). As shown in Table 8.88, the only required entry in the catalog is
FDF; its
value is an FDF dictionary (Table 8.89), which in turn contains references to other
KEY TYPE VALUE
Root
dictionary (Required; must be an indirect reference) The catalog object for this FDF file (see
“FDF Catalog,” below).
Interactive FormsSECTION 8.6
673
objects describing the file’s contents. The catalog may also contain an optional
Version entry identifying the version of the PDF specification to which this FDF
file conforms.
TABLE 8.88 Entries in the FDF catalog dictionary
TABLE 8.89 Entries in the FDF dictionary
KEY TYPE VALUE
Version
name (Optional; PDF 1.4) The version of the PDF specification to which
this FDF file conforms (for example,
1.4) if later than the version
specified in the file’s header (see “FDF Header” on page 671). If the
header specifies a later version, or if this entry is absent, the docu-
ment conforms to the version specified in the header.
Note: The value of this entry is a name object, not a number, and
therefore must be preceded by a slash character (
/) when written in
the FDF file (for example,
/1.4).
FDF
dictionary (Required) The FDF dictionary for this file (see Table 8.89).
Sig
dictionary (Optional; PDF 1.5) A signature dictionary indicating that the docu-
ment is signed using an object digest (see Section 8.7, “Digital Sig-
natures”). This dictionary must contain a signature reference
dictionary whose
Data entry is an indirect reference to the catalog
and whose
TransformMethod entry is Identity.
KEY TYPE VALUE
F
file specification (Optional) The source file or target file: the PDF document file that
this FDF file was exported from or is intended to be imported into.
ID
array (Optional) An array of two strings constituting a file identifier (see
Section 10.3, “File Identifiers”) for the source or target file designat-
ed by
F, taken from the ID entry in the file’s trailer dictionary (see
Section 3.4.4, “File Trailer”).
Fields
array (Optional) An array of FDF field dictionaries (see “FDF Fields” on
page 676) describing the root fields (those with no ancestors in the
field hierarchy) to be exported or imported. This entry and the
Pages entry may not both be present.
Interactive FeaturesCHAPTER 8
674
Status
string (Optional) A status string to be displayed indicating the result of an
action, typically a submit-form action (see “Submit-Form Actions”
on page 662). The string is encoded with
PDFDocEncoding. (See
implementation note 127 in Appendix H.) This entry and the
Pages
entry may not both be present.
Pages
array (Optional; PDF 1.3) An array of FDF page dictionaries (see “FDF
Pages” on page 679) describing new pages to be added to a PDF
target document. The
Fields and Status entries may not be present
together with this entry.
Encoding
name (Optional; PDF 1.3) The encoding to be used for any FDF field
value or option (
V or Opt in the field dictionary; see Table 8.92 on
page 677) or field name that is a string and does not begin with the
Unicode prefix
U+FEFF. (See implementation note 128 in Appendix
H.) Default value:
PDFDocEncoding.
Annots
array (Optional; PDF 1.3) An array of FDF annotation dictionaries (see
“FDF Annotation Dictionaries” on page 681). The array can include
annotations of any of the standard types listed in Table 8.16 on page
580 except
Link, Movie, Widget, PrinterMark, Screen, and TrapNet.
Differences
stream (Optional; PDF 1.4) A stream containing all the bytes in all incre-
mental updates made to the underlying PDF document since it was
opened (see Section 3.4.5, “Incremental Updates”). If a submit-form
action submitting the document to a remote server as FDF has its
IncludeAppendSaves flag set (see “Submit-Form Actions” on page
662), the contents of this stream are included in the submission.
This allows any digital signatures (see Section 8.7, “Digital Signa-
tures) to be transmitted to the server. An incremental update is au-
tomatically performed just before the submission takes place, in
order to capture all changes made to the document. Note that the
submission always includes the full set of incremental updates back
to the time the document was first opened, even if some of them
may already have been included in intervening submissions.
Note: Although a
Fields or Annots entry (or both) may be present
along with
Differences, there is no guarantee that their contents will
be consistent with it. In particular, if
Differences contains a digital sig-
nature, only the values of the form fields given in the
Differences
stream can be considered trustworthy under that signature.
KEY TYPE VALUE
Interactive FormsSECTION 8.6
675
Embedded FDF files specified in the FDF dictionary’s EmbeddedFDFs entry may
optionally be encrypted. Besides the usual entries for an embedded file stream,
the stream dictionary representing such an encrypted FDF file must contain the
additional entry shown in Table 8.90 to identify the revision number of the FDF
encryption algorithm used to encrypt the file. Although the FDF encryption
mechanism is separate from the one for PDF file encryption described in Section
3.5, “Encryption,” revision 1 (the only one defined at the time of publication) uses
a similar RC4 encryption algorithm based on a 40-bit encryption key. The key is
computed by means of an MD5 hash, using a padded user-supplied password as
input. The computation is identical to steps 1 and 2 of Algorithm 3.2 on page 100;
the first 5 bytes of the result are the encryption key for the embedded FDF file.
TABLE 8.90 Additional entry in an embedded file stream dictionary for an encrypted
FDF file
The JavaScript entry in the FDF dictionary holds a JavaScript dictionary contain-
ing JavaScript scripts that are defined globally at the document level, rather than
associated with individual fields. The dictionary can contain scripts defining Jav-
aScript functions for use by other scripts in the document, as well as scripts to be
executed immediately before and after the FDF file is imported. Table 8.91 shows
the contents of this dictionary.
Target
string (Optional; PDF 1.4) The name of a browser frame in which the un-
derlying PDF document is to be opened. This mimics the behavior
of the
target attribute in HTML <href> tags.
EmbeddedFDFs
array (Optional; PDF 1.4) An array of file specifications (see Section 3.10,
“File Specifications”) representing other FDF files embedded within
this one (Section 3.10.3, “Embedded File Streams”).
JavaScript
dictionary (Optional; PDF 1.4) A JavaScript dictionary (see Table 8.91) defin-
ing document-level JavaScript scripts.
KEY TYPE VALUE
EncryptionRevision
integer (Required if the FDF file is encrypted; PDF 1.4) The revision number of the
FDF encryption algorithm used to encrypt the file. The only valid value
defined at the time of publication is 1.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
676
TABLE 8.91 Entries in the JavaScript dictionary
FDF Fields
Each field in an FDF file is described by an FDF field dictionary. Table 8.92 shows
the contents of this type of dictionary. Most of the entries have the same form and
meaning as the corresponding entries in a field dictionary (Table 8.65 on page
637, Table 8.67 on page 640, Table 8.74 on page 654, and Table 8.76 on page 657)
or a widget annotation dictionary (Table 8.11 on page 570 and Table 8.35 on page
603). Unless otherwise indicated in the table, importing a field causes the values
of the entries in the FDF field dictionary to replace those of the corresponding
entries in the field with the same fully qualified name in the target document.
(See implementation notes 129–134 in Appendix H.)
KEY TYPE VALUE
Before
string or stream (Optional) A string or stream containing a JavaScript script to be executed
just before the FDF file is imported.
After
string or stream (Optional) A string or stream containing a JavaScript script to be executed
just after the FDF file is imported.
AfterPermsReady
string or stream (Optional; PDF 1.6) A string or stream containing a JavaScript script to be
executed after the FDF file is imported and the usage rights in the PDF
document have been determined (see “UR” on page 692).
Note: Verification of usage rights requires the entire file to be present, in
which case this script defers execution until that requirement is met.
Doc
array (Optional) An array defining additional JavaScript scripts to be added to
those defined in the
JavaScript entry of the document’s name dictionary
(see Section 3.6.3, “Name Dictionary”). The array contains an even num-
ber of elements, organized in pairs. The first element of each pair is a
name and the second is a string or stream defining the script correspond-
ing to that name. Each of the defined scripts is added to those already de-
fined in the name dictionary and then executed before the script defined
in the
Before entry is executed. As described in “JavaScript Actions” on
page 668, these scripts are used to define JavaScript functions for use by
other scripts in the document.
Interactive FormsSECTION 8.6
677
TABLE 8.92 Entries in an FDF field dictionary
KEY TYPE VALUE
Kids
array (Optional) An array containing the immediate children of this field.
Note: Unlike the children of fields in a PDF file, which must be specified as indirect
object references, those of an FDF field may be either direct or indirect objects.
T
text string (Required) The partial field name (see “Field Names” on page 638).
V
(various) (Optional) The field’s value, whose format varies depending on the field type; see
the descriptions of individual field types in Section 8.6.3 for further information.
Ff
integer (Optional) A set of flags specifying various characteristics of the field (see Table 8.66
on page 638, Table 8.71 on page 648, Table 8.73 on page 653, and Table 8.75 on page
656). When imported into an interactive form, the value of this entry replaces that
of the
Ff entry in the form’s corresponding field dictionary. If this field is present,
the
SetFf and ClrFf entries, if any, are ignored.
SetFf
integer (Optional) A set of flags to be set (turned on) in the Ff entry of the form’s cor-
responding field dictionary. Bits equal to 1 in
SetFf cause the corresponding bits in
Ff to be set to 1. This entry is ignored if an Ff entry is present in the FDF field
dictionary.
ClrFf
integer (Optional) A set of flags to be cleared (turned off) in the Ff entry of the form’s corre-
sponding field dictionary. Bits equal to 1 in
ClrFf cause the corresponding bits in Ff
to be set to 0. If a SetFf entry is also present in the FDF field dictionary, it is applied
before this entry. This entry is ignored if an
Ff entry is present in the FDF field dic-
tionary.
F
integer (Optional) A set of flags specifying various characteristics of the field’s widget anno-
tation (see Section 8.4.2, “Annotation Flags”). When imported into an interactive
form, the value of this entry replaces that of the
F entry in the form’s corresponding
annotation dictionary. If this field is present, the
SetF and ClrF entries, if any, are
ignored.
SetF
integer (Optional) A set of flags to be set (turned on) in the F entry of the form’s corre-
sponding widget annotation dictionary. Bits equal to 1 in
SetF cause the corre-
sponding bits in
F to be set to 1. This entry is ignored if an F entry is present in the
FDF field dictionary.
Interactive FeaturesCHAPTER 8
678
In an FDF field dictionary representing a button field, the optional IF entry holds
an icon fit dictionary (PDF 1.3) specifying how to display the button’s icon within
the annotation rectangle of its widget annotation. Table 8.93 shows the contents
of this type of dictionary.
ClrF
integer (Optional) A set of flags to be cleared (turned off) in the F entry of the form’s corre-
sponding widget annotation dictionary. Bits equal to 1 in
ClrF cause the corre-
sponding bits in
F to be set to 0. If a SetF entry is also present in the FDF field
dictionary, it is applied before this entry. This entry is ignored if an
F entry is
present in the FDF field dictionary.
AP
dictionary (Optional) An appearance dictionary specifying the appearance of a pushbutton
field (see “Pushbuttons” on page 648). The appearance dictionary’s contents are as
shown in Table 8.15 on page 579, except that the values of the
N, R, and D entries
must all be streams.
APRef
dictionary (Optional; PDF 1.3) A dictionary holding references to external PDF files contain-
ing the pages to use for the appearances of a pushbutton field. This dictionary is
similar to an appearance dictionary (see Table 8.15 on page 579), except that the
values of the
N, R, and D entries must all be named page reference dictionaries
(Table 8.96 on page 681). This entry is ignored if an
AP entry is present.
IF
dictionary (Optional; PDF 1.3; button fields only) An icon fit dictionary (see Table 8.93) speci-
fying how to display a button field’s icon within the annotation rectangle of its wid-
get annotation.
Opt
array (Required; choice fields only) An array of options to be presented to the user. Each
element of the array can take either of two forms:
• A text string representing one of the available options
• A two-element array consisting of a text string representing one of the available
options and a default appearance string for constructing the item’s appearance
dynamically at viewing time (see “Variable Text” on page 639)
A
dictionary (Optional) An action to be performed when this field’s widget annotation is activat-
ed (see Section 8.5, “Actions”).
AA
dictionary (Optional) An additional-actions dictionary defining the field’s behavior in re-
sponse to various trigger events (see Section 8.5.2, “Trigger Events”).
RV
text string or
text stream
(Optional; PDF 1.5) A rich text string, as described in “Rich Text Strings” on page
642.
KEY TYPE VALUE
Interactive FormsSECTION 8.6
679
TABLE 8.93 Entries in an icon fit dictionary
FDF Pages
The optional Pages field in an FDF dictionary (see Table 8.89 on page 673)
contains an array of FDF page dictionaries (PDF 1.3) describing new pages to be
added to the target document. Table 8.94 shows the contents of this type of
dictionary.
KEY TYPE VALUE
SW
name (Optional) The circumstances under which the icon should be scaled inside the annota-
tion rectangle:
A Always scale.
B Scale only when the icon is bigger than the annotation rectangle.
S Scale only when the icon is smaller than the annotation rectangle.
N Never scale.
Default value:
A.
S
name (Optional) The type of scaling to use:
A Anamorphic scaling: Scale the icon to fill the annotation rectangle exactly, with-
out regard to its original aspect ratio (ratio of width to height).
P Proportional scaling: Scale the icon to fit the width or height of the annotation
rectangle while maintaining the icon’s original aspect ratio. If the required hori-
zontal and vertical scaling factors are different, use the smaller of the two, cen-
tering the icon within the annotation rectangle in the other dimension.
Default value:
P.
A
array (Optional) An array of two numbers between 0.0 and 1.0 indicating the fraction of left-
over space to allocate at the left and bottom of the icon. A value of
[0.0 0.0] positions the
icon at the bottom-left corner of the annotation rectangle. A value of
[0.5 0.5] centers it
within the rectangle. This entry is used only if the icon is scaled proportionally. Default
value:
[0.5 0.5].
FB
boolean (Optional; PDF 1.5) If true, indicates that the button appearance should be scaled to fit
fully within the bounds of the annotation without taking into consideration the line
width of the border; see implementation note 135 in Appendix H. Default value:
false.
Interactive FeaturesCHAPTER 8
680
TABLE 8.94 Entries in an FDF page dictionary
An FDF template dictionary contains information describing a named page that
serves as a template. Table 8.95 shows the contents of this type of dictionary.
TABLE 8.95 Entries in an FDF template dictionary
The names of fields imported from a template may sometimes conflict with those
of existing fields in the target document. This can occur, for example, if the same
template page is imported more than once or if two different templates have fields
with the same names. If the
Rename flag in the FDF template dictionary is true,
fields with such conflicting names are renamed to guarantee their uniqueness. If
Rename is false, the fields are not renamed; this results in multiple fields with the
same name in the target document. Each time the FDF file provides attributes for
a given field name, all fields with that name are updated. (See implementation
notes 136 and 137 in Appendix H.)
The
TRef entry in an FDF template dictionary holds a named page reference
dictionary describing the location of external templates or page elements. Table
8.96 shows the contents of this type of dictionary.
KEY TYPE VALUE
Templates
array (Required) An array of FDF template dictionaries (see Table 8.95) describing the
named pages that serve as templates on the page.
Info
dictionary (Optional) An FDF page information dictionary containing additional informa-
tion about the page. At the time of publication, no entries have been defined for
this dictionary.
KEY TYPE VALUE
TRef
dictionary (Required) A named page reference dictionary (see Table 8.96) specifying the
location of the template.
Fields
array (Optional) An array of references to FDF field dictionaries (see Table 8.92 on
page 677) describing the root fields to be imported (those with no ancestors in
the field hierarchy).
Rename
boolean (Optional) A flag specifying whether fields imported from the template may be
renamed in the event of name conflicts with existing fields; see below for further
discussion. Default value:
true.
Interactive FormsSECTION 8.6
681
TABLE 8.96 Entries in an FDF named page reference dictionary
FDF Annotation Dictionaries
Each annotation dictionary in an FDF file must have a Page entry (see Table 8.97)
indicating the page of the source document to which the annotation is attached.
TABLE 8.97 Additional entry for annotation dictionaries in an FDF file
8.6.7 XFA Forms
PDF 1.5 introduces support for interactive forms based on the Adobe XML
Forms Architecture (XFA). The
XFA entry in the interactive forms dictionary (see
Table 8.63) specifies an XFA resource, which is an XML stream that contains the
form information. The format of an XFA resource is described in the XML Data
Package Specification and XFA forms are described in detail in the XFA Specifica-
tion, version 2.2 (see the Bibliography).
The
XFA entry may be either a stream containing the entire XFA resource or an
array specifying individual packets that together make up the XFA resource. The
resource includes but is not limited to the following information:
• The form template (specified in the template packet), which describes the char-
acteristics of the form, including its fields, calculations, validations, and for-
matting
• The data (specified in the datasets packet), which represents the state of the
form
KEY TYPE VALUE
Name
string (Required) The name of the referenced page.
F
file specification (Optional) The file containing the named page. If this entry is absent, it is
assumed that the page resides in the associated PDF file.
KEY TYPE VALUE
Page
integer (Required for annotations in FDF files) The ordinal page number on which
this annotation should appear, where page 0 is the first page.
Interactive FeaturesCHAPTER 8
682
• The configuration information (specified in the config packet), which is re-
quired to properly process the form template and associated data
Each packet represents a complete XML element, with the exception of the first
and last packet, which specify begin and end tags for the
xdp:xdp element. Exam-
ple 8.18 shows the
XFA entry consisting of an array of packets; Example 8.19
shows the same entry specified as a stream.
Example 8.18
1 0 obj XFA entry in interactive form dictionary
<< /XFA [(xdp:xdp) 10 0 R XFA resource specified as individual packets
(template) 11 0 R
(datasets) 12 0 R
(config) 13 0 R
(/xdp:xdp) 14 0 R ]
>>
endobj
10 0 obj
stream
<xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/">
endstream
11 0 obj
stream
<template xmlns="http://www.xfa.org/schema/xfa-template/2.1/">
...remaining contents of template packet...
</template>
endstream
12 0 obj
stream
<xfa:datasets xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/">
...contents of datasets packet...
</xfa:datasets>
endstream
13 0 obj
stream
<config xmlns="http://www.xfa.org/schema/xci/1.0/">
...contents of config node of XFA Data Package...
<config>
endstream
Interactive FormsSECTION 8.6
683
14 0 obj
stream
</xdp:xdp>
endstream
Example 8.19
1 0 obj XFA entry in interactive form dictionary
<< /XFA 10 0 R >>
endobj
10 0 obj
stream
<xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/">
<template xmlns="http://www.xfa.org/schema/xfa-template/2.1/">
...remaining contents of template packet...
</template>
<xfa:datasets xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/">
...contents of datasets packet...
</xfa:datasets>
<config xmlns="http://www.xfa.org/schema/xci/1.0/">
...contents of config node of XFA Data Package...
<config>
</xdp:xdp>
endstream
endobj
When an XFA entry is present in an interactive form dictionary, the XFA resource
provides most of the information about the form; in particular, all form-related
events such as calculations and validations. The other entries in the interactive
form dictionary must be consistent with the information in the XFA resource.
When creating or modifying a PDF file with an XFA resource, applications
should follow these guidelines:
• PDF interactive form field objects must be present for each field specified in
the XFA resource. The XFA field values must be consistent with the corre-
sponding
V entries of the PDF field objects.
• The XFA Scripting Object Model (SOM) specifies a naming convention that
must be used to connect interactive form field names with field names in the
XFA resource. Information about this model is available in the XFA Specifica-
tion, version 2.2 (see the Bibliography).
Interactive FeaturesCHAPTER 8
684
• No A or AA entries (see Table 8.11) should be present in the annotation dictio-
naries of fields that also have actions specified by the XFA resource. The behav-
ior of a field whose actions are specified in both ways is undefined.
8.7 Digital Signatures
A digital signature (PDF 1.3) can be used to authenticate the identity of a user and
the document’s contents. It stores information about the signer and the state of
the document when it was signed. The signature may be purely mathematical,
such as a public/private-key encrypted document digest, or it may be a biometric
form of identification, such as a handwritten signature, fingerprint, or retinal
scan. The specific form of authentication used is implemented by a plug-in signa-
ture handler. Third-party handler writers are encouraged to register their handler
names with Adobe; see Appendix E.
Signature information is contained in a signature dictionary, whose entries are
listed in Table 8.98. Signature handlers can use or omit those entries that are
marked optional in the table but are encouraged to use them in a standard way if
they are used at all. In addition, signature handlers may add private entries of
their own. To avoid name duplication, it is suggested that the keys for all such pri-
vate entries be prefixed with the registered handler name followed by a period (
.).
Signatures are created by computing a digest of the data (or part of the data) in a
document, and storing the digest in the document. To verify the signature, the di-
gest is recomputed and compared with the one stored in the document. Differ-
ences in the digest values indicate that modifications have been made since the
document was signed.
There are two defined techniques for computing a reproducible digest of the con-
tents of all or part of a PDF file:
• A byte range digest is computed over a range of bytes in the file, indicated by the
the
ByteRange entry in the signature dictionary. This range is typically the en-
tire file, including the signature dictionary but excluding the signature value it-
self (the
Contents entry). When a byte range digest is present, all values in the
signature dictionary are required to be direct objects. See implementation note
138 in Appendix H.
• An object digest (PDF 1.5) is computed by selectively walking a subtree of ob-
jects in memory, beginning with the referenced object, which is typically the
Digital SignaturesSECTION 8.7
685
root object. The resulting digest, along with information about how it was com-
puted, is placed in a signature reference dictionary, whose entries are listed in
Table 8.99. The
TransformMethod entry specifies the general method used to
compute the digest, and the
TransformParams entry specifies the variable por-
tion of the computation. Transform methods are described in detail in Section
8.7.1, “Transform Methods.”
A PDF document may contain the following standard types of signatures:
• One or more document (or ordinary) signatures. These signatures appear in sig-
nature form fields (see “Signature Fields” on page 658). The signature dictio-
nary corresponding to each signature is the value of the form field (as specified
by its
V entry). The signature dictionary must contain a ByteRange entry repre-
senting a byte range digest, as described above. A signature is validated by re-
computing the digest and comparing it with the one stored in the signature.
Note: If a signed document is modified and saved by incremental update (see Sec-
tion 3.4.5, “Incremental Updates”), the data corresponding to the byte range of the
original signature is preserved. Therefore, if the signature is valid, it is possible to
recreate the state of the document as it existed at the time of signing.
• At most one MDP (modification detection and prevention) signature (PDF 1.5),
also referred to as an author or certifying signature. The signature dictionary of
an MDP signature must be the value of a signature field and must contain a
ByteRange entry. It may also be referenced from the DocMDP entry in the per-
missions dictionary (see Section 8.7.3, “Permissions”). The signature dictionary
must contain a signature reference dictionary (see Table 8.99) that has a
DocMDP transform method. See “DocMDP” on page 690 for information on
how these signatures are created and validated.
A signature dictionary for an MDP or ordinary signature may also have a sig-
nature reference dictionary with a
FieldMDP transform method; see “FieldM-
DP” on page 695.
• At most two usage rights signatures (PDF 1.5). Its signature dictionary is refer-
enced from the
UR or UR3 (PDF 1.6) entry in the permissions dictionary (not
from a signature field); see Table 8.103. The dictionary must contain a signa-
ture reference dictionary that has a
UR transform method. See “UR” on page
692 for information on how these signatures are created and validated.
• The Sig entry in the catalog of an FDF file (see “FDF Catalog” on page 672)
specifies a signature dictionary.
Interactive FeaturesCHAPTER 8
686
TABLE 8.98 Entries in a signature dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
Sig for a signature dictionary.
Filter
name (Required; inheritable) The name of the preferred signature handler to use
when validating this signature. If the
Prop_Build entry is not present, it is also
the name of the signature handler that was used to create the signature. If
Prop_Build is present, it can be used to determine the name of the handler
that created the signature (which is typically the same as
Filter but is not re-
quired to be). An application may substitute a different handler when verify-
ing the signature, as long as it supports the specified
SubFilter format.
Example signature handlers are
Adobe.PPKLite, Entrust.PPKEF, CICI.SignIt,
and
VeriSign.PPKVS.
SubFilter
name (Optional) A name that describes the encoding of the signature value and key
information in the signature dictionary. An application may use any handler
that supports this format to validate the signature.
Defined values for public-key cryptographic signatures are
adbe.x509.rsa_sha1, adbe.pkcs7.detached, and adbe.pkcs7.sha1 (see Section
8.7.2, “Signature Interoperability”).
Contents
string (Required) The signature value. When ByteRange is present, the value is a
hexadecimal string (see “Hexadecimal Strings” on page 32) representing the
value of the byte range digest. If
ByteRange is not present, the value is an ob-
ject digest of the signature dictionary, excluding the
Contents entry.
For public-key signatures,
Contents is commonly either a DER-encoded
PKCS#1 binary data object or a DER-encoded PKCS#7 binary data object.
Cert
array or
string
(Required when SubFilter is adbe.x509.rsa_sha1; not used otherwise) An array
of strings representing the X.509 certificate chain used when signing and ver-
ifying signatures that use public-key cryptography, or a string if the chain has
only one entry. The signing certificate must appear first in the array; it is used
to verify the signature value in
Contents, and the other certificates are used to
verify the authenticity of the signing certificate.
If
SubFilter is adbe.pkcs7.detached or adbe.pkcs7.sha1, this entry is not
used, and the certificate chain must be put in the PKCS#7 envelope in
Contents.
Digital SignaturesSECTION 8.7
687
ByteRange
array (Required for all signatures that are part of a signature field and usage rights
signatures referenced from the
UR3 entry in the permissions dictionary) An ar-
ray of pairs of integers (starting byte offset, length in bytes) describing the ex-
act byte range for the digest calculation. Multiple discontiguous byte ranges
are used to describe a digest that does not include the signature value (the
Contents entry) itself.
Reference
array (Optional; PDF 1.5) An array of signature reference dictionaries (see Table
8.99).
Changes
array (Optional) An array of three integers specifying changes to the document that
have been made between the previous signature and this signature: in this or-
der, the number of pages altered, the number of fields altered, and the num-
ber of fields filled in. (See implementation note 138 in Appendix H.)
Note: The ordering of signatures is determined by the value of
ByteRange. Since
each signature results in an incremental save, later signatures have a greater
length value.
Name
text string (Optional) The name of the person or authority signing the document. This
value should be used only when it is not possible to extract the name from the
signature; for example, from the certificate of the signer.
M
date (Optional) The time of signing. Depending on the signature handler, this may
be a normal unverified computer time or a time generated in a verifiable way
from a secure time server.
This value should be used only when the the time of signing is not available
in the signature; for example, a time stamp can be embedded in a PKCS#7 bi-
nary data object (see “PKCS#7 Signatures” on page 697).
Location
text string (Optional) The CPU host name or physical location of the signing.
Reason
text string (Optional) The reason for the signing, such as (I agree…).
ContactInfo
text string (Optional) Information provided by the signer to enable a recipient to contact
the signer to verify the signature; for example, a phone number.
R
integer (Optional) The version of the signature handler that was used to create the
signature.
Note: Beginning with PDF 1.5, this entry is deprecated, and the information
should be stored in the
Prop_Build dictionary.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
688
Note: The entries in the signature dictionary can be conceptualized as being in dif-
ferent dictionaries; they are in one dictionary for historical and cryptographic rea-
sons. The categories are signature properties (
R, M, Name, Reason, Location,
Prop_Build, Prop_AuthTime, and Prop_AuthType); key information (Cert and por-
tions of
Contents when the signature value is a PKCS#7 object); reference
(
Reference and ByteRange); and signature value (Contents when the signature val-
ue is a PKCS#1 object).
V
integer (Optional; PDF 1.5) The version of the signature dictionary format. It corre-
sponds to the usage of the signature dictionary in the context of the value of
SubFilter. The value is 1 if the Reference dictionary is considered critical to
the validation of the signature.
Default value: 0.
Prop_Build
dictionary (Optional; PDF 1.5) A dictionary that can be used by a signature handler to
record information that captures the state of the computer environment used
for signing, such as the name of the handler used to create the signature, soft-
ware build date, version, and operating system.
Adobe publishes a separate specification, the PDF Signature Build Dictionary
Specification for Acrobat 6.0 that provides implementation guidelines for the
use of this dictionary.
Prop_AuthTime
integer (Optional; PDF 1.5) The number of seconds since the signer was last authen-
ticated. It is intended to be used in claims of signature repudiation. It should
be omitted if the value is unknown.
Prop_AuthType
name (Optional; PDF 1.5) The method used to authenticate the signer. It is intend-
ed to be used in claims of signature repudiation. Valid values include
PIN,
Password, and Fingerprint.
KEY TYPE VALUE
Digital SignaturesSECTION 8.7
689
TABLE 8.99 Entries in a signature reference dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if
present, must be
SigRef for a signature reference dictionary.
TransformMethod
name (Required) The name of the transform method (see Section 8.7.1,
“Transform Methods”) that guides the object digest computation or
modification analysis that takes place when the signature is validat-
ed. Valid values are:
DocMDP Used to detect modifications to a document relative
to a signature field that is signed by the originator of
a document; see “DocMDP” on page 690.
UR Used to detect modifications to a document that
would invalidate a signature in a rights-enabled doc-
ument; see “UR” on page 692.
FieldMDP Used to detect modifications to a list of form fields
specified in
TransformParams; see “FieldMDP” on
page 695.
Identity Used when signing a single object, which is specified
by the value of
Data in the signature reference dic-
tionary (see Table 8.99). This transform method
supports signing of FDF files. See “Identity” on page
696 for details.
TransformParams
dictionary (Optional) A dictionary specifying transform parameters (variable
data) for the transform method specified by
TransformMethod.
Each method except
Identity takes its own set of parameters. See
each of the sections specified above for details on the individual
transform parameter dictionaries
Data
(various) (Required when TransformMethod is FieldMDP or Identity) An indi-
rect reference to the object in the document over which the digest
was computed or upon which the object modification analysis
should be performed. For transform methods other than
FieldMDP
and Identity, this object is implicitly defined.
DigestMethod
name (Optional) A name identifying the algorithm to be used when com-
puting the digest. Valid values are
MD5 and SHA1. Default value:
MD5.
Interactive FeaturesCHAPTER 8
690
8.7.1 Transform Methods
Transform methods, along with transform parameters, determine which objects
are included and excluded in object digest computation or revision comparison.
The following sections discuss the types of transform methods, their transform
parameters, and when they are used. Appendix I, “Computation of Object Di-
gests,” describes in detail the algorithm for computing object digests.
Note: All transform methods exclude the signature dictionary from the object digest.
DocMDP
The DocMDP transform method is used to detect modifications relative to a sig-
nature field that is signed by the author of a document (the person applying the
first signature). A document can contain only one signature field that contains a
DocMDP transform method; it must be the first signed field in the document. It
enables the author to specify what changes are permitted to be made the docu-
ment and what changes invalidate the author’s signature.
As discussed earlier, “MDP” stands for modification detection and prevention.
Such signatures enable detection of disallowed changes specified by the author. In
addition, disallowed changes can also be prevented when the signature dictionary
is referred to by the
DocMDP entry in the permissions dictionary (see Section
8.7.3, “Permissions”).
DigestValue
string (Required in some situations) When present, the computed value of
the digest. See Section 8.7.1, “Transform Methods, for details on
when this entry is required.
DigestLocation
array (Required when DigestValue is required and TransformMethod is
FieldMDP or DocMDP) An array of two integers specifying the loca-
tion in the PDF file of the
DigestValue string. The integers represent
the starting offset and length in bytes, respectively.
This entry is required when
DigestValue is written directly to the
PDF file, bypassing any encryption that has been performed on the
document. When specified, the values must be used to read
DigestValue directly from the file during validation.
KEY TYPE VALUE
Digital SignaturesSECTION 8.7
691
Note: When creating an author signature, applications are encouraged to create a
legal attestation dictionary (see Section 8.7.4, “Legal Content Attestations”) that
specifies all content that might result in unexpected rendering of the document con-
tents, along with the author’s attestation to such content. This dictionary can be
used to establish an author’s intent if the integrity of the document is questioned.
The
P entry in the DocMDP transform parameters dictionary (see Table 8.100) in-
dicates the author’s specification of which changes to the document will invali-
date the signature. (These changes to the document are also prevented if the
signature dictionary is referred to from the
DocMDP entry in the permissions dic-
tionary.) A value of 1 for
P indicates that the document is intended to be final;
that is, any changes invalidate the signature. The values 2 and 3 permit modifica-
tions that are appropriate for form field or comment workflows.
The
DocMDP object digest is computed over a subset of the PDF objects in the
document. Specifically, this subset consists of the objects that are not permitted to
be modified, directly or indirectly, as specified by the transform parameters dic-
tionary. Appendix I describes the object digest computation.
Validating MDP signatures
To validate an MDP signature, an application first verifies the byte range digest.
Next, it verifies that any modifications that have been made to the document are
permitted by the transform parameters by using one of the following techniques:
• PDF 1.5 required the calculated value of the object digest at the time of signing
to be stored in the
DigestValue entry in the signature reference dictionary (see
Table 8.99). Therefore, an application can compare this entry to its calculated
object digest when validating. If the values are different, the signature is invalid.
• In PDF 1.6, the DigestValue entry is not required. Once the byte range digest is
validated, the portion of the document specified by the
ByteRange entry in the
signature dictionary (see Table 8.98) is known to correspond to the state of the
document at the time of signing. Therefore, applications can compare the
signed and current versions of the document to see whether there have been
modifications to any objects that are not permitted by the transform parame-
ters. See implementation note 140 in Appendix H.
Interactive FeaturesCHAPTER 8
692
TABLE 8.100 Entries in the DocMDP transform parameters dictionary
UR
The UR transform method is used to detect changes to a document that would in-
validate a usage rights signature, which is referred to from the
UR or UR3 entry in
the permissions dictionary (see Section 8.7.3, “Permissions). Usage rights signa-
tures are used to enable additional interactive features that are not available by
default in a particular viewer application (such as Adobe Reader). The signature
is used to validate that the permissions have been granted by a bonafide granting
authority. The transform parameters dictionary (see Table 8.101) specifies the ad-
ditional rights that are enabled if the signature is valid. If the signature is invalid
because the document has been modified in a way that is not permitted or the
identity of the signer is not granted the extended permissions, additional rights
are not granted.
Adobe Systems grants permissions, for example, to enable additional features in
Adobe Reader, using public-key cryptography. It uses certificate authorities to is-
sue public key certificates to document creators with which it has entered into a
business relationship. Adobe Reader verifies that the rights-enabling signature
uses a certificate from an Adobe-authorized certificate authority. Other PDF
viewer applications are free to use this same mechanism for their own purposes.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
TransformParams for a transform parameters dictionary.
P
number (Optional) The access permissions granted for this document. Valid values are:
1 No changes to the document are permitted; any change to the docu-
ment invalidates the signature.
2 Permitted changes are filling in forms, instantiating page templates,
and signing; other changes invalidate the signature.
3 Permitted changes are the same as for 2, as well as annotation creation,
deletion, and modification; other changes invalidate the signature.
Default value:
2.
V
name (Optional) The DocMDP transform parameters dictionary version. The value for PDF
1.5 and later is
1.2. (Note that this value is a name object, not a number.) Default val-
ue:
1.2.
Digital SignaturesSECTION 8.7
693
Validation of a usage rights signature depends on whether the signature dictio-
nary is referenced from the
UR or UR3 entry in the permissions dictionary (See
implementation note 141 in Appendix H):
• UR: At the time of signing, the application computes the object digest over a
subset of the PDF objects in the document; that is, the objects that are not
modified, directly or indirectly, by permissible operations, as specified by the
transform parameters dictionary. Appendix I describes the object digest com-
putation. The calculated value of this digest is stored in the
DigestValue entry
in the signature reference dictionary (see Table 8.99). An application can com-
pare this entry to its calculated object digest when validating. If the values are
different, the signature is invalid.
• UR3 (PDF 1.6): The ByteRange entry in the signature dictionary (see Table
8.98) is required to be present. First, the application verifies the byte range di-
gest to determine whether the portion of the document specified by
ByteRange
corresponds to the state of the document at the time of signing. Next, the appli-
cation examines the current version of the document to see whether there have
been modifications to any objects that are not permitted by the transform pa-
rameters.
TABLE 8.101 Entries in the UR transform parameters dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
TransformParams for a transform parameters dictionary.
Document
array (Optional) An array of names specifying additional document-wide usage rights for
the document. The only defined value is
FullSave, which permits a user to save the
document along with modified form and/or annotation data. (See implementation
note 142 in Appendix H.)
Msg
string (Optional) A string that can be used to specify any arbitrary information, such as the
reason for adding usage rights to the document.
V
name (Optional) The UR transform parameters dictionary version. The value for PDF 1.5 is
2.2. (Note that this value is a name object, not a number.) If an unknown version is
present, no rights are enabled. Default value:
2.2.
Interactive FeaturesCHAPTER 8
694
Annots
array (Optional) An array of names specifying additional annotation-related usage rights
for the document. Valid names in PDF 1.5 and later are
Create, Delete, Modify, Copy,
Import, and Export, which permit the user to perform the named operation on anno-
tations.
The following names were added in PDF 1.6. They are permitted only when the signa-
ture dictionary is referenced from the
UR3 entry of the permissions dictionary (see
Table 8.103):
Online Permits online commenting; that is, the ability to upload or
download markup annotations from a server.
SummaryView Permits a user interface to be shown that summarizes the
comments (markup annotations) in a document.
Form
array (Optional) An array of names specifying additional form-field-related usage rights for
the document. Valid names in PDF 1.5 are:
FillIn Permits the user to save a document on which form fill-in
has been done.
Import Permits the user to import form data files in FDF, XFDF
and text (CSV/TSV) formats.
Export Permits the user to export form data files as FDF or XFDF.
SubmitStandalone Permits the user to submit form data when the document is
not open in a Web browser.
SpawnTemplate Permits new pages to be instantiated from named page tem-
plates.
The following names were added in PDF 1.6. They are permitted only when the signa-
ture dictionary is referenced from the
UR3 entry of the permissions dictionary; see Ta-
ble 8.103 (however, see
FormEx below):
BarcodePlaintext Permits text form field data to be encoded as a plaintext
two-dimensional barcode.
Online (PDF 1.6) Permits the use of forms-specific online mecha-
nisms such as SOAP or Active Data Object.
FormEx
array (Optional; permitted only when the signature dictionary is referenced from the UR entry
of the permissions dictionary; PDF 1.5) An array of names specifying additional form-
field-related usage rights. The only valid name is
BarcodePlaintext, which permits text
form field data to be encoded as a plaintext two-dimensional barcode.
KEY TYPE VALUE
Digital SignaturesSECTION 8.7
695
FieldMDP
The FieldMDP transform method computes an object digest over a list of form
field objects and is used to detect changes to the values of those form fields. The
entries in its transform parameters dictionary are listed in Table 8.102.
TABLE 8.102 Entries in the FieldMDP transform parameters dictionary
Signature
array (Optional) An array of names specifying additional signature-related usage rights for
the document. The only defined value is
Modify, which permits a user to apply a digi-
tal signature to an existing signature form field or clear a signed signature form field.
EF
array (Optional; PDF 1.6) An array of names specifying additional usage rights for named
embedded files in the document. Valid names are
Create, Delete, Modify, and Import,
which permit the user to perform the named operation on named embedded files.
P
boolean (Optional; PDF 1.6) If true, permissions for the document should be restricted in all
consumer applications to those permissions granted by Adobe Reader, while allowing
permissions for rights enabled by other entries in this dictionary. Default value:
false.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
TransformParams for a transform parameters dictionary.
Action
name (Required) A name that, along with the Fields array, describes which form fields are
included in the object digest (and hence do not permit changes after the signature is
applied). Valid values are:
All All form fields.
Include Only those form fields that are specified in Fields.
Exclude Only those form fields that are not specified in Fields.
Fields
array (Required if Action is Include or Exclude) An array of strings containing field names.
V
name (Optional) The transform parameters dictionary version. The value for PDF 1.5 and
later is
1.2. (Note that this value is a name object, not a number.) Default value: 1.2.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
696
In documents intended for form field workflows, the following occurs:
• The author specifies that form fields can be filled in without invalidating the
author’s signature. The
P entry of the DocMDP transform parameters dictio-
nary is set to either 2 or 3 (see Table 8.100).
• The author can also specify that after a specific recipient has signed the docu-
ment, any modifications to specific form fields should invalidate that recipient’s
signature. There is a separate signature field for each designated recipient, each
having an associated signature field lock dictionary (see Table 8.78) specifying
the form fields that should be locked for that user.
• When the recipient signs the field, the signature, signature reference, and trans-
form parameters dictionaries are created. The
Action and Fields entries in the
transform parameters dictionary are copied from the corresponding fields in
the signature field lock dictionary.
Note: This copying is done because all objects in a signature dictionary must be
direct objects if the dictionary contains a byte range signature. (Even though
FieldMDP signatures are object signatures, any signature dictionary referred to
from a signature field must also have a byte range signature.) Therefore, the
transform parameters dictionary cannot reference the signature field lock dictio-
nary indirectly.
The object digest is computed over all the form fields specified by the transform
parameters dictionary, sorted in alphabetical order (see Appendix I for details).
The specified form fields are locked to prevent changes by marking them read-
only. Any changes to the form fields can be detected when the recipient’s signa-
ture is verified.
FieldMDP signatures are validated in a similar manner to DocMDP signatures. See
“Validating MDP signatures” on page 691 for details.
Identity
The Identity transform method is used when computing an object digest that is
all-inclusive; that is, no objects are excluded. The entire object tree is walked,
starting with the object specified by
Data in the signature reference dictionary
(see Table 8.99). Any changes to the contents of the object invalidate the signa-
ture. This method is used to support the signing of FDF files. The FDF catalog is
the object over which the digest is calculated.
Digital SignaturesSECTION 8.7
697
8.7.2 Signature Interoperability
It is intended that PDF consumer applications allow interoperability between sig-
nature handlers; that is, a PDF file signed with a handler from one vendor must
be able to be validated with a handler from a different vendor.
The
SubFilter entry in the signature dictionary specifies the encoding of the sig-
nature value and key information, and the
Filter entry specifies the preferred han-
dler to use to validate the signature. Handlers specify the
SubFilter encodings
they support; therefore, handlers other than the preferred handler can be used to
validate the signature if necessary or desired.
There are several defined values for the
SubFilter entry, all based on public-key
cryptographic standards published by RSA Security and also as part of the stan-
dards issued by the Internet Engineering Task Force (IETF) Public Key Infra-
structure (PKIX) working group; see the Bibliography for references.
PKCS#1 Signatures
The PKCS#1 standard supports several public-key cryptographic algorithms and
digest methods, including RSA encryption, DSA signatures, and SHA-1 and MD5
digests (see the Bibliography for references). For signing PDF files using PKCS#1,
the only recommended value of
SubFilter is adbe.x509.rsa_sha1, which uses the
RSA encryption algorithm and SHA-1 digest method. The certificate chain of the
signer is stored in the
Cert entry.
PKCS#7 Signatures
When PKCS#7 signatures are used, the value of Contents is a DER-encoded
PKCS#7 binary data object containing the signature.
SubFilter can take one of the
following values:
• adbe.pkcs7.detached: No data is encapsulated in the PKCS#7 signed-data field.
• adbe.pkcs7.sha1: The SHA1 digest of the byte range is encapsulated in the
PKCS#7 signed-data field with
ContentInfo of type Data.
The PKCS#7 object must conform to the PKCS#7 specification in Internet RFC
2315, PKCS #7: Cryptographic Message Syntax, Version 1.5 (see the Bibliography).
At minimum, it must include the signer’s X.509 signing certificate. This certifi-
Interactive FeaturesCHAPTER 8
698
cate is used to verify the signature value in Contents. The PKCS#7 object may op-
tionally contain one or more issuer certificates from the signer’s trust chain; see
implementation note 143 in Appendix H.
The PKCS#7 object may optionally contain the following attributes:
• Time stamp information as an unsigned attribute: The timestamp token must
conform to RFC 3161 and must be computed and embedded into the PKCS#7
object as described in Appendix A of RFC 3161.
• Revocation information as an signed attribute: This attribute can include all the
revocation information that is necessary to carry out revocation checks for the
signer's certificate and its issuer certificates.
The following object identifier identifies Adobe's revocation information at-
tribute:
adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
{ adbe(1.2.840.113583) acrobat(1) security(1) 8 }
The value of the revocation information attribute can include any of the following
data types:
• Certificate Revocation Lists (CRLs), described in RFC 3280 (see the Bibliogra-
phy): CRLs are generally large and therefore not recommended to be embed-
ded in the PKCS#7 object.
• Online Certificate Status Protocol (OCSP) Responses, described in RFC 2560,
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—
OCSP (see the Bibliography): These are generally small and constant in size and
are the suggested data type to be included in the PKCS#7 object.
• Custom revocation information: The format is not prescribed by this specifica-
tion, other than that it be encoded as an
OCTET STRING. The application should
be able to determine the type of data contained within the
OCTET STRING by
looking at the associated
OBJECT IDENTIFIER.
Digital SignaturesSECTION 8.7
699
Adobe's Revocation Information attribute value has ASN.1 type
RevocationInfoArchival:
RevocationInfoArchival ::= SEQUENCE {
crl [0] EXPLICIT SEQUENCE of CRLs, OPTIONAL
ocsp [1] EXPLICIT SEQUENCE of OCSP Responses, OPTIONAL
otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo, OPTIONAL
}
OtherRevInfo ::= SEQUENCE {
Type OBJECT IDENTIFIER
Value OCTET STRING
}
For byte range signatures, Contents is a hexadecimal string with “<” and “>” de-
limiters. It must fit precisely in the space between the ranges specified by
ByteRange. Since the length of PKCS#7 objects is not entirely predictable, it is of-
ten necessary to pad the value of
Contents with zeros at the end of the string (be-
fore the “
>” delimiter) before writing the PKCS#7 to the allocated space in the
file.
A PKCS#7 object is a wrapper for signing information that, when using PKCS#1,
can be found in the signature dictionary. PKCS#7 signatures require more space
in a PDF file and can vary in size. PKCS#1 signatures are predictable in size and
compact, 131 bytes for a 1024-bit RSA signature, before hex encoding.
It is possible to do an on-the-fly conversion of PKCS#1 signature values to
PKCS#7 signature values, but the reverse conversion is not possible. The implica-
tion is that PKCS#1 signatures can be validated by handlers that do not directly
support PKCS#1, but PKCS#7 signatures cannot be validated by handlers that
support only PKCS#1. PKCS#1 signatures are therefore recommended in all cases
where the added capabilities of PKCS#7 are not required.
8.7.3 Permissions
The Perms entry in the document catalog (see Table 3.25) specifies a permissions
dictionary (PDF 1.5). Each entry in this dictionary (see Table 8.103 for the cur-
rently defined entries) specifies the name of a permission handler that controls
access permissions for the document. These permissions are similar to those de-
fined by security handlers (see Table 3.20 on page 99) but do not require that the
document be encrypted. For a permission (for example, the ability to fill in form
Interactive FeaturesCHAPTER 8
700
fields) to be actually granted for a document, it must be allowed by each permis-
sion handler that is present in the permissions dictionary as well as by the securi-
ty handler.
TABLE 8.103 Entries in a permissions dictionary
8.7.4 Legal Content Attestations
The PDF language provides a number of capabilities that can make the rendered
appearance of a PDF document vary. These capabilities could potentially be used
to construct a document that misleads the recipient of a document, intentionally
KEY TYPE VALUE
DocMDP
dictionary (Optional) An indirect reference to a signature dictionary (see Table 8.98). This dic-
tionary must contain a
Reference entry that is a signature reference dictionary (see
Table 8.99) that has a
DocMDP transform method (see “DocMDP” on page 690) and
corresponding transform parameters.
If this entry is present, consumer applications should enforce the permissions speci-
fied by the
P attribute in the DocMDP transform parameters dictionary and should
also validate the corresponding signature based on whether any of these permis-
sions have been violated.
UR
dictionary (Optional) A signature dictionary that is used to specify and validate additional ca-
pabilities (usage rights) granted for this document; that is, the enabling of interac-
tive features of the viewer application that are not available by default.
For example, Adobe Reader does not permit saving documents by default, but Ado-
be Systems may grant permissions that enable saving in Adobe Reader for specific
documents. The signature is used to validate that the permissions have been granted
by Adobe Systems.
The signature dictionary must contain a
Reference entry that is a signature refer-
ence dictionary that has a
UR transform method (see “UR” on page 692). The trans-
form parameter dictionary for this method indicates which additional permissions
should be granted for the document. If the signature is valid, the Adobe Reader al-
lows the specified permissions for the document, in addition to the application’s de-
fault permissions.
The signature dictionary must not contain a
ByteRange entry.
UR3
dictionary (Optional; PDF 1.6) A signature dictionary that specifies and validates usage rights.
The description of the
UR entry above applies to UR3, except that the signature dic-
tionary must contain a
ByteRange entry. See “UR” on page 692 for details.
Digital SignaturesSECTION 8.7
701
or unintentionally. These situations are relevant when considering the legal im-
plications of a signed PDF document.
Therefore, it is necessary to have a mechanism by which a document recipient
can determine whether the document can be trusted. The primary method is to
accept only documents that contain author signatures (one that has a
DocMDP
signature that defines what is permitted to change in a document; see “DocMDP”
on page 690).
When creating author signatures, applications should also create a legal attesta-
tion dictionary, whose entries are shown in Table 8.104. This dictionary is the val-
ue of the
Legal entry in the document catalog (see Table 3.25). Its entries specify
all content that may result in unexpected rendering of the document contents.
The author may provide further clarification of such content by means of the
Attestation entry. Reviewers should establish for themselves that they trust the
author and contents of the document. In the case of a legal challenge to the docu-
ment, any questionable content can be reviewed in the context of the information
in this dictionary.
TABLE 8.104 Entries in a legal attestation dictionary
KEY TYPE VALUE
JavaScriptActions
integer (Optional) The number of JavaScript actions found in the document (see
“JavaScript Actions” on page 668).
LaunchActions
integer (Optional) The number of launch actions found in the document (see
“Launch Actions” on page 621).
URIActions
integer (Optional) The number of URI actions found in the document (see “URI
Actions” on page 624).
MovieActions
integer (Optional) The number of movie actions found in the document (see “Mov-
ie Actions” on page 626).
SoundActions
integer (Optional) The number of sound actions found in the document (see
“Sound Actions” on page 625).
HideAnnotationActions
integer (Optional) The number of hide actions found in the document (see “Hide
Actions” on page 627).
GoToRemote
integer (Optional) The number of remote go-to actions found in the document (see
“Remote Go-To Actions” on page 617).
Interactive FeaturesCHAPTER 8
702
AlternateImages
integer (Optional) The number of alternate images found in the document (see “Al-
ternate Images” on page 317)
ExternalStreams
integer (Optional) The number of external streams found in the document.
TrueTypeFonts
integer (Optional) The number of TrueType fonts found in the document (see
“TrueType Fonts” on page 387).
ExternalRefXobjects
integer (Optional) The number of reference XObjects found in the document (see
“Reference XObjects” on page 331).
ExternalOPIdicts
integer (Optional) The number of OPI dictionaries found in the document (see
“Open Prepress Interface (OPI)” on page 907).
NonEmbeddedFonts
integer (Optional) The number of non-embedded fonts found in the document (see
Section 5.8, “Embedded Font Programs”)
DevDepGS_OP
integer (Optional) The number of references to the graphics state parameter OP
found in the document (see Table 4.8).
DevDepGS_HT
integer (Optional) The number of references to the graphics state parameter HT
found in the document (see Table 4.8).
DevDepGS_TR
integer (Optional) The number of references to the graphics state parameter TR
found in the document (see Table 4.8).
DevDepGS_UCR
integer (Optional) The number of references to the graphics state parameter UCR
found in the document (see Table 4.8).
DevDepGS_BG
integer (Optional) The number of references to the graphics state parameter BG
found in the document (see Table 4.8).
DevDepGS_FL
integer (Optional) The number of references to the graphics state parameter FL
found in the document (see Table 4.8).
Annotations
integer (Optional) The number of annotations found in the document (see Section
8.4, “Annotations”).
OptionalContent
boolean (Optional) true if optional content is found in the document (see Section
4.10, “Optional Content”).
Attestation
string (Optional) An attestation, created by the author of the document, explaining
the presence of any of the other entries in this dictionary or the presence of
any other content affecting the legal integrity of the document.
KEY TYPE VALUE
Measurement PropertiesSECTION 8.8
703
8.8 Measurement Properties
PDF documents, such as those created by CAD software, may contain graphics
that are intended to represent real-world objects. Users of such documents often
require information about the scale and units of measurement of the correspond-
ing real-world objects and their relationship to units in PDF user space.
This information enables users of viewer applications to perform measurements
that yield results in the units intended by the creator of the document. A mea-
surement in this context is the result of a canonical function that takes as input a
set of n coordinate pairs
and produces a single number as output depending on the type of measurement.
For example, distance measurement is equivalent to
for
Beginning with PDF 1.6, such information may be stored in a measure dictionary
(see Table 8.106). Measure dictionaries provide information about measurement
units associated with a rectangular area of the document known as a viewport.
A viewport (PDF 1.6) is a rectangular region of a page. The optional
VP entry in a
page dictionary (see Table 3.27) specifies an array of viewport dictionaries, whose
entries are shown in Table 8.105. Viewports allow different measurement scales
(specified by the
Measure entry) to be used in different areas of a page, if neces-
sary.
The dictionaries in the
VP array are in drawing order. Since viewports might
overlap, to determine the viewport to use for any point on a page, the dictionaries
in the array are examined, starting with the last one and iterating in reverse, and
the first one whose
BBox entry contains the point is chosen.
x
0
y
0
,()…x
n 1–
y
n 1–
,(),,{}
x
i
x
i 1+
–()
2
y
i
y
i 1+
–()
2
+
i 0=
n 2–
n 2.
Interactive FeaturesCHAPTER 8
704
Note: Any measurement that potentially involves multiple viewports, such as one
specifying the distance between two points, should use the information specified in
the viewport of the first point.
TABLE 8.105 Entries in a viewport dictionary
A measure dictionary specifies an alternate coordinate system for a region of a
page. Along with the viewport dictionary, it provides the information needed to
convert coordinates in the page’s coordinate system to coordinates in the measur-
ing coordinate system. The measure dictionary provides information for format-
ting the resulting values into textual form for presentation in a graphical user
interface.
Table 8.106 shows the entries in a measure dictionary. PDF 1.6 defines only a sin-
gle type of coordinate system, a rectilinear coordinate system, specified by the val-
ue
RL for the Subtype entry, which is defined as one in which the x and y axes are
perpendicular and have units that increment linearly (to the right and up, respec-
tively). Other subtypes are permitted, providing the flexibility to measure using
other types of coordinate systems.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; must be Viewport
for a viewport dictionary.
BBox
rectangle (Required) A rectangle in default user space coordinates specifying the location of
the viewport on the page.
The two coordinate pairs of the rectangle must be specified in normalized form;
that is, lower-left followed by upper-right, relative to the measuring coordinate sys-
tem. This ordering determines the orientation of the measuring coordinate system
(that is, the direction of the positive x and y axes) in this viewport, which may have
a different rotation from the page.
Note: The coordinates of this rectangle are independent of the origin of the measuring
coordinate system, specified in the
O entry (see Table 8.107) of the measurement dic-
tionary specified by
Measure.
Name
text string (Optional) A descriptive text string or title of the viewport, intended for use in a
user interface.
Measure
dictionary (Optional) A measure dictionary (see Table 8.106) that specifies the scale and units
that should apply to measurements taken on the contents within the viewport.
Measurement PropertiesSECTION 8.8
705
TABLE 8.106 Entries in a measure dictionary
Table 8.107 shows the additional entries in a rectilinear measure dictionary. Many
of the entries in this dictionary are number format arrays, which are arrays of
number format dictionaries (see Table 8.108). Each number format dictionary
represents a specific unit of measurement (such as miles or feet). It contains in-
formation about how each unit is expressed in text and factors for calculating the
number of units.
Number format arrays specify all the units that are to be used when expressing a
specific measurement. Each array contains one or more number format dictio-
naries, in descending order of granularity. (For example, a number format dictio-
nary specifying feet should precede one specifying inches.) All the elements in
the array contain text strings that, concatenated together, specify how the units
should be displayed. For example, a measurement of 1.4505 miles might be ex-
pressed as “1.4505 mi”, which would require one number format dictionary for
miles, or as “1 mi 2,378 ft 7 5/8 in”, which would require three dictionaries (for
miles, feet, and inches).
TABLE 8.107 Additional entries in a rectilinear measure dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; must be Measure
for a measure dictionary.
Subtype
name (Optional) A name specifying the type of coordinate system to use for measuring.
Default value:
RL, which specifies a rectilinear coordinate system
KEY TYPE VALUE
R
text string (Required) A text string expressing the scale ratio of the drawing in the region corre-
sponding to this dictionary. Universally recognized unit abbreviations should be
used, either matching those of the number format arrays in this dictionary or those
of commonly used scale ratios. For example, a common scale in architectural draw-
ings is “1/4 in = 1 ft”, indicating that 1/4 inches in default user space is equivalent to
1 foot in real-world measurements.
If the scale ratio differs in the x and y directions, both scales should be specified; for
example, “in X 1 cm = 1 m, in Y 1 cm = 30 m”.
Interactive FeaturesCHAPTER 8
706
X
array (Required) A number format array for measurement of change along the x axis and,
if
Y is not present, along the y axis as well. The first element in the array contains the
scale factor for converting from default user space units to the largest units in the
measuring coordinate system along that axis.
The directions of the x and y axes are in the measuring coordinate system and are
independent of the page rotation. These directions are determined by the
BBox en-
try of the containing viewport (see Table 8.105).
Y
array (Required when the x and y scales have different units or conversion factors) A num-
ber format array for measurement of change along the y axis. The first element in
the array contains the scale factor for converting from default user space units to the
largest units in the measuring coordinate system along the y axis.
D
array (Required) A number format array for measurement of distance in any direction.
The first element in the array specifies the conversion to the largest distance unit
from units represented by the first element in
X. The scale factors from X, Y (if
present) and
CYX (if Y is present) are used to convert from default user space to the
appropriate units before applying the distance function.
A
array (Required) A number format array for measurement of area. The first element in the
array specifies the conversion to the largest area unit from units represented by the
first element in
X, squared. The scale factors from X, Y (if present) and CYX (if Y is
present) are used to convert from default user space to the appropriate units before
applying the area function.
T
array (Optional) A number format array for measurement of angles. The first element in
the array specifies the conversion to the largest angle unit from degrees. The scale
factor from
CYX (if present) is used to convert from default user space to the appro-
priate units before applying the angle function.
S
array (Optional) A number format array for measurement of the slope of a line. The first
element in the array specifies the conversion to the largest slope unit from units rep-
resented by the first element in
Y divided by the first element in X. The scale factors
from
X, Y (if present) and CYX (if Y is present) are used to convert from default user
space to the appropriate units before applying the slope function.
O
array (Optional) An array of two numbers specifying the origin of the measurement coor-
dinate system in default user space coordinates. The directions by which x and y in-
crease in value from this origin is determined by the viewport’s
BBox entry (see
Table 8.105).
Default value: the first coordinate pair (lower-left corner) of the rectangle specified
by the viewport’s
BBox entry.
KEY TYPE VALUE
Measurement PropertiesSECTION 8.8
707
The X and Y entries in a measure dictionary are number format arrays that speci-
fy the units used for measurements in the x and y directions, respectively, and the
ratio between user space units and the specified units.
Y is present only when the
x and y measurements are in different units or have different ratios; in this case,
the
CYX entry is used to convert y values to x values when appropriate.
TABLE 8.108 Entries in a number format dictionary
CYX
number (Optional; meaningful only when Y is present) A factor to convert the largest units
along the y axis to the largest units along the x axis. It is required for some calcula-
tions (distance, area, and angle) where the units must be equivalent; if not specified,
these calculations cannot be performed (which would be the case in situations such
as x representing time and y representing temperature). Other calculations (change
in x, change in y, and slope) do not require this value.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; must be
NumberFormat for a number format dictionary.
U
text string (Required) A text string specifying a label for displaying the units represented by this
dictionary in a user interface; it is recommended that the label use a universally rec-
ognized abbreviation.
C
number (Required) The conversion factor used to multiply a value in partial units of the pre-
vious number format array element to obtain a value in the units of this dictionary.
When this entry is in the first number format dictionary in the array, its meaning
(that is, what it is multiplied by) depends on which entry in the rectilinear measure
dictionary (see Table 8.107) references the number format array.
F
name (Optional; meaningful only for the last dictionary in a number format array) A name
indicating whether and in what manner to display a fractional value from the result
of converting to the units of this dictionary by means of the
C entry. Valid values are:
D Show as decimal to the precision specified by the D entry.
F Show as a fraction with denominator specified by the D entry.
R No fractional part; round to the nearest whole unit.
T No fractional part; truncate to achieve whole units.
Default value:
D.
KEY TYPE VALUE
Interactive FeaturesCHAPTER 8
708
D
integer (Optional; meaningful only for the last dictionary in a number format array) A posi-
tive integer specifying the precision or denominator of a fractional amount:
• When the value of F is D, this entry represents the precision of a decimal display;
it must be a multiple of 10. Low-order zeros may be truncated unless
FD is true.
Default value: 100 (hundredths, corresponding to two decimal digits).
• When the value of F is F, this entry represents the denominator of a fractional dis-
play. The fraction may be reduced unless the value of
FD is true. Default value: 16.
FD
boolean (Optional; meaningful only for the last dictionary in a number format array) If true, a
fractional value formatted according to the
D entry may not have its denominator
reduced or low-order zeros truncated.
Default value:
false.
RT
text string (Optional) Text to be used between orders of thousands in display of numerical val-
ues. An empty string indicates that no text is added.
Default value: comma (“,”), the U.S. convention.
RD
text string (Optional) Text to be used as the decimal point in displaying numerical values. An
empty string indicates that the default should be used.
Default value: period (“.”), the U.S. convention.
PS
text string (Optional) Text to be concatenated to the left of the label specified by U. An empty
string indicates that no text should be added.
Default value: A single space character (“ ”).
SS
text string (Optional) Text to be concatenated after the label specified by U. An empty string in-
dicates that no text should be added.
Default value: A single space character (“ ”).
O
name (Optional) A name indicating the ordering of the label specified by U to the calculat-
ed unit value. Valid values are:
S The label is a suffix to the value.
P The label is a prefix to the value.
Note: The characters specified by
PS and SS are concatenated before considering this
entry.
Default value:
S.
KEY TYPE VALUE
Measurement PropertiesSECTION 8.8
709
To use a number format array to create a text string containing the appropriately
formatted units for display in a user interface, apply Algorithm 8.2:
Algorithm 8.2
1. The entry in the rectilinear measure dictionary (see Table 8.107) that references
the number format array determines the meaning of the initial measurement val-
ue. For example, the
X entry specifies user space units, and the T entry specifies
degrees.
2. Multiply the value specified above by the
C entry of the first number format dic-
tionary in the array, which converts the measurement to units of the largest granu-
larity specified in the array. Apply the value of
RT as appropriate.
3. If the result contains no nonzero fractional portion, concatenate the label speci-
fied by the
U entry in the order specified by O, after adding spacing from PS and
SS. The formatting is then complete.
4. If there is a nonzero fractional portion and no more elements in the array, format
the fractional portion as specified by the
RD, F, D, and FD entries of the last dictio-
nary. Concatenate the label specified by the
U entry in the order specified by O, af-
ter adding spacing from
PS and SS. The formatting is then complete.
5. If there is a nonzero fractional portion and more elements in the array, proceed to
the next number format dictionary in the array. Multiply its
C entry by the frac-
tional result from the previous step. Apply the value of
RT as appropriate. Then
proceed to step 3.
Note: The concatenation of elements in this process assumes left-to-right order. Doc-
uments using right-to-left languages can modify the process and the meaning of the
entries as appropriate to produce the correct results.
Example 8.20 shows a measure dictionary that specifies that changes in x or y are
expressed in miles; distances are expressed in miles, feet, and inches; and area is
expressed in acres. Given a sample distance in scaled units of 1.4505 miles, the
formatted text produced by applying the number format array would be
“1 mi 2,378 ft 7 5/8 in”.
Interactive FeaturesCHAPTER 8
710
Example 8.20
<</Type /Measure
/Subtype /RL
/R (1in = 0.1 mi)
/X [ <</U (mi) % x offset represented in miles
/C .00139 % Conversion from user space units to miles
/D 100000
]
/D [<< /U (mi) /C 1 >> % Distance: initial unit is miles; no conversion needed
<< /U (ft) /C 5280 >> % Conversion from miles to feet
<< /U (in) /C 12 % Conversion from feet to inches
/F /F /D 8 >> % Fractions of inches rounded to nearest 1/8
]
/A [<</U (acres) % Area: measured in acres
/C 640 >> % Conversion from square miles to acres
]
>>
711
CHAPTER 9
9Multimedia Features
This chapter describes those features of PDF that support embedding and playing
multimedia content. It contains the following sections:
• Section 9.1, “Multimedia” describes the comprehensive set of multimedia capa-
bilities that were introduced in PDF 1.5.
• Section 9.2, “Sounds,” and Section 9.3, “Movies,” describe features that have
been supported since PDF 1.2.
• Section 9.4, “Alternate Presentations,” describes a slideshow capability that was
introduced in PDF 1.4.
• Section 9.5, “3D Artwork,” describes the capability of embedding three-dimen-
sional graphics in a document, introduced in PDF 1.6.
9.1 Multimedia
PDF 1.5 introduces a comprehensive set of language constructs to enable the fol-
lowing capabilities:
• Arbitrary media types can be embedded in PDF files. (See implementation
note 144 in Appendix H for a list of media types that are recommended for use
with Acrobat 6.0 viewers).
• Embedded media, as well as referenced media outside a PDF file, can be played
with a variety of player software. (In some situations, the player software may
be the viewer application itself.)
Note: The term playing can be used with a wide variety of media, and is not re-
stricted to audio or video. For example, it may be applied to static images such as
JPEGs.
Multimedia FeaturesCHAPTER 9
712
• Media objects may have multiple renditions, which can be chosen at play-time
based on considerations such as available bandwidth.
• Document authors can control play-time requirements, such as which player
software should be used to play a given media object.
• Media objects can be played in various ways; for example, in a floating window
as well as in a region on a page.
• Future extensions to the media constructs can be handled in an appropriate
manner by current viewer applications. Authors can control how old viewers
treat future extensions.
• Document authors can adapt the use of multimedia to accessibility require-
ments.
• On-line media objects can be played efficiently, even when very large.
The following list summarizes the multimedia features and indicates where each
feature is discussed:
• Section 9.1.1, “Viability,” describes the rules for determining when media ob-
jects are suitable for playing on a particular system.
• Rendition actions (see “Rendition Actions” on page 630) are used to begin the
playing of multimedia content.
• A rendition action associates a screen annotation (see “Screen Annotations” on
page 602) with a rendition (see Section 9.1.2, “Renditions”).
• Renditions are of two varieties: media renditions (see “Media Renditions” on
page 718) that define the characteristics of the media to be played, and selector
renditions (see “Selector Renditions” on page 719) that enables choosing which
of a set of media renditions should be played.
• Media renditions contain entries that specify what should be played (see Sec-
tion 9.1.3, “Media Clip Objects”), how it should be played (see Section 9.1.4,
“Media Play Parameters”), and where it should be played (see Section 9.1.5,
“Media Screen Parameters”).
• Section 9.1.6, “Other Multimedia Objects,” describes several PDF objects that
are referenced by the major objects listed above.
MultimediaSECTION 9.1
713
Note: Some of the features described in the following sections have references to cor-
responding elements in the Synchronized Multimedia Integration Language (SMIL
2.0) standard (see the Bibliography).
9.1.1 Viability
When playing multimedia content, the viewer application must often make deci-
sions such as which player software and which options (for example, volume and
duration) to use. In making these decisions, the viewer must determine the viabil-
ity of the objects used. If an object is considered non-viable, the media should not
be played. If the object is viable, the media should be played, though possibly un-
der less than optimum conditions.
There are several entries in the multimedia object dictionaries whose values have
an effect on viability. In particular, some of the object dictionaries define two en-
tries that divide options into one of two categories:
• MH (“must honor”): The options specified by this entry must be honored; other-
wise, the containing object is considered non-viable.
• BE (“best effort”): An attempt should be made to honor the options; however, if
they cannot be honored, the containing object is still considered viable.
MH and BE are both dictionaries, and the same entries are defined for both of
them. In any dictionary where these entries are allowed, both entries may be
present, or only one, or neither. For example, the media play parameters dictio-
nary (see Table 9.14) allows the playback volume to be set by means of the
V entry
in its
MH and BE dictionaries (see Table 9.15). If the specified volume cannot be
honored, the object is considered non-viable if
V is in the MH dictionary, and
playback should not occur. If
V is in the BE dictionary (and not also in the MH
dictionary), playback should still occur: the playing software attempts to honor
the specified option as best it can.
Using this mechanism, authors can specify minimum requirements (
MH) and
preferred options (
BE). They can also specify how entries that are added in the fu-
ture to the multimedia dictionaries are interpreted by old viewer applications. If
an entry that is unrecognized by the viewer is in the
MH dictionary, the object is
considered non-viable. If an unrecognized entry is in a
BE dictionary, the entry is
ignored and viability is unaffected. Unless otherwise stated, an object should be
Multimedia FeaturesCHAPTER 9
714
considered non-viable if its MH dictionary contains an unrecognized key or an
unrecognized value for a recognized key.
The following rules apply to the entries in
MH and BE dictionaries, which behave
somewhat differently from other PDF dictionaries:
• If an entry is required, the requirement is met if the entry is present in either
the
MH dictionary or the BE dictionary.
• If an optional entry is not present in either dictionary, it is considered to be
present with its default value (if one is defined) in the
BE dictionary.
• If an instance of the same entry is present in both MH and BE, the instance in
the
BE dictionary is ignored unless otherwise specified.
• If the value of an entry in an MH or a BE dictionary is a dictionary or array, it is
treated as an atomic unit when determining viability. That is, all entries within
the dictionary or array must be honored for the containing object to be viable.
Note: When determining whether entries can be honored, it is not required that
each one be evaluated independently, since they may be dependent on one another.
That is, a viewer application or player may examine multiple entries at once (even
within different dictionaries) to determine whether their values can be honored.
The following media objects have
MH and BE dictionaries. They function as de-
scribed above, except where noted in the individual sections:
• Rendition (Table 9.2)
• Media clip data (Table 9.11)
• Media clip section (Table 9.13)
• Media play parameters (Table 9.15)
• Media screen parameters (Table 9.18)
MultimediaSECTION 9.1
715
9.1.2 Renditions
There are two types of rendition objects:
• A media rendition (see “Media Renditions” on page 718) is a basic media object
that specifies what to play, how to play it, and where to play it.
• A selector rendition (see “Selector Renditions” on page 719) contains an ordered
list of renditions. This list may include other selector renditions, resulting in a
tree whose leaves are media renditions. The viewer application should play the
first viable media rendition it encounters in the tree (see Section 9.1.1, “Viabili-
ty”).
Table 9.1 shows the entries common to all rendition dictionaries. The
N entry in a
rendition dictionary specifies a name that can be used to access the rendition ob-
ject by means of name tree lookup (see Table 3.28 on page 125). JavaScript actions
(see “JavaScript Actions” on page 668), for example, use this mechanism. Since
the values referenced by name trees must be indirect objects, it is recommended
that all rendition objects be indirect objects.
Note: A rendition dictionary is not required to have a name tree entry. When it
does, the viewer application should ensure that the name specified in the tree is kept
the same as the value of the
N entry (for example, if the user interface allows the
name to be changed). It is recommended (but not required) that a document not
contain multiple renditions with the same name.
The
MH and BE entries are dictionaries whose entries may be present in one or
the other of them, as described in Section 9.1.1, “Viability”. For renditions, these
dictionaries have a single entry
C (see Table 9.2), whose value is a media criteria
dictionary, which specifies a set of criteria that must be met for the rendition to be
considered viable (see Table 9.3).
The media criteria dictionary behaves somewhat differently than other
MH/BE
entries, as they are described in Section 9.1.1. The criteria specified by all of its
entries must be met regardless of whether they are in an
MH or a BE dictionary.
The only exception is that if an entry in a
BE dictionary is unrecognized by the
viewer application, it does not affect the viability of the object. If a media criteria
dictionary is present in both
MH and BE, the entries in both dictionaries are indi-
vidually evaluated, with
MH taking precedence (corresponding BE entries are ig-
nored).
Multimedia FeaturesCHAPTER 9
716
TABLE 9.1 Entries common to all rendition dictionaries
TABLE 9.2 Entries in a rendition MH/BE dictionary
TABLE 9.3 Entries in a media criteria dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that dictionary describes; if present, must be
Rendition for a rendition object.
S
name (Required) The type of rendition that this dictionary describes. May be MR for me-
dia rendition or
SR for selector rendition. The rendition is considered non-viable if
the viewer application does not recognize the value of this entry.
N
text string (Optional) A Unicode-encoded text string specifying the name of the rendition for
use in a user interface and for name tree lookup by JavaScript actions.
MH
dictionary (Optional) A dictionary whose entries (see Table 9.2) must be honored for the ren-
dition to be considered viable.
BE
dictionary (Optional) A dictionary whose entries (see Table 9.2) need only be honored in a
“best effort” sense.
KEY TYPE VALUE
C
dictionary (Optional) A media criteria dictionary (see Table 9.3).
Note: The media criteria dictionary behaves somewhat differently than other
MH/BE
entries described in Section 9.1.1, “Viability.” The criteria specified by all of its entries
must be met regardless of whether it is in an
MH or a BE dictionary. The only exception
is that if an entry in a
BE dictionary is unrecognized by the viewer application, it does
not affect the viability of the object.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaCriteria for a media criteria dictionary.
A
boolean (Optional) If specified, the value of this entry must match the user’s preference for
whether to hear audio descriptions in order for this object to be viable. Equivalent
to SMIL’s systemAudioDesc attribute.
C
boolean (Optional) If specified, the value of this entry must match the user’s preference for
whether to see text captions in order for this object to be viable. Equivalent to
SMIL’s
systemCaptions attribute.
MultimediaSECTION 9.1
717
TABLE 9.4 Entries in a minimum bit depth dictionary
O
boolean (Optional) If specified, the value of this entry must match the user’s preference for
whether to hear audio overdubs in order for this object to be viable.
S
boolean (Optional) If specified, the value of this entry must match the user’s preference for
whether to see subtitles in order for this object to be viable.
R
integer (Optional) If specified, the system’s bandwidth (in bits per second) must be greater
than or equal to the value of this entry in order for this object to be viable. Equiva-
lent to SMIL’s
systemBitrate attribute.
D
dictionary (Optional) A dictionary (see Table 9.4) specifying the minimum bit depth required
in order for this object to be viable. Equivalent to SMIL’s
systemScreenDepth at-
tribute.
Z
dictionary (Optional) A dictionary (see Table 9.5) specifying the minimum screen size re-
quired in order for this object to be viable. Equivalent to SMIL’s
systemScreenSize at-
tribute.
V
array (Optional) An array of software identifier objects (see “Software Identifier Dictio-
nary” on page 736). If this entry is present and non-empty, the viewer application
must be identified by one or more of the objects in the array in order for this object
to be viable.
P
array (Optional) An array containing one or two name objects specifying a minimum and
optionally a maximum PDF language version, in the same format as the
Version en-
try in the document catalog (see Table 3.25). If this entry is present and non-empty,
the version of multimedia constructs fully supported by the viewer application must
be within the specified range in order for this object to be viable.
L
array (Optional) An array of language identifiers (see “Language Identifiers” on page 865).
If this entry is present and non-empty, the language in which the viewer application
is running must exactly match a language identifier, or consist only of a primary
code that matches the primary code of an identifier, in order for this object to be vi-
able. Equivalent to SMIL’s
systemLanguage attribute.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MinBitDepth for a minimum bit depth dictionary.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
718
TABLE 9.5 Entries in a minimum screen size dictionary
Media Renditions
Table 9.6 lists the entries in a media rendition dictionary. Its entries specify what
media should be played (
C), how (P), and where (SP) it should be played. A media
rendition object is viable if and only if the objects referenced by its
C, P, and SP
entries are viable.
C can be omitted only in cases where a referenced player takes no meaningful in-
put. This requires that
P is present and that its referenced media play parameters
dictionary (see Table 9.14) contains a
PL entry, whose referenced media players
dictionary (see “Media Players Dictionary” on page 733) has a non-empty
MU ar-
ray or a non-empty
A array.
V
integer (Required) A positive integer (0 or greater) specifying the minimum screen depth
(in bits) of the monitor for the rendition to be viable. A negative value is not al-
lowed.
M
integer (Optional) A monitor specifier (see Table 9.28) that specifies which monitor the val-
ue of
V should be tested against. If the value is unrecognized, the object is not viable.
Default value: 0.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MinScreenSize for a rendition object.
V
array (Required) An array containing two non-negative integers. The width and height (in
pixels) of the monitor specified by M must be greater than or equal to the values of
the first and second integers in the array, respectively, in order for this object to be
viable.
M
integer (Optional) A monitor specifier (see Table 9.28) that specifies which monitor the val-
ue of
V should be tested against. If the value is unrecognized, the object is not viable.
Default value: 0.
KEY TYPE VALUE
MultimediaSECTION 9.1
719
TABLE 9.6 Additional entries in a media rendition dictionary
Selector Renditions
A selector rendition specifies an array of rendition objects in its R entry (see Table
9.7). The renditions in this array should be ordered by preference, with the most
preferred rendition first. At play-time, the renditions in the array are evaluated
and the first viable media rendition, if any, is played. If one of the renditions is it-
self a selector, that selector is evaluated in turn, yielding the equivalent of a depth-
first tree search. Note, however, that a selector rendition itself may be non-viable;
in this case, none of its associated media renditions are evaluated (in effect, this
branch of the tree is skipped).
This mechanism may be used, for example, to specify that a large video clip
should be used on high-bandwidth machines and a smaller clip should be used
on low-bandwidth machines.
TABLE 9.7 Additional entries specific to a selector rendition dictionary
KEY TYPE VALUE
C
dictionary (Optional) A media clip dictionary (see Section 9.1.3, “Media Clip Objects”) that
specifies what should be played when the media rendition object is played.
P
dictionary (Required if C is not present, otherwise optional) A media play parameters dictionary
(see Section 9.1.4, “Media Play Parameters”) that specifies how the media rendition
object should be played.
Default value: a media play parameters dictionary whose entries (see Table 9.14) all
contain their default values.
SP
dictionary (Optional) A media screen parameters dictionary (see Section 9.1.5, “Media Screen
Parameters”) that specifies where the media rendition object should be played.
Default value: a media screen parameters dictionary whose entries (see Table 9.17)
all contain their default values.
KEY TYPE VALUE
R
array (Required) An array of rendition objects. The first viable media rendition object
found in the array, or nested within a selector rendition in the array, should be used.
An empty array is legal.
Multimedia FeaturesCHAPTER 9
720
9.1.3 Media Clip Objects
There are two types of media clip objects, determined by the subtype S, which can
be either
MCD for media clip data (see “Media Clip Data” on page 720) or MCS for
media clip section (see “Media Clip Section” on page 723). The entries common
to all media clip dictionaries are listed in Table 9.8.
TABLE 9.8 Entries common to all media clip dictionaries
Media Clip Data
A media clip data dictionary defines the data for a media object that can be
played. For example, it may reference a URL to a streaming video presentation or
a movie embedded in the PDF file. Its entries are listed in Table 9.9.
TABLE 9.9 Additional entries in a media clip data dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaClip for a media clip dictionary.
S
name (Required) The subtype of media clip that this dictionary describes. May be MCD for
media clip data (see “Media Clip Data” on page 720) or
MCS for a media clip section
(see “Media Clip Section” on page 723). The media clip is considered non-viable if
the viewer application does not recognize the value of this entry.
N
text string (Optional) The name of the media clip, for use in the user interface.
KEY TYPE VALUE
D
file specification
or stream
(Required) A full file specification or form XObject that specifies the actual media
data.
CT
string (Optional; not allowed for form XObjects) A string identifying the type of data in D.
The string should conform to the content type specification described in Internet
RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of In-
ternet Message Bodies (see the Bibliography).
P
dictionary (Optional) A media permissions dictionary (see Table 9.10) containing permissions
that control the use of the media data. Default value: a media permissions dictio-
nary containing default values.
MultimediaSECTION 9.1
721
The media clip data object must be considered non-viable if the object referenced
by the
D entry does not contain a Type entry, the Type entry is unrecognized, or
the referenced object is not a dictionary or stream. Note that this excludes the use
of simple file specifications (see Section 3.10, “File Specifications”).
If
D references a file specification that has an embedded file stream (see Section
3.10.3, “Embedded File Streams”), the embedded file stream’s
Subtype entry is ig-
nored if present, and the media clip data dictionary’s
CT entry identifies the type
of data.
If
D references a form XObject, the associated player is implicitly the viewer ap-
plication, and the form XObject should be rendered as if it were any other data
type. For example, the
F and D entries in the media play parameters dictionary
(see Table 9.14) apply to a form XObject just as they do to a QuickTime movie.
For media other than form XObjects, the media clip object must provide enough
information to allow a viewer application to locate an appropriate player. This can
be done by providing one or both of the following entries:
• A CT entry that specifies the content type of the media (the preferred method).
If this entry is present, any player that is selected must support this content
type.
• A PL entry that specifies one or more players that can be used to play the refer-
enced media. It is highly recommended if
CT is present. However, see imple-
mentation note 145 in Appendix H.
Alt
array (Optional) An array that provides alternate text descriptions for the media clip data
in case it cannot be played; see “Multi-language Text Arrays” on page 869.
PL
dictionary (Optional) A media players dictionary (see “Media Players Dictionary” on page 733)
that identifies, among other things, players that are legal and not legal for playing
the media.
Note: If the media players dictionary is non-viable, the media clip data is non-viable.
MH
dictionary (Optional) A dictionary whose entries (see Table 9.11) must be honored for the me-
dia clip data to be considered viable.
BE
dictionary (Optional) A dictionary whose entries (see Table 9.11) need only be honored in a
“best effort” sense.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
722
The P entry specifies a media permissions dictionary (see Table 9.10), which spec-
ifies the manner in which the data referenced by the media may be used by a
viewer application. These permissions allow authors control over how their data
is exposed to operations that could allow it to be copied. If the dictionary con-
tains unrecognized entries or entries with unrecognized values, it should be con-
sidered non-viable, and the viewer application should not play the media.
TABLE 9.10 Entries in a media permissions dictionary
The BU entry in the media clip data MH and BE dictionaries (see Table 9.11) spec-
ifies a base URL for the media data. Relative URLs in the media (which point to
auxiliary files or are used for hyperlinking, for example) should be resolved with
respect to the value of
BU. The following should be noted about the BU entry:
• If BU is in the MH dictionary and the base URL is not honored (for example, the
player does not accept base URLs), the media clip data is non-viable.
• Determining the viability of the object does not require checking whether the
base URL is valid (for example, that the target host exists).
• Absolute URls within the media are not affected.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaPermissions for a media permissions dictionary.
TF
string (Optional) A string indicating the circumstances under which it is acceptable to
write a temporary file in order to play a media clip. Valid values are:
(TEMPNEVER) Never allowed.
(TEMPEXTRACT) Allowed only if the document permissions allow content
extraction; for example, when bit 5 of the user access
permissions (see Table 3.20) is set.
(TEMPACCESS) Allowed only if the document permissions allow content
extraction, including for accessibility purposes; for example,
when bits 5 or 10 of the user access permissions (see Table
3.20) are set, or both.
(TEMPALWAYS) Always allowed.
Default value:
(TEMPNEVER).
An unrecognized value is treated as
(TEMPNEVER).
MultimediaSECTION 9.1
723
• If the media itself contains a base URL (for example, the <BASE> element is de-
fined in HTML), that value is used in preference to
BU.
• BU is completely independent of and unrelated to the value of the URI entry in
the document catalog (see Section 3.6.1, “Document Catalog”).
• If BU is not present and the media is embedded within the document, the URL
to the PDF file itself should be used as if it were the value of a
BU entry in the BE
dictionary; that is, as an implicit best-effort base URL.
TABLE 9.11 Entries in a media clip data MH/BE dictionary
Media Clip Section
A media clip section dictionary (see Table 9.12) defines a continuous section of
another media clip object (known as the next-level media clip object). For exam-
ple, a media clip section could define a 15-minute segment of a media clip data
object representing a two-hour movie. The next-level media clip object, specified
by the
D entry, can be either a media clip data object or another media clip sec-
tion object. However, the linked list formed by the
D entries of media clip sec-
tions must terminate in a media clip data object. If the next-level media object is
non-viable, the media clip section is also non-viable.
TABLE 9.12 Additional entries in a media clip section dictionary
KEY TYPE VALUE
BU
string (Optional) An absolute URL to be used as the base URL in resolving any relative
URLs found within the media data.
KEY TYPE VALUE
D
dictionary (Required) The media clip section or media clip data object (the next-level media
object) of which this media clip section object defines a continuous section.
Alt
array (Optional) An array that provides alternate text descriptions for the media clip sec-
tion in case it cannot be played; see “Multi-language Text Arrays” on page 869.
MH
dictionary (Optional) A dictionary whose entries (see Table 9.13) must be honored for the me-
dia clip section to be considered viable.
BE
dictionary (Optional) A dictionary whose entries (see Table 9.13) need only be honored in a
“best effort” sense.
Multimedia FeaturesCHAPTER 9
724
The B and E entries in the media clip section’s MH and BE dictionaries (see Table
9.13) define a subsection of the next-level media object referenced by
D by speci-
fying beginning and ending offsets into it. Depending on the media type, the off-
sets may be specified by time, frames, or markers (see “Media Offset Dictionary”
on page 732).
B and E are not required to specify the same type of offset.
The following rules apply to these offsets:
• For media types where an offset makes no sense (such as JPEG images), B and E
are ignored, with no effect on viability.
• When B or E are specified by time or frames, their value is considered to be rel-
ative to the start of the next-level media clip. However, if
E specifies an offset
beyond the end of the next-level media clip, the end value is used instead, and
there is no effect on viability.
• When B or E are specified by markers, there is a corresponding absolute offset
into the underlying media clip data object. If this offset is not within the range
defined by the next-level media clip (if any), or if the marker is not present in
the underlying media clip, the existence of the entry is ignored, and there is no
effect on viability.
• If the absolute offset derived from the values of all B entries in a media clip sec-
tion chain is greater than or equal to the absolute offset derived from the values
of all
E entries, an empty range is defined. An empty range is legal.
• Any B or E entry in a media clip section’s MH dictionary must be honored at
play-time in order for the media clip section to be considered viable. (The entry
might not be honored if its value was not viable or if the player did not support
its value; for example, the player did not support markers.)
• If a B or E entry is in a media clip section’s MH dictionary, all B or E entries, re-
spectively, at deeper levels (closer to the media clip data), are evaluated as if
they were in an
MH dictionary (even if they are actually within BE dictionaries).
• If B or E entry in a BE dictionary cannot be supported, it may be ignored at
play-time.
MultimediaSECTION 9.1
725
TABLE 9.13 Entries in a media clip section MH/BE dictionary
9.1.4 Media Play Parameters
A media play parameters dictionary specifies how a media object should be
played. It is referenced from a media rendition (see “Media Renditions” on page
718).
TABLE 9.14 Entries in a media play parameters dictionary
KEY TYPE VALUE
B
dictionary (Optional) A media offset dictionary (see “Media Offset Dictionary” on page 732)
that specifies the offset into the next-level media object at which the media clip sec-
tion begins. Default: the start of the next-level media object.
E
dictionary (Optional) A media offset dictionary (see “Media Offset Dictionary” on page 732)
that specifies the offset into the next-level media object at which the media clip sec-
tion ends. Default: the end of the next-level media object.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaPlayParams for a media play parameters dictionary.
PL
dictionary (Optional) A media players dictionary (see “Media Players Dictionary” on page 733)
that identifies, among other things, players that are legal and not legal for playing
the media.
Note: If this object is non-viable, the media play parameters dictionary is considered
non-viable.
MH
dictionary (Optional) A dictionary whose entries (see Table 9.13) must be honored for the me-
dia play parameters to be considered viable.
BE
dictionary (Optional) A dictionary whose entries (see Table 9.13) need only be honored in a
“best effort” sense.
Multimedia FeaturesCHAPTER 9
726
TABLE 9.15 Entries in a media play parameters MH/BE dictionary
KEY TYPE VALUE
V
integer (Optional) An integer that specifies the desired volume level as a percentage of re-
corded volume level. A zero value is equivalent to mute; negative values are illegal.
Default value: 100.
C
boolean (Optional) A flag specifying whether to display a player-specific controller user in-
terface (for example, play/pause/stop controls) when playing. Default value:
false
F
integer‘ (Optional) The manner in which the player should treat a visual media type that
does not exactly fit the rectangle in which it plays.
0 The media’s width and height are scaled while preserving the aspect ratio
so that the media and play rectangles have the greatest possible
intersection while still displaying all media content. Same as “meet” value
of SMIL’s
fit attribute.
1 The media’s width and height are scaled while preserving the aspect ratio
so that the play rectangle is entirely filled, and the amount of media
content that does not fit within the play rectangle is minimized. Same as
“slice” value of SMIL’s
fit attribute.
2 The media’s width and height are scaled independently so that the media
and play rectangles are the same; the aspect ratio is not necessarily
preserved. Same as “fill” value of SMIL’s
fit attribute.
3 The media is not scaled. A scrolling user interface is provided if the media
rectangle is wider or taller than the play rectangle. Same as “scroll” value of
SMIL’s
fit attribute.
4 The media is not scaled. Only the portions of the media rectangle that
intersect the play rectangle are displayed. Same as “hidden” value of SMIL’s
fit attribute.
5 Use the player’s default setting (author has no preference).
Default value: 5.
An unrecognized value should be treated as the default value if the entry is in a
BE
dictionary. If the entry is in an MH dictionary and it has an unrecognized value, the
object should be considered non-viable.
D
dictionary (Optional) A media duration dictionary (see Table 9.16). Default value: a dictionary
specifying the intrinsic duration (see below).
A
boolean (Optional) If true, the media should automatically play when activated. If false, the
media should be initially paused when activated (for example, the first frame is dis-
played). Relevant only for media that may be paused. Default value:
true.
MultimediaSECTION 9.1
727
The value of the D entry is a media duration dictionary, whose entries are shown
in Table 9.16. It specifies a temporal duration (which corresponds to the notion of
a simple duration in SMIL). The duration may be a specific amount of time, it
may be infinity, or it may be the media’s intrinsic duration (for example, the in-
trinsic duration of a two-hour QuickTime movie is two hours). The intrinsic du-
ration may be modified when a media clip section (see “Media Clip Section” on
page 723) is used: the intrinsic duration is the difference between the absolute be-
gin and end offsets. For a media type having no notion of time (such as a JPEG
image), the duration is considered to be infinity.
If the simple duration is longer than the intrinsic duration, the player should
freeze the media in its final state until the simple duration has elapsed. For visual
media types, the last appearance (frame) would be displayed. For aural media
types, the media is logically frozen but should not continue to produce sound.
Note: In this case, the
RC entry, which specifies a repeat count, applies to the simple
duration; therefore, the entire play-pause sequence is repeated
RC times.
TABLE 9.16 Entries in a media duration dictionary
RC
number (Optional) Specifies the number of iterations of the duration D to repeat; similar to
SMIL’s
repeatCount attribute. Zero means repeat forever. Negative values are illegal;
non-integral values are legal. Default value: 1.0.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaDuration for a media duration dictionary.
S
name (Required) The subtype of media duration dictionary. Valid values are:
I The duration is the intrinsic duration of the associated media
F The duration is infinity
T The duration is specified by the T entry
The media duration dictionary is considered non-viable if the viewer application
does not recognize the value of this entry.
T
dictionary (Required if the value of S is T; otherwise ignored) A timespan dictionary specifying
an explicit duration (see Table 9.24). A negative duration is illegal.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
728
9.1.5 Media Screen Parameters
A media screen parameters dictionary (see Table 9.17) specifies where a media
object should be played. It contains
MH and BE dictionaries (see Table 9.18),
which function as discussed in Section 9.1.1, “Viability.” All media clips that are
being played are associated with a particular document and must be stopped
when the document is closed.
Note: It is recommended that viewer applications disallow floating windows and
full-screen windows unless specifically allowed by the user. The reason is that docu-
ment-based security attacks are possible if windows containing arbitrary media con-
tent can be displayed without indicating to the user that the window is merely
hosting a media object. This recommendation may be relaxed if it is possible to com-
municate the nature of such windows to the user; for example, with text in a float-
ing window’s title bar.
TABLE 9.17 Entries in a media screen parameters dictionary
TABLE 9.18 Entries in a media screen parameters MH/BE dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaScreenParams for a media screen parameters dictionary.
MH
dictionary (Optional) A dictionary whose entries (see Table 9.18) must be honored for the me-
dia screen parameters to be considered viable.
BE
dictionary (Optional) A dictionary whose entries (see Table 9.18) need only be honored in a
“best effort” sense.
KEY TYPE VALUE
W
integer (Optional) The type of window that the media object should play in:
0A floating window
1 A full-screen window that obscures all other windows
2A hidden window
3 The rectangle occupied by the screen annotation (see “Screen
Annotations” on page 602) associated with the media rendition
Default value: 3. Unrecognized value in
MH: object is non-viable; in BE: treat as de-
fault value.
MultimediaSECTION 9.1
729
The F entry in the media screen parameters MH/BE dictionaries is a floating win-
dow parameters dictionary, whose entries are listed in Table 9.19. The entries in
the floating window parameters dictionary are treated as if they were present in
the
MH or BE dictionaries that they are referenced from. That is, the contained
entries are individually evaluated for viability rather than the dictionary being
evaluated as a whole. (There may be an
F entry in both MH and BE. In such a case,
if a given entry is present in both floating window parameters dictionaries, the
one in the
MH dictionary takes precedence.)
B
array (Optional) An array of three numbers in the range 0.0 to 1.0 specifying the compo-
nents in the
DeviceRGB color space of the background color for the rectangle in
which the media is being played. This color is used if the media object does not en-
tirely cover the rectangle or if it has transparent sections. Ignored for hidden win-
dows.
Default value: implementation-defined. The viewer application should choose a
reasonable value based on the value of
W; for example, a system default background
color for floating windows or a user-preferred background color for full-screen
windows.
Note: If a media format has an intrinsic background color,
B does not override it.
However, the
B color is visible if the media has transparent areas or otherwise does not
cover the entire window.
O
number (Optional) A number in the range 0.0 to 1.0 specifying the constant opacity value to
be used in painting the background color specified by
B. A value below 1.0 means
the window is transparent; for example, windows behind a floating window show
through if the media does not cover the entire floating window. A value of 0.0 indi-
cates full transparency and makes
B irrelevant. Ignored for full-screen and hidden
windows.
Default value: 1.0 (fully opaque).
M
integer (Optional) A monitor specifier (see Table 9.28) that specifies which monitor in a
multi-monitor system a floating or full-screen window should appear on. Ignored
for other types.
Default value: 0 (document monitor). Unrecognized value in
MH: object is non-via-
ble; in
BE: treat as default value.
F
dictionary (Required if the value of W is 0; otherwise ignored) A floating window parameters
dictionary (see Table 9.19) specifying the size, position, and options used in display-
ing floating windows.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
730
The D, P, and RT entries are used to specify the rectangle that the floating window
occupies. Once created, the floating window’s size and position are not tied to any
other window, even if the initial size or position was computed relative to other
windows.
Unrecognized values for the
R, P, RT, and O entries are handled as follows: if they
are nested within an
MH dictionary, the floating window parameters object (and
hence the media screen parameters object) must be considered non-viable; if they
are nested within a
BE dictionary, they should be considered to have their default
values.
TABLE 9.19 Entries in a floating window parameters dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
FWParams for a floating window parameters dictionary.
D
array (Required) An array containing two non-negative integers representing the floating
window’s width and height, in pixels, respectively. These values correspond to the
dimensions of the rectangle in which the media will play, not including such items
as title bar and resizing handles.
RT
integer (Optional) The window relative to which the floating window should be positioned:
0The document window
1 The application window
2 The full virtual desktop
3 The monitor specified by
M in the media screen parameters MH or
BE dictionary (see 9.22)
Default value: 0.
MultimediaSECTION 9.1
731
P
integer (Optional) The location where the floating window (including such items as title bar
and resizing handles) should be positioned relative to the window specified by
RT:
0 Upper-left corner
1 Upper center
2 Upper-right corner
3Center left
4Center
5 Center right
6 Lower-left corner
7 Lower center
8Lower-right corner
Default value: 4.
O
integer (Optional) Specifies what should occur if the floating window is positioned totally
or partially offscreen (that is, not visible on any physical monitor):
0 Take no special action
1 Move and/or resize the window so that it is on-screen
2 Consider the object to be non-viable
Default value: 1
T
boolean (Optional) If true, the floating window should have a title bar. Default value: true.
UC
boolean (Optional; meaningful only if T is true) If true, the floating window should include
user interface elements that allow a user to close a floating window.
Default value:
true
R
integer (Optional) Specifies whether the floating window may be resized by a user:
0 May not be resized
1 May be resized only if aspect ratio is preserved
2 May be resized without preserving aspect ratio
Default value: 0.
TT
array (Optional; meaningful only if T is true) An array providing text to display on the
floating window’s title bar. See “Multi-language Text Arrays” on page 869. If this en-
try is not present, the viewer application may provide default text.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
732
Media Offset Dictionary
A media offset dictionary (Table 9.20) specifies an offset into a media object. The
S (subtype) entry indicates how the offset is specified: in terms of time (for exam-
ple, “10 seconds”), frames (for example, “frame 20”) or markers (for example,
“Chapter One”). Different media types support different types of offsets.
TABLE 9.20 Entries common to all media offset dictionaries
TABLE 9.21 Additional entries in a media offset time dictionary
TABLE 9.22 Additional entries in a media offset frame dictionary
TABLE 9.23 Additional entries in a media offset marker dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaOffset for a media offset dictionary.
S
name (Required) The subtype of media offset dictionary. Valid values are:
T A media offset time dictionary (see Table 9.21)
F A media offset frame dictionary (see Table 9.22)
M A media offset marker dictionary (see Table 9.23)
The rendition is considered non-viable if the viewer application does not recognize
the value of this entry.
KEY TYPE VALUE
T
dictionary (Required) A timespan dictionary (see Table 9.24) that specifies a temporal offset
into a media object. Negative timespans are not allowed in this context. The media
offset time dictionary is non-viable if its timespan dictionary is non-viable.
KEY TYPE VALUE
F
integer (Required) Specifies a frame within a media object. Frame numbers begin at 0; neg-
ative frame numbers are not allowed.
KEY TYPE VALUE
M
text string (Required) A text string that identifies a named offset within a media object.
MultimediaSECTION 9.1
733
Timespan Dictionary
A timespan dictionary specifies a length of time; its entries are shown in Table
9.24.
TABLE 9.24 Entries in a timespan dictionary
9.1.6 Other Multimedia Objects
This section defines several dictionary types that are referenced by the previous
sections.
Media Players Dictionary
A media players dictionary can be referenced by media clip data (see “Media Clip
Data” on page 720) and media play parameters (see Section 9.1.4, “Media Play Pa-
rameters”) dictionaries, and allows them to specify which players may or may not
be used to play the associated media. The media players dictionary references
media player info dictionaries (see “Media Player Info Dictionary,” below) that
provide specific information about each player.
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
Timespan for a timespan dictionary.
S
name (Required) The subtype of timespan dictionary. The only value currently allowed is
S (simple timespan). The rendition is considered non-viable if the viewer applica-
tion does not recognize the value of this entry.
V
number (Required) The number of seconds in the timespan. Non-integral values are al-
lowed. Negative values are allowed, but may be disallowed in some contexts (all sit-
uations defined in PDF 1.5 disallow negative values).
Note: This entry is required only if the value of the
S entry is S. Subtypes defined in the
future need not use this entry.
Multimedia FeaturesCHAPTER 9
734
TABLE 9.25 Entries in a media players dictionary
The MU, A, and NU entries each specify one or more media player info objects.
(An empty array is treated as if it is not present.) The media player info objects
are allowed to specify overlapping player ranges (for example,
MU could contain a
media player info dictionary describing versions 1 to 10 of Player X and another
describing versions 3 through 5 of Player X).
If a non-viable media player info object is referenced by
MU, NU, or A, it is treated
as if it were not present in its original array, and a media player info object con-
taining the same software identifier dictionary (see “Software Identifier Dictio-
nary” on page 736) is logically considered to be present in
NU. The same rule
applies to a media player info object that contains a partially unrecognized soft-
ware identifier dictionary.
Since both media clip data and media play parameters dictionaries can be em-
ployed in a play operation, and each can reference a media players dictionary,
there is a potential for conflict between the contents of the two media players dic-
tionaries. At play-time, the viewer should use the following algorithm to deter-
mine whether a player present on the machine can be employed. The player
cannot be used if any of the following conditions are true:
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaPlayers for a media players dictionary.
MU
array (Optional) An array of media player info objects (see Table 9.26) that specify a set of
players, one of which must be used in playing the associated media object.
Note: Any players specified in
NU are effectively removed from MU. (For example, if
MU specifies versions 1 through 5 of a player and NU specifies versions 1 and 2 of the
same player,
MU is effectively versions 3 through 5.)
A
array (Optional) An array of media player info objects (see Table 9.26) that specify a set of
players, any of which may be used in playing the associated media object. If
MU is
also present and non-empty,
A is ignored.
NU
array (Optional) An array of media player info objects (see Table 9.26) that specify a set of
players that must not be used in playing the associated media object (even if they are
also specified in
MU).
MultimediaSECTION 9.1
735
Algorithm 9.1
1. The content type is known and the player does not support the type.
2. The player is found in the
NU array of either dictionary.
3. Both dictionaries have non-empty
MU arrays and the player is not found in both
of them, or only one of the dictionaries has a non-empty
MU array and the player
is not found in it.
4. Neither dictionary has a non-empty
MU array, the content type is not known, and
the player is not found in the
A array of either dictionary.
If none of the conditions are true, the player can be used.
Note: A player is “found” in the
NU, MU, or A arrays if it matches the information
found in the PID entry of one of the entries, as described by Algorithm 9.2.
Media Player Info Dictionary
A media player info dictionary provides a variety of information regarding a spe-
cific media player. Its entries (see Table 9.26) allow information to be associated
with a particular version or range of versions of a player. As of PDF 1.5, only the
PID entry provides information about the player, as described in the next section,
“Software Identifier Dictionary”.
TABLE 9.26 Entries in a media player info dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
MediaPlayerInfo for a media player info dictionary.
PID
dictionary (Required) A software identifier object (see “Software Identifier Dictionary,” below)
that specifies the player name, versions, and operating systems to which this media
player info object applies.
MH
dictionary (Optional) A dictionary containing entries that must be honored for this object to
be considered viable
Note: Currently, there are no defined entries for this dictionary
BE
dictionary (Optional) A dictionary containing entries that need only be honored in a “best ef-
fort” sense.
Note: Currently, there are no defined entries for this dictionary
Multimedia FeaturesCHAPTER 9
736
Software Identifier Dictionary
A software identifier dictionary allows software to be identified by name, range of
versions, and operating systems; its entries are listed in Table 9.27. A viewer appli-
cation uses this information to determine whether a given media player can be
used in a given situation. If the dictionary contains keys that are unrecognized by
the viewer application, it is considered to be partially recognized. The viewer ap-
plication may or may not decide to treat the software identifier as viable, depend-
ing on the context in which it is used.
The following procedure is used to determine whether a piece of software is con-
sidered to match a software identifier object:
Algorithm 9.2
1. The software name must match the name specified by the U entry (see “Software
URIs,” below).
2. The software version must be within the interval specified by the
L, H, LI, and H1
entries (see “Version arrays,” below).
3. The machine’s operating system name must be an exact match for one present in
the
OS array. If the array is not present or empty, a match is also considered to ex-
ist.
TABLE 9.27 Entries in a software identifier dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
SoftwareIdentifier for a software identifier dictionary.
U
string (Required) A URI that identifies a piece of software (see “Software URIs,” below).
L
array (Optional) The lower bound of the range of software versions that this software
identifier object specifies (see “Version arrays,” below). Default value: the array
[0].
LI
boolean (Optional) If true, the lower bound of the interval defined by L and H is inclusive;
that is, the software version must be greater than or equal to
L (see “Version arrays,”
below). If
false, it is not inclusive. Default value: true.
H
array (Optional) The upper bound of the range of software versions that this software
identifier object specifies (see “Version arrays,” below). Default value: an empty ar-
ray
[].
MultimediaSECTION 9.1
737
Software URIs
The U entry is a URI (universal resource identifier) that identifies a piece of soft-
ware. It is interpreted according to its scheme; the only presently defined scheme
is
vnd.adobe.swname. The scheme name is case-insensitive; if is not recognized by
the viewer application, the software must be considered a non-match. The syntax
of URIs of this scheme is
“vnd.adobe.swname:” software_name
where software_name is equivalent to reg_name as defined in Internet RFC 2396,
Uniform Resource Identifiers (URI): Generic Syntax; see the Bibliography.
software_name is considered to be a sequence of UTF-8-encoded characters that
have been escaped with one pass of URL escaping (see “URL Strings” on page
878). That is, to recover the original software name,
software_name must be unes-
caped and then treated as a sequence of UTF-8 characters. The actual software
names must be compared in a case-sensitive fashion.
Software names are second-class names (see Appendix E). For example, the URI
for Acrobat is
vnd.adobe.swname:ADBE_Acrobat
Version arrays
The L, H, LI, and HI entries are used to specify a range of software versions. L and
H are version arrays containing zero or more non-negative integers representing
subversion numbers. The first integer is the major version numbers, and subse-
HI
boolean (Optional) If true, the upper bound of the interval defined by L and H is inclusive;
that is, the software version must be less than or equal to
H (see “Version arrays,” be-
low). If
false, it is not inclusive. Default value: true.
OS
array (Optional) An array of strings representing operating system identifiers that indi-
cate which operating systems this object applies to. The defined values are the same
as those defined for SMIL 2.0’s
systemOperatingSystem attribute. There may not be
multiple copies of the same identifier in the array. An empty array is considered to
represent all operating systems. Default value: an empty array.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
738
quent integers are increasingly minor. H must be greater than or equal to L, ac-
cording to the following rules for comparing version arrays:
Algorithm 9.3 Comparing version arrays
1. An empty version array is treated as infinity; that is, it is considered greater than
any other version array except another empty array. Two empty arrays are equal.
2. When comparing arrays that contain different numbers of elements, the smaller
array is implicitly padded with zero-valued integers to make the number of ele-
ments equal. For example, when comparing
[5 1 2 3 4] to [5], the latter is treated as
[5 0 0 0 0].
3. The corresponding elements of the arrays are compared, starting with the first.
When a difference is found, the array containing the larger element is considered
to have the larger version number. If no differences are found, the versions are
equal.
Note: If a version array contains negative numbers, it is considered non-viable, as
is the enclosing software identifier.
Monitor Specifier
A monitor specifier is an integer that identifies a physical monitor attached to a
system. It can have one of the values in Table 9.28:
TABLE 9.28 Monitor specifier values
VALUE DESCRIPTION
0 The monitor containing the largest section of the document window
1 The monitor containing the smallest section of the document window
2 Primary monitor. If no monitor is considered primary, use case 0
3 Monitor with the greatest color depth
4 Monitor with the greatest area (in pixels squared)
5 Monitor with the greatest height (in pixels)
6 Monitor with the greatest width (in pixels)
SoundsSECTION 9.2
739
For some of these values, it is possible have a “tie” at play-time; for example, two
monitors might have the same color depth. Ties are broken in an implementa-
tion-dependent manner.
9.2 Sounds
A sound object (PDF 1.2) is a stream containing sample values that define a sound
to be played through the computer’s speakers. The
Sound entry in a sound anno-
tation or sound action dictionary (see Table 8.32 on page 601 and Table 8.54 on
page 625) identifies a sound object representing the sound to be played when the
annotation is activated.
Since a sound object is a stream, it can contain any of the standard entries com-
mon to all streams, as described in Table 3.4 on page 38. In particular, if it con-
tains an
F (file specification) entry, the sound is defined in an external file. This
sound file must be self-describing, containing all information needed to render
the sound; no additional information need be present in the PDF file.
Note: The AIFF, AIFF-C (Mac OS), RIFF (
.wav), and snd (.au) file formats are all
self-describing.
If no
F entry is present, the sound object itself contains the sample data and all
other information needed to define the sound. Table 9.29 shows the additional
dictionary entries specific to a sound object.
TABLE 9.29 Additional entries specific to a sound object
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
Sound for a sound object.
R
number (Required) The sampling rate, in samples per second.
C
integer (Optional) The number of sound channels. Default value: 1. (See implementation
note 146 in Appendix H.)
B
integer (Optional) The number of bits per sample value per channel. Default value: 8.
Multimedia FeaturesCHAPTER 9
740
Sample values are stored in the stream with the most significant bits first (big-en-
dian order for samples larger than 8 bits). Samples that are not a multiple of 8 bits
are packed into consecutive bytes, starting at the most significant end. If a sample
extends across a byte boundary, the most significant bits are placed in the first
byte, followed by less significant bits in subsequent bytes. For dual-channel ste-
reophonic sounds, the samples are stored in an interleaved format, with each
sample value for the left channel (channel 1) preceding the corresponding sample
for the right (channel 2).
To maximize the portability of PDF documents containing embedded sounds, it
is recommended that PDF viewer applications and plug-in extensions support at
least the following formats (assuming the platform has sufficient hardware and
OS support to play sounds at all):
R 8000, 11,025, or 22,050 samples per second
C 1 or 2 channels
B 8 or 16 bits per channel
E Raw, Signed, or muLaw encoding
If the encoding (
E) is Raw or Signed, R must be 11,025 or 22,050 samples per
channel. If the encoding is
muLaw, R must be 8000 samples per channel, C must
be 1 channel, and
B must be 8 bits per channel. Sound players should be prepared
E
name (Optional) The encoding format for the sample data:
Raw Unspecified or unsigned values in the range 0 to 2
B
1
Signed Twos-complement values
muLaw µ-law–encoded samples
ALaw A-law–encoded samples
Default value:
Raw.
CO
name (Optional) The sound compression format used on the sample data. (This is separate
from any stream compression specified by the sound object’s
Filter entry; see Table
3.4 on page 38 and Section 3.3, “Filters.”) If this entry is absent, no sound compres-
sion has been used; the data contains sampled waveforms to be played at
R samples
per second per channel.
CP
(various) (Optional) Optional parameters specific to the sound compression format used.
Note: At the time of publication, no standard values have been defined for the
CO and
CP entries.
KEY TYPE VALUE
MoviesSECTION 9.3
741
to convert between formats, downsample rates, and combine channels as neces-
sary to render sound on the target platform.
9.3 Movies
Note: The features described in this section are obsolescent and their use is no longer
recommended. They are superseded by the general multimedia framework described
in Section 9.1, “Multimedia.”
PDF includes the ability to embed movies within a document by means of movie
annotations (see “Movie Annotations” on page 601). Despite the name, a movie
may consist entirely of sound with no visible images to be displayed on the
screen. The
Movie and A (activation) entries in the movie annotation dictionary
refer, respectively, to a movie dictionary (Table 9.30) describing the static charac-
teristics of the movie and a movie activation dictionary (Table 9.31) specifying
how it should be presented.
TABLE 9.30 Entries in a movie dictionary
KEY TYPE VALUE
F
file specification (Required) A file specification identifying 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) The width and height of the movie’s bounding box, in pixels, spec-
ified as
[width height ]. This entry should be omitted for a movie consisting
entirely of sound with no visible images. See implementation note 147 in Ap-
pendix H.
Rotate
integer (Optional) The number of degrees by which the movie is rotated clockwise
relative to the page. The value must be a multiple of 90. Default value: 0.
Poster
boolean or stream (Optional) A flag or stream specifying whether and how to display a poster
image representing the movie. If this value is a stream, it contains an image
XObject (see Section 4.8, “Images”) to be displayed as the poster. If it is the
boolean value
true, the poster image should be retrieved from the movie file;
if it is
false, no poster should be displayed. See implementation note 148 in
Appendix H. Default value:
false.
Multimedia FeaturesCHAPTER 9
742
TABLE 9.31 Entries in a movie activation dictionary
KEY TYPE VALUE
Start
(various) (Optional) The starting time of the movie segment to be played. Movie time
values are expressed in units of time based on a time scale, which defines the
number of units per second. The default time scale is defined in the movie
data. The starting time is nominally a non-negative 64-bit integer, specified
as follows:
• If it is representable as an integer (subject to the implementation limit for
integers, as described in Appendix C), it should be specified as such.
• If it is not representable as an integer, it should be specified as an 8-byte
string representing a 64-bit twos-complement integer, most significant
byte first.
• If it is expressed in a time scale different from that of the movie itself, it is
represented as an array of two values: an integer or string denoting the
starting time, as above, followed by an integer specifying the time scale in
units per second.
If this entry is omitted, the movie is played from the beginning.
Duration
(various) (Optional) The duration of the movie segment to be played, specified in the
same form as
Start. If this entry is omitted, the movie is played to the end.
Rate
number (Optional) The initial speed at which to play the movie. If the value of this en-
try is negative, the movie is played backward with respect to
Start and
Duration. Default value: 1.0.
Volume
number (Optional) The initial sound volume at which to play the movie, in the range
1.0 to 1.0. Higher values denote greater volume; negative values mute the
sound. Default value: 1.0.
ShowControls
boolean (Optional) A flag specifying whether to display a movie controller bar while
playing the movie. Default value:
false.
Mode
name (Optional) The play mode for playing the movie:
Once Play once and stop.
Open Play and leave the movie controller bar open.
Repeat Play repeatedly from beginning to end until stopped.
Palindrome Play continuously forward and backward until stopped.
Default value:
Once.
Alternate PresentationsSECTION 9.4
743
9.4 Alternate Presentations
Beginning with PDF 1.4, a PDF document may contain alternate presentations,
which specify alternate ways in which the document may be viewed. The optional
AlternatePresentations entry (PDF 1.4) in a document’s name dictionary (see Ta-
ble 3.28) contains a name tree that maps name strings to the alternate presenta-
tions available for the document.
Note: Since PDF viewers are not required to support alternate presentations, au-
thors of documents containing alternate presentations should define the files such
that something useful and meaningful can be displayed and printed. For example, if
the document contains an alternate presentation slideshow of a sequence of photo-
graphs, the photographs should be viewable in a static form by viewers that are not
capable of playing the slideshow.
Synchronous
boolean (Optional) A flag specifying whether to play the movie synchronously or
asynchronously. If this value is
true, the movie player retains control until the
movie is completed or dismissed by the user. If the value is
false, the player
returns control to the viewer application immediately after starting the mov-
ie. Default value:
false.
FWScale
array (Optional) The magnification (zoom) factor at which to play the movie. The
presence of this entry implies that the movie is to be played in a floating win-
dow. If the entry is absent, the movie is played in the annotation rectangle.
The value of the entry is an array of two positive integers,
[numerator denominator], denoting a rational magnification factor for the
movie. (See implementation note 149 in Appendix H.) The final window size,
in pixels, is
(
numerator ÷ denominator) × Aspect
where the value of Aspect is taken from the movie dictionary (see Table 9.30).
FWPosition
array (Optional) For floating play windows, the relative position of the window on
the screen. The value is an array of two numbers
[horiz vert]
each in the range 0.0 to 1.0, denoting the relative horizontal and vertical posi-
tion of the movie window with respect to the screen. For example, the value
[0.5 0.5] centers the window on the screen. See implementation note 150 in
Appendix H. Default value:
[0.5 0.5].
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
744
As of PDF 1.5, the only type of alternate presentation is a slideshow. Slideshows
are typically invoked by means of JavaScript actions (see “JavaScript Actions” on
page 668”) initiated by user action on an interactive form element (see Section
8.6, “Interactive Forms”). Implementation note 151 in Appendix H describes Ac-
robat’s implementation of slideshows.
The following table shows the entries in a slideshow dictionary.
TABLE 9.32 Entries in a slideshow dictionary
The Resources name tree represents a virtual file system to the slideshow. It asso-
ciates strings (“file names”) with PDF objects that represent resources used by the
slideshow. For example, a root stream might reference a file name, which would
be looked up in the
Resources name tree, and the corresponding object would be
loaded as the file. (This virtual file system is flat; that is, there is no way to refer-
ence subfolders.)
Typically, images are stored in the document as image XObjects (see Section
4.8.4, “Image Dictionaries”), thereby allowing them to be shared between the
standard PDF representation and the slideshow. Other media objects are stored
or embedded file streams (see Section 3.10.3, “Embedded File Streams”). Also, see
Implementation note 152 in Appendix H.
To allow viewers to verify content against the supported features in a particular
viewer, it is a requirement that all referenced objects include a
Type entry in their
dictionary, even when the
Type entry is normally optional for a given object.
KEY TYPE DESCRIPTION
Type
name (Required; PDF 1.4) The type of PDF object that this dictionary describes; must be
SlideShow for a slideshow dictionary.
Subtype
name (Required; PDF 1.4) The subtype of the PDF object that this dictionary describes;
must be
Embedded for a slideshow dictionary.
Resources
name tree (Required; PDF 1.4) A name tree that maps name strings to objects referenced by
the alternate presentation.
Note: Even though PDF treats the strings in the name tree as strings without a speci-
fied encoding, the slideshow interprets them as UTF-8 encoded Unicode.
StartResource
string (Required; PDF 1.4) A string that must match one of the strings in the Resources
entry. It defines the root object for the slideshow presentation.
Alternate PresentationsSECTION 9.4
745
The following example illustrates the use of alternate presentation slideshows.
Example 9.1
1 0 obj
<</Type /Catalog
/Pages 2 0 R
/Names 3 0 R % Indirect reference to name dictionary
>>
...
3 0 obj % The name dictionary
<</AlternatePresentations 4 0 R >>
endobj
4 0 obj % The alternate presentations name tree
<</Names [(MySlideShow) 5 0 R]>>
endobj
5 0 obj % The slideshow definition
<</Type /SlideShow
/Subtype /Embedded
/Resources <</Names [ (mysvg.svg) 31 0R
(abc0001.jpg) 35 0 R (abc0002.jpg) 36 0 R
(mysvg.js) 61 0 R (mymusic.mp3) 65 0 R ]>>
/StartResource (mysvg.svg)
>>
...
31 0 obj
<</Type /Filespec % The root object, which
/F (mysvg.svg) % points to an embedded file stream
/EF <</F 32 0 R>>
>>
endobj
32 0 obj % The embedded file stream
<</Type /EmbeddedFile
/Subtype /image#2Fsvg+xml
/Length 72
>>
stream
<?xml version="1.0" standalone="no"?>
<svg><!-- Some SVG goes here--></svg>
endstream
endobj
% ... other objects not shown
Multimedia FeaturesCHAPTER 9
746
9.5 3D Artwork
PDF 1.6 introduces the capability for collections of three-dimensional objects,
such as those used by CAD software, to be embedded in PDF files. Such collec-
tions are often called 3D models; in the context of PDF, they are referred to as 3D
artwork. The PDF constructs for 3D artwork support the following features:
• 3D artwork can be rendered within a page; that is, not as a separate window or
user interface element.
• Multiple instances of 3D artwork can appear within a page or document.
• Specific views of 3D artwork can be available, including a default view that is
displayed initially and other views that can be selected. Views may have names
that can be presented in a user interface.
• Two-dimensional (2D) content can be overlayed on 3D artwork.
• Pages containing 3D artwork can be printed.
• Users can rotate and move the artwork, enabling them to examine complex ob-
jects from any angle or orientation.
• JavaScripts and other software can programmatically manipulate objects in the
artwork, creating dynamic presentations in which objects move, spin, appear,
and disappear. The Acrobat JavaScript Scripting Reference (see the Bibliogra-
phy) describes the JavaScript interface to 3D annotations.
The following sections describe the major PDF objects that relate to 3D artwork,
as well as providing background information on 3D graphics:
• 3D annotations provide a virtual camera through which the artwork is viewed.
(see Section 9.5.1, “3D Annotations”).
• 3D streams contain the actual specification of a piece of 3D artwork (see Sec-
tion 9.5.2, “3D Streams”). In PDF 1.6, this specification conforms to the U3D
format developed by the 3D Industry Forum (<http://www.3dif.org>). Other
formats may be supported in the future.
• 3D views specify information about the relationship between the camera and
the 3D artwork (see Section 9.5.3, “3D Views”).
• 3D coordinate systems are described in Section 9.5.4, “Coordinate Systems for
3D Annotations.”
3D ArtworkSECTION 9.5
747
9.5.1 3D Annotations
3D annotations (PDF 1.6) are the means by which 3D artwork is represented in a
PDF document. Table 9.33 shows the entries specific to a 3D annotation dictio-
nary.
In addition to these entries, a 3D annotation is required to provide an appearance
stream in its
AP entry (see Table 8.11 on page 570) that has a normal appearance
(the
N entry in Table 8.15 on page 579). This appearance can be used by applica-
tions that do not support 3D annotations and by all applications for the initial
display of the annotation.
TABLE 9.33 Additional entries specific to a 3D annotation
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be 3D for
a 3D annotation.
3DD
stream or
dictionary
(Required) A 3D stream (see Section 9.5.2, “3D Streams”) or 3D reference dictio-
nary (see “3D Reference Dictionaries” on page 754) that specifies the 3D art-
work to be shown.
3DV
(various) (Optional) An object that specifies the default initial view of the 3D artwork that
should be used when the annotation is activated. It can be either a 3D view dic-
tionary (see Section 9.5.3, “3D Views”) or one of the following types specifying
an element in the
VA array in the 3D stream (see Table 9.35):
• An integer specifying an index into the VA array.
• A text string matching the IN entry in one of the views in the VA array.
• A name that indicates the first (F), last (L), or default (D) entries in the VA ar-
ray.
Default value: the default view in the 3D stream object specified by
3DD.
3DA
dictionary (Optional) An activation dictionary (see Table 9.34) that defines the times at
which the annotation should be activated and deactivated and the state of the 3D
artwork instance at those times. Default value: an activation dictionary contain-
ing default values for all its entries.
Multimedia FeaturesCHAPTER 9
748
The 3DB entry specifies the 3D view box, a rectangle in which the 3D artwork ap-
pears. The view box must fit within the annotation’s rectangle (specified by its
Rect entry). It may be the same size, or it may be smaller if necessary to provide
extra drawing area for additional 2D graphics within the annotation.
Note: Although U3D view nodes can specify viewport size, PDF consumers ignore it
in favor of information provided by the
3DB entry.
The view box is not specified in the same coordinate system as the annotation’s
rectangle, but rather in the annotation’s target coordinate system, whose origin is
at the center of the annotation’s rectangle. Units in this coordinate system are the
same as default user space units. Therefore, the coordinates of the annotation’s
rectangle in the target coordinate system are
[ -
w/2 -h/2 w/2 h/2 ]
given
w and h as the rectangle’s width and height.
The
3DD entry specifies a 3D stream that contains the 3D artwork to be shown in
the annotation; 3D streams are described in Section 9.5.2. The
3DD entry can
specify a 3D stream directly; it can also specify a 3D stream indirectly by means
of a 3D reference dictionary (see “3D Reference Dictionaries” on page 754).
3DI
boolean (Optional) A boolean indicating the primary use of the 3D annotation. If true, it
is intended to be interactive; if
false, it is intended to be manipulated program-
matically, as with a JavaScript animation. Viewer applications may present differ-
ent user interface controls for interactive 3D annotations (for example, to rotate,
pan, or zoom the artwork) than for those managed by a script or other mecha-
nism.
Default value:
true.
3DB
rectangle (Optional) The 3D view box, which is the rectangular area in which the 3D art-
work is to be drawn. It must be within the rectangle specified by the annotation’s
Rect entry and is expressed in the annotation’s target coordinate system (see be-
low).
Default value: the annotation’s
Rect entry, expressed in the target coordinate sys-
tem. This value is
[ -w/2 -h/2 w/2 h/2 ], where w and h are the width and height,
respectively, of
Rect.
KEY TYPE VALUE
3D ArtworkSECTION 9.5
749
These options control whether annotations share the same run-time instance of
the artwork.
The
3DV entry specifies the view of the 3D artwork that is displayed when the an-
notation is activated (as described in the next paragraph). 3D views, which are
described in Section 9.5.3, represent settings for the virtual camera, such as posi-
tion, orientation, and projection style. The view specified by
3DV may be one of
the 3D view dictionaries listed in the
VA entry in a 3D stream (see Table 9.35) or
another view dictionary.
The
3DA entry is an activation dictionary (see Table 9.34) that determines how
the state of the annotation and its associated artwork can change. These states re-
flect the fact it is often desirable to delay the processing or display of 3D artwork
until a user chooses to interact with it, for a number of reasons, including perfor-
mance.
3D annotations can be in one of two states:
• Inactive (the default initial state): the annotation displays the annotation’s nor-
mal appearance.
Note: It is typical, though not required, for the normal appearance to be a pre-
rendered bitmap of the default view of the 3D artwork. Producers should provide
bitmaps of appropriate resolution for all intended uses of the document; for exam-
ple, a high-resolution bitmap for high-quality printing and a screen-resolution
bitmap for on-screen viewing. Optional content (see Section 4.10) can be used to
select the appropriate bitmap for each situation.
• Active: the annotation displays a rendering of the 3D artwork. This rendering is
specified by the annotation’s
3DV entry.
Multimedia FeaturesCHAPTER 9
750
TABLE 9.34 Entries in a 3D activation dictionary
KEY TYPE VALUE
A
name (Optional) A name specifying the circumstances under which the annotation
should be activated. Valid values are:
PO The annotation should be activated as soon as the page containing
the annotation is opened.
PV The annotation should be activated as soon as any part of the page
containing the annotation becomes visible.
XA The annotation should remain inactive until explicitly activated by
a script or user action.
Note: At any one time, only a single page is considered open in a viewer applica-
tion, even though more than one page may be visible, depending on the page lay-
out.
Default value:
XA.
Note: For performance reasons, it is recommended that documents intended for
viewing in a web browser use explicit activation (
XA). In non-interactive applica-
tions, such as printing systems or aggregating applications,
PO and PV indicate
that the annotation should be activated when the page is printed or placed;
XA in-
dicates that the annotation is never activated and the normal appearance should
always be used.
AIS
name (Optional) A name specifying the state of the artwork instance upon activation
of the annotation. Valid values are:
I The artwork is instantiated, but real-time script-driven animations
are disabled.
L Real-time script-driven animations are enabled if present; if not,
the artwork is instantiated.
Default value:
L.
Note: In non-interactive applications, the artwork is always instantiated and nev-
er live.
3D ArtworkSECTION 9.5
751
The A and D entries of the activation dictionary determine when a 3D annotation
may become active and inactive. The
AIS and DIS entries specify what state the as-
sociated artwork should be in when the annotation is activated or deactivated. 3D
artwork can be in one of three states:
• Uninstantiated: the initial state of the artwork before it has been used in any
way.
• Instantiated: the state in which the artwork has been read and a run-time in-
stance of the artwork has been created. In this state, it can be rendered but
script-driven real-time modifications (that is, animations) are disabled.
• Live: the artwork is instantiated, and it is being modified in real time to achieve
some animation effect.
Note: The live state is valid only in interactive viewer applications that have Java-
Script support.
If 3D artwork becomes uninstantiated after having been instantiated, later use of
the artwork requires re-instantiation (animations are lost, and the artwork ap-
D
name (Optional) A name specifying the circumstances under which the annotation
should be deactivated. Valid values are:
PC The annotation should be deactivated as soon as the page is closed.
PI The annotation should be deactivated as soon as the page
containing the annotation becomes invisible.
XD The annotation should remain active until explicitly deactivated by
a script or user action.
Note: At any one time, only a single page is considered open in the viewer applica-
tion, even though more than one page may be visible, depending on the page lay-
out.
Default value:
PI.
DIS
name (Optional) A name specifying the state of the artwork instance upon deactiva-
tion of the annotation. Valid values are
U (uninstantiated), I (instantiated), and L
(live). Default value: U.
Note: If the value of this entry is
L, uninstantiation of instantiated artwork is not
required unless it has been modified. Uninstantiation is never required in non-in-
teractive applications.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
752
pears in its initial form). For this reason, uninstantiation is not actually required
unless the artwork has been modified in some way; consumers may choose to
keep unchanged artwork instantiated for performance reasons.
Note: In non-interactive systems such as printing systems, the artwork cannot be
changed. Therefore, applications can choose to deactivate annotations and unin-
stantiate artwork differently, based on factors such as memory usage and time need-
ed to instantiate artwork, and the
D and DIS entries may be ignored.
Multiple 3D annotations can share an instance of 3D artwork, as described in “3D
Reference Dictionaries” on page 754. In such a case, the state of the artwork in-
stance is determined in the following way:
• If any annotation dictates (through its activation dictionary) that the artwork
should be live, it is live.
• Otherwise, if any annotation dictates that the artwork should be instantiated, it
is instantiated.
• Otherwise, the artwork is uninstantiated.
Note: Artwork must not be uninstantiated if any annotation referring to it is active.
It is, however, possible for artwork to be instantiated or live if all annotations refer-
ring to it are inactive.
9.5.2 3D Streams
The specification of 3D artwork is contained in a 3D stream. 3D stream dictionar-
ies, whose entries are shown in Table 9.35, can provide a set of predefined views
of the artwork, as well as a default view. They can also provide scripts and re-
sources for providing customized behaviors or presentations.
TABLE 9.35 Additional entries in a 3D stream dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
3D for a 3D stream.
Subtype
name (Required) A name specifying the format of the 3D data contained in the
stream. In PDF 1.6, the only valid value is
U3D.
3D ArtworkSECTION 9.5
753
The Subtype entry specifies the format of the 3D stream data. In PDF 1.6, only
one value is defined,
U3D, which indicates that the stream data conforms to the
U3D file format specification. PDF consumer applications should be prepared to
encounter unknown values for
Subtype and recover appropriately, which usually
means leaving the annotation in its inactive state, displaying its normal appear-
ance.
Note: Applications are encouraged to follow the approach of falling back to the nor-
mal appearance with regard to entries in other dictionaries that may take different
types or values in future PDF versions than the ones specified here.
The
VA entry is an array containing a list of named present views of the 3D art-
work. Each entry in the array is a 3D view dictionary (see Section 9.5.3, “3D
Views”) that contains the name of the view and the information needed to display
the view. The order of array elements is the order in which the views should be
presented in a user interface. The
DV entry specifies the view to use as the initial
view of the 3D artwork.
VA
array (Optional) An array of 3D view dictionaries, each of which specifies a named
preset view of this 3D artwork (see Section 9.5.3, “3D Views”).
DV
(various) (Optional) An object that specifies the default (initial) view of the 3D art-
work. It can be a 3D view dictionary (see Section 9.5.3, “3D Views”) or one of
the following types:
• An integer specifying an index into the VA array.
• A text string matching the IN entry in one of the views in the VA array.
• A name that indicates the first (F) or last (L) entries in the VA array.
Default value: 0 (the first entry in the
VA array) if VA is present; if VA is not
present, the default view is specified within the 3D stream itself.
Resources
name tree (Optional) A name tree that maps name strings to objects that can be used by
applications or scripts to modify the default view of the 3D artwork.
The names in this name tree must be text strings so that they can be accessible
from JavaScript.
OnInstantiate
stream (Optional) A JavaScript script that should be executed when the 3D stream is
read to create an instance of the artwork.
KEY TYPE VALUE
Multimedia FeaturesCHAPTER 9
754
Note: Default views can be specified in the following order of precedence: in the an-
notation dictionary, in the 3D stream dictionary, or in the 3D artwork contained in
the 3D stream.
3D streams contain information that can be used by applications and scripts to
perform animations and other programmatically-defined behaviors, from chang-
ing the viewing orientation to moving individual components of the artwork. The
OnInstantiate entry specifies a JavaScript script that should be executed by appli-
cations that support JavaScript whenever a 3D stream is read to create an instance
of the 3D artwork. The
Resources entry is a name tree that contains objects that
can be used to modify the initial appearance of the 3D artwork. The Acrobat 3D
JavaScript interface is described in Acrobat JavaScript Scripting Reference (see the
Bibliography).
3D Reference Dictionaries
It is possible for more than one 3D annotation to be associated with the same 3D
artwork. For example, several annotations might show different views of the same
object. There are two ways in which this association can occur, as determined by
the annotation’s
3DD entry (see Table 9.33):
• If the 3DD entry specifies a 3D stream, the annotation has its own run-time in-
stance of the 3D artwork. Any changes to the artwork are reflected only in this
annotation. Other annotations that refer to the same stream have separate run-
time instances.
• If the 3DD entry specifies a 3D reference dictionary (whose entries are shown
in Table 9.36), the annotation shares a run-time instance of the 3D artwork
with all other annotations that specify the same reference dictionary. Any
changes to the artwork are reflected in all such annotations.
TABLE 9.36 Entries in a 3D reference dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
3DRef for a 3D reference dictionary.
3DD
stream (Required) The 3D stream (see Section 9.5.2, “3D Streams”) containing the
specification of the 3D artwork.
3D ArtworkSECTION 9.5
755
Example 9.1 and Figure 9.1through Figure 9.3 show three annotations that use
the same 3D artwork. Object 100 (Annotation 1) has its own run-time instance of
the 3D stream (object 200); object 101(Annotation 2) and object 102 (Annotation
3) share a run-time instance through the 3D reference dictionary (object 201).
Example 9.2
100 0 obj % 3D annotation 1
<< /Type /Annot
/Subtype /3D
/3DD 200 0 R % Reference to the 3D stream containing the 3D artwork
>>
endobj
101 0 obj % 3D annotation 2
<< /Type /Annot
/Subtype /3D
/3DD 201 0 R % Reference to a 3D reference dictionary
>>
endobj
102 0 obj % 3D annotation 3
<< /Type /Annot
/Subtype /3D
/3DD 201 0 R % Reference to the same 3D reference dictionary
>>
endobj
200 0 obj % The 3D stream
<< /Type /3D
/Subtype /U3D
... other keys related to a stream, such as /Length
>>
stream
... U3D data...
endstream
endobj
201 0 obj % 3D reference dictionary
<< /Type /3DRef
/3DD 200 0 R % Reference to the actual 3D artwork.
>>
endobj
Multimedia FeaturesCHAPTER 9
756
FIGURE 9.1 Default view of artwork
FIGURE 9.2 Annotation 2 rotated
FIGURE 9.3 Shared artwork (annotations 2 &3) modified
Annotation 1
Annotation 2
Annotation 3
3
4
6
2
1
5
C
D
F
B
A
E
3
4
6
2
1
5
C
D
F
B
A
E
3
4
6
2
1
5
C
D
F
B
A
E
Annotation 1
Annotation 2
Annotation 3
3
4
6
2
1
5
1
3
4
6
2
1
5
C
D
F
B
A
E
A
C
D
F
B
A
E
Annotation 1
Annotation 2
Annotation 3
3
4
6
2
1
5
1
3
4
6
2
1
5
C
D
F
B
A
E
A
C
D
F
B
A
E
3D ArtworkSECTION 9.5
757
The figures show how the objects in Example 9.1 might be used. Figure 9.1 shows
the same initial view of the artwork in all three annotations. Figure 9.2 shows the
results of rotating the view of the artwork within Annotation 2. Figure 9.3 shows
the results of manipulating the artwork shared by Annotation 2 and Annotation
3: they both reflect the change in the artwork because they share the same run-
time instance. Annotation 1 remains unchanged because it has its own run-time
instance.
Note: When multiple annotations refer to the same instance of 3D artwork, the state
of the instance is determined as described in Section 9.5.1, “3D Annotations.”
9.5.3 3D Views
A 3D view (or simply view) specifies parameters to be applied to the virtual cam-
era associated with a 3D annotation. These parameters may include orientation
and position of the camera, details regarding the projection of camera coordi-
nates into the annotation’s target coordinate system, and a description of the
background on which the artwork is to be drawn.
Users can manipulate views by performing interactive operations such as free ro-
tation and translation. In addition, 3D artwork can contain a set of predefined
views that the author deems to be of particular interest. For example, a mechani-
cal drawing of a part may have specific views showing the top, bottom, left, right,
front, and back of an object.
A 3D stream may contain a list of named preset views of the 3D artwork, as spec-
ified by the
VA entry, which is an array of 3D view dictionaries. The entries in a
3D view dictionary are shown in Table 9.37.
TABLE 9.37 Entries in a 3D view dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present,
must be
3DView for a 3D view dictionary.
XN
text string (Required) The external name of the view, suitable for presentation in a user in-
terface.
IN
text string (Optional) The internal name of the view, used to refer to the view from other
objects, such as the go-to-3D-view action (see “Go-To-3D-View Actions” on
page 632).
Multimedia FeaturesCHAPTER 9
758
For any view, the document author may provide 2D content specific to the view,
to be drawn on top of the 3D artwork. The
O entry specifies a form XObject that
should be overlayed on the rendered 3D artwork. The coordinate system of the
MS
name (Optional) A name specifying the entry that should be used for the 3D camera-
to-world transformation matrix. The value must be either
M, which indicates
that the
C2W entry specifies the matrix, or the same value as the Subtype entry
in the 3D stream object, which indicates that the
U3DPath entry is used for the
matrix (since the only valid
Subtype value in PDF 1.6 is U3D).
C2W
array (Required if the value of MS is M, ignored otherwise) A 12-element 3D transfor-
mation matrix that specifies a position and orientation of the camera in world
coordinates.
U3DPath
string or array (Required if the value of MS is U3D, ignored otherwise) A sequence of one or
more strings used to access a view node within the U3D artwork. The first
string is a U3D node ID for the root node, and each subsequent string is the
node ID for a child of the node specified by the prior string. Each node specifies
a 3D transformation matrix (see Section 9.5.4, “Coordinate Systems for 3D An-
notations”); the concatenation of all the matrices forms the camera-to-world
matrix.
CO
number (Optional; used only if MS is present) A non-negative number indicating a dis-
tance in the camera coordinate system along the z axis to the center of orbit for
this view; see discussion below. If this entry is not present, the viewer applica-
tion must determine the center of orbit.
P
dictionary (Optional) A projection dictionary (see “Projection Dictionaries” on page 760)
that defines the projection of coordinates in the 3D artwork (already trans-
formed into camera coordinates) onto the target coordinate system of the anno-
tation.
Default value: a projection dictionary where the value of
Subtype is
Perspective, the value of FOV is 90, and all other entries take their default val-
ues.
O
stream (Optional; meaningful only if MS and P are present) A form XObject that is used
to overlay 2D graphics on top of the rendered 3D artwork.
BG
dictionary (Optional) A background dictionary (see “Background Dictionaries” on page
764”) that defines the background over which the 3D artwork is to be drawn.
Default value: a background dictionary whose entries take their default values.
KEY TYPE VALUE
3D ArtworkSECTION 9.5
759
form XObject is defined to be the same as the (x, y, 0) plane in the camera coordi-
nate system (see Section 9.5.4, “Coordinate Systems for 3D Annotations”).
The form XObject specified by the
O entry is subject to the following restrictions;
failure to abide by them could result in misalignment of the overlay with the ren-
dered 3D graphics:
• The form XObject is associated with a specific view (not with the camera posi-
tion defined by the 3D view dictionary). It should only be drawn when the user
navigates using the 3D view, not when the user happens to navigate to the same
orientation by manual means.
• It should only be drawn if the artwork-to-world matrix has not been altered.
• It may only be specified in 3D view dictionaries in which both a camera-to-
world matrix (
MS and associated entries) and a projection dictionary (the P en-
try) are present.
The
CO entry specifies the distance from the camera to the center of orbit for the
3D view, which is the point around which the camera should rotate when per-
forming an orbit-style navigation. Figure 9.4 illustrates camera positioning when
orbiting around the center of orbit.
FIGURE 9.4 Rotation around the center of orbit
Center Of Orbit
Multimedia FeaturesCHAPTER 9
760
Projection Dictionaries
A projection dictionary (see Table 9.38) defines the mapping of 3D camera coor-
dinates onto the target coordinate system of the annotation. Each 3D view can
specify a projection dictionary by means of its
P entry.
Note: Although U3D view nodes can specify projection information, PDF consum-
ers ignore it in favor of information in the projection dictionary.
PDF 1.6 supports near/far clipping. This type of clipping defines a near plane and
a far plane (as shown in Figure 9.5 on page 762). Objects, or parts of objects, that
are beyond the far plane or closer to the camera than the near plane are not
drawn. 3D objects are projected onto the near plane and then scaled and posi-
tioned within the annotation’s target coordinate system, as described below.
TABLE 9.38 Entries in a projection dictionary
KEY TYPE VALUE
Subtype
name (Required) The type of projection. Valid values are O (orthographic) or P (per-
spective).
CS
name (Optional) The clipping style. Valid values are XNF (explicit near/far) or ANF
(automatic near/far). Default value: ANF.
F
number (Optional; meaningful only if the value of CS is XNF) The far clipping distance,
expressed in the camera coordinate system. No parts of objects whose z coordi-
nates are greater than the value of this entry are drawn. If this entry is absent, no
far clipping occurs.
N
number (Meaningful only if the value of CS is XNF; required if the value of Subtype is P)
The near clipping distance, expressed in the camera coordinate system. No
parts of objects whose z coordinates are less than the value of this entry are
drawn. If
Subtype is P, the value must be positive; if Subtype is O, the value
must be non-negative, and the default value is 0.
FOV
number (Required if Subtype is P, ignored otherwise) A number between 0 and 180, inclu-
sive, specifying the field of view of the virtual camera, in degrees. It defines a
cone in 3D space centered around the z axis and a circle where the cone inter-
sects the near clipping plane. The circle, along with the value of
PS, specify the
scaling of the projected artwork when rendered in the 2D plane of the annota-
tion.
3D ArtworkSECTION 9.5
761
The CS entry defines how the near and far planes are determined. A value of XNF
means that the N and F entries explicitly specify the z coordinate of the near and
far planes, respectively. A value of
ANF for CS means that the near and far planes
are determined automatically based on the objects in the artwork.
The
Subtype entry specifies the type of projection, which determines how objects
are projected onto the near plane and scaled. The possible values are
O for ortho-
graphic projection and
P for perspective projection.
For orthographic projection, objects are projected onto the near plane by simply
discarding their z value. They are scaled from units of the near plane’s coordinate
system to those of the annotation’s target coordinate system by a factor specified
by the
OS entry.
For perspective projection, a given coordinate (x, y, z) is projected onto the near
plane, defining a 2D coordinate (x
1
, y
1
) using the following formulas:
where n is the z coordinate of the near plane.
PS
number or name (Optional; meaningful only if Subtype is P) An object that specifies the scaling
used when projecting the 3D artwork onto the annotation’s target coordinate
system. It defines the diameter of the circle formed by the intersection of the
near plane and the cone specified by
FOV. The value may be one of the follow-
ing:
• A positive number that explicitly specifies the diameter as a distance in the
annotation’s target coordinate system.
• A name specifying that the diameter should be set to the width (W), height
(
H), minimum of width and height (Min), or maximum of width and height
(
Max) of the annotation’s 3D view box. Default value: W.
OS
number (Optional; meaningful only if Subtype is O) A positive number that specifies the
scale factor to be applied to both the x and y coordinates when projecting onto
the annotation’s target coordinate system (the z coordinate is discarded). De-
fault value: 1.
KEY TYPE VALUE
x
1
x
n
z
---
×=
y
1
y
n
z
---
×=
Multimedia FeaturesCHAPTER 9
762
Scaling with perspective projection is more complicated than for orthographic
projection. The
FOV entry specifies an angle that defines a cone centered along
the z axis in the camera coordinate system (see Figure 9.5). The cone intersects
with the near plane, forming a circular area on the near plane. Figure 9.6 shows
this circle and graphics from the position of the camera.
FIGURE 9.5 Perspective projection of 3D artwork onto the near plane
FIGURE 9.6 Objects projected onto the near clipping plane, as seen from the position of the camera
Far Clipping Plane Near Clipping plane
Objects projected onto near clipping plane
Circle defined by Field of View angle on near clipping plane
Field of View angle
Z axis
FOV circle
Z axis projected onto near plane
3D ArtworkSECTION 9.5
763
The PS entry specifies the diameter that this circle will have when the graphics
projected onto the near plane are rendered in the annotation’s 3D view box (see
Figure 9.7). Although the diameter of the circle determines the scaling factor,
graphics outside the circle are also displayed, providing they fit within the view
box, as seen in the figure.
Figure 9.8 shows the entire 3D annotation. In this case, the 3D view box is smaller
than the annotation’s rectangle, which also contains 2D content outside the 3D
view box.
FIGURE 9.7 Positioning and scaling the near plane onto the annotation’s 3D view box
FIGURE 9.8 3D annotation positioned on the page
3D Annotation’s 3DB box
Z axis projected onto near plane,
aligned with center of 3DB box,
scaled to fit the width of the 3DB box
New Planet
Discovered!
The Daily News
Multimedia FeaturesCHAPTER 9
764
Background Dictionaries
A 3D background dictionary defines the background over which a 3D view is to
be drawn; the entries in a background dictionary are shown in Table 9.39. PDF
1.6 supports only a single opaque color using the
DeviceRGB color space. 3D art-
work may include transparent objects; however, there is no interaction between
such objects and objects drawn below the annotation. In effect, the 3D artwork
and its background form a transparency group whose flattened results have an
opacity of 1 (see Chapter 7, “Transparency”).
Note: An annotation’s normal appearance should have the same behavior with re-
spect to transparency when the appearance is intended to depict the 3D artwork.
This recommendation does not necessarily apply when the appearance is used for
another purpose, such as a compatibility warning message.
TABLE 9.39 Entries in a 3D background dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
3DBG for a 3D background dictionary.
Subtype
name (Optional) The type of background. The only valid value for PDF 1.6 is SC (solid
color), which indicates a single opaque color. Default value:
SC.
CS
name or
array
(Optional) The color space of the background. The only valid value for PDF 1.6 is
the name
DeviceRGB. Default value: DeviceRGB.
Note: PDF consumers should be prepared to encounter other values that may be sup-
ported in future versions of PDF.
C
(various) (Optional) The color of the background, in the color space defined by CS. Default
value: an array
[1 1 1] representing the color white when the value of CS is
DeviceRGB.
EA
boolean (Optional) If true, the background should apply to the entire annotation; if false, the
background should apply only to the rectangle specified by the annotation’s 3D view
box (the
3DB entry in Table 9.33). Default value: false.
3D ArtworkSECTION 9.5
765
9.5.4 Coordinate Systems for 3D Annotations
3D artwork is a collection of objects whose positions and geometry are specified
using three-dimensional coordinates. Section 4.2, “Coordinate Systems,” discuss-
es the concepts of two-dimensional coordinate systems, their geometry and
transformations. This section extends those concepts to include the third dimen-
sion.
As described in Section 4.2, positions are defined in terms of pairs of x and y co-
ordinates on the Cartesian plane. The origin of the plane specifies the location (0,
0); x values increase to the right and y values increase upward. For three-dimen-
sional graphics, a third axis, the z axis, is required. The origin is therefore at (0, 0,
0); positive z values increase going into the page.
In two-dimensional graphics, the transformation matrix transforms the position,
size, and orientation of objects in a plane. It is a 3-by-3 matrix, where only six of
the elements can be changed; therefore, the matrix is expressed in PDF as an ar-
ray of six numbers:
In 3D graphics, a 4-by-4 matrix is used to transform the position, size, and orien-
tations of objects in a three-dimensional coordinate system. Only the first three
columns of the matrix can be changed; therefore, the matrix is expressed in PDF
as an array of 12 numbers:
3D coordinate transformations are expressed as matrix transformations:
ab0
cd0
tx ty 1
abcdtxty
=
abc0
def0
ghi0
tx ty tz 1
abcdefghitxtytz
=
x' y' z' 1
xyz1
abc0
def0
ghi0
tx ty tz 1
×=
Multimedia FeaturesCHAPTER 9
766
Carrying out the multiplication has the following results:
Position and orientation of 3D artwork typically involves translation (movement)
and rotation along any axis. The virtual camera represents the view of the art-
work. The relationship between camera and artwork can be thought of in two
ways:
• The 3D artwork is in a fixed position and orientation, and the camera moves to
different positions and orientations.
• The camera is in a fixed location, and the 3D artwork is translated and rotated.
Both approaches can achieve the same visual effects; in practice, 3D systems typi-
cally use a combination of both. Conceptually, there are three distinct coordinate
systems:
• The artwork coordinate system.
• The camera coordinate system, in which the camera is positioned at (0, 0, 0) fac-
ing out along the positive z axis, with the positive x axis to the right and the
positive y axis going straight up.
• An intermediate system called the world coordinate system.
Two 3D transformation matrices are used in coordinate conversions:
• The artwork-to-world matrix specifies the position and orientation of the art-
work in the world coordinate system. This matrix is contained in the 3D
stream.
• The camera-to-world matrix specifies the position and orientation of the cam-
era in the world coordinate system. This matrix is specified by either the
C2W
or U3DPath entries of the 3D view dictionary.
x' axdygztx+×+×+×=
y' bxeyhzty+×+×+×=
z' cxfyiztz+×+×+×=
3D ArtworkSECTION 9.5
767
When drawing 3D artwork in a 3D annotation’s target coordinate system, the fol-
lowing transformations take place:
1. Artwork coordinates are transformed to world coordinates:
2. World coordinates are transformed to camera coordinates:
The first two steps can be expressed as a single equation, as follows:
3. Finally, the camera coordinates are projected into two dimensions, eliminating
the z coordinate, then scaled and positioned within the annotation’s target co-
ordinate system.
x
w
y
w
z
w
1 x
a
y
a
z
a
1
aw×=
x
c
y
c
z
c
1 x
w
y
w
z
w
1
cw
1–
()×=
x
c
y
c
z
c
1 x
w
y
w
z
w
1
aw cw
1–
×()×=
Multimedia FeaturesCHAPTER 9
768
769
CHAPTER 10
10Document Interchange
The features described in this chapter do not affect the final appearance of a doc-
ument. Rather, these features enable a document to include higher-level informa-
tion that is useful for the interchange of documents among applications:
• Procedure sets (Section 10.1) that define the implementation of PDF operators
• Metadata (Section 10.2) consisting of general information about a document or
a component of a document, such as its title, author, and creation and modifi-
cation dates
• File identifiers (Section 10.3) for reliable reference from one PDF file to another
• Page-piece dictionaries (Section 10.4) allowing an application to embed private
data in a PDF document for its own use
• Marked-content operators (Section 10.5) for identifying portions of a content
stream and associating them with additional properties or externally specified
objects
• Logical structure facilities (Section 10.6) for imposing a hierarchical organiza-
tion on the content of a document
• Tagged PDF (Section 10.7), a set of conventions for using the marked content
and logical structure facilities to facilitate the extraction and reuse of a docu-
ment’s content for other purposes
• Various ways of increasing the accessibility of a document to users with disabil-
ities (Section 10.8), including the identification of the natural language in
which it is written (such as English or Spanish) for the benefit of a text-to-
speech engine
Document InterchangeCHAPTER 10
770
• The Web Capture plug-in extension (Section 10.9), which creates PDF files
from Internet-based or locally resident HTML, PDF, GIF, JPEG, and ASCII text
files
• Facilities supporting prepress production workflows (Section 10.10), such as
the specification of page boundaries and the generation of printer’s marks, color
separations, output intents, traps, and low-resolution proxies for high-resolution
images
10.1 Procedure Sets
The PDF operators used in content streams are grouped into categories of related
operators called procedure sets (see Table 10.1). Each procedure set corresponds
to a named resource containing the implementations of the operators in that pro-
cedure set. The
ProcSet entry in a content stream’s resource dictionary (see Sec-
tion 3.7.2, “Resource Dictionaries”) holds an array consisting of the names of the
procedure sets used in that content stream. These procedure sets are used only
when the content stream is printed to a PostScript output device. The names
identify PostScript procedure sets that must be sent to the device to interpret the
PDF operators in the content stream. Each element of this array must be one of
the predefined names shown in Table 10.1. (See implementation note 153 in
Appendix H.)
TABLE 10.1 Predefined procedure sets
Note: Beginning with PDF 1.4, this feature is considered obsolete. For compatibility
with existing consumer applications, PDF producer applications should continue to
specify procedure sets (preferably, all of those listed in Table 10.1 unless it is known
that fewer are needed). However, consumer applications should not depend on the
correctness of this information.
NAME CATEGORY OF OPERATORS
PDF Painting and graphics state
Text Text
ImageB Grayscale images or image masks
ImageC Color images
ImageI Indexed (color-table) images
MetadataSECTION 10.2
771
10.2 Metadata
A PDF document may include general information, such as the document’s title,
author, and creation and modification dates. Such global information about the
document (as opposed to its content or structure) is called metadata and is in-
tended to assist in cataloguing and searching for documents in external databas-
es. A document’s metadata may also be added or changed by users or plug-in
extensions (see implementation note 154 in Appendix H). Beginning with PDF
1.4, metadata can also be specified for individual components of a document.
Metadata can be stored in a PDF document in either of the following ways:
• In a document information dictionary associated with the document (Section
10.2.1)
• In a metadata stream (PDF 1.4) associated with the document or a component
of the document (Section 10.2.2)
10.2.1 Document Information Dictionary
The optional Info entry in the trailer of a PDF file (see Section 3.4.4, “File Trailer”)
can hold a document information dictionary containing metadata for the docu-
ment; Table 10.2 shows its contents. Any entry whose value is not known should
be omitted from the dictionary rather than included with an empty string as its
value.
Some plug-in extensions may choose to permit searches on the contents of the
document information dictionary. To facilitate browsing and editing, all keys in
the dictionary are fully spelled out, not abbreviated. New keys should be chosen
with care so that they make sense to users.
The value associated with any key not specifically mentioned in Table 10.2 must
be a text string.
Note: Although consumer applications can store custom metadata in the document
information dictionary, it is inappropriate to store private content or structural in-
formation there. Such information should be stored in the document catalog instead
(see Section 3.6.1, “Document Catalog”).
Document InterchangeCHAPTER 10
772
TABLE 10.2 Entries in the document information dictionary
KEY TYPE VALUE
Title
text string (Optional; PDF 1.1) The document’s title.
Author
text string (Optional) The name of the person who created the document.
Subject
text string (Optional; PDF 1.1) The subject of the document.
Keywords
text string (Optional; PDF 1.1) Keywords associated with the document.
Creator
text string (Optional) If the document was converted to PDF from another format, the
name of the application (for example, Adobe FrameMaker
®
) that created the
original document from which it was converted.
Producer
text string (Optional) If the document was converted to PDF from another format, the
name of the application (for example, Acrobat Distiller) that converted it to
PDF.
CreationDate
date (Optional) The date and time the document was created, in human-readable
form (see Section 3.8.3, “Dates”).
ModDate
date (Required if PieceInfo is present in the document catalog; otherwise optional;
PDF 1.1) The date and time the document was most recently modified, in hu-
man-readable form (see Section 3.8.3, “Dates”).
Trapped
name (Optional; PDF 1.3) A name object indicating whether the document has
been modified to include trapping information (see Section 10.10.5, “Trap-
ping Support”):
True The document has been fully trapped; no further trapping is
needed. (This is the name
True, not the boolean value true.)
False The document has not yet been trapped; any desired
trapping must still be done. (This is the name
False, not the
boolean value
false.)
Unknown Either it is unknown whether the document has been
trapped or it has been partly but not yet fully trapped; some
additional trapping may still be needed.
Default value:
Unknown.
The value of this entry may be set automatically by the software creating the
document’s trapping information, or it may be known only to a human oper-
ator and entered manually.
MetadataSECTION 10.2
773
Example 10.1 shows a typical document information dictionary.
Example 10.1
1 0 obj
<< /Title (PostScript Language Reference, Third Edition)
/Author (Adobe Systems Incorporated)
/Creator (Adobe® FrameMaker® 5.5.3 for Power Macintosh®)
/Producer (Acrobat® Distiller™ 3.01 for Power Macintosh)
/CreationDate (D:19970915110347-08'00')
/ModDate (D:19990209153925-08'00')
>>
endobj
10.2.2 Metadata Streams
Metadata, both for an entire document and for components within a document,
can be stored in PDF streams called metadata streams (PDF 1.4). Metadata
streams have the following advantages over the document information dictio-
nary:
• PDF-based workflows often embed metadata-bearing artwork as components
within larger documents. Metadata streams provide a standard way of pre-
serving the metadata of these components for examination downstream. PDF-
aware applications should be able to derive a list of all metadata-bearing
document components from the PDF document itself.
• PDF documents are often made available on the Web or in other environments,
where many tools routinely examine, catalog, and classify documents. These
tools should be able to understand the self-contained description of the docu-
ment even if they do not understand PDF.
Besides the usual entries common to all stream dictionaries (see Table 3.4 on page
38), the metadata stream dictionary contains the additional entries listed in Table
10.3.
The contents of a metadata stream is the metadata represented in Extensible
Markup Language (XML). This information is visible as plain text to tools that
are not PDF-aware only if the metadata stream is both unfiltered and unencrypt-
ed.
Document InterchangeCHAPTER 10
774
TABLE 10.3 Additional entries in a metadata stream dictionary
The format of the XML representing the metadata is defined as part of a frame-
work called the Extensible Metadata Platform (XMP) and described in the Adobe
document XMP: Extensible Metadata Platform (see the Bibliography). This
framework provides a way to use XML to represent metadata describing docu-
ments and their components and is intended to be adopted by a wider class of ap-
plications than just those that process PDF. It includes a method to embed XML
data within non-XML data files in a platform-independent format that can be
easily located and accessed by simple scanning rather than requiring the docu-
ment file to be parsed.
A metadata stream can be attached to a document through the
Metadata entry in
the document catalog (see Chapter 3.6.1, “Document Catalog,” and also see
implementation note 155 in Appendix H). In addition, most PDF document
components represented as a stream or dictionary can have a
Metadata entry (see
Table 10.4).
TABLE 10.4 Additional entry for components having metadata
In general, a PDF stream or dictionary can have metadata attached to it as long as
the stream or dictionary represents an actual information resource, as opposed to
serving as an implementation artifact. Some PDF constructs are considered im-
plementational, and hence cannot have associated metadata.
For the remaining PDF constructs, there is sometimes ambiguity about exactly
which stream or dictionary should bear the
Metadata entry. Such cases are to be
resolved so that the metadata is attached as close as possible to the object that
actually stores the data resource described. For example, metadata describing a
tiling pattern should be attached to the pattern stream’s dictionary, but a shading
should have metadata attached to the shading dictionary rather than to the shad-
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be Metadata
for a metadata stream.
Subtype
name (Required) The type of metadata stream that this dictionary describes; must be XML.
KEY TYPE VALUE
Metadata
stream (Optional; PDF 1.4) A metadata stream containing metadata for the component.
File IdentifiersSECTION 10.3
775
ing pattern dictionary that refers to it. Similarly, metadata describing an ICCBased
color space should be attached to the ICC profile stream describing it, and meta-
data for fonts should be attached to font file streams rather than to font dictionar-
ies.
In tables describing document components in this book, the
Metadata entry is
listed only for those in which it is most likely to be used. Keep in mind, however,
that this entry may appear in other components represented as streams or dictio-
naries.
In addition, metadata can also be associated with marked content within a con-
tent stream. This association is created by including an entry in the property list
dictionary whose key is
Metadata and whose value is the metadata stream dictio-
nary. Because this construct refers to an object outside the content stream, the
property list must be referred to indirectly as a named resource (see Section
10.5.1, “Property Lists”).
10.3 File Identifiers
PDF files may contain references to other PDF files (see Section 3.10, “File Speci-
fications”). Simply storing a file name, however, even in a platform-independent
format, does not guarantee that the file can be found. Even if the file still exists
and its name has not been changed, different server software applications may
identify it in different ways. For example, servers running on DOS platforms must
convert all file names to 8 characters and a 3-character extension. Different serv-
ers may use different strategies for converting longer file names to this format.
External file references can be made more reliable by including a file identifier
(PDF 1.1) in the file and using it in addition to the normal platform-based file
designation. Matching the identifier in the file reference with the one in the file
confirms whether the correct file was found.
File identifiers are defined by the optional
ID entry in a PDF file’s trailer dic-
tionary (see Section 3.4.4, “File Trailer”; see also implementation note 156 in
Appendix H). The value of this entry is an array of two strings. The first string is
a permanent identifier based on the contents of the file at the time it was original-
ly created and does not change when the file is incrementally updated. The sec-
ond string is a changing identifier based on the file’s contents at the time it was
last updated. When a file is first written, both identifiers are set to the same value.
Document InterchangeCHAPTER 10
776
If both identifiers match when a file reference is resolved, it is very likely that the
correct file has been found. If only the first identifier matches, a different version
of the correct file has been found.
To help ensure the uniqueness of file identifiers, it is recommend that they be
computed by means of a message digest algorithm such as MD5 (described in In-
ternet RFC 1321, The MD5 Message-Digest Algorithm; see the Bibliography), us-
ing the following information (see implementation note 157 in Appendix H):
• The current time
• A string representation of the file’s location, usually a pathname
• The size of the file in bytes
• The values of all entries in the file’s document information dictionary (see
Section 10.2.1, “Document Information Dictionary”)
10.4 Page-Piece Dictionaries
A page-piece dictionary (PDF 1.3) can be used to hold private application data.
The data can be associated with a page or form XObject by means of the optional
PieceInfo entry in the page object (see Table 3.27 on page 119) or form dictionary
(see Table 4.45 on page 328). Beginning with PDF 1.4, private data may also be
associated with the PDF document by means of the
PieceInfo entry in the docu-
ment catalog (see Table 3.25 on page 114).
Applications can use this dictionary as a place to store private data in connection
with that document, page, or form. Such private data can convey information
meaningful to the application that produces it (such as information on object
grouping for a graphics editor or the layer information used by Adobe Photo-
shop
®
) but is typically ignored by general-purpose PDF viewer applications.
As Table 10.5 shows, a page-piece dictionary may contain any number of entries,
each keyed by the name of a distinct application or of a well-known data type rec-
ognized by a family of applications. The value associated with each key is an ap-
plication data dictionary containing the private data to be used by the application.
The
Private entry may have a value of any data type, but typically it is a dictionary
containing all of the private data needed by the application other than the actual
content of the document, page, or form.
Page-Piece DictionariesSECTION 10.4
777
TABLE 10.5 Entries in a page-piece dictionary
TABLE 10.6 Entries in an application data dictionary
The LastModified entry indicates when this application last altered the content of
the page or form. If the page-piece dictionary contains several application data
dictionaries, their modification dates can be compared with those in the corre-
sponding entry of the page object or form dictionary (see Table 3.27 on page 119
and Table 4.45 on page 328), or the
ModDate entry of the document information
dictionary (see Table 10.2), to ascertain which application data dictionary corre-
sponds to the current content of the page or form. Because some platforms may
use only an approximate value for the date and time or may not deal correctly
with differing time zones, modification dates are compared only for equality and
not for sequential ordering.
Note: It is possible for two or more application data dictionaries to have the same
modification date. Applications can use this capability to define multiple or extend-
ed versions of the same data format. For example, suppose that earlier versions of an
application use an application data dictionary named
PictureEdit, and later ver-
sions of the same application extend the data to include additional items not previ-
ously used. The original data could continue to be kept in the
PictureEdit dictionary
and the additional items placed in a new dictionary named
PictureEditExtended.
This allows the earlier versions of the application to continue to work as before, and
later versions are able to locate and use the extended data items.
KEY TYPE VALUE
any application name
or well-known data type
dictionary An application data dictionary (see Table 10.6).
KEY TYPE VALUE
LastModified date (Required) The date and time when the contents of the document,
page, or form were most recently modified by this application.
Private (any) (Optional) Any private data appropriate to the application, typically
in the form of a dictionary.
Document InterchangeCHAPTER 10
778
10.5 Marked Content
Marked-content operators (PDF 1.2) identify a portion of a PDF content stream as
a marked-content element of interest to a particular application or PDF plug-in
extension. Marked-content elements and the operators that mark them fall into
two categories:
• The MP and DP operators designate a single marked-content point in the con-
tent stream.
• The BMC, BDC, and EMC operators bracket a marked-content sequence of ob-
jects within the content stream. Note that this is a sequence not simply of bytes
in the content stream but of complete graphics objects. Each object is fully
qualified by the parameters of the graphics state in which it is rendered.
A graphics application, for example, might use marked content to identify a set of
related objects as a group to be processed as a single unit. A text-processing
application might use it to maintain a connection between a footnote marker in
the body of a document and the corresponding footnote text at the bottom of the
page. The PDF logical structure facilities use marked-content sequences to asso-
ciate graphical content with structure elements (see Section 10.6.3, “Structure
Content”). Table 10.7 summarizes the marked-content operators.
All marked-content operators except
EMC take a tag operand indicating the role
or significance of the marked-content element to the processing application. All
such tags must be registered with Adobe Systems (see Appendix E) to avoid con-
flicts between different applications marking the same content stream. In addi-
tion to the tag operand, the
DP and BDC operators specify a property list
containing further information associated with the marked content. Property lists
are discussed further in Section 10.5.1, “Property Lists.”
Marked-content operators may appear only between graphics objects in the con-
tent stream. They may not occur within a graphics object or between a graphics
state operator and its operands. Marked-content sequences may be nested one
within another, but each sequence must be entirely contained within a single con-
tent stream; it may not cross page boundaries, for example.
Note: The
Contents entry of a page object (see “Page Objects” on page 119), which
may be either a single stream or an array of streams, is considered a single stream
with respect to marked-content sequences.
Marked ContentSECTION 10.5
779
TABLE 10.7 Marked-content operators
When the marked-content operators BMC, BDC, and EMC are combined with the
text object operators
BT and ET (see Section 5.3, “Text Objects”), each pair of
matching operators (
BMC…EMC, BDC…EMC, or BT…ET) must be properly (sep-
arately) nested. Therefore, the sequences
BMC BT
BT BMC
…
and …
ET EMC
EMC ET
are valid, but
OPERANDS OPERATOR DESCRIPTION
tag
MP
Designate a marked-content point. tag is a name object indicating the role or
significance of the point.
tag properties
DP
Designate a marked-content point with an associated property list. tag is a
name object indicating the role or significance of the point.
properties is either
an inline dictionary containing the property list or a name object associated
with it in the
Properties subdictionary of the current resource dictionary (see
Section 10.5.1, “Property Lists”).
tag
BMC
Begin a marked-content sequence terminated by a balancing EMC operator.
tag is a name object indicating the role or significance of the sequence.
tag properties
BDC
Begin a marked-content sequence with an associated property list, terminat-
ed by a balancing
EMC operator. tag is a name object indicating the role or
significance of the sequence.
properties is either an inline dictionary contain-
ing the property list or a name object associated with it in the
Properties sub-
dictionary of the current resource dictionary (see Section 10.5.1, “Property
Lists”).
—
EMC
End a marked-content sequence begun by a BMC or BDC operator.
Document InterchangeCHAPTER 10
780
BMC BT
BT BMC
…
and …
EMC ET
BT EMC
are not valid.
10.5.1 Property Lists
The marked-content operators DP and BDC associate a property list with a
marked-content element within a content stream. The property list is a dictionary
containing private information meaningful to the program (application or plug-
in extension) creating the marked content. It is suggested that programs use the
dictionary entries in a consistent way; for example, the values associated with a
given key should always be of the same type (or small set of types).
If all of the values in a property list dictionary are direct objects, the dictionary
may be written inline in the content stream as a direct object. If any of the values
are indirect references to objects outside the content stream, the property list
dictionary must instead be defined as a named resource in the
Properties sub-
dictionary of the current resource dictionary (see Section 3.7.2, “Resource Dic-
tionaries”) and referenced by name as the
properties operand of the DP or BDC
operator.
10.5.2 Marked Content and Clipping
Some PDF path and text objects are defined purely for their effect on the current
clipping path, without the objects actually being painted on the page. This occurs
when a path object is defined using the operator sequence
W n or W* n (see
Section 4.4.3, “Clipping Path Operators”) or when a text object is painted in text
rendering mode 7 (see Section 5.2.5, “Text Rendering Mode”). Such clipped,
unpainted path or text objects are called clipping objects. When a clipping object
falls within a marked-content sequence, it is not considered part of the sequence
unless the entire sequence consists only of clipping objects. In Example 10.2, for
instance, the marked-content sequence tagged
Clip includes the text string
(Clip me) but not the rectangular path that defines the clipping boundary.
Marked ContentSECTION 10.5
781
Example 10.2
/Clip BMC
100 100 10 10 re W n % Clipping path
(Clip me) Tj % Object to be clipped
EMC
Only when a marked-content sequence consists entirely of clipping objects are
the clipping objects considered part of the sequence. In this case, the sequence is
known as a marked clipping sequence. Such sequences may be nested. In Example
10.3, for instance, multiple lines of text are used to clip a subsequent graphics
object (in this case, a filled path). Each line of text is bracketed within a separate
marked clipping sequence, tagged
Pgf. The entire series is bracketed in turn by an
outer marked clipping sequence, tagged
Clip. Note, however, that the marked-
content sequence tagged
ClippedText is not a marked clipping sequence, since it
contains a filled rectangular path that is not a clipping object. The clipping
objects belonging to the
Clip and Pgf sequences are therefore not considered part
of the
ClippedText sequence.
Example 10.3
/ClippedText BMC
/Clip <<…>>
BDC
BT
7 Tr % Begin text clip mode
/Pgf BMC
(Line 1) Tj
EMC
/Pgf BMC
(Line) '
(2)Tj
EMC
ET % Set current text clip
EMC
100 100 10 10 re f % Filled path
EMC
Document InterchangeCHAPTER 10
782
The precise rules governing marked clipping sequences are as follows:
• A clipping object is a path object ended by the operator sequence W n or W* n or
a text object painted in text rendering mode 7.
• An invisible graphics object is a path object ended by the operator n only (with
no preceding
W or W*) or a text object painted in text rendering mode 3.
• A visible graphics object is a path object ended by any operator other than n, a
text object painted in any text rendering mode other than 3 or 7, or any
XObject invoked by the
Do operator.
• An empty marked-content element is a marked-content point or a marked-
content sequence that encloses no graphics objects.
• A marked clipping sequence is a marked-content sequence that contains at least
one clipping object and no visible graphics objects.
• Clipping objects and marked clipping sequences are considered part of an
enclosing marked-content sequence only if it is a marked clipping sequence.
• Invisible graphics objects and empty marked-content elements are always con-
sidered part of an enclosing marked-content sequence, regardless of whether it
is a marked clipping sequence.
• The q (save) and Q (restore) operators may not occur within a marked clipping
sequence.
Example 10.4 illustrates the application of these rules. Marked-content sequence
S4 is a marked clipping sequence because it contains a clipping object (clipping
path 2) and no visible graphics objects. Clipping path 2 is therefore considered
part of sequence
S4. Marked-content sequences S1, S2, and S3 are not marked
clipping sequences, since they each include at least one visible graphics object.
Thus, clipping paths 1 and 2 are not part of any of these three sequences.
Marked ContentSECTION 10.5
783
Example 10.4
/S1 BMC
/S2 BMC
/S3 BMC
00m
100 100 l
0 100 l W n % Clipping path 1
00m
200 200 l
0 100 l f % Filled path
EMC
/S4 BMC
00m
300 300 l
0 100 l W n % Clipping path 2
EMC
EMC
100 100 10 10 re f % Filled path
EMC
In Example 10.5, marked-content sequence S1 is a marked clipping sequence
because the only graphics object it contains is a clipping path. Thus, the empty
marked-content sequence
S3 and the marked-content point P1 are both part of
sequence
S2, and S2, S3, and P1 are all part of sequence S1.
Example 10.5
/S1 BMC
…Clipping path …
/S2 BMC
/S3 BMC
EMC
/P1 DP
EMC
EMC
In Example 10.6, marked-content sequences S1 and S4 are marked clipping
sequences because the only object they contain is a clipping path. Hence the
clipping path is part of sequences
S1 and S4; S3 is part of S2; and S2, S3, and S4 are
all part of
S1.
Document InterchangeCHAPTER 10
784
Example 10.6
/S1 BMC
/S2 BMC
/S3 BMC
EMC
EMC
/S4 BMC
…Clipping path …
EMC
EMC
10.6 Logical Structure
PDF’s logical structure facilities (PDF 1.3) provide a mechanism for incorporating
structural information about a document’s content into a PDF file. Such in-
formation might include, for example, the organization of the document into
chapters and sections or the identification of special elements such as figures,
tables, and footnotes. The logical structure facilities are extensible, allowing
applications that produce PDF files to choose what structural information to
include and how to represent it, while enabling PDF consumers to navigate a file
without knowing the producer’s structural conventions.
PDF logical structure shares basic features with standard document markup
languages such as HTML, SGML, and XML. A document’s logical structure is
expressed as a hierarchy of structure elements, each represented by a dictionary
object. Like their counterparts in other markup languages, PDF structure
elements can have content and attributes. In PDF, rendered document content
takes over the role occupied by text in HTML, SGML, and XML.
A PDF document’s logical structure is stored separately from its visible content,
with pointers from each to the other. This separation allows the ordering and
nesting of logical elements to be entirely independent of the order and location of
graphics objects on the document’s pages.
The
MarkInfo entry in the document catalog (see Section 3.6.1, “Document Cata-
log”) specifies a mark information dictionary, whose entries are shown in Table
10.8. It provides additional information relevant to specialized uses of structured
PDF documents.
Logical StructureSECTION 10.6
785
TABLE 10.8 Entries in the mark information dictionary
10.6.1 Structure Hierarchy
The logical structure of a document is described by a hierarchy of objects called
the structure hierarchy or structure tree. At the root of the hierarchy is a dictionary
object called the structure tree root, located by means of the
StructTreeRoot entry
in the document catalog (see Section 3.6.1, “Document Catalog”). Table 10.9
shows the entries in the structure tree root dictionary. The
K entry specifies the
immediate children of the structure tree root, which are structure elements.
Structure elements are represented by a dictionary, whose entries are shown in
Table 10.10. The
K entry specifies the children of the structure element, which
can be zero or more items of the following kinds:
• Other structure elements
• References to content items, which are either marked-content sequences (see
Section 10.5, “Marked Content”) or complete PDF objects such as XObjects
and annotations. These content items represent the graphical content, if any,
associated with a structure element. Content items are discussed in detail in
Section 10.6.3, “Structure Content.”
KEY TYPE VALUE
Marked
boolean (Optional) A flag indicating whether the document conforms to Tagged PDF
conventions. Default value:
false.
Note: If
Suspects is true, the document may not completely conform to Tagged PDF
conventions.
UserProperties
boolean (Optional; PDF 1.6) A flag indicating the presence of structure elements that
contain user properties attributes (see “User Properties” on page 804). Default
value:
false.
Suspects
boolean (Optional; PDF 1.6) A flag indicating the presence of tag suspects (see “Page
Content Order” on page 817). Default value:
false.
Document InterchangeCHAPTER 10
786
TABLE 10.9 Entries in the structure tree root
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be
StructTreeRoot for a structure tree root.
K
dictionary
or array
(Optional) The immediate child or children of the structure tree root in
the structure hierarchy. The value may be either a dictionary represent-
ing a single structure element or an array of such dictionaries.
IDTree
name tree (Required if any structure elements have element identifiers) A name tree
that maps element identifiers (see Table 10.10) to the structure elements
they denote.
ParentTree
number tree (Required if any structure element contains content items) A number tree
(see Section 3.8.6, “Number Trees”) used in finding the structure ele-
ments to which content items belong. Each integer key in the number
tree corresponds to a single page of the document or to an individual ob-
ject (such as an annotation or an XObject) that is a content item in its
own right. The integer key is given as the value of the
StructParent or
StructParents entry in that object (see “Finding Structure Elements from
Content Items” on page 797). The form of the associated value depends
on the nature of the object:
• For an object that is a content item in its own right, the value is an in-
direct reference to the object’s parent element (the structure element
that contains it as a content item).
• For a page object or content stream containing marked-content
sequences that are content items, the value is an array of references to
the parent elements of those marked-content sequences.
See “Finding Structure Elements from Content Items” on page 797 for
further discussion.
ParentTreeNextKey
integer (Optional) An integer greater than any key in the parent tree, to be used
as a key for the next entry added to the tree.
RoleMap
dictionary (Optional) A dictionary that maps the names of structure types used in
the document to their approximate equivalents in the set of standard
structure types (see Section 10.7.3, “Standard Structure Types”).
ClassMap
dictionary (Optional) A dictionary that maps name objects designating attribute
classes to the corresponding attribute objects or arrays of attribute ob-
jects (see “Attribute Classes” on page 802).
Logical StructureSECTION 10.6
787
TABLE 10.10 Entries in a structure element dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if
present, must be
StructElem for a structure element.
S
name (Required) The structure type, a name object identifying the nature of the
structure element and its role within the document, such as a chapter,
paragraph, or footnote (see Section 10.6.2, “Structure Types”). Names of
structure types must conform to the guidelines described in Appendix E.
P
dictionary (Required; must be an indirect reference) The structure element that is the
immediate parent of this one in the structure hierarchy.
ID
string (Optional) The element identifier, a string designating this structure
element. The string must be unique among all elements in the docu-
ment’s structure hierarchy. The
IDTree entry in the structure tree root
(see Table 10.9) defines the correspondence between element identifiers
and the structure elements they denote.
Pg
dictionary (Optional; must be an indirect reference) A page object representing a
page on which some or all of the content items designated by the
K entry
are rendered.
K
(various) (Optional) The children of this structure element. The value of this entry
may be one of the following objects or an array consisting of one or more
of the following objects:
• A structure element dictionary denoting another structure element
• An integer marked-content identifier denoting a marked-content
sequence
• A marked-content reference dictionary denoting a marked-content
sequence
• An object reference dictionary denoting a PDF object
Each of these objects other than the first (structure element dictionary)
is considered to be a content item; see Section 10.6.3, “Structure Content”
for further discussion of each of these forms of representation.
Note: If the value of
K is a dictionary containing no Type entry, it is as-
sumed to be a structure element dictionary.
Document InterchangeCHAPTER 10
788
A
(various) (Optional) A single attribute object or array of attribute objects associat-
ed with this structure element. Each attribute object is either a dictio-
nary or a stream. If the value of this entry is an array, each attribute
object in the array may be followed by an integer representing its revi-
sion number (see Section 10.6.4, “Structure Attributes,” and “Attribute
Revision Numbers” on page 803).
C
name or array (Optional) An attribute class name or array of class names associated
with this structure element. If the value of this entry is an array, each
class name in the array may be followed by an integer representing its re-
vision number (see “Attribute Classes” on page 802 and “Attribute Revi-
sion Numbers” on page 803).
Note: If both the
A and C entries are present and a given attribute is speci-
fied by both, the one specified by the
A entry takes precedence.
R
integer (Optional) The current revision number of this structure element (see
“Attribute Revision Numbers” on page 803). The value must be a non-
negative integer. Default value: 0.
T
text string (Optional) The title of the structure element, a text string representing it
in human-readable form. The title should characterize the specific struc-
ture element, such as
Chapter 1, rather than merely a generic element
type, such as
Chapter.
Lang
text string (Optional; PDF 1.4) A language identifier specifying the natural language
for all text in the structure element except where overridden by language
specifications for nested structure elements or marked content (see Sec-
tion 10.8.1, “Natural Language Specification”). If this entry is absent, the
language (if any) specified in the document catalog applies.
Alt
text string (Optional) An alternate description of the structure element and its
children in human-readable form, which is useful when extracting the
document’s contents in support of accessibility to users with disabilities
or for other purposes (see Section 10.8.2, “Alternate Descriptions”).
E
text string (Optional; PDF 1.5) The expanded form of an abbreviation.
ActualText
text string (Optional; PDF 1.4) Text that is an exact replacement for the structure el-
ement and its children. This replacement text (which should apply to as
small a piece of content as possible) is useful when extracting the docu-
ment’s contents in support of accessibility to users with disabilities or for
other purposes (see Section 10.8.3, “Replacement Text”).
KEY TYPE VALUE
Logical StructureSECTION 10.6
789
10.6.2 Structure Types
Every structure element has a structure type, a name object that identifies the
nature of the structure element and its role within the document (such as a chap-
ter, paragraph, or footnote). To facilitate the interchange of content among PDF
applications, Adobe has defined a set of standard structure types; see Section
10.7.3, “Standard Structure Types.” Applications are not required to adopt them,
however, and may use any names for their structure types.
Where names other than the standard ones are used, a role map may be provided
in the structure tree root, mapping the structure types used in the document to
their nearest equivalents in the standard set. For example, a structure type named
Section used in the document might be mapped to the standard type Sect. The
equivalence need not be exact; the role map merely indicates an approximate
analogy between types, allowing applications other than the one creating a docu-
ment to handle its nonstandard structure elements in a reasonable way.
Note: The same structure type may occur as both a key and a value in the role map,
and circular chains of association are explicitly permitted. A single role map can
thus define a bidirectional mapping. An application using the role map should fol-
low the chain of associations until it either finds a structure type it recognizes or re-
turns to one it has already encountered.
Note: In PDF versions earlier than 1.5, standard element types were never
remapped. Beginning with PDF 1.5, an element name is always mapped to its corre-
sponding name in the role map, if there is one, even if the original name is one of the
standard types. This is done to allow the element, for example, to represent a tag
with the same name as a standard role, even though its use differs from the standard
role.
10.6.3 Structure Content
Any structure element may have associated graphical content, consisting of one
or more content items. Content items are graphical objects that exist in the docu-
Document InterchangeCHAPTER 10
790
ment independently of the structure tree but are associated with structure ele-
ments as described in the following sections. Content items are of two kinds:
• Marked-content sequences within content streams (see “Marked-Content Se-
quences as Content Items”)
• Complete PDF objects such as annotations and XObjects (see “PDF Objects as
Content Items”)
The
K entry in a structure element dictionary (see Table 10.10) specifies the chil-
dren of the structure element, which can include any number of content items, as
well as child structure elements that may in turn have content items of their own.
Conceptually, content items must be leaf nodes of the structure tree; that is, they
cannot have other content items nested within them for purposes of logical struc-
ture. The hierarchical relationship among structure elements is represented en-
tirely by the
K entries of the structure element dictionaries, not by nesting of the
associated content items. Therefore, the following restrictions apply:
• A marked-content sequence delimiting a structure content item may not have
another marked-content sequence for a content item nested within it (though
non-structural marked content is allowed).
• A structure content item may not invoke (with the Do operator) an XObject
that is itself a structure content item.
Marked-Content Sequences as Content Items
A sequence of graphics operators in a content stream can be specified as a con-
tent item of a structure element in the following way:
• The operators must be bracketed as a marked-content sequence between BDC
and EMC operators (see Section 10.5, “Marked Content”)
Note: Although the tag associated with a marked-content sequence is not directly
related to the document’s logical structure, it should be the same as the structure
type of the associated structure element.
• The marked-content sequence must have a property list (see Section 10.5.1,
“Property Lists”) containing an
MCID entry, which is an integer marked-content
identifier that uniquely identifies the marked-content sequence within its con-
tent stream, as shown in the following example:
Logical StructureSECTION 10.6
791
Example 10.7
2 0 obj % Page object
<< /Type /Page
/Contents 3 0 R % Content stream
…
>>
endobj
3 0 obj % Page's content stream
<< /Length … >>
stream
…
/P << /MCID 0 >> % Start of marked-content sequence
BDC
…
(Here is some text) Tj
…
EMC % End of marked-content sequence
…
endstream
endobj
Note: This example and the following examples omit required StructParents entries
in the objects used as content items (see “Finding Structure Elements from Content
Items” on page 797).
A structure element dictionary can include one or more marked-content se-
quences as content items by referring to them in its
K entry (see Table 10.10). This
reference can have two forms:
• A dictionary object called a marked-content reference. Table 10.11 shows the
contents of this type of dictionary, which specifies the marked-content identifi-
er, as well other information identifying the stream in which the sequence is
contained. Example 10.8 illustrates the use of a marked-content reference to the
marked-content sequence shown in Example 10.7.
• An integer that specifies the marked-content identifier. This can be done in the
common case where the marked-content sequence is contained in the content
stream of the page that is specified in the
Pg entry of the structure element dic-
tionary. Example 10.9 shows a structure element that has three children: a
marked-content sequence specified by a marked-content identifier, as well as
two other structure elements.
Document InterchangeCHAPTER 10
792
Example 10.8
1 0 obj % Structure element
<< /Type /StructElem
/S /P % Structure type
/P … % Parent in structure hierarchy
/K << /Type /MCR
/Pg 2 0 R % Page containing marked-content sequence
/MCID 0 % Marked-content identifier
>>
>>
endobj
TABLE 10.11 Entries in a marked-content reference dictionary
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be MCR
for a marked-content reference.
Pg
dictionary (Optional; must be an indirect reference) The page object representing the page
on which the graphics objects in the marked-content sequence are rendered.
This entry overrides any
Pg entry in the structure element containing the
marked-content reference; it is required if the structure element has no such en-
try.
Stm
stream (Optional; must be an indirect reference) The content stream containing the
marked-content sequence. This entry should be present only if the marked-con-
tent sequence resides in a content stream other than the content stream for the
page—for example, in a form XObject (see Section 4.9, “Form XObjects”) or an
annotation’s appearance stream (Section 8.4.4, “Appearance Streams”). If this en-
try is absent, the marked-content sequence is contained in the content stream of
the page identified by
Pg (either in the marked-content reference dictionary or
in the parent structure element).
StmOwn
(any) (Optional; must be an indirect reference) The PDF object owning the stream
identified by
Stm—for example, the annotation to which an appearance stream
belongs.
MCID
integer (Required) The marked-content identifier of the marked-content sequence with-
in its content stream.
Logical StructureSECTION 10.6
793
Example 10.9
1 0 obj % Containing structure element
<< /Type /StructElem
/S /MixedContainer % Structure type
/P … % Parent in structure hierarchy
/Pg 2 0 R % Page containing marked-content sequence
/K [ 4 0 R % Three children: a structure element
0 % a marked-content identifier
5 0 R % another structure element
]
>>
endobj
2 0 obj % Page object
<< /Type /Page
/Contents 3 0 R % Content stream
…
>>
endobj
3 0 obj % Page's content stream
<< /Length … >>
stream
…
/P << /MCID 0 >> % Start of marked-content sequence
BDC
(Here is some text) Tj
…
EMC % End of marked-content sequence
…
endstream
endobj
Content streams other than page contents can also contain marked content se-
quences that are content items of structure elements. The content of form XOb-
jects can be incorporated into structure elements in one of the following ways:
• A Do operator that paints a form XObject can be part of a marked-content se-
quence that is associated with a structure element (see Example 10.10). In this
case, the entire form XObject is considered to be part of the structure element’s
content, as if it were inserted into the marked-content sequence at the point of
the
Do operator. The form XObject cannot in turn contain any marked-content
sequences associated with this or other structure elements.
Document InterchangeCHAPTER 10
794
• The content stream of a form XObject can contain one or more marked-con-
tent sequences that are associated with structure elements (see Example 10.11).
The form XObject can have arbitrary substructure, containing any number of
marked-content sequences associated with logical structure elements. Howev-
er, any
Do operator that paints the form XObject should not be part of a logical
structure content item.
Note: A form XObject that is painted with multiple invocations of the
Do operator
can be incorporated into the document’s logical structure only by the first method,
with each invocation of
Do individually associated with a structure element.
Example 10.10
1 0 obj % Structure element
<< /Type /StructElem
/S /P % Structure type
/P … % Parent in structure hierarchy
/Pg 2 0 R % Page containing marked-content sequence
/K 0 % Marked-content identifier
>>
endobj
2 0 obj % Page object
<< /Type /Page
/Resources << /XObject << /Fm4 4 0 R >> % Resource dictionary
>> % containing form XObject
/Contents 3 0 R % Content stream
…
>>
endobj
3 0 obj % Page's content stream
<< /Length … >>
stream
…
/P << /MCID 0 >> % Start of marked-content sequence
BDC
/Fm4 Do % Paint form XObject
EMC % End of marked-content sequence
…
endstream
endobj
Logical StructureSECTION 10.6
795
4 0 obj % Form XObject
<< /Type /XObject
/Subtype /Form
/Length …
>>
stream
…
(Here is some text) Tj
…
endstream
endobj
Example 10.11
1 0 obj % Structure element
<< /Type /StructElem
/S /P % Structure type
/P … % Parent in structure hierarchy
/K << /Type /MCR
/Pg 2 0 R % Page containing marked-content sequence
/Stm 4 0 R % Stream containing marked-content sequence
/MCID 0 % Marked-content identifier
>>
>>
endobj
2 0 obj % Page object
<< /Type /Page
/Resources << /XObject << /Fm4 4 0 R >> % Resource dictionary
>> % containing form XObject
/Contents 3 0 R % Content stream
…
>>
endobj
3 0 obj % Page's content stream
<< /Length … >>
stream
…
/Fm4 Do % Paint form XObject
…
endstream
endobj
Document InterchangeCHAPTER 10
796
4 0 obj % Form XObject
<< /Type /XObject
/Subtype /Form
/Length …
>>
stream
…
/P << /MCID 0 >> % Start of marked-content sequence
BDC
…
(Here is some text) Tj
…
EMC % End of marked-content sequence
…
endstream
endobj
PDF Objects as Content Items
When a structure element’s content includes an entire PDF object, such as an
XObject or an annotation, that is associated with a page but not directly included
in the page’s content stream, the object is identified in the structure element’s
K
entry by an object reference dictionary (see Table 10.12). Note that this form of ref-
erence is used only for entire objects. If the referenced content forms only part of
the object’s content stream, it is instead handled as a marked-content sequence, as
described in the preceding section.
TABLE 10.12 Entries in an object reference dictionary
Note: If the referenced object is rendered on multiple pages, each rendering requires
a separate object reference. However, if it is rendered multiple times on the same
page, just a single object reference suffices to identify all of them. (If it is important
KEY TYPE VALUE
Type
name (Required) The type of PDF object that this dictionary describes; must be OBJR for an
object reference.
Pg
dictionary (Optional; must be an indirect reference) The page object representing the page on
which the object is rendered. This entry overrides any
Pg entry in the structure element
containing the object reference; it is required if the structure element has no such entry.
Obj
(any) (Required; must be an indirect reference) The referenced object.
Logical StructureSECTION 10.6
797
to distinguish between multiple renditions of the same XObject on the same page,
they should be accessed by means of marked-content sequences enclosing particular
invocations of the
Do operator rather than through object references.)
Finding Structure Elements from Content Items
Because a stream cannot contain object references, there is no way for content
items that are marked-content sequences to refer directly back to their parent
structure elements (the ones to which they belong as content items). Instead, a
different mechanism, the structural parent tree, is provided for this purpose. For
consistency, content items that are entire PDF objects, such as XObjects, also use
the parent tree to refer to their parent structure elements.
The parent tree is a number tree (see Section 3.8.6, “Number Trees”), accessed
from the
ParentTree entry in a document’s structure tree root (Table 10.9 on page
786). The tree contains an entry for each object that is a content item of at least
one structure element and for each content stream containing at least one
marked-content sequence that is a content item. The key for each entry is an inte-
ger given as the value of the
StructParent or StructParents entry in the object (see
below). The values of these entries are as follows:
• For an object identified as a content item by means of an object reference (see
“PDF Objects as Content Items” on page 796), the value is an indirect reference
to the parent structure element.
• For a content stream containing marked-content sequences that are content
items, the value is an array of indirect references to the sequences’ parent struc-
ture elements. The array element corresponding to each sequence is found by
using the sequence’s marked-content identifier as a zero-based index into the
array.
Note: Because marked-content identifiers serve as indices into an array in the struc-
tural parent tree, their assigned values should be as small as possible to conserve
space in the array.
The
ParentTreeNextKey entry in the structure tree root holds an integer value
greater than any that is currently in use as a key in the structural parent tree.
Whenever a new entry is added to the parent tree, it uses the current value of
ParentTreeNextKey as its key. The value is then incremented to prepare for the
next new entry to be added.
Document InterchangeCHAPTER 10
798
To locate the relevant parent tree entry, each object or content stream that is rep-
resented in the tree must contain a special dictionary entry,
StructParent or
StructParents (see Table 10.13). Depending on the type of content item, this entry
may appear in the page object of a page containing marked-content sequences, in
the stream dictionary of a form or image XObject, in an annotation dictionary, or
in any other type of object dictionary that is included as a content item in a struc-
ture element. Its value is the integer key under which the entry corresponding to
the object is to be found in the structural parent tree.
TABLE 10.13 Additional dictionary entries for structure element access
For a content item identified by an object reference, the parent structure element
can thus be found by using the value of the
StructParent entry in the item’s object
dictionary as a retrieval key in the structural parent tree (found in the
ParentTree
entry of the structure tree root). The corresponding value retrieved from the
parent tree is a reference to the parent structure element (see Example 10.12).
KEY TYPE VALUE
StructParent
integer (Required for all objects that are structural content items; PDF 1.3) The integer
key of this object’s entry in the structural parent tree.
StructParents
integer (Required for all content streams containing marked-content sequences that are
structural content items; PDF 1.3) The integer key of this object’s entry in the
structural parent tree.
Note: At most one of these two entries may be present in a given object. An object
can be either a content item in its entirety or a container for marked-content
sequences that are content items, but not both.
Logical StructureSECTION 10.6
799
Example 10.12
1 0 obj % Parent structure element
<< /Type /StructElem
…
/K << /Type /OBJR % Object reference
/Pg 2 0 R % Page containing form XObject
/Obj 4 0 R % Reference to form XObject
>>
>>
endobj
2 0 obj % Page object
<< /Type /Page
/Resources << /XObject << /Fm4 4 0 R >> % Resource dictionary
>> % containing form XObject
/Contents 3 0 R % Content stream
…
>>
endobj
3 0 obj % Page's content stream
<< /Length … >>
stream
…
/Fm4 Do % Paint form XObject
…
endstream
endobj
4 0 obj % Form XObject
<< /Type /XObject
/Subtype /Form
/Length …
/StructParent 6 % Parent tree key
>>
stream
…
endstream
endobj
Document InterchangeCHAPTER 10
800
100 0 obj % Parent tree (accessed from structure tree root)
<< /Nums [ 0 101 0 R
1 102 0 R
…
6 1 0 R % Entry for page object 2; points back
… % to parent structure element
]
>>
endobj
For a content item that is a marked-content sequence, the retrieval method is
similar but slightly more complicated. Because a marked-content sequence is not
an object in its own right, its parent tree key is found in the
StructParents entry of
the page object or other content stream in which the sequence resides. The value
retrieved from the parent tree is not a reference to the parent structure element
itself but to an array of such references—one for each marked-content sequence
contained within that content stream. The parent structure element for the given
sequence is found by using the sequence’s marked-content identifier as an index
into this array (see Example 10.13).
Example 10.13
1 0 obj % Parent structure element
<< /Type /StructElem
…
/Pg 2 0 R % Page containing marked-content sequence
/K 0 % Marked-content identifier
>>
endobj
2 0 obj % Page object
<< /Type /Page
/Contents 3 0 R % Content stream
/StructParents 6 % Parent tree key
…
>>
endobj
Logical StructureSECTION 10.6
801
3 0 obj % Page's content stream
<< /Length … >>
stream
…
/P << /MCID 0 >> % Start of marked-content sequence
BDC
(Here is some text) TJ
…
EMC % End of marked-content sequence
…
endstream
endobj
100 0 obj % Parent tree (accessed from structure tree root)
<< /Nums [ 0 101 0 R
1 102 0 R
…
6 [1 0 R] % Entry for page object 2; array element at index 0
… % points back to parent structure element
]
>>
endobj
10.6.4 Structure Attributes
An application or plug-in extension that processes logical structure can attach ad-
ditional information, called attributes, to any structure element. The attribute in-
formation is held in one or more attribute objects associated with the structure
element. An attribute object is a dictionary or stream that includes an
O entry (see
Table 10.14) identifying the application or plug-in that owns the attribute
information. Other entries represent the attributes: the keys are attribute names,
and values are the corresponding attribute values. To facilitate the interchange of
content among PDF applications, Adobe has defined a set of standard structure
attributes identified by specific standard owners; see Section 10.7.4, “Standard
Structure Attributes.” In addition, PDF 1.6 introduces a use of attributes to repre-
sent user properties (see “User Properties” on page 804).
TABLE 10.14 Entry common to all attribute object dictionaries
KEY TYPE VALUE
O
name (Required) The name of the application or plug-in extension owning the attribute data.
The name must conform to the guidelines described in Appendix E.
Document InterchangeCHAPTER 10
802
Any application can attach attributes to any structure element, even one created
by another application. Multiple applications can attach attributes to the same
structure element. The
A entry in the structure element dictionary (see Table
10.10 on page 787) can hold either a single attribute object or an array of such
objects, together with revision numbers for coordinating attributes created by dif-
ferent owners (see “Attribute Revision Numbers” on page 803). An application
creating or destroying the second attribute object for a structure element is re-
sponsible for converting the value of the
A entry from a single object to an array
or vice versa, as well as for maintaining the integrity of the revision numbers. No
inherent order is defined for the attribute objects in an
A array, but it is consid-
ered good practice to add new objects at the end of the array so that the first ar-
ray element is the one belonging to the application that originally created the
structure element.
Attribute Classes
If many structure elements share the same set of attribute values, they can be
defined as an attribute class sharing the identical attribute object. Structure
elements refer to the class by name. The association between class names and
attribute objects is defined by a dictionary called the class map, kept in the
ClassMap entry of the structure tree root (see Table 10.9 on page 786). Each key
in the class map is a name object denoting the name of a class. The corresponding
value is an attribute object or an array of such objects.
Note: PDF attribute classes are unrelated to the concept of a class in object-oriented
programming languages such as Java and C++. Attribute classes are strictly a mech-
anism for storing attribute information in a more compact form; they have no in-
heritance properties like those of true object-oriented classes.
The
C entry in a structure element dictionary (see Table 10.10 on page 787) con-
tains a class name or an array of class names (typically accompanied by revision
numbers as well; see “Attribute Revision Numbers,” below). For each class named
in the
C entry, the corresponding attribute object or objects are considered to be
attached to the given structure element, along with those identified in the
element’s
A entry. If both the A and C entries are present and a given attribute is
specified by both, the one specified by the
A entry takes precedence.
Logical StructureSECTION 10.6
803
Attribute Revision Numbers
When an application modifies a structure element or its contents, the change may
affect the validity of attribute information attached to that structure element by
other applications. A system of revision numbers allows applications to detect
such changes and update their own attribute information accordingly, as de-
scribed in this section.
A structure element has a revision number, stored in the
R entry in the structure
element dictionary (see Table 10.10 on page 787). Initially, the revision number is
0 (the default value if no
R entry is present). When an application modifies the
structure element or any of its content items, it may signal the change by
incrementing the revision number.
Note: The revision number is unrelated to the generation number associated with
an indirect object (see Section 3.2.9, “Indirect Objects”).
Each attribute object attached to a structure element may have an associated revi-
sion number. The revision number is stored in the array that associates the
attribute object with the structure element:
• Each attribute object in a structure element’s A array is represented by a pair of
array elements, the first containing the attribute object itself and the second
containing the integer revision number associated with it in this structure
element.
• The structure element’s C array contains a pair of elements for each attribute
class, the first containing the class name and the second containing the associ-
ated revision number.
The revision numbers are optional in both the
A and C arrays. An attribute object
or class name that is not followed by an integer array element is understood to
have a revision number of 0.
Note: The revision number is not stored directly in the attribute object because a
single attribute object may be associated with more than one structure element
(whose revision numbers may differ).
When an attribute object is created or modified, its revision number is set to the
current value of the structure element’s
R entry. By comparing the attribute ob-
ject’s revision number with that of the structure element, an application can de-
Document InterchangeCHAPTER 10
804
termine whether the contents of the attribute object are still current or whether
they have been outdated by more recent changes in the underlying structure ele-
ment.
Note: Changes in an attribute object do not change the revision number of the asso-
ciated structure element, which changes only when the structure element itself or
any of its content items is modified.
Occasionally, an application may make extensive changes to a structure element
that are likely to invalidate all previous attribute information associated with it. In
this case, instead of incrementing the structure element’s revision number, the ap-
plication may choose to delete all unknown attribute objects from its
A and C ar-
rays. These two actions are mutually exclusive: the application should either
increment the structure element’s revision number or remove its attribute objects,
but not both. Note that any application creating attribute objects must be pre-
pared for the possibility that they may be deleted at any time by another applica-
tion.
User Properties
Most structure attributes (see Section 10.7.4, “Standard Structure Attributes”)
specify information that is reflected in the element’s appearance; for example,
BackgroundColor or BorderStyle. However, some PDF producers, such as CAD
applications, may use objects that have a standardized appearance, each of which
contains non-graphical information that distinguishes the objects from one an-
other. For example, several transistors might have the same appearance but dif-
ferent attributes such as type and part number.
User properties (PDF 1.6) can be used to contain such information. Any graphical
object that corresponds to a structure element may have associated user proper-
ties, specified by means of an attribute object dictionary with a value of
UserProperties for the O entry (see Table 10.15).
TABLE 10.15 Additional entries in an attribute object dictionary for user properties
KEY TYPE VALUE
O
name (Required) The attribute owner. Must be UserProperties.
P
array (Required) An array of dictionaries, each of which represents a user property (see Table
10.16).
Logical StructureSECTION 10.6
805
The P entry is an array specifying the user properties. Each element in the array is
a user property dictionary representing an individual property (see Table 10.16).
The order of the array elements is significant, allowing producers to specify at-
tributes in order of importance.
TABLE 10.16 Entries in a user property dictionary
PDF documents that contain user properties must provide a UserProperties entry
with a value of
true in the document’s mark information dictionary (see Table
10.8). This entry allows consumer applications to quickly determine whether it is
necessary to search the structure tree for elements containing user properties.
Example 10.14 shows a structure element containing user properties called
Part
Name
, Part Number, Supplier, and Price.
KEY TYPE VALUE
N
text (Required) The name of the user property.
V
any (Required) The value of the user property.
Note: While the value of this entry is allowed to be any type of PDF object, PDF producers
are strongly encouraged to use only text string, number, and boolean values. PDF consumers
are not required to display values of other types to users; however, they should tolerate other
values and not treat them as errors.
F
text string (Optional) A formatted representation of the value of V, used when special formatting is
required; for example “($123.45)” for the number -123.45. If this entry is absent, applica-
tions should use a default format.
H
boolean (Optional) If true, the attribute is hidden; that is, it should not be shown in any user inter-
face element that presents the attributes of an object. Default value:
false.
Document InterchangeCHAPTER 10
806
Example 10.14
100 0 obj
<< /Type /StructElem
/S /Figure % Structure type
/P 50 0 R % Parent in structure tree
/A << /O /UserProperties % Attribute object
/P [ % Array of user properties
<< /N (Part Name) /V (Framostat) >>
<< /N (Part Number) /V 11603 >>
<< /N (Supplier) /V (Just Framostats) /H true >> % Hidden attribute
<< /N (Price) /V -37.99 /F ($37.99) >> % Formatted value
]
>>
>>
endobj
10.6.5 Example of Logical Structure
Example 10.15 shows portions of a PDF file with a simple document structure.
The structure tree root (object 300) contains elements with structure types
Chap
(object 301) and Para (object 304). The Chap element, titled Chapter 1, contains
elements with types
Head1 (object 302) and Para (object 303).
These elements are mapped to the standard structure types specified in Tagged
PDF (see Section 10.7.3, “Standard Structure Types”) by means of the role map
specified in the structure tree root. Objects 302 through 304 have attached at-
tributes (see Section 10.6.4, “Structure Attributes”and Section 10.7.4, “Standard
Structure Attributes”).
The example also illustrates the structure of a parent tree (object 400) that maps
content items back to their parent structure elements and an ID tree (object 403)
that maps element identifiers to the structure elements they denote.
Example 10.15
1 0 obj % Document catalog
<< /Type /Catalog
/Pages 100 0 R % Page tree
/StructTreeRoot 300 0 R % Structure tree root
>>
endobj
Logical StructureSECTION 10.6
807
100 0 obj % Page tree
<< /Type /Pages
/Kids [ 101 1 R % First page object
102 0 R % Second page object
]
/Count 2 % Page count
>>
endobj
101 1 obj % First page object
<< /Type /Page
/Parent 100 0 R % Parent is the page tree
/Resources << /Font << /F1 6 0 R % Font resources
/F12 7 0 R
>>
/ProcSet [/PDF /Text] % Procedure sets
>>
/MediaBox [0 0 612 792] % Media box
/Contents 201 0 R % Content stream
/StructParents 0 % Parent tree key
>>
endobj
201 0 obj % Content stream for first page
<< /Length … >>
stream
111rg
0 0 612 792 re f
BT % Start of text object
/Head1 << /MCID 0 >> % Start of marked-content sequence 0
BDC
000rg
/F1 1 Tf
30 0 0 30 18 732 Tm
(This is a first level heading. Hello world: ) Tj
1.1333 TL
T*
(goodbye universe.) Tj
EMC % End of marked-content sequence 0
Document InterchangeCHAPTER 10
808
/Para << /MCID 1 >> % Start of marked-content sequence 1
BDC
/F12 1 Tf
14 0 0 14 18 660.8 Tm
(This is the first paragraph, which spans pages . It has four fairly short and \
concise sentences. This is the next to last ) Tj
EMC % End of marked-content sequence 1
ET % End of text object
endstream
endobj
102 0 obj % Second page object
<< /Type /Page
/Parent 100 0 R % Parent is the page tree
/Resources << /Font << /F1 6 0 R % Font resources
/F12 7 0 R
>>
/ProcSet [/PDF /Text] % Procedure sets
>>
/MediaBox [0 0 612 792] % Media box
/Contents 202 0 R % Content stream
/StructParents 1 % Parent tree key
>>
endobj
202 0 obj % Content stream for second page
<< /Length … >>
stream
111rg
0 0 612 792 re f
BT % Start of text object
/Para << /MCID 0 >> % Start of marked-content sequence 0
BDC
000rg
/F12 1 Tf
14 0 0 14 18 732 Tm
(sentence. This is the very last sentence of the first paragraph.) Tj
EMC % End of marked-content sequence 0
Logical StructureSECTION 10.6
809
/Para << /MCID 1 >> % Start of marked-content sequence 1
BDC
/F12 1 Tf
14 0 0 14 18 570.8 Tm
(This is the second paragraph. It has four fairly short and concise sentences. \
This is the next to last ) Tj
EMC % End of marked-content sequence 1
/Para << /MCID 2 >> % Start of marked-content sequence 2
BDC
1.1429 TL
T*
(sentence. This is the very last sentence of the second paragraph.) Tj
EMC % End of marked-content sequence 2
ET % End of text object
endstream
endobj
300 0 obj % Structure tree root
<< /Type /StructTreeRoot
/K [ 301 0 R % Two children: a chapter
304 0 R % and a paragraph
]
/RoleMap << /Chap /Sect % Mapping to standard structure types
/Head1 /H
/Para /P
>>
/ClassMap << /Normal 305 0 R >> % Class map containing one attribute class
/ParentTree 400 0 R % Number tree for parent elements
/ParentTreeNextKey 2 % Next key to use in parent tree
/IDTree 403 0 R % Name tree for element identifiers
>>
endobj
301 0 obj % Structure element for a chapter
<< /Type /StructElem
/S /Chap
/ID (Chap1) % Element identifier
/T (Chapter 1) % Human-readable title
/P 300 0 R % Parent is the structure tree root
/K [ 302 0 R % Two children: a section head
303 0 R % and a paragraph
]
>>
endobj
Document InterchangeCHAPTER 10
810
302 0 obj % Structure element for a section head
<< /Type /StructElem
/S /Head1
/ID (Sec1.1) % Element identifier
/T (Section 1.1) % Human-readable title
/P 301 0 R % Parent is the chapter
/Pg 101 1 R % Page containing content items
/A << /O /Layout % Attribute owned by Layout
/SpaceAfter 25
/SpaceBefore 0
/TextIndent 12.5
>>
/K 0 % Marked-content sequence 0
>>
endobj
303 0 obj % Structure element for a paragraph
<< /Type /StructElem
/S /Para
/ID (Para1) % Element identifier
/P 301 0 R % Parent is the chapter
/Pg 101 1 R % Page containing first content item
/C /Normal % Class containing this element’s attributes
/K [ 1 % Marked-content sequence 1
<< /Type /MCR % Marked-content reference to 2nd item
/Pg 102 0 R % Page containing second item
/MCID 0 % Marked-content sequence 0
>>
]
>>
endobj
304 0 obj % Structure element for another paragraph
<< /Type /StructElem
/S /Para
/ID (Para2) % Element identifier
/P 300 0 R % Parent is the structure tree root
/Pg 102 0 R % Page containing content items
/C /Normal % Class containing this element’s attributes
/A << /O /Layout
/TextAlign /Justify % Overrides attribute provided by classmap
>>
/K [1 2] % Marked-content sequences 1 and 2
>>
endobj
Logical StructureSECTION 10.6
811
305 0 obj % Attribute class
<< /O /Layout % Owned by Layout
/EndIndent 0
/StartIndent 0
/WritingMode /LrTb
/TextAlign /Start
>>
endobj
400 0 obj % Parent tree
<< /Nums [ 0 401 0 R % Parent elements for first page
1 402 0 R % Parent elements for second page
]
>>
endobj
401 0 obj % Array of parent elements for first page
[ 302 0 R % Parent of marked-content sequence 0
303 0 R % Parent of marked-content sequence 1
]
endobj
402 0 obj % Array of parent elements for second page
[ 303 0 R % Parent of marked-content sequence 0
304 0 R % Parent of marked-content sequence 1
304 0 R % Parent of marked-content sequence 2
]
endobj
403 0 obj % ID tree root node
<< /Kids [404 0 R] >> % Reference to leaf node
endobj
404 0 obj % ID tree leaf node
<< /Limits [ (Chap1) (Sec1.3) ] % Least and greatest keys in tree
/Names [ (Chap1) 301 0 R % Mapping from element identifiers
(Sec1.1) 302 0 R % to structure elements
(Sec1.2) 303 0 R
(Sec1.3) 304 0 R
]
>>
endobj
Document InterchangeCHAPTER 10
812
10.7 Tagged PDF
Tagged PDF (PDF 1.4) is a stylized use of PDF that builds on the logical structure
framework described in Section 10.6, “Logical Structure.” It defines a set of stan-
dard structure types and attributes that allow page content (text, graphics, and
images) to be extracted and reused for other purposes. It is intended for use by
tools that perform the following types of operations:
• Simple extraction of text and graphics for pasting into other applications
• Automatic reflow of text and associated graphics to fit a page of a different size
than was assumed for the original layout
• Processing text for such purposes as searching, indexing, and spell-checking
• Conversion to other common file formats (such as HTML, XML, and RTF)
with document structure and basic styling information preserved
• Making content accessible to users with visual impairments (see Section 10.8,
“Accessibility Support)
A tagged PDF document conforms to the following conventions:
• Page content (Section 10.7.1, “Tagged PDF and Page Content”). Tagged PDF
defines a set of rules for representing text in the page content so that characters,
words, and text order can be determined reliably. All text is represented in a
form that can be converted to Unicode. Word breaks are represented explicitly.
Actual content is distinguished from artifacts of layout and pagination. Content
is given in an order related to its appearance on the page, as determined by the
authoring application.
• A basic layout model (Section 10.7.2, “Basic Layout Model”). A set of rules for
describing the arrangement of structure elements on the page.
• Structure types (Section 10.7.3, “Standard Structure Types”). A set of standard
structure types define the meaning of structure elements, such as paragraphs,
headings, articles, and tables.
• Structure attributes (Section 10.7.4, “Standard Structure Attributes”). Standard
structure attributes preserve styling information used by the authoring applica-
tion in laying out content on the page.
A Tagged PDF document must also contain a mark information dictionary (see
Table 10.8) with a value of
true for the Marked entry.
Tagged PDFSECTION 10.7
813
Note: The types and attributes defined for Tagged PDF are intended to provide a set
of standard fallback roles and minimum guaranteed attributes to enable consumer
applications to perform operations such as those mentioned above. Producer appli-
cations are free to define additional structure types as long as they also provide a
role mapping to the nearest equivalent standard types, as described in Section
10.6.2, “Structure Types.” Likewise, producer applications can define additional
structure attributes using any of the available extension mechanisms.
10.7.1 Tagged PDF and Page Content
Like all PDF documents, a Tagged PDF document consists of a sequence of self-
contained pages, each of which is described by one or more page content streams
(including any subsidiary streams such as form XObjects and annotation appear-
ances). Tagged PDF defines some further conventions for organizing and mark-
ing content streams so that additional information can be derived from them:
• Distinguishing between the author’s original content and artifacts of the layout
process (see “Real Content and Artifacts” on page 813)
• Specifying a content order to guide the layout process if the page content must
be reflowed (see “Page Content Order” on page 817)
• Representing text in a form from which a Unicode representation and informa-
tion about font characteristics can be unambiguously derived (see “Extraction
of Character Properties” on page 819)
• Representing word breaks unambiguously (see “Identifying Word Breaks” on
page 822)
• Marking text with information for making it accessible to users with visual im-
pairments (see Section 10.8, “Accessibility Support)
Real Content and Artifacts
The graphics objects in a document can be divided into two classes:
• The real content of a document comprises objects representing material origi-
nally introduced by the document’s author.
• Artifacts are graphics objects that are not part of the author’s original content
but rather are generated by the PDF producer application in the course of pagi-
nation, layout, or other strictly mechanical processes.
Document InterchangeCHAPTER 10
814
The document’s logical structure encompasses all graphics objects making up the
real content and describes how those objects relate to one another. It does not in-
clude graphics objects that are mere artifacts of the layout and production pro-
cess.
A document’s real content includes not only the page content stream and subsid-
iary form XObjects but also associated annotations that meet all of the following
conditions:
• The annotation has an appearance stream (see Section 8.4.4, “Appearance
Streams”) containing a normal (
N) appearance.
• The annotation’s Hidden flag (see Section 8.4.2, “Annotation Flags”) is not set.
• The annotation is included in the document’s logical structure (see Section
10.6, “Logical Structure”).
Specification of Artifacts
An artifact can be explicitly distinguished from real content by enclosing it in a
marked-content sequence with the tag
Artifact:
/Artifact /Artifact propertyList
BMC BDC
…or …
EMC EMC
The first form is used to identify a generic artifact; the second is used for those
that have an associated property list. Table 10.17 shows the properties that can be
included in such a property list.
Note: To aid in text reflow, it is recommended that artifacts be defined with proper-
ty lists whenever possible. Artifacts lacking a specified bounding box are likely to be
discarded during reflow.
TABLE 10.17 Property list entries for artifacts
KEY TYPE VALUE
Type
name (Optional) The type of artifact that this property list describes; if present, must
be one of the names
Pagination, Layout, or Page.
Tagged PDFSECTION 10.7
815
The following types of artifacts can be specified by the Type entry:
• Pagination artifacts. Ancillary page features such as running heads and folios
(page numbers).
• Layout artifacts. Purely cosmetic typographical or design elements such as
footnote rules or background screens.
• Page artifacts. Production aids extraneous to the document itself, such as cut
marks and color bars.
Tagged PDF consumer applications may have their own ideas about what page
content to consider relevant. A text-to-speech engine, for instance, probably
should not speak running heads or page numbers when the page is turned. In
general, consumer applications can do any of the following:
• Disregard elements of page content (for example, specific types of artifacts)
that are not of interest
• Treat some page elements as terminals that are not to be examined further (for
example, to treat an illustration as a unit for reflow purposes)
• Replace an element with alternate text (see Section 10.8.2, “Alternate Descrip-
tions”)
Depending on their goals, different consumer applications can make different de-
cisions in this regard. The purpose of Tagged PDF is not to prescribe what the
consumer application should do, but to provide sufficient declarative and de-
scriptive information to allow it to make appropriate choices about how to pro-
cess the content.
BBox
rectangle (Optional) An array of four numbers in default user space units giving the coor-
dinates of the left, bottom, right, and top edges, respectively, of the artifact’s
bounding box (the rectangle that completely encloses its visible extent).
Attached
array (Optional; pagination artifacts only) An array of name objects containing one to
four of the names
Top, Bottom, Left, and Right, specifying the edges of the page, if
any, to which the artifact is logically attached. Page edges are defined by the
page’s crop box (see Section 10.10.1, “Page Boundaries”). The ordering of names
within the array is immaterial. Including both
Left and Right or both Top and
Bottom indicates a full-width or full-height artifact, respectively.
KEY TYPE VALUE
Document InterchangeCHAPTER 10
816
Note: To support consumer applications in providing accessibility to users with dis-
abilities, Tagged PDF documents should use the natural language specification
(
Lang), alternate description (Alt), replacement text (ActualText), and abbreviation
expansion text (
E) facilities described in Section 10.8, “Accessibility Support.”
Incidental Artifacts
In addition to objects that are explicitly marked as artifacts and excluded from
the document’s logical structure, the running text of a page may contain other el-
ements and relationships that are not logically part of the document’s real con-
tent, but merely incidental results of the process of laying out that content into a
document. They may include the following elements:
• Hyphenation. Among the artifacts introduced by text layout is the hyphen
marking the incidental division of a word at the end of a line. In Tagged PDF,
such an incidental word division must be represented by a soft hyphen charac-
ter, which the Unicode mapping algorithm (see “Unicode Mapping in Tagged
PDF” on page 820) translates to the Unicode value
U+00AD. (This character is
distinct from an ordinary hard hyphen, whose Unicode value is
U+002D.) The
producer of a Tagged PDF document must distinguish explicitly between soft
and hard hyphens so that the consumer does not have to guess which type a
given character represents.
Note: In some languages, the situation is more complicated: there may be multiple
hyphen characters, and hyphenation may change the spelling of words. See Exam-
ple 10.24 on page 872.
• Text discontinuities. The running text of a page, as expressed in page content
order (see “Page Content Order,” below), may contain places where the normal
progression of text suffers a discontinuity. For example, the page may contain
the beginnings of two separate articles (see Section 8.3.2, “Articles”), each of
which is continued onto a later page of the document. The last words of the
first article appearing on the page should not be run together with the first
words of the second article. Consumer applications can recognize such discon-
tinuities by examining the document’s logical structure.
• Hidden page elements. For a variety of reasons, elements of a document’s logical
content may be invisible on the page: they may be clipped, their color may
match the background, or they may be obscured by other, overlapping objects.
Consumer applications must still be able to recognize and process such hidden
elements. For example, formerly invisible elements may become visible when a
Tagged PDFSECTION 10.7
817
page is reflowed, or a text-to-speech engine may choose to speak text that is not
visible to a sighted reader. For the purposes of Tagged PDF, page content is con-
sidered to include all text and illustrations in their entirety, regardless of
whether they are visible when the document is displayed or printed.
Page Content Order
When dealing with material on a page-by-page basis, some Tagged PDF consum-
er applications may wish to process elements in page content order, determined by
the sequencing of graphics objects within a page’s content stream and of charac-
ters within a text object, rather than in the logical structure order defined by a
depth-first traversal of the page’s logical structure hierarchy. The two orderings
are logically distinct and may or may not coincide. In particular, any artifacts the
page may contain are included in the page content order but not in the logical
structure order, since they are not considered part of the document’s logical
structure. The creator of a Tagged PDF document is responsible for establishing
both an appropriate page content order for each page and an appropriate logical
structure hierarchy for the entire document.
Because the primary requirement for page content order is to enable reflow to
maintain elements in proper reading sequence, it should normally (for Western
writing systems) proceed from top to bottom (and, in a multiple-column layout,
from column to column), with artifacts in their correct relative places. In general,
all parts of an article that appear on a given page should be kept together, even if
it flows to scattered locations on the page. Illustrations or footnotes may be inter-
spersed with the text of the associated article or may appear at the end of its con-
tent (or, in the case of footnotes, at the end of the entire page’s logical content).
In some situations, a producer that intends to generate Tagged PDF may be un-
able to generate correct page content order for part of a document’s contents. This
can occur, for example, if content was extracted from another application, or if
there are ambiguities or missing information in text output. In such cases, tag sus-
pects (PDF 1.6) can be used. The producer can identify suspect content by using
marked content (see Section 10.5, “Marked Content”) with a tag of
TagSuspect, as
shown in Example 10.16. The marked content must have a properties dictionary
with an entry whose name is
TagSuspect and whose value is Ordering, which in-
dicates that the ordering of the enclosed marked content does not meet Tagged
PDF specifications.
Document InterchangeCHAPTER 10
818
Example 10.16
/TagSuspect <</TagSuspect /Ordering>>
BDC
.... % Problem page contents
EMC
Documents containing tag suspects must contain a Suspects entry with a value of
true in the mark information dictionary (see Table 10.8). Consumer applications
encountering this entry should process the
TagSuspect marked content in an
manner appropriate to their use of Tagged PDF.
Sequencing of Annotations
Annotations associated with a page are not interleaved within the page’s content
stream but are placed in the
Annots array in its page object (see “Page Objects” on
page 119). Consequently, the correct position of an annotation in the page con-
tent order is not readily apparent but is determined from the document’s logical
structure.
Both page content (marked-content sequences) and annotations can be treated as
content items that are referenced from structure elements (see Section 10.6.3,
“Structure Content”). Structure elements of type
Annot (PDF 1.5), Link, or Form
(see “Inline-Level Structure Elements” on page 834 and “Illustration Elements”
on page 841) explicitly specify the association between a marked-content se-
quence and a corresponding annotation. In other cases, if the structure element
corresponding to an annotation immediately precedes or follows (in the logical
structure order) a structure element corresponding to a marked-content se-
quence, the annotation is considered to precede or follow the marked-content se-
quence, respectively, in the page content order.
Note: If necessary, a Tagged PDF producer may introduce an empty marked-content
sequence solely to serve as a structure element for the purpose of positioning adja-
cent annotations in the page content order.
Reverse-Order Show Strings
In writing systems that are read from right to left (such as Arabic or Hebrew), one
might expect that the glyphs in a font would have their origins at the lower right
and their widths (rightward horizontal displacements) specified as negative. For
Tagged PDFSECTION 10.7
819
various technical and historical reasons, however, many such fonts follow the
same conventions as those designed for Western writing systems, with glyph ori-
gins at the lower left and positive widths, as shown in Figure 5.4 on page 364.
Consequently, showing text in such right-to-left writing systems requires either
positioning each glyph individually (which is tedious and costly) or representing
text with show strings (see “Organization and Use of Fonts” on page 358) whose
character codes are given in reverse order. When the latter method is used, the
character codes’ correct page content order is the reverse of their order within the
show string.
The marked-content tag
ReversedChars informs the Tagged PDF consumer appli-
cation that show strings within a marked-content sequence contain characters in
the reverse of page content order. If the sequence encompasses multiple show
strings, only the individual characters within each string are reversed; the strings
themselves are in natural reading order. For example, the sequence
/ReversedChars
BMC
( olleH) Tj
200 0 Td
(.dlrow) Tj
EMC
represents the text
Hello world.
The show strings may have a space character at the beginning or end to indicate a
word break (see “Identifying Word Breaks” on page 822) but may not contain
interior spaces. This limitation is not serious, since a space provides an opportu-
nity to realign the typography without visible effect, and it serves the valuable
purpose of limiting the scope of reversals for word-processing consumer applica-
tions.
Extraction of Character Properties
It is a requirement of Tagged PDF that character codes can be unambiguously
converted to Unicode values representing the information content of the text.
There are several methods for doing this; a Tagged PDF document must conform
to at least one of them (see “Unicode Mapping in Tagged PDF,” below).
Document InterchangeCHAPTER 10
820
In addition, Tagged PDF documents must allow some characteristics of the asso-
ciated fonts to be deduced (see “Font Characteristics” on page 820). These Uni-
code values and font characteristics can then be used for such operations as cut-
and-paste editing, searching, text-to-speech conversion, and exporting to other
applications or file formats.
Unicode Mapping in Tagged PDF
Tagged PDF requires that every character code in a document can be mapped to
a corresponding Unicode value. Unicode defines scalar values for most of the
characters used in the world’s languages and writing systems, as well as providing
a private use area for application-specific characters. Information about Unicode
can be found in the Unicode Standard, by the Unicode Consortium (see the Bib-
liography).
The methods for mapping a character code to a Unicode value are described in
Section 5.9.1, “Mapping Character Codes to Unicode Values.” Tagged PDF pro-
ducers should ensure that the PDF file contains enough information to map all
character codes to Unicode by one of the methods described there.
An
Alt, ActualText, or E entry specified in a structure element dictionary or a
marked-content property list (see Sections 10.8.2, “Alternate Descriptions,”
10.8.3, “Replacement Text,” and 10.8.4, “Expansion of Abbreviations and Acro-
nyms”) may affect the character stream that some Tagged PDF consumers actual-
ly use. For example, some consumers may choose to use the
Alt or ActualText
value and ignore all text and other content associated with the structure element
and its descendants.
Some uses of Tagged PDF require characters that may not be available in all fonts,
such as the soft hyphen (see “Incidental Artifacts” on page 816). Such characters
can be represented either by adding them to the font’s encoding or CMap and
using
ToUnicode to map them to appropriate Unicode values, or by using an
ActualText entry in the associated structure element to provide substitute charac-
ters.
Font Characteristics
In addition to a Unicode value, each character code in a content stream has an as-
sociated set of font characteristics. These characteristics are useful when export-
Tagged PDFSECTION 10.7
821
ing text to another application or file format that has a limited repertoire of
available fonts.
Table 10.18 lists a common set of font characteristics corresponding to those used
in CSS and XSL; the W3C document Extensible Stylesheet Language (XSL) 1.0
provides more information (see the Bibliography). Each of the characteristics can
be derived from information available in the font descriptor’s
Flags entry (see
Section 5.7.1, “Font Descriptor Flags”).
TABLE 10.18 Derivation of font characteristics
Note: The characteristics shown in the table apply only to character codes con-
tained in show strings within content streams. They do not exist for alternate de-
scription text (
Alt), replacement text (ActualText), or abbreviation expansion text
(
E).
Note: For the standard 14 Type 1 fonts, the font descriptor may be missing; the well-
known values for those fonts are used.
Tagged PDF in PDF 1.5 defines a wider set of font characteristics, which provide
information needed when converting PDF to other files formats such as RTF,
HTML, XML, and OEB, and also improve accessibility and reflow of tables. Table
10.19 lists these font selector attributes and shows how their values are derived.
Note: If the
FontFamily, FontWeight and FontStretch fields are not present in the font de-
scriptor, these values are derived from the font name in an implementation-defined
manner.
CHARACTERISTIC TYPE DERIVATION
Serifed boolean The value of the Serif flag in the font descriptor’s Flags entry
Proportional boolean The complement of the FixedPitch flag in the font descriptor’s
Flags entry
Italic boolean The value of the Italic flag in the font descriptor’s
Flags entry
Smallcap boolean The value of the SmallCap flag in the font descriptor’s
Flags entry
Document InterchangeCHAPTER 10
822
TABLE 10.19 Font Selector Attributes
Identifying Word Breaks
A document’s text stream defines not only the characters in a page’s text but also
the words. Unlike a character, the notion of a word is not precisely defined but
depends on the purpose for which the text is being processed. A reflow tool needs
to determine where it can break the running text into lines; a text-to-speech en-
gine needs to identify the words to be vocalized; spelling checkers and other ap-
ATTRIBUTE DESCRIPTION
FontFamily
A string specifying the preferred font family name. Derived from the FontFamily entry
in the font descriptor (see Table 5.19 on page 426).
GenericFontFamily
A general font classification, used if FontFamily is not found. The following values are
supported; with two exceptions, they can be derived from the font descriptor’s
Flags en-
try:
• Serif: Chosen if the Serif flag is set and the FixedPitch and Script flags are not set
• SansSerif: Chosen if the FixedPitch, Script and Serif flags are all not set
• Cursive: Chosen if the Script flag is set and the FixedPitch flag is not set
• Monospace: Chosen if the FixedPitch flag is set
• Decorative: Cannot be derived
• Symbol: Cannot be derived
FontSize
The size of the font: a positive fixed-point number specifying the height of the typeface
in points. It is derived from the
a, b, c, and d fields of the current text matrix.
FontStretch
The stretch value of the font. It can be derived from FontStretch in the font descriptor
(see Table 5.19 on page 426).
FontStyle
The italicization value of the font. It is set to Italic if the Italic flag is set in the Flags field
of the font descriptor. Otherwise, it is set to
Normal.
FontVariant
The small-caps value of the font. It is set to SmallCaps if the SmallCap flag is set in the
Flags field of the font descriptor. Otherwise, it is set to Normal.
FontWeight
The weight (thickness) value of the font. It can be derived from FontWeight in the font
descriptor (see Table 5.19 on page 426).
The ForceBold flag and the
StemV field should not be used to set this attribute.
Tagged PDFSECTION 10.7
823
plications all have their own ideas of what constitutes a word. It is not important
for a Tagged PDF document to identify the words within the text stream accord-
ing to a single, unambiguous definition that satisfies all of these clients. What is
important is that there be enough information available for each client to make
that determination for itself.
The consumer of a Tagged PDF document finds words by sequentially examining
the Unicode character stream, perhaps augmented by replacement text specified
with
ActualText (see Section 10.8.3, “Replacement Text”). The consumer does not
need to guess about word breaks based on information such as glyph positioning
on the page, font changes, or glyph sizes. The main consideration is to ensure that
the spacing characters that would be present to separate words in a pure text rep-
resentation are also present in the Tagged PDF.
Note that the identification of what constitutes a word is unrelated to how the text
happens to be grouped into show strings. The division into show strings has no
semantic significance. In particular, a space or other word-breaking character is
still needed even if a word break happens to fall at the end of a show string.
Note: Some applications may identify words by simply separating them at every
space character. Others may be slightly more sophisticated and treat punctuation
marks such as hyphens or em dashes as word separators as well. Still other applica-
tions may identify possible line-break opportunities by using an algorithm similar to
the one in Unicode Standard Annex #29, Text Boundaries, available from the Uni-
code Consortium (see the Bibliography).
10.7.2 Basic Layout Model
Tagged PDF’s standard structure types and attributes are interpreted in the con-
text of a basic layout model that describes the arrangement of structure elements
on the page. This model is designed to capture the general intent of the docu-
ment’s underlying structure and does not necessarily correspond to the one actu-
ally used for page layout by the application creating the document. (The PDF
content stream specifies the exact appearance.) The goal is to provide sufficient
information for Tagged PDF consumers to make their own layout decisions while
preserving the authoring application’s intent as closely as their own layout models
allow.
Document InterchangeCHAPTER 10
824
Note: The Tagged PDF layout model resembles the ones used in markup languages
such as HTML, CSS, XSL, and RTF, but does not correspond exactly to any of them.
The model is deliberately defined loosely to allow reasonable latitude in the interpre-
tation of structure elements and attributes when converting to other document for-
mats. Some degree of variation in the resulting layout from one format to another is
to be expected.
The basic layout model begins with the notion of a reference area. This is a rect-
angular region used by the layout application as a frame or guide in which to
place the document’s content. Some of the standard structure attributes, such as
StartIndent and EndIndent (see “Layout Attributes for BLSEs” on page 851), are
measured from the boundaries of the reference area. Reference areas are not
specified explicitly but are inferred from context. Those of interest are generally
the column area or areas in a general text layout, the outer bounding box of a
table and those of its component cells, and the bounding box of an illustration or
other floating element.
The standard structure types are divided into four main categories according to
the roles they play in page layout:
• Grouping elements (see “Grouping Elements” on page 827) group other ele-
ments into sequences or hierarchies but hold no content directly and have no
direct effect on layout.
• Block-level structure elements (BLSEs) (see “Block-Level Structure Elements” on
page 829) describe the overall layout of content on the page, proceeding in the
block-progression direction.
• Inline-level structure elements (ILSEs) (see “Inline-Level Structure Elements” on
page 834) describe the layout of content within a BLSE, proceeding in the in-
line-progression direction.
• Illustration elements (see “Illustration Elements” on page 841) are compact se-
quences of content, in page content order, that are considered to be unitary ob-
jects with respect to page layout. An illustration can be treated as either a BLSE
or an ILSE.
The meaning of the terms block-progression direction and inline-progression
direction depends on the writing system in use, as specified by the standard
attribute
WritingMode (see “General Layout Attributes” on page 846). In Western
writing systems, the block direction is from top to bottom and the inline direc-
Tagged PDFSECTION 10.7
825
tion is from left to right. Other writing systems use different directions for laying
out content.
Because the progression directions can vary depending on the writing system,
edges of areas and directions on the page must be identified by terms that are
neutral with respect to the progression order rather than by familiar terms such
as up, down, left, and right. Block layout proceeds from before to after, inline
from start to end. Thus, for example, in Western writing systems, the before and
after edges of a reference area are at the top and bottom, respectively, and the
start and end edges are at the left and right. Another term, shift direction (the
direction of shift for a superscript), refers to the direction opposite that for block
progression—that is, from after to before (in Western writing systems, from bot-
tom to top).
BLSEs are stacked within a reference area in block-progression order. In general,
the first BLSE is placed against the before edge of the reference area. Subsequent
BLSEs are stacked against preceding ones, progressing toward the after edge, until
no more BLSEs fit in the reference area. If the overflowing BLSE allows itself to be
split—such as a paragraph that can be split between lines of text—a portion of it
may be included in the current reference area and the remainder carried over to a
subsequent reference area (either elsewhere on the same page or on another page
of the document). Once the amount of content that fits in a reference area is de-
termined, the placements of the individual BLSEs may be adjusted to bias the
placement toward the before edge, the middle, or the after edge of the reference
area, or the spacing within or between BLSEs may be adjusted to fill the full ex-
tent of the reference area.
Note: BLSEs may be nested, with child BLSEs stacked within a parent BLSE in the
same manner as BLSEs within a reference area. Except in a few instances noted
below (the
BlockAlign and InlineAlign elements), such nesting of BLSEs does not re-
sult in the nesting of reference areas; a single reference area prevails for all levels of
nested BLSEs.
Within a BLSE, child ILSEs are packed into lines. (Direct content items—those that
are immediate children of a BLSE rather than contained within a child ILSE—are
implicitly treated as ILSEs for packing purposes.) Each line is treated as a synthe-
sized BLSE and is stacked within the parent BLSE. Lines may be intermingled
with other BLSEs within the parent area. This line-building process is analogous
to the stacking of BLSEs within a reference area, except that it proceeds in the
inline-progression rather than the block-progression direction: a line is packed
Document InterchangeCHAPTER 10
826
with ILSEs beginning at the start edge of the containing BLSE and continuing
until the end edge is reached and the line is full. The overflowing ILSE may allow
itself to be broken at linguistically determined or explicitly marked break points
(such as hyphenation points within a word), and the remaining fragment is car-
ried over to the next line.
Note: Certain values of an element’s
Placement attribute remove the element from
the normal stacking or packing process and allow it instead to float to a specified
edge of the enclosing reference area or parent BLSE; see “General Layout Attributes”
on page 846 for further discussion.
Two enclosing rectangles are associated with each BLSE and ILSE (including
direct content items that are treated implicitly as ILSEs):
• The content rectangle is derived from the shape of the enclosed content and
defines the bounds used for the layout of any included child elements.
• The allocation rectangle includes any additional borders or spacing surround-
ing the element, affecting how it is positioned with respect to adjacent elements
and the enclosing content rectangle or reference area.
The definitions of these rectangles are determined by layout attributes associated
with the structure element; see “Content and Allocation Rectangles” on page 859
for further discussion.
10.7.3 Standard Structure Types
Tagged PDF’s standard structure types characterize the role of a content element
within the document and, in conjunction with the standard structure attributes
(described in Section 10.7.4, “Standard Structure Attributes”), how that content is
laid out on the page. As discussed in Section 10.6.2, “Structure Types,” the struc-
ture type of a logical structure element is specified by the
S entry in its structure
element dictionary. To be considered a standard structure type, this value must be
either:
• One of the standard structure type names described below.
• An arbitrary name that is mapped to one of the standard names by the docu-
ment’s role map (see Section 10.6.2, “Structure Types”), possibly through multi-
ple levels of mapping.
Tagged PDFSECTION 10.7
827
Note: Beginning with PDF 1.5, an element name is always mapped to its corre-
sponding name in the role map, if there is one, even if the original name is one of the
standard types. This is done to allow the element, for example, to represent a tag
with the same name as a standard role, even though its use differs from the standard
role.
Ordinarily, structure elements having standard structure types are processed the
same way whether the type is expressed directly or is determined indirectly from
the role map. However, some consumer applications may ascribe additional se-
mantics to nonstandard structure types, even though the role map associates
them with standard ones. For instance, the actual values of the
S entries may be
used when exporting to a tagged representation such as XML, and the corre-
sponding role-mapped values are used when converting to presentation formats
such as HTML or RTF, or for purposes such as reflow or accessibility to users
with disabilities.
Note: Most of the standard element types are designed primarily for laying out text;
the terminology reflects this usage. However, a layout can in fact include any type of
content, such as path or image objects. The content items associated with a structure
element are laid out on the page as if they were blocks of text (for a BLSE) or charac-
ters within a line of text (for an ILSE).
Grouping Elements
Grouping elements are used solely to group other structure elements; they are not
directly associated with content items. Table 10.20 describes the standard struc-
ture types for elements in this category.
For most content extraction formats, the document must be a tree with a single
top-level element; the structure tree root (identified by the
StructTreeRoot entry
in the document catalog) must have only one child in its
K (kids) array. If the PDF
file contains a complete document, the structure type
Document is recommended
for this top-level element in the logical structure hierarchy. If the file contains a
well-formed document fragment, one of the structure types
Part, Art, Sect, or Div
may be used instead.
Document InterchangeCHAPTER 10
828
TABLE 10.20 Standard structure types for grouping elements
STRUCTURE TYPE DESCRIPTION
Document
(Document) A complete document. This is the root element of any
structure tree containing multiple parts or multiple articles.
Part
(Part) A large-scale division of a document. This type of element is
appropriate for grouping articles or sections.
Art
(Article) A relatively self-contained body of text constituting a
single narrative or exposition. Articles should be disjoint; that is,
they should not contain other articles as constituent elements.
Sect
(Section) A container for grouping related content elements. For ex-
ample, a section might contain a heading, several introductory
paragraphs, and two or more other sections nested within it as sub-
sections.
Div
(Division) A generic block-level element or group of elements.
BlockQuote
(Block quotation) A portion of text consisting of one or more para-
graphs attributed to someone other than the author of the sur-
rounding text.
Caption
(Caption) A brief portion of text describing a table or figure.
TOC
(Table of contents) A list made up of table of contents items (struc-
ture type
TOCI; see below) and/or other TOC elements. A table of
contents is thus potentially hierarchical. Ideally, the hierarchy corre-
sponds in structure to the structure hierarchy of the main body of
the document.
Note: Lists of figures and tables, as well as bibliographies, can be
treated as tables of contents for purposes of the standard structure
types.
TOCI
(Table of contents item) An individual member of a table of con-
tents. Its children may include a label (structure type
Lbl; see “List
Elements” on page 831), references to the title and the page number
(structure type
Reference; see “Inline-Level Structure Elements” on
page 834),
NonStruct elements (for wrapping a leader artifact, for
example; see “Grouping Elements” on page 827), and descriptive
text (structure type
P; see “Paragraphlike Elements” on page 830).
Tagged PDFSECTION 10.7
829
Block-Level Structure Elements
A block-level structure element (BLSE) is any region of text or other content that is
laid out in the block-progression direction, such as a paragraph, heading, list
item, or footnote. A structure element is a BLSE if its structure type (after role
mapping, if any) is one of those listed in Table 10.21. All other standard structure
types are treated as ILSEs, with the following exceptions:
• TR (Table row), TH (Table header), TD (Table data), THead (Table head), TBody
(Table body), and TFoot (Table footer), which are used to group elements with-
in a table and are considered neither BLSEs nor ILSEs
• Elements with a Placement attribute (see “General Layout Attributes” on page
846) other than the default value of
Inline
Index
(Index) A sequence of entries containing identifying text accompa-
nied by reference elements (structure type
Reference; see “Inline-
Level Structure Elements” on page 834) that point out occurrences
of the specified text in the main body of a document.
NonStruct
(Nonstructural element) A grouping element having no inherent
structural significance; it serves solely for grouping purposes. This
type of element differs from a division (structure type
Div; see
above) in that it is not interpreted or exported to other document
formats; however, its descendants are to be processed normally.
Private
(Private element) A grouping element containing private content
belonging to the application producing it. The structural signifi-
cance of this type of element is unspecified and is determined en-
tirely by the producer application. Neither the
Private element nor
any of its descendants are to be interpreted or exported to other
document formats.
STRUCTURE TYPE DESCRIPTION
Document InterchangeCHAPTER 10
830
TABLE 10.21 Block-level structure elements
In many cases, a BLSE appears as one compact, contiguous piece of page content;
in other cases, it is discontiguous. Examples of the latter include a BLSE that
extends across a page boundary or is interrupted in the page content order by
another, nested BLSE or a directly included footnote. When necessary, Tagged
PDF consumer applications can recognize such fragmented BLSEs from the logi-
cal structure and use this information to reassemble them and properly lay them
out.
Paragraphlike Elements
Table 10.22 describes structure types for paragraphlike elements that consist of
running text and other content laid out in the form of conventional paragraphs
(as opposed to more specialized layouts such as lists and tables).
TABLE 10.22 Standard structure types for paragraphlike elements
CATEGORY STRUCTURE TYPES
Paragraphlike elements
PH1H4
HH2H5
H3 H6
List elements
L Lbl
LI LBody
Table element
Table
STRUCTURE TYPE DESCRIPTION
H
(Heading) A label for a subdivision of a document’s content. It
should be the first child of the division that it heads.
H1–H6 Headings with specific levels, for use in applications that cannot
hierarchically nest their sections and thus cannot determine the
level of a heading from its level of nesting.
P
(Paragraph) A low-level division of text.
Tagged PDFSECTION 10.7
831
List Elements
The structure types described in Table 10.23 are used for organizing the content
of lists.
TABLE 10.23 Standard structure types for list elements
Table Elements
The structure types described in Table 10.24 are used for organizing the content
of tables.
Note: Strictly speaking, the
Table element is a BLSE; the others in this table are nei-
ther BLSEs or ILSEs.
STRUCTURE TYPE DESCRIPTION
L
(List) A sequence of items of like meaning and importance. Its im-
mediate children should be an optional caption (structure type
Cap-
tion
; see “Grouping Elements” on page 827) followed by one or
more list items (structure type
LI; see below).
LI
(List item) An individual member of a list. Its children may be one
or more labels, list bodies, or both (structure types
Lbl or LBody; see
below).
Lbl
(Label) A name or number that distinguishes a given item from
others in the same list or other group of like items. In a dictionary
list, for example, it contains the term being defined; in a bulleted or
numbered list, it contains the bullet character or the number of the
list item and associated punctuation.
LBody
(List body) The descriptive content of a list item. In a dictionary list,
for example, it contains the definition of the term. It can either con-
tain the content directly or have other BLSEs, perhaps including
nested lists, as children.
Document InterchangeCHAPTER 10
832
TABLE 10.24 Standard structure types for table elements
Note: The association of headers with rows and columns of data is typically deter-
mined heuristically by applications. Such heuristics may fail for complex tables; the
standard attributes for tables shown in Table 10.35 can be used to make the associa-
tion explicit.
STRUCTURE TYPE DESCRIPTION
Table
(Table) A two-dimensional layout of rectangular data cells, possibly
having a complex substructure. It contains either one or more table
rows (structure type
TR; see below) as children; or an optional table
head (structure type
THead; see below) followed by one or more ta-
ble body elements (structure type
TBody; see below) and an optional
table footer (structure type
TFoot; see below). In addition, a table
may have an optional caption (structure type
Caption; see “Group-
ing Elements” on page 827) as its first or last child.
TR
(Table row) A row of headings or data in a table. It may contain
table header cells and table data cells (structure types
TH and TD; see
below).
TH
(Table header cell) A table cell containing header text describing
one or more rows or columns of the table.
TD
(Table data cell) A table cell containing data that is part of the table’s
content.
THead
(Table header row group; PDF 1.5) A group of rows that constitute
the header of a table. If the table is split across multiple pages, these
rows may be redrawn at the top of each table fragment (although
there is only one
THead element).
TBody
(Table body row group; PDF 1.5) A group of rows that constitute the
main body portion of a table. If the table is split across multiple pag-
es, the body area may be broken apart on a row boundary. A table
may have multiple
TBody elements to allow for the drawing of a bor-
der or background for a set of rows.
TFoot
Note: (Table footer row group; PDF 1.5) A group of rows that con-
stitute the footer of a table. If the table is split across multiple pages,
these rows may be redrawn at the bottom of each table fragment
(although there is only one
TFoot element.)
Tagged PDFSECTION 10.7
833
Usage Guidelines for Block-Level Structure
Because different consumer applications use PDF’s logical structure facilities in
different ways, Tagged PDF does not enforce any strict rules regarding the order
and nesting of elements using the standard structure types. Furthermore, each
export format has its own conventions for logical structure. However, adhering to
certain general guidelines helps to achieve the most consistent and predictable in-
terpretation among different Tagged PDF consumers.
As described under “Grouping Elements” on page 827, a Tagged PDF document
can have one or more levels of grouping elements, such as
Document, Part, Art
(Article), Sect (Section), and Div (Division). The descendants of these are BLSEs,
such as
H (Heading), P (Paragraph), and L (List), that hold the actual content.
Their descendants, in turn, are either content items or ILSEs that further describe
the content.
Note: As noted earlier, elements with structure types that would ordinarily be treat-
ed as ILSEs can have a
Placement attribute (see “General Layout Attributes” on
page 846) that causes them to be treated as BLSEs instead. Such elements may be in-
cluded as BLSEs in the same manner as headings and paragraphs.
The block-level structure can follow one of two principal paradigms:
• Strongly structured. The grouping elements nest to as many levels as necessary
to reflect the organization of the material into articles, sections, subsections,
and so on. At each level, the children of the grouping element consist of a head-
ing (
H), one or more paragraphs (P) for content at that level, and perhaps one or
more additional grouping elements for nested subsections.
• Weakly structured. The document is relatively flat, having perhaps only one or
two levels of grouping elements, with all the headings, paragraphs, and other
BLSEs as their immediate children. In this case, the organization of the material
is not reflected in the logical structure; however, it can be expressed by the use
of headings with specific levels (
H1–H6).
The strongly structured paradigm is used by some rich document models based
on XML. The weakly structured paradigm is typical of documents represented in
HTML.
Lists and tables should be organized using the specific structure types described
under “List Elements” on page 831 and “Table Elements” on page 831. Likewise,
Document InterchangeCHAPTER 10
834
tables of contents and indexes should be structured as described for the TOC and
Index structure types under “Grouping Elements” on page 827.
Inline-Level Structure Elements
An inline-level structure element (ILSE) contains a portion of text or other content
having specific styling characteristics or playing a specific role in the document.
Within a paragraph or other block defined by a containing BLSE, consecutive
ILSEs—possibly intermixed with other content items that are direct children of
the parent BLSE—are laid out consecutively in the inline-progression direction
(left to right in Western writing systems). The resulting content may be broken
into multiple lines, which in turn are stacked in the block-progression direction.
It is possible for an ILSE in turn to contain a BLSE, which is treated as a unitary
item of layout in the inline direction. Table 10.25 lists the standard structure types
for ILSEs.
TABLE 10.25 Standard structure types for inline-level structure elements
STRUCTURE TYPE DESCRIPTION
Span
(Span) A generic inline portion of text having no particular inher-
ent characteristics. It can be used, for example, to delimit a range of
text with a given set of styling attributes.
Note: Not all inline style changes need to be identified as a span. Text
color and font changes (including modifiers such as bold, italic, and
small caps) need not be so marked, since these can be derived from the
PDF content (see “Font Characteristics” on page 820). However, it is
necessary to use a span to apply explicit layout attributes such as
LineHeight, BaselineShift, or TextDecorationType (see “Layout Attri-
butes for ILSEs” on page 855).
Note: Marked-content sequences having the tag
Span are also used to
carry certain accessibility properties (
Alt, ActualText, Lang, and E; see
Section 10.8, “Accessibility Support”). Such sequences lack an
MCID
property and are not associated with any structure element. This use
of the
Span marked-content tag is distinct from its use as a structure
type.
Tagged PDFSECTION 10.7
835
Quote
(Quotation) An inline portion of text attributed to someone other
than the author of the surrounding text.
Note: The quoted text is contained inline within a single paragraph.
This differs from the block-level element
BlockQuote (see “Grouping
Elements” on page 827), which consists of one or more complete para-
graphs (or other elements presented as if they were complete para-
graphs).
Note
(Note) An item of explanatory text, such as a footnote or an end-
note, that is referred to from within the body of the document. It
may have a label (structure type
Lbl; see “List Elements” on page
831) as a child. The note may be included as a child of the structure
element in the body text that refers to it, or it may be included else-
where (such as in an endnotes section) and accessed by means of a
reference (structure type
Reference; see below).
Note: Tagged PDF does not prescribe the placement of footnotes in the
page content order. They can be either inline or at the end of the page,
at the discretion of the producer application.
Reference
(Reference) A citation to content elsewhere in the document.
BibEntry
(Bibliography entry) A reference identifying the external source of
some cited content. It may contain a label (structure type
Lbl; see
“List Elements” on page 831) as a child.
Note: Although a bibliography entry is likely to include component
parts identifying the cited content’s author, work, publisher, and so
forth, no standard structure types are defined at this level of detail at
the time of publication.
Code
(Code) A fragment of computer program text.
Link
(Link) An association between a portion of the ILSE’s content and a
corresponding link annotation or annotations (see “Link Annota-
tions” on page 587). Its children are one or more content items or
child ILSEs and one or more object references (see “PDF Objects as
Content Items” on page 796) identifying the associated link annota-
tions. See “Link Elements,” below, for further discussion.
STRUCTURE TYPE DESCRIPTION
Document InterchangeCHAPTER 10
836
Link Elements
Link annotations (like all PDF annotations) are associated with a geometric
region of the page rather than with a particular object in its content stream. Any
connection between the link and the content is based solely on visual appearance
rather than on an explicitly specified association. For this reason, link annota-
tions alone are not useful to users with visual impairments or to applications
needing to determine which content can be activated to invoke a hypertext link.
Tagged PDF link elements (structure type
Link) use PDF’s logical structure facili-
ties to establish the association between content items and link annotations, pro-
viding functionality comparable to HTML hypertext links. The following items
can be children of a link element:
• One or more content items or other ILSEs (except other links)
• Object references (see “PDF Objects as Content Items” on page 796) to one or
more link annotations associated with the content
Annot
(Annotation; PDF 1.5) An association between a portion of the
ILSE’s content and a corresponding PDF annotation (see Section
8.4, “Annotations”).
Annot is used for all PDF annotations except
link annotations (see the
Link element, above) and widget annota-
tions (see the
Form element in Table 10.27 on page 841). See “Anno-
tation Elements” on page 839 for further discussion.
Ruby
(Ruby; PDF 1.5) A side-note (annotation) written in a smaller text
size and placed adjacent to the base text to which it refers. It is used
in Japanese and Chinese to describe the pronunciation of unusual
words or to describe such items as abbreviations and logos. A
Ruby
element may also contain the RB, RT, and RP elements. See “Ruby
and Warichu Elements” on page 839 for more details.
Warichu
(Warichu; PDF 1.5) A comment or annotation in a smaller text size
and formatted onto two smaller lines within the height of the con-
taining text line and placed following (inline) the base text to which
it refers. It is used in Japanese for descriptive comments and for
ruby annotation text that is too long to be aesthetically formatted as
a ruby. A Warichu element may also contain the
WT and WP ele-
ments. See “Ruby and Warichu Elements” on page 839 for more de-
tails.
STRUCTURE TYPE DESCRIPTION
Tagged PDFSECTION 10.7
837
A link element may contain several link annotations if the geometry of the
content requires it. For instance, if a span of text wraps from the end of one line to
the beginning of another, separate link annotations may be needed to cover the
two portions of text. All of the child link annotations must have the same target
and action. To maintain a geometric association between the content and the an-
notation that is consistent with the logical association, all of the link element’s
content must be covered by the union of its child link annotations.
As an example, consider the following fragment of HTML code, which produces
a line of text containing a hypertext link:
<html>
<body>
<p>
Here is some text <a href=http://www.adobe.com>with a link</a> inside.
</body>
</html>
Example 10.17 shows an equivalent fragment of PDF using a link element, whose
text it displays in blue and underlined. Example 10.18 shows an excerpt from the
associated logical structure hierarchy.
Example 10.17
/P << /MCID 0 >> % Marked-content sequence 0 (paragraph)
BDC % Begin marked-content sequence
BT % Begin text object
/T1_0 1 Tf % Set text font and size
14 0 0 14 10.000 753.976 Tm % Set text matrix
0.0 0.0 0.0 rg % Set nonstroking color to black
(Here is some text ) Tj % Show text preceding link
ET % End text object
EMC % End marked-content sequence
/Link << /MCID 1 >> % Marked-content sequence 1 (link)
BDC % Begin marked-content sequence
0.7 w % Set line width
[ ] 0 d % Solid dash pattern
111.094 751.8587 m % Move to beginning of underline
174.486 751.8587 l % Draw underline
0.0 0.0 1.0 RG % Set stroking color to blue
S % Stroke underline
Document InterchangeCHAPTER 10
838
BT % Begin text object
14 0 0 14 111.094 753.976 Tm % Set text matrix
0.0 0.0 1.0 rg % Set nonstroking color to blue
(with a link) Tj % Show text of link
ET % End text object
EMC % End marked-content sequence
/P << /MCID 2 >> % Marked-content sequence 2 (paragraph)
BDC % Begin marked-content sequence
BT % Begin text object
14 0 0 14 174.486 753.976 Tm % Set text matrix
0.0 0.0 0.0 rg % Set nonstroking color to black
( inside.) Tj % Show text following link
ET % End text object
EMC % End marked-content sequence
Example 10.18
501 0 obj % Structure element for paragraph
<< /Type /StructElem
/S /P
. . .
/K [ 0 % Three children: marked-content sequence 0
502 0 R % Link
2 % Marked-content sequence 2
]
>>
endobj
502 0 obj % Structure element for link
<< /Type /StructElem
/S /Link
. . .
/K [ 1 % Two children: marked-content sequence 1
503 0 R % Object reference to link annotation
]
>>
endobj
503 0 obj % Object reference to link annotation
<< /Type /OBJR
/Obj 600 0 R % Link annotation (not shown)
>>
endobj
Tagged PDFSECTION 10.7
839
Annotation Elements
Tagged PDF annotation elements (structure type Annot; PDF 1.5) use PDF’s logi-
cal structure facilities to establish the association between content items and PDF
annotations. Annotation elements are used for all types of annotations other than
links (see “Link Elements” on page 836) and forms (see Table 10.27 on page 841).
The following items can be children of an annotation element:
• Object references (see “PDF Objects as Content Items” on page 796) to one or
more annotation dictionaries
• Optionally, one or more content items (such as marked-content sequences) or
other ILSEs (except other annotations) associated with the annotations
If an
Annot element has no children other than object references, its rendering is
defined by the appearance of the referenced annotations, and its text content is
treated as if it were a
Span element. It may have an optional BBox attribute; if sup-
plied, this attribute overrides the rectangle specified by the annotation dictio-
nary’s
Rect entry.
If the
Annot element has children that are content items, those children represent
the displayed form of the annotation, and the appearance of the associated anno-
tation may also be applied (for example, with a
Highlight annotation).
There can be multiple children that are object references to different annotations,
subject to the constraint that the annotations must be the same except for their
Rect entry. This is much the same as is done for the Link element; it allows an an-
notation to be associated with discontiguous pieces of content, such as line-
wrapped text.
Ruby and Warichu Elements
Ruby text is a side note, written in a smaller text size and placed adjacent to the
base text to which it refers. It is used in Japanese and Chinese to describe the pro-
nunciation of unusual words or to describe such items as abbreviations and logos
.
Warichu text is a comment or annotation, written in a smaller text size and for-
matted onto two smaller lines within the height of the containing text line and
placed following (inline) the base text to which it refers. It is used in Japanese for
Document InterchangeCHAPTER 10
840
descriptive comments and for ruby annotation text that is too long to be aestheti-
cally formatted as a ruby.
TABLE 10.26 Standard structure types for Ruby and Warichu elements (PDF 1.5)
STRUCTURE TYPE DESCRIPTION
Ruby
(Ruby) The wrapper around the entire ruby assembly. It contains
one
RB element followed by either an RT element or a three-element
group consisting of
RP, RT, and RP. Ruby elements and their content
elements may not break across multiple lines.
RB
(Ruby base text) The full-size text to which the ruby annotation is
applied.
RB can contain text, other inline elements, or a mixture of
both. It may have the
RubyAlign attribute.
RT
(Ruby annotation text) The smaller-size text that is placed adjacent
to the ruby base text. It can contain text, other inline elements, or a
mixture of both. It may have the
RubyAlign and RubyPosition at-
tributes.
RP
(Ruby punctuation) Punctuation surrounding the ruby annotation
text. It us used only when a ruby annotation cannot be properly for-
matted in a ruby style and instead is formatted as a normal com-
ment, or when it is formatted as a warichu. It contains text (usually
a single open or close parenthesis or similar bracketing character).
Warichu
(Warichu) The wrapper around the entire warichu assembly. It may
contain a three-element group consisting of
WP, WT, and WP. Wari-
chu elements (and their content elements) may wrap across multi-
ple lines, according to the warichu breaking rules described in the
Japanese Industrial Standard (JIS) X 4051-1995.
WT
(Warichu text) The smaller-size text of a warichu comment that is
formatted into two lines and placed between surrounding
WP ele-
ments.
WP
(Warichu punctuation) The punctuation that surrounds the WT
text. It contains text (usually a single open or close parenthesis or
similar bracketing character). According to JIS X 4051-1995, the pa-
rentheses surrounding a warichu may be converted to a space
(nominally 1/4 EM in width) at the discretion of the formatter.
Tagged PDFSECTION 10.7
841
Illustration Elements
Tagged PDF defines an illustration element as any structure element whose struc-
ture type (after role mapping, if any) is one of those listed in Table 10.27. The il-
lustration’s content must consist of one or more complete graphics objects. It may
not appear between the
BT and ET operators delimiting a text object (see Section
5.3, “Text Objects”). It may include clipping only in the form of a contained
marked clipping sequence, as defined in Section 10.5.2, “Marked Content and
Clipping.” In Tagged PDF, all such marked clipping sequences must carry the
marked-content tag
Clip.
TABLE 10.27 Standard structure types for illustration elements
An illustration may have logical substructure, including other illustrations. For
purposes of reflow, however, it is moved (and perhaps resized) as a unit, without
examining its internal contents. To be useful for reflow, it must have a
BBox
attribute. It may also have Placement, Width, Height, and BaselineShift attributes
(see “Layout Attributes” on page 845).
Often an illustration is logically part of, or at least attached to, a paragraph or oth-
er element of a document. Any such containment or attachment is represented
through the use of the
Figure structure type. The Figure element indicates the
STRUCTURE TYPE DESCRIPTION
Figure
(Figure) An item of graphical content. Its placement may be speci-
fied with the
Placement layout attribute (see “General Layout Attri-
butes” on page 846).
Formula
(Formula) A mathematical formula.
Note: This structure type is useful only for identifying an entire con-
tent element as a formula. No standard structure types are defined for
identifying individual components within the formula. From a for-
matting standpoint, the formula is treated similarly to a figure (struc-
ture type
Figure; see above).
Form
(Form) A widget annotation representing an interactive form field
(see Section 8.6, “Interactive Forms”). Its only child is an object ref-
erence (see “PDF Objects as Content Items” on page 796) identify-
ing the widget annotation. The annotation’s appearance stream (see
Section 8.4.4, “Appearance Streams”) defines the rendering of the
form element.
Document InterchangeCHAPTER 10
842
point of attachment, and its Placement attribute describes the nature of the at-
tachment. An illustration element without a
Placement attribute is treated as an
ILSE and laid out inline.
Note: For accessibility to users with disabilities and other text extraction purposes,
an illustration element should always have an
Alt entry or an ActualText entry (or
both) in its structure element dictionary (see Sections 10.8.2, “Alternate Descrip-
tions,” and 10.8.3, “Replacement Text”).
Alt is a description of the illustration,
whereas
ActualText gives the exact text equivalent of a graphical illustration that
has the appearance of text.
10.7.4 Standard Structure Attributes
In addition to the standard structure types, Tagged PDF defines standard layout
and styling attributes for structure elements of those types. These attributes en-
able predictable formatting to be applied during operations such as reflow and
export of PDF content to other document formats.
As discussed in Section 10.6.4, “Structure Attributes,” attributes are defined in
attribute objects, which are dictionaries or streams attached to a structure element
in either of two ways:
• The A entry in the structure element dictionary identifies an attribute object or
an array of such objects.
• The C entry in the structure element dictionary gives the name of an attribute
class or an array of such names. The class name is in turn looked up in the class
map, a dictionary identified by the
ClassMap entry in the structure tree root,
yielding an attribute object or array of objects corresponding to the class.
In addition to the standard structure attributes described below, there are several
other optional entries—
Lang, Alt, ActualText, and E—that are described in Sec-
tion 10.8, “Accessibility Support,” but are useful to other PDF consumers as well.
They appear in the following places in a PDF file (rather than in attribute dictio-
naries):
• As entries in the structure element dictionary (see Table 10.10 on page 787)
• As entries in property lists attached to marked-content sequences with a Span
tag (see Section 10.5, “Marked Content”)
Tagged PDFSECTION 10.7
843
Example 10.15 illustrates the use of standard structure attributes.
Standard Attribute Owners
Each attribute object has an owner, specified by the object’s O entry, which deter-
mines the interpretation of the attributes defined in the object’s dictionary. Multi-
ple owners may define like-named attributes with different value types or
interpretations. Tagged PDF defines a set of standard attribute owners, shown in
Table 10.28.
TABLE 10.28 Standard attribute owners
An attribute object owned by a specific export format, such as XML-1.00, is
applied only when exporting PDF content to that format. Such format-specific
attributes override any corresponding attributes owned by
Layout, List, or Table.
There may also be additional format-specific attributes; the set of possible at-
tributes is open-ended and is not explicitly specified or limited by Tagged PDF.
OWNER DESCRIPTION
Layout
Attributes governing the layout of content
List
Attributes governing the numbering of lists
Table
Attributes governing the organization of cells in tables
XML-1.00
Additional attributes governing translation to XML, version 1.00
HTML-3.20
Additional attributes governing translation to HTML, version 3.20
HTML-4.01
Additional attributes governing translation to HTML, version 4.01
OEB-1.00
Additional attributes governing translation to OEB, version 1.0
RTF-1.05
Additional attributes governing translation to Microsoft Rich Text
Format, version 1.05
CSS-1.00
Additional attributes governing translation to a format using CSS,
version 1.00
CSS-2.00
Additional attributes governing translation to a format using CSS,
version 2.00
Document InterchangeCHAPTER 10
844
Attribute Values and Inheritance
Some attributes are defined as inheritable. Inheritable attributes propagate down
the structure tree; that is, an attribute that is specified for an element applies to all
the descendants of the element in the structure tree unless a descendent element
specifies an explicit value for the attribute.
Note: The description of each of the standard attributes in this section specifies
whether their values are inheritable.
It is permissible to specify an inheritable attribute on an element for the purpose
of propagating its value to child elements, even if the attribute is not meaningful
for the parent element. Non-inheritable attributes may be specified only for ele-
ments on which they would be meaningful.
The following list shows the priority for setting attribute values. A processing ap-
plication sets an attribute’s value to the first item in the list that applies:
1. The value of the attribute specified in the element’s
A entry, owned by one of
the export formats (such as
XML, HTML-3.20, HTML-4.01, OEB-1.0, CSS-1.00,
CSS-2.0, and RTF), if present, and if outputting to that format
2. The value of the attribute specified in the element’s
A entry, owned by Layout
or Table or List, if present
3. The value of the attribute specified in a class map associated with the element’s
C entry, if there is one
4. The resolved value of the parent structure element, if the attribute is inherita-
ble
5. The default value for the attribute, if there is one
Note: The attributes
Lang, Alt, ActualText, and E do not appear in attribute dictio-
naries. The rules governing their application are discussed in Section 10.8, “Accessi-
bility Support.”
There is no semantic distinction between attributes that are specified explicitly
and ones that are inherited. Logically, the structure tree has attributes fully bound
to each element, even though some may be inherited from an ancestor element.
This is consistent with the behavior of properties (such as font characteristics)
that are not specified by structure attributes but are derived from the content.
Tagged PDFSECTION 10.7
845
Layout Attributes
Layout attributes specify parameters of the layout process used to produce the
appearance described by a document’s PDF content. Attributes in this category
are defined in attribute objects whose
O (owner) entry has the value Layout (or is
one of the format-specific owner names listed in Table 10.28 on page 843). The
intent is that these parameters can be used to reflow the content or export it to
some other document format with at least basic styling preserved.
Table 10.32 summarizes the standard layout attributes and the structure elements
to which they apply. The following sections describe the meaning and usage of
these attributes.
Note: An asterisk (*) after the attribute name indicates that the attribute is inherit-
able. As described in “Attribute Values and Inheritance” on page 844, an inheritable
attribute may be specified for any element to propagate it to descendants, regardless
of whether it is meaningful for that element.
TABLE 10.29 Standard layout attributes
STRUCTURE ELEMENTS ATTRIBUTES
Any structure element
Placement
WritingMode*
BackgroundColor
BorderColor*
BorderStyle
BorderThickness*
Color*
Padding
Any BLSE
ILSEs with
Placement other than
Inline
SpaceBefore
SpaceAfter
StartIndent*
EndIndent*
BLSEs containing text
TextIndent*
TextAlign*
Illustration elements (Figure,
Formula, Form)
Table
BBox
Width
Height
Document InterchangeCHAPTER 10
846
General Layout Attributes
The layout attributes described in Table 10.30 can apply to structure elements of
any of the standard types at the block level (BLSEs) or the inline level (ILSEs).
TABLE 10.30 Standard layout attributes common to all standard structure types
TH
(Table header)
TD (Table data)
Width
Height
BlockAlign*
InlineAlign*
TBorderStyle*
TPadding*
Any ILSE
BLSEs containing ILSEs or
containing direct or nested content
items
LineHeight*
BaselineShift
TextDecorationType
TextDecorationColor*
TextDecorationThickness*
Grouping elements Art, Sect, and
Div
ColumnCount
ColumnWidths
ColumnGap
Vertical text
GlyphOrientationVertical*
Ruby text
RubyAlign*
RubyPosition*
KEY TYPE VALUE
Placement
name (Optional; not inheritable) The positioning of the element with respect to the
enclosing reference area and other content:
Block Stacked in the block-progression direction within an
enclosing reference area or parent BLSE.
Inline Packed in the inline-progression direction within an
enclosing BLSE.
STRUCTURE ELEMENTS ATTRIBUTES
Tagged PDFSECTION 10.7
847
Before Placed so that the before edge of the element’s allocation
rectangle (see “Content and Allocation Rectangles” on page
859) coincides with that of the nearest enclosing reference
area. The element may float, if necessary, to achieve the
specified placement (see note below). The element is treated
as a block occupying the full extent of the enclosing reference
area in the inline direction. Other content is stacked so as to
begin at the after edge of the element’s allocation rectangle.
Start Placed so that the start edge of the element’s allocation
rectangle (see “Content and Allocation Rectangles” on page
859) coincides with that of the nearest enclosing reference
area. The element may float, if necessary, to achieve the
specified placement (see note below). Other content that
would intrude into the element’s allocation rectangle is laid
out as a runaround.
End Placed so that the end edge of the element’s allocation
rectangle (see “Content and Allocation Rectangles” on page
859) coincides with that of the nearest enclosing reference
area. The element may float, if necessary, to achieve the
specified placement (see note below). Other content that
would intrude into the element’s allocation rectangle is laid
out as a runaround.
When applied to an ILSE, any value except
Inline causes the element to be
treated as a BLSE instead. Default value:
Inline.
Note: Elements with
Placement values of Before, Start, or End are removed from
the normal stacking or packing process and allowed to float to the specified edge
of the enclosing reference area or parent BLSE. Multiple such floating elements
may be positioned adjacent to one another against the specified edge of the ref-
erence area or placed serially against the edge, in the order encountered. Com-
plex cases such as floating elements that interfere with each other or do not fit
on the same page may be handled differently by different layout applications.
Tagged PDF merely identifies the elements as floating and indicates their de-
sired placement.
KEY TYPE VALUE
Document InterchangeCHAPTER 10
848
WritingMode
name (Optional; inheritable) The directions of layout progression for packing of
ILSEs (inline progression) and stacking of BLSEs (block progression):
LrTb Inline progression from left to right; block progression from
top to bottom. This is the typical writing mode for Western
writing systems.
RlTb Inline progression from right to left; block progression from
top to bottom. This is the typical writing mode for Arabic and
Hebrew writing systems.
TbRl Inline progression from top to bottom; block progression
from right to left. This is the typical writing mode for Chinese
and Japanese writing systems.
The specified layout directions apply to the given structure element and all of
its descendants to any level of nesting. Default value:
LrTb.
For elements that produce multiple columns, the writing mode defines the
direction of column progression within the reference area: the inline direc-
tion determines the stacking direction for columns and the default flow order
of text from column to column. For tables, the writing mode controls the lay-
out of rows and columns: table rows (structure type
TR) are stacked in the
block direction, cells within a row (structure type
TD) in the inline direction.
Note: The inline-progression direction specified by the writing mode is subject
to local override within the text being laid out, as described in Unicode Stan-
dard Annex #9, The Bidirectional Algorithm, available from the Unicode Con-
sortium (see the Bibliography).
BackgroundColor
array (Optional; not inheritable; PDF 1.5) The color to be used to fill the back-
ground of a table cell or any element’s content rectangle (possibly adjusted by
the
Padding attribute). The value is an array of three numbers in the range 0.0
to 1.0, representing the red, green, and blue values, respectively, of an RGB
color space. If this attribute is not specified, the element is treated as if it were
transparent.
KEY TYPE VALUE
Tagged PDFSECTION 10.7
849
BorderColor
array (Optional; inheritable; PDF 1.5) The color of the border drawn on the edges of
a table cell or any element’s content rectangle (possibly adjusted by the
Padding attribute). The value of each edge is an array of three numbers in the
range 0.0 to 1.0, representing the red, green, and blue values, respectively, of
an RGB color space. There are two forms:
• A single array of three numbers representing the RGB values to apply to all
four edges.
• An array of four arrays, each specifying the RGB values for one edge of the
border, in the order of the before, after, start, and end edges. A value of
null
for any of the edges means that it is not to be drawn.
If this attribute is not specified, the border color for this element is the cur-
rent text fill color in effect at the start of its associated content.
BorderStyle
array or
name
(Optional; not inheritable; PDF 1.5) The style of an element’s border. Specifies
the stroke pattern of each edge of a table cell or any element’s content rectan-
gle (possibly adjusted by the
Padding attribute). There are two forms:
• A name from the list below representing the border style to apply to all
four edges.
• An array of four entries, each entry specifying the style for one edge of the
border in the order of the before, after, start, and end edges. A value of
null
for any of the edges means that it is not to be drawn.
None No border. Forces the computed value of BorderThickness to
be 0.
Hidden Same as None, except in terms of border conflict resolution
for table elements.
Dotted The border is a series of dots.
Dashed The border is a series of short line segments.
Solid The border is a single line segment.
Double The border is two solid lines. The sum of the two lines and
the space between them equals the value of
BorderThickness.
Groove The border looks as though it were carved into the canvas.
Ridge The border looks as though it were coming out of the canvas
(the opposite of
Groove).
KEY TYPE VALUE
Document InterchangeCHAPTER 10
850
Inset The border makes the entire box look as though it were
embedded in the canvas.
Outset The border makes the entire box look as though it were
coming out of the canvas (the opposite of
Inset).
Default value:
None
Note: All borders are drawn on top of the box’s background. The color of borders
drawn for values of
Groove, Ridge, Inset, and Outset depends on the structure el-
ement’s
BorderColor attribute and the color of the background over which the
border is being drawn.
Note: Conforming HTML applications may interpret Dotted, Dashed, Double,
Groove, Ridge, Inset, and Outset to be Solid.
BorderThickness
number or
array
(Optional; inheritable; PDF 1.5) The thickness of the border drawn on the
edges of a table cell or any element’s content rectangle (possibly adjusted by
the
Padding attribute). The value of each edge is a positive number in default
user space units representing the border’s thickness (a value of 0 indicates
that the border is not drawn). There are two forms:
• A number representing the border thickness for all four edges.
• An array of four entries, each entry specifying the thickness for one edge of
the border, in the order of the before, after, start, and end edges. A value of
null for any of the edges means that it is not to be drawn.
Padding
number or
array
(Optional; not inheritable; PDF 1.5) Specifies an offset to account for the sep-
aration between the element’s content rectangle and the surrounding border
(see “Content and Allocation Rectangles” on page 859). A positive value en-
larges the background area; a negative value trims it, possibly allowing the
border to overlap the element’s text or graphic.
The value is either a single number representing the width of the padding, in
default user space units, that applies to all four sides or a 4-entry array repre-
senting the padding width for the before, after, start, and end edge, respec-
tively, of the content rectangle. Default value: 0.
Color
array (Optional; inheritable; PDF 1.5) The color to be used for drawing text and the
default value for the color of table borders and text decorations. The value is
an array of three numbers in the range 0.0 to 1.0, representing the red, green,
and blue values, respectively, of an RGB color space. If this attribute is not
specified, the border color for this element is the current text fill color in ef-
fect at the start of its associated content.
KEY TYPE VALUE
Tagged PDFSECTION 10.7
851
Layout Attributes for BLSEs
Table 10.31 describes layout attributes that apply only to block-level structure ele-
ments (BLSEs).
Note: Inline-level structure elements (ILSEs) with a
Placement attribute other than
the default value of
Inline are treated as BLSEs and hence are also subject to the
attributes described here.
TABLE 10.31 Additional standard layout attributes specific to block-level structure
elements
KEY TYPE VALUE
SpaceBefore
number (Optional; not inheritable) The amount of extra space preceding the before
edge of the BLSE, measured in default user space units in the block-progres-
sion direction. This value is added to any adjustments induced by the
LineHeight attributes of ILSEs within the first line of the BLSE (see “Layout
Attributes for ILSEs” on page 855). If the preceding BLSE has a
SpaceAfter at-
tribute, the greater of the two attribute values is used. Default value: 0.
Note: This attribute is disregarded for the first BLSE placed in a given reference
area.
SpaceAfter
number (Optional; not inheritable) The amount of extra space following the after edge
of the BLSE, measured in default user space units in the block-progression di-
rection. This value is added to any adjustments induced by the
LineHeight at-
tributes of ILSEs within the last line of the BLSE (see “Layout Attributes for
ILSEs” on page 855). If the following BLSE has a
SpaceBefore attribute, the
greater of the two attribute values is used. Default value: 0.
Note: This attribute is disregarded for the last BLSE placed in a given reference
area.
Document InterchangeCHAPTER 10
852
StartIndent
number (Optional; inheritable) The distance from the start edge of the reference area
to that of the BLSE, measured in default user space units in the inline-pro-
gression direction. This attribute applies only to structure elements with a
Placement attribute of Block or Start (see “General Layout Attributes” on page
846). The attribute is disregarded for elements with other
Placement values.
Default value: 0.
Note: A negative value for this attribute places the start edge of the BLSE out-
side that of the reference area. The results are implementation-dependent and
may not be supported by all Tagged PDF consumer applications or export
formats.
Note: If a structure element with a
StartIndent attribute is placed adjacent to a
floating element with a
Placement attribute of Start, the actual value used for
the element’s starting indent is its own
StartIndent attribute or the inline extent
of the adjacent floating element, whichever is greater. This value may be further
adjusted by the element’s
TextIndent attribute, if any.
EndIndent
number (Optional; inheritable) The distance from the end edge of the BLSE to that of
the reference area, measured in default user space units in the inline-progres-
sion direction. This attribute applies only to structure elements with a
Placement attribute of Block or End (see “General Layout Attributes” on page
846). The attribute is disregarded for elements with other
Placement values.
Default value: 0.
Note: A negative value for this attribute places the end edge of the BLSE outside
that of the reference area. The results are implementation-dependent and may
not be supported by all Tagged PDF consumer applications or export formats.
Note: If a structure element with an
EndIndent attribute is placed adjacent to a
floating element with a
Placement attribute of End, the actual value used for the
element’s ending indent is its own
EndIndent attribute or the inline extent of the
adjacent floating element, whichever is greater.
TextIndent number (Optional; inheritable; applies only to some BLSEs, as described below) The ad-
ditional distance, measured in default user space units in the inline-progres-
sion direction, from the start edge of the BLSE, as specified by
StartIndent
(above), to that of the first line of text. A negative value indicates a hanging
indent. Default value: 0.
This attribute applies only to paragraphlike BLSEs and those of structure
types
Lbl (Label), LBody (List body), TH (Table header), and TD (Table data),
provided that they contain content other than nested BLSEs.
KEY TYPE VALUE
Tagged PDFSECTION 10.7
853
TextAlign
name (Optional; inheritable; applies only to BLSEs containing text) The alignment, in
the inline-progression direction, of text and other content within lines of the
BLSE:
Start Aligned with the start edge.
Center Centered between the start and end edges.
End Aligned with the end edge.
Justify Aligned with both the start and end edges, with internal
spacing within each line expanded, if necessary, to achieve
such alignment. The last (or only) line is aligned with the
start edge only.
Default value:
Start.
BBox
rectangle (Optional for Annot; required for any figure or table appearing in its entirety on
a single page; not inheritable). An array of four numbers in default user space
units giving the coordinates of the left, bottom, right, and top edges, respec-
tively, of the element’s bounding box (the rectangle that completely encloses
its visible content). This attribute applies to any element that lies on a single
page and occupies a single rectangle.
Width
number
or name
(Optional; not inheritable; illustrations, tables, table headers, and table cells
only; strongly recommended for table cells) The width of the element’s content
rectangle (see “Content and Allocation Rectangles” on page 859), measured
in default user space units in the inline-progression direction. This attribute
applies only to elements of structure type
Figure, Formula, Form, Table, TH
(Table header), or TD (Table data).
The name
Auto in place of a numeric value indicates that no specific width
constraint is to be imposed; the element’s width is determined by the intrinsic
width of its content. Default value:
Auto.
Height
number
or name
(Optional; not inheritable; illustrations, tables, table headers, and table cells
only) The height of the element’s content rectangle (see “Content and Alloca-
tion Rectangles” on page 859), measured in default user space units in the
block-progression direction. This attribute applies only to elements of struc-
ture type
Figure, Formula, Form, Table, TH (Table header), or TD (Table data).
The name
Auto in place of a numeric value indicates that no specific height
constraint is to be imposed; the element’s height is determined by the intrin-
sic height of its content. Default value:
Auto.
KEY TYPE VALUE
Document InterchangeCHAPTER 10
854
BlockAlign
name (Optional; inheritable; table cells only) The alignment, in the block-progres-
sion direction, of content within the table cell:
Before Before edge of the first child’s allocation rectangle aligned
with that of the table cell’s content rectangle.
Middle Children centered within the table cell. The distance between
the before edge of the first child’s allocation rectangle and
that of the table cell’s content rectangle is the same as the
distance between the after edge of the last child’s allocation
rectangle and that of the table cell’s content rectangle.
After After edge of the last child’s allocation rectangle aligned with
that of the table cell’s content rectangle.
Justify Children aligned with both the before and after edges of the
table cell’s content rectangle. The first child is placed as
described above for
Before and the last child as described for
After, with equal spacing between the children. If there is only
one child, it is aligned with the before edge only, as for
Before.
This attribute applies only to elements of structure type
TH (Table header) or
TD (Table data) and controls the placement of all BLSEs that are children of
the given element. The table cell’s content rectangle (see “Content and Allo-
cation Rectangles” on page 859) becomes the reference area for all of its
descendants. Default value:
Before.
InlineAlign
name (Optional; inheritable; table cells only) The alignment, in the inline-progres-
sion direction, of content within the table cell:
Start Start edge of each child’s allocation rectangle aligned with
that of the table cell’s content rectangle.
Center Each child centered within the table cell. The distance
between the start edges of the child’s allocation rectangle and
the table cell’s content rectangle is the same as the distance
between their end edges.
End End edge of each child’s allocation rectangle aligned with that
of the table cell’s content rectangle.
This attribute applies only to elements of structure type
TH (Table header) or
TD (Table data) and controls the placement of all BLSEs that are children of
the given element. The table cell’s content rectangle (see “Content and Allo-
cation Rectangles” on page 859) becomes the reference area for all of its
descendants. Default value:
Start.
KEY TYPE VALUE
Tagged PDFSECTION 10.7
855
Layout Attributes for ILSEs
The attributes described in Table 10.32 apply to inline-level structure elements
(ILSEs). They may also be specified for a block-level element (BLSE) and apply to
any content items that are its immediate children.
TABLE 10.32 Standard layout attributes specific to inline-level structure elements
TBorderStyle
name or
array
(Optional; inheritable; PDF 1.5) The style of the border drawn on each edge of
a table cell. Possible values are the same as those specified for
BorderStyle
(see Table 10.30). If both TBorderStyle and BorderStyle apply to a given table
cell,
BorderStyle supersedes TBorderStyle. Default value: None.
TPadding
integer or
array
(Optional; inheritable; PDF 1.5) Specifies an offset to account for the separa-
tion between the table cell’s content rectangle and the surrounding border
(see “Content and Allocation Rectangles” on page 859). If both
TPadding and
Padding apply to a given table cell, Padding supersedes TPadding. A positive
value enlarges the background area; a negative value trims it, possibly allow-
ing the border to overlap the element’s text or graphic. The value is either a
single number representing the width of the padding, in default user space
units, that applies to all four edges of the table cell or a 4-entry array repre-
senting the padding width for the before edge, after edge, start edge, and end
edge, respectively, of the content rectangle. Default value: 0.
KEY TYPE VALUE
BaselineShift
number (Optional; not inheritable) The distance, in default user space units, by
which the element’s baseline is shifted relative to that of its parent ele-
ment. The shift direction is the opposite of the block-progression direc-
tion specified by the prevailing
WritingMode attribute (see “General
Layout Attributes” on page 846). Thus, positive values shift the baseline
toward the before edge and negative values toward the after edge of the
reference area (upward and downward, respectively, in Western writing
systems). Default value: 0.
The shifted element might be a superscript, a subscript, or an inline
graphic. The shift applies to the element, its content, and all of its descen-
dants. Any further baseline shift applied to a child of this element is mea-
sured relative to the shifted baseline of this (parent) element.
KEY TYPE VALUE
Document InterchangeCHAPTER 10
856
LineHeight
number
or name
(Optional; inheritable) The element’s preferred height, measured in de-
fault user space units in the block-progression direction. The height of a
line is determined by the largest
LineHeight value for any complete or
partial ILSE that it contains.
The name
Normal or Auto in place of a numeric value indicates that no
specific height constraint is to be imposed. The element’s height is set to a
reasonable value based on the content’s font size:
Normal Adjust the line height to include any nonzero value
specified for
BaselineShift (see below).
Auto Do not adjust for the value of BaselineShift.
Default value:
Normal.
This attribute applies to all ILSEs (including implicit ones) that are chil-
dren of this element or of its nested ILSEs, if any. It does not apply to
nested BLSEs.
Note: When translating to a specific export format, the values
Normal and
Auto, if specified, are used directly if they are available in the target format.
The meaning of the term “reasonable value,” used above, is left to the con-
sumer application to determine. It can be assumed to be approximately 1.2
times the font size, but this value may vary depending on the export format.
In the absence of a numeric value for
LineHeight or an explicit value for the
font size, a reasonable method of calculating the line height from the infor-
mation in a Tagged PDF file is to find the difference between the associated
font’s
Ascent and Descent values (see Section 5.7, “Font Descriptors”), map
it from glyph space to default user space (see Section 5.3.3, “Text Space De-
tails”), and use the maximum resulting value for any character in the line.
TextDecorationColor
array (Optional; inheritable; PDF 1.5) The color to be used for drawing text
decorations. The value is an array of three numbers in the range 0.0 to
1.0, representing the red, green, and blue values, respectively, of an RGB
color space. If this attribute is not specified, the border color for this ele-
ment is the current fill color in effect at the start of its associated content.
TextDecorationThickness
number (Optional; inheritable; PDF 1.5) The thickness of each line drawn as part
of the text decoration. The value is a non-negative number in default user
space units representing the thickness (0 is interpreted as the thinnest
possible line). If this attribute is not specified, it is derived from the cur-
rent stroke thickness in effect at the start of the element’s associated con-
tent, transformed into default user space units.
KEY TYPE VALUE
Tagged PDFSECTION 10.7
857
TextDecorationType
name (Optional; not inheritable) The text decoration, if any, to be applied to the
element’s text.
None No text decoration
Underline A line below the text
Overline A line above the text
LineThrough A line through the middle of the text
Default value:
None.
This attribute applies to all text content items that are children of this ele-
ment or of its nested ILSEs, if any. The attribute does not apply to nested
BLSEs or to content items other than text.
Note: The color, position, and thickness of the decoration should be uniform
across all children, regardless of changes in color, font size, or other varia-
tions in the content’s text characteristics.
RubyAlign
name (Optional; inheritable; PDF 1.5) The justification of the lines within a
ruby assembly:
Start The content is to be aligned on the start edge in the
inline-progression direction.
Center The content is to be centered in the inline-progression
direction.
End The content is to be aligned on the end edge in the
inline-progression direction.
Justify The content is to be expanded to fill the available width
in the inline-progression direction.
Distribute The content is to be expanded to fill the available width
in the inline-progression direction. However, some space
is also inserted at the start edge and end edge of the text.
Normally, the spacing is distributed using a 1:2:1
(start:infix:end) ratio. It is changed to a 0:1:1 ratio if the
ruby appears at the start of a text line or to a 1:1:0 ratio if
the ruby appears at the end of the text line.
KEY TYPE VALUE
Document InterchangeCHAPTER 10
858
Default value: Distribute.
This attribute may be specified on the
RB and RT elements. When a ruby
is formatted, the attribute is applied to the shorter line of these two ele-
ments. (If the
RT element has a shorter width than the RB element, the RT
element is aligned as specified in its RubyAlign attribute.)
RubyPosition
name (Optional; inheritable; PDF 1.5) The placement of the RT structure ele-
ment relative to the
RB element in a ruby assembly:
Before The RT content is to be aligned along the before edge of
the element.
After The RT content is to be aligned along the after edge of the
element.
Warichu The RT and associated RP elements are to be formatted as
a warichu, following the
RB element.
Inline The RT and associated RP elements are to be formatted as
a parenthesis comment, following the
RB element.
Default value:
Before.
GlyphOrientationVertical
name (Optional; inheritable; PDF 1.5) Specifies the orientation of glyphs when
the inline-progression direction is top to bottom or bottom to top.
This attribute may take one of the following values:
angle A number representing the clockwise rotation in degrees
of the top of the glyphs relative to the top of the reference
area. Must be a multiple of 90 degrees between -180 and
+360.
Auto Specifies a default orientation for text, depending on
whether it is fullwidth (as wide as it is high). Fullwidth
Latin and fullwidth ideographic text (excluding
ideographic punctuation) is set with an angle of 0.
Ideographic punctuation and other ideographic
characters having alternate horizontal and vertical forms
use the vertical form of the glyph. Non-fullwidth text is
set with an angle of 90.
Default value:
Auto.
KEY TYPE VALUE
Tagged PDFSECTION 10.7
859
Content and Allocation Rectangles
As defined in Section 10.7.2, “Basic Layout Model,” an element’s content rectangle
is an enclosing rectangle derived from the shape of the element’s content, which
defines the bounds used for the layout of any included child elements. The
allocation rectangle includes any additional borders or spacing surrounding the
element, affecting how it is positioned with respect to adjacent elements and the
enclosing content rectangle or reference area.
The exact definition of the content rectangle depends on the element’s structure
type:
• For a table cell (structure type TH or TD), the content rectangle is determined
from the bounding box of all graphics objects in the cell’s content, taking into
account any explicit bounding boxes (such as the
BBox entry in a form XOb-
ject). This implied size can be explicitly overridden by the cell’s
Width and
Height attributes. The cell’s height is further adjusted to equal the maximum
height of any cell in its row; its width is adjusted to the maximum width of any
cell in its column.
• For any other BLSE, the height of the content rectangle is the sum of the heights
of all BLSEs it contains, plus any additional spacing adjustments between these
elements.
• For an ILSE that contains text, the height of the content rectangle is set by the
LineHeight attribute. The width is determined by summing the widths of the
contained characters, adjusted for any indents, letter spacing, word spacing, or
line-end conditions.
This attribute is used most commonly to differentiate between the pre-
ferred orientation of alphabetic (non-ideographic) text in vertically writ-
ten Japanese documents (
Auto or 90) and the orientation of the
ideographic characters and/or alphabetic (non-ideographic) text in west-
ern signage and advertising (90).
It affects both the alignment and width of the glyphs. If a glyph is perpen-
dicular to the vertical baseline, its horizontal alignment point is aligned
with the alignment baseline for the script to which the glyph belongs.
The width of the glyph area is determined from the horizontal width font
characteristic for the glyph.
KEY TYPE VALUE
Document InterchangeCHAPTER 10
860
• For an ILSE that contains an illustration or table, the content rectangle is deter-
mined from the bounding box of all graphics objects in the content, taking into
account any explicit bounding boxes (such as the
BBox entry in a form XOb-
ject). This implied size can be explicitly overridden by the element’s
Width and
Height attributes.
• For an ILSE that contains a mixture of elements, the height of the content rect-
angle is determined by aligning the child objects relative to one another based
on their text baseline (for text ILSEs) or end edge (for non-text ILSEs), along
with any applicable
BaselineShift attribute (for all ILSEs), and finding the ex-
treme top and bottom for all elements.
Note: Some applications may apply this process to all elements within the block;
others may apply it on a line-by-line basis.
The allocation rectangle is derived from the content rectangle in a way that also
depends on the structure type:
• For a BLSE, the allocation rectangle is equal to the content rectangle with its
before and after edges adjusted by the element’s
SpaceBefore and SpaceAfter
attributes, if any, but with no changes to the start and end edges.
• For an ILSE, the allocation rectangle is the same as the content rectangle.
Note: Future versions of Tagged PDF are likely to include additional attributes that
can adjust all four edges of the allocation rectangle for both BLSEs and ILSEs.
Illustration Attributes
Certain additional restrictions arise in connection with particular uses of illustra-
tion elements (structure types
Figure, Formula, or Form):
• When an illustration element has a Placement attribute of Block, it must have a
Height attribute with an explicitly specified numerical value (not Auto). This
value is the sole source of information about the illustration’s extent in the
block-progression direction.
• When an illustration element has a Placement attribute of Inline, it must have a
Width attribute with an explicitly specified numerical value (not Auto). This
value is the sole source of information about the illustration’s extent in the
inline-progression direction.
Tagged PDFSECTION 10.7
861
• When an illustration element has a Placement attribute of Inline, Start, or End,
the value of its
BaselineShift attribute is used to determine the position of its af-
ter edge relative to the text baseline;
BaselineShift is ignored for all other values
of
Placement. (An illustration element with a Placement value of Start can be
used to create a dropped capital; one with a
Placement value of Inline can be
used to create a raised capital.)
Column Attributes
The attributes described in Table 10.33 apply only to the grouping elements Art,
Sect, and Div (see “Grouping Elements” on page 827). They are used when the
content in the grouping element is divided into columns.
TABLE 10.33 Standard column attributes
List Attribute
The ListNumbering attribute, described in Table 10.34, is carried by an L (List)
element, but controls the interpretation of the
Lbl (Label) elements within the
list’s
LI (List item) elements (see “List Elements” on page 831). This attribute is de-
KEY TYPE VALUE
ColumnCount
integer (Optional; not inheritable; PDF 1.6) The number of columns in the content of the
grouping element. Default value: 1.
ColumnGap
number or
array
(Optional; not inheritable; PDF 1.6) The desired space between adjacent col-
umns, measured in default user space units in the inline-progression direction.
If the value is a number, it specifies the space between all columns. If the value is
an array, it should contain
ColumnCount - 1 numbers, representing the space be-
tween the first and second columns, the second and third columns, and so on,
respectively. If there are fewer than
ColumnCount - 1 numbers, the last element
specifies all remaining spaces; excess array elements are ignored.
ColumnWidths
number or
array
(Optional; not inheritable; PDF 1.6) The desired width of the columns, measured
in default user space units in the inline-progression direction. If the value is a
number, it specifies the width of all columns. If the value is an array, it should
contain
ColumnCount numbers, representing the width of each column, in or-
der. If there are fewer than
ColumnCount numbers, the last element specifies all
remaining widths; excess array elements are ignored.
Document InterchangeCHAPTER 10
862
fined in attribute objects whose O (owner) entry has the value List (or is one of
the format-specific owner names listed in Table 10.28 on page 843).
TABLE 10.34 Standard list attribute
Note: This attribute is used to allow a content extraction tool to autonumber a list.
However, the
Lbl elements within the table should nevertheless contain the resulting
numbers explicitly, so that the document can be reflowed or printed without the
need for autonumbering.
Table Attributes
The attributes described in Table 10.35 apply only to table cells (structure types
TH and TD; see “Table Elements” on page 831). Attributes in this category are de-
KEY TYPE VALUE
ListNumbering
name (Optional; inheritable) The numbering system used to generate the content of
the
Lbl (Label) elements in an autonumbered list, or the symbol used to identify
each item in an unnumbered list:
None No autonumbering; Lbl elements (if present) contain arbitrary
text not subject to any numbering scheme
Disc Solid circular bullet
Circle Open circular bullet
Square Solid square bullet
Decimal Decimal arabic numerals (1–9, 10–99, … )
UpperRoman Uppercase roman numerals (I, II, III, IV, … )
LowerRoman Lowercase roman numerals (i, ii, iii, iv, … )
UpperAlpha Uppercase letters (A, B, C, … )
LowerAlpha Lowercase letters (a, b, c, … )
Default value:
None.
Note: The alphabet used for
UpperAlpha and LowerAlpha is determined by the pre-
vailing
Lang entry (see Section 10.8.1, “Natural Language Specification”).
Note: The set of possible values may be expanded as Unicode identifies additional
numbering systems.
Accessibility SupportSECTION 10.8
863
fined in attribute objects whose O (owner) entry has the value Table (or is one of
the format-specific owner names listed in Table 10.28 on page 843).
TABLE 10.35 Standard table attributes
10.8 Accessibility Support
PDF includes several facilities in support of accessibility of documents to users
with disabilities. In particular, many visually computer users with visual impair-
ments use screen readers to read documents aloud. To enable proper vocaliza-
tion, either through a screen reader or by some more direct invocation of a text-
to-speech engine, PDF supports the following features:
• Specifying the natural language used for text in a PDF document—for example,
as English or Spanish (see Section 10.8.1, “Natural Language Specification”)
• Providing textual descriptions for images or other items that do not translate
naturally into text (Section 10.8.2, “Alternate Descriptions”), or replacement
text for content that does translate into text but is represented in a nonstandard
KEY TYPE VALUE
RowSpan
integer (Optional; not inheritable) The number of rows in the enclosing table that are
spanned by the cell. The cell expands by adding rows in the block-progression
direction specified by the table’s
WritingMode attribute. Default value: 1.
ColSpan
integer (Optional; not inheritable) The number of columns in the enclosing table that are
spanned by the cell. The cell expands by adding columns in the inline-progres-
sion direction specified by the table’s
WritingMode attribute. Default value: 1.
Headers
array (Optional; not inheritable; PDF 1.5) An array of strings, where each string is the
element identifier (see the
ID entry in Table 10.10) for a TH structure element
that is a header associated with this cell.
This attribute may apply to header cells (
TH) as well as data cells (TD). Therefore,
the headers associated with any cell are those in its
Headers array plus those in
the
Headers array of any TH cells in that array, and so on recursively.
Scope
name (Optional; not inheritable; PDF 1.5) A name with one of the values Row, Column,
or
Both. This attribute applies only to TH elements and indicates whether the
header cell applies to the rest of the cells in the row that contains it, the column
that contains it, or both the row and the column that contain it.
Document InterchangeCHAPTER 10
864
way (such as with a ligature or illuminated character; see Section 10.8.3,
“Replacement Text”)
• Specifying the expansion of abbreviations or acronyms (Section 10.8.4, “Ex-
pansion of Abbreviations and Acronyms”)
The core of this support lies in the ability to determine the logical order of con-
tent in a PDF document, independently of the content’s appearance or layout,
through logical structure and Tagged PDF, as described under “Page Content
Order” on page 817. An accessibility application can extract the content of a doc-
ument for presentation to users with disabilities by traversing the structure hier-
archy and presenting the contents of each node. For this reason, producers of
PDF files must ensure that all information in a document is reachable by means
of the structure hierarchy, and they are strongly encouraged to use the facilities
described in this section.
Note: Text can be extracted from Tagged PDF documents and examined or reused
for purposes other than accessibility; see Section 10.7, “Tagged PDF.”
Additional guidelines for accessibility support of content published on the Web
can be found in the W3C document Web Content Accessibility Guidelines and the
documents it points to (see the Bibliography).
10.8.1 Natural Language Specification
The natural language used for text in a document is determined in a hierarchical
fashion, based on whether an optional
Lang entry (PDF 1.4) is present in any of
several possible locations. At the highest level, the document’s default language
(which applies to both text strings and text within content streams) can be speci-
fied by a
Lang entry in the document catalog (see Section 3.6.1, “Document Cata-
log”). Below this, the language can be specified for the following items:
• Structure elements of any type (see Section 10.6.1, “Structure Hierarchy”),
through a
Lang entry in the structure element dictionary.
• Marked-content sequences that are not in the structure hierarchy (see Section
10.5, “Marked Content”), through a
Lang entry in a property list attached to the
marked-content sequence with a
Span tag. (Although Span is also a standard
Accessibility SupportSECTION 10.8
865
structure type, as described under “Inline-Level Structure Elements” on page
834, its use here is entirely independent of logical structure.)
The following sections provide details on the value of the
Lang entry and the
hierarchical manner in which the language for text in a document is determined.
Note: Text strings encoded in Unicode may include an escape sequence or language
tag indicating the language of the text and overriding the prevailing
Lang entry (see
Section 3.8.1, “Text Strings”).
Language Identifiers
The value of the Lang entry in the document catalog, structure element dictio-
nary, or property list is a text string that specifies the language with a language
identifier having the syntax defined in Internet RFC 3066, Tags for the Identifica-
tion of Languages. This syntax, which is summarized below, is also used to identi-
fy languages in XML, according to the W3C document Extensible Markup
Language (XML) 1.1; see the Bibliography for more information about these doc-
uments. An empty string indicates that the language is unknown.
Language identifiers can be based on codes defined by the International Organi-
zation for Standardization in ISO 639 and ISO 3166 (see the Bibliography) or reg-
istered with the Internet Assigned Numbers Authority (IANA, whose Web site is
located at <http://iana.org/>), or they can include codes created for private use. A
language identifier consists of a primary code optionally followed by one or more
subcodes (each preceded by a hyphen). The primary code can be any of the fol-
lowing:
• A 2-character ISO 639 language code—for example, en for English or es for
Spanish
• The letter i, designating an IANA-registered identifier
• The letter x, for private use
The first subcode can be a 2-character ISO 3166 country code, as in
en-US, or a
3- to 8-character subcode registered with IANA, as in
en-cockney or i-cherokee
(except in private identifiers, for which subcodes are not registered). Subcodes
beyond the first can be any that have been registered with IANA.
Document InterchangeCHAPTER 10
866
Language Specification Hierarchy
The Lang entry in the document catalog specifies the natural language for all text
in the document except where overridden by language specifications for struc-
ture elements or for marked-content sequences that are not in the structure hier-
archy (for example, within an entirely unstructured document). Examples in this
section illustrate the hierarchical manner in which the language for text in a doc-
ument is determined.
Example 10.19 shows how a language specified for the document as a whole
could be overridden by one specified for a marked-content sequence within a
page’s content stream, independent of any logical structure. In this case, the
Lang
entry in the document catalog (not shown) has the value en-US, meaning U.S. En-
glish, and it is overridden by the
Lang property attached (with the Span tag) to
the marked-content sequence
Hasta la vista. The Lang property identifies the lan-
guage for this marked content sequence with the value
es-MX, meaning Mexican
Spanish.
Example 10.19
2 0 obj % Page object
<< /Type /Page
/Contents 3 0 R % Content stream
…
>>
endobj
3 0 obj % Page's content stream
<< /Length … >>
stream
BT
(See you later, or as Arnold would say, ) Tj
/Span << /Lang (es-MX) >> % Start of marked-content sequence
BDC
(Hasta la vista.) Tj
EMC % End of marked-content sequence
ET
endstream
endobj
Where logical structure is described (by a structure hierarchy) within a docu-
ment, the
Lang entry in the document catalog sets the default for the document.
Accessibility SupportSECTION 10.8
867
Below that, any language specifications within the structure hierarchy apply in
this order:
• A structure element’s language specification
Note: If a structure element does not have a
Lang entry, the element inherits its
language from any parent element that has one.
• Within a structure element, a language specification for a nested structure ele-
ment or marked-content sequence
In Example 10.20, the
Lang entry in the structure element dictionary (specifying
English) applies to the marked-content sequence having an
MCID (marked-
content identifier) value of 0 within the indicated page’s content stream. However,
nested within that marked-content sequence is another one in which the
Lang
property attached with the Span tag (specifying Spanish) overrides the structure
element’s language specification.
Note: This example and the next one below omit required
StructParents entries in
the objects used as content items (see “Finding Structure Elements from Content
Items” on page 797).
Example 10.20
1 0 obj % Structure element
<< /Type /StructElem
/S /P % Structure type
/P … % Parent in structure hierarchy
/K << /Type /MCR
/Pg 2 0 R % Page containing marked-content sequence
/MCID 0 % Marked-content identifier
>>
/Lang (en-US) % Language specification for this element
>>
endobj
2 0 obj % Page object
<< /Type /Page
/Contents 3 0 R % Content stream
…
>>
endobj
Document InterchangeCHAPTER 10
868
3 0 obj % Page's content stream
<< /Length … >>
stream
BT
/P << /MCID 0 >> % Start of marked-content sequence
BDC
(See you later, or as Arnold would say, ) Tj
/Span << /Lang (es-MX) >> % Start of nested marked-content sequence
BDC
(Hasta la vista.) Tj
EMC % End of nested marked-content sequence
EMC % End of marked-content sequence
ET
endstream
endobj
If only part of the page content is contained in the structure hierarchy, and the
structured content is nested within nonstructured content to which a different
language specification applies, the structure element’s language specification
takes precedence. In Example 10.21, the page’s content stream consists of a
marked-content sequence that specifies Spanish as its language by means of the
Span tag with a Lang property. Nested within it is content that is part of a struc-
ture element (indicated by the
MCID entry in that property list), and the language
specification that applies to the latter content is that of the structure element,
English.
Example 10.21
1 0 obj % Structure element
<< /Type /StructElem
/S /P % Structure type
/P … % Parent in structure hierarchy
/K << /Type /MCR
/Pg 2 0 R % Page containing marked-content sequence
/MCID 0 % Marked-content identifier
>>
/Lang (en-US) % Language specification for this element
>>
endobj
Accessibility SupportSECTION 10.8
869
2 0 obj % Page object
<< /Type /Page
/Contents 3 0 R % Content stream
…
>>
endobj
3 0 obj % Page's content stream
<< /Length … >>
stream
/Span << /Lang (es-MX) >> % Start of marked-content sequence
BDC
(Hasta la vista, ) Tj
/P << /MCID 0 >> % Start of structured marked-content sequence,
BDC % to which structure element's language applies
(as Arnold would say. ) Tj
EMC % End of structured marked-content sequence
EMC % End of marked-content sequence
endstream
endobj
In other words, a language identifier attached to a marked-content sequence with
the
Span tag specifies the language for all text in the sequence except for nested
marked content that is contained in the structure hierarchy (in which case the
structure element’s language applies) and except where overridden by language
specifications for other nested marked content.
Multi-language Text Arrays
A multi-language text array (PDF 1.5) allows multiple text strings to be specified,
each in association with a language identifier. (See the
Alt entry in Tables 9.9 and
9.12 for examples of its use.) The array contains pairs of strings:
• The first string in each pair is a language identifier. A given language identifier
may not appear more than once in the array; any unrecognized language iden-
tifier should be ignored. An empty string specifies default text to be used when
no matching language identifier is found in the array.
• The second string is text associated with the language.
Example 10.22
[ (en-US) (My vacation) (fr) (mes vacances) ( ) (default text) ]
Document InterchangeCHAPTER 10
870
When a consumer application searches a multi-language text array to find text for
a given language, it should look for an exact (though case-insensitive) match be-
tween the given language’s identifier and the language identifiers in the array. If
no exact match is found, prefix matching is attempted in increasing array order: a
match is declared if the given identifier is a leading, case-insensitive, substring of
an identifier in the array, and the first post-substring character in the array iden-
tifier is a hyphen. For example, given identifier
en matches array identifier en-US,
but given identifier
en-US matches neither en nor en-GB. If no exact or prefix
match can be found, the default text (if any) should be used.
10.8.2 Alternate Descriptions
PDF documents can be enhanced by providing alternate descriptions for images,
formulas, or other items that do not translate naturally into text. Alternate de-
scriptions are human-readable text that could, for example, be vocalized by a
text-to-speech engine for the benefit of users with visual impairments.
An alternate description can be specified for the following items:
• A structure element (see Section 10.6.1, “Structure Hierarchy”), through an Alt
entry in the structure element dictionary
• (PDF 1.5) A marked-content sequence (see Section 10.5, “Marked Content”),
through an
Alt entry in a property list attached to the marked-content sequence
with a
Span tag.
• Any type of annotation (see Section 8.4, “Annotations”) that does not already
have a text representation, through a
Contents entry in the annotation dic-
tionary
For annotation types that normally display text, that text (specified in the
Contents entry of the annotation dictionary) is the natural source for vocalization
purposes. For annotation types that do not display text, a
Contents entry (PDF
1.4) can optionally be included to specify an alternate description. Sound annota-
tions, which are vocalized by default and therefore need no alternate description
for that purpose, can include a
Contents entry specifying a description to be dis-
played in a pop-up window for the benefit of users with hearing impairments.
In addition, an alternate name can be specified for an interactive form field (see
Section 8.6, “Interactive Forms”), to be used in place of the actual field name
wherever the field must be identified in the user interface (such as in error or sta-
Accessibility SupportSECTION 10.8
871
tus messages referring to the field). This alternate name, specified in the optional
TU entry of the field dictionary, can be useful for vocalization purposes.
Alternate descriptions are text strings, which may be encoded in either
PDFDocEncoding or Unicode character encoding. As described in Section 3.8.1,
“Text Strings,” Unicode defines an escape sequence for indicating the language of
the text. This mechanism enables the alternate description to change from the
language specified by the prevailing
Lang entry (as described in the preceding
section).
When applied to structure elements, the text is considered to be a word or phrase
substitution for the current element. For example, if each of two (or more) ele-
ments in a sequence has an
Alt entry in its dictionary, they should be treated as if
a word break is present between them. The same would apply to consecutive
marked-content sequences.
Note: The
Alt entry in property lists can be combined with other entries, as shown in
Example 10.23.
Example 10.23
/Span << /Lang (en-us) /Alt (six-point star) >> BDC (✡) Tj EMC
10.8.3 Replacement Text
Just as alternate descriptions can be provided for images and other items that do
not translate naturally into text (as described in the preceding section), replace-
ment text can be specified for content that does translate into text but that is rep-
resented in a nonstandard way. These nonstandard representations might
include, for example, glyphs for ligatures or custom characters, or inline graphics
corresponding to letters in an illuminated manuscript or to dropped capitals.
Replacement text can be specified for the following items:
• A structure element (see Section 10.6.1, “Structure Hierarchy”), by means of
the optional
ActualText entry (PDF 1.4) of the structure element dictionary.
• (PDF 1.5) A marked-content sequence (see Section 10.5, “Marked Content”),
through an
ActualText entry in a property list attached to the marked-content
sequence with a
Span tag.
Document InterchangeCHAPTER 10
872
The ActualText value is not a description but a replacement for the content, pro-
viding text that is equivalent to what a reader with sight would see when viewing
the content. In contrast to the value of
Alt, which is considered to be a word or
phrase substitution, the value of
ActualText is considered to be a character substi-
tution for the structure element or marked-content sequence. Thus, if each of two
(or more) consecutive structure or marked-content sequences has an
ActualText
entry, they should be treated as if no word break is present between them.
The following example shows the use of replacement text to indicate the correct
character content in a case where hyphenation changes the spelling of a word (in
German, the word “Drucker” when hyphenated is rendered as “Druk-” and
“ker”).
Example 10.24
(Dru) Tj
/Span
<</Actual Text (c) >>
BDC
(k-) Tj
EMC
(ker) '
Like alternate descriptions (and other text strings), replacement text, if encoded
in Unicode, may include an escape sequence for indicating the language of the
text, overriding the prevailing
Lang entry (see Section 3.8.1, “Text Strings”).
10.8.4 Expansion of Abbreviations and Acronyms
Abbreviations and acronyms can pose a problem for text-to-speech engines.
Sometimes the full pronunciation for an abbreviation can be divined without aid.
For example, a dictionary search will probably reveal that “Blvd.” is pronounced
“boulevard” and that “Ave.” is pronounced “avenue.” However, some abbreviations
are difficult to resolve, as in the sentence “Dr. Healwell works at 123 Industrial
Dr.” For this reason, the expansion of an abbreviation or acronym can be speci-
fied for the following items:
• Marked-content sequences, through an E property (PDF 1.4) in a property list
attached to the sequence with a
Span tag, as shown in Example 10.25
• Structure elements, through an E entry (PDF 1.5) in the structure element dic-
tionary
Web CaptureSECTION 10.9
873
Example 10.25
BT
/Span << /E (Doctor) >>
BDC
(Dr. ) Tj
EMC
(Healwell works at 123 Industrial ) Tj
/Span << /E (Drive) >>
BDC
(Dr.) Tj
EMC
ET
The E value (a text string) is considered to be a word or phrase substitution for
the tagged text and therefore should be treated as if a word break separates it
from any surrounding text. Like other text strings, the expansion text, if encoded
in Unicode, may include an escape sequence for indicating the language of the
text (see Section 3.8.1, “Text Strings”).
Some abbreviations or acronyms are conventionally not expanded into words.
For the text “CBS,” for example, either no expansion should be supplied (leaving
its pronunciation up to the text-to-speech engine) or, to be safe, the expansion
“C B S” should be specified.
10.9 Web Capture
Web Capture is a PDF 1.3 feature that allows information from Internet-based or
locally resident HTML, PDF, GIF, JPEG, and ASCII text files to be imported into
a PDF file. This feature is implemented in Acrobat 4.0 and later viewers by a Web
Capture plug-in extension (sometimes called AcroSpider). The information in
the Web Capture data structures enables viewer applications to perform the fol-
lowing operations:
• Save locally and preserve the visual appearance of material from the Web
• Retrieve additional material from the Web and add it to an existing PDF file
• Update or modify existing material previously captured from the Web
• Find source information for material captured from the Web, such as the URL
(if any) from which it was captured
Document InterchangeCHAPTER 10
874
• Find all material in a PDF file that was generated from a given URL
• Find all material in a PDF file that matches a given digital identifier (MD5
hash)
The information needed to perform these operations is recorded in two data
structures in the PDF file:
• The Web Capture information dictionary holds document-level information
related to Web Capture.
• The Web Capture content database keeps track of the material retrieved by Web
Capture and where it came from, enabling Web Capture to avoid downloading
material that is already present in the file.
The following sections provide a detailed overview of these structures. See
Appendix C for information about implementation limits in Web Capture.
Note: The following discussion centers on HTML and GIF files, although Web Cap-
ture handles other file types as well.
10.9.1 Web Capture Information Dictionary
The optional SpiderInfo entry in the document catalog (see Section 3.6.1, “Docu-
ment Catalog”) holds an optional Web Capture information dictionary containing
document-level information related to Web Capture. Table 10.36 shows the con-
tents of this dictionary.
TABLE 10.36 Entries in the Web Capture information dictionary
KEY TYPE VALUE
V
number (Required) The Web Capture version number. For PDF 1.3, the version number is 1.0.
Note: This value is a single real number, not a major and minor version number. Thus, for
example, a version number of 1.2 would be considered greater than 1.15.
C
array (Optional) An array of indirect references to Web Capture command dictionaries (see
“Command Dictionaries” on page 886) describing commands that were used in building
the PDF file. The commands appear in the array in the order in which they were executed
in building the file.
Web CaptureSECTION 10.9
875
10.9.2 Content Database
Web Capture retrieves HTML files from URLs and converts them to PDF. The re-
sulting PDF file may contain the contents of multiple HTML pages. Conversely,
since HTML pages do not have a fixed size, a single HTML page may give rise to
multiple PDF pages. To keep track of the correspondences, Web Capture main-
tains a content database that maps URLs and digital identifiers to PDF objects
such as pages and XObjects. By looking up digital identifiers in the database, Web
Capture can determine whether newly downloaded content is identical to content
already retrieved from a different URL. Thus, it can perform optimizations such
as storing only one copy of an image that is referenced by multiple HTML pages.
Web Capture’s content database is organized into content sets. Each content set is
a dictionary holding information about a group of related PDF objects generated
from the same source data. Content sets are of two subtypes: page sets and image
sets. When Web Capture converts an HTML file to PDF pages, for example, it cre-
ates a page set to hold information about the pages. Similarly, when it converts a
GIF image to one or more image XObjects, it creates an image set describing
those XObjects.
The content set corresponding to a given data source can be accessed in either of
two ways:
• By the URLs from which it was retrieved
• By a digital identifier generated from the source data itself (see “Digital Identi-
fiers” on page 878)
The
URLS and IDS entries in a PDF document’s name dictionary (see Section
3.6.3, “Name Dictionary”) contain name trees mapping URLs and digital identifi-
ers, respectively, to Web Capture content sets. Figure 10.1 shows a simple exam-
ple. An HTML file retrieved from the URL <http://www.adobe.com/> has been
converted to three pages in the PDF file. The entry for that URL in the
URLS
name tree points to a page set containing the three pages. Similarly, the IDS name
tree contains an entry pointing to the same page set, associated with the digital
identifier calculated from the HTML source (the string shown in the figure as
904B…1EA2).
Document InterchangeCHAPTER 10
876
FIGURE 10.1 Simple Web Capture file structure
Entries in the URLS and IDS name trees may refer to an array of content sets
instead of just a single content set. The content sets need not have the same sub-
type, but may include both page sets and image sets. In Figure 10.2, for example, a
GIF file has been retrieved from a URL (<http://www.adobe.com/getacro.gif>)
and converted to a single PDF page. As in Figure 10.1, a page set has been created
to hold information about the new page. However, since the retrieval also
resulted in a new image XObject, an image set has also been created. Instead of
Name dictionary
URLS IDS
Page set
Name tree
Dictionary
Page Page Page
http://www.adobe.com/ 904B…1EA2
Document catalog
Web CaptureSECTION 10.9
877
pointing directly to a single content set, the URLS and IDS entries point to an
array containing both the page set and the image set.
FIGURE 10.2 Complex Web Capture file structure
Names dictionary
URLS IDS
Page Image XObject
Content set array
Document catalog
http://www.adobe.com/getacro.gif
Page set Image set
Dictionary
Array
Name tree
BF70…14D8
Document InterchangeCHAPTER 10
878
URL Strings
URLs associated with Web Capture content sets must be reduced to a predictable,
canonical form before being used as keys in the
URLS name tree. The following
steps describe how to perform this reduction, using terminology from Internet
RFCs 1738, Uniform Resource Locators, and 1808, Relative Uniform Resource Lo-
cators (see the Bibliography). This algorithm is relevant for HTTP, FTP, and file
URLs:
1. If the URL is relative, make it absolute.
2. If the URL contains one or more number sign characters (
#), strip the leftmost
number sign and any characters after it.
3. Convert the scheme section to lowercase ASCII.
4. If there is a host section, convert it to lowercase ASCII.
5. If the scheme is
file and the host is localhost, strip the host section.
6. If there is a port section and the port is the default port for the given protocol
(80 for HTTP or 21 for FTP), strip the port section.
7. If the path section contains dot (
.) or double-dot (..) subsequences, transform
the path as described in section 4 of RFC 1808.
Note: Because the percent character (
%) is unsafe according to RFC 1738 and is
also the escape character for encoded characters, it is not possible in general to dis-
tinguish a URL with unencoded characters from one with encoded characters. For
example, it is impossible to decide whether the sequence
%00 represents a single
encoded null character or a sequence of three unencoded characters. Hence, no
number of encoding or decoding passes on a URL can ever cause it to reach a stable
state. Empirically, URLs embedded in HTML files have unsafe characters encoded
with one encoding pass, and Web servers perform one decoding pass on received
paths (though CGI scripts can make their own decisions). Canonical URLs are thus
assumed to have undergone one and only one encoding pass. A URL whose initial
encoding state is known can be safely transformed into a URL that has undergone
only one encoding pass.
Digital Identifiers
Digital identifiers associated with Web Capture content sets by the IDS name tree
are generated using the MD5 message-digest algorithm (described in Internet
Web CaptureSECTION 10.9
879
RFC 1321, The MD5 Message-Digest Algorithm; see the Bibliography). The exact
data passed to the algorithm depends on the type of content set and the nature of
the identifier being calculated.
For a page set, the source data is passed to the MD5 algorithm first, followed by
strings representing the digital identifiers of any auxiliary data files (such as im-
ages) referenced in the source data, in the order in which they are first referenced.
(If an auxiliary file is referenced more than once, its identifier is passed only the
first time.) This produces a composite identifier representing the visual appear-
ance of the pages in the page set. Two HTML source files that are identical, but
for which the referenced images contain different data—for example, if they have
been generated by a script or are pointed to by relative URLs—do not produce the
same identifier.
Note: When the source data is taken from a PDF file, the identifier is generated sole-
ly from the contents of that file; there is no auxiliary data. (See also implementation
note 158 in Appendix H.)
A page set can also have a text identifier, calculated by applying the MD5 algo-
rithm to just the rendered text present in the source data. For an HTML file, for
example, the text identifier is based solely on the text between markup tags; no
images are used in the calculation.
For an image set, the digital identifier is calculated by passing the source data for
the original image to the MD5 algorithm. For example, the identifier for an image
set created from a GIF image is calculated from the contents of the GIF.
Unique Name Generation
In generating PDF pages from a data source, Web Capture converts items such as
hypertext links and HTML form fields into corresponding named destinations
and interactive form fields. These items must have names that do not conflict
with those of existing items in the file. Also, when updating the file, Web Capture
may need to locate all destinations and fields constructed for a given page set.
Accordingly, each destination or field is given a unique name that is derived from
its original name but constructed so that it avoids conflicts with similarly named
items in other page sets.
Document InterchangeCHAPTER 10
880
Note: As used here, the term name refers to a string, not a name object.
The unique name is formed by appending an encoded form of the page set’s digi-
tal identifier string to the original name of the destination or field. The identifier
string must be encoded to remove characters that have special meaning in desti-
nations and fields. For example, since the period character (
.) is used as the field
separator in interactive form field names, it must not appear in the identifier por-
tion of the unique name; it is therefore encoded internally as two bytes, 92 and
112, corresponding to the ASCII characters
\p. Note that since the backslash
character (
\) has special meaning for the syntax of string objects, it must be pre-
ceded by another backslash when written in the PDF file. For example, if the orig-
inal digital identifier string were
alpha.beta
it would be encoded internally as
alpha\pbeta
and written in the PDF file as
(alpha\\pbeta)
Similarly, the null character (character code 0) is encoded internally as the two
bytes 92 and 48, corresponding to the ASCII characters
\0. If the original digital
identifier string were
alphaØbeta
(where Ø denotes the null character), it would be encoded internally as
alpha\0beta
and written in the PDF file as
(alpha\\0beta)
Finally, the backslash character itself is encoded internally as the two bytes 92 and
92, corresponding to the characters
\\. In written form, each of these in turn
requires a preceding backslash. Thus, the digital identifier string
alpha\beta
Web CaptureSECTION 10.9
881
would be encoded internally as
alpha\\beta
and written in the PDF file as
(alpha\\\\beta)
If the name is used for an interactive form field, there is an additional encoding to
ensure uniqueness and compatibility with interactive forms. Each byte in the
source string, encoded as described above, is replaced by two bytes in the destina-
tion string. The first byte in each pair is 65 (corresponding to the ASCII character
A) plus the high-order 4 bits of the source byte; the second byte is 65 plus the low-
order 4 bits of the source byte.
10.9.3 Content Sets
A Web Capture content set is a dictionary describing a set of PDF objects gener-
ated from the same source data. It may include information common to all the
objects in the set as well as about the set itself. Table 10.37 shows the contents of
this type of dictionary.
Page Sets
A page set is a content set containing a group of PDF page objects generated from
a common source, such as an HTML file. The pages are listed in the
O array (see
Table 10.37) in the same order in which they were initially added to the file. A
single page object may not belong to more than one page set. Table 10.38 shows
the content set dictionary entries specific to this type of content set.
The optional
TID (text identifier) entry may be used to store an identifier gener-
ated from the text of the pages belonging to the page set (see “Digital Identifi-
ers” on page 878). This identifier may be used, for example, to determine
whether the text of a document has changed. A text identifier may not be
appropriate for some page sets (such as those with no text) and should be omit-
ted in these cases.
Document InterchangeCHAPTER 10
882
TABLE 10.37 Entries common to all Web Capture content sets
TABLE 10.38 Additional entries specific to a Web Capture page set
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes; if present, must be
SpiderContentSet for a Web Capture content set.
S
name (Required) The subtype of content set that this dictionary describes:
SPS (“Spider page set”) A page set
SIS (“Spider image set”) An image set
ID
string (Required) The digital identifier of the content set (see “Digital Identifiers” on page
878). If the content set has been located by means of the
URLS name tree, this allows its
related entry in the
IDS name tree to be found.
O
array (Required) An array of indirect references to the objects belonging to the content set.
The order of objects in the array is undefined in general but may be restricted by spe-
cific content set subtypes.
SI
dictionary
or array
(Required) A source information dictionary (see Section 10.9.4, “Source Information”)
or an array of such dictionaries, describing the sources from which the objects belong-
ing to the content set were created.
CT
string (Optional) The content type, a string characterizing the source from which the objects
belonging to the content set were created. The string should conform to the content
type specification described in Internet RFC 2045, Multipurpose Internet Mail Exten-
sions (MIME) Part One: Format of Internet Message Bodies (see the Bibliography). For
example, for a page set consisting of a group of PDF pages created from an HTML file,
the content type would be
text/html.
TS
date (Optional) A time stamp giving the date and time at which the content set was created.
KEY TYPE VALUE
S
name (Required) The subtype of content set that this dictionary describes; must be SPS (“Spi-
der page set”) for a page set.
T
text string (Optional) The title of the page set, a text string representing it in human-readable
form.
TID
string (Optional) A text identifier generated from the text of the page set, as described in
“Digital Identifiers” on page 878.
Web CaptureSECTION 10.9
883
Image Sets
An image set is a content set containing a group of image XObjects generated
from a common source, such as multiple frames of an animated GIF image. (Web
Capture 4.0 always generates a single image XObject for a given image.) A single
XObject may not belong to more than one image set. Table 10.39 shows the con-
tent set dictionary entries specific to this type of content set.
TABLE 10.39 Additional entries specific to a Web Capture image set
Each image XObject in an image set has a reference count indicating the number
of PDF pages referring to that XObject. The reference count is incremented
whenever Web Capture creates a new page referring to the XObject (including
copies of already existing pages) and decremented whenever such a page is
destroyed. (The reference count is incremented or decremented only once per
page, regardless of the number of times the XObject may be referenced by that
same page.) When the reference count reaches 0, it is assumed that there are no
remaining pages referring to the XObject and that it can be removed from the im-
age set’s
O array. (See implementation note 159 in Appendix H.)
10.9.4 Source Information
The SI entry in a content set dictionary (see Table 10.37 on page 882) identifies
one or more source information dictionaries containing information about the lo-
cations from which the source data for the content set was retrieved. Table 10.40
shows the contents of this type of dictionary.
KEY TYPE VALUE
S
name (Required) The subtype of content set that this dictionary describes; must be SIS (“Spider
image set”) for an image set.
R
integer
or array
(Required) The reference counts (see below) for the image XObjects belonging to the im-
age set. For an image set containing a single XObject, the value is simply the integer
reference count for that XObject. If the image set contains multiple XObjects, the value is
an array of reference counts parallel to the
O array (see Table 10.37 on page 882); that is,
each element in the
R array holds the reference count for the image XObject at the corre-
sponding position in the
O array.
Document InterchangeCHAPTER 10
884
TABLE 10.40 Entries in a source information dictionary
In the simplest case, the content set’s SI entry just contains a single source infor-
mation dictionary. However, it is not uncommon for the same source data to be
accessible from two or more unrelated URLs. When Web Capture detects such a
condition (by comparing digital identifiers), it generates a single content set from
the source data, containing just one copy of the relevant PDF pages or image
XObjects, but creates multiple source information dictionaries describing the
separate ways in which the original source data can be accessed. It then stores an
array containing these multiple source information dictionaries as the value of
the
SI entry in the content set dictionary.
A source information dictionary’s
AU (aliased URLs) entry identifies the URLs
from which the source data was retrieved. If there is only one such URL, a simple
string suffices as the value of this entry. If multiple URLs map to the same loca-
tion through redirection, the
AU value is a URL alias dictionary representing
them (see “URL Alias Dictionaries,” below).
KEY TYPE VALUE
AU string or
dictionary
(Required) A string or URL alias dictionary (see “URL Alias Dictionaries,” below) iden-
tifying the URLs from which the source data was retrieved.
TS date (Optional) A time stamp giving the most recent date and time at which the content set’s
contents were known to be up to date with the source data.
E date (Optional) An expiration stamp giving the date and time at which the content set’s con-
tents should be considered out of date with the source data.
S integer (Optional) A code indicating the type of form submission, if any, by which the source
data was accessed (see “Submit-Form Actions” on page 662):
0 Not accessed by means of a form submission
1 Accessed by means of an HTTP GET request
2 Accessed by means of an HTTP POST request
This entry should be present only in source information dictionaries associated with
page sets. Default value: 0.
C dictionary (Optional; must be an indirect reference) A command dictionary (see “Command Dic-
tionaries” on page 886) describing the command that caused the source data to be
retrieved. This entry should be present only in source information dictionaries associ-
ated with page sets.
Web CaptureSECTION 10.9
885
Note: For file size efficiency, it is recommended that the entire URL alias dictionary
(excluding the URL strings) be represented as a direct object because its internal
structure should never be shared or externally referenced.
The
TS (time stamp) entry allows each source location associated with a content
set to have its own time stamp. This is necessary because the time stamp in the
content set dictionary (see Table 10.37 on page 882) merely refers to the creation
date of the content set. A hypothetical “Update Content Set” command might re-
set the time stamp in the source information dictionary to the current time if it
found that the source data had not changed since the time stamp was last set.
The
E (expiration) entry specifies an expiration date for each source location
associated with a content set. If the current date and time are later than those
specified, the contents of the content set should be considered out of date with
the original source.
URL Alias Dictionaries
When a URL is accessed via HTTP, a response header may be returned indicat-
ing that the requested data is at a different URL. This redirection process may be
repeated in turn at the new URL and can potentially continue indefinitely. It is
not uncommon to find multiple URLs that all lead eventually to the same desti-
nation through one or more redirections. A URL alias dictionary represents such
a set of URL chains leading to a common destination. Table 10.41 shows the con-
tents of this type of dictionary.
TABLE 10.41 Entries in a URL alias dictionary
The C (chains) entry should be omitted if the URL alias dictionary contains only
one URL. If
C is present, its value is an array of arrays, each representing a chain
of URLs leading to the common destination. Within each chain, the URLs are
stored as strings in the order in which they occur in the redirection sequence.
The common destination (the last URL in a chain) may be omitted, since it is al-
ready identified by the
U entry. (See implementation note 160 in Appendix H.)
KEY TYPE VALUE
U string (Required) The destination URL to which all of the chains specified by the C entry lead.
C array (Optional) An array of one or more arrays of strings, each representing a chain of URLs
leading to the common destination specified by
U.
Document InterchangeCHAPTER 10
886
Command Dictionaries
A Web Capture command dictionary represents a command executed by Web
Capture to retrieve one or more pieces of source data that were used to create new
pages or modify existing pages. The entries in this dictionary represent
parameters that were originally specified interactively by the user who requested
that the Web content be captured. This information is recorded so that the com-
mand can subsequently be repeated to update the captured content. Table 10.42
shows the contents of this type of dictionary.
TABLE 10.42 Entries in a Web Capture command dictionary
The URL entry specifies the initial URL for the retrieval command. The L (levels)
entry specifies the number of levels of pages requested to be retrieved from this
URL. If the
L entry is omitted, its value is assumed to be 1, denoting retrieval of
the initial URL only.
The value of the command dictionary’s
F entry is an unsigned 32-bit integer con-
taining flags specifying various characteristics of the command. Bit positions
within the flag word are numbered from 1 (low-order) to 32 (high-order). Table
10.43 shows the meanings of the flags; all undefined flag bits are reserved and
must be set to 0.
KEY TYPE VALUE
URL string (Required) The initial URL from which source data was requested.
L integer (Optional) The number of levels of pages retrieved from the initial URL. Default
value: 1.
F integer (Optional) A set of flags specifying various characteristics of the command (see
Table 10.43). Default value: 0.
P string or stream (Optional) Data that was posted to the URL.
CT string (Optional) A content type describing the data posted to the URL. Default value:
application/xwwwformurlencoded.
H string (Optional) Additional HTTP request headers sent to the URL.
S dictionary (Optional) A command settings dictionary containing settings used in the con-
version process (see “Command Settings” on page 888).
Web CaptureSECTION 10.9
887
TABLE 10.43 Web Capture command flags
The SamePath flag, if set, indicates that pages were retrieved only if they were in
the same path specified in the initial URL. A page is considered to be in the same
path if its scheme and network location components (as defined in Internet RFC
1808, Relative Uniform Resource Locators) match those of the initial URL and its
path component matches up to and including the last forward slash (
/) character
in the initial URL. For example, the URL
http://www.adobe.com/fiddle/faddle/foo.html
is considered to be in the same path as the initial URL
http://www.adobe.com/fiddle/initial.html
The comparison is case-insensitive for the scheme and network location compo-
nents and case-sensitive for the path component.
If the Submit flag is set, the command represents a form submission. If no
P
(posted data) entry is present, the submitted data is encoded in the URL (an
HTTP GET request). If
P is present, the command represents an HTTP POST
request. In this case, the value of the Submit flag is ignored. If the posted data is
small enough, it may be represented by a string. For large amounts of data, a
stream is recommended because it can be compressed.
The
CT (content type) entry is relevant only for POST requests. It describes the
content type of the posted data, as described in Internet RFC 2045, Multipurpose
Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies
(see the Bibliography).
BIT POSITION NAME MEANING
1 SameSite If set, pages were retrieved only from the host specified in the initial URL.
2 SamePath If set, pages were retrieved only from the path specified in the initial URL
(see below).
3 Submit If set, the command represents a form submission (see below).
Document InterchangeCHAPTER 10
888
The H (headers) entry specifies additional HTTP request headers that were sent
in the request for the URL. Each header line in the string is terminated with a car-
riage return and a line feed, as in this example:
(Referer: http://frumble.com\015\012From:veeble@frotz.com\015\012)
The HTTP request header format is specified in Internet RFC 2616, Hypertext
Transfer Protocol—HTTP/1.1 (see the Bibliography).
The
S (settings) entry specifies a command settings dictionary (see the next sec-
tion). Holding settings specific to the conversion engines. If this entry is omitted,
default values are assumed. It is recommended that command settings dictionar-
ies be shared by any command dictionaries that use the same settings.
Command Settings
The S (settings) entry in a command dictionary contains a command settings
dictionary, which holds settings for conversion engines used in converting the
results of the command to PDF. Table 10.44 shows the contents of this type of dic-
tionary.
TABLE 10.44 Entries in a Web Capture command settings dictionary
Each key in the C dictionary is the internal name of a conversion engine, which
should be a name object of the following form:
/company:product:version:contentType
KEY TYPE VALUE
G dictionary (Optional) A dictionary containing global conversion engine settings relevant to all con-
version engines. If this entry is absent, default settings are used.
C dictionary (Optional) Settings for specific conversion engines. Each key in this dictionary is the
internal name of a conversion engine (see below). The associated value is a dictionary
containing the settings associated with that conversion engine. If the settings for a par-
ticular conversion engine are not found in the dictionary, default settings are used.
Web CaptureSECTION 10.9
889
where
company is the name (or abbreviation) of the company that created the conver-
sion engine.
product is the name of the conversion engine. This field may be left blank, but
the trailing colon character (
:) is still required.
version is the version of the conversion engine.
contentType is an identifier for the content type that the settings are associated
with. This is required because some converters may handle multiple content
types.
For example:
/ADBE:H2PDF:1.0:HTML
Note that all fields in the internal name are case-sensitive. The company field
must conform to the naming guidelines described in Appendix E. The values of
the other fields are unrestricted, except that they must not contain a colon.
Note: It must be possible to make a deep copy of a command settings dictionary
without explicit knowledge of the settings it may contain. To facilitate this operation,
the directed graph of PDF objects rooted by the command settings dictionary must
be entirely self-contained; that is, it must not contain any object referred to from
elsewhere in the PDF file.
10.9.5 Object Attributes Related to Web Capture
A given page object or image XObject can belong to at most one Web Capture
content set, called its parent content set. However, the object has no direct pointer
to its parent content set. Such a pointer might present problems for an application
that traces all pointers from an object to determine, for example, what resources
the object depends on. Instead, the object’s
ID entry (see Table 3.27 on page 119
and Table 4.39 on page 310) contains the digital identifier of the parent content
set, which can be used to locate the parent content set via the
IDS name tree in the
document’s name dictionary. (If the
IDS entry for the identifier contains an array
of content sets, the parent can be found by searching the array for the content set
whose
O entry includes the child object.)
Document InterchangeCHAPTER 10
890
In the course of creating PDF pages from HTML files, Web Capture frequently
scales the contents down to fit on fixed-sized pages. The
PZ (preferred zoom)
entry in a page object (see “Page Objects” on page 119) specifies a magnification
factor by which the page can be scaled to undo the downscaling and view the
page at its original size. That is, when the page is viewed at the preferred magnifi-
cation factor, one unit in default user space corresponds to one original source
pixel.
10.10 Prepress Support
This section describes features of PDF that support prepress production work-
flows:
• The specification of page boundaries governing various aspects of the prepress
process, such as cropping, bleed, and trimming (Section 10.10.1, “Page Bound-
aries”)
• Facilities for including printer’s marks, such as registration targets, gray ramps,
color bars, and cut marks to assist in the production process (Section 10.10.2,
“Printer’s Marks”)
• Information for generating color separations for pages in a document (Section
10.10.3, “Separation Dictionaries”)
• Output intents for matching the color characteristics of a document with those
of a target output device or production environment in which it will be printed
(Section 10.10.4, “Output Intents”)
• Support for the generation of traps to minimize the visual effects of misregis-
tration between multiple colorants (Section 10.10.5, “Trapping Support”)
• The Open Prepress Interface (OPI) for creating low-resolution proxies for high-
resolution images (Section 10.10.6, “Open Prepress Interface (OPI)”)
10.10.1 Page Boundaries
A PDF page may be prepared either for a finished medium, such as a sheet of
paper, or as part of a prepress process in which the content of the page is placed
on an intermediate medium, such as film or an imposed reproduction plate. In
the latter case, it is important to distinguish between the intermediate page and
the finished page. The intermediate page may often include additional
production-related content, such as bleeds or printer marks, that falls outside the
Prepress SupportSECTION 10.10
891
boundaries of the finished page. To handle such cases, a PDF page can define as
many as five separate boundaries to control various aspects of the imaging
process:
• The media box defines the boundaries of the physical medium on which the
page is to be printed. It may include any extended area surrounding the
finished page for bleed, printing marks, or other such purposes. It may also
include areas close to the edges of the medium that cannot be marked because
of physical limitations of the output device. Content falling outside this bound-
ary can safely be discarded without affecting the meaning of the PDF file.
• The crop box defines the region to which the contents of the page are to be
clipped (cropped) when displayed or printed. Unlike the other boxes, the crop
box has no defined meaning in terms of physical page geometry or intended
use; it merely imposes clipping on the page contents. However, in the absence
of additional information (such as imposition instructions specified in a JDF or
PJTF job ticket), the crop box determines how the page’s contents are to be po-
sitioned on the output medium. The default value is the page’s media box.
• The bleed box (PDF 1.3) defines the region to which the contents of the page
should be clipped when output in a production environment. This may include
any extra bleed area needed to accommodate the physical limitations of cut-
ting, folding, and trimming equipment. The actual printed page may include
printing marks that fall outside the bleed box. The default value is the page’s
crop box.
• The trim box (PDF 1.3) defines the intended dimensions of the finished page
after trimming. It may be smaller than the media box to allow for production-
related content, such as printing instructions, cut marks, or color bars. The
default value is the page’s crop box.
• The art box (PDF 1.3) defines the extent of the page’s meaningful content
(including potential white space) as intended by the page’s creator. The default
value is the page’s crop box.
These boundaries are specified by the
MediaBox, CropBox, BleedBox, TrimBox,
and
ArtBox entries, respectively, in the page object dictionary (see Table 3.27 on
page 119). All of them are rectangles expressed in default user space units. The
crop, bleed, trim, and art boxes should not ordinarily extend beyond the boun-
daries of the media box. If they do, they are effectively reduced to their intersec-
Document InterchangeCHAPTER 10
892
tion with the media box. Figure 10.3 illustrates the relationships among these
boundaries. (The crop box is not shown in the figure because it has no defined re-
lationship with any of the other boundaries.)
FIGURE 10.3 Page boundaries
This might be a caption
Bleed box
Media box
Art box
Trim box
Bleed: 10.75x8.25
Trim: 10.5x8
Printer’s marks
Headline
Prepress SupportSECTION 10.10
893
How the various boundaries are used depends on the purpose to which the page
is being put. The following are typical purposes:
• Placing the content of a page in another application. The art box determines the
boundary of the content that is to be placed in the application. Depending on
the applicable usage conventions, the placed content may be clipped to either
the art box or the bleed box. (For example, a quarter-page advertisement to be
placed on a magazine page might be clipped to the art box on the two sides of
the ad that face into the middle of the page and to the bleed box on the two
sides that bleed over the edge of the page.) The media box and trim box are
ignored.
• Printing a finished page. This case is typical of desktop or shared page printers,
in which the page content is positioned directly on the final output medium.
The art box and bleed box are ignored. The media box may be used as advice
for selecting media of the appropriate size. The crop box and trim box, if
present, should be the same as the media box. (See implementation note 161 in
Appendix H.)
• Printing an intermediate page for use in a prepress process. The art box is
ignored. The bleed box defines the boundary of the content to be imaged. The
trim box specifies the positioning of the content on the medium; it may also be
used to generate cut or fold marks outside the bleed box. Content falling within
the media box but outside the bleed box may or may not be imaged, depending
on the specific production process being used.
• Building an imposition of multiple pages on a press sheet. The art box is ignored.
The bleed box defines the clipping boundary of the content to be imaged; con-
tent outside the bleed box is ignored. The trim box specifies the positioning of
the page’s content within the imposition. Cut and fold marks are typically gen-
erated for the imposition as a whole.
In the scenarios above, an application that interprets the bleed, trim, and art
boxes for some purpose typically alters the crop box so as to impose the clipping
that those boxes prescribe.
Display of Page Boundaries
For the user’s convenience, viewer applications may offer the ability to display
guidelines on the screen for the various page boundaries. The optional
BoxCol-
orInfo
entry in a page object (see “Page Objects” on page 119) holds a box color
Document InterchangeCHAPTER 10
894
information dictionary (PDF 1.4) specifying the colors and other visual character-
istics to be used for such display. Viewer applications typically provide a user in-
terface to allow the user to set these characteristics interactively. Note that this
information is page-specific and can vary from one page to another.
As shown in Table 10.45, the box color information dictionary contains an op-
tional entry for each of the possible page boundaries other than the media box.
The value of each entry is a box style dictionary, whose contents are shown in Table
10.46. If a given entry is absent, the viewer application should use its own current
default settings instead.
10.10.2 Printer’s Marks
Printer’s marks are graphic symbols or text added to a page to assist production
personnel in identifying components of a multiple-plate job and maintaining
consistent output during production. Examples commonly used in the printing
industry include these:
• Registration targets for aligning plates
• Gray ramps and color bars for measuring colors and ink densities
• Cut marks showing where the output medium is to be trimmed
Although PDF producer applications traditionally include such marks in the con-
tent stream of a document, they are logically separate from the content of the page
itself and typically appear outside the boundaries (the crop box, trim box, and art
box) defining the extent of that content (see Section 10.10.1, “Page Boundaries”).
Printer’s mark annotations (PDF 1.4) provide a mechanism for incorporating
printer’s marks into the PDF representation of a page, while keeping them sepa-
rate from the actual page content. Each page in a PDF document may contain any
number of such annotations, each of which represents a single printer’s mark.
Note: Because printer’s marks typically fall outside the page’s content boundaries,
each mark must be represented as a separate annotation. Otherwise—if, for exam-
ple, the cut marks at the four corners of the page were defined in a single annota-
tion—the annotation rectangle would encompass the entire contents of the page and
could interfere with the user’s ability to select content or interact with other annota-
tions on the page. Defining printer’s marks in separate annotations also facilitates
the implementation of a drag-and-drop user interface for specifying them.
Prepress SupportSECTION 10.10
895
TABLE 10.45 Entries in a box color information dictionary
TABLE 10.46 Entries in a box style dictionary
KEY TYPE VALUE
CropBox dictionary (Optional) A box style dictionary (see Table 10.46) specifying the visual characteris-
tics for displaying guidelines for the page’s crop box. This entry is ignored if no crop
box is defined in the page object.
BleedBox dictionary (Optional) A box style dictionary (see Table 10.46) specifying the visual characteris-
tics for displaying guidelines for the page’s bleed box. This entry is ignored if no
bleed box is defined in the page object.
TrimBox dictionary (Optional) A box style dictionary (see Table 10.46) specifying the visual characteris-
tics for displaying guidelines for the page’s trim box. This entry is ignored if no trim
box is defined in the page object.
ArtBox dictionary (Optional) A box style dictionary (see Table 10.46) specifying the visual characteris-
tics for displaying guidelines for the page’s art box. This entry is ignored if no art
box is defined in the page object.
KEY TYPE VALUE
C array (Optional) An array of three numbers in the range 0.0 to 1.0, representing the com-
ponents in the
DeviceRGB color space of the color to be used for displaying the
guidelines. Default value:
[0.0 0.0 0.0].
W number (Optional) The guideline width in default user space units. Default value: 1.
S name (Optional) The guideline style:
S (Solid) A solid rectangle.
D (Dashed) A dashed rectangle. The dash pattern is specified by the D entry
(see below).
Other guideline styles may be defined in the future. Default value:
S.
D array (Optional) A dash array defining a pattern of dashes and gaps to be used in drawing
dashed guidelines (guideline style
D above). The dash array is specified in default
user space units, in the same format as in the line dash pattern parameter of the
graphics state (see “Line Dash Pattern” on page 187). The dash phase is not speci-
fied and is assumed to be 0. For example, a
D entry of [3 2] specifies guidelines
drawn with 3-point dashes alternating with 2-point gaps. Default value:
[3].
Document InterchangeCHAPTER 10
896
The visual presentation of a printer’s mark is defined by a form XObject specified
as an appearance stream in the
N (normal) entry of the printer’s mark annota-
tion’s appearance dictionary (see Section 8.4.4, “Appearance Streams”). More than
one appearance may be defined for the same printer’s mark to meet the
requirements of different regions or production facilities. In this case, the
appearance dictionary’s
N entry holds a subdictionary containing the alternate
appearances, each identified by an arbitrary key. The
AS (appearance state) entry
in the annotation dictionary designates one of them to be displayed or printed.
Note: The printer’s mark annotation’s appearance dictionary may include
R (roll-
over) or
D (down) entries, but appearances defined in either of these entries are
never displayed or printed.
Like all annotations, a printer’s mark annotation is defined by an annotation dic-
tionary (see Section 8.4.1, “Annotation Dictionaries”); its annotation type is
PrinterMark. The AP (appearances) and F (flags) entries (which ordinarily are
optional) must be present, as must the
AS (appearance state) entry if the appear-
ance dictionary
AP contains more than one appearance stream. The Print and
ReadOnly flags in the
F entry must be set and all others clear (see Section 8.4.2,
“Annotation Flags”). Table 10.47 shows an additional annotation dictionary entry
specific to this type of annotation.
TABLE 10.47 Additional entries specific to a printer’s mark annotation
The form dictionary defining a printer’s mark can contain the optional entries
shown in Table 10.48 in addition to the standard ones common to all form dictio-
naries (see Section 4.9.1, “Form Dictionaries”).
TABLE 10.48 Additional entries specific to a printer’s mark form dictionary
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
PrinterMark for a printer’s mark annotation.
MN
name (Optional) An arbitrary name identifying the type of printer’s mark, such as
ColorBar or RegistrationTarget.
KEY TYPE VALUE
MarkStyle
text string (Optional; PDF 1.4) A text string representing the printer’s mark in human-
readable form and suitable for presentation to the user on the screen.
Prepress SupportSECTION 10.10
897
10.10.3 Separation Dictionaries
In high-end printing workflows, pages are ultimately produced as sets of separa-
tions, one per colorant (see “Separation Color Spaces” on page 234). Ordinarily,
each page in a PDF file is treated as a composite page that paints graphics objects
using all the process colorants and perhaps some spot colorants as well. In other
words, all separations for a page are generated from a single PDF description of
that page.
In some workflows, however, pages are preseparated before generating the PDF
file. In a preseparated PDF file, the separations for a page are described as sepa-
rate page objects, each painting only a single colorant (usually specified in the
DeviceGray color space). When this is done, additional information is needed to
identify the actual colorant associated with each separation and to group together
the page objects representing all the separations for a given page. This informa-
tion is contained in a separation dictionary (PDF 1.3) in the
SeparationInfo entry
of each page object (see “Page Objects” on page 119). Table 10.49 shows the con-
tents of this type of dictionary.
TABLE 10.49 Entries in a separation dictionary
Colorants
dictionary (Optional; PDF 1.4) A dictionary identifying the individual colorants
associated with a printer’s mark, such as a color bar. For each entry in this
dictionary, the key is a colorant name and the value is an array defining a
Separation color space for that colorant (see “Separation Color Spaces” on
page 234). The key must match the colorant name given in that color space.
KEY TYPE VALUE
Pages
array (Required) An array of indirect references to page objects representing separa-
tions of the same document page. One of the page objects in the array must be
the one with which this separation dictionary is associated, and all of them must
have separation dictionaries (
SeparationInfo entries) containing Pages arrays
identical to this one.
DeviceColorant
name or
string
(Required) The name of the device colorant to be used in rendering this separa-
tion, such as
Cyan or PANTONE 35 CV.
KEY TYPE VALUE
Document InterchangeCHAPTER 10
898
10.10.4 Output Intents
Output intents (PDF 1.4) provide a means for matching the color characteristics
of a PDF document with those of a target output device or production environ-
ment in which the document will be printed. The optional
OutputIntents entry in
the document catalog (see Section 3.6.1, “Document Catalog”) holds an array of
output intent dictionaries, each describing the color reproduction characteristics
of a possible output device or production condition. The contents of these dictio-
naries can vary for different devices and conditions. The dictionary’s
S entry
specifies an output intent subtype that determines the format and meaning of the
remaining entries.
This use of multiple output intents allows the production process to be custom-
ized to the expected workflow and the specific tools available. For example, one
production facility might process files conforming to a recognized format stan-
dard such as PDF/X-1, while another uses custom Acrobat plug-in extensions to
produce RGB output for document distribution on the Web. Each of these work-
flows would require different sets of output intent information. Multiple output
intents also allow the same PDF file to be distributed unmodified to multiple pro-
duction facilities. The choice of which output intent to use in a given production
environment is a matter for agreement between the purchaser and provider of
production services. PDF intentionally does not include a selector for choosing a
particular output intent from within the PDF file.
At the time of publication, only one output intent subtype,
GTS_PDFX, has been
defined, corresponding to the PDF/X format standard (available on the Web at
<http://www.npes.org/standards/>). Table 10.50 shows the contents of this type
ColorSpace
array (Optional) An array defining a Separation or DeviceN color space (see “Separa-
tion Color Spaces” on page 234 and “DeviceN Color Spaces” on page 238). It
provides additional information about the color specified by
DeviceColorant—in
particular, the alternate color space and tint transformation function that would
be used to represent the colorant as a process color. This information enables a
viewer application to preview the separation in a color that approximates the de-
vice colorant.
The value of
DeviceColorant must match the space’s colorant name (if it is a
Separation space) or be one of the space’s colorant names (if it is a DeviceN
space).
KEY TYPE VALUE
Prepress SupportSECTION 10.10
899
of output intent dictionary. Other subtypes may be added in the future; the names
of any such additional subtypes must conform to the naming guidelines de-
scribed in Appendix E.
TABLE 10.50 Entries in a PDF/X output intent dictionary
KEY TYPE VALUE
Type
name (Optional) The type of PDF object that this dictionary describes;
if present, must be
OutputIntent for an output intent dictionary.
S
name (Required) The output intent subtype; must be GTS_PDFX for a
PDF/X output intent.
OutputCondition
text string (Optional) A text string concisely identifying the intended out-
put device or production condition in human-readable form.
This is the preferred method of defining such a string for pre-
sentation to the user.
OutputConditionIdentifier
string (Required) A string identifying the intended output device or
production condition in human- or machine-readable form. If
human-readable, this string may be used in lieu of an
OutputCondition string for presentation to the user.
A typical value for this entry would be the name of a production
condition maintained in an industry-standard registry such as
the ICC Characterization Data Registry (see the Bibliography). If
the designated condition matches that in effect at production
time, the production software is responsible for providing the
corresponding ICC profile as defined in the registry.
If the intended production condition is not a recognized
standard, the value of this entry may be
Custom or an applica-
tion-specific, machine-readable name. The
DestOutputProfile
entry defines the ICC profile, and the Info entry is used for fur-
ther human-readable identification.
RegistryName
string (Optional) A string (conventionally a uniform resource identifi-
er, or URI) identifying the registry in which the condition desig-
nated by OutputConditionIdentifier is defined.
Info
text string (Required if OutputConditionIdentifier does not specify a standard
production condition; optional otherwise) A human-readable text
string containing additional information or comments about the
intended target device or production condition.
Document InterchangeCHAPTER 10
900
Note: PDF/X is actually a family of standards representing varying levels of con-
formance. The standard for a given conformance level may prescribe further restric-
tions on the usage and meaning of entries in the output intent dictionary. Any such
restrictions take precedence over the descriptions given in Table 10.50.
The ICC profile information in an output intent dictionary supplements rather
than replaces that in an
ICCBased or default color space (see “ICCBased Color
Spaces” on page 222 and “Default Color Spaces” on page 227). Those mecha-
nisms are specifically intended for describing the characteristics of source color
component values. An output intent can be used in conjunction with them to
convert source colors to those required for a specific production condition or to
enable the display or proofing of the intended output.
The data in an output intent dictionary is provided for informational purposes
only, and PDF consumer applications are free to disregard it. In particular, there
is no expectation that PDF production tools will automatically convert colors
expressed in the same source color space to the specified target space before gen-
erating output. (In some workflows, such conversion may, in fact, be undesirable.
For example, when working with CMYK source colors tagged with a source ICC
profile solely for purposes of characterization, converting such colors from four
components to three and back is unnecessary and will result in a loss of fidelity in
the values of the black component; see “Implicit Conversion of CIE-Based Color
Spaces” on page 228 for further discussion.) On the other hand, when source
colors are expressed in different base color spaces—for example, when combining
separately generated images on the same PDF page—it is possible (though not re-
quired) to use the destination profile specified in the output intent dictionary to
DestOutputProfile
stream (Required if OutputConditionIdentifier does not specify a standard
production condition; optional otherwise) An ICC profile stream
defining the transformation from the PDF document’s source
colors to output device colorants.
The format of the profile stream is the same as that used in spec-
ifying an
ICCBased color space (see “ICCBased Color Spaces” on
page 222). The output transformation uses the profile’s “from
CIE” information (BToA in ICC terminology); the “to CIE”
(AToB ) information can optionally be used to remap source
color values to some other destination color space, such as for
screen preview or hardcopy proofing. (See implementation note
162 in Appendix H.)
KEY TYPE VALUE
Prepress SupportSECTION 10.10
901
convert source colors to the same target color space. (See implementation note
163 in Appendix H.)
Example 10.26 shows a PDF/X output intent dictionary based on an industry-
standard production condition (
CGATS TR 001) from the ICC Characterization
Data Registry. Example 10.27 shows one for a custom production condition.
Example 10.26
<< /Type /OutputIntent % Output intent dictionary
/S /GTS_PDFX
/OutputCondition (CGATS TR 001 (SWOP ))
/OutputConditionIdentifier (CGATS TR 001)
/RegistryName (http://www.color.org)
/DestOutputProfile 100 0 R
>>
100 0 obj % ICC profile stream
<< /N 4
/Length 1605
/Filter /ASCIIHexDecode
>>
stream
00 00 02 0C 61 70 … >
endstream
endobj
Example 10.27
<< /Type /OutputIntent % Output intent dictionary
/S /GTS_PDFX
/OutputCondition (Coated)
/OutputConditionIdentifier (Custom)
/Info (Coated 150lpi)
/DestOutputProfile 100 0 R
>>
100 0 obj % ICC profile stream
<< /N 4
/Length 1605
/Filter /ASCIIHexDecode
>>
Document InterchangeCHAPTER 10
902
stream
00 00 02 0C 61 70 … >
endstream
endobj
10.10.5 Trapping Support
On devices such as offset printing presses, which mark multiple colorants on a
single sheet of physical medium, mechanical limitations of the device can cause
imprecise alignment, or misregistration, between colorants. This can produce
unwanted visual artifacts such as brightly colored gaps or bands around the edges
of printed objects. In high-quality reproduction of color documents, such arti-
facts are commonly avoided by creating an overlap, called a trap, between areas of
adjacent color.
Figure 10.4 shows an example of trapping. The light and medium grays represent
two different colorants, which are used to paint the background and the glyph de-
noting the letter
A. The first figure shows the intended result, with the two colo-
rants properly registered. The second figure shows what happens when the
colorants are misregistered. In the third figure, traps have been overprinted along
the boundaries, obscuring the artifacts caused by the misregistration. (For em-
phasis, the traps are shown here in dark gray; in actual practice, their color would
be similar to one of the adjoining colors.)
FIGURE 10.4 Trapping example
Trapping can be implemented by the application generating a PDF file, by some
intermediate application that adds traps to a PDF document, or by the raster
image processor (RIP) that produces final output. In the last two cases, the trap-
Intended result Misregistration
with no trap
Misregistration
with trap
Prepress SupportSECTION 10.10
903
ping process is controlled by a set of trapping instructions, which define two kinds
of information:
• Trapping zones within which traps should be created
• Trapping parameters specifying the nature of the traps within each zone
Trapping zones and trapping parameters are discussed fully in Sections 6.3.2 and
6.3.3, respectively, of the PostScript Language Reference, Third Edition. Trapping
instructions are not directly specified in a PDF file (as they are in a PostScript
file). Instead, they are specified in a job ticket that accompanies the PDF file or
can be embedded within it. Various standards exist for the format of job tickets;
two of them, JDF (Job Definition Format) and PJTF (Portable Job Ticket Format),
are described in the CIP4 document JDF Specification and in Adobe Technical
Note #5620, Portable Job Ticket Format (see the Bibliography).
When trapping is performed before the production of final output, the resulting
traps are placed in the PDF file for subsequent use. The traps themselves are
described as a content stream in a trap network annotation (see below). The
stream dictionary can include additional entries describing the method that was
used to produce the traps and other information about their appearance.
Trap Network Annotations
A complete set of traps generated for a given page under a specified set of trap-
ping instructions is called a trap network (PDF 1.3). It is a form XObject contain-
ing graphics objects for painting the required traps on the page. A page may have
more than one trap network based on different trapping instructions, presumably
intended for different output devices. All of the trap networks for a given page are
contained in a single trap network annotation (see Section 8.4, “Annotations”).
There can be at most one trap network annotation per page, which must be the
last element in the page’s
Annots array (see “Page Objects” on page 119). This en-
sures that the trap network is printed after all of the page’s other contents. (See
implementation note 164 in Appendix H.)
The form XObject defining a trap network is specified as an appearance stream in
the
N (normal) entry of the trap network annotation’s appearance dictionary (see
Section 8.4.4, “Appearance Streams”). If more than one trap network is defined
for the same page, the
N entry holds a subdictionary containing the alternate trap
networks, each identified by an arbitrary key. The
AS (appearance state) entry in
Document InterchangeCHAPTER 10
904
the annotation dictionary designates one of them as the current trap network to
be displayed or printed.
Note: The trap network annotation’s appearance dictionary may include
R (rollover)
or
D (down) entries, but appearances defined in either of these entries are never
printed.
Like all annotations, a trap network annotation is defined by an annotation dic-
tionary (see Section 8.4.1, “Annotation Dictionaries”); its annotation type is
TrapNet. The AP (appearances), AS (appearance state), and F (flags) entries
(which ordinarily are optional) must be present, with the Print and ReadOnly
flags set and all others clear (see Section 8.4.2, “Annotation Flags”). Table 10.51
shows the additional annotation dictionary entries specific to this type of anno-
tation.
The
Version and AnnotStates entries, if present, are used to detect changes in the
content of a page that might require regenerating its trap networks. The
Version
array identifies elements of the page’s content that might be changed by an editing
application and thus invalidate its trap networks. Because there is at most one
Version array per trap network annotation (and thus per page), any application
generating a new trap network must also verify the validity of existing trap net-
works by enumerating the objects identified in the array and verifying that the
results exactly match the array’s current contents. Any trap networks found to be
invalid must be regenerated. (See implementation notes 165 and 166 in Appendix
H.)
Beginning with PDF 1.4, the
LastModified entry can be used in place of the
Version array to track changes to a page’s trap network. (The trap network anno-
tation must include either a
LastModified entry or the combination of Version
and AnnotStates, but not all three.) If the modification date in the LastModified
entry of the page object (see “Page Objects” on page 119) is more recent than the
one in the trap network annotation dictionary, the page’s trap networks are in-
valid and must be regenerated. Note, however, that not all editing applications
and plug-in extensions correctly maintain these modification dates. This method
of tracking trap network modifications can be used reliably only in a controlled
workflow environment where the integrity of the modification dates is assured.
Prepress SupportSECTION 10.10
905
TABLE 10.51 Additional entries specific to a trap network annotation
Trap Network Appearances
Each entry in the N (normal) subdictionary of a trap network annotation’s
appearance dictionary holds an appearance stream defining a trap network asso-
KEY TYPE VALUE
Subtype
name (Required) The type of annotation that this dictionary describes; must be
TrapNet for a trap network annotation.
LastModified
date (Required if Version and AnnotStates are absent; must be absent if Version and
AnnotStates are present; PDF 1.4) The date and time (see Section 3.8.3,
“Dates”) when the trap network was most recently modified.
Version
array (Required if AnnotStates is present; must be absent if LastModified is present)
An unordered array of all objects present in the page description at the time
the trap networks were generated and that, if changed, could affect the
appearance of the page. If present, the array must include the following
objects:
• All content streams identified in the page object’s Contents entry (see
“Page Objects” on page 119)
• All resource objects (other than procedure sets) in the page’s resource dic-
tionary (see Section 3.7.2, “Resource Dictionaries”)
• All resource objects (other than procedure sets) in the resource dictionar-
ies of any form XObjects on the page (see Section 4.9, “Form XObjects”)
• All OPI dictionaries associated with XObjects on the page (see Section
10.10.6, “Open Prepress Interface (OPI)”)
AnnotStates
array (Required if Version is present; must be absent if LastModified is present) An
array of name objects representing the appearance states (value of the
AS
entry) for annotations associated with the page. The appearance states must
be listed in the same order as the annotations in the page’s
Annots array (see
“Page Objects” on page 119). For an annotation with no
AS entry, the corre-
sponding array element should be
null. No appearance state should be
included for the trap network annotation itself.
FontFauxing
array (Optional) An array of font dictionaries representing fonts that were fauxed
(replaced by substitute fonts) during the generation of trap networks for the
page.
Document InterchangeCHAPTER 10
906
ciated with the given page. Like all appearances, a trap network is a stream object
defining a form XObject (see Section 4.9, “Form XObjects”). The body of the
stream contains the graphics objects needed to paint the traps making up the trap
network. Its dictionary entries include, besides the standard entries for a form
dictionary, the additional entries shown in Table 10.52.
TABLE 10.52 Additional entries specific to a trap network appearance stream
Note: Preseparated PDF files (see Section 10.10.3, “Separation Dictionaries”) can-
not be trapped because traps are defined along the borders between different colors
and a preseparated file uses only one color. Preseparation must therefore occur after
trapping, not before. An application preseparating a trapped PDF file is responsible
for calculating new
Version arrays for the separated trap networks.
KEY TYPE VALUE
PCM
name (Required) The name of the process color model that was assumed
when this trap network was created; equivalent to the PostScript
page device parameter
ProcessColorModel (see Section 6.2.5 of the
PostScript Language Reference, Third Edition). Valid values are
DeviceGray, DeviceRGB, DeviceCMYK, DeviceCMY, DeviceRGBK,
and
DeviceN.
SeparationColorNames
array (Optional) An array of names identifying the colorants that were
assumed when this network was created; equivalent to the Post-
Script page device parameter of the same name (see Section 6.2.5 of
the PostScript Language Reference, Third Edition). Colorants im-
plied by the process color model
PCM are available automatically
and need not be explicitly declared. If this entry is absent, the colo-
rants implied by
PCM are assumed.
TrapRegions
array (Optional) An array of indirect references to TrapRegion objects
defining the page’s trapping zones and the associated trapping
parameters, as described in Adobe Technical Note #5620, Portable
Job Ticket Format. These references are to objects comprising
portions of a PJTF job ticket that is embedded in the PDF file.
When the trapping zones and parameters are defined by an external
job ticket (or by some other means, such as with JDF), this entry is
absent.
TrapStyles
text string (Optional) A human-readable text string that applications can use
to describe this trap network to the user (for example, to allow
switching between trap networks).
Prepress SupportSECTION 10.10
907
10.10.6 Open Prepress Interface (OPI)
The workflow in a prepress environment often involves multiple applications in
areas such as graphic design, page layout, word processing, photo manipulation,
and document construction. As pieces of the final document are moved from one
application to another, it is useful to separate the data of high-resolution images,
which can be quite large—in some cases, many times the size of the rest of the
document combined—from that of the document itself. The Open Prepress Inter-
face (OPI) is a mechanism, originally developed by Aldus
®
Corporation, for cre-
ating low-resolution placeholders, or proxies, for such high-resolution images.
The proxy typically consists of a downsampled version of the full-resolution
image, to be used for screen display and proofing. Before the document is print-
ed, it passes through a filter known as an OPI server, which replaces the proxies
with the original full-resolution images.
In PostScript programs, OPI proxies are defined by PostScript code surrounded
by special OPI comments, which specify such information as the placement and
cropping of the image and adjustments to its size, rotation, color, and other
attributes. In PDF, proxies are embedded in a document as image or form
XObjects with an associated OPI dictionary (PDF 1.2) containing the same infor-
mation conveyed in PostScript by the OPI comments. Two versions of OPI are
supported, versions 1.3 and 2.0. In OPI 1.3, a proxy consisting of a single image,
with no changes in the graphics state, may be represented as an image XObject;
otherwise it must be a form XObject. In OPI 2.0, the proxy always entails changes
in the graphics state and hence must be represented as a form XObject. (See
implementation notes 167 and 168 in Appendix H.)
An XObject representing an OPI proxy must contain an
OPI entry in its image or
form dictionary (see Table 4.39 on page 310 and Table 4.45 on page 328). The val-
ue of this entry is an OPI version dictionary (Table 10.53) identifying the version
of OPI to which the proxy corresponds. This dictionary consists of a single entry,
whose key is the name
1.3 or 2.0 and whose value is the OPI dictionary defining
the proxy’s OPI attributes.
TABLE 10.53 Entry in an OPI version dictionary
KEY TYPE VALUE
version number
dictionary (Required; PDF 1.2) An OPI dictionary specifying the attributes of this proxy
(see Tables 10.54 and 10.55). The key for this entry must be the name
1.3 or
2.0, identifying the version of OPI to which the proxy corresponds.
Document InterchangeCHAPTER 10
908
Note: As in any other PDF dictionary, the key in an OPI version dictionary must be
a name object. The OPI version dictionary would thus be written in the PDF file in
either the form
<< /1.3 d 0 R >> % OPI 1.3 dictionary
or
<< /2.0 d 0 R >> % OPI 2.0 dictionary
where d is the object number of the corresponding OPI dictionary.
Tables 10.54 and 10.55 describe the contents of the OPI dictionaries for OPI 1.3
and OPI 2.0, respectively, along with the corresponding PostScript OPI com-
ments. The dictionary entries are listed in the order in which the corresponding
OPI comments should appear in a PostScript program. Complete details on the
meanings of these entries and their effects on OPI servers can be found in OPI:
Open Prepress Interface Specification 1.3 (available from Adobe) and Adobe Tech-
nical Note #5660, Open Prepress Interface (OPI) Specification, Version 2.0.
TABLE 10.54 Entries in a version 1.3 OPI dictionary
KEY TYPE OPI COMMENT VALUE
Type
name (Optional) The type of PDF object that this dic-
tionary describes; if present, must be
OPI for an
OPI dictionary.
Version
number (Required) The version of OPI to which this dic-
tionary refers; must be the number 1.3 (not the
name
1.3, as in an OPI version dictionary).
F
file speci-
fication
%ALDImageFilename
(Required) The external file containing the im-
age corresponding to this proxy. (See implemen-
tation note 169 in Appendix H.)
ID
string
%ALDImageID
(Optional) An identifying string denoting the
image.
Comments
text string
%ALDObjectComments
(Optional) A human-readable comment, typical-
ly containing instructions or suggestions to the
operator of the OPI server on how to handle the
image.
Prepress SupportSECTION 10.10
909
Size
array
%ALDImageDimensions
(Required) An array of two integers of the form
[pixelsWide pixelsHigh]
specifying the dimensions of the image in pixels.
CropRect
rectangle
%ALDImageCropRect
(Required) An array of four integers of the form
[left top right bottom]
specifying the portion of the image to be used.
CropFixed
array
%ALDImageCropFixed
(Optional) An array with the same form and
meaning as
CropRect, but expressed in real
numbers instead of integers. Default value: the
value of
CropRect.
Position
array
%ALDImagePosition
(Required) An array of eight numbers of the
form
[ll
x
ll
y
ul
x
ul
y
ur
x
ur
y
lr
x
lr
y
]
specifying the location on the page of the
cropped image, where (
ll
x
, ll
y
) are the user space
coordinates of the lower-left corner, (
ul
x
, ul
y
) are
those of the upper-left corner, (
ur
x
, ur
y
) are
those of the upper-right corner, and (
lr
x
, lr
y
) are
those of the lower-right corner. The specified
coordinates must define a parallelogram; that is,
they must satisfy the conditions
ul
x
ll
x
= ur
x
lr
x
and
ul
y
ll
y
= ur
y
lr
y
The combination of Position and CropRect de-
termines the image’s scaling, rotation, reflection,
and skew.
Resolution
array
%ALDImageResolution
(Optional) An array of two numbers of the form
[horizRes vertRes]
specifying the resolution of the image in samples
per inch.
KEY TYPE OPI COMMENT VALUE
Document InterchangeCHAPTER 10
910
ColorType
name
%ALDImageColorType
(Optional) The type of color specified by the
Color entry. Valid values are Process, Spot, and
Separation. Default value: Spot.
Color
array
%ALDImageColor
(Optional) An array of four numbers and a
string of the form
[C M Y K colorName]
specifying the value and name of the color in
which the image is to be rendered. The values of
C, M, Y, and K must all be in the range 0.0 to 1.0.
Default value:
[0.0 0.0 0.0 1.0 (Black)].
Tint
number
%ALDImageTint
(Optional) A number in the range 0.0 to 1.0
specifying the concentration of the color speci-
fied by
Color in which the image is to be ren-
dered. Default value: 1.0.
Overprint
boolean
%ALDImageOverprint
(Optional) A flag specifying whether the image
is to overprint (
true) or knock out (false) under-
lying marks on other separations. Default value:
false.
ImageType
array
%ALDImageType
(Optional) An array of two integers of the form
[samples bits]
specifying the number of samples per pixel and
bits per sample in the image.
GrayMap
array
%ALDImageGrayMap
(Optional) An array of 2
n
integers in the range 0
to 65,535 (where n is the number of bits per
sample) recording changes made to the bright-
ness or contrast of the image.
Transparency
boolean
%ALDImageTransparency
(Optional) A flag specifying whether white pix-
els in the image are to be treated as transparent.
Default value:
true.
KEY TYPE OPI COMMENT VALUE
Prepress SupportSECTION 10.10
911
TABLE 10.55 Entries in a version 2.0 OPI dictionary
Tags
array
%ALDImageAsciiTag<NNN>
(Optional) An array of pairs of the form
[tagNum
1
tagText
1
… tagNum
n
tagText
n
]
where each tagNum is an integer representing a
TIFF tag number and each
tagText is a string
representing the corresponding ASCII tag value.
KEY TYPE OPI COMMENT VALUE
Type
name (Optional) The type of PDF object that this dic-
tionary describes; if present, must be
OPI for an
OPI dictionary.
Version
number (Required) The version of OPI to which this dic-
tionary refers; must be the number 2 or 2.0 (not
the name
2.0, as in an OPI version dictionary).
F
file speci-
fication
%%ImageFilename
(Required) The external file containing the low-
resolution proxy image. (See implementation
note 169 in Appendix H.)
MainImage
string
%%MainImage
(Optional) The pathname of the file containing
the full-resolution image corresponding to this
proxy, or any other identifying string that
uniquely identifies the full-resolution image.
Tags
array
%%TIFFASCIITag
(Optional) An array of pairs of the form
[tagNum
1
tagText
1
… tagNum
n
tagText
n
]
where each tagNum is an integer representing a
TIFF tag number and each
tagText is a string or
an array of strings representing the correspond-
ing ASCII tag value.
Size
array
%%ImageDimensions
(Optional; see note below) An array of two num-
bers of the form
[width height ]
specifying the dimensions of the image in pixels.
KEY TYPE OPI COMMENT VALUE
Document InterchangeCHAPTER 10
912
CropRect
rectangle
%%ImageCropRect
(Optional; see note below) An array of four num-
bers of the form
[left top right bottom]
specifying the portion of the image to be used.
Note: The
Size and CropRect entries should either
both be present or both be absent. If present, they
must satisfy the conditions
0 left < right width
and
0 top < bottom height
Note that in this coordinate space, the positive y
axis extends vertically downward; hence, the
requirement that
top
<
bottom.
Overprint
boolean
%%ImageOverprint
(Optional) A flag specifying whether the image
is to overprint (
true) or knock out (false) under-
lying marks on other separations. Default value:
false.
Inks
name or
array
%%ImageInks
(Optional) A name object or array specifying the
colorants to be applied to the image. The value
may be the name
full_color or registration or an
array of the form
[/monochrome name
1
tint
1
… name
n
tint
n
]
where each name is a string representing the
name of a colorant and each
tint is a real number
in the range 0.0 to 1.0 specifying the concentra-
tion of that colorant to be applied.
IncludedImageDimensions
array
%%IncludedImageDimensions
(Optional) An array of two integers of the form
[pixelsWide pixelsHigh]
specifying the dimensions of the included image
in pixels.
IncludedImageQuality
number %%IncludedImageQuality (Optional) A number indicating the quality of
the included image. Valid values are 1, 2, and 3.
KEY TYPE OPI COMMENT VALUE
913
APPENDIX A
AOperator Summary
This appendix lists, in alphabetical order, all the operators used in PDF content
streams. Table A.1 lists each operator, its corresponding PostScript language op-
erators (when it is an exact or near-exact equivalent of the PDF operator), a de-
scription of the operator, and references to the table and page where each
operator is introduced.
TABLE A.1 PDF content stream operators
OPERATOR
POSTSCRIPT
EQUIVALENT DESCRIPTION TABLE PAGE
b closepath, fill,
stroke
Close, fill, and stroke path using nonzero winding number
rule
4.10 200
B fill, stroke Fill and stroke path using nonzero winding number rule 4.10 200
b* closepath, eofill,
stroke
Close, fill, and stroke path using even-odd rule 4.10 200
B* eofill, stroke Fill and stroke path using even-odd rule 4.10 200
BDC (PDF 1.2) Begin marked-content sequence with property list 10.7 779
BI Begin inline image object 4.42 322
BMC (PDF 1.2) Begin marked-content sequence 10.7 779
BT Begin text object 5.4 375
BX (PDF 1.1) Begin compatibility section 3.29 127
ccurvetoAppend curved segment to path (three control points) 4.9 196
cm concat Concatenate matrix to current transformation matrix 4.7 189
Operator SummaryAPPENDIX A
914
CS setcolorspace (PDF 1.1) Set color space for stroking operations 4.24 257
cs setcolorspace (PDF 1.1) Set color space for nonstroking operations 4.24 257
d setdash Set line dash pattern 4.7 189
d0 setcharwidth Set glyph width in Type 3 font 5.10 392
d1 setcachedevice Set glyph width and bounding box in Type 3 font 5.10 393
Do Invoke named XObject 4.37 302
DP (PDF 1.2) Define marked-content point with property list 10.7 779
EI End inline image object 4.42 322
EMC (PDF 1.2) End marked-content sequence 10.7 779
ET End text object 5.4 375
EX (PDF 1.1) End compatibility section 3.29 127
f fill Fill path using nonzero winding number rule 4.10 200
F fill Fill path using nonzero winding number rule (obsolete) 4.10 200
f* eofill Fill path using even-odd rule 4.10 200
G setgray Set gray level for stroking operations 4.24 258
g setgray Set gray level for nonstroking operations 4.24 258
gs (PDF 1.2) Set parameters from graphics state parameter
dictionary
4.7 189
h closepath Close subpath 4.9 197
i setflat Set flatness tolerance 4.7 189
ID Begin inline image data 4.42 322
j setlinejoin Set line join style 4.7 189
J setlinecap Set line cap style 4.7 189
K setcmykcolor Set CMYK color for stroking operations 4.24 258
OPERATOR
POSTSCRIPT
EQUIVALENT DESCRIPTION TABLE PAGE
Operator SummaryAPPENDIX A
915
k setcmykcolor Set CMYK color for nonstroking operations 4.24 258
l lineto Append straight line segment to path 4.9 196
m moveto Begin new subpath 4.9 196
M setmiterlimit Set miter limit 4.7 189
MP (PDF 1.2) Define marked-content point 10.7 779
n End path without filling or stroking 4.10 200
qgsaveSave graphics state 4.7 189
Q grestore Restore graphics state 4.7 189
re Append rectangle to path 4.9 197
RG setrgbcolor Set RGB color for stroking operations 4.24 258
rg setrgbcolor Set RGB color for nonstroking operations 4.24 258
ri Set color rendering intent 4.7 189
s closepath,
stroke
Close and stroke path 4.10 200
S stroke Stroke path 4.10 200
SC setcolor (PDF 1.1) Set color for stroking operations 4.24 257
sc setcolor (PDF 1.1) Set color for nonstroking operations 4.24 258
SCN setcolor (PDF 1.2) Set color for stroking operations (ICCBased and
special color spaces)
4.24 258
scn setcolor (PDF 1.2) Set color for nonstroking operations (ICCBased
and special color spaces)
4.24 258
sh shfill (PDF 1.3) Paint area defined by shading pattern 4.27 273
T* Move to start of next text line 5.5 376
Tc Set character spacing 5.2 368
Td Move text position 5.5 376
OPERATOR
POSTSCRIPT
EQUIVALENT DESCRIPTION TABLE PAGE
Operator SummaryAPPENDIX A
916
TD Move text position and set leading 5.5 376
Tf selectfont Set text font and size 5.2 368
Tj show Show text 5.6 377
TJ Show text, allowing individual glyph positioning 5.6 378
TL Set text leading 5.2 368
Tm Set text matrix and text line matrix 5.5 376
Tr Set text rendering mode 5.2 368
Ts Set text rise 5.2 368
Tw Set word spacing 5.2 368
Tz Set horizontal text scaling 5.2 368
vcurvetoAppend curved segment to path (initial point replicated) 4.9 196
w setlinewidth Set line width 4.7 189
W clip Set clipping path using nonzero winding number rule 4.11 205
W* eoclip Set clipping path using even-odd rule 4.11 205
ycurvetoAppend curved segment to path (final point replicated) 4.9 196
' Move to next line and show text 5.6 377
" Set word and character spacing, move to next line, and
show text
5.6 377
OPERATOR
POSTSCRIPT
EQUIVALENT DESCRIPTION TABLE PAGE
917
APPENDIX B
BOperators in Type 4
Functions
This appendix summarizes the PostScript operators that can appear in a type 4
function, as discussed in Section 3.9.4, “Type 4 (PostScript Calculator) Func-
tions.” For details on these operators, see the PostScript Language Reference, Third
Edition.
B.1 Arithmetic Operators
num
1
num
2
add sum Return num
1
plus num
2
num
1
num
2
sub difference Return num
1
minus num
2
num
1
num
2
mul product Return num
1
times num
2
num
1
num
2
div quotient Return num
1
divided by num
2
int
1
int
2
idiv quotient Return int
1
divided by int
2
as an integer
int
1
int
2
mod remainder Return remainder after dividing int
1
by int
2
num
1
neg num
2
Return negative of num
1
num
1
abs num
2
Return absolute value of num
1
num
1
ceiling num
2
Return ceiling of num
1
num
1
floor num
2
Return floor of num
1
num
1
round num
2
Round num
1
to nearest integer
num
1
truncate num
2
Remove fractional part of num
1
num sqrt real Return square root of num
angle sin real
Return sine of angle degrees
angle cos real Return cosine of angle degrees
num den atan angle Return arc tangent of num/den in degrees
base exponent exp real Raise base to exponent power
num ln real Return natural logarithm (base e)
num log real Return common logarithm (base 10)
num cvi int Convert to integer
num cvr real Convert to real
Operators in Type 4 FunctionsAPPENDIX B
918
B.2 Relational, Boolean, and Bitwise Operators
any
1
any
2
eq bool Test equal
any
1
any
2
ne bool Test not equal
num
1
num
2
gt bool Test greater than
num
1
num
2
ge bool Test greater than or equal
num
1
num
2
lt bool Test less than
num
1
num
2
le bool Test less than or equal
bool
1
|int
1
bool
2
|int
2
and bool
3
|int
3
Perform logical|bitwise and
bool
1
|int
1
bool
2
|int
2
or bool
3
|int
3
Perform logical|bitwise inclusive or
bool
1
|int
1
bool
2
|int
2
xor bool
3
|int
3
Perform logical|bitwise exclusive or
bool
1
|int
1
not bool
2
|int
2
Perform logical|bitwise not
int
1
shift bitshift int
2
Perform bitwise shift of int
1
(positive is left)
– true true Return boolean value true
– false false Return boolean value false
B.3 Conditional Operators
bool {expr} if – Execute expr if bool is true
bool {expr
1
}{expr
2
} ifelse – Execute expr
1
if bool is true, expr
2
if false
B.4 Stack Operators
any pop – Discard top element
any
1
any
2
exch any
2
any
1
Exchange top two elements
any dup any any Duplicate top element
any
1
… any
n
n copy any
1
… any
n
any
1
… any
n
Duplicate top n elements
any
n
… any
0
n index any
n
… any
0
any
n
Duplicate arbitrary element
any
n
1
… any
0
njroll any
(
j
1
) mod
n
… any
0
any
n
1
… any
j
mod
n
Roll n elements up j times
919
APPENDIX C
CImplementation Limits
In general, PDF does not restrict the size or quantity of things described in the
file format, such as numbers, arrays, images, and so on. However, a PDF consum-
er application running on a particular processor and in a particular operating en-
vironment does have such limits. If an application attempts to perform an action
that exceeds one of the limits, it displays an error.
PostScript interpreters also have implementation limits, listed in Appendix B of
the PostScript Language Reference, Third Edition. It is possible to construct a PDF
file that does not violate application limits but does not print on a PostScript
printer. Keep in mind that these limits vary according to the PostScript Lan-
guageLevel, interpreter version, and the amount of memory available to the inter-
preter.
This appendix describes typical limits for Acrobat. These limits fall into two main
classes:
• Architectural limits. The hardware on which a viewer application executes im-
poses certain constraints. For example, an integer is usually represented in 32
bits, limiting the range of allowed integers. In addition, the design of the soft-
ware imposes other constraints, such as a limit to the number of elements in an
array or string.
• Memory limits. The amount of memory available to a viewer application limits
the number of memory-consuming objects that can be held simultaneously.
PDF itself has one architectural limit: Because ten digits are allocated to byte off-
sets, the size of a file is limited to 10
10
bytes (approximately 10 gigabytes).
Table C.1 describes the architectural limits for Acrobat viewer applications run-
ning on 32-bit machines. Because Acrobat implementations are subject to these
Implementation LimitsAPPENDIX C
920
limits, applications producing PDF files are strongly advised to remain within
them. Note, however, that memory limits are often exceeded before architectural
limits (such as the limit on the number of indirect objects) are reached.
TABLE C.1 Architectural limits
QUANTITY LIMIT DESCRIPTION
integer 2,147,483,647 Largest integer value; equal to 2
31
1.
-2,147,483,648 Smallest integer value; equal to 2
31
.
real ±3.403 × 10
38
Largest and smallest real values (approximate).
±1.175 × 10
38
Nonzero real values closest to 0 (approximate). Values closer
than these are automatically converted to 0.
5 Number of significant decimal digits of precision in fractional
part (approximate).
Note: To represent real numbers, Acrobat 6 uses IEEE single-precision floating-point
numbers, as described in the IEEE Standard for Binary Floating-Point Arithmetic (see
the Bibliography). Previous versions used 32-bit fixed-point numbers (16 bits on either
side of the radix point), which have greater precision but a much smaller range than
IEEE floating-point numbers. (Acrobat 6 still converts floating-point numbers to fixed
point for some components, such as screen display and fonts.)
string (in content
stream)
32,767 Maximum length of a string, in bytes.
Note: This restriction applies only to strings in content streams.
There is no effective restriction on other strings in PDF files.
name 127 Maximum length of a name, in bytes.
indirect object 8,388,607 Maximum number of indirect objects in a PDF file.
q/Q nesting 28 Maximum depth of graphics state nesting by q and Q operators.
(This is not a limit of Acrobat as such, but arises from the fact
that
q and Q are implemented by the PostScript gsave and gre-
store
operators when generating PostScript output; see imple-
mentation note 170 in Appendix H.)
DeviceN
components 32 Maximum number of colorants or tint components in a DeviceN
color space.
CID 65,535 Maximum value of a CID (character identifier).
Implementation LimitsAPPENDIX C
921
Acrobat has some additional architectural limits:
• Thumbnail images may be no larger than 106 by 106 samples, and should be
created at one-eighth scale for 8.5-by-11-inch and A4-size pages.
• The minimum allowed page size is 3 by 3 units in default user space; the maxi-
mum is 14,400 by 14,400 units. In versions of PDF earlier than 1.6 (Acrobat
7.0), the size of the default user space unit was fixed at 1⁄72 inch, yielding a
minimum of approximately 0.04 by 0.04 inch and a maximum of 200 by 200
inches. Beginning with PDF 1.6, the size of the unit may be set on a page-by-
page basis; the default remains at 1/72 inch. (See implementation note 171 in
Appendix H.)
• The magnification factor of a view is constrained to be between approximately
8 percent and 3200 percent. These limits are not fixed; they vary with the size of
the page being displayed, as well as with the size of the pages previously viewed
within the file.
• When Acrobat reads a PDF file with a damaged or missing cross-reference
table, it attempts to rebuild the table by scanning all the objects in the file.
However, the generation numbers of deleted entries are lost if the cross-
reference table is missing or severely damaged. Reconstruction fails if any ob-
ject identifiers do not appear at the start of a line or if the
endobj keyword does
not appear at the start of a line. Also, reconstruction fails if a stream contains a
line beginning with the word
endstream, aside from the required endstream
that delimits the end of the stream.
Memory limits cannot be characterized as precisely as architectural limits because
the amount of available memory and the ways in which it is allocated vary from
one product to another. Memory is automatically reallocated from one use to an-
other when necessary: when more memory is needed for a particular purpose, it
can be taken from memory allocated to another purpose if that memory is cur-
rently unused or its use is nonessential (a cache, for example). Also, data is often
saved to a temporary file when memory is limited. Because of this behavior, it is
not possible to state limits for such items as the number of pages in a document,
number of text annotations or hypertext links on a page, number of graphics ob-
jects on a page, or number of fonts on a page or in a document.
Implementation LimitsAPPENDIX C
922
923
APPENDIX D
DCharacter Sets and
Encodings
This appendix lists the character sets and encodings that are assumed to be pre-
defined in any PDF consumer application. Only simple fonts, encompassing
Latin text and some symbols, are described here. See “Predefined CMaps” on
page 412 for a list of predefined CMaps for CID-keyed fonts.
Section D.1, “Latin Character Set and Encodings,” describes the entire character
set for the Adobe standard Latin-text fonts. This character set is supported by the
Times, Helvetica, and Courier font families, which are among the standard 14
predefined fonts (see “Standard Type 1 Fonts” on page 385). For each named
character, an octal character code is given in four different encodings:
Standard-
Encoding
, MacRomanEncoding, WinAnsiEncoding, and PDFDocEncoding (see
Table D.1). Unencoded characters are indicated by a dash (—).
Section D.2, “Expert Set and MacExpertEncoding,” describes the so-called
“expert” character set, which contains additional characters useful for sophisti-
cated typography, such as small capitals, ligatures, and fractions. For each named
character, an octal character code is given in
MacExpertEncoding. Note that the
built-in encoding in an expert font program is usually different from
MacEx-
pertEncoding
.
Sections D.3, “Symbol Set and Encoding,” and D.4, “ZapfDingbats Set and Encod-
ing,” describe the character sets and built-in encodings for the
Symbol and
ZapfDingbats (ITC Zapf Dingbats) font programs, which are among the standard
14 predefined fonts. These fonts have built-in encodings that are unique to each
font. (The characters for
ZapfDingbats are ordered by code instead of by name,
since the names in that font are meaningless.)
Character Sets and EncodingsAPPENDIX D
924
TABLE D.1 Latin-text encodings
ENCODING DESCRIPTION
StandardEncoding Adobe standard Latin-text encoding. This is the built-in encoding
defined in Type 1 Latin-text font programs (but generally not in
TrueType font programs). PDF does not have a predefined encod-
ing named
StandardEncoding. However, it is useful to describe
this encoding, since a font’s built-in encoding can be used as the
base encoding from which differences are specified in an encod-
ing dictionary.
MacRomanEncoding Mac OS standard encoding for Latin text in Western writing sys-
tems. PDF has a predefined encoding named
MacRomanEncoding
that can be used with both Type 1 and TrueType fonts.
WinAnsiEncoding Windows Code Page 1252, often called the “Windows ANSI”
encoding. This is the standard Windows encoding for Latin text in
Western writing systems. PDF has a predefined encoding named
WinAnsiEncoding that can be used with both Type 1 and True-
Type fonts.
PDFDocEncoding Encoding for text strings in a PDF document outside the docu-
ment’s content streams. This is one of two encodings (the other
being Unicode) that can be used to represent text strings; see Sec-
tion 3.8.1, “Text Strings.” PDF does not have a predefined encod-
ing named
PDFDocEncoding; it is not customary to use this
encoding to show text from fonts.
MacExpertEncoding An encoding for use with expert fonts—ones containing the
expert character set. PDF has a predefined encoding named
MacExpertEncoding. Despite its name, it is not a platform-specific
encoding; however, only certain fonts have the appropriate char-
acter set for use with this encoding. No such fonts are among the
standard 14 predefined fonts.
Latin Character Set and EncodingsSECTION D.1
925
D.1 Latin Character Set and Encodings
CHAR CODE (OCTAL) CHAR CODE (OCTAL)
CHAR NAME STD MAC WIN PDF CHAR NAME STD MAC WIN PDF
A A 101 101 101 101
Æ
AE 341 256 306 306
Á Aacute — 347 301 301
 Acircumflex — 345 302 302
Ä Adieresis — 200 304 304
À Agrave — 313 300 300
Å Aring — 201 305 305
à Atilde — 314 303 303
B B 102 102 102 102
C C 103 103 103 103
Ç Ccedilla — 202 307 307
D D 104 104 104 104
E E 105 105 105 105
É Eacute — 203 311 311
Ê Ecircumflex — 346 312 312
Ë Edieresis — 350 313 313
È Egrave — 351 310 310
Ð Eth — — 320 320
€ Euro
1
— — 200 240
F F 106 106 106 106
G G 107 107 107 107
H H 110 110 110 110
I I 111 111 111 111
Í Iacute — 352 315 315
Î Icircumflex — 353 316 316
Ï Idieresis — 354 317 317
Ì Igrave — 355 314 314
J J 112 112 112 112
K K 113 113 113 113
L L 114 114 114 114
Ł Lslash 350 — — 225
M M 115 115 115 115
N N 116 116 116 116
Ñ Ntilde — 204 321 321
O O 117 117 117 117
ΠOE 352 316 214 226
Ó Oacute — 356 323 323
Ô Ocircumflex — 357 324 324
Ö Odieresis — 205 326 326
Ò Ograve — 361 322 322
Ø Oslash 351 257 330 330
Õ Otilde — 315 325 325
P P 120 120 120 120
Q Q 121 121 121 121
R R 122 122 122 122
S S 123 123 123 123
Š Scaron — — 212 227
T T 124 124 124 124
Þ Thorn — — 336 336
U U 125 125 125 125
Ú Uacute — 362 332 332
Û Ucircumflex — 363 333 333
Ü Udieresis — 206 334 334
Ù Ugrave — 364 331 331
V V 126 126 126 126
W W 127 127 127 127
X X 130 130 130 130
Y Y 131 131 131 131
Ý Yacute — — 335 335
Ÿ Ydieresis — 331 237 230
Z Z 132 132 132 132
Ž Zcaron
2
— — 216 231
a a 141 141 141 141
á aacute — 207 341 341
â acircumflex — 211 342 342
´ acute 302 253 264 264
ä adieresis — 212 344 344
æ ae 361 276 346 346
à agrave — 210 340 340
& ampersand 046 046 046 046
Character Sets and EncodingsAPPENDIX D
926
CHAR CODE (OCTAL) CHAR CODE (OCTAL)
CHAR NAME STD MAC WIN PDF CHAR NAME STD MAC WIN PDF
å aring — 214 345 345
^ asciicircum 136 136 136 136
~ asciitilde 176 176 176 176
* asterisk 052 052 052 052
@ at 100 100 100 100
ã atilde — 213 343 343
b b 142 142 142 142
\ backslash 134 134 134 134
| bar 174 174 174 174
{ braceleft 173 173 173 173
} braceright 175 175 175 175
[ bracketleft 133 133 133 133
] bracketright 135 135 135 135
˘ breve 306 371 — 030
¦ brokenbar — — 246 246
• bullet
3
267 245 225 200
c c 143 143 143 143
ˇ caron 317 377 — 031
ç ccedilla — 215 347 347
¸ cedilla 313 374 270 270
¢ cent 242 242 242 242
ˆ circumflex 303 366 210 032
: colon 072 072 072 072
, comma 054 054 054 054
© copyright — 251 251 251
¤ currency
1
250 333 244 244
d d 144 144 144 144
† dagger 262 240 206 201
‡ daggerdbl 263 340 207 202
° degree — 241 260 260
¨ dieresis 310 254 250 250
÷ divide — 326 367 367
$ dollar 044 044 044 044
˙ dotaccent 307 372 — 033
ı dotlessi 365 365 — 232
e e 145 145 145 145
é eacute — 216 351 351
ê ecircumflex — 220 352 352
ë edieresis — 221 353 353
è egrave — 217 350 350
8 eight 070 070 070 070
… ellipsis 274 311 205 203
— emdash 320 321 227 204
– endash 261 320 226 205
= equal 075 075 075 075
ð eth — — 360 360
! exclam 041 041 041 041
¡ exclamdown 241 301 241 241
f f 146 146 146 146
fi fi 256 336 — 223
5 five 065 065 065 065
fl fl 257 337 — 224
ƒ florin 246 304 203 206
4 four 064 064 064 064
⁄ fraction 244 332 — 207
g g 147 147 147 147
ß germandbls 373 247 337 337
` grave 301 140 140 140
> greater 076 076 076 076
« guillemotleft
4
253 307 253 253
» guillemotright
4
273 310 273 273
‹ guilsinglleft 254 334 213 210
› guilsinglright 255 335 233 211
h h 150 150 150 150
˝ hungarumlaut 315 375 — 034
- hyphen
5
055 055 055 055
i i 151 151 151 151
í iacute — 222 355 355
î icircumflex — 224 356 356
ï idieresis — 225 357 357
ì igrave — 223 354 354
j j 152 152 152 152
k k 153 153 153 153
l l 154 154 154 154
Latin Character Set and EncodingsSECTION D.1
927
CHAR CODE (OCTAL) CHAR CODE (OCTAL)
CHAR NAME STD MAC WIN PDF CHAR NAME STD MAC WIN PDF
< less 074 074 074 074
¬ logicalnot — 302 254 254
ł lslash 370 — — 233
m m 155 155 155 155
¯ macron 305 370 257 257
− minus — — — 212
µ mu — 265 265 265
× multiply — — 327 327
n n 156 156 156 156
9 nine 071 071 071 071
ñ ntilde — 226 361 361
# numbersign 043 043 043 043
o o 157 157 157 157
ó oacute — 227 363 363
ô ocircumflex — 231 364 364
ö odieresis — 232 366 366
œ oe 372 317 234 234
˛ ogonek 316 376 — 035
ò ograve — 230 362 362
1 one 061 061 061 061
½ onehalf — — 275 275
¼ onequarter — — 274 274
¹ onesuperior — — 271 271
ª ordfeminine 343 273 252 252
º ordmasculine 353 274 272 272
ø oslash 371 277 370 370
õ otilde — 233 365 365
p p 160 160 160 160
¶ paragraph 266 246 266 266
( parenleft 050 050 050 050
) parenright 051 051 051 051
% percent 045 045 045 045
. period 056 056 056 056
· periodcentered 264 341 267 267
‰ perthousand 275 344 211 213
+ plus 053 053 053 053
± plusminus — 261 261 261
q q 161 161 161 161
? question 077 077 077 077
¿ questiondown 277 300 277 277
" quotedbl 042 042 042 042
„ quotedblbase 271 343 204 214
“ quotedblleft 252 322 223 215
” quotedblright 272 323 224 216
‘ quoteleft 140 324 221 217
’ quoteright 047 325 222 220
‚ quotesinglbase 270 342 202 221
' quotesingle 251 047 047 047
r r 162 162 162 162
® registered — 250 256 256
˚ ring 312 373 — 036
s s 163 163 163 163
š scaron — — 232 235
§ section 247 244 247 247
; semicolon 073 073 073 073
7 seven 067 067 067 067
6 six 066 066 066 066
/ slash 057 057 057 057
space
6
040 040 040 040
£ sterling 243 243 243 243
t t 164 164 164 164
þ thorn — — 376 376
3 three 063 063 063 063
¾ threequarters — — 276 276
³ threesuperior — — 263 263
˜ tilde 304 367 230 037
™ trademark — 252 231 222
2 two 062 062 062 062
² twosuperior — — 262 262
u u 165 165 165 165
ú uacute — 234 372 372
û ucircumflex — 236 373 373
ü udieresis — 237 374 374
ù ugrave — 235 371 371
Character Sets and EncodingsAPPENDIX D
928
CHAR CODE (OCTAL) CHAR CODE (OCTAL)
CHAR NAME STD MAC WIN PDF CHAR NAME STD MAC WIN PDF
1. In PDF 1.3, the euro character was added to the Adobe standard Latin character set. It
is encoded as 200 in
WinAnsiEncoding and 240 in PDFDocEncoding, assigning codes
that were previously unused. Apple changed the Mac OS Latin-text encoding for code
333 from the currency character to the euro character. However, this incompatible
change has not been reflected in PDF’s
MacRomanEncoding, which continues to map
code 333 to currency. If the euro character is desired, an encoding dictionary can be
used to specify this single difference from
MacRomanEncoding.
2. In PDF 1.3, the existing Zcaron and zcaron characters were added to
WinAnsiEncoding
as the previously unused codes 216 and 236.
3. In
WinAnsiEncoding, all unused codes greater than 40 map to the bullet character.
However, only code 225 is specifically assigned to the bullet character; other codes are
subject to future reassignment.
4. The character names guillemotleft and guillemotright are misspelled. The correct spell-
ing for this punctuation character is guillemet. However, the misspelled names are the
ones actually used in the fonts and encodings containing these characters.
5. The hyphen character is also encoded as 255 in
WinAnsiEncoding. The meaning of this
duplicate code is “soft hyphen,” but it is typographically the same as hyphen.
6. The space character is also encoded as 312 in
MacRomanEncoding and as 240 in
WinAnsiEncoding. This duplicate code signifies a nonbreaking space,; it is typographi-
cally the same as space.
This invisible paragraph references
MinionExp-Regular (1), Symbol (3), and ZapfDing-
bats
(❁), which are needed in some of the PostScript-generated tables but are not used
anywhere else in the book.
_ underscore 137 137 137 137
v v 166 166 166 166
w w 167 167 167 167
x x 170 170 170 170
y
y 171 171 171 171
ý
yacute — — 375 375
ÿ ydieresis — 330 377 377
¥ yen 245 264 245 245
z z 172 172 172 172
ž zcaron
2
— — 236 236
0 zero 060 060 060 060
Expert Set and MacExpertEncodingSECTION D.2
929
D.2 Expert Set and MacExpertEncoding
CHAR NAME CODE CHAR NAME CODE
AEsmall 276
Aacutesmall 207
Acircumflexsmall 211
Acutesmall 047
Adieresissmall 212
Agravesmall 210
Aringsmall 214
Asmall 141
Atildesmall 213
Brevesmall 363
Bsmall 142
Caronsmall 256
Ccedillasmall 215
Cedillasmall 311
Circumflexsmall 136
Csmall 143
Dieresissmall 254
Dotaccentsmall 372
Dsmall 144
Eacutesmall 216
Ecircumflexsmall 220
Edieresissmall 221
Egravesmall 217
Esmall 145
Ethsmall 104
Fsmall 146
Gravesmall 140
Gsmall 147
Hsmall 150
Hungarumlautsmall 042
Iacutesmall 222
Icircumflexsmall 224
Idieresissmall 225
Igravesmall 223
Ismall 151
Jsmall 152
Ksmall 153
Lslashsmall 302
Lsmall 154
Macronsmall 364
Msmall 155
Nsmall 156
Ntildesmall 226
OEsmall 317
Oacutesmall 227
Ocircumflexsmall 231
Odieresissmall 232
Ogoneksmall 362
Ogravesmall 230
Oslashsmall 277
Osmall 157
Otildesmall 233
Psmall 160
Qsmall 161
Ringsmall 373
Rsmall 162
Scaronsmall 247
Ssmall 163
Thornsmall 271
Tildesmall 176
Tsmall 164
Uacutesmall 234
Ucircumflexsmall 236
Udieresissmall 237
Ugravesmall 235
Usmall 165
Vsmall 166
Wsmall 167
Xsmall 170
Yacutesmall 264
Character Sets and EncodingsAPPENDIX D
930
CHAR NAME CODE CHAR NAME CODE
Ydieresissmall 330
Ysmall 171
Zcaronsmall 275
Zsmall 172
ampersandsmall 046
asuperior 201
bsuperior 365
centinferior 251
centoldstyle 043
centsuperior 202
: colon 072
₡ colonmonetary 173
, comma 054
commainferior 262
commasuperior 370
dollarinferior 266
dollaroldstyle 044
dollarsuperior 045
dsuperior 353
₈ eightinferior 245
eightoldstyle 070
⁸ eightsuperior 241
esuperior 344
exclamdownsmall 326
exclamsmall 041
ff ff 126
ffi ffi 131
ffl ffl 132
fi fi 127
‒ figuredash 320
⅝ fiveeighths 114
₅ fiveinferior 260
fiveoldstyle 065
⁵ fivesuperior 336
fl fl 130
₄ fourinferior 242
fouroldstyle 064
⁴ foursuperior 335
⁄ fraction 057
- hyphen 055
hypheninferior 137
hyphensuperior 321
isuperior 351
lsuperior 361
msuperior 367
₉ nineinferior 273
nineoldstyle 071
⁹ ninesuperior 341
ⁿ nsuperior 366
․ onedotenleader 053
⅛
oneeighth 112
onefitted 174
½ onehalf 110
₁ oneinferior 301
oneoldstyle 061
¼ onequarter 107
¹ onesuperior 332
⅓ onethird 116
osuperior 257
₍ parenleftinferior 133
⁽ parenleftsuperior 050
₎ parenrightinferior 135
⁾ parenrightsuperior 051
. period 056
periodinferior 263
periodsuperior 371
questiondownsmall 300
questionsmall 077
rsuperior 345
rupiah 175
; semicolon 073
⅞ seveneighths 115
Expert Set and MacExpertEncodingSECTION D.2
931
CHAR NAME CODE CHAR NAME CODE
₇ seveninferior 246
sevenoldstyle 067
⁷ sevensuperior 340
₆ sixinferior 244
sixoldstyle 066
⁶ sixsuperior 337
space 040
ssuperior 352
⅜ threeeighths 113
₃ threeinferior 243
threeoldstyle 063
¾ threequarters 111
threequartersemdash 075
³ threesuperior 334
tsuperior 346
‥ twodotenleader 052
₂ twoinferior 252
twooldstyle 062
² twosuperior 333
⅔ twothirds 117
₀ zeroinferior 274
zerooldstyle 060
⁰ zerosuperior 342
Character Sets and EncodingsAPPENDIX D
932
D.3 Symbol Set and Encoding
CHAR NAME CODE CHAR NAME CODE
Alpha 101
Beta 102
Chi 103
Delta 104
Epsilon 105
Eta 110
€ Euro 240
Gamma 107
Ifraktur 301
Iota 111
Kappa 113
Lambda 114
Mu 115
Nu 116
Omega 127
Omicron 117
Phi 106
Pi 120
Psi 131
Rfraktur 302
Rho 122
Sigma 123
Tau 124
Theta 121
Upsilon 125
Upsilon1 241
Xi 130
Zeta 132
aleph 300
alpha 141
& ampersand 046
angle 320
angleleft 341
angleright 361
approxequal 273
arrowboth 253
arrowdblboth 333
arrowdbldown 337
arrowdblleft 334
arrowdblright 336
arrowdblup 335
arrowdown 257
arrowhorizex 276
arrowleft 254
arrowright 256
arrowup 255
arrowvertex 275
asteriskmath 052
| bar 174
beta 142
{
braceleft 173
} braceright 175
bracelefttp 354
braceleftmid 355
braceleftbt 356
bracerighttp 374
bracerightmid 375
bracerightbt 376
braceex 357
[ bracketleft 133
] bracketright 135
bracketlefttp 351
bracketleftex 352
bracketleftbt 353
bracketrighttp 371
bracketrightex 372
bracketrightbt 373
• bullet 267
carriagereturn 277
chi 143
Symbol Set and EncodingSECTION D.3
933
CHAR NAME CODE CHAR NAME CODE
circlemultiply 304
circleplus 305
club 247
: colon 072
, comma 054
congruent 100
© copyrightsans 343
© copyrightserif 323
° degree 260
delta 144
diamond 250
÷ divide 270
dotmath 327
8 eight 070
element 316
… ellipsis 274
emptyset 306
epsilon 145
= equal 075
equivalence 272
eta 150
! exclam 041
existential 044
5 five 065
ƒ florin 246
4 four 064
⁄ fraction 244
gamma 147
gradient 321
> greater 076
greaterequal 263
heart 251
infinity 245
integral 362
integraltp 363
integralex 364
integralbt 365
intersection 307
iota 151
kappa 153
lambda 154
< less 074
lessequal 243
logicaland 331
¬ logicalnot 330
logicalor 332
lozenge 340
minus 055
minute 242
µ mu 155
×
multiply 264
9 nine 071
notelement 317
notequal 271
notsubset 313
nu 156
# numbersign 043
omega 167
omega1 166
omicron 157
1 one 061
( parenleft 050
) parenright 051
parenlefttp 346
parenleftex 347
parenleftbt 350
parenrighttp 366
parenrightex 367
parenrightbt 370
partialdiff 266
% percent 045
. period 056
Character Sets and EncodingsAPPENDIX D
934
CHAR NAME CODE CHAR NAME CODE
perpendicular 136
phi 146
phi1 152
pi 160
+ plus 053
± plusminus 261
product 325
propersubset 314
propersuperset 311
proportional 265
psi 171
? question 077
radical 326
radicalex 140
reflexsubset 315
reflexsuperset 312
® registersans 342
® registerserif 322
rho 162
second 262
; semicolon 073
7 seven 067
sigma 163
sigma1 126
similar 176
6 six 066
/ slash 057
space 040
spade 252
suchthat 047
summation 345
tau 164
therefore 134
theta 161
theta1 112
3 three 063
™ trademarksans 344
™ trademarkserif 324
2 two 062
_ underscore 137
union 310
universal 042
upsilon 165
weierstrass 303
xi 170
0 zero 060
zeta 172
ZapfDingbats Set and EncodingSECTION D.4
935
D.4 ZapfDingbats Set and Encoding
CHAR NAME CODE CHAR NAME CODE CHAR NAME CODE CHAR NAME CODE
space 040
✁ a1 041
✂ a2 042
✃ a202 043
✄ a3 044
☎ a4 045
✆ a5 046
✇ a119 047
✈ a118 050
✉ a117 051
☛ a11 052
☞ a12 053
✌ a13 054
✍ a14 055
✎ a15 056
✏ a16 057
✐ a105 060
✑ a17 061
✒ a18 062
✓ a19 063
✔ a20 064
✕ a21 065
✖ a22 066
✗ a23 067
✘ a24 070
✙ a25 071
✚ a26 072
✛ a27 073
✜ a28 074
✝ a6 075
✞ a7 076
✟ a8 077
✠ a9 100
✡ a10 101
✢ a29 102
✣ a30 103
✤ a31 104
✥ a32 105
✦ a33 106
✧ a34 107
★ a35 110
✩ a36 111
✪ a37 112
✫ a38 113
✬ a39 114
✭ a40 115
✮ a41 116
✯ a42 117
✰ a43 120
✱ a44 121
✲
a45 122
✳ a46 123
✴ a47 124
✵ a48 125
✶ a49 126
✷ a50 127
✸ a51 130
✹ a52 131
✺ a53 132
✻ a54 133
✼ a55 134
✽ a56 135
✾ a57 136
✿ a58 137
❀ a59 140
❁ a60 141
❂ a61 142
❃ a62 143
❄ a63 144
❅ a64 145
❆ a65 146
❇ a66 147
❈ a67 150
❉ a68 151
❊ a69 152
❋ a70 153
● a71 154
❍ a72 155
■ a73 156
❏ a74 157
❐ a203 160
❑ a75 161
❒ a204 162
▲ a76 163
▼ a77 164
◆ a78 165
❖ a79 166
◗ a81 167
❘ a82 170
❙ a83 171
❚ a84 172
❛ a97 173
❜ a98 174
❝ a99 175
❞ a100 176
❡ a101 241
❢ a102 242
❣ a103 243
❤ a104 244
❥ a106 245
❦ a107 246
❧ a108 247
♣ a112 250
♦ a111 251
♥ a110 252
♠ a109 253
① a120 254
② a121 255
③ a122 256
④ a123 257
⑤ a124 260
⑥ a125 261
⑦ a126 262
⑧ a127 263
⑨ a128 264
⑩ a129 265
❶ a130 266
❷ a131 267
❸ a132 270
❹ a133 271
❺ a134 272
❻ a135 273
❼ a136 274
❽ a137 275
❾ a138 276
❿ a139 277
➀ a140 300
➁ a141 301
➂ a142 302
➃ a143 303
➄ a144 304
➅ a145 305
➆ a146 306
➇ a147 307
➈ a148 310
➉ a149 311
➊ a150 312
➋ a151 313
➌ a152 314
➍ a153 315
Character Sets and EncodingsAPPENDIX D
936
CHAR NAME CODE CHAR NAME CODE CHAR NAME CODE CHAR NAME CODE
➎ a154 316
➏ a155 317
➐ a156 320
➑ a157 321
➒ a158 322
➓ a159 323
➔ a160 324
→ a161 325
↔ a163 326
↕ a164 327
➘ a196 330
➙ a165 331
➚ a192 332
➛ a166 333
➜ a167 334
➝ a168 335
➞ a169 336
➟ a170 337
➠ a171 340
➡ a172 341
➢ a173 342
➣ a162 343
➤ a174 344
➥ a175 345
➦ a176 346
➧ a177 347
➨ a178 350
➩ a179 351
➪ a193 352
➫ a180 353
➬ a199 354
➭ a181 355
➮ a200 356
➯ a182 357
➱ a201 361
➲ a183 362
➳ a184 363
➴ a197 364
➵ a185 365
➶ a194 366
➷ a198 367
➸ a186 370
➹ a195 371
➺ a187 372
➻ a188 373
➼ a189 374
➽ a190 375
➾ a191 376
937
APPENDIX E
EPDF Name Registry
This appendix discusses a registry, maintained by Adobe for developers, that con-
tains private names and formats used by PDF producers or Acrobat plug-in ex-
tensions.
Acrobat enables third parties to add private data to PDF documents and to add
plug-in extensions that change viewer behavior based on this data. However,
Acrobat users have certain expectations when opening a PDF document, no mat-
ter what plug-ins are available. PDF enforces certain restrictions on private data
in order to meet these expectations.
A PDF producer or Acrobat viewer plug-in extension may define new types of
actions, destinations, annotations, security, and file system handlers. If a user
opens a PDF document and the plug-in that implements the new type of object is
unavailable, the viewer behaves as described in Appendix H, “Compatibility and
Implementation Notes.”
A PDF producer or Acrobat plug-in extension may also add keys to any PDF
object that is implemented as a dictionary, except the file trailer dictionary (see
Section 3.4.4, “File Trailer”). In addition, a PDF producer or Acrobat plug-in may
create tags that indicate the role of marked-content operators (PDF 1.2), as
described in Section 10.5, “Marked Content.”
To avoid conflicts with third-party names and with future versions of PDF, Adobe
maintains a registry for certain private names and formats. Developers must only
add private data that conforms to the registry rules. The registry includes three
classes:
• First class. Names and data formats that are of value to a wide range of de-
velopers. All names defined in any version of the PDF specification are first-
PDF Name RegistryAPPENDIX E
938
class names. Plug-in extensions that are publicly available should often use
first-class names for their private data. First-class names and data formats must
be registered with Adobe and are made available for all developers to use. To
submit a private name and format for consideration as first-class, use the Acro-
bat SDK feedback form at this Web page:
<http://partners.adobe.com/links/pdf/register>
• Second class. Names that are applicable to a specific developer. (Adobe does not
register second-class data formats.) Adobe distributes second-class names by
registering developer-specific prefixes, which must be used as the first char-
acters in the names of all private data added by the developer. Adobe will not
register the same prefix to two different developers, thereby ensuring that dif-
ferent developers’ second-class names do not conflict. It is the responsibility of
the developer not to use the same name in conflicting ways. To register a devel-
oper-specific prefix, use this Web page:
<http://partners.adobe.com/links/pdf/register>
• Third class. Names that can be used only in files that other third parties will
never see because they may conflict with third-class names defined by others.
Third-class names all begin with a specific prefix reserved by Adobe for private
plug-in extensions. This prefix, which is
XX, must be used as the first characters
in the names of all private data added by the developer. It is not necessary to
contact Adobe to register third-class names.
Note: New keys for the document information dictionary (see Section 10.2.1, “Doc-
ument Information Dictionary”) or a thread information dictionary (in the
I entry
of a thread dictionary; see Section 8.3.2, “Articles”) need not be registered.
939
APPENDIX F
FLinearized PDF
A Linearized PDF file is a file that has been organized in a special way to enable
efficient incremental access in a network environment. The file is valid PDF in all
respects, and is compatible with all existing viewers and other PDF applications.
Enhanced viewer applications can recognize that a PDF file has been linearized
and can take advantage of that organization (as well as added hint information) to
enhance viewing performance.
The Linearized PDF file organization is an optional feature available beginning in
PDF 1.2. Its primary goal is to achieve the following behavior:
• When a document is opened, display the first page as quickly as possible. The
first page to be viewed can be an arbitrary page of the document, not neces-
sarily page 0 (though opening at page 0 is most common).
• When the user requests another page of an open document (for example, by
going to the next page or by following a link to an arbitrary page), display that
page as quickly as possible.
• When data for a page is delivered over a slow channel, display the page incre-
mentally as it arrives. To the extent possible, display the most useful data first.
• Permit user interaction, such as following a link, to be performed even before
the entire page has been received and displayed.
This behavior should be achieved for documents of arbitrary size. The total num-
ber of pages in the document should have little or no effect on the user-perceived
performance of viewing any particular page.
The primary focus of Linearized PDF is optimized viewing of read-only PDF
documents. It is intended that the Linearized PDF be generated once and read
many times. Incremental update is still permitted, but the resulting PDF is no
Linearized PDFAPPENDIX F
940
longer linearized and subsequently is treated as ordinary PDF. Linearizing it
again may require reprocessing the entire file; see Section F.4.6, “Accessing an Up-
dated File,” for details.
Linearized PDF requires two additions to the PDF specification:
• Rules for the ordering of objects in the PDF file
• Additional data structures, called hint tables, that enable efficient navigation
within the document
Both of these additions are relatively simple to describe; however, using them
effectively requires a deeper understanding of their purpose. Consequently, this
appendix goes considerably beyond a simple specification of these PDF exten-
sions to include background, motivation, and strategies.
• Section F.1, “Background and Assumptions,” provides background information
about the properties of the Web that are relevant to the design of Linearized
PDF.
• Section F.2, “Linearized PDF Document Structure,” specifies the file format and
object-ordering requirements of Linearized PDF.
• Section F.3, “Hint Tables,” specifies the detailed representation of the hint
tables.
• Section F.4, “Access Strategies,” outlines strategies for accessing Linearized PDF
over a network, which in turn determine the optimal way to organize the PDF
file.
The reader is assumed to be familiar with the basic architecture of the Web, in-
cluding terms such as URL, HTTP, and MIME.
F.1 Background and Assumptions
The principal problem addressed by the Linearized PDF design is the access of
PDF documents through the Web. This environment has the following important
properties:
• The access protocol (HTTP) is a transaction consisting of a request and a re-
sponse. The client presents a request in the form of a URL, and the server sends
a response consisting of one or more MIME-tagged data blocks.
Background and AssumptionsSECTION F.1
941
• After a transaction has completed, obtaining more data requires a new request-
response transaction. The connection between client and server does not ordi-
narily persist beyond the end of a transaction, although some implementations
may attempt to cache the open connection to expedite subsequent transactions
with the same server.
• Round-trip delay can be significant. A request-response transaction can take
up to several seconds, independent of the amount of data requested.
• The data rate may be limited. A typical bottleneck is a slow modem link be-
tween the client and the Internet service provider.
These properties are generally shared by other wide-area network architectures
besides the Web. Also, CD-ROMs share some of these properties, since they have
relatively slow seek times and limited data rates compared to magnetic media.
The remainder of this appendix focuses on the Web.
Some additional properties of the HTTP protocol are relevant to the problem of
accessing PDF files efficiently. These properties may not all be shared by other
protocols or network environments.
• When a PDF file is initially accessed (such as by following a URL hyperlink
from some other document), the file type is not known to the client. Therefore,
the client initiates a transaction to retrieve the entire document and then in-
spects the MIME tag of the response as it arrives. Only at that point is the doc-
ument known to be PDF. Additionally, with a properly configured server
environment, the length of the document becomes known at that time.
• The client can abort a response while the transaction is still in progress if it
decides that the remainder of the data is not of immediate interest. In HTTP,
aborting the transaction requires closing the connection, which interferes with
the strategy of caching the open connection between transactions.
• The client can request retrieval of portions of a document by specifying one or
more byte ranges (by offset and count) in the HTTP request headers. Each
range can be relative to either the beginning or the end of the file. The client
can specify as many ranges as it wants in the request, and the response consists
of multiple blocks, each properly tagged.
• The client can initiate multiple concurrent transactions in an attempt to ob-
tain multiple responses in parallel. This is commonly done, for instance, to re-
trieve inline images referenced from an HTML document. This strategy is not
Linearized PDFAPPENDIX F
942
always reliable and may backfire if the transactions interfere with each other
by competing for scarce resources in the server or the communication chan-
nel.
Note: Extensive experimentation has determined that having multiple concurrent
transactions does not work very well for PDF in some important environments.
Therefore, Linearized PDF is designed to enable good performance to be achieved
using only one transaction at a time. In particular, this means that the client must
have sufficient information to determine the byte ranges for all the objects re-
quired to display a given page of the PDF file so that it can specify all those byte
ranges in a single request.
The following additional assumptions are made about the PDF viewer application
and its local environment:
• The viewer application has plenty of local temporary storage available. It
should rarely need to retrieve a given portion of a PDF document more than
once from the server.
• The viewer application is able to display PDF data quickly once it has been
received. The performance bottleneck is assumed to be in the transport sys-
tem (throughput or round-trip delay), not in the processing of data after it ar-
rives.
The consequence of these assumptions is that it may be advantageous for the cli-
ent to do considerable extra work to minimize delays due to communications.
Such work includes maintaining local caches and reordering actions according to
when the needed data becomes available.
F.2 Linearized PDF Document Structure
Except as noted below, all elements of a Linearized PDF file are as specified in
Section 3.4, “File Structure,” and all indirect objects in the file are numbered
sequentially in two groups, based on their order of appearance in the file.
• The first group consists of the document catalog, certain other document-level
objects, and all objects belonging to the first page of the document. These ob-
jects are numbered sequentially, starting at the first object number after the last
number of the second group. (The stream containing the hint tables, called a
Linearized PDF Document StructureSECTION F.2
943
hint stream, may be numbered out of sequence; see Section F.2.5, “Hint Streams
(Parts 5 and 10).”)
• The second group consists of all remaining objects in the document, including
all pages after the first, all shared objects (objects referenced from more than
one page, not counting objects referenced from the first page), and so forth.
These objects are numbered sequentially starting at 1.
These groups of objects are indexed by exactly two cross-reference table sections,
located as shown in Example F.1. The composition of these groups is discussed in
more detail in the sections that follow (ordered by the part number as shown in
this example, with one section for parts 5 and 10). All objects have a generation
number of 0.
Beginning with PDF 1.5, PDF files may contain object streams (see Section 3.4.6,
“Object Streams”). In linearized files containing object streams, the following
conditions apply:
• Certain additional objects cannot be contained in an object stream: the linear-
ization dictionary, the document catalog, and page objects.
• Objects stored within object streams are given the highest range of object num-
bers within the main and first-page cross-reference sections.
• For files containing object streams, hint data can specify the location and size
of the object streams only (or uncompressed objects), not the individual com-
pressed objects. Similarly, shared object references should be made to the ob-
ject stream containing a compressed object, not to the compressed object itself.
• Cross-reference streams (Section 3.4.7, “Cross-Reference Streams”) can be used
in place of traditional cross-reference tables. The logic described in this chapter
still applies, with the appropriate syntactic changes.
Example F.1
Part 1: Header
%PDF1.1 % …Binary characters…
Linearized PDFAPPENDIX F
944
Part 2: Linearization parameter dictionary
43 0 obj
<< /Linearized 1.0 % Version
/L 54567 % File length
/H [475 598] % Primary hint stream offset and length (part 5)
/O 45 % Object number of first page’s page object (part 6)
/E 5437 % Offset of end of first page
/N 11 % Number of pages in document
/T 52786 % Offset of first entry in main cross-reference table (part 11)
>>
endobj
Part 3: First-page cross-reference table and trailer
xref
43 14
0000000052 00000 n
0000000392 00000 n
0000001073 00000 n
…Cross-reference entries for remaining objects in the first page …
0000000475 00000 n
trailer
<< /Size 57 % Total number of cross-reference table entries in document
/Prev 52776 % Offset of main cross-reference table (part 11)
/Root 44 0 R % Indirect reference to catalog (part 4)
…Any other entries, such as Info and Encrypt… % (part 9)
>>
startxref
0 % Dummy cross-reference table offset
%%EOF
Part 4: Document catalog and other required document-level objects
44 0 obj
<< /Type /Catalog
/Pages 42 0 R
>>
endobj
…Other objects…
Linearized PDF Document StructureSECTION F.2
945
Part 5: Primary hint stream (may precede or follow part 6)
56 0 obj
<< /Length 457
…Possibly other stream attributes, such as Filter…
/S 221 % Position of shared object hint table
…Possibly entries for other hint tables …
>>
stream
…Page offset hint table …
…Shared object hint table…
…Possibly other hint tables …
endstream
endobj
Part 6: First-page section (may precede or follow part 5)
45 0 obj
<< /Type /Page
…
>>
endobj
…Outline hierarchy (if the PageMode value in the document catalog is UseOutlines)…
…Objects for first page, including both shared and nonshared objects…
Part 7: Remaining pages
1 0 obj
<< /Type /Page
…Other page attributes, such as MediaBox, Parent, and Contents…
>>
endobj
…Nonshared objects for this page …
…Each successive page followed by its nonshared objects…
…Last page followed by its nonshared objects…
Part 8: Shared objects for all pages except the first
…Shared objects…
Part 9: Objects not associated with pages, if any
…Other objects…
Linearized PDFAPPENDIX F
946
Part 10: Overflow hint stream (optional)
…Overflow hint stream…
Part 11: Main cross-reference table and trailer
xref
043
0000000000 65535 f
…Cross-reference entries for all except first page’s objects…
trailer
<< /Size 43 >> % Trailer need not contain other entries; in particular,
startxref % it should not have a Prev entry
257 % Offset of first-page cross-reference table (part 3)
%%EOF
F.2.1 Header (Part 1)
The Linearized PDF file begins with the standard header line (see Section 3.4.1,
“File Header”). Linearization is independent of PDF version number and can be
applied to any PDF file of version 1.1 or greater.
The binary characters following the percent sign on the second line are characters
with codes 128 or greater, as recommended in Section 3.4.1, “File Header.”
F.2.2 Linearization Parameter Dictionary (Part 2)
Following the header, the first object in the body of the file (part 2) must be an in-
direct dictionary object, the linearization parameter dictionary, containing the pa-
rameters listed in Table F.1. All values in this dictionary must be direct objects.
There are no references to this dictionary anywhere in the document; however,
the first-page cross-reference table (Part 3) contains a normal entry for it.
The linearization parameter dictionary must be entirely contained within the first
1024 bytes of the PDF file. This limits the amount of data a viewer application
must read before deciding whether the file is linearized.
Linearized PDF Document StructureSECTION F.2
947
TABLE F.1 Entries in the linearization parameter dictionary
PARAMETER TYPE VALUE
Linearized number (Required) A version identification for the linearized format. As usual, a
change in the integer part indicates an incompatible change in the linearized
format, while a change in the fractional part indicates a backward-compatible
change. The current version is 1.0.
L integer (Required) The length of the entire file in bytes. It must be exactly equal to the
actual length of the PDF file. A mismatch indicates that the file is not
linearized and must be treated as ordinary PDF, ignoring linearization in-
formation. (If the mismatch resulted from appending an update, the linear-
ization information may still be correct but requires validation; see Section
F.4.6, “Accessing an Updated File,” for details.)
H array (Required) An array of two or four integers, [offset
1
length
1
] or
[offset
1
length
1
offset
2
length
2
]. offset
1
is the offset of the primary hint
stream from the beginning of the file. (This is the beginning of the stream ob-
ject, not the beginning of the stream data.)
length
1
is the length of this stream,
including stream object overhead.
If the value of the primary hint stream dictionary’s
Length entry is an indirect
reference, the object it refers to must immediately follow the stream object,
and
length
1
also includes the length of the indirect length object, including
object overhead. (See implementation note 172 in Appendix H.)
If there is an overflow hint stream,
offset
2
and length
2
specify its offset and
length. (See implementation note 173 in Appendix H.)
O integer (Required) The object number of the first page’s page object.
E integer (Required) The offset of the end of the first page (the end of part 6 in Example
F.1), relative to the beginning of the file. (See implementation note 174 in
Appendix H.)
N integer (Required) The number of pages in the document.
Linearized PDFAPPENDIX F
948
F.2.3 First-Page Cross-Reference Table and Trailer (Part 3)
Part 3 contains the cross-reference table for objects belonging to the first page
(discussed in Section F.2.6, “First-Page Section (Part 6)”) as well as for the docu-
ment catalog and document-level objects appearing before the first page (dis-
cussed in Section F.2.4, “Document Catalog and Document-Level Objects (Part
4)”). Additionally, this cross-reference table contains entries for the linearization
parameter dictionary (at the beginning) and the primary hint stream (at the end).
This table is a valid cross-reference table as defined in Section 3.4.3, “Cross-
Reference Table,” although its position in the file is unconventional. It consists of
a single cross-reference subsection that has no free entries.
Note: In PDF 1.5 and later, cross-reference streams (see Section 3.4.7, “Cross-Refer-
ence Streams”) may be used in linearized files in place of traditional cross-reference
tables. The logic described in this section, along with the appropriate syntactic
changes for cross-reference streams, still applies.
Below the table is the first-page trailer. The trailer’s
Prev entry gives the offset of
the main cross-reference table near the end of the file. This is valid PDF syntax,
although the trailers are linked in an unusual order. A PDF viewer application
that is unaware of linearization interprets the first-page cross-reference table as
an update to an original document that is indexed by the main cross-reference ta-
ble.
T integer (Required) In documents that use standard main cross-reference tables (in-
cluding hybrid-reference files; see “Compatibility with PDF 1.4” on page 85),
this entry represents the offset of the white-space character preceding the
first entry of the main cross-reference table (the entry for object number 0),
relative to the beginning of the file. Note that this differs from the
Prev entry
in the first-page trailer, which gives the location of the
xref line that precedes
the table.
In PDF 1.5 and later documents that use cross-reference streams exclusively
(see Section 3.4.7, “Cross-Reference Streams”), this entry represents the offset
of the main cross-reference stream object.
P integer (Optional) The page number of the first page (see Section F.2.6, “First-Page
Section (Part 6)”). Default value: 0.
PARAMETER TYPE VALUE
Linearized PDF Document StructureSECTION F.2
949
The first-page trailer must contain valid Size and Root entries, as well as any
other entries needed to display the document. The
Size value must be the com-
bined number of entries in both the first-page cross-reference table and the main
cross-reference table.
The first-page trailer may optionally end with
startxref, an integer, and %%EOF,
just as in an ordinary trailer. This information is ignored.
F.2.4 Document Catalog and Document-Level Objects (Part 4)
Following the first-page cross-reference table and trailer are the catalog dictio-
nary and other objects that are required when the document is opened. These
additional objects (constituting part 4) include the values of the following entries
if they are present and are indirect objects:
• The ViewerPreferences entry in the catalog.
• The PageMode entry in the catalog. Note that if the value of PageMode is
UseOutlines, the outline hierarchy is located in part 6; otherwise, the outline
hierarchy, if any, is located in part 9. See Section F.2.9, “Other Objects (Part 9)”
for details.
• The Threads entry in the catalog, along with all thread dictionaries it refers to.
This does not include the threads’ information dictionaries or the individual
bead dictionaries belonging to the threads.
• The OpenAction entry in the catalog.
• The AcroForm entry in the catalog. Only the top-level interactive form dictio-
nary is needed, not the objects that it refers to.
• The Encrypt entry in the first-page trailer dictionary. All values in the encryp-
tion dictionary must also be located here.
Objects that are not ordinarily needed when the document is opened should not
be located here but instead should be at the end of the file; see Section F.2.9, “Oth-
er Objects (Part 9).” This includes objects such as page tree nodes, the document
information dictionary, and the definitions for named destinations.
Note that the objects located here are indexed by the first-page cross-reference
table, even though they are not logically part of the first page.
Linearized PDFAPPENDIX F
950
F.2.5 Hint Streams (Parts 5 and 10)
The core of the linearization information is stored in data structures known as
hint tables, whose format is described in Section F.3, “Hint Tables.” They provide
indexing information that enables the client to construct a single request for all
the objects that are needed to display any page of the document or to retrieve cer-
tain other information efficiently. The hint tables may contain additional infor-
mation to optimize access by plug-in extensions to application-specific data.
The hint tables are not logically part of the information content of the document;
they can be derived from the document. Any action that changes the document—
for instance, appending an incremental update—invalidates the hint tables. The
document remains a valid PDF file but is no longer linearized; see Section F.4.6,
“Accessing an Updated File,” for details.
The hint tables are binary data structures that are enclosed in a stream object.
Syntactically, this stream is a normal PDF indirect object. However, there are no
references to the stream anywhere in the document. Therefore, it is not logically
part of the document, and an operation that regenerates the document may re-
move the stream.
Usually, all the hint tables are contained in a single stream, known as the primary
hint stream. Optionally, there may be an additional stream containing more hints,
known as the overflow hint stream. The contents of the two hint streams are to be
concatenated and treated as if they were a single unbroken stream.
The primary hint stream, which is required, is shown as part 5 in Example F.1.
The order of this part and the first-page section, shown as part 6, may be re-
versed; see Section F.4, “Access Strategies,” for considerations on the choice of
placement. The overflow hint stream, part 10, is optional. (See implementation
note 173 in Appendix H.)
The location and length of the primary hint stream, and of the overflow hint
stream if present, are given in the linearization parameter dictionary at the begin-
ning of the file.
The hint streams are assigned the last object numbers in the file—that is, after the
object number for the last object in the first page. Their cross-reference table
entries are at the end of the first-page cross-reference table. This object number
assignment is independent of the physical locations of the hint streams in the file.
Linearized PDF Document StructureSECTION F.2
951
(This convention keeps their object numbers from conflicting with the number-
ing of the linearized objects.)
With one exception, the values of all entries in the hint streams’ dictionaries must
be direct objects and can contain no indirect object references. The exception is
the stream dictionary’s
Length entry (see the discussion of the H entry in Table
F.1).
In addition to the standard stream attributes, the dictionary of the primary hint
stream contains entries giving the position of the beginning of each hint table in
the stream. These positions are given in bytes relative to the beginning of the
stream data (after decoding filters, if any, are applied) and with the overflow
hint stream concatenated if present. The dictionary of the overflow hint stream
should not contain these entries. The keys designating the standard hint tables
in the primary hint stream’s dictionary are listed in Table F.2; Section F.3, “Hint
Tables,” documents the format of these hint tables. Additionally, there is a re-
quired page offset hint table, which must be the first table in the stream and
must start at offset 0.
TABLE F.2 Standard hint tables
KEY HINT TABLE
S (Required) Shared object hint table (see Section F.3.2, “Shared Object Hint Ta-
ble”)
T (Present only if thumbnail images exist) Thumbnail hint table (see Section F.3.3,
“Thumbnail Hint Table”)
O (Present only if a document outline exists) Outline hint table (see Section F.3.4,
“Generic Hint Tables”)
A (Present only if article threads exist) Thread information hint table (see Section
F.3.4, “Generic Hint Tables”)
E (Present only if named destinations exist) Named destination hint table (see
Section F.3.4, “Generic Hint Tables”)
V (Present only if an interactive form dictionary exists) Interactive form hint table
(see Section F.3.5, “Extended Generic Hint Tables”)
I (Present only if a document information dictionary exists) Information dictio-
nary hint table (see Section F.3.4, “Generic Hint Tables”)
Linearized PDFAPPENDIX F
952
New keys may be registered for additional hint tables required for new PDF
features or for application-specific data accessed by plug-in extensions. See
Appendix E for further information.
F.2.6 First-Page Section (Part 6)
As mentioned earlier, the section containing objects belonging to the first page of
the document may either precede or follow the primary hint stream. The starting
file offset and length of this section can be determined from the hint tables. In
addition, the
E entry in the linearization parameter dictionary specifies the end of
the first page (as an offset relative to the beginning of the file), and the
O entry
gives the object number of the first page’s page object.
This part of the file contains all the objects needed to display the first page of the
document. Ordinarily, the first page is page 0—that is, the leftmost leaf page node
in the page tree. However, if the document catalog contains an
OpenAction entry
that specifies opening at some page other than page 0, that page is considered the
first page and should be located here. The page number of the first page is given
in the
P entry of the linearization parameter dictionary. (See also implementation
note 175 in Appendix H.)
The following objects should be contained in the first-page section:
• The page object for the first page. This object must be the first one in this part
of the file. Its object number is given in the linearization parameter dictionary.
This page object must explicitly specify all required attributes, such as
C (Present only if a logical structure hierarchy exists; PDF 1.3) Logical structure
hint table (see Section F.3.5, “Extended Generic Hint Tables”)
L (PDF 1.3) Page label hint table (see Section F.3.4, “Generic Hint Tables”)
R (Present only if a renditions name tree exists; PDF 1.5) Renditions name tree
hint table (see Section F.3.5, “Extended Generic Hint Tables”)
B
(Present only if embedded file streams exist; PDF 1.5) Embedded file stream hint
table (see Section F.3.6, “Embedded File Stream Hint Tables”)
KEY HINT TABLE
Linearized PDF Document StructureSECTION F.2
953
Resources and MediaBox; the attributes cannot be inherited from ancestor page
tree nodes.
• The entire outline hierarchy, if the value of the PageMode entry in the catalog
is
UseOutlines. (If the PageMode entry is omitted or has some other value and
the document has an outline hierarchy, the outline hierarchy appears in part 9;
see Section F.2.9, “Other Objects (Part 9)” for details.)
• All objects that the page object refers to, to an arbitrary depth, except page tree
nodes or other page objects. This includes objects referred to by its
Contents,
Resources, Annots, and B entries, but not the Thumb entry.
The order of objects referenced from the page object should facilitate early user
interaction and incremental display of the page data as it arrives. The following
order is recommended:
1. The
Annots array and all annotation dictionaries, to a depth sufficient for
those annotations to be activated. Information required to draw the annota-
tion can be deferred until later since annotations are always drawn on top of
(hence after) the contents.
2. The
B (beads) array and all bead dictionaries, if any, for this page. If any beads
exist for this page, the
B array is required to be present in the page dictionary.
Additionally, each bead in the thread (not just the first bead) must contain a
T
entry referring to the associated thread dictionary.
3. The resource dictionary, but not the resource objects contained in the dic-
tionary.
4. Resource objects, other than the types listed below, in the order that they are
first referenced (directly or indirectly) from the content stream. If the contents
are represented as an array of streams, each resource object should precede the
stream in which it is first referenced. Note that
Font, FontDescriptor, and
Encoding resources should be included here, but not substitutable font files
referenced from font descriptors (see item 7 below).
5. The page contents (
Contents). If large, this should be represented as an array
of indirect references to content streams, which in turn are interleaved with
the resources they require. If small, the entire contents should be a single con-
tent stream preceding the resources.
6. Image XObjects, in the order that they are first referenced. Images are assumed
to be large and slow to transfer; therefore, the viewer application defers ren-
dering images until all the other contents have been displayed.
Linearized PDFAPPENDIX F
954
7. FontFile streams, which contain the actual definitions of embedded fonts.
These are assumed to be large and slow to transfer; therefore, the viewer appli-
cation uses substitute fonts until the real ones have arrived. Only those fonts
for which substitution is possible can be deferred in this way. (Currently, this
includes any Type 1 or TrueType font that has a font descriptor with the
Nonsymbolic flag set, indicating the Adobe standard Latin character set).
See Section F.4, “Access Strategies,” for additional discussion about object order
and incremental drawing strategies.
F.2.7 Remaining Pages (Part 7)
Part 7 of the Linearized PDF file contains the page objects and nonshared objects
for all remaining pages of the file, with the objects for each page grouped togeth-
er. The pages are contiguous and are ordered by page number. If the first page of
the file is not page 0, this section starts with page 0 and skips over the first page
when its position in the sequence is reached.
For each page, the objects required to display that page are grouped together,
except for resources and other objects that are shared with other pages. Shared
objects are located in the shared objects section (part 8). The starting file offset
and length of any page can be determined from the hint tables.
The recommended order of objects within a page is essentially the same as in the
first page. In particular, the page object must be the first object in each section.
In most cases, unlike for the first page, little benefit is gained from interleaving
contents with resources because most resources other than images—fonts in par-
ticular—are shared among multiple pages and therefore reside in the shared ob-
jects section. Image XObjects usually are not shared, but they should appear at
the end of the page’s section of the file, since rendering of images is deferred.
F.2.8 Shared Objects (Part 8)
Part 8 of the file contains objects, primarily named resources, that are referenced
from more than one page but that are not referenced (directly or indirectly) from
the first page. The hint tables contain an index of these objects. For more infor-
mation on named resources, see Section 3.7.2, “Resource Dictionaries.”
Linearized PDF Document StructureSECTION F.2
955
The order of these objects is essentially arbitrary. However, wherever a resource
consists of a multiple-level structure, all components of the structure should be
grouped together. If only the top-level object is referenced from outside the
group, the entire group can be described by a single entry in the shared object
hint table. This helps to minimize the size of the shared object hint table and the
number of individual references from entries in the page offset hint table. (See
also implementation note 176 in Appendix H.)
F.2.9 Other Objects (Part 9)
Following the shared objects are any other objects that are part of the document
but are not required for displaying pages. These objects are divided into function-
al categories. Objects within each of these categories should be grouped together;
the relative order of the categories is unimportant.
• The page tree. This object can be located in this section because the viewer ap-
plication never needs to consult it. Note that all
Resources attributes and other
inheritable attributes of the page objects must be pushed down and replicated
in each of the leaf page objects (but they may contain indirect references to
shared objects).
• Thumbnail images. These objects should simply be ordered by page number.
(The thumbnail image for page 0 should be first, even if the first page of the
document is some page other than 0.) Each thumbnail image consists of one or
more objects, which may refer to objects in the thumbnail shared objects sec-
tion (see the next item).
• Thumbnail shared objects. These are objects that are shared among some or all
thumbnail images and are not referenced from any other objects.
• The outline hierarchy, if not located in part 6. The order of objects should be the
same as the order in which they are displayed by the viewer application. This is
a preorder traversal of the outline tree, skipping over any subtree that is closed
(that is, whose parent’s
Count value is negative). Following that should be the
subtrees that were skipped over, in the order in which they would have ap-
peared if they were all open.
• Thread information dictionaries, referenced from the I entries of thread dictio-
naries. Note that the thread dictionaries themselves are located with the docu-
ment catalog and the bead dictionaries with the individual pages.
Linearized PDFAPPENDIX F
956
• Named destinations. These objects include the value of the Dests or Names
entry in the document catalog and all the destination objects that it refers to.
See Section F.4.2, “Opening at an Arbitrary Page.”
• The document information dictionary and the objects contained within it.
• The interactive form field hierarchy. This group of objects does not include the
top-level interactive form dictionary, which is located with the document cata-
log.
• Other entries in the document catalog that are not referenced from any page.
• (PDF 1.3) The logical structure hierarchy.
• (PDF 1.5) The renditions name tree hierarchy.
• (PDF 1.5) Embedded file streams.
F.2.10 Main Cross-Reference and Trailer (Part 11)
Part 11 is the cross-reference table for all objects in the PDF file except those
listed in the first-page cross-reference table (part 3). As indicated earlier, this
cross-reference table plays the role of the original cross-reference table for the file
(before any updates are appended) and must conform to the following rules:
• It consists of a single cross-reference subsection, beginning at object number 0.
• The first entry (for object number 0) must be a free entry.
• The remaining entries are for in-use objects, which are numbered consecutive-
ly, starting at 1.
The
startxref line gives the offset of the first-page cross-reference table. The Prev
entry of the first-page trailer gives the offset of the main cross-reference table.
The main trailer has no
Prev entry and in fact does not need to contain any en-
tries other than
Size.
Note: In PDF 1.5 and later, cross-reference streams (see Section 3.4.7, “Cross-Refer-
ence Streams”) may be used in linearized files in place of traditional cross-reference
tables. The logic described in this chapter, along with the appropriate syntactic
changes for cross-reference streams, still applies.
Hint TablesSECTION F.3
957
F.3 Hint Tables
The core of the linearization information is stored in two or more hint tables, as
indicated by the attributes of the primary hint stream (see Section F.2.5, “Hint
Streams (Parts 5 and 10)”). The format of the standard hint tables is described in
this section.
There can be additional hint tables for application-specific data that is accessed
by plug-in extensions. A generic format for such hint tables is defined; see Section
F.3.4, “Generic Hint Tables.” Alternatively, the format of a hint table can be private
to the application; see Appendix E for further information.
Each hint table consists of a portion of the stream, beginning at the position in
the stream indicated by the corresponding stream attribute. Additionally, there is
a required page offset hint table, which must be the first table in the stream and
must start at offset 0. (If there is an overflow hint stream, its contents are to be ap-
pended seamlessly to the primary hint stream; hint table positions are relative to
the beginning of this combined stream.) In general, this byte stream is treated as a
bit stream, high-order bit first, which is then subdivided into fields of arbitrary
width without regard to byte boundaries. However, each hint table begins at a
byte boundary.
The hint tables are designed to encode the required information as compactly as
possible. Interpreting the hint tables requires reading them sequentially; they are
not designed for random access. The client is expected to read and decode the
tables once and retain the information for as long as the document remains open.
A hint table encodes the positions of various objects in the file. The representa-
tion is either explicit (an offset from the beginning of the file) or implicit (accu-
mulated lengths of preceding objects). Regardless of the representation, the
resulting positions must be interpreted as if the primary hint stream itself were
not present. That is, a position greater than the hint stream offset must have the
hint stream length added to it to determine the actual offset relative to the begin-
ning of the file. (The hint stream offset and hint stream length are the values
offset
1
and length
1
in the H array in the linearization parameter dictionary at the
beginning of the file.)
The reason for this rule is that the length of the primary hint stream depends on
the information contained within the hint tables, which is not known until after
Linearized PDFAPPENDIX F
958
they have been generated. Any information contained in the hint tables must not
depend on knowing the primary hint stream’s length in advance.
Note that this rule applies only to offsets given in the hint tables and not to offsets
given in the cross-reference tables or linearization parameter dictionary. Also, the
offset and length of the overflow hint stream, if present, need not be taken into
account, since this object follows all other objects in the file.
Note: In linearized files that use object streams (Section 3.4.6, “Object Streams), the
position specified in a hint table for a compressed object is to be interpreted as a byte
range in which the object can be found, not as a precise offset. Viewer applications
should locate the object via a cross-reference stream, as it would if the hint table
were not present.
F.3.1 Page Offset Hint Table
The page offset hint table provides information required for locating each page.
Additionally, for each page except the first, it also enumerates all shared objects
that the page references, directly or indirectly.
This table begins with a header section, described in Table F.3, followed by one or
more per-page entries, described in Table F.4. Note that the items making up each
per-page entry are not contiguous; they are broken up with items from entries for
other pages. The order of items making up the per-page entries is as follows:
1. Item 1 for all pages, in page order starting with the first page
2. Item 2 for all pages, in page order starting with the first page
3. Item 3 for all pages, in page order starting with the first page
4. Item 4 for all shared objects in the second page, followed by item 4 for all
shared objects in the third page, and so on
5. Item 5 for all shared objects in the second page, followed by item 5 for all
shared objects in the third page, and so on
6. Item 6 for all pages, in page order starting with the first page
7. Item 7 for all pages, in page order starting with the first page
Hint TablesSECTION F.3
959
Note: All the items in Table F.3 that specify a number of bits needed, such as item 3,
can have values in the range 0 through 32. Although that range requires only 6 bits,
16-bit numbers are used.
TABLE F.3 Page offset hint table, header section
ITEM SIZE (BITS) DESCRIPTION
1 32 The least number of objects in a page (including the page object itself).
2 32 The location of the first page’s page object.
3 16 The number of bits needed to represent the difference between the greatest
and least number of objects in a page.
4 32 The least length of a page in bytes. This is the least length from the beginning
of a page object to the last byte of the last object used by that page.
5 16 The number of bits needed to represent the difference between the greatest
and least length of a page, in bytes.
6 32 The least offset of the start of any content stream, relative to the beginning of
its page. (See implementation note 177 in Appendix H.)
7 16 The number of bits needed to represent the difference between the greatest
and least offset to the start of the content stream. (See implementation note
177 in Appendix H.)
8 32 The least content stream length. (See implementation note 178 in Appendix
H.)
9 16 The number of bits needed to represent the difference between the greatest
and least content stream length. (See implementation note 178 in Appendix
H.)
10 16 The number of bits needed to represent the greatest number of shared object
references.
11 16 The number of bits needed to represent the numerically greatest shared ob-
ject identifier used by the pages (discussed further in Table F.4, item 4).
Linearized PDFAPPENDIX F
960
TABLE F.4 Page offset hint table, per-page entry
12 16 The number of bits needed to represent the numerator of the fractional posi-
tion for each shared object reference. For each shared object referenced from
a page, there is an indication of where in the page’s content stream the object
is first referenced. That position is given as the numerator of a fraction,
whose denominator is specified once for the entire document (in the next
item in this table). The fraction is explained in more detail in Table F.4,
item 5.
13 16 The denominator of the fractional position for each shared object reference.
ITEM SIZE (BITS) DESCRIPTION
1 See Table F.3, item 3 A number that, when added to the least number of objects in a page (Table
F.3, item 1), gives the number of objects in the page. The first object of the
first page has an object number that is the value of the
O entry in the
linearization parameter dictionary at the beginning of the file. The first
object of the second page has an object number of 1. Object numbers for sub-
sequent pages can be determined by accumulating the number of objects in
all previous pages.
2 See Table F.3, item 5 A number that, when added to the least page length (Table F.3, item 4), gives
the length of the page in bytes. The location of the first object of the first page
can be determined from its object number (the
O entry in the linearization
parameter dictionary) and the cross-reference table entry for that object (see
Section F.2.3, “First-Page Cross-Reference Table and Trailer (Part 3)”). The
locations of subsequent pages can be determined by accumulating the lengths
of all previous pages. Note that it is necessary to skip over the primary hint
stream, wherever it is located.
3 See Table F.3, item 10 The number of shared objects referenced from the page. For the first page,
this number must be 0; the next two items start with the second page.
4 See Table F.3, item 11 (One item for each shared object referenced from the page) A shared object
identifier—that is, an index into the shared object hint table (described in
Section F.3.2, “Shared Object Hint Table”). Note that a single entry in the
shared object hint table can designate a group of shared objects, only one of
which is referenced from outside the group. That is, shared object identifiers
are not directly related to object numbers.
This identifier combines with the numerators provided in item 5 to form a
shared object reference.
ITEM SIZE (BITS) DESCRIPTION
Hint TablesSECTION F.3
961
F.3.2 Shared Object Hint Table
The shared object hint table gives information required to locate shared objects
(see Section F.2.8, “Shared Objects (Part 8)”). Shared objects can be physically
located in either of two places: objects that are referenced from the first page are
located with the first-page objects (part 6); all other shared objects are located in
the shared objects section (part 8).
5 See Table F.3, item 12 (One item for each shared object referenced from the page) The numerator of
the fractional position for each shared object reference, in the same order as
the preceding item. The fraction indicates where in the page’s content stream
the shared object is first referenced. This item is interpreted as the numerator
of a fraction whose denominator is specified once for the entire document
(Table F.3, item 13).
If the denominator is d, a numerator ranging from 0 to d 1 indicates the
corresponding portion of the page’s content stream. For example, if the
denominator is 4, a numerator of 0, 1, 2, or 3 indicates that the first reference
lies in the first, second, third, or fourth quarter of the content stream, respec-
tively.
There are two (or more) other possible values for the numerator, which indi-
cate that the shared object is not referenced from the content stream but is
needed by annotations or other objects that are drawn after the contents. The
value d indicates that the shared object is needed before image XObjects and
other nonshared objects that are at the end of the page. A value of d + 1 or
greater indicates that the shared object is needed after those objects.
This method of dividing the page into fractions is only approximate. Deter-
mining the first reference to a shared object entails inspecting the unencoded
content stream. The relationship between positions in the unencoded and en-
coded streams is not necessarily linear.
6 See Table F.3, item 7 A number that, when added to the least offset to the start of the content
stream (Table F.3, item 6), gives the offset in bytes of the start of the page’s
content stream (the stream object, not the stream data), relative to the begin-
ning of the page. (See implementation note 177 in Appendix H.)
7 See Table F.3, item 9 A number that, when added to the least content stream length (Table F.3,
item 8), gives the length of the page’s content stream in bytes. This length in-
cludes object overhead preceding and following the stream data. (See imple-
mentation note 178 in Appendix H.)
ITEM SIZE (BITS) DESCRIPTION
Linearized PDFAPPENDIX F
962
A single entry in the shared object hint table can actually describe a group of ad-
jacent objects under the following condition: Only the first object in the group is
referenced from outside the group; the remaining objects in the group are refer-
enced only from other objects in the same group. The objects in a group must
have adjacent object numbers.
The page offset hint table, interactive form hint table, and logical structure hint
table refer to an entry in the shared object hint table by a simple index that is its
sequential position in the table, counting from 0.
The shared object hint table consists of a header section (Table F.5) followed by
one or more shared object group entries (Table F.6). There are two sequences of
shared object group entries: the ones for objects located in the first page, followed
by the ones for objects located in the shared objects section. The entries have the
same format in both cases. Note that the items making up each shared object
group entry are not contiguous; they are broken up with items from entries for
other shared object groups. The order of items in each sequence is as follows:
1. Item 1 for the first group, item 1 for the second group, and so on
2. Item 2 for the first group, item 2 for the second group, and so on
3. Item 3 for the first group, item 3 for the second group, and so on
4. Item 4 for the first group, item 4 for the second group, and so on
All objects associated with the first page (part 6) have entries in the shared object
hint table, regardless of whether they are actually shared. The first entry refers to
the beginning of the first page and has an object count and length that span all
the initial nonshared objects. The next entry refers to a group of shared objects.
Subsequent entries span additional groups of either shared or nonshared objects
consecutively until all shared objects in the first page have been enumerated.
(The entries that refer to nonshared objects are never used.)
TABLE F.5 Shared object hint table, header section
ITEM SIZE (BITS) DESCRIPTION
1 32 The object number of the first object in the shared objects section (part 8).
2 32 The location of the first object in the shared objects section.
3 32 The number of shared object entries for the first page (including nonshared
objects, as noted above).
Hint TablesSECTION F.3
963
TABLE F.6 Shared object hint table, shared object group entry
4 32 The number of shared object entries for the shared objects section, including
the number of shared object entries for the first page (that is, the value of item
3).
5 16 The number of bits needed to represent the greatest number of objects in a
shared object group. (See also implementation note 179 in Appendix H.)
6 32 The least length of a shared object group in bytes.
7 16 The number of bits needed to represent the difference between the greatest
and least length of a shared object group, in bytes.
ITEM SIZE (BITS) DESCRIPTION
1 See Table F.5, item 7 A number that, when added to the least shared object group length (Table F.5,
item 6), gives the length of the object group in bytes. The location of the first
object of the first page is given in the page offset hint table, header section
(Table F.3, item 4). The locations of subsequent object groups can be deter-
mined by accumulating the lengths of all previous object groups until all
shared objects in the first page have been enumerated. Following that, the
location of the first object in the shared objects section can be obtained from
the header section of the shared object hint table (Table F.5, item 2).
2 1 A flag indicating whether the shared object signature (item 3) is present; its
value is 1 if the signature is present and 0 if it is absent. (See also implementa-
tion note 180 in Appendix H.)
3 128 (Only if item 2 is 1) The shared object signature, a 16-byte MD5 hash that
uniquely identifies the resource that the group of objects represents. It is in-
tended to enable the client to substitute a locally cached copy of the resource
instead of reading it from the PDF file. Note that this signature is unrelated to
signature fields in interactive forms, as defined in the section “Signature
Fields” on page 658.
ITEM SIZE (BITS) DESCRIPTION
Linearized PDFAPPENDIX F
964
Note: In a document consisting of only one page, all of that page’s objects are never-
theless treated as if they were shared; the shared object hint table reflects this. (See
implementation note 182 in Appendix H.)
F.3.3 Thumbnail Hint Table
The thumbnail hint table consists of a header section (Table F.7) followed by the
thumbnails section, which includes one or more per-page entries (Table F.8), each
of which describes the thumbnail image for a single page. The entries are in page
number order starting with page 0, even if the document catalog contains an
OpenAction entry that specifies opening at some page other than page 0. Thumb-
nail images may exist for some pages and not for others.
TABLE F.7 Thumbnail hint table, header section
4 See Table F.5, item 5 A number equal to 1 less than the number of objects in the group. The first
object of the first page is the one whose object number is given by the
O entry
in the linearization parameter dictionary at the beginning of the file. Object
numbers for subsequent entries can be determined by accumulating the
number of objects in all previous entries until all shared objects in the first
page have been enumerated. Following that, the first object in the shared
objects section has a number that can be obtained from the header section of
the shared object hint table (Table F.5, item 1). (See also implementation note
181 in Appendix H.)
ITEM SIZE (BITS) DESCRIPTION
1 32 The object number of the first thumbnail image (that is, the thumbnail image
that is described by the first entry in the thumbnails section).
2 32 The location of the first thumbnail image.
3 32 The number of pages that have thumbnail images.
4 16 The number of bits needed to represent the greatest number of consecutive
pages that do not have a thumbnail image.
5 32 The least length of a thumbnail image in bytes.
6 16 The number of bits needed to represent the difference between the greatest
and least length of a thumbnail image.
ITEM SIZE (BITS) DESCRIPTION
Hint TablesSECTION F.3
965
TABLE F.8 Thumbnail hint table, per-page entry
The order of items in Table F.8 is as follows:
1. Item 1 for all pages, in page order starting with the first page
2. Item 2 for all pages, in page order starting with the first page
3. Item 3 for all pages, in page order starting with the first page
7 32 The least number of objects in a thumbnail image.
8 16 The number of bits needed to represent the difference between the greatest
and least number of objects in a thumbnail image.
9 32 The object number of the first object in the thumbnail shared objects section
(a subsection of part 9). This section includes objects (color spaces, for exam-
ple) that are referenced from some or all thumbnail objects and are not refer-
enced from any other objects. The thumbnail shared objects are
undifferentiated; there is no indication of which shared objects are referenced
from any given page’s thumbnail image.
10 32 The location of the first object in the thumbnail shared objects section.
11 32 The number of thumbnail shared objects.
12 32 The length of the thumbnail shared objects section in bytes.
ITEM SIZE (BITS) DESCRIPTION
1 See Table F.7, item 4 (Optional) The number of preceding pages lacking a thumbnail image. This
number indicates how many pages without a thumbnail image lie between
the previous entry’s page and this page.
2 See Table F.7, item 8 A number that, when added to the least number of objects in a thumbnail im-
age (Table F.7, item 7), gives the number of objects in this page’s thumbnail
image.
3 See Table F.7, item 6 A number that, when added to the least length of a thumbnail image (Table
F.7, item 5), gives the length of this page’s thumbnail image in bytes.
ITEM SIZE (BITS) DESCRIPTION
Linearized PDFAPPENDIX F
966
F.3.4 Generic Hint Tables
Certain categories of objects are associated with the document as a whole rather
than with individual pages (see Section F.2.9, “Other Objects (Part 9)”), and it is
sometimes useful to provide hints for accessing those objects efficiently. For each
category of hints, there is a separate entry in the primary hint stream giving the
starting position of the table within the stream (see Section F.2.5, “Hint Streams
(Parts 5 and 10)”).
Such hints may be represented by a generic hint table, which describes a single
group of objects that are located together in the PDF file. The entries in this table
are listed in Table F.9. This representation is used for the following hint tables, if
needed:
• Outline hint table
• Thread information hint table
• Named destination hint table
• Information dictionary hint table
• Page label hint table
Generic hint tables may also be useful for application-specific objects accessed by
plug-in extensions. It is considerably more convenient for a plug-in to use the ge-
neric hint representation than to specify custom hints.
TABLE F.9 Generic hint table
F.3.5 Extended Generic Hint Tables
An extended generic hint table begins with the same entries as in a generic hint
table, followed by three additional entries, as shown in Table F.10. This table is
ITEM SIZE (BITS) DESCRIPTION
1 32 The object number of the first object in the group.
2 32 The location of the first object in the group.
3 32 The number of objects in the group.
4 32 The length of the object group in bytes.
Hint TablesSECTION F.3
967
used to provide hints for accessing objects that reference shared objects. As of
PDF 1.5, the following hint tables, if needed, use the extended generic format:
• Interactive form hint table
• Logical structure hint table
• Renditions name tree hint table
Note: Embedded file streams should not be referred to by this hint table, even if
they are reachable from nodes in the renditions name tree; instead they should use
the hint table described in Section F.3.6, “Embedded File Stream Hint Tables.”
TABLE F.10 Extended generic hint table
F.3.6 Embedded File Stream Hint Tables
The embedded file streams hint table allows a viewer application to locate all byte
ranges of a PDF file needed to access its embedded file streams. An embedded file
stream may be grouped with other objects that it references; all objects in such a
group must have adjacent object numbers. (A group may contain no objects at all
if it contains shared object references.)
This hint table has a header section (see Table F.11), which has general informa-
tion about the embedded file stream groups. The header section is followed by
the entries in Table F.12. Each of the items in Table F.12 is repeated for each em-
ITEM SIZE (BITS) DESCRIPTION
1 32 The object number of the first object in the group.
2 32 The location of the first object in the group.
3 32 The number of objects in the group.
4 32 The length of the object group in bytes.
5 32 The number of shared object references.
6 16 The number of bits needed to represent the numerically greatest shared ob-
ject identifier used by the objects in the group.
7… See Table F.3, item 11 Starting with item 7, each of the remaining items in this table is a shared ob-
ject identifier—that is, an index into the shared object hint table (described in
Section F.3.2, “Shared Object Hint Table”).
Linearized PDFAPPENDIX F
968
bedded file stream group (the number of groups being represented by item 3 in
Table F.11). That is, the order of items in Table F.12 is item 1 for the first group,
item 1 for the second group, and so on; item 2 for the first group, item 2 for the
second group, and so on; repeated for the 5 items.
TABLE F.11 Embedded file stream hint table, header section
TABLE F.12 Embedded file stream hint table, per-embedded file stream group entries
ITEM SIZE (BITS) DESCRIPTION
1 32 The object number of the first object in the first embedded file stream group.
2 32 The location of the first object in the first embedded file stream group.
3 32 The number of embedded file stream groups referenced by this hint table.
4 16 The number of bits needed to represent the highest object number corresponding to an
embedded file stream object.
5 16 The number of bits needed to represent the greatest number of objects in an embedded
file stream group.
6 16 The number of bits needed to represent the greatest length of an embedded file stream
group, in bytes.
7 16 The number of bits needed to represent the greatest number of shared object references
in any embedded file stream group.
ITEM SIZE (BITS) DESCRIPTION
1 See Table F.11, item 4 The object number of the embedded file stream that this entry is associated
with.
2 See Table F.11, item 5 The number of objects in this embedded file streams group. This item may be
0, meaning that there are only shared object references. In this case, item 4 for
this group must be greater than zero and item 3 must be zero.
3 See Table F.11, item 6 The length of this embedded file stream group, in bytes. This item may be 0,
meaning that there are only shared object references. In this case, item 4 for
this group must be greater than zero and item 2 must be zero.
4 See Table F.11, item 7 The number of shared objects referenced by this embedded file stream group.
Access StrategiesSECTION F.4
969
F.4 Access Strategies
This section outlines how the client can take advantage of the structure of a
Linearized PDF file to retrieve and display it efficiently. This material is not for-
mally a part of the Linearized PDF specification, but it may help explain the ratio-
nale for the organization.
F.4.1 Opening at the First Page
As described earlier, when a document is initially accessed, a request is issued to
retrieve the entire file, starting at the beginning. Consequently, Linearized PDF is
organized so that all the data required to display the first page is at the beginning
of the file. This includes all resources that are referenced from the first page, re-
gardless of whether they are also referenced from other pages.
The first page is usually but not necessarily page 0. If the document catalog con-
tains an
OpenAction entry that specifies opening at some page other than page 0,
that page is the one physically located at the beginning of the document. Thus,
opening a document at the default place (rather than a specific destination) re-
quires simply waiting for the first-page data to arrive; no additional transactions
are required.
In an ordinary PDF viewer application, opening a document requires first posi-
tioning to the end to obtain the
startxref line. Since a Linearized PDF file has the
first page’s cross-reference table at the beginning, reading the
startxref line is not
necessary. All that is required is to verify that the file length given in the lineari-
zation parameter dictionary at the beginning of the file matches the actual length
of the file, indicating that no updates have been appended to the PDF file.
The primary hint stream is located either before or after the first-page section,
which means that it is also retrieved as part of the initial sequential read of the
file. The client is expected to interpret and retain all the information in the hint
5 See Table F.3, item 11 A bit-packed list of shared object identifiers; that is, indices into the shared
object hint table (see Section F.3.2, “Shared Object Hint Table”). Item 4 for
this group specifies how many shared object identifiers are associated with
the group.
ITEM SIZE (BITS) DESCRIPTION
Linearized PDFAPPENDIX F
970
tables. The tables are reasonably compact and are not designed to be obtained
from the file in random pieces.
The client must now decide whether to continue reading the remainder of the
document sequentially or to abort the initial transaction and access subsequent
pages by using separate transactions requesting byte ranges. This decision is a
function of the size of the file, the data rate of the channel, and the overhead cost
of a transaction.
F.4.2 Opening at an Arbitrary Page
The viewer application may be requested to open a PDF file at an arbitrary page.
The page can be specified in one of three ways:
• By page number (remote go-to action, integer page specifier)
• By named destination (remote go-to action, name or string page specifier)
• By article thread (thread action)
Additionally, an indexed search results in opening a document by page number.
Handling this case efficiently is especially important.
As indicated above, when the document is initially opened, it is retrieved sequen-
tially starting at the beginning. As soon as the hint tables have been received, the
client has sufficient information to request retrieval of any page of the document
given its page number. Therefore, the client can abort the initial transaction and
issue a new transaction for the target page, as described in Section F.4.3, “Going
to Another Page of an Open Document.”
The position of the primary hint stream (part 5) with respect to the first-page
section (part 6) determines how quickly this can be done. If the primary hint
stream precedes the first-page section, the initial transaction can be aborted very
quickly; however, this is at the cost of increased delay when opening the docu-
ment at the first page. On the other hand, if the primary hint stream follows the
first-page section, displaying the first page is quicker (since the hint tables are not
needed for that), but opening at an arbitrary page is delayed by the time required
to receive the first page. The decision whether to favor opening at the first page or
opening at an arbitrary page must be made at the time a PDF file is linearized.
Access StrategiesSECTION F.4
971
If an overflow hint stream exists, obtaining it requires issuing an additional trans-
action. For this reason, inclusion of an overflow hint stream in Linearized PDF,
although permitted, is not recommended. The feature exists to allow the lineariz-
er to write the PDF file with space reserved for a primary hint stream of an esti-
mated size and then go back and fill in the hint tables. If the estimate is too small,
the linearizer can append an overflow stream containing the remaining hint table
data. Thus, the PDF file can be written in one pass, which may be an advantage if
the performance of writing PDF is considered important.
Opening at a named destination requires the viewer application first to read the
entire
Dests or Names dictionary, for which a hint is present. Using this informa-
tion, it is possible to determine the page containing the specific destination iden-
tified by the name.
Opening to an article requires the viewer application first to read the entire
Threads array, which is located with the document catalog at the beginning of the
document. Using this information, it is possible to determine the page containing
the first bead of any thread. Opening at other than the first bead of a thread re-
quires chaining through all the beads until the desired one is reached; there are
no hints to accelerate this.
F.4.3 Going to Another Page of an Open Document
Given a page number and the information in the hint tables, it is now straight-
forward for the client to construct a single request to retrieve any arbitrary page
of the document. The request should include the following items:
• The objects of the page itself, whose byte range can be determined from the
entry in the page offset hint table.
• The portion of the main cross-reference table referring to those objects. This
can be computed from main cross-reference table location (the
T entry in the
linearization parameter dictionary) and the cumulative object number in the
page offset hint table.
• The shared objects referenced from the page, whose byte ranges can be deter-
mined from information in the shared object hint table.
• The portion or portions of the main cross-reference table referring to those ob-
jects, as described above.
Linearized PDFAPPENDIX F
972
The purpose of the fractions in the page offset hint table is to enable the client to
schedule retrieval of the page in a way that allows incremental display of the data
as it arrives. It accomplishes this by constructing a request that interleaves pieces
of the page contents with the shared resources that the contents refer to. This
serves much the same purpose as the physical interleaving that is done for the
first page.
F.4.4 Drawing a Page Incrementally
The ordering of objects in pages and the organization of the hint tables are in-
tended to allow progressive update of the display and early opportunities for user
interaction when the data is arriving slowly. The viewer application must recog-
nize instances in which the targets of indirect object references have not yet
arrived and, where possible, rearrange the order in which it acts on the objects in
the page.
The following sequence of actions is recommended:
1. Activate the annotations, but do not draw them yet. Also activate the cursor
feedback for any article threads in the page.
2. Begin drawing the contents. Whenever there is a reference to an image
XObject that has not yet arrived, skip over it. Whenever there is a reference to
a font whose definition is an embedded font file that has not yet arrived, draw
the text using a substitute font (if that is possible).
3. Draw the annotations.
4. Draw the images as they arrive, together with anything that overlaps them.
5. Once the embedded font definitions have arrived, redraw the text using the
correct fonts, together with anything that overlaps the text.
The last two steps should be done using an off-screen buffer, if possible, to avoid
objectionable flashing during the redraw process.
On encountering a reference XObject (see Section 4.9.3, “Reference XObjects”),
the viewer application may choose to initially display the object as a proxy and
defer the retrieval and rendering of the imported content. Note that, since all
XObjects in a Linearized PDF file follow the content stream of the page on which
they appear, their retrieval is already deferred; the use of a reference XObject re-
sults in an additional level of deferral.
Access StrategiesSECTION F.4
973
F.4.5 Following an Article Thread
As indicated earlier, the bead dictionaries for any article thread that visits a given
page are located with that page. This enables the bead rectangles to be activated
and proper cursor feedback to be shown.
If the user follows a thread, the viewer application can obtain the object number
from the
N or P entry of the bead dictionary. This identifies a target bead, which
is located with the page to which it belongs. Given this object number, the viewer
application can go to that page, as discussed in Section F.4.3, “Going to Another
Page of an Open Document.”
F.4.6 Accessing an Updated File
As stated earlier, if a Linearized PDF file subsequently has an incremental update
appended to it, the linearization and hints are no longer valid. Actually, this is not
necessarily true, but the viewer application must do some additional work to val-
idate the information.
When the viewer application sees that the file is longer than the length given in
the linearization parameter dictionary, it must issue an additional transaction to
read everything that was appended. It must then analyze the objects in that up-
date to see whether any of them modify objects that are in the first page or that
are the targets of hints. If so, it must augment its internal data structures as neces-
sary to take the updates into account.
For a PDF file that has received only a small update, this approach may be worth-
while. Accessing the file this way is quicker than accessing it without hints or re-
trieving the entire file before displaying any of it.
Linearized PDFAPPENDIX F
974
975
APPENDIX G
GExample PDF Files
This appendix presents several examples showing the structure of actual PDF
files:
• A minimal file that can serve as a starting point for creating other PDF files
(and that is the basis of later examples)
• A simple example that shows a text string—the classic “Hello World”—and a
simple graphics example that draws lines and shapes
• A fragment of a PDF file that illustrates the structure of the page tree for a large
document and, similarly, two fragments that illustrate the structure of an out-
line hierarchy
• An example showing the structure of a PDF file as it is updated several times,
illustrating multiple body sections, cross-reference sections, and trailers
Note: The
Length values of stream objects in the examples and the byte addresses in
cross-reference tables are not necessarily accurate.
G.1 Minimal PDF File
Example G.1 is a PDF file that does not draw anything; it is almost the minimum
acceptable PDF file. It is not strictly the minimum acceptable because it contains
an outline dictionary (
Outlines in the document catalog) with a zero count (in
which case this object would normally be omitted); a page content stream
(
Contents in the page object); and a resource dictionary (Resources in the page
object) containing a
ProcSet array. These objects were included to make this file
useful as a starting point for creating other, more realistic PDF files.
Table G.1 lists the objects in this example.
Example PDF FilesAPPENDIX G
976
TABLE G.1 Objects in minimal example
Note: When using Example G.1 as a starting point for creating other files, remember
to update the
ProcSet array as needed (see Section 10.1, “Procedure Sets”). Also,
remember that the cross-reference table entries may need to have a trailing space
(see Section 3.4.3, “Cross-Reference Table”).
Example G.1
%PDF1.4
1 0 obj
<< /Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
>>
endobj
2 0 obj
<< /Type Outlines
/Count 0
>>
endobj
3 0 obj
<< /Type /Pages
/Kids [4 0 R]
/Count 1
>>
endobj
OBJECT NUMBER OBJECT TYPE
1 Catalog (document catalog)
2
Outlines (outline dictionary)
3
Pages (page tree node)
4
Page (page object)
5Content stream
6 Procedure set array
Minimal PDF FileSECTION G.1
977
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [0 0 612 792]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R >>
>>
endobj
5 0 obj
<< /Length 35 >>
stream
…Page-marking operators…
endstream
endobj
6 0 obj
[/PDF]
endobj
xref
07
0000000000 65535 f
0000000009 00000 n
0000000074 00000 n
0000000120 00000 n
0000000179 00000 n
0000000300 00000 n
0000000384 00000 n
trailer
<< /Size 7
/Root 1 0 R
>>
startxref
408
%%EOF
Example PDF FilesAPPENDIX G
978
G.2 Simple Text String Example
Example G.2 is the classic “Hello World” example built from the preceding exam-
ple. It shows a single line of text consisting of the string
Hello World, illustrating
the use of fonts and several text-related PDF operators. The string is displayed in
24-point Helvetica. Because Helvetica is one of the standard 14 fonts, no font
descriptor is needed.
Table G.2 lists the objects in this example.
TABLE G.2 Objects in simple text string example
Example G.2
%PDF1.4
1 0 obj
<< /Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
>>
endobj
2 0 obj
<< /Type /Outlines
/Count 0
>>
endobj
OBJECT NUMBER OBJECT TYPE
1 Catalog (document catalog)
2
Outlines (outline dictionary)
3
Pages (page tree node)
4
Page (page object)
5Content stream
6 Procedure set array
7
Font (Type 1 font)
Simple Text String ExampleSECTION G.2
979
3 0 obj
<< /Type /Pages
/Kids [4 0 R]
/Count 1
>>
endobj
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [0 0 612 792]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R
/Font << /F1 7 0 R >>
>>
>>
endobj
5 0 obj
<< /Length 73 >>
stream
BT
/F1 24 Tf
100 100 Td
(Hello World) Tj
ET
endstream
endobj
6 0 obj
[/PDF /Text]
endobj
7 0 obj
<< /Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /MacRomanEncoding
>>
endobj
Example PDF FilesAPPENDIX G
980
xref
08
0000000000 65535 f
0000000009 00000 n
0000000074 00000 n
0000000120 00000 n
0000000179 00000 n
0000000364 00000 n
0000000466 00000 n
0000000496 00000 n
trailer
<< /Size 8
/Root 1 0 R
>>
startxref
625
%%EOF
G.3 Simple Graphics Example
Example G.3 draws a thin black line segment, a thick black dashed line segment, a
filled and stroked rectangle, and a filled and stroked cubic Bézier curve. Table G.3
lists the objects in this example, and Figure G.1 shows the resulting output. (Each
shape has a red border, and the rectangle is filled with light blue.)
TABLE G.3 Objects in simple graphics example
OBJECT NUMBER OBJECT TYPE
1 Catalog (document catalog)
2
Outlines (outline dictionary)
3
Pages (page tree node)
4
Page (page object)
5Content stream
6 Procedure set array
Example PDF FilesAPPENDIX G
982
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [0 0 612 792]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R >>
>>
endobj
5 0 obj
<< /Length 883 >>
stream
% Draw a black line segment, using the default line width .
150 250 m
150 350 l
S
% Draw a thicker, dashed line segment.
4 w % Set line width to 4 points
[4 6] 0 d % Set dash pattern to 4 units on, 6 units off
150 250 m
400 250 l
S
[] 0 d % Reset dash pattern to a solid line
1 w % Reset line width to 1 unit
% Draw a rectangle with a 1unit red border, filled with light blue.
1.0 0.0 0.0 RG % Red for stroke color
0.5 0.75 1.0 rg % Light blue for fill color
200 300 50 75 re
B
% Draw a curve filled with gray and with a colored border.
0.5 0.1 0.2 RG
0.7 g
300 300 m
300 400 400 400 400 300 c
b
endstream
endobj
6 0 obj
[/PDF]
endobj
Page Tree ExampleSECTION G.4
983
xref
07
0000000000 65535 f
0000000009 00000 n
0000000074 00000 n
0000000120 00000 n
0000000179 00000 n
0000000300 00000 n
0000001532 00000 n
trailer
<< /Size 7
/Root 1 0 R
>>
startxref
1556
%%EOF
G.4 Page Tree Example
Example G.4 is a fragment of a PDF file illustrating the structure of the page tree
for a large document. It contains the page tree nodes for a 62-page document.
Figure G.2 shows the structure of this page tree. Numbers in the figure are object
numbers corresponding to the objects in the example.
FIGURE G.2 Page tree for Example G.4
337
335
336
4
43 77 108 139 170
201 232 263 294 325
3
16
21
26
31
37
42
48
53
58
63
70
76
82
87
92
97
102
107
113
118
123
128
133
138
144
149
154
159
164
169
175
180
185
190
195
200
206
211
216
221
226
231
237
242
247
252
257
262
268
273
278
283
288
293
299
304
309
314
319
324
330
Example PDF FilesAPPENDIX G
984
Example G.4
337 0 obj
<< /Type /Pages
/Kids [ 335 0 R
336 0 R
]
/Count 62
>>
endobj
335 0 obj
<< /Type /Pages
/Parent 337 0 R
/Kids [ 4 0 R
43 0 R
77 0 R
108 0 R
139 0 R
170 0 R
]
/Count 36
>>
endobj
336 0 obj
<< /Type /Pages
/Parent 337 0 R
/Kids [ 201 0 R
232 0 R
263 0 R
294 0 R
325 0 R
]
/Count 26
>>
endobj
Page Tree ExampleSECTION G.4
985
4 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids [ 3 0 R
16 0 R
21 0 R
26 0 R
31 0 R
37 0 R
]
/Count 6
>>
endobj
43 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids [ 42 0 R
48 0 R
53 0 R
58 0 R
63 0 R
70 0 R
]
/Count 6
>>
endobj
77 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids [ 76 0 R
82 0 R
87 0 R
92 0 R
97 0 R
102 0 R
]
/Count 6
>>
endobj
Example PDF FilesAPPENDIX G
986
108 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids [ 107 0 R
113 0 R
118 0 R
123 0 R
128 0 R
133 0 R
]
/Count 6
>>
endobj
139 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids [ 138 0 R
144 0 R
149 0 R
154 0 R
159 0 R
164 0 R
]
/Count 6
>>
endobj
170 0 obj
<< /Type /Pages
/Parent 335 0 R
/Kids [ 169 0 R
175 0 R
180 0 R
185 0 R
190 0 R
195 0 R
]
/Count 6
>>
endobj
Page Tree ExampleSECTION G.4
987
201 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids [ 200 0 R
206 0 R
211 0 R
216 0 R
221 0 R
226 0 R
]
/Count 6
>>
endobj
232 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids [ 231 0 R
237 0 R
242 0 R
247 0 R
252 0 R
257 0 R
]
/Count 6
>>
endobj
263 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids [ 262 0 R
268 0 R
273 0 R
278 0 R
283 0 R
288 0 R
]
/Count 6
>>
endobj
Example PDF FilesAPPENDIX G
988
294 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids [ 293 0 R
299 0 R
304 0 R
309 0 R
314 0 R
319 0 R
]
/Count 6
>>
endobj
325 0 obj
<< /Type /Pages
/Parent 336 0 R
/Kids [ 324 0 R
330 0 R
]
/Count 2
>>
endobj
G.5 Outline Hierarchy Example
This section from a PDF file illustrates the structure of an outline hierarchy with
six items. Example G.5 shows the outline with all items open, as illustrated in
Figure G.3.
FIGURE G.3 Document outline as displayed in Example G.5
Document
Section 1
Section 2
Subsection 1
Section 3
Summary
On-screen appearance
Object
number
Count
22
25
26
27
28
29
4
0
1
0
0
0
621
Outline Hierarchy ExampleSECTION G.5
989
Example G.5
21 0 obj
<< /Type /Outlines
/First 22 0 R
/Last 29 0 R
/Count 6
>>
endobj
22 0 obj
<< /Title (Document)
/Parent 21 0 R
/Next 29 0 R
/First 25 0 R
/Last 28 0 R
/Count 4
/Dest [3 0 R /XYZ 0 792 0]
>>
endobj
25 0 obj
<< /Title (Section 1)
/Parent 22 0 R
/Next 26 0 R
/Dest [3 0 R /XYZ null 701 null]
>>
endobj
26 0 obj
<< /Title (Section 2)
/Parent 22 0 R
/Prev 25 0 R
/Next 28 0 R
/First 27 0 R
/Last 27 0 R
/Count 1
/Dest [3 0 R /XYZ null 680 null]
>>
endobj
Example PDF FilesAPPENDIX G
990
27 0 obj
<< /Title (Subsection 1)
/Parent 26 0 R
/Dest [3 0 R /XYZ null 670 null]
>>
endobj
28 0 obj
<< /Title (Section 3)
/Parent 22 0 R
/Prev 26 0 R
/Dest [7 0 R /XYZ null 500 null]
>>
endobj
29 0 obj
<< /Title (Summary)
/Parent 21 0 R
/Prev 22 0 R
/Dest [8 0 R /XYZ null 199 null]
>>
endobj
Example G.6 is the same as Example G.5, except that one of the outline items has
been closed in the display. The outline appears as shown in Figure G.4.
FIGURE G.4 Document outline as displayed in Example G.6
On-screen appearance
Object
number
Count
Document
Section 1
Section 2
Section 3
Summary
22
25
26
28
29
3
0
–1
0
0
521
Outline Hierarchy ExampleSECTION G.5
991
Example G.6
21 0 obj
<< /Type /Outlines
/First 22 0 R
/Last 29 0 R
/Count 5
>>
endobj
22 0 obj
<< /Title (Document)
/Parent 21 0 R
/Next 29 0 R
/First 25 0 R
/Last 28 0 R
/Count 3
/Dest [3 0 R /XYZ 0 792 0]
>>
endobj
25 0 obj
<< /Title (Section 1)
/Parent 22 0 R
/Next 26 0 R
/Dest [3 0 R /XYZ null 701 null]
>>
endobj
26 0 obj
<< /Title (Section 2)
/Parent 22 0 R
/Prev 25 0 R
/Next 28 0 R
/First 27 0 R
/Last 27 0 R
/Count 1
/Dest [3 0 R /XYZ null 680 null]
>>
endobj
Example PDF FilesAPPENDIX G
992
27 0 obj
<< /Title (Subsection 1)
/Parent 26 0 R
/Dest [3 0 R /XYZ null 670 null]
>>
endobj
28 0 obj
<< /Title (Section 3)
/Parent 22 0 R
/Prev 26 0 R
/Dest [7 0 R /XYZ null 500 null]
>>
endobj
29 0 obj
<< /Title (Summary)
/Parent 21 0 R
/Prev 22 0 R
/Dest [8 0 R /XYZ null 199 null]
>>
endobj
G.6 Updating Example
This example shows the structure of a PDF file as it is updated several times; it
illustrates multiple body sections, cross-reference sections, and trailers. In addi-
tion, it shows that once an object has been assigned an object identifier, it keeps
that identifier until the object is deleted, even if the object is altered. Finally, the
example illustrates the reuse of cross-reference entries for objects that have been
deleted, along with the incrementing of the generation number after an object has
been deleted.
The original file is the one shown in Example G.1 on page 976. The updates are
divided into four stages, with the file saved after each stage:
1. Four text annotations are added.
2. The text of one of the annotations is altered.
3. Two of the text annotations are deleted.
4. Three text annotations are added.
Updating ExampleSECTION G.6
993
The sections following show the segments added to the file at each stage.
Throughout this example, objects are referred to by their object identifiers, which
are made up of the object number and the generation number, rather than simply
by their object numbers as in earlier examples. This is necessary because the ex-
ample reuses object numbers; therefore, the objects they denote are not unique.
Note: The tables in these sections show only those objects that are modified during
the updating process. Objects from Example G.1 that are not altered during the up-
date are not shown.
G.6.1 Stage 1: Add Four Text Annotations
Four text annotations are added to the initial file and the file is saved. Table G.4
lists the objects involved in this update.
TABLE G.4 Object usage after adding four text annotations
Example G.7 shows the lines added to the file by this update. The page object is
updated because an
Annots entry has been added to it. Note that the file’s trailer
now contains a
Prev entry, which points to the original cross-reference section in
the file, while the
startxref value at the end of the trailer points to the cross-
reference section added by the update.
OBJECT IDENTIFIER OBJECT TYPE
40 Page (page object)
7 0 Annotation array
80
Annot (annotation dictionary)
90
Annot (annotation dictionary)
10 0
Annot (annotation dictionary)
11 0
Annot (annotation dictionary)
Example PDF FilesAPPENDIX G
994
Example G.7
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [0 0 612 792]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R >>
/Annots 7 0 R
>>
endobj
7 0 obj
[ 8 0 R
9 0 R
10 0 R
11 0 R
]
endobj
8 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [44 616 162 735]
/Contents (Text #1)
/Open true
>>
endobj
9 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [224 668 457 735]
/Contents (Text #2)
/Open false
>>
endobj
10 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [239 393 328 622]
/Contents (Text #3)
/Open true
>>
endobj
Updating ExampleSECTION G.6
995
11 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [34 398 225 575]
/Contents (Text #4)
/Open false
>>
endobj
xref
01
0000000000 65535 f
41
0000000632 00000 n
75
0000000810 00000 n
0000000883 00000 n
0000001024 00000 n
0000001167 00000 n
0000001309 00000 n
trailer
<< /Size 12
/Root 1 0 R
/Prev 408
>>
startxref
1452
%%EOF
G.6.2 Stage 2: Modify Text of One Annotation
One text annotation is modified and the file is saved. Example G.8 shows the lines
added to the file by this update. Note that the file now contains two copies of the
object with identifier
10 0 (the text annotation that was modified) and that the
added cross-reference section points to the more recent version of the object.
This added cross-reference section contains one subsection, which contains only
an entry for the object that was modified. In addition, the
Prev entry in the file’s
trailer has been updated to point to the cross-reference section added in the pre-
vious stage, while the
startxref value at the end of the trailer points to the newly
added cross-reference section.
Example PDF FilesAPPENDIX G
996
Example G.8
10 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [239 393 328 622]
/Contents (Modified Text #3)
/Open true
>>
endobj
xref
01
0000000000 65535 f
10 1
0000001703 00000 n
trailer
<< /Size 12
/Root 1 0 R
/Prev 1452
>>
startxref
1855
%%EOF
G.6.3 Stage 3: Delete Two Annotations
Two text annotation are deleted and the file is saved. Table G.5 lists the objects
updated.
TABLE G.5 Object usage after deleting two text annotations
The Annots array is the only object that is written in this update. It is updated be-
cause it now contains two annotations fewer.
OBJECT IDENTIFIER OBJECT TYPE
7 0 Annotation array
80 Free
90 Free
Updating ExampleSECTION G.6
997
Example G.9 shows the lines added when the file was saved. Note that objects
with identifiers
8 0 and 9 0 have been deleted, as can be seen from the fact that
their entries in the cross-reference section end with the keyword
f.
Example G.9
7 0 obj
[ 10 0 R
11 0 R
]
endobj
xref
01
0000000008 65535 f
73
0000001978 00000 n
0000000009 00001 f
0000000000 00001 f
trailer
<< /Size 12
/Root 1 0 R
/Prev 1855
>>
startxref
2027
%%EOF
The cross-reference section added at this stage contains four entries, representing
object number 0, the
Annots array, and the two deleted text annotations.
• The cross-reference entry for object number 0 is updated because it is the head
of the linked list of free entries and must now point to the entry for the newly
freed object number 8. The entry for object number 8 points to the entry for
object number 9 (the next free entry), while the entry for object number 9 is the
last free entry in the cross-reference table, indicated by the fact that it points
back to object number 0.
• The entries for the two deleted text annotations are marked as free and as
having generation numbers of 1, which are used for any objects that reuse these
cross-reference entries. Keep in mind that, although the two objects have been
deleted, they are still present in the file. It is the cross-reference table that
records the fact that they have been deleted.
Example PDF FilesAPPENDIX G
998
The Prev entry in the trailer has again been updated so that it points to the cross-
reference section added at the previous stage, and the
startxref value points to the
newly added cross-reference section.
G.6.4 Stage 4: Add Three Annotations
Finally, three new text annotations are added to the file. Table G.6 lists the objects
involved in this update.
TABLE G.6 Object usage after adding three text annotations
Object numbers 8 and 9, which were used for the two annotations deleted in the
previous stage, have been reused; however, the new objects have been given a
generation number of 1. In addition, the third text annotation added has been
assigned the previously unused object identifier of
12 0.
Example G.10 shows the lines added to the file by this update. The added cross-
reference section contains five entries, corresponding to object number 0, the
Annots array, and the three annotations added. The entry for object number 0 is
updated because the previously free entries for object numbers 8 and 9 have been
reused. The entry for object number 0 now shows that the cross-reference table
has no free entries. The
Annots array is updated to reflect the addition of the
three text annotations.
Example G.10
7 0 obj
[ 10 0 R
11 0 R
8 1 R
9 1 R
12 0 R
]
endobj
OBJECT IDENTIFIER OBJECT TYPE
7 0 Annotation array
81
Annot (annotation dictionary)
91
Annot (annotation dictionary)
12 0
Annot (annotation dictionary)
Updating ExampleSECTION G.6
999
8 1 obj
<< /Type /Annot
/Subtype /Text
/Rect [58 657 172 742]
/Contents (New Text #1)
/Open true
>>
endobj
9 1 obj
<< /Type /Annot
/Subtype /Text
/Rect [389 459 570 537]
/Contents (New Text #2)
/Open false
>>
endobj
12 0 obj
<< /Type /Annot
/Subtype /Text
/Rect [44 253 473 337]
/Contents (New Text #3\203a longer text annotation which we will continue \
onto a second line)
/Open true
>>
endobj
xref
01
0000000000 65535 f
73
0000002216 00000 n
0000002302 00001 n
0000002447 00001 n
12 1
0000002594 00000 n
trailer
<< /Size 13
/Root 1 0 R
/Prev 2027
>>
startxref
2814
%%EOF
Example PDF FilesAPPENDIX G
1000
The annotation with object identifier 12 0 illustrates splitting a long text string
across multiple lines, as well as the technique for including nonstandard charac-
ters in a string. In this case, the character is an ellipsis (…), which is character
code 203 (octal) in
PDFDocEncoding, the encoding used for text annotations.
As in previous updates, the trailer’s
Prev entry and startxref value have been
updated.
1001
APPENDIX H
HCompatibility and
Implementation Notes
The goal of the Acrobat family of products is to enable people to exchange and
view electronic documents easily and reliably. Ideally, this means that any Acro-
bat viewer application should be able to display the contents of any PDF file, even
if the PDF file was created long before or long after the viewer application. Of
course, new versions of viewer applications are introduced to provide additional
capabilities not present before. Furthermore, beginning with Acrobat 2.0, viewer
applications may accept plug-in extensions, making some Acrobat viewers more
capable than others, depending on what extensions are present.
Both viewer applications and PDF have been designed to enable users to view ev-
erything in the document that the viewer application understands and to ignore
or inform the user about objects not understood. The decision whether to ignore
or inform the user is made on a feature-by-feature basis.
The original PDF specification did not define how a viewer application should
behave when it reads a file that does not conform to the specification. This ap-
pendix provides that information. The PDF version associated with a file deter-
mines how it should be treated when a viewer application encounters a problem.
In addition, this appendix includes notes on the Acrobat implementation for de-
tails that are not strictly defined by the PDF specifications.
H.1 PDF Version Numbers
PDF version numbers take the form M.m, where M is the major and m the minor
version number. Adobe increments the major version number when the PDF
specification changes in such a way that existing viewer applications are unlikely
to read a document without serious errors that prevent pages from being viewed.
Compatibility and Implementation NotesAPPENDIX H
1002
The minor version number is incremented if the changes do not prevent existing
viewer applications from continuing to work, such as the addition of new page
description operators. The version number does not change at all if PDF changes
in a way that existing viewer applications are unlikely to detect. Such changes
might include the addition of private data, such as additional entries in the docu-
ment catalog, that can be gracefully ignored by applications that do not under-
stand it.
The header in the first line of a PDF file specifies a PDF version (see Section 3.4.1,
“File Header”). In PDF 1.4, a PDF version can also be specified in the
Version en-
try of the document catalog, essentially updating the version associated with the
file by overriding the one specified in the file header (see Section 3.6.1, “Docu-
ment Catalog”). As described in the following paragraphs, the viewer applica-
tion’s behavior upon opening or saving a document depends on what it perceives
to be the document’s PDF version (compared to the viewer’s native file format—
for example, PDF 1.3 for Acrobat 4.0—which is also referred to as the viewer’s
PDF version). Viewers that are not PDF 1.4–aware may perceive the document’s
version incorrectly, because they look for it only in the PDF file’s header and do
not see the version (if any) specified in the document catalog.
An Acrobat viewer attempts to read any PDF file, even if the file’s version is more
recent than that of the viewer. It reads without errors any file that does not re-
quire a plug-in extension, even if the file’s version is older than the viewer’s. Some
documents may require a plug-in to display an annotation, follow a link, or exe-
cute an action. Viewer behavior in this situation is described in Section H.3, “Im-
plementation Notes.” However, a plug-in is never required to display the contents
of a page.
If a viewer application opens a document with a major version number newer
than it expects, it warns the user that it is unlikely to be able to read the document
successfully and that the user cannot change or save the document. At the first er-
ror related to document processing, the viewer notifies the user that an error has
occurred but that no further errors will be reported. (Some errors are always re-
ported, including file I/O errors, extension loading errors, out-of-memory errors,
and notifications that a command has failed.) Processing continues if possible.
Acrobat does not permit a document that has a newer-than-expected major ver-
sion number to be inserted into another document.
If a viewer application opens a document that has a minor version number newer
than it expects, it notifies the user that the document may contain information
PDF Version NumbersSECTION H.1
1003
the viewer does not understand. (This describes the behavior in Acrobat 5.0 and
later; earlier versions do not notify the user.) If the viewer encounters an error, it
notifies the user that the document version is newer than expected, an error has
occurred, and no further errors will be reported. Acrobat permits a document
with a newer minor version to be inserted into another document.
Whether and how the version of a document changes when the document is
modified and saved depends on several factors. If the document has a newer ver-
sion than expected, the viewer does not alter the version—that is, a document’s
version is never changed to an older version. If the document has an older version
than expected, the viewer updates the document’s version to match the viewer’s
version. If a user modifies a document by inserting another document into it, the
saved document’s version is the most recent of the viewer’s version, the docu-
ment’s original version, and the inserted document’s version.
If the version of a document changes, viewers that are not PDF 1.4–aware cannot
save the document by using an incremental update because updating the header
requires rewriting the entire file. Among other disadvantages, rewriting the file
can cause existing digital signatures to become invalid. Since viewers that are
PDF 1.4–aware can use the
Version entry in the document catalog to update the
document’s version, they can incrementally save the document (and will do so if
necessary to preserve existing signatures). For example, if an Acrobat 5.0 user
modifies a document that has a PDF version earlier than 1.4, the document can
be updated incrementally when saved (with the updated version of 1.4 in the doc-
ument catalog). However, if an Acrobat 4.0 user modifies a document that has a
PDF version earlier than 1.3, the entire file is rewritten when saved (with a new
header indicating version 1.3).
Again, the preceding discussion of viewer behavior applies to what the viewer
perceives to be a document’s PDF version, which may be different from the doc-
ument’s actual version if the viewer does not look for the
Version entry in the
document’s catalog (a PDF 1.4 feature). One consequence is that a file may be re-
written when it could have been incrementally updated. For example, suppose an
Acrobat 4.0 user opens a document that has a version of 1.4 (newer than expect-
Compatibility and Implementation NotesAPPENDIX H
1004
ed) specified in the catalog’s Version entry. Acrobat 4.0 determines the version by
looking only at the document’s header. There are two cases to consider:
• The header specifies version 1.2 or earlier. If the user alters and saves the docu-
ment, the viewer updates the document’s version to match its own by rewriting
the file with a new header indicating version 1.3.
• The header specifies version 1.3 or later. If the user alters and saves the docu-
ment, the viewer allows the file to be incrementally updated, since it does not
believe the version needs updating.
In both cases, the version number in the document catalog is maintained at 1.4,
and later versions of Acrobat will recognize the correct version number.
H.2 Feature Compatibility
Many PDF features are introduced simply by adding new entries to existing dic-
tionaries. Earlier versions of viewer applications do not notice the existence of
such entries and behave as if they were not there. Such new features are therefore
both forward- and backward-compatible. Likewise, adding entries not described
in the PDF specification to dictionary objects does not affect the viewers’ behav-
ior. (See Appendix E for information on how to choose key names that are com-
patible with future versions of PDF.)
In some cases, a new feature is impossible to ignore, because doing so would pre-
clude some vital operation such as viewing or printing a page. For instance, if a
page’s content stream is encoded with some new type of filter, there is no way to
view or print the page, even though the content stream (if decoded) would be
perfectly understood by the viewer. There is little choice but to give an error in
cases like these. Such new features are forward-compatible but not backward-
compatible.
In a few cases, new features are defined in a way that earlier viewer versions will
ignore, but the output will be degraded in some way without any error indication.
The most significant example of this is transparency. All of the transparency fea-
tures introduced in PDF 1.4 are defined as new entries in existing dictionaries
(including the graphics state parameter dictionary). A viewer that does not un-
derstand transparency treats transparency group XObjects as if they were opaque
form XObjects. This is a significant enough deviation from the intended behavior
Implementation NotesSECTION H.3
1005
that it is worth pointing out as a compatibility issue (and so is covered in imple-
mentation notes in this appendix).
If a PDF document undergoes editing by an application that does not understand
some of the features that the document uses, the occurrences of those features
may or may not survive. If a dictionary object such as an annotation is copied
into another document during a page insertion (or, beginning with Acrobat 2.0,
during a page extraction), all entries are copied. If a value is an indirect reference
to another object, that object may be copied as well, depending on the entry.
H.3 Implementation Notes
This section gives notes on the implementation of Acrobat and on compatibility
between different versions of PDF. The notes are listed in the order of the sections
to which they refer in the main text.
1.2, “Introduction to PDF 1.6 Features”
1. The native file formats of Acrobat products are PDF 1.2 for Acrobat 3.0,
PDF 1.3 for Acrobat 4.0, PDF 1.4 for Acrobat 5.0, PDF 1.5 for Acrobat 6.0,
and PDF 1.6 for Acrobat 7.0.
3.1.2, “Comments”
2. Acrobat viewers do not preserve comments when saving a file.
3.2.4, “Name Objects”
3. In PDF 1.1, the number sign character (#) could be used as part of a name
(for example,
/A#B), and the specifications did not specifically prohibit
embedded spaces (although Adobe producer applications did not provide
a way to write names containing them). In PDF 1.2, the number sign be-
came an escape character, preceding two hexadecimal digits. Thus, a
3-character name
A-space-B can now be written as /A#20B (since 20 is the
hexadecimal code for the space character). This means that the name
/A#B
is no longer valid, since the number sign is not followed by two hexadeci-
mal digits. A name object with this value must be written as
/A#23B, since
23 is the hexadecimal code for the character #.
Compatibility and Implementation NotesAPPENDIX H
1006
4. In cases where a PostScript name must be preserved or where a string is
permitted in PostScript but not in PDF, the Acrobat Distiller application
uses the
# convention as necessary. When an Acrobat viewer generates
PostScript, it inverts the convention by writing a string where permitted
or a name otherwise. For example, if the string
(Adobe Green) were used
as a key in a dictionary, Distiller would use the name
/Adobe#20Green and
the viewer would generate
(Adobe Green).
5. In Acrobat 4.0 and earlier versions, a name object being treated as text is
typically interpreted in a host platform encoding, which depends on the
operating system and the local language. For Asian languages, this
encoding may be something like Shift-JIS or Big Five. Consequently, it is
necessary to distinguish between names encoded this way and ones
encoded as UTF-8. Fortunately, UTF-8 encoding is very stylized and its
use can usually be recognized. A name that does not conform to UTF-8
encoding rules can instead be interpreted according to host platform en-
coding.
3.2.7, “Stream Objects”
6. When a stream specifies an external file, PDF 1.1 parsers ignore the file
and always use the bytes between
stream and endstream.
7. Acrobat viewers accept the name
DP as an abbreviation for the
DecodeParms key in any stream dictionary. If both DP and DecodeParms
entries are present, DecodeParms takes precedence.
3.2.9, “Indirect Objects”
8. Acrobat viewers require that the name object used as a key in a dictionary
entry be a direct object; an indirect object reference to a name is not ac-
cepted.
3.3, “Filters”
9. Acrobat viewers accept the abbreviated filter names shown in Table H.1 in
addition to the standard ones. Although the abbreviated names are
intended for use only in the context of inline images (see Section 4.8.6,
“Inline Images”), they are also accepted as filter names in any stream
object.
Implementation NotesSECTION H.3
1007
TABLE H.1 Abbreviations for standard filter names
10. If an unrecognized filter is encountered, Acrobat viewers report the con-
text in which the filter was found. If errors occur while a page is being dis-
played, only the first error is reported. The subsequent behavior depends
on the context, as described in Table H.2. Acrobat operations that process
pages, such as the Find command and the Create Thumbnails command,
stop as soon as an error occurs.
TABLE H.2 Acrobat behavior with unknown filters
STANDARD FILTER NAME ABBREVIATION
ASCIIHexDecode
AHx
ASCII85Decode
A85
LZWDecode
LZW
FlateDecode
(PDF 1.2) Fl (uppercase F, lowercase L)
RunLengthDecode
RL
CCITTFaxDecode
CCF
DCTDecode
DCT
CONTEXT BEHAVIOR
Content stream Page processing stops.
Indexed color space The image does not appear, but page processing continues.
Image resource The image does not appear, but page processing continues.
Inline image Page processing stops.
Thumbnail image An error is reported and no more thumbnail images are dis-
played, but the thumbnails can be deleted and created
again.
Form XObject The form does not appear, but page processing continues.
Type 3 glyph description The glyph does not appear, but page processing continues.
The text position is adjusted based on the glyph width.
Embedded font The viewer behaves as if the font is not embedded.
Compatibility and Implementation NotesAPPENDIX H
1008
3.3.7, “DCTDecode Filter”
11. Acrobat 4.0 and later viewers do not support the combination of the
DCTDecode filter with any other filter if the encoded data uses the pro-
gressive JPEG format. If a version of the Acrobat viewer earlier than 4.0
encounters
DCTDecode data encoded in progressive JPEG format, an er-
ror occurs that is handled according to Table H.2.
3.4, “File Structure”
12. Acrobat viewers do not enforce the restriction on line length.
3.4.1, “File Header”
13. Acrobat viewers require only that the header appear somewhere within
the first 1024 bytes of the file.
14. Acrobat viewers also accept a header of the form
%!PSAdobeN.n PDFM.m
3.4.3, “Cross-Reference Table”
15. Acrobat viewers do not enforce the restriction on object numbers existing
in more than one subsection; they use the entry in the first subsection
where the object number is encountered. However, overlap is explicitly
prohibited in cross-reference streams in PDF 1.5.
16. Acrobat 6.0 and later do not use the free list to recycle object numbers;
new objects are assigned new numbers.
17. Acrobat viewers do not raise an error in cases where there are gaps in the
sequence of object numbers between cross-reference subsections. The
missing object numbers are treated as free objects.
3.4.4, “File Trailer”
18. Acrobat viewers require only that the %%EOF marker appear somewhere
within the last 1024 bytes of the file.
Implementation NotesSECTION H.3
1009
3.4.6, “Object Streams”
19. When creating or saving PDF files, Acrobat 6.0 limits the number of ob-
jects in individual object streams to 100 for linearized files and 200 for
non-linearized files.
3.4.7, “Cross-Reference Streams
20. FlateDecode is the only filter supported by Acrobat 6.0 and later viewers
for cross-reference streams. These viewers also support unencoded cross-
reference steams.
3.5, “Encryption”
21. An option to use an unpublished algorithm was needed because of an ex-
port requirement of the U.S. Department of Commerce. This requirement
no longer exists. Acrobat 7.0 does not use this algorithm to encrypt docu-
ments, although it can decrypt files that are encrypted with the algorithm.
22. Acrobat viewers will fail to open a document encrypted with a
V value de-
fined in a version of PDF that the viewer does not understand.
23. Security handlers are responsible for protecting the value of
EFF from
tampering if needed. Acrobat security handlers do not provide this protec-
tion.
3.5.2, “Standard Security Handler” (Standard Encryption Dictionary)
24. Acrobat viewers implement this limited mode of printing as “Print As Im-
age,” except on UNIX systems, where this feature is not available.
3.5.2, “Standard Security Handler” (Encryption Key Algorithm)
25. The first element of the ID array generally remains the same for a given
document. However, in some situations, Acrobat may regenerate the
ID ar-
ray if a new generation of a document is created. Security handlers are en-
couraged not to rely on the
ID in the encryption key computation.
3.5.2, “Standard Security Handler” (Password Algorithms)
26. In Acrobat 2.0 and 2.1 viewers, the standard security handler uses the
empty string if there is no owner password in step 1 of Algorithm 3.3.
Compatibility and Implementation NotesAPPENDIX H
1010
3.5.4, “Crypt Filters”
27. In Acrobat 6.0, crypt filter usage is limited to allowing document-level
metadata streams to be left as plaintext in an otherwise encrypted docu-
ment. In Acrobat 7.0, crypt filter usage also includes the ability to encrypt
embedded files while leaving the remainder of the document as plaintext.
28. In Acrobat 6.0 and later, when strings and streams in an encrypted docu-
ment are edited, those streams and strings are encrypted with the
StmF
and StrF filters, respectively. In Acrobat 7.0, if the EFF entry in the encryp-
tion dictionary is set, embedded files are encrypted with the crypt filter
specified by the
EFF entry. In both Acrobat 6.0 and 7.0, if the security han-
dler indicates that document-level metadata is to be in plaintext, the meta-
data will not be encrypted. It is up to individual security handlers to store
their own flags that indicate whether document-level metadata should be
in plaintext.
29. Acrobat viewers do not support the ability for third-party security han-
dlers to specify
None as a value for CFM.
30. In the file specification dictionary (see Section 3.10.2, “File Specification
Dictionaries”), related files (
RF) must use the same crypt filter as the em-
bedded file (
EF).
31. The value of the
EncryptMetadata entry is set by the security handler
rather than the Acrobat viewer application.
3.6.1, “Document Catalog”
32. Acrobat 5.0 and Acrobat 6.0 avoid adding a Version entry to the document
catalog and do so only if necessary. Once they have added this entry, they
behave in this way:
• Acrobat 5.0 never removes the Version entry. For documents containing
a
Version entry, Acrobat 5.0 attempts to ensure that the version specified
in the header matches the version specified in the
Version entry; if this is
not possible, it at least ensures that the latter is later than (and therefore
overrides) the version specified in the header.
• Acrobat 6.0 removes the Version entry when doing a full (non-incre-
mental) save of the document.
Implementation NotesSECTION H.3
1011
33. An earlier version of this specification documented the PageLayout entry
as being in the viewer preferences dictionary (see Section 8.1, “Viewer
Preferences”); it is actually implemented in the document catalog instead.
34. In PDF 1.2, an additional entry in the document catalog, named
AA, was
defined but was never implemented. The
AA entry that is newly intro-
duced in PDF 1.4 is entirely different from the one that was contemplated
for PDF 1.2.
3.6.2, “Page Tree” (Page Objects)
35. In PDF 1.2, an additional entry in the page object, named Hid, was defined
but was never implemented. Beginning with PDF 1.3, this entry is obso-
lete and should be ignored.
36. Acrobat 5.0 and later viewers do not accept a
Contents array containing
no elements.
37. In a document containing articles, if the first page that has an article bead
does not have a
B entry, Acrobat viewers rebuild the B array for all pages of
the document.
38. In PDF 1.2, additional-actions dictionaries were inheritable; beginning
with PDF 1.3, they are not inheritable.
3.7.1, “Content Streams”
39. Acrobat viewers report an error the first time they find an unknown oper-
ator or an operator with too few operands, but continue processing the
content stream. No further errors are reported.
3.9.1, “Type 0 (Sampled) Functions”
40. When printing, Acrobat performs only linear interpolation, regardless of
the value of the
Order entry.
3.9.2, “Type 2 (Exponential Interpolation) Functions”
41. Since Type 2 functions are not defined in PDF 1.2 or earlier versions,
Acrobat 3.0 (whose native file format is PDF 1.2) reports an Invalid Func-
tion Resource error if it encounters a function of this type.
Compatibility and Implementation NotesAPPENDIX H
1012
3.9.3, “Type 3 (Stitching) Functions”
42. Since Type 3 functions are not defined in PDF 1.2 or earlier versions,
Acrobat 3.0 (whose native file format is PDF 1.2) reports an error, “Invalid
Function Resource,” if it encounters a function of this type.
3.9.4, “Type 4 (PostScript Calculator) Functions”
43. Since Type 4 functions are not defined in PDF 1.2 or earlier versions,
Acrobat 3.0 (whose native file format is PDF 1.2) reports an error, “Invalid
Function Resource,” if it encounters a function of this type.
44. Acrobat uses single-precision floating-point numbers for all real-number
operations in a type 4 function.
3.10.2, “File Specification Dictionaries”
45. In Acrobat 5.0, file specifications accessed through EmbeddedFiles have a
Type entry whose value is F instead of the correct Filespec. Acrobat 6.0
and later accept a file specification whose
Type entry is either Filespec or F.
4.5.2, “Color Space Families”
46. If an Acrobat viewer encounters an unknown color space family name, it
displays an error specifying the name, but reports no further errors there-
after.
4.5.5, “Special Color Spaces” (DeviceN Color Spaces)
47. Acrobat viewers support the special meaning of None only when a
DeviceN color space is used as a base color for an indexed color space. For
all other uses of
DeviceN, None is treated as a regular spot color name.
4.5.5, “Special Color Spaces” (Multitone Examples)
48. This method of representing multitones is used by Adobe Photoshop 5.0.2
and subsequent versions when exporting EPS files. Beginning with ver-
sion 4.0, Acrobat exports Level 3 EPS files using this method, and can also
export Level 1 EPS files that use the “Level 1 separation” conventions of
Adobe Technical Note #5044, Color Separation Conventions for PostScript
Language Programs. These conventions are used to emit multitone images
Implementation NotesSECTION H.3
1013
as calls to “customcolorimage” with overprinting, which can then be
placed in page layout applications such as Adobe PageMaker
®
, Adobe In-
Design, and QuarkXPress.
4.6, “Patterns”
49. Acrobat viewers earlier than version 4.0 do not display patterns on the
screen, although they do print them to PostScript output devices.
4.7, “External Objects”
50. Acrobat viewers that encounter an XObject of an unknown type display
an error specifying the type of XObject but report no further errors there-
after.
4.8.4, “Image Dictionaries”
51. Image XObjects in PDF 1.2 and earlier versions are all implicitly un-
masked images. A PDF consumer that does not recognize the
Mask entry
treats the image as unmasked without raising an error.
52. All Acrobat viewers ignore the
Name entry in an image dictionary.
4.8.5, “Masked Images”
53. Explicit masking and color key masking are features of PostScript Lan-
guageLevel 3. Acrobat 4.0 and later versions do not attempt to emulate the
effect of masked images when printing to LanguageLevel 1 or Lan-
guageLevel 2 output devices; they print the base image without the mask.
The Acrobat 4.0 viewer displays masked images, but only when the
amount of data in the mask is below a certain limit. Above that, the viewer
displays the base image without the mask.
4.9.1, “Form Dictionaries”
54. All Acrobat viewers ignore the Name entry in a form dictionary.
4.9.3, “Reference XObjects
55. Acrobat 6.0 and earlier viewers do not implement reference XObjects. The
proxy is always used for viewing and printing.
Compatibility and Implementation NotesAPPENDIX H
1014
5.2.5, “Text Rendering Mode”
56. In Acrobat 4.05 and earlier versions, text-showing operators such as Tj
first perform the fills for all the glyphs in the string being shown, followed
by the strokes for all the glyphs. This produces incorrect results if glyphs
overlap.
5.3.2, “Text-Showing Operators”
57. In versions of Acrobat earlier than 3.0, the horizontal coordinate of the
text position after the
TJ operator paints a character glyph and moves by
any specified offset must not be less than it was before the glyph was
painted.
58. In Acrobat 4.0 and earlier viewers, position adjustments specified by num-
bers in a
TJ array are performed incorrectly if the horizontal scaling pa-
rameter, T
h
, is different from its default value of 100.
5.5.1, “Type 1 Fonts”
59. All Acrobat viewers ignore the Name entry in a font dictionary.
60. Acrobat 5.0 and later viewers use the glyph widths stored in the font dic-
tionary to override the widths of glyphs in the font program itself, which
improves the consistency of the display and printing of the document.
This addresses the situation in which the font program used by the viewer
application is different from the one used by the application that produced
the document.
The font program with the altered glyph widths may or may not be em-
bedded. If it is embedded, its widths should exactly match the widths in
the font dictionary. If the font program is not embedded, Acrobat over-
rides the widths in the font program on the viewer application’s system
with the widths specified in the font dictionary.
It is important that the widths in the font dictionary match the actual
glyph widths of the font program that was used to produce the document.
Consumers of PDF files depend on these widths in many different con-
texts, including viewing, printing, fauxing (font substitution), reflow, and
word search. These operations may malfunction if arbitrary adjustments
are made to the widths so that they do not represent the glyph widths in-
tended by the PDF producer.
Implementation NotesSECTION H.3
1015
It is recommended that diagnostic and preflight tools check the glyph
widths in the font dictionary against those in an embedded font program
and flag any inconsistencies. It would also be helpful if the tools could op-
tionally check for consistency with the widths in font programs that are
not embedded. This is useful for checking a PDF file immediately after it
is produced, when the original font programs are still available.
Note: This implementation note is also referred to in Section 5.6.3, “CIDFonts”
(Glyph Metrics in CIDFonts).
5.5.1, “Type 1 Fonts” (Standard Type 1 Fonts)
61. Acrobat 3.0 and earlier viewers may ignore attempts to override the stan-
dard fonts.
TABLE H.3 Names of standard fonts
STANDARD NAME ALTERNATIVE
Courier
CourierNew
Courier
Oblique CourierNew,Italic
Courier
Bold CourierNew,Bold
Courier
BoldOblique CourierNew,BoldItalic
Helvetica
Arial
Helvetica
Oblique Arial,Italic
Helvetica
Bold Arial,Bold
Helvetica
BoldOblique Arial,BoldItalic
Times
Roman TimesNewRoman
Times
Italic TimesNewRoman,Italic
Times
Bold TimesNewRoman,Bold
Times
BoldItalic TimesNewRoman,BoldItalic
Symbol
ZapfDingbats
Compatibility and Implementation NotesAPPENDIX H
1016
Also, Acrobat 4.0 and earlier viewers incorrectly allow substitution fonts,
such as
TimesNewRoman and ArialMT, to be specified without FirstChar,
LastChar, Widths, and FontDescriptor entries.
Table H.3 shows the complete list of font names that are accepted as the
names of standard fonts. The first column shows the proper one (for ex-
ample,
Helvetica); the second column shows the alternative if one exists
(for example,
Arial).
5.5.3, “Font Subsets”
62. For Acrobat 3.0 and earlier viewers, all font subsets whose BaseFont
names differ only in their tags should have the same font descriptor values
and should map character names to glyphs in the same way; otherwise,
glyphs may be shown unpredictably. This restriction is eliminated in
Acrobat 4.0.
5.5.4, “Type 3 Fonts”
63. In principle, the value of the Encoding entry could also be the name of a
predefined encoding or an encoding dictionary whose
BaseEncoding
entry is a predefined encoding. However, Acrobat 4.0 and earlier viewers
do not implement this correctly.
64. For compatibility with Acrobat 2.0 and 2.1, the names of resources in a
Type 3 font’s resource dictionary must match those in the page object’s re-
source dictionary for all pages in which the font is referenced. If backward
compatibility is not required, any valid names may be used.
5.6.4, “CMaps”
65. Embedded CMap files, other than ToUnicode CMaps, do not work prop-
erly in Acrobat 4.0 viewers; this has been corrected in Acrobat 4.05.
66. Japanese fonts included with Acrobat 6.0 contain only glyphs from the
Adobe Japan1-4 character collection. Documents that use fonts contain-
ing additional glyphs from the Adobe-Japan1-5 collection must embed
those fonts to ensure proper display and printing.
Implementation NotesSECTION H.3
1017
5.7, “Font Descriptors”
67. Acrobat viewers earlier than version 3.0 ignore the FontFile3 entry. If a
font uses the Adobe standard Latin character set (as defined in Section
D.1, “Latin Character Set and Encodings”), Acrobat creates a substitute
font. Otherwise, Acrobat displays an error message (once per document)
and substitutes any characters in the font with the bullet character.
5.8, “Embedded Font Programs”
68. For simple fonts, font substitution is performed using multiple master
Type 1 fonts. This substitution can be performed only for fonts that use
the Adobe standard Latin character set (as defined in Section D.1, “Latin
Character Set and Encodings”). In Acrobat 3.0.1 and later, Type 0 fonts
that use a CMap whose
CIDSystemInfo dictionary defines the Adobe-GB1,
Adobe-CNS1 Adobe-Japan1, or Adobe-Korea1 character collection can
also be substituted. To make a document portable, fonts that cannot be
substituted must be embedded. The only exceptions are the
Symbol and
ZapfDingbats fonts, which are assumed to be present.
6.4.2, “Spot Functions”
69. When Distiller encounters a call to the PostScript setscreen or sethalftone
operator that includes a spot function, it compares the PostScript code de-
fining the spot function with that of the predefined spot functions shown
in Table 6.1. If the code matches one of the predefined functions, Distiller
puts the name of that function into the halftone dictionary; Acrobat uses
that function when printing the PDF document to a PostScript output de-
vice. If the code does not match any of the predefined spot functions, Dis-
tiller samples the specified spot function and generates a function for the
halftone dictionary; when printing to a PostScript device, Acrobat gener-
ates a spot function that interpolates values from that function.
When producing PDF version 1.3 or later, Distiller represents the spot
function by using a Type 4 (PostScript calculator) function whenever pos-
sible (see Section 3.9.4, “Type 4 (PostScript Calculator) Functions”). In
this case, Acrobat uses this function directly when printing the document.
Compatibility and Implementation NotesAPPENDIX H
1018
6.5.4, “Automatic Stroke Adjustment”
70. When drawing to the screen, Acrobat 6.0 always performs automatic
stroke adjustment, regardless of the value of the
SA entry in the graphics
state parameter dictionary.
7.5.2, “Specifying Blending Color Space and Blend Mode”
71. PDF 1.3 or earlier viewers ignore all transparency-related graphics state
parameters (blend mode, soft mask, alpha constant, and alpha source). All
graphics objects are painted opaquely.
Note: This implementation note is also referred to in Sections 7.5.3, “Specifying
Shape and Opacity” (Mask Shape and Opacity, Constant Shape and Opacity)
and 7.5.4, “Specifying Soft Masks” (Soft-Mask Dictionaries).
7.5.3, “Specifying Shape and Opacity” (Mask Shape and Opacity)
72. PDF 1.3 or earlier viewers ignore the SMask entry in an image dictionary.
All images are painted opaquely.
Note: This implementation note is also referred to in Section 7.5.4, “Specifying
Soft Masks” (Soft-Mask Images).
8.1, “Viewer Preferences”
73. Earlier versions of the PDF specification erroneously described an addi-
tional entry,
PageLayout, as being in the viewer preferences dictionary; it
is actually implemented in the document catalog instead (see Section
3.6.1, “Document Catalog”).
8.2.2, “Document Outline”
74. In PDF 1.2, an additional entry in the outline item dictionary, named AA,
was defined but was never implemented. Beginning with PDF 1.3, this
entry is obsolete and should be ignored.
75. Acrobat viewers report an error when a user activates an outline item
whose destination is of an unknown type.
Implementation NotesSECTION H.3
1019
8.3.1, “Page Labels”
76. Acrobat viewers up to version 3.0 ignore the PageLabels entry and label
pages with decimal numbers starting at 1.
8.4, “Annotations”
77. In PDF 1.5, the order of moving the keyboard focus between annotations
on a page by using the tab key can be made explicit by means of the page’s
Tabs entry (see Table 3.27). In earlier versions, the tab order was not ex-
plicitly specified and depended on the viewer. In Acrobat 4.0, the order in-
cludes only widget annotations and is determined by their order in the
page’s
Annots array. In Acrobat 5.0, the order includes all annotations:
widgets come first and are ordered as in Acrobat 4.0; other annotations
come after widgets and are ordered by rows. Acrobat 6.0 has the same be-
havior as Acrobat 5.0 for documents that do not contain a
Tabs entry. For
documents that have a
Tabs entry, Acrobat 6.0 reorders widgets in the
Annots array to match the specified order (row, column, or structure) so
that the tab order for widgets is preserved when the document is opened
by earlier viewers.
8.4.1, “Annotation Dictionaries”
78. Acrobat viewers update the annotation dictionary’s M entry only for text
annotations.
79. Acrobat 2.0 and 2.1 viewers ignore the annotation dictionary’s
BS, AP, and
AS entries.
80. All versions of Acrobat through 6.0 ignore the
AP entry when drawing the
appearance of link annotations.
81. Acrobat viewers ignore the horizontal and vertical corner radii in the an-
notation dictionary’s
Border entry; the border is always drawn with square
corners.
82. Acrobat viewers support a maximum of ten elements in the dash array of
the annotation dictionary’s
Border entry.
8.4.2, “Annotation Flags”
83. Acrobat viewers earlier than version 3.0 ignore an annotation’s Hidden
and Print flags. Annotations that should be hidden are shown; annotations
Compatibility and Implementation NotesAPPENDIX H
1020
that should be printed are not printed. Acrobat 3.0 ignores the Print flag
for text and link annotations.
84. Acrobat 5.0 obeys the Locked flag only for widget annotations. In Acrobat
6.0, markup annotations support it as well.
85. In Acrobat 6.0, the ToggleNoView flag is applicable to mouse-over and se-
lection events.
8.4.3, “Border Styles”
86. Acrobat viewers support border style dictionaries (referenced by the BS
entry in the annotation dictionary) for the following annotation types:
• Acrobat 3.0 and 4.0: widget annotations only
• Acrobat 5.0: all types except link annotations
• Acrobat 6.0 and later: all annotation types
87. If an Acrobat viewer encounters a border style it does not recognize, the
border style defaults to
S (Solid).
8.4.4, “Appearance Streams”
88. Acrobat 5.0 treats the annotation appearance as an isolated group, regard-
less of whether a
Group entry is present. This behavior is corrected in Ac-
robat 6.0.
8.4.5, “Annotation Types”
89. Acrobat viewers display annotations whose types they do not recognize in
closed form, with an icon containing a question mark. Such an annotation
can be selected, moved, or deleted, but if the user attempts to activate it, an
alert appears giving the annotation type and reporting that a required
plug-in is unavailable.
8.4.5, “Annotation Types” (Link Annotations)
90. Acrobat viewers report an error when a user activates a link annotation
whose destination is of an unknown type.
91. When a link annotation specifies a value of
P for the H entry (highlighting
mode), Acrobat viewers display the link appearance with a beveled border,
Implementation NotesSECTION H.3
1021
ignoring any down appearance that is defined (see Section 8.4.4, “Appear-
ance Streams”).
8.4.5, “Annotation Types” (Text Markup Annotations)
92. In Acrobat 4.0 and later versions, the text is oriented with respect to the
vertex with the smallest y value (or the leftmost of those, if there are two
such vertices) and the next vertex in a counterclockwise direction, regard-
less of whether these are the first two points in the
QuadPoints array.
8.4.5, “Annotation Types” (Ink Annotations)
93. Acrobat viewers always use straight lines to connect the points along each
path.
8.4.5, “Annotation Types” (File Attachment Annotations)
94. Acrobat 7.0 and earlier viewers only support file attachment annotations
whose referenced file is embedded in the PDF document.
95. Acrobat 7.0 does not include a
Desc entry in file specifications for file at-
tachment annotations and ignores them if they are present.
8.4.5, “Annotation Types” (Watermark Annotations)
96. Watermark annotations are handled correctly only when Acrobat n-up
printing is selected. Selecting n-up from within the printer driver does not
produce correct results.
8.5.2, “Trigger Events”
97. In PDF 1.2, the additional-actions dictionary could contain entries named
NP (next page), PP (previous page), FP (first page), and LP (last page). The
actions associated with these entries were never implemented; beginning
with PDF 1.3, these entries are obsolete and should be ignored.
98. In PDF 1.2, additional-actions dictionaries were inheritable; beginning
with PDF 1.3, they are not inheritable.
99. In Acrobat 3.0, the
O and C events in a page object’s additional-actions dic-
tionary are ignored if the document is not being displayed in a page-ori-
ented layout mode. Beginning with Acrobat 4.0, the actions associated
Compatibility and Implementation NotesAPPENDIX H
1022
with these events are executed if the document is in a page-oriented or
single-column layout and are ignored if the document is in a multiple-col-
umn layout.
8.5.3, “Action Types” (Launch Actions)
100. The Acrobat viewer for the Windows platform uses the Windows function
ShellExecute to launch an application. The Win dictionary entries corre-
spond to the parameters of
ShellExecute.
8.5.3, “Action Types” (URI Actions)
101. URI actions are resolved by the Acrobat WebLink plug-in extension.
102. If the appropriate plug-in extension (WebLink) is not present, Acrobat
viewers report the following error when a link annotation that uses a URI
action is activated: “The plug-in required by this URI action is not avail-
able.”
8.5.3, “Action Types” (Sound Actions)
103. In PDF 1.2, the value of the Sound entry was allowed to be a file specifica-
tion. Beginning with PDF 1.3, this is not supported, but the same effect
can be achieved by using an external stream.
104. Acrobat viewers mute the sound if the value of
Volume is negative; other-
wise, this entry is ignored.
105. Acrobat 6.0 does not support the
Synchronous entry.
106. Acrobat 5.0 and earlier viewers do not support the
Mix entry.
8.5.3, “Action Types” (Movie Actions)
107. Acrobat viewers earlier than version 3.0 report an error when they en-
counter an action of type
Movie.
8.5.3, “Action Types” (Hide Actions)
108. Acrobat viewers earlier than version 3.0 report the following error when
encountering an action of type
Hide: “The plug-in needed for this Hide ac-
tion is not available.”
Implementation NotesSECTION H.3
1023
109. In Acrobat viewers, the change in an annotation’s Hidden flag as a result of
a hide action is temporary in that the user can subsequently close the doc-
ument without being prompted to save changes and the effect of the hide
action is lost. However, if the user explicitly saves the document before
closing, such changes are saved and thus become permanent.
8.5.3, “Action Types” (Named Actions)
110. Acrobat viewers earlier than version 3.0 report the following error when
encountering an action of type
Named: “The plug-in needed for this
Named action is not available.”
111. Acrobat viewers extend the list of named actions in Table 8.57 to include
most of the menu item names available in the viewer.
8.6.1, “Interactive Form Dictionary”
112. Acrobat viewers may insert additional entries in the DR resource dictio-
nary, such as
Encoding, as a convenience for keeping track of objects being
used to construct form fields. Such objects are not actually resources and
are not referenced from the appearance stream.
113. In Acrobat, markup annotations can also make use of the resources in the
DR dictionary.
114. Acrobat 6.0 recognizes only the stream value of the
XFA entry; Acrobat
6.02 and later recognize both stream and array values.
8.6.2, “Field Dictionaries” (Field Names)
115. Beginning in Acrobat 3.0, partial field names cannot contain a period.
116. Acrobat 6.0 and later support Unicode encoding of field names. Versions
earlier than Acrobat 6.0 do not support Unicode encoding of field names.
8.6.2, “Field Dictionaries” (Variable Text)
117. In PDF 1.2, an additional entry in the field dictionary, DR, was defined but
was never implemented. Beginning with PDF 1.5, this entry is obsolete
and should be ignored.
118. If the
MK entry is present in the field’s widget annotation dictionary (see
Table 8.35), Acrobat viewers regenerate the entire XObject appearance
Compatibility and Implementation NotesAPPENDIX H
1024
stream. If MK is not present, the contents of the stream outside /Tx BMC ...
EMC
are preserved.
8.6.2, “Field Dictionaries” (Rich Text Strings)
119. To select a font specified by attributes in a rich text string, Acrobat 6.0 fol-
lows this sequence, choosing the first appropriate font it finds:
a. A font in the default resource dictionary (specified by the document’s
DR
entry; see Table 8.63) whose font descriptor information matches the font
specification in the rich text string. “Font Characteristics” on page 820 de-
scribes how this matching is done.
b. A matching font installed on the user’s system, ignoring generic font fami-
lies.
c. A font on the user’s system that matches the generic font family, if speci-
fied.
d. A standard font (see implementation note 61) that most closely matches
the other font specification properties and is appropriate for the current
input locale.
8.6.2, “Field Dictionaries” (Button Fields)
120. The behavior of Acrobat has changed in the situation where a check box or
radio button field have multiple children that have the same export value.
In Acrobat 4.0, such buttons always turned off and on in unison. In Acro-
bat 5.0, the behavior of radio buttons was changed to mimic HTML so
that turning on a radio button always turned off its siblings regardless of
export value. In Acrobat 6.0, the RadiosInUnison flag allows the docu-
ment author to choose between these behaviors.
8.6.3, “Field Types” (Choice Fields)
121. In Acrobat 3.0, the Opt array must be homogenous: its elements must be
either all text strings or all arrays.
8.6.4, “Form Actions” (Submit-Form Actions)
122. In Acrobat viewers, if the response to a submit-form action uses Forms
Data Format (FDF), the URL must end in
#FDF so that it can be recog-
Implementation NotesSECTION H.3
1025
nized as such by the Acrobat software and handled properly. Conversely, if
the response is in any other format, the URL should not end in
#FDF.
8.6.4, “Form Actions” (Import-Data Actions)
123. Acrobat viewers set the F entry to a relative file specification locating the
FDF file with respect to the current PDF document file. If the designated
FDF file is not found when the import-data action is performed, Acrobat
tries to locate the file in a few well-known locations, depending on the
host platform. On the Windows platform, for example, Acrobat searches
in the directory from which Acrobat was loaded, the current directory, the
System directory, the Windows directory, and any directories listed in the
PATH environment variable. On Mac OS, Acrobat searches in the Prefer-
ences folder and the Acrobat folder.
124. When performing an import-data action, Acrobat viewers import the
contents of the FDF file into the current document’s interactive form,
ignoring the
F and ID entries in the FDF dictionary of the FDF file.
8.6.4, “Form Actions” (JavaScript Actions)
125. Because JavaScript 1.2 is not Unicode-compatible, PDFDocEncoding and
the Unicode encoding are translated to a platform-specific encoding be-
fore interpretation by the JavaScript engine.
8.6.6, “Forms Data Format” (FDF Header)
126. Because Acrobat viewers earlier than 5.0 cannot accept any other version
number because of a bug, the FDF file header is permanently frozen at
version 1.2. All further updates to the version number will be made via the
Version entry in the FDF catalog dictionary instead.
8.6.6, “Forms Data Format” (FDF Catalog)
127. The Acrobat implementation of interactive forms displays the value of the
Status entry, if any, in an alert note when importing an FDF file.
128. The only
Encoding value supported by Acrobat 4.0 is ShiftJIS. Acrobat 5.0
supports
ShiftJIS, UHC, GBK, and BigFive. If any other value is specified,
the default,
PDFDocEncoding, is used.
Compatibility and Implementation NotesAPPENDIX H
1026
8.6.6, “Forms Data Format” (FDF Fields)
129. Of all the possible entries shown in Table 8.92 on page 677, Acrobat 3.0 ex-
ports only the
V entry when generating FDF, and Acrobat 4.0 and later
versions export only the
V and AP entries. Acrobat does, however, import
FDF files containing fields that have any of the described entries.
130. If the FDF dictionary in an FDF file received as a result of a submit-form
action contains an
F entry specifying a form other than the one currently
being displayed, Acrobat fetches the specified form before importing the
FDF file.
131. When exporting a form to an FDF file, Acrobat sets the
F entry in the FDF
dictionary to a relative file specification giving the location of the FDF file
relative to that of the file from which it was exported.
132. If an FDF file being imported contains fields whose fully qualified names
are not in the form, Acrobat discards those fields. This feature can be use-
ful, for example, if an FDF file containing commonly used fields (such as
name and address) is used to populate various types of forms, not all of
which necessarily include all of the fields available in the FDF file.
133. As shown in Table 8.92 on page 677, the only required entry in the field
dictionary is
T. One possible use for exporting FDF with fields containing
T entries but no V entries is to indicate to a server which fields are desired
in the FDF files returned in response. For example, a server accessing a
database might use this information to decide whether to transmit all
fields in a record or just some selected ones. As noted in implementation
note 132, the Acrobat implementation of interactive forms ignores fields
in the imported FDF file that do not exist in the form.
134. The Acrobat implementation of forms allows the option of submitting the
data in a submit-form action in HTML Form format for the benefit of ex-
isting server scripts written to process such forms. Note, however, that any
such existing scripts that generate new HTML forms in response need to
be modified to generate FDF instead.
135. When scaling a button’s appearance to the bounds of an annotation, ver-
sions of Acrobat earlier than 6.0 always took into account the line width
used to draw the border, even when no border was being drawn.Begin-
ning with Acrobat 6.0, the
FB entry in the icon fit dictionary (see Table
8.93 on page 679) allows the option of ignoring the line width.
Implementation NotesSECTION H.3
1027
8.6.6, “Forms Data Format” (FDF Pages)
136. Acrobat renames fields by prepending a page number, a template name,
and an ordinal number to the field name. The ordinal number cor-
responds to the order in which the template is applied to a page, with 0
being the first template specified for the page. For example, if the first
template used on the fifth page has the name
Template and has the
Rename flag set to true, fields defined in that template are renamed by
prepending the character string
P5.Template_0. to their field names.
137. Adobe Extreme® printing systems require that the
Rename flag be true.
8.7, “Digital Signatures”
138. Acrobat 6.0 computes a byte range digest only when the signature dictio-
nary is referenced from a signature field. There is no byte range signature
(that is, there is only an object signature) for FDF file signatures and usage
rights signatures referenced from the
UR entry of a permissions dictio-
nary. In Acrobat 7.0, byte range digests are also computed for usage rights
signatures referenced from the
UR3 entry of a permissions dictionary.
139. Acrobat 6.0 and later do not provide the
Changes entry.
8.7.1, “Transform Methods”
140. Acrobat 6.0 and 7.0 always generate DigestValue when creating MDP sig-
natures. Acrobat 6.0 requires the presence of
DigestValue in order to vali-
date MDP signatures. Acrobat 7.0 does not use
DigestValue but compares
the current and signed versions of the document.
141. Acrobat 6.0 requires a usage rights signature dictionary that is referenced
from the
UR entry of the permissions dictionary in order to validate the
usage rights. Acrobat 7.0 supports both
UR and UR3; it uses the UR3 dic-
tionary if both are present.
142. In Adobe Reader 6.0, any usage right that permits the document to be
modified implicitly enables the
FullSave right. In Adobe Reader 7.0, only
rights specified by the
Annots entry that permit the document to be mod-
ified implicitly enable the
FullSave right. For all other rights, FullSave must
be explicitly enabled in order to save the document. (Signature rights per-
mit saving as part of the signing process but not otherwise).
Compatibility and Implementation NotesAPPENDIX H
1028
If the P entry in the UR transform parameters dictionary is true, Acrobat
7.0 viewer applications permit only those rights that are enabled by the
entries in the dictionary. However, viewers permit saving the document as
long as any rights that permit modifying the document are enabled.
8.7.2, “Signature Interoperability”
143. In versions earlier than Acrobat 6.0, it was a requirement that the signer’s
signature be the first certificate in the PKCS#7 object. Acrobat 6.0 re-
moved this restriction, but for maximum compatibility with earlier ver-
sions, this practice should be followed.
9.1, “Multimedia”
144. The following media formats are recommended for use in authoring
cross-platform PDF files intended for consumption by Acrobat 6.0.
TABLE H.4 Recommended media types
145. If the CT entry is not present, Acrobat requires a PL entry to be present
that specifies at least one player that can be used.
COMMON EXTENSION COMMON MIME TYPE DESCRIPTION
.aiff audio/aiff
Audio Interchange File Format
.au audio/basic
NeXT/Sun
™
Audio Format
.avi video/avi
AVI (Audio/Video Interleaved)
.mid audio/midi
MIDI (Musical Instrument Digital Interface)
.mov video/quicktime
QuickTime
.mp3 audio/x-mp3
MPEG Audio Layer-3
.mp4 audio/mp4
MPEG-4 Audio
.mp4 video/mp4
MPEG-4 Video
.mpeg video/mpeg
MPEG-2 Video
.smil application/smil
Synchronized Multimedia Integration Language
.swf application/x-shockwave-flash
Macromedia Flash
Implementation NotesSECTION H.3
1029
9.2, “Sounds”
146. Acrobat supports a maximum of two sound channels.
9.3, “Movies”
147. Acrobat viewers do not support the value of Aspect.
148. Acrobat viewers support only the
DeviceRGB and DeviceGray color spaces
for poster image XObjects. For indexed color spaces with a base color
space of
DeviceRGB (see “Indexed Color Spaces” on page 232”), Acrobat
5.0 viewers incorrectly treat
hival as the number of colors rather than the
number of colors - 1. Acrobat 6.0 can handle this case properly, as well as
the correct value of
hival; for compatibility with 5.0 viewers, it is necessary
to specify
hival as the number of colors.
Also, Acrobat viewers do not support authoring or rendering posters
when the value of
Poster is true.
149. Acrobat viewers treat a
FWScale value of [999 1] as full screen.
150. Acrobat viewers never allow any portion of a floating window to be off-
screen.
9.4, “Alternate Presentations”
151. The PDF language contains no direct method of initiating an alternate
presentation-defined slideshow. Instead, a slideshow is invoked by a
JavaScript call that is typically triggered by an interactive form element
(see Section 8.6, “Interactive Forms”). Refer to the Acrobat JavaScript
Scripting Reference (see the Bibliography) for information on starting and
stopping a slideshow using JavaScript.
152. The only type of slideshow supported in Acrobat 5.1 and later is an SVG
slideshow (MIME content type
image/svg+xml). Acrobat supports the
Scalable Vector Graphics (SVG) 1.0 Specification defined by the W3C (see
the Bibliography). Implementation notes on support of SVG by Adobe
products are available at <http://www.adobe.com/svg/>.
All resources must be either image XObjects (see Section 4.8.4, “Image
Dictionaries”) or embedded file streams (see Section 3.10.3, “Embedded
File Streams”).
Compatibility and Implementation NotesAPPENDIX H
1030
• Image XObjects used for slideshows must use the DCTDecode filter and
an RGB color space. Color profile information must be specified in the
image XObject dictionary as well as embedded within the JPEG stream.
• Embedded audio files must be of type .wav (supported on Windows
only, MIME type
audio/x-wav) or .mp3 (MIME type audio/mpeg, docu-
mented at <http://www.chiariglione.org/mpeg/index.htm>).
• Embedded video must be QuickTime-compatible files of type .avi
(MIME type video/ms-video) or .mov (MIME type video/quicktime,
documented at <http://developer.apple.com/documentation/Quick-
Time/PDF/QTFileFormat.pdf>). To play video, a QuickTime player
(version 3 or later) must be installed.
10.1, “Procedure Sets”
153. Acrobat viewers earlier than version 5.0 respond to requests for unknown
procedure sets by warning the user that a required procedure set is un-
available and canceling the printing operation. Acrobat 5.0 ignores proce-
dure sets.
10.2, “Metadata”
154. Acrobat viewers display the document’s metadata in the Document Prop-
erties dialog box and impose a limit of 255 bytes on any string represent-
ing one of those values.
10.2.2, “Metadata Streams”
155. For backward compatibility, applications that create PDF 1.4 documents
should include the metadata for a document in the document information
dictionary as well as in the document’s metadata stream. Applications that
support PDF 1.4 should check for the existence of a metadata stream and
synchronize the information in it with that in the document information
dictionary. The Adobe metadata framework provides a date stamp for
metadata expressed in the framework. If this date stamp is equal to or later
than the document modification date recorded in the document informa-
tion dictionary, the metadata stream can be taken as authoritative. If, how-
ever, the document modification date recorded in the document
information dictionary is later than the metadata stream’s date stamp, the
document has likely been saved by an application that is not aware of PDF
Implementation NotesSECTION H.3
1031
1.4 metadata streams. In this case, information stored in the document in-
formation dictionary should be taken to override any semantically equiva-
lent items in the metadata stream.
10.3, “File Identifiers”
156. Although the ID entry is not required, all Adobe applications that produce
PDF files include this entry. Acrobat adds this entry when saving a file if it
is not already present.
157. Adobe applications pass the suggested information to the MD5 message
digest algorithm to calculate file identifiers. Note that the calculation of
the file identifier need not be reproducible; all that matters is that the
identifier is likely to be unique. For example, two implementations of this
algorithm might use different formats for the current time, causing them
to produce different file identifiers for the same file created at the same
time, but the uniqueness of the identifier is not affected.
10.9.2, “Content Database” (Digital Identifiers)
158. The Acrobat Web Capture plug-in treats external streams referenced with-
in a PDF file as auxiliary data. Such streams are not used in generating the
digital identifier.
10.9.3, “Content Sets” (Image Sets)
159. In Acrobat 4.0 and later versions, if the indirect reference to an image
XObject is not removed from the
O array when its reference count reaches
0, the XObject is never garbage-collected during a save operation. The im-
age set’s reference to the XObject may thus be considered a weak one that
is relevant only for caching purposes; when the last strong reference goes
away, so does the weak one.
10.9.4, “Source Information” (URL Alias Dictionaries)
160. Acrobat viewers use an indirect object reference to a shared string for each
URL in a URL alias dictionary. These strings can be shared among the
chains and with other data structures. It is recommended that other PDF
viewer applications adopt this same implementation.
Compatibility and Implementation NotesAPPENDIX H
1032
10.10.1, “Page Boundaries”
161. Acrobat provides various user-specified options for determining how the
region specified by the crop box is to be imposed on the output medium
during printing. Although these options have varied from one Acrobat
version to another, the default behavior is as follows:
1. Select the media size and orientation according to the operating sys-
tem’s Print Setup dialog. (Acrobat has no direct control over this pro-
cess.)
2. Compute an effective crop box by clipping it with the media box and
rotating the page according to the page object’s
Rotate entry, if speci-
fied.
3. Center the crop box on the medium, rotating it if necessary to enable
it to fit in both dimensions.
4. Optionally, scale the page up or down so that the crop box coincides
with the edges of the medium in the more restrictive dimension.
The description above applies only in simple printing workflows that lack
any other information about how PDF pages are to be imposed on the
output medium. In some workflows, there is additional information, ei-
ther in the PDF file (
BleedBox, TrimBox, or ArtBox) or in a separate job
ticket (such as JDF or PJTF). In these circumstances, other rules apply,
which depend on the details of the workflow.
Consequently, it is recommended that PDF files initially be created with
the crop box the same as the media box (or equivalently, with the crop box
omitted). This ensures that if the page is printed on that size medium, the
crop box coincides with the edges of the medium, producing predictable
and dependable positioning of the page contents. On the other hand, if the
page is printed on a different size medium, the page may be repositioned
or scaled in implementation-defined or user-specified ways.
10.10.4, “Output Intents”
162. Acrobat viewers do not make use of the “to CIE” (AToB) information in an
output intent’s ICC profile.
163. Acrobat 5.0 does not make direct use of the destination profile in the out-
put intent dictionary, but third-party plug-in extensions might do so. Ac-
robat 6.0 does make use of this profile.
Implementation NotesSECTION H.3
1033
10.10.5, “Trapping Support” (Trap Network Annotations)
164. Older viewers may fail to maintain the trap network annotation’s required
position at the end of the
Annots array.
165. Older viewers may fail to validate trap networks before printing.
166. In Acrobat 4.0, saving a PDF file with the Optimize option selected causes
a page’s trap networks to be incorrectly invalidated even if the contents of
the page has not been changed. This occurs because the new, optimized
content stream generated for the page differs from the original content
stream still referenced by the trap network annotation’s
Version array. This
problem has been corrected in later versions of Acrobat.
10.10.6, “Open Prepress Interface (OPI)”
167. The Acrobat 3.0 Distiller application converts OPI comments into OPI
dictionaries. When the Acrobat 3.0 viewer prints a PDF file to a PostScript
file or printer, it converts the OPI dictionary back to OPI comments.
However, the OPI information has no effect on the displayed image or
form XObject.
168. Acrobat viewer and Distiller applications earlier than version 4.0 do not
support OPI 2.0.
169. In Acrobat 3.0, the value of the
F entry in an OPI dictionary must be a
string.
Appendix C, “Implementation Limits”
170. Acrobat viewers earlier than 5.0 use the PostScript save and restore oper-
ators rather than
gsave and grestore to implement q and Q, and are sub-
ject to a nesting limit of 12 levels.
171. In PDF versions earlier than PDF 1.6, the size of the default user space
unit is fixed at 1⁄72 inch. In Acrobat viewers earlier than version 4.0, the
minimum allowed page size is 72 by 72 units in default user space (1 by 1
inch); the maximum is 3240 by 3240 units (45 by 45 inches). In Acrobat
versions 5.0 and later, the minimum allowed page size is 3 by 3 units (ap-
proximately 0.04 by 0.04 inch); the maximum is 14,400 by 14,400 units
(200 by 200 inches).
Beginning with PDF 1.6, the size of the default user space unit may be set
with the
UserUnit entry of the page dictionary. Acrobat 7.0 supports a
Compatibility and Implementation NotesAPPENDIX H
1034
maximum UserUnit value of 75,000, which gives a maximum page dimen-
sion of 15,000,000 inches (14,400 * 75,000 * 1⁄72). The minimum
UserUnit value is 1.0 (the default).
F.2.2, “Linearization Parameter Dictionary (Part 2)“
172. Acrobat requires a white-space character to follow the left bracket ([)
character that begins the
H array.
173. Acrobat does not currently support reading or writing files that have an
overflow hint stream.
Note: This implementation note is also referred to in Section F.2.5, “Hint Streams
(Parts 5 and 10).”
174. Acrobat generates a value for the
E parameter that incorrectly includes an
object beyond the end of the first page as if it were part of the first page.
F.2.6, “First-Page Section (Part 6)”
175. Acrobat always treats page 0 as the first page for linearization, regardless
of the value of
OpenAction.
F.2.8, “Shared Objects (Part 8)”
176. Acrobat does not generate shared object groups containing more than one
object.
F.3.1, “Page Offset Hint Table”
177. In Acrobat, items 6 and 7 in the header section of the page offset hint table
are set to 0. As a result, item 6 of the per-page entry effectively does not
exist; its value is taken to be 0. That is, the sequence of bytes constituting
the content stream for a page is described as if the content stream were the
first object in the page, even though it is not.
178. Acrobat 4.0 and later versions always set item 8 equal to 0. They also set
item 9 equal to the value of item 5, and set item 7 of each per-page hint ta-
ble entry (Table F.4) to be the same as item 2 of the per-page entry. Acro-
bat ignores all of these entries when reading the file.
Implementation NotesSECTION H.3
1035
F.3.2, “Shared Object Hint Table”
179. In Acrobat, item 5 in the header section of the shared objects hint table is
unused and is always set to 0.
180. MD5 signatures are not implemented in Acrobat; item 2 in a shared object
group entry must be 0.
181. Acrobat does not support more than one shared object in a group; item 4
in a shared object group entry should always be 0.
182. In a document consisting of only one page, items 1 and 2 in the shared ob-
ject hint table are not meaningful; Acrobat writes unpredictable values for
these items.
Compatibility and Implementation NotesAPPENDIX H
1036
1037
APPENDIX I
IComputation of Object
Digests
This appendix describes the algorithm for computing object digests (discussed in
Section 8.7, “Digital Signatures”). The computation uses a hashing method, spec-
ified by the
DigestMethod entry of the signature reference dictionary (see Table
8.99). Its value can be
SHA1 for the Secure Hash Algorithm 1 (SHA-1) or MD5 for
the MD5 message-digest algorithm; see the Bibliography. Both algorithms oper-
ate on an arbitrary-length stream of bytes to produce a digest of fixed length (16
bytes for MD5, 20 bytes for SHA-1).
The following sections describe how the stream of bytes to be digested is generat-
ed, starting with a specific object within a PDF file. A PDF object is digested by re-
cursively traversing the object hierarchy beginning with the given object. Objects
encountered during the traversal are categorized as basic PDF types, described in
Section I.1, “Basic Object Types,” or more complex types, described in Section I.2,
“Selective Computation.” Each object is digested as it is processed. Not all objects
may be included, depending on the transform method and parameters (see Sec-
tion 8.7.1, “Transform Methods”) that are being used.
I.1 Basic Object Types
The basic PDF object types are listed in Table I.1. For each type, the following
data is digested:
• a single-byte type identifier
• other bytes representing the value of the data, as described in Table I.1
Dictionaries and arrays can contain indirect references to other objects; therefore,
the data can be recursive. To prevent infinite recursions, the algorithm keeps
track of all indirect objects visited during a recursive descent into a given object.
Computation of Object DigestsAPPENDIX I
1038
When it encounters an object that has already been visited, it adds the type iden-
tifier followed by a 4-byte value for the number -1 (0xFFFFFFFF).
TABLE I.1 Data added to object digest for basic object types
OBJECT TYPE TYPE IDENTIFIER REMAINING VALUES ADDED TO DIGEST
Null 0 Nothing.
Integer 1 The unsigned 4-byte value of this integer (most significant byte first).
Real 2 The 4-byte integer corresponding to the integral part of the rounded value of the
object.
Boolean 3 0x01 for
true; 0x00 for false.
Name 4 An unsigned 4-byte integer (most significant byte first) representing the length of
the name, followed by byte array containing the string representing the name
(following expansion of any escape characters, and excluding the leading “
/”
character).
String 5 An unsigned 4-byte integer (most significant byte first) representing the length of
the string, followed by the sequence of bytes corresponding to the string.
Dictionary 6 An unsigned 4-byte value (most significant byte first) specifying the number of
entries in the dictionary, followed by the key-value pairs of the dictionary, sorted
by lexicographic order of the keys (for comparison purposes, the key names are
treated as binary byte sequences). The values may involve recursion; see above.
Special treatment is given to certain dictionaries when the transform method is
anything but
Identity (see Section 8.7.1, “Transform Methods”). For these dictio-
naries (which include catalog, page, named page, form field, annotation, action
and additional-actions dictionaries), all key-value pairs are not digested. Instead,
only the values of specified entries are digested; see Section I.2, “Selective Com-
putation,” for details.
Array 7 An unsigned 4-byte value (most significant byte first) specifying the number of
entries in the array, followed by the individual entries, in order. Individual entries
may involve recursion. Specific entries may be excluded when dictated by the
transform method and parameters (for example, annotation dictionaries in a
page’s
Annots array).
Selective ComputationSECTION I.2
1039
I.2 Selective Computation
There is a set of special objects that, when encountered in an object calculation,
are not treated as described in the previous section. These objects are described
in the following sections. For each of them, a selective list of entries is chosen, and
only the value of the entry is digested; the key is not included.
When the transform method is
DocMDP (see “DocMDP” on page 690)or UR (see
“UR” on page 692), the object digest is computed over the entire document (see
Section I.2.1, “Document”). The calculation varies depending on the transform
parameters, which may specify, for example, whether form fields or annotations
are included.
When the transform method is
FieldMDP (see “FieldMDP” on page 695), the
transform parameters indicate specific form fields over which the object digest
should be computed. For each form field, the digest calculation is performed as
specified in Section I.2.6, “Form Fields.”
When the transform method is
Identity, selective computation is not used. All
objects are processed as basic object types as described in Section I.1, “Basic Ob-
ject Types.”
Stream 8 The following values, in order:
• An unsigned 4-byte value (most significant byte first) specifying the number of
entries in the stream dictionary
• The following key-value pairs in the stream dictionary, if present, sorted as fol-
lows:
DecodeParms, F, FDecodeParms, FFilter, Filter and Length
• An unsigned 4-byte value (most significant byte first) specifying the length of
the stream
• The stream data
OBJECT TYPE TYPE IDENTIFIER REMAINING VALUES ADDED TO DIGEST
Computation of Object DigestsAPPENDIX I
1040
I.2.1 Document
When calculating a digest for the document, the following items are included, in
order:
• The values of the following entries in the document catalog (see Table 3.25), if
present:
AA, Legal; and Perms
• The values of the following entries in the document information dictionary
(see Table 10.2), if present:
Title, Author, Keywords, and Subject
• All page objects in the document, in page order, as described in Section I.2.2,
“Page Objects”
• All named pages specified in the Pages name tree, sorted by name, as described
in Section I.2.3, “Named Pages”
• All embedded files specified in the EmbeddedFiles name tree, sorted by name,
as described in Section I.2.4, “Embedded Files”
I.2.2 Page Objects
For page objects (see Table 3.27), the digest includes the values of the following
entries, in order, if present. For entries listed as inheritable, their values may be
inherited from ancestor nodes in the page tree if not specified explicitly.
• MediaBox (inheritable)
• CropBox (inheritable)
• Resources (inheritable)
• Contents
• Rotate (inheritable)
• AA
• Annots. This entry consists of an array of dictionaries for annotations on the
page. They are sorted by the value of the
NM entry; if NM is not present, a glo-
bally unique ID (GUID) is supplied as
NM.
For each annotation, if it is a widget, the values added to the digest are those
specified in Section I.2.6, “Form Fields.” If it is any other type of annotation, the
values added to the digest are those specified in Section I.2.5, “Annotation Dic-
tionaries.” However, when the transform parameters specify that annotations
Selective ComputationSECTION I.2
1041
may be modified (for example, when the value of P is 3 for the DocMDP trans-
form method), annotation dictionaries other than widgets are not included.
Note: Pages that have a
TemplateInstantiated entry are not included in the digest
when the transform method indicates that page template instantiation is permitted.
Instead, a separate calculation is performed to compare instantiated pages with
their associated named pages; see Section I.2.9, “Page Template Verification.”
I.2.3 Named Pages
For named pages (see Section 8.6.5, “Named Pages”), only the Contents and
Annots entries are digested, as shown in Section I.2.2, “Page Objects,” above.
I.2.4 Embedded Files
The document’s embedded files (as specified in the EmbeddedFiles name tree)
are sorted by name. For each embedded file, the following values are digested, in
order:
• The name of the embedded file
• The stream corresponding to the file
I.2.5 Annotation Dictionaries
For annotation dictionaries (see Table 8.40), the values of the following entries
are digested, in order, if present:
• Contents
Note: A content stream of the form “
()” (empty parentheses) is considered nonex-
istent content and is not included.
• T
• F
• A
• AA
• Dest
• QuadPoints
Computation of Object DigestsAPPENDIX I
1042
• Inklist
• Name
• FS (If FS refers to the contents of a remote file, the contents of that file are not
digested)
• Sound
• If Movie is present, the value of its F and Poster entries
• For stamp annotations only, the value of the AP entry
I.2.6 Form Fields
For form fields (see Table 8.65), the values of the following entries are digested, in
order, if present:
Note: The
A, AA, and F entries are from the annotation dictionary (see Table 8.11);
all others are from the form field dictionary (see Tables 8.65 and 8.77).
• T (the unqualified name)
• FT (inheritable)
• DV (inheritable)
• V (included only in the cases where the transform method and parameters
specify that form field fill-in is not allowed or that this particular field is
locked)
• A (inheritable)
• AA (inheritable)
• F (annotation flags, whose values, if necessary, are obtained by traveling the in-
heritance hierarchy)
• Lock (signature fields only)
• SV (signature fields only)
I.2.7 Actions
For most actions (see Section 8.5, “Actions”), the values of the following entries in
the action dictionary are digested, in order, if present:
S (required), D, F,
NewWindow, O, P, B, Base, Sound, Vol, Annot, T, H, N, JS and URI.
Selective ComputationSECTION I.2
1043
Rendition actions (see “Rendition Actions” on page 630) are treated differently
than the other types. The data that is digested is media data that is nested in sev-
eral levels of objects, as follows:
• The rendition action’s R entry, if present, specifies a rendition object (see Sec-
tion 9.1.2, “Renditions”) whose
S entry determines whether it is a media rendi-
tion or a selector rendition.
• Selector renditions have an R entry specifying an array of renditions, which
may themselves be selector renditions. This array is searched recursively for all
media renditions, which are then processed as specified below.
• Media renditions have a C entry that refers to a media clip dictionary. If the S
entry of the media clip is MCD (media clip data), the D entry specifies the data
that is digested (see Table 9.9).
I.2.8 Additional-Actions
Additional-actions dictionaries (see Section 8.5.2, “Trigger Events”) can be the
value of the
AA entry of a catalog, page, annotation or field dictionary. If the addi-
tional action is valid, the values of the following entries in the additional-actions
dictionary are digested, in order, if present:
E, X, D, U, Fo, Bl, O, C, K, F, V, C, DC,
WS, DS, WP, and DP.
I.2.9 Page Template Verification
In some cases, the permissions granted allow page template instantiation; this oc-
curs when the value of
P in the DocMDP transform parameters dictionary is 2 or 3
(see Table 8.100) or the value of
Form in the UR transform parameters is
SpawnTemplate (see Table 8.101). In such cases, object digest must be computed
in such a way that its value changes when new pages have been added to the doc-
ument but not when pages have been instantiated from named pages (templates).
Computation of Object DigestsAPPENDIX I
1044
To accomplish this, the document object digest does not include pages that have a
value for the
TemplateInstantiated entry (see Table 3.27), indicating that they are
instantiated from a named page. At the time the signature is verified, the follow-
ing occurs:
• An object digest is computed for every named page in the document.
• Using the same method, an object digest is computed for every page in the doc-
ument that has a
TemplateInstantiated entry and matched against the digest for
the corresponding named page.
• Verification succeeds only if the digests match for all instantiated pages in the
document.
PLATE 8 Colored tiling pattern (“Colored Tiling Patterns,” page 265)
PLATE 9 Uncolored tiling pattern (“Uncolored Tiling Patterns,” page 269)
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
♠
♥
♦
♣
PLATE 10 Axial shading (“Type 2 (Axial) Shadings,” page 280)
PLATE 11 Radial shadings depicting a cone (“Type 3 (Radial) Shadings,” page 282)
Extend = [false
false], Background not specified
ABCDEFGHIJKL
M
ABCDEFGHIJKL
M
ABCDEFGHIJKLM
Extend
= [true
true], Background not specified
Extend
= [false
false], Background specified
Starting from
smaller circle
Starting from
larger circle
Neither circle extended Starting circle extended
PLATE 12
Radial shadings depicting a sphere (“Type 3 (Radial) Shadings,” page 283)
PLATE 13
Radial shadings with extension (“Type 3 (Radial) Shadings,” page 283)
PLATE 14
Radial shading effect (“Type 3 (Radial) Shadings,” page 283)
Starting from inner circle;
no background color specified
Starting from outer circle;
background color specified
No background color specified Background color specified
PLATE 16
Transparency groups (Section 7.1, “Overview of Transparency,” page 485)
PLATE 17
Isolated and knockout groups (Sections 7.3.4, “Isolated Groups,” page 507
and 7.3.5, “Knockout Groups,” page 508)
Ungrouped objects
Object opacity = 1.0
Ungrouped objects
Object opacity = 0.5
Transparency group
Object opacity = 1.0
Group opacity = 0.5
Blend mode = Normal
Transparency group
Object opacity = 0.5
Group opacity = 1.0
Blend mode = HardLight
Isolated
Non-isolated
Knockout Non-knockout
PLATE 18
RGB blend modes (Section 7.2.4, “Blend Mode,” page 490)
Duck in foreground, rainbow in background
ColorBurn
HardLi
g
h
t
SoftLi
g
h
t
Overlay
Screen
Multiply
Normal
ColorDodge
C
o
l
or
Luminosit
y
Satu
r
at
i
on
H
ue
Excl
u
si
on
Diff
e
r
e
n
ce
Lighten
Darken
Rainbow in foreground, duck in background
Color
Luminosity
Saturation
Hue
Exclusion
Difference
Li
g
hte
n
D
a
rke
n
C
o
l
o
rB
u
r
n
HardLight
SoftLight
Overla
y
Sc
r
een
Multipl
y
N
o
rm
a
l
ColorDod
ge
PLATE 19
CMYK blend modes (Section 7.2.4, “Blend Mode,” page 490)
Color
Luminosity
Saturation
Hue
Exclusion
Difference
Li
g
hte
n
D
a
rke
n
C
o
l
o
rB
u
r
n
HardLight
SoftLight
Overla
y
Sc
r
een
Multipl
y
N
o
rm
a
l
ColorDod
ge
Rainbow in foreground, duck in background
ColorBurn
HardLi
g
h
t
SoftLi
g
h
t
Overlay
Screen
Multiply
Normal
ColorDodge
Co
l
or
Luminosit
y
Satu
r
at
i
on
H
ue
Excl
u
si
on
Diff
e
r
e
n
ce
Lighten
Darken
Duck in foreground, rainbow in background
PLATE 20
Blending and overprinting (“Compatibility with Opaque Overprinting,” page 537)
O
v
e
r
p
r
i
n
t
+ Screen
Screen blending modeOverprint
axial shade from [0 0 1 0] to [0 1 0 0]
color = [0.5 0 0.5 0]
opacity = 0.5
Overprint + Screen
Screen blending modeOverprint
axialshadefrom[0010]to[0100]
color = [0.5 0 0.5 0]
opacity = 1.0
Opacity = 1.0
Opacity = 0.5
Overprint enabled
Overprint enabled
Axial shading from [0.0
0.0
1.0
0.0]
Axial shading from [0.0
0.0
1.0
0.0]
Blend mode
=
Screen
Blend mode
=
Screen
blend mode
=
Screen
Overprint enabled and
blend mode
=
Screen
Overprint enabled and
to [0.0
1.0
0.0
0.0]
to [0.0
1.0
0.0
0.0]
Color
=
[0.5
0.0
0.5
0.0]
Color
=
[0.5
0.0
0.5
0.0]
1057
Bibliography
This Bibliography provides details on books and documents, from both Adobe
Systems and other sources, that are referred to in this book.
Resources from Adobe Systems Incorporated
All of these resources from Adobe are available on the Adobe Solutions Network
(ASN) Web site. They can be accessed from this location:
<http://partners.adobe.com/asn/tech/pdf/pdf_ref_bibliography.jsp>
The ASN can also be contacted as follows:
Adobe Solutions Network
Adobe Systems Incorporated
345 Park Avenue
San Jose, CA 95110-2704
(800) 685-3510 (from North America)
(206) 675-6145 (from other areas)
Note:
Document version numbers and dates given in this Bibliography are the latest
at the time of publication; more recent versions may be found on the Web site.
Acrobat JavaScript Scripting Reference, Version 7.0
Adobe Glyph List, Version 2.0
Adobe Patent Clarification Notice
Adobe Type 1 Font Format
. Explains the internal organization of a PostScript
Type 1 font program. Also see Adobe Technical Note #5015,
Type 1 Font Format
Supplement
.
Digital Signature Appearances
Bibliography
1058
OPI: Open Prepress Interface Specification 1.3.
Also see Adobe Technical Note
#5660,
Open Prepress Interface (OPI) Specification, Version 2.0
.
OpenType Font Specification
PDF Signature Build Dictionary Specification for Acrobat 6.0
PostScript Language Reference
, Third Edition, Addison-Wesley, Reading, MA,
1999
XML Forms Architecture (XFA) Specification, version 2.2
XML Data Package Specification
XML Forms Data Format Specification, Version 2.0
XMP: Extensible Metadata Platform
Numbered Technical Notes:
•
Technical Note #5001,
PostScript Language Document Structuring Conventions
Specification, Version 3.0
•
Technical Note #5004,
Adobe Font Metrics File Format Specification, Version 4.1
Adobe font metrics (AFM) files are available through the Type section of the
ASN Web site.
•
Technical Note #5014,
Adobe CMap and CID Font Files Specification, Version
1.0
•
Technical Note #5015,
Type 1 Font Format Supplement
•
Technical Note #5044,
Color Separation Conventions for PostScript Language
Programs
•
Technical Note #5078,
Adobe-Japan1-4 Character Collection for CID-Keyed
Fonts
•
Technical Note #5079,
Adobe-GB1-4 Character Collection for CID-Keyed Fonts
•
Technical Note #5080,
Adobe-CNS1-4 Character Collection for CID-Keyed Fonts
•
Technical Note #5088,
Font Naming Issues
•
Technical Note #5092,
CID-Keyed Font Technology Overview
Bibliography
1059
•
Technical Note #5093,
Adobe-Korea1-2 Character Collection for CID-Keyed
Fonts
•
Technical Note #5094,
Adobe CJKV Character Collections and CMaps for CID-
Keyed Fonts
•
Technical Note #5097,
Adobe-Japan2-0 Character Collection for CID-Keyed
Fonts
•
Technical Note #5116
, Supporting the DCT Filters in PostScript Level 2
•
Technical Note #5146, Adobe-Japan1-5 Character Collection for CID-Keyed
Fonts (Addendum)
• Technical Note #5176, The Compact Font Format Specification
• Technical Note #5177, The Type 2 Charstring Format
• Technical Note #5411, ToUnicode Mapping File Tutorial
• Technical Note #5620, Portable Job Ticket Format, Version 1.1
• Technical Note #5660, Open Prepress Interface (OPI) Specification, Version 2.0
Other Resources
Aho, A. V., Hopcroft, J. E., and Ullman, J. D., Data Structures and Algorithms,
Addison-Wesley, Reading, MA, 1983. Includes a discussion of balanced trees.
Apple Computer, Inc., TrueType Reference Manual. Available on Apple’s Web site
at <http://developer.apple.com/fonts/TTRefMan/>.
Arvo, J. (ed.), Graphics Gems II, Academic Press, 1994. The section “Geometric-
ally Continuous Cubic Bézier Curves” by Hans-Peter Seidel describes the mathe-
matics used to smoothly join two cubic Bézier curves.
CIP4. See International Cooperation for the Integration of Processes in Prepress,
Press and Postpress.
Fairchild, M. D., Color Appearance Models, Addison-Wesley, Reading, MA, 1997.
Covers color vision, basic colorimetry, color appearance models, cross-media
color reproduction, and the current CIE standards activities. Updates, software,
and color appearance data are available at <http://www.cis.rit.edu/people/faculty/
fairchild/CAM.html>.
Bibliography
1060
Federal Information Processing Standards Publications:
• FIPS PUB 186-2, Digital Signature Standard, describes DSA signatures. It is
available at
<http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf>
• FIPS PUB 197, Advanced Encryption Standard (AES)
Foley, J. D. et al., Computer Graphics: Principles and Practice, Addison-Wesley,
Reading, MA, 1996. (First edition was Foley, J. D. and van Dam, A., Fundamentals
of Interactive Computer Graphics, Addison-Wesley, Reading, MA, 1982.) Covers
many graphics-related topics, including a thorough treatment of the mathematics
of Bézier cubics and Gouraud shadings.
Glassner, A. S. (ed.), Graphics Gems, Academic Press, 1993. The section “An Al-
gorithm for Automatically Fitting Digitized Curves” by Philip J. Schneider de-
scribes an algorithm for determining the set of Bézier curves approximating an
arbitrary set of user-provided points. Appendix 2 contains an implementation of
the algorithm, written in the C programming language. Other sections relevant to
the mathematics of Bézier curves include “Solving the Nearest-Point-On-Curve
Problem” and “A Bézier Curve-Based Root-Finder,” both by Philip J. Schneider,
and “Some Properties of Bézier Curves” by Ronald Goldman. The source code
appearing in the appendix is available via anonymous FTP, as described in the
preface to Graphics Gems III (edited by D. Kirk; see its entry below).
Hewlett-Packard Corporation, PANOSE Classification Metrics Guide. Available
on the Agfa Monotype Web site at <http://www.agfamonotype.com/printer/
pan1.asp>.
Hunt, R. W. G., The Reproduction of Colour, 5th ed., Fisher Books, England, 1996.
A comprehensive general reference on color reproduction; includes an introduc-
tion to the CIE system.
Institute of Electrical and Electronics Engineers, IEEE Standard for Binary Float-
ing-Point Arithmetic (IEEE 754-1985).
International Color Consortium (ICC). The following are available with related
documents at <http://www.color.org>:
• Specification ICC.1:2003-09, File Format for Color Profiles
• ICC Characterization Data Registry
Bibliography
1061
International Cooperation for the Integration of Processes in Prepress, Press and
Postpress (CIP4), JDF Specification, Version 1.2. Available through the CIP4 Web
site at <http://www.cip4.org>.
International Electrotechnical Commission (IEC), IEC/3WD 61966-2.1, Colour
Measurement and Management in Multimedia Systems and Equipment, Part 2.1:
Default RGB Colour Space—sRGB. Available through Hewlett-Packard’s sRGB
Web site at <http://www.srgb.com>.
International Organization for Standardization (ISO). The following standards
are available through <http://www.iso.org/>:
• ISO 639, Codes for the Representation of Names of Languages
• ISO 3166, Codes for the Representation of Names of Countries and Their Sub-
divisions
• ISO/IEC 8824-1, Abstract Syntax Notation One (ASN.1): Specification of Basic
Notation
• ISO/IEC 10918-1, Digital Compression and Coding of Continuous-Tone Still
Images (informally known as the JPEG standard, for the Joint Photographic Ex-
perts Group, the ISO group that developed the standard)
• ISO/IEC 15444-2, Information Technology—JPEG 2000 Image Coding System:
Extensions
International Telecommunication Union (ITU). The following can be ordered
from ITU at <http://www.itu.int/>
• Recommendations T.4 and T.6. These standards for Group 3 and Group 4 fac-
simile encoding replace those formerly provided in the CCITT Blue Book, Vol.
VII.3.
• Recommendation X.509 (1997): Information Technology—Open Systems Inter-
connection—The Directory: Authentication Framework.
Internet Engineering Task Force (IETF) Requests for Comments (RFCs). The
following RFCs are available through <http://www.rfc-editor.org>:
• RFC 1321, The MD5 Message-Digest Algorithm
• RFC 1738, Uniform Resource Locators
• RFC 1808, Relative Uniform Resource Locators
Bibliography
1062
• RFC 1950, ZLIB Compressed Data Format Specification, Version 3.3
• RFC 1951, DEFLATE Compressed Data Format Specification, Version 1.3
• RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies
• RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types
• RFC 2083, PNG (Portable Network Graphics) Specification, Version 1.0
• RFC 2315, PKCS #7: Cryptographic Message Syntax, Version 1.5
• RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax
• RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol—OCSP
• RFC 2616, Hypertext Transfer Protocol—HTTP/1.1
• RFC 3066, Tags for the Identification of Languages
• RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
• RFC 3174, US Secure Hash Algorithm 1 (SHA1)
• RFC 3280, Internet X.509 Public Key Infrastructure, Certificate and Certificate
Revocation List (CRL) Profile
Internet Engineering Task Force (IETF) Public Key Infrastructure (PKIX) work-
ing group: <http://www.ietf.org/html.charters/pkix-charter.html>
Kirk, D. (ed.), Graphics Gems III, Academic Press, 1994. The section “Interpola-
tion Using Bézier Curves” by Gershon Elber contains an algorithm for calculating
a Bézier curve that passes through a user-specified set of points. The algorithm
uses not only cubic Bézier curves, which are supported in PDF, but also higher-
order Bézier curves. The appendix contains an implementation of the algorithm,
written in the C programming language. The source code appearing in the
appendix is available via anonymous FTP, as described in the book’s preface.
Lunde, K., CJKV Information Processing, O’Reilly & Associates, Sebastopol, CA,
1999. Excellent background material on CMaps, character sets, encodings, and
the like.
Microsoft Corporation, TrueType 1.0 Font Files Technical Specification. Available
at <http://www.microsoft.com/typography/tt/tt.htm>.
Bibliography
1063
Netscape Communications Corporation, Client-Side JavaScript Reference and
other JavaScript documents are available through the Adobe Web page
<http://partners.adobe.com/NSjscript/>.
Pennebaker, W. B. and Mitchell, J. L., JPEG: Still Image Data Compression Stan-
dard, Van Nostrand Reinhold, New York, 1992.
Porter, T. and Duff, T., “Compositing Digital Images,” Computer Graphics, Vol. 18
No. 3, July 1984. Computer Graphics is the newsletter of the ACM’s special interest
group SIGGRAPH; for more information, see <http://www.acm.org>.
RSA Security, Inc. The following document, among others related to encryption
and digital signatures, is available at <http://www.rsasecurity.com>:
PKCS #1 - RSA Cryptography Standard
<http://www.rsasecurity.com/rsalabs/node.asp?id=2125>
Unicode Consortium publications:
• The Unicode Standard, Version 4.0, Addison-Wesley, Reading, MA, 2003. The
latest information is available at <http://www.unicode.org>.
• Unicode Standard Annex #9, The Bidirectional Algorithm, Version 4.0.0, Uni-
code Standard Annex #14, Line Breaking Properties, Version 4.0.0, and Unicode
Standard Annex #29, Text Boundaries, Version 4.0.0. These technical reports are
available at <http://www.unicode.org>.
World Wide Web Consortium (W3C). The following publications are available
through the W3C Web site at <http://www.w3.org/>:
• Cascading Style Sheets, level 2 (CSS2) Specification
<http://www.w3.org/TR/REC-CSS2/>
• Extensible Markup Language (XML) 1.1
<http://www.w3.org/TR/xml11/>
• Extensible Stylesheet Language (XSL) 1.0
<http://www.w3.org/TR/xsl/>
• HTML 4.01 Specification
<http://www.w3.org/TR/html401/>
• Scalable Vector Graphics (SVG) 1.0 Specification
<http://www.w3.org/TR/2001/REC-SVG-20010904/>
1065
Index
Page references in boldface mark principal or defining occurrences of a topic.
' (apostrophe) character
in dates 133
as text-showing operator 166
as text-showing operator. See
' (apostrophe) operator
' (apostrophe) operator 166, 368, 371, 377, 916
\ (backslash) character 29
as DOS (Windows) file name delimiter 153, 622
as escape character 30-31, 152, 155, 379
escape sequence for 30, 379
in unique names (Web Capture) 880-881
: (colon) character
in conversion engine names 889
as DOS file name delimiter 153
as Mac OS file name delimiter 154
$ (dollar sign) character 413
… (ellipsis) character 1000
! (exclamation point) character
in ASCII base-85 encoding 45, 46
< (left angle bracket) character 26
double, as dictionary delimiter 35, 73, 672
as hexadecimal string delimiter 29, 32, 35, 155
{ (left brace) character 26
as delimiter in PostScript calculator functions 149
[ (left bracket) character 26
as array delimiter 34, 1034
( (left parenthesis) character 26
escape sequence for 30, 379
as literal string delimiter 29
(minus sign) character
in dates 133
# (number sign) character
as hexadecimal escape character in names 33, 34, 389,
1005-1006
in uniform resource locators (URLs) 878
% (percent sign) character 26
as comment delimiter 27
in uniform resource locators, “unsafe” 878
. (period) character
double, in relative file specifications 153
double, in uniform resource locators (URLs) 878
in field names 639, 1023
in file names 154
in handler names 684
in uniform resource locators (URLs) 878
in unique names (Web Capture) 880
+ (plus sign) character
in dates 133
in font subset names 389
" (quotation mark) character
as text-showing operator. See
" (quotation mark)
operator
" (quotation mark) operator 166, 368, 371, 377, 916
> (right angle bracket) character 26
double, as dictionary delimiter 35, 73, 672
as EOD marker 45
as hexadecimal string delimiter 29, 32, 35, 155
} (right brace) character 26
as delimiter in PostScript calculator functions 149
] (right bracket) character 26
as array delimiter 34
) (right parenthesis) character 26
escape sequence for 30, 379
as literal string delimiter 29
/ (slash) character 26, 126
as file specification delimiter 152, 155
as name delimiter 32, 34, 114, 428, 673
in uniform resource locators (URLs) 887
as UNIX file name delimiter 154
~> (tilde, right angle bracket) character sequence
as EOD marker 45, 46
_ (underscore) character
in file specifications 154
in multiple master font names 386
¥ (yuan symbol) character 413
1.3 entry (OPI version dictionary) 907
2.0 entry (OPI version dictionary) 907
3D activation dictionaries 747, 750-751
A entry 750
AIS entry 750
D entry 751
DIS entry 751
Index
1066
3D annotation dictionaries 747-748
3DA entry 747, 749
3DB entry 748, 764
3DD entry 747, 748, 754
3DI entry 748
3DV entry 747, 749
Subtype entry 747
3D annotation type 581, 747
3D annotations 581, 747-752
activation 749-751
coordinate systems 765-767
normal appearance 747
target coordinate system 748, 757, 758, 760, 761, 767
See also
3D annotation dictionaries
3D artwork 746-767
clipping 760-762
instantiation 751-752
transformation matrices 758, 765-767
3D background dictionaries 764
C entry 764
CS entry 764
EA entry 764
Subtype entry 764
Type entry 764
3D graphics. See 3D artwork
3D models 746
3D object type 752
3D reference dictionaries 747, 748, 754-757
3DD entry 754
Type entry 754
3D stream dictionaries 752-754
DV entry 753
OnInstantiate entry 753, 754
Resources entry 753, 754
Subtype entry 752, 753, 758
Type entry 752
VA entry 633, 747, 749, 753, 753, 757
3D streams 747, 748, 752-757, 758
See also
3D stream dictionaries
3D view box 748, 761, 763, 764
3D view dictionaries 633, 753, 757-759
BG entry 758
C2W entry 758
CO entry 758
IN entry 633, 747, 753, 757
MS entry 758
O entry 758, 758
P entry 758, 760
Type entry 757
U3DPath entry 758
XN entry 757
3D views 757-764
3DA entry (3D annotation dictionary) 747, 749
3DB entry (3D annotation dictionary) 748, 764
3DBG object type 764
3DD entry
3D annotation dictionary 747, 748, 754
3D reference dictionary 754
3DI entry (3D annotation dictionary) 748
3DRef object type 754
3DV entry (3D annotation dictionary) 747, 749
3DView object type 757
83pvRKSJH predefined CMap 414, 417
90msRKSJH predefined CMap 414, 417
90msRKSJV predefined CMap 414, 417
90mspRKSJH predefined CMap 414, 417
90mspRKSJV predefined CMap 414, 417
90pvRKSJH predefined CMap 414, 417
A
A entry
3D activation dictionary 750
annotation dictionary 572, 609, 611, 616, 684
FDF field dictionary 678
hint stream dictionary 951
icon fit dictionary 679
media criteria dictionary 716
media play parameters
MH/BE dictionaries 726
media players dictionary 718, 734, 735
movie annotation dictionary 572, 602, 741
outline item dictionary 555, 609, 616
rectilinear measure dictionary 706
structure element dictionary 788, 788, 802, 803, 804,
842, 844
target dictionary 619
A85 filter abbreviation 324, 1007
AA entry
annotation dictionary 572, 602, 610, 638, 684
document catalog 116, 611, 1011
document catalog (obsolete) 1011
FDF field dictionary 678
field dictionary 610, 638
outline item dictionary (obsolete) 1018
page object 122, 610
abbreviations and acronyms, expansion of 864, 872-873
font characteristics unavailable for 821
for marked-content sequences 872
for structure elements 788
in Tagged PDF 816
and Unicode natural language escape 873
abs operator (PostScript) 149, 917
Index
1067
absolute file specifications 152-153
AbsoluteColorimetric rendering intent 231
Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation (ISO/IEC 8824-1) 133, 1061
AC entry (appearance characteristics dictionary) 604
accented characters 395, 427
Accepted annotation state 585
access flags 99-100
access permissions
copyright 7
document 699
flags 99-100
operations 96-98
public-key security handlers 104
standard security handler 96
accessibility to users with disabilities 769, 863-873
access permissions 97, 99, 100
alternate descriptions 571, 581, 788
annotation contents 582
content extraction for 864
field contents 637
replacement text 788
Span marked-content tag 834
standard structure types 827
Tagged PDF and 812, 813, 816, 842
See also
abbreviations and acronyms, expansion of
alternate descriptions
natural language specification
replacement text
accurate screens algorithm 468
AccurateScreens entry (type 1 halftone dictionary) 467,
468
ACFM (Adobe Composite Font Metrics) file format 366
achromatic highlight, diffuse 218
achromatic shadow, diffuse 218
Acrobat
®
PDF viewer application xxi, 1
Create Thumbnails command 1007, 1033
Document Properties dialog box 1030
error reporting 1002-1003, 1004, 1007, 1008, 1011,
1012, 1013, 1017, 1018, 1020, 1022, 1023, 1030
Find command 1007
implementation limits 1, 919-921
implementation notes 1005-1035
indirect processing of PDF 19, 21
JPEG implementation 61
native file formats 1005, 1012
plug-in extensions 898, 937
Print As Image feature 97, 1009
RC4 encryption algorithm 94
scan conversion 478
trademark 8
TrueType font encodings, treatment of 400-403
Type 0 fonts, naming of 423
version compatibility 1, 423, 1001-1035
Web Capture plug-in extension 116
WebLink plug-in extension 1022
Acrobat Distiller
®
PDF producer application 20-21, 772
balanced trees 117
OPI comments 1033
PostScript names, compatibility with 1006
spot functions 1017
Acrobat JavaScript Scripting Reference 668, 746, 754, 1029,
1057
AcroForm entry (document catalog) 116, 634, 949
AcroForms
See interactive forms
acronyms
See abbreviations and acronyms, expansion of
AcroSpider
See Web Capture plug-in extension
action dictionaries 115, 609-610
Next entry 610, 632
S entry 610
Type entry 610
See also
embedded go-to action dictionaries
go-to-3D-view action dictionaries
go-to action dictionaries
hide action dictionaries
import-data action dictionaries
JavaScript action dictionaries
launch action dictionaries
movie action dictionaries
named-action dictionaries
remote go-to action dictionaries
rendition action dictionaries
reset-form action dictionaries
set-OCG-state action dictionaries
sound action dictionaries
submit-form action dictionaries
thread action dictionaries
transition action dictionaries
URI action dictionaries
Action entry
FieldMDP transform parameters dictionary 695
signature field lock dictionary 659
action handlers 937
Action object type 610
action types 609, 610, 614-633, 662-669
FirstPage 628
GoTo 615, 616
GoTo3DView 615, 633
GoToE 615, 618
GoToR 615, 617
Index
1068
Hide 615, 628, 1022
ImportData 615, 668
JavaScript 615, 668
LastPage 628
Launch 615, 622
Movie 615, 627, 1022
Named 615, 629, 1023
NextPage 628
PrevPage 628
Rendition 615, 631
ResetForm 615, 667
SetOCGState 356, 615, 629
Sound 615, 625
SubmitForm 615, 662
Thread 615, 623
Trans 615, 632
URI 615, 624
actions 9, 115, 609-633
for annotations 572, 587, 609
chaining of 610
destinations for 551
for FDF fields 678
handlers 937
and named destinations 553
for outline items 554, 555, 609
plug-in extensions for 937, 1002
type. See action types
See also
action dictionaries
additional-actions dictionaries
FirstPage named action
go-to actions
go-to-3D-view actions
hide actions
import-data actions
JavaScript actions
LastPage named action
launch actions
movie actions
named actions
NextPage named action
PrevPage named action
remote go-to actions
rendition actions
reset-form actions
set-OCG-state actions
sound actions
submit-form actions
thread actions
transition actions
trigger events
URI actions
activating
annotations 568, 572, 587, 600, 601, 609, 678, 953, 972,
1020
outline items 554, 555, 609, 1018
sound annotations 739
activation of 3D annotations 749-751
ActualText entry
property list 820, 834, 871
structure element dictionary 441, 788, 816, 842, 844,
871, 872
Alt entry, compared with 872
and font characteristics 821
for illustrations 842
and Unicode mapping 820
and word breaks 823
adbe.pkcs7.detached (PKCS#7 signature) 686, 686, 697
adbe.pkcs7.s3 public-key encryption format 104, 105, 106
adbe.pkcs7.s4 public-key encryption format 104, 105, 106
adbe.pkcs7.s5 public-key encryption format 104, 105, 106
adbe.pkcs7.sha1 (PKCS#7 signature) 686, 686, 697
adbe.x509.rsa_sha1 (PKCS#1 signature) 686, 686, 697
add operator (PostScript) 149, 917
AddRKSJH predefined CMap 414, 417
AddRKSJV predefined CMap 414, 417
additional-actions dictionaries 116, 122, 610-613, 627,
1011
for annotations 572
Bl entry (widget annotation) 612
C entry
form field 613, 635
page object 611, 612, 612, 1021
D entry (annotation) 611
DC entry (document catalog) 613
DP entry (document catalog) 613
DS entry (document catalog) 613
E entry (annotation) 611
F entry (form field) 613
for FDF fields 678
Fo entry (widget annotation) 611
for form fields 638
FP entry (obsolete) 1021
inheritability of 1021
K entry (form field) 612
LP entry (obsolete) 1021
NP entry (obsolete) 1021
O entry (page object) 611, 612, 1021
PC entry (annotation) 611, 612
PI entry (annotation) 611, 612
PO entry (annotation) 611, 612
PP entry (obsolete) 1021
PV entry (annotation) 611, 612
U entry (annotation) 611
V entry (form field) 613
WP entry (document catalog) 613
Index
1069
WS entry (document catalog) 613
X entry (annotation) 611, 614
additive color representation 211
for blend modes 490, 540
in blending color space 489, 525
and default color spaces 228
DeviceRGB color space 212
and halftones 457
overprinting, not typically subject to 540
primary color components 211, 213
in soft-mask images 522
transfer functions, input to 455
transfer functions, output from 455, 458
additive colorants 234
See also
blue colorant
green colorant
red colorant
additive output devices 234, 236, 457
Adobe CJKV Character Collections and CMaps for CID-
Keyed Fonts (Adobe Technical Note #5094) 1059
Adobe CMap and CID Font Files Specification (Adobe Tech-
nical Note #5014) 404, 405, 418, 419, 422, 442,
1058
Adobe-CNS1 character collection 414, 416-417, 433, 442,
1017
Adobe-CNS1-4 Character Collection for CID-Keyed Fonts
(Adobe Technical Note #5080) 1058
Adobe Composite Font Metrics (ACFM) file format 366
Adobe Font Metrics (AFM) file format 366, 386, 1058
Adobe Font Metrics File Format Specification (Adobe Tech-
nical Note #5004) 366, 386, 1058
Adobe Garamond
®
typeface 384
Adobe-GB1 character collection 413, 416, 433, 442, 1017
Adobe-GB1-4 Character Collection for CID-Keyed Fonts
(Adobe Technical Note #5079) 1058
Adobe Glyph List 401, 441, 1057
Adobe-Identity character collection 417
Adobe imaging model xxi, 10, 11-12
and indirect generation of PDF 19, 20
memory representation, independent of 14
and PostScript 6, 303
rendering 447
and transparent annotations 578, 583
Adobe-Japan1 character collection 414, 415, 417, 433, 434,
442, 1017
Adobe-Japan1-4 Character Collection for CID-Keyed Fonts
(Adobe Technical Note #5078) 1058
Adobe-Japan1-5 Character Collection for CID-Keyed Fonts
(Addendum) (Adobe Technical Note #5146) 1059
Adobe-Japan2 character collection 433, 434
Adobe-Japan2-0 Character Collection for CID-Keyed Fonts
(Adobe Technical Note #5097) 1059
Adobe-Korea1 character collection 415, 417, 433, 434,
442, 1017
Adobe-Korea1-2 Character Collection for CID-Keyed Fonts
(Adobe Technical Note #5093) 1059
Adobe Patent Clarification Notice 8, 1057
Adobe PDF printer 19-20
Adobe.PPKLite signature handler 686
Adobe products
See
Acrobat
®
PDF viewer application
Acrobat Distiller
®
PDF producer application
Adobe Garamond
®
typeface
Adobe Reader
®
PDF viewer application
Extreme
®
printing systems
FrameMaker
®
document publishing software
Illustrator
®
graphics software
InDesign
®
page layout software
Minion
®
Pro typeface
Myriad
®
Pro typeface
PageMaker
®
page layout software
Photoshop
®
image editing software
Poetica
®
typeface
XMP (Extensible Metadata Platform) framework
Adobe Reader
®
PDF viewer application xxi, 1, 8, 692, 700
Adobe Solutions Network (ASN) 406
contact addresses 1057
registering names 938
telephone numbers 1057
Web site 366, 386, 406, 418, 442, 1057, 1058
Adobe standard encoding
See
StandardEncoding standard character encoding
Adobe Technical Notes 418, 1058
#5001 (PostScript Language Document Structuring Con-
ventions Specification) 1058
#5004 (Adobe Font Metrics File Format Specification)
366, 386, 1058
#5014 (Adobe CMap and CID Font Files Specification)
404, 405, 418, 419, 422, 442, 1058
#5015 (Type 1 Font Format Supplement) 386, 1057,
1058
#5044 (Color Separation Conventions for PostScript
Language Programs) 1012, 1058
#5078 (Adobe-Japan1-4 Character Collection for CID-
Keyed Fonts) 1058
#5079 (Adobe-GB1-4 Character Collection for CID-
Keyed Fonts) 1058
#5080 (Adobe-CNS1-4 Character Collection for CID-
Keyed Fonts) 1058
#5088 (Font Naming Issues) 387, 1058
#5092 (CID-Keyed Font Technology Overview) 404,
1058
Index
1070
#5093 (Adobe-Korea1-2 Character Collection for CID-
Keyed Fonts) 1059
#5094 (Adobe CJKV Character Collections and CMaps
for CID-Keyed Fonts) 1059
#5097 (Adobe-Japan2-0 Character Collection for CID-
Keyed Fonts) 1059
#5116 (Supporting the DCT Filters in PostScript Level
2) 1059
#5146 (Adobe-Japan1-5 Character Collection for CID-
Keyed Fonts (Addendum)) 1059
#5176 (The Compact Font Format Specification) 383,
436, 437, 1059
#5177 (The Type 2 Charstring Format) 1059
#5411 (ToUnicode Mapping File Tutorial) 442, 1059
#5620 (Portable Job Ticket Format) 24, 448, 903, 906,
1059
#5660 (Open Prepress Interface (OPI) Specification)
908, 1058, 1059
Digital Signature Appearances 658, 1057
OpenType Font Specification 437, 439, 1058
PDF Signature Build Dictionary Specification for Acro-
bat 6.0 688, 1058
XFA Specification 681, 683, 1058
XML Data Package Specification 635, 681, 1058
XML Forms Data Format Specification, Version 2.0 666,
1058
Adobe Type 1 Font Format 382, 383, 436, 438, 439, 1057
Adobe® Intelligent Document Platform xxi-xxii
Adobe.PPKLite public-key security handler 104
Adobe.PubSec public-key security handler 104
advance timing
See display duration
Advanced Encryption Standard (FIPS PUB 197) 95, 1060
Advanced Encryption Standard. See AES
AES encryption algorithm 95, 95, 108
AESV2 decryption method (crypt filters) 97, 108, 109
AFM (Adobe Font Metrics) file format 366, 386, 1058
After block alignment 854
after edge 825
of allocation rectangle 860
border color 849
border style 849
border thickness 850
in layout 825, 847, 851, 854, 855, 861
padding width 850, 855
ruby text position 858
After entry (JavaScript dictionary) 676
After ruby text position 858
AfterPermsReady entry (JavaScript dictionary) 676
AHx filter abbreviation 324, 1007
AIFF (Audio Interchange File Format) 739, 1028
AIFF-C (Audio Interchange File Format, Compressed)
739
AIS entry
3D activation dictionary 750
graphics state parameter dictionary 193, 518
ALaw sound encoding format 740
%ALDImageAsciiTag OPI comment (PostScript) 911
%ALDImageColor OPI comment (PostScript) 910
%ALDImageColorType OPI comment (PostScript) 910
%ALDImageCropFixed OPI comment (PostScript) 909
%ALDImageCropRect OPI comment (PostScript) 909
%ALDImageDimensions OPI comment (PostScript) 909
%ALDImageFilename OPI comment (PostScript) 908
%ALDImageGrayMap OPI comment (PostScript) 910
%ALDImageID OPI comment (PostScript) 908
%ALDImageOverprint OPI comment (PostScript) 910
%ALDImagePosition OPI comment (PostScript) 909
%ALDImageResolution OPI comment (PostScript) 909
%ALDImageTint OPI comment (PostScript) 910
%ALDImageTransparency OPI comment (PostScript) 910
%ALDImageType OPI comment (PostScript) 910
%ALDObjectComments OPI comment (PostScript) 908
Aldus Corporation 907
“Algorithm for Automatically Fitting Digitized Curves, An”
(Schneider) 1060
algorithm tags (PNG predictor functions) 52
All action
FieldMDP transform parameters 695
signature field lock dictionary 659
all-cap fonts 429
All colorant name
DeviceN color spaces, prohibited in 240
in
Separation color spaces 236
All intent (optional content) 346
AllCap font flag 429
allocation rectangle 826, 859-860
in layout 847, 854
AllOff visibility policy (optional content membership
dictionary) 336, 337, 342
AllOn visibility policy (optional content membership
dictionary) 336, 337
AllPages list mode (optional content configuration
dictionary) 347
alpha 485
alpha source parameter 182, 193, 311, 518, 519
backdrop. See backdrop alpha
in basic compositing formula 487, 488
current alpha constant 182, 192, 311
group backdrop 503
group. See group alpha
Index
1071
interpretation of 493-494
notation for 487
object 503, 504, 505, 507
premultiplied. See preblending of soft-mask image data
result. See result alpha
shape and opacity, product of 487, 494, 498, 503, 510
source. See source alpha
alpha constant, current
See current alpha constant
alpha mask
See soft masks
Alpha soft-mask subtype 520, 521
alpha source parameter 182
AIS entry (graphics state parameter dictionary) 193
constant opacity 519
constant shape 519
ignored by older viewer applications 1018
mask opacity 518
mask shape 518
soft-mask images 311
Alphabetic glyph class 433, 434
AlphaNum glyph class 434
Alt entry
media clip data dictionary 721
media clip section dictionary 723
property list 820, 834, 870, 871
structure element dictionary 788, 816, 842, 844, 870,
871
ActualText entry, compared with 872
and font characteristics 821
for illustrations 842
and Unicode mapping 820
alternate color space
and color separations 898
for
DeviceN color spaces 148, 228, 240-241, 242, 256,
277
and flattening of transparent content 545
for
ICCBased color spaces 223, 224
and overprinting 237, 241
for
Separation color spaces 228, 236, 237, 277
in soft masks 520
and spot color components 532, 533
and transparent imaging model 237, 241, 489
and transparent overprinting 537
alternate descriptions 863, 870-871
for annotations 571, 581, 870
font characteristics unavailable for 821
for marked-content sequences 870
for sound annotations 870
for structure elements 788, 815, 870, 871
in Tagged PDF 816
and Unicode natural language escape 871
Alternate entry (ICC profile stream dictionary) 223, 224
alternate field names 637, 870-871
alternate image dictionaries 317
DefaultForPrinting entry 317
Image entry 317
OC entry 317, 319
alternate images 305, 309, 311, 317-318
optional content 317, 319
printing 317
See also
alternate image dictionaries
alternate presentations 125, 743-745
slideshows 744, 1029
AlternateImages entry (legal attestation dictionary) 702
AlternatePresentations entry (name dictionary) 125, 743
Alternates entry (image dictionary) 311, 319, 523
AN entry (rendition action dictionary) 631
anamorphic scaling 679
and operator (PostScript) 149, 918
angle (halftone screen) 458
type 1 halftones 466, 467, 467, 468
type 10 halftones 466, 469, 470, 472
type 16 halftones 466, 473
angle brackets (
< >)26
double, as dictionary delimiters 35, 73, 672
as hexadecimal string delimiters 29, 32, 35, 155
Angle entry (type 1 halftone dictionary) 467
Annot object type 570, 993, 998
Annot standard structure type 818, 836, 839
annotation dictionaries 121, 570-573, 993, 998, 1019
A entry 572, 609, 611, 616, 684
AA entry 572, 602, 610, 638, 684
AP entry 571, 578, 586, 589, 590, 594, 595, 596, 598,
599, 600, 601, 602, 640, 650, 658, 666, 747, 896, 904,
1019
AS entry 571, 579, 580, 896, 903, 904, 905, 1019
Border entry 572, 575, 576, 1019
BS entry 571, 572, 575, 576, 577, 594, 1019, 1020
C entry 572, 599
Contents entry 571, 580, 581, 582, 591, 599, 600, 645,
870
F entry 571, 573, 611, 677, 678, 896, 904
and hide actions 628
in Linearized PDF 953
M entry 571, 599, 1019
NM entry 571, 583
OC entry 573
P entry 571, 602, 632
Page entry (FDF files) 681
Rect entry 570, 574, 575, 577, 588, 593, 594, 595, 597,
607, 624, 641, 658, 748, 839
StructParent entry 573, 798
Subtype entry 570, 580
Index
1072
Type entry 570
See also
3D annotation dictionaries
caret annotation dictionaries
circle annotation dictionaries
FDF annotation dictionaries
file attachment annotation dictionaries
free text annotation dictionaries
ink annotation dictionaries
line annotation dictionaries
link annotation dictionaries
markup annotation dictionaries
movie annotation dictionaries
polygon annotation dictionaries
polyline annotation dictionaries
pop-up annotation dictionaries
printer’s mark annotation dictionaries
rubber stamp annotation dictionaries
screen annotation dictionaries
sound annotation dictionaries
square annotation dictionaries
text annotation dictionaries
text markup annotation dictionaries
trap network annotation dictionaries
watermark annotation dictionaries
widget annotation dictionaries
annotation elements (Tagged PDF) 839
Annotation entry (movie action dictionary) 627
annotation flags 571, 573-575, 677-678, 1019-1020
Hidden 573, 627, 632, 814, 1019, 1023
Invisible 573
Locked 574, 1020
NoRotate 574, 574, 575, 586
NoView 574, 632
NoZoom 574, 574, 586
Print 573, 896, 904, 1019, 1020
ReadOnly 574, 896, 904
ToggleNoView 574, 1020
annotation handlers 570, 573, 937
annotation icons 568, 1020
Approved 598
AsIs 598
background color 572
for button fields 678-679
Comment 586
Confidential 598
Departmental 598
Draft 598
Experimental 598
Expired 598
for file attachment annotations 600
Final 598
ForComment 598
ForPublicRelease 598
Graph 600
Help 586
Insert 586
Key 586
Mic 601
NewParagraph 586
NotApproved 598
Note 586
NotForPublicRelease 598
Paperclip 600
Paragraph 586
PushPin 600
for rubber stamp annotations 598
scaling 679
Sold 598
for sound annotations 601
Speaker 601
Tag 600
for text annotations 586, 586
TopSecret 598
for widget annotations 604-605, 678-679
annotation rectangle 570
and appearance streams 577, 605, 641
border style 575, 576
for circle annotations 593
coordinate system 577
highlighting 587, 603
for movie annotations 626, 743
for printer’s mark annotations 894
rotation 574, 575
scaling 574, 575
for signature fields 658
for square annotations 593
and submit-form actions 664
for text fields 653
and URI actions 624
for widget annotations 678, 679
annotation states 585, 586
Accepted 585
Cancelled 585
Completed 585
Marked 585
None 585
Rejected 585
state models 585, 586
Unmarked 585
annotation types 568, 570, 580-581, 1020-1021
3D 581, 747
Caret 581, 597
Circle 580, 594
dictionary entries for 570
FileAttachment 581, 600
FreeText 580, 589
handlers for 570
Index
1073
and Hidden flag 573
Highlight 581, 596, 839
Ink 581, 598
Line 580, 590
Link 580, 582, 587, 674
markup 581-584
Movie 581, 582, 601, 674
plug-in extensions for 570, 579
Polygon 580, 595, 596
PolyLine 580, 595, 595
Popup 581, 599
PrinterMark 581, 582, 674, 896
Screen 581, 602, 674
Sound 581, 601
Square 580, 594
Squiggly 581, 596
Stamp 581, 598
StrikeOut 581, 596
Text 580, 586
text markup 596
TrapNet 581, 582, 605, 674, 904, 905
Underline 581, 596
unknown 573, 579
Watermark 581, 606
Widget 581, 582, 603, 674
annotations 9, 23, 568-609, 747-752
actions for 572, 587, 609
activating 568, 572, 587, 600, 601, 609, 678, 953, 972,
1020
active area 578, 587, 603, 604, 605, 611, 614, 627
additional-actions dictionary 572
alternate description 571, 581, 870
annotation rectangle. See annotation rectangle
appearance dictionary 571, 573, 578-579
appearance state 571, 579, 609, 648, 651
appearances. See appearance streams
blend mode 578, 583
border style. See border styles
border width 572, 575, 576, 590, 594, 595, 599
color 572
corner radii 572
dash pattern 571, 572, 576, 590, 594, 599
destinations for 551, 553, 587, 1020
in FDF 669, 670, 674
flags. See annotation flags
handlers 570, 573, 937
hiding and showing 573, 574, 627, 628
highlighting 578, 587, 603
icon. See annotation icons
label 583, 665
in Linearized PDF 953, 961, 972
as logical structure content items 818
in logical structure elements 796
marked-content sequences, association with 818
modification date 571
name 571
optional content and 344, 573
in page content order, sequencing of 818
and page objects 112
plug-in extensions for 570, 937, 1002
pop-up window 572, 583, 665
PostScript conversion to 22
printing 573, 574, 578, 1020
as real content 814
and reference XObjects 333
replies 583, 584, 585
rotating 574, 586
scaling 574, 586, 679
states 585
in structural parent tree 786
and submit-form actions 664, 665
tab order 569-570, 1019
and trap networks 905
trigger events for 611-612
type. See annotation types
in updating example 992, 993, 995, 996, 997, 998, 1000
URI actions for 624
user interaction 573, 574, 577, 578, 603
version compatibility 1005
See also
annotation dictionaries
3D annotations
circle annotations
file attachment annotations
free text annotations
ink annotations
line annotations
link annotations
markup annotations
movie annotations
caret annotations
polygon annotations
polyline annotations
pop-up annotations
printer’s mark annotations
rubber stamp annotations
screen annotations
sound annotations
square annotations
text annotations
text markup annotations
trap network annotations
widget annotations
Annotations entry (legal attestation dictionary) 702
Annots entry
FDF dictionary 674
page object 121, 570, 602, 606, 632, 818, 903, 905, 953,
993, 996, 997, 998, 1033
Index
1074
UR transform parameters dictionary 694
AnnotStates entry (trap network annotation dictionary)
904, 905
AntiAlias entry (shading dictionary) 275
anti-aliasing
shading patterns 275
transparency 485, 495
AnyOff visibility policy (optional content membership
dictionary) 336, 337
AnyOn visibility policy (optional content membership
dictionary) 336, 337
AP entry
annotation dictionary 571, 578, 586, 589, 590, 594,
595, 596, 598, 599, 600, 601, 602, 640, 650, 658, 666,
747, 896, 904, 1019
FDF field dictionary 678, 1026
name dictionary 125, 580
API. See application programming interface
apostrophe (
') character
in dates 133
as text-showing operator 166, 368, 371, 377, 916
AppDefault page scaling 550
appearance characteristics dictionaries
AC entry 604
BC entry 604
BG entry 604
CA entry 604
I entry 604
IF entry 605
IX entry 605
R entry 604
RC entry 604
RI entry 605
TP entry 605
for widget annotations 604-605
appearance dictionaries 571, 578-579
D entry 579, 678, 896, 904
N entry 579, 579, 640, 678, 747, 814, 896, 903, 905
for pushbutton fields 678
R entry 579, 678, 896, 904
subdictionaries 571, 579, 896, 903
and unknown annotation types 573
for widget annotations 635, 648
appearance states 571, 579, 609
for check box fields 648, 651
for printer’s marks 896
in trap networks 903, 905
appearance streams 577-580
appearance states, selected by 571
backdrop 578
for button fields 669
as content streams 126, 813
coordinate system 577
default font 635
down appearance 578, 603
dynamic 603, 634
and form fields 634, 639
and
Form standard structure type 841
marked-content sequences in 792
named 125, 580
normal appearance 578, 579, 814
opacity 583
pop-up annotations, inapplicable to 599
and pop-up help systems 573, 627
for printer’s mark annotations 896
and reference XObjects 333
resources 128, 1023
rollover appearance 578
soft mask 578
and transparency 578
transparency groups as 526
for trap network annotations. See trap network appear-
ances
and unknown annotation types 573
for widget annotations 635, 640, 648, 841
appearances, annotation
See appearance streams
AppendOnly signature flag 636
Apple Computer, Inc.
Mac
®
OS operating system 19, 395, 928
TrueType
®
font format 387
TrueType Reference Manual 387, 1059
application data dictionaries 329, 776-777
LastModified entry 777
Private entry 777
application/pdf content type (MIME) 664
application programming interface (API) 19
application-specific data 18
application/vnd.fdf content type (MIME) 670
application/x-www-form-urlencoded content type (MIME)
886
applications
launching 609, 621, 622
See also
consumer applications, PDF
consumer applications, Tagged PDF
producer applications, PDF
producer applications, Tagged PDF
Approved annotation icon 598
APRef entry (FDF field dictionary) 678
Arabic writing systems 818, 848
Arial standard font name 1015
Arial,Bold standard font name 1015
Arial,BoldItalic standard font name 1015
Arial,Italic standard font name 1015
Index
1075
array objects 26, 27, 34
capacity limit 34
as dictionary values 131
null elements 28
syntax 34
arrays
color space. See color space arrays
explicit destinations, defining 551, 553
multi-language text 869-870
related files 156, 159-160, 162
See also
array objects
art box 891
and bounding box 332
clipping to 893
display of 895
imposition of pages, ignored in 893
in page object 120
page placement in another document 893
printer’s marks excluded from 894
printing, ignored in 893
Art standard structure type 827, 828, 833
ArtBox entry
box color information dictionary 895
page object 120, 891, 1032
articles 558, 560-562
in document catalog 112, 115
in Linearized PDF 971, 973
and page content order 817
in page objects 121, 1011
as structure elements (Tagged PDF) 828
and text discontinuities 816
See also
beads
threads
Artifact marked-content tag 814
artifact types 814
Layout 814
Page 814
Pagination 814
artifacts (Tagged PDF) 812, 813-817
attached 815
bounding box 815
incidental 816-817
layout 815
logical structure order, excluded from 817
page 815
page content order, included in 817
pagination 815
property list 814-815
specification 814
See also
artifact types
AS entry
annotation dictionary 571, 579, 580, 896, 903, 904,
905, 1019
optional content configuration dictionary 347, 349,
352, 353, 356
Ascent entry (font descriptor) 427, 856
ASCII (American Standard Code for Information
Interchange) 24-25
base-85 encoding 15, 41, 42, 43, 45-46
character set 25, 26, 31
compression 42
in file specifications 152, 154, 155
filters 42
hexadecimal encoding 41, 43, 45, 58, 96
LZW encoding 48
nonprinting characters 30
for PDF representation 15
for portability 41
strings and streams 25
text files 770, 873
TIFF tags 911
in uniform resource locators (URLs) 161, 878
in unique names (Web Capture) 880, 881
UTF-8 character encoding 34
ASCII85Decode filter 43, 45-46
A85 abbreviation 324, 1007
in inline images 322
ASCIIHexDecode filter 41, 43, 45
AHx abbreviation 324, 1007
in inline images 322
Asian writing systems 365, 404
AsIs annotation icon 598
ASN. See Adobe Solutions Network
ASN.1 (Abstract Syntax Notation One) 133
Aspect entry (movie dictionary) 741, 743, 1029
atan operator (PostScript) 149, 917
AToB transformation (ICC color profile) 225, 489, 900,
1032
Attached entry (property list, Tagged PDF artifact) 815
Attestation entry (legal attestation dictionary) 701, 702
attribute classes 802
class map 786
name 786, 788, 802, 803, 842
revision number 788, 802, 803
and standard attribute owners 842
structure elements belonging to 788, 802
attribute objects 801
for attribute classes 802
O entry 801, 804, 843, 845, 862, 863
owner 801, 843
P entry 804, 805
revision number 803-804
Index
1076
role map 786
standard attribute owners 842-843, 845
structure elements, associated with 788
attribute owners, standard
See standard attribute owners
attribute revision numbers 788, 788, 802, 803-804
generation numbers, distinguished from 803
attributes dictionary (
DeviceN color spaces). See DeviceN
color space attributes dictionaries
AU (NeXT/Sun Audio Format) file format 1028
AU entry (source information dictionary) 884
authenticity of documents, certifying 18
AuthEvent entry (crypt filter dictionary) 97, 107, 108
Author entry (document information dictionary) 772
author signature. See MDP signatures 685
Auto glyph orientation 858, 859
Auto height attribute 853, 860
Auto line height 856
Auto width attribute 853, 860
automatic stroke adjustment 1018
See stroke adjustment, automatic
Average predictor function (LZW and Flate encoding) 51,
52
AvgWidth entry (font descriptor) 428
AVI (Audio/Video Interleaved) file format 1028
axial shadings
See type 2 shadings
B
B border style (beveled) 576
B entry
hint stream dictionary 952
media clip section
MH/BE dictionaries 724, 725
media screen parameters
MH/BE dictionaries 729
page object 121, 560, 669, 953, 1011
sound object 739, 740
thread action dictionary 623
transition dictionary 565
B operator 166, 200, 913
and transparent overprinting 538
b operator 166, 195, 200, 913
and transparent overprinting 538
<b> XHTML element (rich text strings) 643
B* operator 166, 200, 913
and transparent overprinting 538
b* operator 166, 200, 913
and transparent overprinting 538
B5pcH predefined CMap 413, 416
B5pcV predefined CMap 413, 416
backdrop 484
for annotation appearances 578
compositing with 165, 204, 486
and fully opaque objects 542
group. See group backdrop
immediate (transparency group element). See immedi-
ate backdrop
initial (transparency group). See initial backdrop
for page group 486, 507, 510, 511, 512
for patterns 528, 529
and transparent overprinting 538
See also
backdrop alpha
backdrop color
backdrop opacity
backdrop shape
backdrop alpha
in compositing 494
notation 488, 503
backdrop color 487
backdrop fraction 506
blending color space, conversion to 489
and CompatibleOverprint blend mode 536, 537
in compositing 485, 493, 494
and nonseparable blend modes 493
notation 488, 503, 511
and overprinting 535
for page group 510
removal from compositing computations 506
and separable blend modes 490, 491, 492
and soft masks 513, 514, 515, 521
specifying 516
spot color components 532
in transparency groups 505
backdrop fraction 506
backdrop opacity 485, 498
notation 497
and overprinting 535
backdrop shape 498
notation 497
background color (Tagged PDF) 848
background dictionaries 758
Background entry (shading dictionary) 273, 275, 279, 280,
528
BackgroundColor standard structure attribute 845, 848
backslash (
\) character 29
as DOS (Windows) file name delimiter 153, 622
as escape character 30-31, 152, 155, 379
escape sequence for 30, 379
in unique names (Web Capture) 880-881
backspace (BS) character
escape sequence for 30
balanced trees 117, 1059
Index
1077
BarcodePlainText form usage rights 694
<BASE> body element (universal resource identifier) 625
base color space (
Indexed color space) 228, 232-233, 277,
531, 537
base encoding 397, 430, 924
Base entry (URI dictionary) 625
base images 309, 317, 317, 321, 1013
base URI (URI action) 625
base URL (media clip data) 723
BaseEncoding entry (encoding dictionary) 397, 399, 401,
1016
BaseFont entry
CIDFont dictionary 407, 423, 426
font dictionary 426
font subset 389, 1016
multiple master font dictionary 386
TrueType font dictionar y 388-389
Type 0 font dictionary 423
Type 1 font dictionary 34, 303, 383
baseline shift (ILSEs) 855
BaselineShift standard structure attribute 834, 841, 846,
855, 860, 861
BaseState entry (optional content configuration
dictionary) 346, 355
basic compositing formula
See compositing computations
BBox entry
property list (Tagged PDF artifact) 815
shading dictionary 275, 278, 282
type 1 form dictionary 327, 577, 328, 332, 526, 640,
859, 860
type 1 pattern dictionary 263, 263
viewport dictionary 703, 704
BBox standard structure attribute 839, 841, 845, 853
BC entry
appearance characteristics dictionary 604
soft-mask dictionary 520, 521
BDC operator 166, 340, 341, 778, 779, 790, 913
property list 778, 780
BE dictionaries (multimedia objects) 713-714
BE entry
circle annotation dictionary 576, 594
media clip data dictionary 721
media clip section dictionary 723
media play parameters dictionary 725
media player info dictionary 735
media screen parameters dictionary 728
polygon annotation dictionary 576, 596
rendition dictionary 715, 716
square annotation dictionary 576, 594
bead dictionaries 560-561
in Linearized PDF 949, 953, 955, 973
N entry 561, 973
P entry 561, 973
R entry 561
T entry 561, 953
thread actions, target of 623
Type entry 561
V entry 561
Bead object type 561
beads, article 560, 560
in Linearized PDF 953, 971, 973
in page objects 121, 1011
and thread actions 623
See also
articles
bead dictionaries
threads
Before block alignment 854
before edge 825
of allocation rectangle 860
border color 849
border style 849
border thickness 850
in layout 825, 847, 851, 854, 855
padding width 850, 855
ruby text position 858
Before entry (JavaScript dictionary) 676
Before placement attribute 847
Before ruby text position 858
beginbfchar operator (PostScript) 422, 424, 443, 445
beginbfrange operator (PostScript) 422, 443, 445, 446
begincidchar operator (PostScript) 422, 424
begincidrange operator (PostScript) 422
begincmap operator (PostScript) 422
begincodespacerange operator (PostScript) 422, 424, 443,
444
beginnotdefchar operator (PostScript) 422, 425
beginnotdefrange operator (PostScript) 422, 425
beginrearrangedfont operator (PostScript) 422
beginusematrix operator (PostScript) 422
Bernstein polynomials 299
best effort
See
BE dictionaries (multimedia objects)
bevel line join style 186, 187, 201
“Bézier Curve-Based Root-Finder, A” (Schneider) 1060
Bézier curves, cubic
See cubic Bézier curves
BG entry
3D view dictionary 758
appearance characteristics dictionary 604
graphics state parameter dictionary 191, 259, 453, 702
Index
1078
BG2 entry (graphics state parameter dictionary) 191, 259,
453
BI operator 166, 322, 913
BibEntry standard structure type 835
bibliographies 828, 835
bicubic tensor-product patches 297, 298-300
Bidirectional Algorithm, The (Unicode Standard Annex
#9) 848, 1063
Big Five character encoding 413, 1006, 1025
Big Five character set 413
bilevel output devices 12, 14
halftone screens 457, 464
bilinear interpolation 291, 292
binary data 25
binary files 15, 25
biometric authentication 684
bitshift operator (PostScript) 149, 918
BitsPerComponent entry
FlateDecode filter parameter dictionary 50
image dictionary 310, 314, 315, 320, 321, 523, 557
inline image object 323
LZWDecode filter parameter dictionary 50
type 4 shading dictionary 285, 288
type 5 shading dictionary 290
type 6 shading dictionary 294
BitsPerCoordinate entry
type 4 shading dictionary 285, 288
type 5 shading dictionary 290
type 6 shading dictionary 294
BitsPerFlag entry
type 4 shading dictionary 285, 288
type 6 shading dictionary 294
BitsPerSample entry (type 0 function dictionary) 143, 144
Bl entry (additional-actions dictionary) 612
Bl trigger event (annotation) 612
black color component
black-generation function 183, 452, 453
DeviceCMYK color space 211, 213
DeviceN color spaces 238
gray, complement of 451
grayscale conversion 451
halftones for 476
initialization 213
in multitones 238, 239
overprinting 539, 540
RGB conversion 452, 454
transfer function 454, 455
transparent overprinting 540
black colorant
overprinting 539, 540
PANTONE Hexachrome system 238
printing ink 234
process colorant 211, 213
transparent overprinting 540
black-generation function 183, 452, 453, 454
BG entry (graphics state parameter dictionary) 191
BG2 entry (graphics state parameter dictionary) 191
and transparency 541, 542, 543, 544
black point, diffuse 216, 218, 221
BlackIs1 entry (CCITTFaxDecode filter parameter
dictionary) 55
BlackPoint entry
CalGray color space dictionary 216
CalRGB color space dictionary 218
Lab color space dictionary 221
bleed box 891
clipping to 893
display of 895
in page object 120
printing of finished pages, ignored in 893
in printing of intermediate pages 893
BleedBox entry
box color information dictionary 895
page object 120, 891, 1032
blend circles (type 3 shading) 281-283
blend functions 489, 490
in basic compositing formula 487
blending color space, assumptions about 489
in compositing 493, 494
linear 530
notation 488, 501, 505
and overprinting 535, 536-537
and subtractive color components 540
white-preserving blend modes 536
See also
blend modes
blend modes 484, 490-493
additive color representation 490, 540
for annotations 578, 583
in basic compositing formula 488
blending color space, assumptions about 489
Color 493
ColorBurn 492
ColorDodge 492
Compatible 493, 536, 542
CompatibleOverprint 536-537, 540, 541, 543
in compositing 494
current. See current blend mode
Darken 491, 535, 536, 541
Difference 492, 536
Exclusion 492, 536
HardLight 486, 492
Hue 493
in isolated groups 507
Index
1079
in knockout groups 508
Lighten 491
Luminosity 493
Multiply 491, 507
nonseparable 492-493, 536
non-white-preserving 536
Normal 374, 486, 491, 493, 494, 506, 507, 511, 516, 527,
529, 534, 535, 536, 537, 538, 541, 542, 578, 583
Overlay 491
and overprinting 534-536, 538
Saturation 493
Screen 491, 537
separable 490-492, 535, 536
SoftLight 492
specifying 516
standard 490-493, 516
in subtractive color spaces 489
in transparency groups 485, 499, 505
white-preserving 536
See also
blend functions
blending color space 225, 229, 488-490
for isolated groups 499, 507, 525
for nonseparable blend modes 493
for page group 516
process colors 489
specifying 516, 1018
spot colors 489
for transparency groups 516, 525, 529
Blinds transition style 563, 564
block alignment 854
After 854
Before 854
Justify 854
Middle 854
block-level structure, Tagged PDF 833
strong 833
weak 833
block-level structure elements (BLSEs) 824, 829-834
bounding box 853
content items in 827
direct content items in 825, 834
general layout attributes 846
illustrations as 824
ILSEs contained in 824, 834
ILSEs, nested within 834, 856, 857
list elements 831
L 830, 831, 861
Lbl 828, 830, 831, 835, 852, 861, 862
LBody 830, 831, 852
LI 830, 831, 861
list elements, nested within 831
nesting of 825
packing of ILSEs within 825-826, 846, 847
paragraphlike elements 830, 852
H 830, 830, 833
H1–H6 830, 830, 833
P 828, 830, 830, 833
stacking 825, 834, 846, 847, 848
standard layout attributes for 845, 846, 851-855
BBox 845, 853
BlockAlign 825, 846, 854
EndIndent 845, 852
Height 845, 846, 853
InlineAlign 825, 846, 854
LineHeight 846
SpaceAfter 845, 851
SpaceBefore 845, 851
StartIndent 845, 852
TBorderStyle 846, 855
TextAlign 845, 853
TextIndent 845, 852
TPadding 846, 855
Width 846, 853
table element 831-832
Table 830, 832, 845, 853
usage guidelines 833-834
Block placement attribute 846, 852, 860
block-progression direction 824
illustrations, height of 860
in layout 825, 829, 834, 846, 851, 853, 854, 856
shift direction, opposite to 825, 855
table expansion 863
writing mode 848
block quotations 828
BlockAlign standard structure attribute 825, 846, 854
BlockQuote standard structure type 828
Quote, distinguished from 835
BLSEs. See block-level structure elements
blue color component
CMYK conversion 451, 454
DeviceRGB color space 211, 212
grayscale conversion 451
halftones for 476
in
Indexed color table 232
initialization 213
and threshold arrays 465
transfer function 455
yellow, complement of 452
blue colorant
additive primary 211, 212, 213
display phosphor 234
BM entry (graphics state parameter dictionary) 192, 516
BMC operator 166, 641, 778, 779, 913
body, file
See file body
<body> XHTML element (rich text strings) 642
Index
1080
xfa:APIVersion attribute 643
xfa:contentType attribute 643
xfa:spec attribute 643
xmlns attribute 643
Bold outline item flag 556
bookmarks
access permission 97, 100
PostScript conversion 22
See also
outline items
boolean objects 27, 28
as dictionary values 131
boolean operators 28
border color (Tagged PDF) 849
border effect dictionaries 594
I entry 577
S entry 577
Border entry (annotation dictionary) 572, 575, 576, 1019
Border object type 576
border style dictionaries 571, 575-576, 590, 594, 595, 599,
1020
D entry 576
S entry 576
Type entry 576
W entry 576
border styles 571-572, 575-576, 590, 594, 595, 599, 1020
B (beveled) 576
D (dashed) 576
I (inset) 576
S (solid) 576, 1020
U (underline) 576
border styles (Tagged PDF)
Dashed 849
Dotted 849
Double 849
Groove 849
Hidden 849
Inset 850
None 849
Outset 850
Ridge 849
Solid 849
border thickness (Tagged PDF) 850
BorderColor standard structure attribute 845, 849, 850
BorderStyle standard structure attribute 845, 849, 855
BorderThickness standard structure attribute 845, 850
Both table scope attribute 863
bounding box
artifact 815
BLSE 853
font 390, 392, 393, 427, 914
form XObject 328, 640
glyph 365
illustration 824, 860
imported page 332
movie 741
non-isolated group 526
page 551
pattern cell 263
reference XObject 332
shading object 275, 278, 279, 282
soft mask 520
table 824, 860
table cell 859
transparency group 527
Bounds entry (type 3 function dictionary) 147
box color information dictionaries 120, 893-894, 895
ArtBox entry 895
BleedBox entry 895
CropBox entry 895
TrimBox entry 895
box style dictionaries 894, 895
C entry 895
D entry 895
S entry 895
W entry 895
Box transition style 563, 564
BoxColorInfo entry (page object) 120, 893
BPC entry (inline image object) 323
braces (
{ })26
as delimiters in PostScript calculator functions 149
brackets (
[ ])26
as array delimiters 34
BS entry
annotation dictionary 571, 572, 575, 576, 577, 594,
1019, 1020
circle annotation dictionary 594
ink annotation dictionary 599
line annotation dictionary 590
polygon annotation dictionary 595
polyline annotation dictionary 595
square annotation dictionary 594
BT operator 166, 360, 371, 375, 641, 779, 841, 913
Btn field type 637, 648, 651
BToA transformation (ICC color profile) 225, 489, 900
BU entry (media clip data MH/BE dictionaries) 722, 723
built-in character encodings 395
embedded fonts 397
expert fonts 923
overriding 396
simple fonts 382
Symbol font 923, 932-934
symbolic fonts 396, 397, 923
TrueType fonts 399
Index
1081
Type 1 fonts 384, 399, 924
ZapfDingbats font 923, 935-936
bullet character 928, 1017
butt line cap style 186, 186, 201
Butt line ending style 593
button field flags 647-648
NoToggleToOff 648, 651
Pushbutton 648, 648, 651
Radio 648, 648, 651
RadiosInUnison 648, 650, 651, 1024
button fields 637, 647, 647-653
alternate (down) caption 604
alternate (down) icon 605
appearances 669
flags. See button field flags
icon 678-679
icon fit dictionary 605
normal caption 604
normal icon 604
rollover caption 604
rollover icon 605
scaling 679
trigger events inapplicable to 614
See also
check box fields
pushbutton fields
radio button fields
BX operator 127, 166, 339, 913
byte order marker (Unicode) 132
byte range digests 684
ByteRange entry (signature dictionary) 684, 685, 686, 687,
688, 691, 693, 699, 700
C
C entry
3D background dictionary 764
additional-actions dictionary
form field 613, 635
page 611, 612, 612, 1021
annotation dictionary 572, 599
box style dictionary 895
hint stream dictionary 952
media criteria dictionary 716
media play parameters
MH/BE dictionaries 726
media rendition dictionary 718, 719
number format dictionary 707
outline item dictionary 555
rendition
MH/BE dictionary 715, 716
sound object 739, 740
source information dictionary 884
structure element dictionary 788, 802, 803, 804, 842,
844
URL alias dictionary 885
Web Capture command settings dictionary 888
Web Capture information dictionary 874
c operator 166, 196, 198, 913
C programming language 1060, 1062
C++ programming language 802
C tab order (annotations) 122, 569
C trigger event
form field 613, 614
page 612
C0 entry (type 2 function dictionary) 146
C1 entry (type 2 function dictionary) 146
C2W entry (3D view dictionary) 758
CA entry
appearance characteristics dictionary 604
graphics state parameter dictionary 192, 519
markup annotation dictionary 583
ca entry (graphics state parameter dictionary) 192, 519
CalCMYK color spaces 214
calculator functions, PostScript
See type 4 functions
CalGray color space dictionaries 216
BlackPoint entry 216
Gamma entry 216, 217
WhitePoint entry 216, 217
CalGray color spaces 207, 214, 215-217, 315
as blending color space 489
color values 216
gamma correction 216
and
ICCBased color spaces, compared 222, 225
initial color value 257
rendering 448
setting color values in 257
See also
CalGray color space dictionaries
calibrated color 214
CalGray color spaces 216, 217
CalRGB color spaces 217
CMYK, as blending color space 489
device profiles 449
implicit conversion 228-230
multitones 251, 254
callouts (free text annotations) 589
CalRGB color space dictionaries 218, 219
BlackPoint entry 218
Gamma entry 218, 218, 219, 515
Matrix entry 218, 219, 515
WhitePoint entry 218, 219
CalRGB color spaces 207, 214, 217-220, 315
as base color space 232
as blending color space 489
color values 217
Index
1082
gamma correction 218
and
ICCBased color spaces, compared 222, 225
initial color value 257
process colors, conversion to 532
rendering 448
setting color values in 257
for soft masks 515
sRGB color space, approximating 226
transfer functions 454
and transparent overprinting 537, 541
See also
CalRGB color space dictionaries
camera, virtual (3D annotations) 746, 749, 757, 758, 759,
760, 766
Cancelled annotation state 585
CanonicalFormat field flag (submit-form field) 665
Cap entry (line annotation dictionary) 591
CapHeight entry (font descriptor) 427
Caption standard structure type 828, 831, 832
captions 828, 831, 832
caret annotation dictionaries
RD entry 597
Subtype entry 597
Sy entry 597
Caret annotation type 581, 597
caret annotations 581, 597
carriage return (CR) character 26
in cross-reference tables 70
as end-of-line marker 26, 31, 37, 67, 70
escape sequence for 30
in HTTP requests 888
in stream objects 36, 37
as white space 24, 32
Cascading Style Sheets, level 2 (CSS2) Specification (World
Wide Web Consortium) 1063
catalog
document. See document catalog
FDF (Forms Data Format). See FDF catalog
Catalog object type 114, 976, 978
Category entry (usage application dictionary) 352
CCF filter abbreviation 324, 1007
CCITT (Comité Consultatif International Téléphonique et
Télé g rap hi qu e)
compression 62
encoding standard 53, 56
facsimile compression 15, 43, 53-56, 1061
CCITTFaxDecode filter 43, 53-56
CCF abbreviation 324, 1007
end-of-facsimile-block (EOFB) pattern 55
parameters. See
CCITTFaxDecode filter parameter dic-
tionaries
return-to-control (RTC) pattern 55
in sampled images 310
CCITTFaxDecode filter parameter dictionaries 54-55
BlackIs1 entry 55
Columns entry 55
DamagedRowsBeforeError entry 54, 55
EncodedByteAlign entry 54, 55
EndOfBlock entry 55
EndOfLine entry 55
K entry 54, 55
Rows entry 55
ceiling operator (PostScript) 149, 917
cells, halftone 457
coordinate system 458
frequency 458, 468
predefined spot functions 459
and spot function 458, 467
and threshold array 464
type 10 halftones 466, 470, 472
type 16 halftones 466
Center inline alignment 854
center of orbit (3D views) 758, 759
Center ruby text alignment 857
Center text alignment 853
CenterWindow entry (viewer preferences dictionary) 548
Cert entry
signature dictionary 686, 697
signature field seed value dictionary 660
certificate revocation lists (CRLs) 698
certificate seed value dictionaries 660, 661
Ff entry 661
Issuer entry 661
OID entry 661
Subject entry 661
Type entry 661
URL entry 661
certifying signature. See MDP signatures 685
CF entry (encryption dictionary) 66, 93, 93, 105, 107
CFF (Compact Font Format) 6, 408, 436, 437, 438, 439
“CFF” table (OpenType font) 437, 439, 440
CFM entry (crypt filter dictionary) 97, 107, 108, 109
CGI (Common Gateway Interface) file format 878
Ch field type 637
Changes entry (signature dictionary) 687
character codes
7-bit ASCII 15
character encodings, mapped by 389, 395
in CIDFonts 406
and CMaps 404, 411, 412, 418, 422, 424
codespace ranges 422, 424, 425, 443
Differences array 397, 398
in font dictionaries 384, 390, 391
Index
1083
hexadecimal, in name objects 33, 158
mapping operators 421-422
mapping to Unicode values 441-442
multiple-byte 155, 370, 378, 379, 389, 403, 404
notdef mappings 422, 424, 425
octal, in literal strings 30, 31
and predefined CMaps 418
Shift-JIS encoding 420
showing text 358
single-byte 370, 379, 382
and standard encodings 923
in text objects 357
and text-showing operators 378
and
Tj operator 360
in TrueType fonts 399, 400, 401, 439
in Type 0 fonts 423
in Type 1 fonts 398, 399
in Type 3 fonts 391, 399
undefined characters 425
undefined widths 428
Unicode, mapping to 384, 391, 423, 442-446, 820
and word spacing 369
character collections 404
Adobe-CNS1 414, 416-417, 433, 442, 1017
Adobe-GB1 413, 416, 433, 442, 1017
Adobe-Identity 417
Adobe-Japan1 414, 415, 417, 433, 434, 442, 1017
Adobe-Japan2 433, 434
Adobe-Korea1 415, 417, 433, 434, 442, 1017
Chinese (simplified) 416
Chinese (traditional) 416-417
for CIDFonts 407, 408, 432, 433
CIDSystemInfo dictionaries 405, 419
CJK (Chinese, Japanese, and Korean) 416-417
for CMaps 404-405, 412
Generic 417
and
IdentityH predefined CMap 416
and
IdentityV predefined CMap 416
Japanese 417
Korean 417
ordering 406, 418, 442
for predefined CMaps 416-418, 442
registry 442
registry identifier 406, 418
supplement number 406, 418, 442
character encodings 381, 382, 395-403, 1062
base 397, 430, 924
Big Five 413, 1006, 1025
built-in. See built-in character encodings
CJK (Chinese, Japanese, and Korean) 389
and CMaps, compared 404, 411
for composite fonts. See CMaps
content extraction 16
EUC-CN 412, 413
EUC-JP 414
EUC-KR 415
EUC-TW 413
for FDF fields 674
GBK 413, 1025
glyph selection 378
Hong Kong SCS 413
ISO-2022-JP 414
ISO Latin 1 131
Microsoft Unicode 401
for name objects 1006
named 441
natural language 431
predefined. See predefined character encodings
Shift-JIS 404, 414, 420, 1006, 1025
for simple fonts 395-403
and
ToUnicode CMaps 443
for TrueType fonts 399-403, 439, 924
for Type 1 fonts 384, 398-399, 924
for Type 3 fonts 389, 399
UCS-2 412, 413, 414, 415
UHC (Unified Hangul Code) 415, 1025
Unicode, mapping to 820
Unicode. See Unicode character encoding
UTF-8 34, 1006
UTF-16BE 132
character identifiers (CIDs) 404
and character collections 404, 405, 418
CID 0 409, 425
and CIDFonts 405, 406, 408, 409, 410, 411, 432, 442
and CMaps 404, 411, 412, 422, 424
and
IdentityH predefined CMap 415, 416
and
IdentityV predefined CMap 415, 416
mapping to glyph indices 408, 409
maximum value 404, 920
notdef mappings 422, 424, 425
and Type 0 fonts 423
undefined characters 425
Unicode conversion 441, 442
character names
CharProcs dictionary 390, 391
CID-keyed fonts, unused in 404
and CMaps 404, 411, 422
Differences array 397
in font subsets 428, 1016
glyph descriptions, Type 1 398, 399
glyph descriptions, Type 3 389, 399
.notdef 398, 409, 425, 428
and standard encodings 923
in Type 3 fonts 391
Unicode conversion 441
character selectors 404
in CIDFonts 406
and CMaps 411, 418, 424
Index
1084
undefined characters 425
character sequences
double left angle bracket (
<<) 35, 73, 672
double period (
..) 153, 878
double right angle bracket (
>>) 35, 73, 672
tilde, right angle bracket (
~>) 45, 46
character sets 15, 358, 1062
ASCII 25, 26, 31
Big Five 413
and character collections 404
CJK (Chinese, Japanese, and Korean) 403, 404
CNS 11643-1992 413
encodings for 395-396
ETen 413
for font subsets 428
Fujitsu FMR 414
GB 2312-80 412, 413
GB 18030-2000 413
GBK 413
Hong Kong SCS 413
JIS C 6226 414
JIS X 0208 414
JIS78 414
KanjiTalk6 414
KanjiTalk7 414
KS X 1001:1992 415
Latin. See Latin character set, standard
Mac OS KH 415
non-Latin 396, 653
PDF 25-26
Unicode, conversion to 441
character spacing (T
c
) parameter 364, 367, 368-369
and horizontal scaling 370
and quotation mark (
") operator 377
Tc operator 368, 915, 916
text matrix, updating of 380
characters 358
accented 395, 427
apostrophe (
') 133, 166, 368, 371, 377, 916
backslash (
\)29, 30-31, 152, 153, 155, 379, 622, 880-
881
backspace (BS) 30
bullet 928, 1017
and bytes 25
carriage return (CR) 24, 26, 30, 31, 32, 36, 37, 67, 70,
888
codes. See character codes
colon (
:) 153, 154, 889
currency 928
Cyrillic 433, 434
delimiter 25, 26, 27, 32, 33
dollar sign (
$) 413
ellipsis (
…) 1000
em dash 823
encodings. See character encodings
escape 30
euro 928
exclamation point (
!)45, 46
form feed (FF) 26, 30, 32
glyphs. See glyphs, character
Greek 433, 434
hangul 434
hanzi (kanji, hanja) 432, 433, 434
horizontal tab (HT) 24, 26, 27, 30, 32
hyphen (-) 816, 823, 928
illuminated 864, 871
jamo 434
kana (katakana, hiragana) 433, 434
Latin 432, 433, 434
left angle bracket (
<) 26, 29, 32, 35, 73, 155, 672
left brace (
{)26, 149
left bracket (
[)26, 34, 1034
left parenthesis (
()26, 29, 30, 379
ligatures 395, 445, 864, 871, 923
line feed (LF) 24, 26, 30, 31, 32, 36, 37, 67, 70, 888
line-drawing 433, 434
minus sign () 133
names. See character names
newline 26, 30
nonbreaking space 928
nonprinting 30, 31
null (NUL) 26, 880
number sign (
#) 33, 34, 389, 878, 1005-1006
numeric 434
percent sign (
%)26, 27, 878
period (
.) 153, 154, 639, 684, 878, 880, 1023
plus sign (
+) 133, 389
quotation mark (
") 166, 368, 371, 377, 916
regular 25, 26, 27, 32
right angle bracket (
>) 26, 29, 32, 35, 45, 73, 155, 672
right brace (
})26, 149
right bracket (
])26, 34
right parenthesis (
))26, 29, 30, 379
ruby 434
selectors. See character selectors
sets. See character sets
slash (
/)26, 32, 34, 114, 126, 152, 154, 155, 428, 673,
887
space (SP) 24, 26, 27, 32, 70, 369, 372, 386, 388, 664,
819, 823, 976, 1005
special symbols 433, 434
tab. See horizontal tab (HT)
underscore (
_) 154, 386
white-space 24, 25-26, 32, 33, 45, 322, 1034
yuan symbol (
¥) 413
CharProcs entry (Type 3 font dictionary) 340, 390, 391,
392, 393, 399
CharSet entry (font descriptor) 428, 440
Index
1085
check box field dictionaries
Opt entry 650
check box fields 647, 648, 648-650
normal caption 604
Off appearance state 648
value 648
Yes appearance state 648
See also
check box field dictionaries
CheckSum entry (embedded file parameter dictionary)
158
Chinese
character collections (simplified) 416
character collections (traditional) 416-417
character sets 403, 404
CMaps (simplified) 412-413
CMaps (traditional) 413-414
fonts 389
glyph widths 410
hanzi (kanji, hanja) characters 432, 433, 434
R2L reading order 549
writing systems 848
choice field dictionaries 657
I entry 657
Opt entry 657, 657, 1024
TI entry 657
choice field flags 656
Combo 656
CommitOnSelChange 656
DoNotSpellCheck 656
Edit 656
MultiSelect 656, 657
Sort 656
choice fields 637, 647, 656-658, 1024
flags. See choice field flags
multiple selection 656, 657
value 656, 657
See also
choice field dictionaries
combo box fields
list box fields
chroma-key 321, 64
chromaticity 219, 489, 525
chrominance 61
CICI.SignIt signature handler 686
CID-Keyed Font Technology Overview (Adobe Technical
Note #5092) 404, 1058
CID-keyed fonts 6, 403-405, 923
character collections 404
DescendantFonts array 405
embedded 16
Encoding entry 405
glyph descriptions 404, 405
as Type 0 fonts 405
See also
CIDFonts
CMaps
CIDFont dictionaries 381, 406-408
BaseFont entry 407, 423, 426
in CID-keyed fonts 405
CIDSystemInfo entry 405, 407, 408, 420
CIDToGIDMap entry 408, 416
DW entry 407, 410
DW2 entry 407, 410-411, 439
FontDescriptor entry 407
Subtype entry 407
and TrueType fonts 439
Type entry 407
W entry 407, 410
W2 entry 407, 411, 439
CIDFont
FD dictionaries 432-435
CIDFont files 405
CIDFont font descriptors 407, 431-435
CIDSet entry 432, 440
FD entry 432
Lang entry 431
Style entry 431
See also
CIDFont
FD dictionaries
CIDFont
Style dictionaries
CIDFont
Style dictionaries 432
Panose entry 432
CIDFont subtypes
See CIDFont types
CIDFont types 407
CIDFontType0 381, 407, 437
CIDFontType2 381, 407, 436, 437
CIDFontName entry (CIDFont program) 407
CIDFonts 381, 382, 403, 406-411
base font 407
character collection 407, 408, 432, 433
CIDFont files 405
and CMaps 406, 411, 412, 419, 422, 424
embedded 405, 408
font descriptors. See CIDFont font descriptors
and fonts, compared 406
glyph classes 432-435
glyph descriptions 406, 408
glyph indices, mapping from CIDs to 408, 409
glyph metrics 407, 409-411, 433, 1015
glyph selection 408-409
glyph widths 407
and
IdentityH predefined CMap 415, 416
and
IdentityV predefined CMap 415, 416
PostScript name 407
subsets 432
Index
1086
Tf operator inapplicable to 406
Type 0 406, 407, 408, 423
Type 0 fonts, descendants of 406, 423, 425, 442
Type 2 406, 407, 408-409, 416, 423
Unicode mapping 442
vertical writing 407, 410-411, 433, 434
writing mode 412
See also
CIDFont dictionaries
CIDFont
FD dictionaries
CIDFont
Style dictionaries
CIDFont types
CIDFontType0 CIDFont type 381, 407, 437
CIDFontType0C embedded font subtype 408, 437, 438
CIDFontType2 CIDFont type 381, 407, 436, 437
CIDs. See character identifiers
CIDSet entry (CIDFont font descriptor) 432, 440
CIDSystemInfo dictionaries 405, 408, 419, 432, 433, 442,
1017
Ordering entry 406, 415, 433
Registry entry 406, 415, 433
Supplement entry 406, 415, 433
CIDSystemInfo entry
CIDFont dictionary 405, 407, 408, 420
CMap dictionary 405, 419, 1017
CIDToGIDMap entry (CIDFont dictionary) 408, 416
CIE (Commission Internationale de l’Éclairage) 207
CIE 1931 XYZ color space
and
CalGray color spaces 215, 216, 217
and
CalRGB color spaces 218
CIE-based color spaces, semantics of 214
implicit conversion, bypassed in 229
and
Lab color spaces 221
soft masks, derivation of 515
CIE 1976 L*a*b* color space 61, 220, 222
CIE-based A color spaces 215-216
color values 215
decoding functions 216, 217
CIE-based ABC color spaces 214-215, 217, 220, 232
color values 214
decoding functions 214, 217, 219, 221
CIE-based color spaces 207, 214-231
as alternate color space 237, 240
as base color space 232
blending in 490, 530
CalCMYK 214
CIE 1931 XYZ. See CIE 1931 XYZ color space
CIE 1976 L*a*b* 61, 220, 222
CIE-based A 215-216
CIE-based ABC 214-215, 217, 220, 232
color conversion, control of 450
color mapping mapping function 449
and color specification 205
decoding functions 214, 216, 217, 219, 221
default 211, 227-228, 531, 900
device spaces, conversion to 277, 447, 448-449
diffuse achromatic highlight 218
diffuse achromatic shadow 218
diffuse white point 216, 217, 218, 221
and flattening of transparent content 545
gamut mapping function 218, 449, 454
as group color space 530, 531
implicit conversion to device colors 228-230
initial color value 215
inline images, prohibited in 324
and overprinting 254
for page group 511
parameters 215
process colors, rendered as 450
rendering intents. See rendering intents
setting color values in 257
for shadings 275, 277
for soft masks 515
specification 215
specular highlight 218
sRGB (standard RGB) 226, 530
for transparency groups 211, 525
See also
CalGray color spaces
CalRGB color spaces
ICCBased color spaces
Lab color spaces
CIE colorimetric system 214, 1060
CIP4 (International Cooperation for the Integration of
Processes in Prepress, Press and Postpress)
JDF Specification 448, 903, 1061
circle annotation dictionaries 594-595
BE entry 576, 594
BS entry 594
IC entry 594
RD entry 595
Subtype entry 594
Circle annotation type 580, 594
circle annotations 580, 593-595
border style 571, 575
border width 594
dash pattern 594
interior color 594
See also
circle annotation dictionaries
Circle line ending style 593
Circle list numbering style 862
CJK (Chinese, Japanese, and Korean)
character collections 416-417
character sets 403, 404
Index
1087
CMaps 412-415
fonts 389
glyph widths 410
See also
Chinese
Japanese
Korean
CJKV Information Processing (Lunde) 418, 1062
CL entry (free text annotation dictionary) 589
class map 786, 802, 842
ClassMap entry (structure tree root) 786, 802, 842
clear-table marker (LZW compression) 48, 49
cleartomark operator (PostScript) 437, 438
Client-Side JavaScript Reference (Netscape Communica-
tions Corporation) 668, 1063
Clip marked-content tag 841
clip operator (PostScript) 916
clipping 11, 12, 204-205, 371-372
3D artwork 760-762
to art box 893
to bleed box 120, 891, 893
to crop box 120, 891, 893
even-odd rule 205, 916
to form bounding box 327, 328
to function domain 141, 143, 315
to function range 141, 144
to function sample table 143
to glyph outlines 362, 371
in illustration elements (Tagged PDF) 841
and marked content 780-784
nonzero winding number rule 205, 372, 916
to page boundaries 120, 549, 891, 893
paths 163, 164, 204-205, 371, 372
pattern cells 263
to reference XObject bounding box 332
scan conversion 481
shadings 275
soft 192, 486, 495, 513, 518
text rendering mode 371-372
to transparency group bounding box 527
See also
clipping path operators
current clipping path
clipping objects 780-782
clipping path, current
See current clipping path
clipping path operators 166, 195, 204-205
W 166, 202, 204, 205, 780, 782, 916
W* 166, 202, 204, 205, 780, 782, 916
ClosedArrow line ending style 593
closepath operator (PostScript) 913, 914, 915
ClrF entry (FDF field dictionary) 678
ClrFf entry (FDF field dictionary) 677
cm operator 166, 172, 180, 189, 308, 913
CMap dictionaries 418, 419
in CID-keyed fonts 405
CIDSystemInfo entry 405, 419, 1017
CMapName entry 419, 423
for
ToUnicode CMaps 443
Type entry 419
UseCMap entry 419, 422, 443
WMode entry 410, 419
CMap files 404-405, 412
CIDSystemInfo dictionary 419
example 419-420, 420-421
name 419
ToUnicode CMaps 384, 391, 423, 443
writing mode 419
CMap object type 419
“cmap” table (OpenType font) 439
“cmap” table (TrueType font) 399-402, 409, 439
platform-specific subtables 399-403
CMapName entry (CMap dictionary) 419, 423
CMaps 378, 381, 382, 403, 411-422, 1016, 1062
base CMap 419
and character collections 404-405, 412
and character encodings, compared 404, 411
Chinese (simplified) 412-413
Chinese (traditional) 413-414
and CIDFonts 406, 411, 412, 419, 422, 424
CJK (Chinese, Japanese, and Korean) 412-415
embedded 405, 418, 418, 1016
example 419-420, 420-421
files. See CMap files
font numbers 404, 412, 418, 422, 423, 424
IdentityH 416, 442
IdentityV 416, 442
Japanese 414-415
Korean 415
mapping operators 421-422
notdef mappings 422, 424, 425
PostScript name 419, 423
predefined. See predefined CMaps
for Type 0 fonts 423, 1017
undefined characters 425
Unicode mapping 442, 820
writing mode 412, 419
See also
CMap dictionaries
CMS. See color management system
CMYK color representation
calibrated, as blending color space 489
DCTDecode filter, transformation by 61
DeviceCMYK color space 207, 213
and grayscale, conversion between 451, 456
Index
1088
in halftones 457
and high-fidelity color, compared 238
in output devices 205, 450
and output intents 900
RGB, conversion from 183, 451-453, 544
RGB, conversion to 454
for subtractive color 211
in transfer functions 454
CMYK color space abbreviation (inline image object) 323
CNS 11643-1992 character set 413
CNSEUCH predefined CMap 413, 416
CNSEUCV predefined CMap 414, 416
CO entry
3D view dictionary 758
interactive form dictionary 613, 635
sound object 740
code, computer program 835
Code standard structure type 835
Codes for the Representation of Names of Countries and
Their Subdivisions (ISO 3166) 132, 865, 1061
Codes for the Representation of Names of Languages (ISO
639) 132, 865, 1061
codespace ranges 422, 424, 425
for
ToUnicode CMaps 443
collaborative editing 665
collection 77
colon (
:) character
in conversion engine names 889
as DOS file name delimiter 153
as Mac OS file name delimiter 154
color
annotations 572
backdrop. See backdrop color
background, dynamic appearance stream 604
border, dynamic appearance stream 604
calibrated. See calibrated color
conversion between spaces. See color conversion
current. See current color
duotone 238, 249-252
glyph descriptions 392, 393
gradient fills 183
group. See group color
group backdrop 503
high-fidelity 205, 207, 238
ICC profiles 214, 222-225
interior
annotations 591, 594
line endings 593
inversion 316, 455
mapping 205, 207, 232
masking. See color key masking
multitone 205, 207, 238-239, 249-254, 1012-1013
object (transparent imaging model) 504
outline items 555
overprint control 254-256
page boundaries 895
process. See process colors
quadtone 238, 252-254
remapping 211, 227-228, 450, 525, 531, 900
rendering 206, 447-448
result (transparent imaging model). See result color
separations. See separations, color
smoothness tolerance 479-480
source (transparent imaging model). See source color
specification 205
tints. See tints
YUV 61
YUVK 61
See also
color components
color operators
color representation
color spaces
color values
colorants
Color Appearance Models (Fairchild) 1059
color bars 890, 891, 894, 897
as page artifacts 815
as printer’s mark annotations 605
Color blend mode 493
color components 206
additive 212, 228, 235, 240, 455, 457
alternate color space 237, 240
DeviceCMYK 235, 240
DeviceGray 235, 240
DeviceN (tints) 238, 239, 240, 241, 920
DeviceRGB 235, 240
halftones for 456, 457-458, 466, 475, 476
in JPEG2000 images 62
linear 530
nonprimary 455, 468, 469, 472, 474, 475, 476
and nonseparable blend modes 493
nonstandard 468, 469, 472, 474, 476
and output intents 900
and overprinting 539-540
primary 212, 476
range 489
and separable blend modes 490
Separation (tints) 235
smoothness tolerance 479
in soft-mask images 522, 524
spot 238, 455, 520, 532, 533
subtractive 213, 228, 234, 235, 240, 455, 457
transfer functions 447, 455
and transparent overprinting 534, 535, 536, 537, 540,
541
Index
1089
See also
black color component
blue color component
cyan color component
gray color component
green color component
magenta color component
red color component
yellow color component
color conversion 448-454
to alternate color space 277, 533
to base color space 277
CIE-based to device 277, 532
CMYK to RGB 454
device color spaces, among 277, 447, 450-454
device to CIE-based not generally possible 530, 531
grayscale and CMYK, between 451, 456
grayscale and RGB, between 451
to group color space 525, 527, 529, 530, 532
to page color space 530
in rendering 206, 542
RGB to CMYK 183, 451-453, 544
in shading patterns 277, 533
soft-mask images, preblending of 524
See also
black-generation function
undercolor-removal function
color CSS2 style attribute (rich text strings) 644
Color entry (version 1.3 OPI dictionary) 910
color functions 276
type 1 (function-based) shadings 278
type 2 (axial) shadings 279, 280
type 3 (radial) shadings 281, 282
type 4 shadings (free-form Gouraud-shaded triangle
meshes) 285, 288
type 5 shadings (lattice-form Gouraud-shaded triangle
meshes) 290
type 6 shadings (Coons patch meshes) 294, 296
color key masking 311, 319, 321, 1013
and object shape 517
and soft masks 518
color management system (CMS) 449
color mapping (
Indexed color spaces) 205, 207, 232
color mapping functions, CIE-based 449
color operators 166, 188, 256-259
CS 166, 206, 210, 212, 213, 240, 257, 259, 261, 914
cs 166, 206, 210, 212, 213, 257, 259, 261, 914
G 166, 206, 210, 211, 212, 258, 259, 914
g 166, 206, 210, 211, 212, 258, 259, 306, 361, 914
in glyph descriptions 393
K 166, 206, 210, 211, 213, 258, 914
k 166, 206, 210, 211, 213, 258, 915
restrictions on 258-259
RG 166, 206, 210, 211, 213, 258, 259, 915
rg 166, 206, 210, 211, 213, 258, 259, 531, 537, 915
SC 166, 206, 210, 212, 213, 234, 257, 259, 915
sc 166, 206, 210, 212, 213, 234, 258, 259, 288, 306, 915
SCN 166, 210, 234, 235, 240, 258, 259, 261, 264, 265,
268, 915
scn 166, 210, 234, 235, 240, 258, 259, 261, 264, 265,
268, 269, 915
text, showing 361
in text objects 375
color patches
bicubic tensor-product 297, 298-300
Coons 291-293, 297, 298, 300
color plates
Plate 1, Additive and subtractive color 211
Plate 2, Uncalibrated color 214
Plate 3,
Lab color space 220
Plate 4, Color gamuts 220
Plate 5, Rendering intents 230
Plate 6, Duotone image 238
Plate 7, Quadtone image 238, 252
Plate 8, Colored tiling pattern 265
Plate 9, Uncolored tiling pattern 269
Plate 10, Axial shading 280
Plate 11, Radial shadings depicting a cone 282, 283
Plate 12, Radial shadings depicting a sphere 283
Plate 13, Radial shadings with extension 283
Plate 14, Radial shading effect 283
Plate 15, Coons patch mesh 291
Plate 16, Transparency groups 485
Plate 17, Isolated and knockout groups 507, 508
Plate 18, RGB blend modes 490
Plate 19, CMYK blend modes 490
Plate 20, Blending and overprinting 537
color profiles, ICC
See ICC color profiles
color representation
ICC profiles 214, 222-225
YUV 61
YUVK 61
See also
additive color representation
CMYK color representation
grayscale color representation
RGB color representation
subtractive color representation
Color Separation Conventions for PostScript Language Pro-
grams (Adobe Technical Note #5044) 1012, 1058
color separations
See separations, color
color space arrays 210
for CIE-based color spaces 215
as
ColorSpace resources 210, 257
Index
1090
content streams, prohibited in 210
for
DeviceN color spaces 239
for
ICCBased color spaces 222
for
Indexed color spaces 232
for
Pattern color spaces 268
in PDF objects 210
for
Separation color spaces 235, 242
color spaces 205-259
abbreviations for, in inline images 323
additive. See additive color representation
alternate. See alternate color space
for appearance streams 635
arrays. See color space arrays
blending. See blending color space
CalCMYK 214
CIE 1931 XYZ. See CIE 1931 XYZ color space
CIE 1976 L*a*b* 61, 220, 222
CIE-based A 215-216
CIE-based ABC 214-215, 217, 220, 232
conversion between. See color conversion
current. See current color space
Decode arrays, default 315-316
DeviceRGB 729
diffuse achromatic highlight 218
diffuse achromatic shadow 218
diffuse black point 216, 218, 221
diffuse white point 216, 217, 218, 221
families 207-210, 1012
gamma correction 216, 218
gamut 220, 238, 449, 543, 544
group. See group color space
for image XObjects 210, 227, 557
implicit conversion 228-230
for inline images 227, 324
in JPEG2000 images 64
JPEG2000 formats and 310
in Linearized PDF 965
as named resources 129
native (output device). See native color space
and overprinting 539-540
for page group 511, 527, 530, 541
rendering intents. See rendering intents
for sampled images 304, 305, 306, 307, 310, 311, 314,
315, 321
for separable blend modes 490
for shadings 227, 275, 276-277, 278, 279, 281, 285, 288,
290, 294
for soft masks 515, 521, 522, 523, 524
specification 210
specular highlight 218
sRGB (standard RGB) 226, 530
subtractive. See subtractive color representation
for thumbnail images 557
for transparency groups. See group color space
and transparent overprinting 534, 540
See also
CalGray color spaces
CalRGB color spaces
CIE-based color spaces
default color spaces
device color spaces
DeviceCMYK color space
DeviceGray color space
DeviceN color spaces
DeviceRGB color space
ICCBased color spaces
Indexed color spaces
Lab color spaces
Pattern color spaces
Separation color spaces
special color spaces
Color standard structure attribute 845, 850
color table (
Indexed color space) 232, 233, 524
color values 180, 206
background (shadings) 275, 279, 280, 283
CalGray 216
CalRGB 217
CIE-based A 215
CIE-based ABC 214
CIE-based color mapping 449
components 206, 447
DeviceCMYK 213
DeviceGray 212
DeviceN 240
DeviceRGB 212
Indexed 232
interpolation (shadings) 276-277
Lab 220
Pattern 261
remapping 228
Separation 235
transfer functions, produced by 458
in transparent imaging model 487
for uncolored tiling patterns 268
colorants
additive 234
device 211, 254, 255, 534, 541, 897
DeviceN 240, 242, 920
halftones for 456, 466, 475, 476
misregistration 605, 890, 902
for OPI proxies 912
primary 234, 237, 457, 466
for printer’s marks 897
process. See process colorants
and separations 235, 236, 237, 240, 897
spot. See spot colorants
subtractive 234, 236
and transparent overprinting 534
Index
1091
for trap networks 906
See also
black colorant
blue colorant
cyan colorant
green colorant
magenta colorant
orange colorant
red colorant
yellow colorant
colorants dictionary (
DeviceN color spaces) 242
Colorants entry
DeviceN color space attributes dictionary 242, 245, 246
printer’s mark form dictionary 897
ColorBurn blend mode 492
ColorDodge blend mode 492
colored tiling patterns 262, 264-268
in transparent imaging model 529
Colors entry
FlateDecode filter parameter dictionary 50
LZWDecode filter parameter dictionary 50
ColorSpace entry
DeviceN process dictionary 244
image dictionary 65, 210, 310, 311, 314, 320, 523, 524,
537, 557
inline image object 323, 324
resource dictionary 129, 210, 227, 257, 324, 525
separation dictionary 898
shading dictionary 273, 275, 276, 277
ColorSpace resource type 129, 210, 227, 257, 324, 525
ColorTransform entry (DCTDecode filter parameter
dictionary) 61
ColorType entry (version 1.3 OPI dictionary) 910
Colour Measurement and Management in Multimedia Sys-
tems and Equipment (International Electrotechnical
Commission) 226, 1061
ColSpan standard structure attribute 863
column attributes, standard
See standard column attributes
Column table scope attribute 863
ColumnCount standard structure attribute 846, 861
ColumnGap standard structure attribute 846, 861
Columns entry
CCITTFaxDecode filter parameter dictionary 55
FlateDecode filter parameter dictionary 50
LZWDecode filter parameter dictionary 50
ColumnWidths standard structure attribute 846, 861
Comb field flag (text field) 653
combo box fields 647, 656
trigger events for 612
Combo field flag (choice field) 656
command dictionaries, Web Capture
See Web Capture command dictionaries
command settings dictionaries, Web Capture
See Web Capture command settings dictionaries
Comment annotation icon 586
comments 25, 26, 27, 1005
OPI. See OPI comments
Comments entry (version 1.3 OPI dictionary) 908
Commission Internationale de l’Éclairage (International
Commission on Illumination) 207
CommitOnSelChange field flag (choice field) 656
Compact Font Format (CFF) 6, 408, 436, 437, 438, 439
Compact Font Format Specification, The (Adobe Technical
Note #5176) 383, 1059
compact font programs
embedded 436, 438-439
subtypes 436
compatibility
blend modes for 493, 536
of file names 154
object streams and cross-reference streams 85-91
with other applications 67
of PDF versions. See version compatibility, PDF
sections 127, 913, 914
transparency 544-545
compatibility operators 127, 166
BX 127, 166, 339, 913
EX 127, 166, 339, 914
compatibility sections 127, 913, 914
Compatible blend mode 493, 536
and fully opaque objects 542
CompatibleOverprint blend mode 536-537, 540
and halftones 543
overprint mode ignored by 541
overprint parameter ignored by 541
and transfer functions 543
and transparency groups 541
Completed annotation state 585
Components entry
DeviceN process dictionary 244, 248
Composite (group compositing) function 503
backdrop, compositing with 503
backdrop removal 506
in group compositing computations 504
for page group 511
recursive application 504
soft masks, derivation of 514
summary 512
composite fonts 381, 403-425
encoding. See CMaps
glyph selection 378
PostScript and PDF, compared 403
Index
1092
Tj operator 360
Unicode mapping 442
word spacing 369
writing mode 365
See also
CID-keyed fonts
Type 0 fonts
composite pages 234
separations, generation of 897
spot colorants in 532
compositing 11, 165, 483, 484, 485
of annotation appearances 578
blending color space 488-490, 516, 1018
computations. See compositing computations
in isolated groups 507, 508, 526
of isolated groups 507
in knockout groups 509, 526
in non-isolated groups 526
in non-knockout groups 508
and overprinting 535
in page group 486, 511
of page group 510, 511, 512
pattern cells 528
shading patterns 528
of spot color components 532-533
text knockout parameter 373-374
tiling patterns 528
in transparency groups 485, 486, 499, 502, 514, 525,
527, 529
of transparency groups 485, 486, 499, 502, 503, 520,
525, 526, 527, 529, 538
See also
alpha
blend modes
opacity
shape
compositing computations
basic 486-498
formula 487-488
notation 487
summary 498
group 500-501, 503-507
general groups 500-501
isolated groups 508
knockout groups 509
non-isolated groups 510
non-isolated, non-knockout groups 504
notation 500
page group 511
summary 512-513
linear 530
for patterns 528
and preblending of soft-mask image data 524
simplification of 513
“Compositing Digital Images” (Porter and Duff) 488,
1063
compressed objects 76
compression, data 15, 41, 42
CCITT facsimile 15, 43, 53-56, 62, 1061
DCT (discrete cosine transform) 43, 60-62
filters 15, 22, 47-62, 740
Flate (zlib/deflate) 15, 43, 47-53
JBIG2 (Joint Bi-Level Image Experts Group) 15, 43,
56
-60
JPEG (Joint Photographic Experts Group) 15, 43, 60,
62
JPEG2000 43, 62, 63
lossless 42, 56, 226
lossy 42, 56, 60
LZW (Lempel-Ziv-Welch) 15, 41, 42, 43, 47-53
run-length encoding 43, 53
sounds 740
computation order 613, 635
Computer Graphics: Principles and Practice (Foley et al.)
1060
concat operator (PostScript) 913
Condensed font stretch 426
Confidential annotation icon 598
Configs entry (optional content properties dictionary)
345, 345
configuration dictionaries (optional content)
See optional content configuration dictionaries
configuration information (XFA forms) 682
constant opacity 182, 192, 496, 517
for annotations 583
notation 496, 501, 505
specifying 519, 1018
in transparency groups 499
constant shape 182, 192, 495, 517
notation 496, 501, 505
specifying 519, 1018
in transparency groups 499
consumer applications, PDF 1, 2, 382
alternate color space, handling of 223, 236
blend modes 516
character encodings, standard 923
character sets, standard 923
characters, identification of 441
color mapping function 449
compatibility, version 2, 18, 68
content extraction 16, 440
content streams, processing of 11
cross-reference table, processing of 75, 86
decoding of data 41
device profiles 449
embedded file streams, processing of 157
embedded fonts, copyright restrictions on 436
Index
1093
encrypted documents, handling of 96, 97
file content, processing of 17
file identifiers, use of 156, 332
file systems, platform-specific 155
font management 16, 358, 382, 383, 387
font substitution 426, 430
form XObjects, caching of 325, 527
gamut mapping function 449
glyph selection, TrueType fonts 399, 400, 409
glyph widths, use of 1014
glyphs, positioning of 363
graphics state, maintenance of 180
ICC profile rendering intents ignored 225
image data, handling of 306
images, rendering of 305
implicit color conversion 229
Indexed color spaces, use of 232
logical structure, navigation of 784
logical structure, usage of 833
masked images, treatment of 1013
metadata, use of 771
numbers, range and precision of 28
output intents, use of 900
page tree, handling of 117, 118
predefined CMaps, support for 418
procedure sets, compatibility with 770
reference XObjects, handling of 331
reference XObjects, printing of 333
rendering intents, handling of 230
resolution of output device, adjusting for 171
role map, processing of 789
shading patterns, interpolation of color values in 276
standard fonts 16, 386
standard security handler 92
tint transformation functions, use of 237
transparency, representing in PostScript 544-545
transparent objects, rasterization of 484
TrueType fonts, treatment of 439
Type 3 fonts, showing of text with 391, 392
volatile files, handling of 156
consumer applications, Tagged PDF
artifacts, treatment of 815-816
fragmented BLSEs, recognition of 830
hidden page elements, recognition of 816
hyphenation 816
ILSEs, line height for 856
layout 823
nonstandard structure types 827
page content order 817
placement attributes, treatment of negative values 852
reverse-order show strings 819
standard structure elements, processing of 813
text discontinuities, recognition of 816
Unicode mapping 820
word breaks, recognition of 823
ContactInfo entry (signature dictionary) 687
containing document (reference XObject) 331
content
extraction. See content extraction
importing 331-334
interchange 9, 789, 801
reflow. See reflow of content
content database, Web Capture
See Web Capture content database
content extraction 10, 769
access permission for 97, 99, 100
for accessibility to users with disabilities 864
from annotations 571, 581, 582
character encodings and 16
of character properties 819-821
of fonts 436
from form fields 637
of graphics 97, 99, 100, 168
lists, autonumbering of 862
in PostScript conversion 22
from structure elements 788
in Tagged PDF 812, 827, 842
of text 16, 97, 99, 100, 379, 440-446, 842
content items (logical structure) 789-801
annotations as 818
direct 825, 826, 834
finding structure elements from 786, 797-801, 867
link annotations, association with 836, 839
marked-content sequences as 329, 785, 786, 787, 790-
796, 797, 798, 800, 818
PDF objects as 785, 786, 787, 790, 796-797, 797
structural parent tree 312, 329
structure elements, associated with 787, 789
in Tagged PDF 827, 833
content, optional
See optional content
content rectangle 826, 859-860
and allocation rectangle 860
in layout 853, 854
content set subtypes (Web Capture) 882, 883
SIS 882, 883
SPS 882
content sets, Web Capture
See Web Capture content sets
content streams 9, 125-130, 1011
annotation appearances, defining 126, 813
application-specific data in 18
and basic layout model (Tagged PDF) 823
color space arrays prohibited in 210
color space, selection of 206
common programming language features, lack of 21
compatibility sections 127, 913, 914
Index
1094
as component of PDF syntax 23-24
data syntax 324
external objects (XObjects) 302
filters, decoding with 126, 1004
font characteristics 821
fonts 126, 359
form XObjects 126, 165, 325, 326, 327, 813, 814
glyph descriptions 390, 392, 393
glyphs, painting 358
images, painting 305
and
Indexed color spaces 232
indirect object references prohibited in 40
inline images 305, 322
in Linearized PDF 953, 959, 960, 961, 972, 1034
and marked content. See marked content
marked-content sequences confined within 778
named resources in 128
natural language specification 866, 867, 868
operands in 11, 126, 164
operators in 11, 126, 164, 913
optional content in 340-343
at page description level 166
pages, describing contents of 121, 126, 813, 814, 975,
976, 978, 980, 1004, 1033
parent, of patterns 261, 262, 264
and
Pattern color spaces 232
patterns, defining 126, 262, 263, 264, 268, 272
PostScript, conversion to 22
PostScript language fragments 303
printer’s marks in 894
procedure sets 770
q and Q operators in 185
and resources 125, 128-130, 328
as self-describing graphics objects 163, 302
shading patterns in 273
in structural parent tree 786, 797
text operators 375
text state parameters 367
transparency group XObjects 520, 526-527
trap network annotations 903
and trap networks 905
type 2 (shading) patterns, absent in 190
uncolored tiling patterns 259
unrecognized filters in 1007
content types (Web Capture) 882, 886, 887, 889
Contents entry
annotation dictionary 571, 580, 581, 582, 591, 599,
600, 645, 870
free text annotation dictionary 582
markup annotation dictionary 582
page object 121, 128, 185, 340, 778, 905, 953, 975, 1011
pop-up annotation dictionary 582
signature dictionary 67, 684, 686, 686, 687, 688, 697,
699
sound annotation dictionary 582
continuous-tone reproduction 51, 60, 447, 450, 456
controller bars (movies) 742
conversion engines (Web Capture) 888, 889
Coons patch meshes
See type 6 shadings
Coons patches 291-293, 297, 298, 300
coordinate spaces
See coordinate systems
coordinate systems 169-179
3D annotations 765-767
for appearance streams 577
coordinate spaces 169-174
rectilinear (measurement properties) 704
relationships among 174
for soft masks 520
for type 1 (function-based) shadings 278
See also
device space
form space
glyph space
image space
pattern space
target coordinate space
text space
transformation matrices
user space
coordinate transformations 172, 174-177
cm operator 172
combining 176-177, 178-179
on glyphs 357
inverting 179
reflection 169, 309, 909
rotation. See rotation
on sampled images 307
scaling. See scaling
skewing. See skewing
translation. See translation
Coords entry
type 2 shading dictionary 279
type 3 shading dictionary 281
Copy annotation usage rights 694
copy operator (PostScript) 149, 918
copyright 7
permission 7-8
cos operator (PostScript) 149, 917
CosineDot predefined spot function 460
Count entry
outline dictionary 554
outline item dictionary 555, 955
page tree node 118
country codes (ISO 3166) 132, 865
Index
1095
Courier standard font 385, 1015
Courier typeface 16, 923
CourierBold standard font 385, 1015
CourierBoldOblique standard font 385, 1015
CourierOblique standard font 385, 1015
CourierNew standard font name 1015
CourierNew,Bold standard font name 1015
CourierNew,BoldItalic standard font name 1015
CourierNew,Italic standard font name 1015
Cover transition style 564, 564
CP entry (sound object) 740
Create annotation usage rights 694
Create embedded files usage rights 695
Create Thumbnails command (Acrobat) 1007, 1033
creation date
document 769, 771, 772
Web Capture content set 882, 885
CreationDate entry
document information dictionary 772
embedded file parameter dictionary 158
markup annotation dictionary 583
Creator entry
CreatorInfo subdictionary, optional content usage
dictionary 350
document information dictionary 772
Mac OS file information dictionary 159
optional content configuration dictionary 346
creator signature (Mac OS) 159
CreatorInfo entry (optional content usage dictionary) 350
crop box 891, 892
and attached artifacts 815
and bounding box 332, 551
clipping to 893
display of 895
in page imposition 1032
in page object 120
printer’s marks excluded from 894
in printing 893
CropBox entry
box color information dictionary 895
page object 120, 120, 171, 549, 550, 891
CropFixed entry (version 1.3 OPI dictionary) 909
CropRect entry
version 1.3 OPI dictionary 909
version 2.0 OPI dictionary 912
Cross predefined spot function 463
cross-reference sections 69
byte offset 73, 75, 998
example 975, 992, 993, 995, 997, 998
in hybrid-reference files 86
and incremental updates 69, 71, 75
length count 73
in Linearized PDF 943
object numbers in 71
cross-reference stream dictionaries 83-84
Index entry 83, 84, 84
Prev entry 84
Size entry 83
Type entry 83
W entry 83, 84
cross-reference streams 69, 82-91
compatibility with PDF 1.4 85-91
entries 84-85
in Linearized PDF 943, 948
object stream entries 79
restrictions on 83
See also cross-reference stream dictionaries
cross-reference table 17, 67, 69-72, 997, 998
entries 70-71, 73, 75, 976, 992, 997, 998
in FDF files 670
and file trailer 72, 73
free entries 71, 956, 996, 997
in hybrid-reference files 86
incremental updates 18
in-use entries 70, 956
in Linearized PDF 943, 944, 948, 949, 950, 956, 958
reconstruction 921
sections. See cross-reference sections
subsections 69-70, 956, 995
Crypt filter 43, 66, 93, 106, 107
cross-reference stream dictionaries and 83
parameters. See
Crypt filter parameter dictionaries
crypt filter dictionaries 93, 107-111
AuthEvent entry 97, 107, 108
CFM entry 97, 107, 108, 109
EncryptMetadata entry 110, 1010
Length entry 109
Recipients entry 109
Type entry 108
Crypt filter parameter dictionary 66, 109
Name entry 66, 107
Type entry 66
crypt filters 66, 92, 93, 97, 104, 107-111, 1010
authorization event 108
decryption method 108
encryption of embedded files 94
Identity 66, 93, 94, 97, 107, 109, 110
key length 109
stream encryption 93
string encryption 94
See also crypt filter dictionaries
CryptFilter object type 108
CryptFilterDecodeParms object type 66
CS entry
Index
1096
3D background dictionary 764
inline image object 323, 324
projection dictionary 760, 761
transparency group attributes dictionary 521, 525, 527
CS operator 166, 210, 240, 257, 259, 914
in content streams 206, 210
for
DeviceCMYK color space 213
for
DeviceGray color space 212
for
DeviceRGB color space 213
for
Pattern color space 261
cs operator 166, 210, 240, 257, 259, 914
in content streams 206, 210
for
DeviceCMYK color space 213
for
DeviceGray color space 212
for
DeviceRGB color space 213
for
Pattern color space 261
CSS (Cascading Style Sheets) file format 821, 824
standard attribute owner 843
CSS-1.00 standard attribute owner 843, 844
CSS2 style attributes (rich text strings) 642, 644
color 644
font 644
font-family 644
font-size 644
font-stretch 644
font-style 644
font-weight 644
text-align 644
text-decoration 644
vertical-align 644
CSS-2.00 standard attribute owner 843, 844
CSV/TSV (text) format, importing 694
CT entry
media clip data dictionary 720, 721, 1028
Web Capture command dictionary 886, 887
Web Capture content set 882
CTM. See current transformation matrix
cubic Bézier curves 197-199, 1059, 1060, 1062
control points 199, 274, 294-295, 297-300
example 980
path construction 196, 913, 916
in path objects 164
type 6 shadings (Coons patch meshes) 274, 291, 295
type 7 shadings (tensor-product patch meshes) 298-
300
cubic spline interpolation 143, 145
currency character 928
current alpha constant 182, 519
and alpha source parameter 193
for annotations 578
CA entry (graphics state parameter dictionary) 192
ca entry (graphics state parameter dictionary) 192
current color, analogous to 519
and fully opaque objects 542
ignored by older viewer applications 1018
initialization 527, 528
multiple objects, applied to 519
nonstroking. See nonstroking alpha constant
and overprinting 538, 539
setting 519
soft-mask images, unaffected by 311
stroking. See stroking alpha constant
and transparency groups 519
current blend mode 181, 516
BM entry (graphics state parameter dictionary) 192,
516
and CompatibleOverprint 537
and fully opaque objects 542
ignored by older viewer applications 1018
initialization 527, 528
and overprinting 535
and process colorants 516
soft-mask images, unaffected by 311
and spot colorants 516
current clipping path 12, 163, 180, 194
clipping path operators 204
even-odd rule 202
explicit masks, simulating 319
glyph outlines 362
as “hard clip” 513
initialization 194
and marked content 780
n operator 200
nonzero winding number rule 202
object shape 204, 513
sh operator 273
shading patterns 275
and soft clipping, compared 192, 486, 513
text rendering mode 372
transparency groups 204
W operator 202, 205, 916
W* operator 202, 205, 916
See also
clipping path operators
current color 12, 163, 180, 184
B operator 200
for colored tiling patterns 262
current alpha constant, analogous to 519
“current opacity,” analogous to 496
f operator 180, 206
forced into valid range 184
initializing 212, 213, 215, 232
nonzero overprint mode 256
path objects, used by 168
Pattern color spaces 261
S operator 206
Separation color spaces 234
Index
1097
setting 183, 210, 212, 213, 235, 240, 257-258, 914, 915
sh operator, ignored by 273
shading patterns 273
as source color (transparent imaging model) 516
stencil masking 320
stroking and nonstroking 184, 200
text, showing 361
text objects, nesting of 375
tiling patterns as 264
tints 234
and transparent overprinting 534
Type 3 glyph descriptions 392, 393
for uncolored tiling patterns 262
See also
nonstroking color, current
stroking color, current
current color space 180
All colorant name 236
color values interpreted in 206
and current color 180
and image dictionaries 309
nonzero overprint mode 256
and overprinting 254
Pattern color spaces 264
remapping 227
Separation color spaces 234
setting 210, 212, 213, 215, 232, 257-258, 914, 915
stroking and nonstroking 184
and transparent overprinting 534, 536-537
See also
nonstroking color space, current
stroking color space, current
current font 12, 360
composite fonts 403
setting 359
See also
text font parameter
text font size parameter
current halftone 183, 455, 465, 476
HT entry (graphics state parameter dictionary) 192
setting 183
and transparency 541, 542
current line (text) 376
current line width 12, 181, 185
forced into valid range 184
LW entry (graphics state parameter dictionary) 190
and miter length 187
and projecting square line cap style 186
and round line cap style 186
and round line join style 186
and
S operator 180, 201
setting 183
stroke adjustment 181, 185, 481-482
and text rendering mode 371
and Type 3 glyph descriptions 392
w operator 189, 916
current navigation node 567, 568
current page 11, 170, 172, 486, 499
current path 196, 201, 205
current point 196, 197, 198
current rendering intent 181
Intent entry (image dictionary) 310
shading patterns, compositing of 528
and transparency 541, 542, 543
current resource dictionary 129
ColorSpace subdictionary 210, 227, 257, 324, 525
ExtGState subdictionary 189, 190
Font subdictionary 303, 359, 368, 383
Pattern subdictionary 258, 264
Properties subdictionary 779, 780
Shading subdictionary 273
XObject subdictionary 302, 309, 312, 326, 330
current soft mask 182, 518, 519, 520
alpha source parameter 193
and fully opaque objects 542
ignored by older viewer applications 1018
initialization 527, 528
SMask entry (graphics state parameter dictionary) 192
soft-mask images, overridden by 311
current text position 360, 363
current transfer function 183, 455, 468, 469, 472, 474
TR operator 192
TR2 operator 192
and transparency 541, 542
current transformation matrix (CTM) 163, 171, 180
cm operator 189, 913
form XObjects, positioning 326, 327
halftones unaffected by 457
sampled images, positioning 173, 308
shading patterns, compositing of 528
and soft masks 520
stroking, effect on 185
and text rendering matrix 374, 380
text size 361
and tiling patterns 264
in Type 3 glyph descriptions 391
current trap network 904
Cursive font classification (Tagged PDF) 822
curves, cubic Bézier
See cubic Bézier curves
curveto operator (PostScript) 913, 916
Custom production condition 899
cut marks 605, 890, 891, 893, 894
as page artifacts 815
cvi operator (PostScript) 149, 917
cvr operator (PostScript) 149, 917
Index
1098
“cvt ” table (TrueType font) 439
cyan color component
DeviceCMYK color space 211, 213
DeviceN color spaces 238
grayscale conversion 451, 456
halftones for 476
initialization 213
overprinting 539, 540
red, complement of 452
RGB conversion 451, 452
transfer function 454, 455
transparent overprinting 540
undercolor removal 183, 452, 453
cyan colorant
overprinting 539, 540
PANTONE Hexachrome system 238
printing ink 234
process colorant 211, 213
subtractive primary 211, 213
transparent overprinting 540
Cyrillic characters 433, 434
CYX entry (rectilinear measure dictionary) 707
D
D border style (dashed) 576
D entry
3D activation dictionary 751
additional-actions dictionary 611
appearance dictionary 579, 678, 896, 904
border style dictionary 576
box style dictionary 895
floating window parameters dictionary 730
go-to action dictionary 616
graphics state parameter dictionary 190
inline image object 323
media clip data dictionary 720, 721
media clip section dictionary 723
media criteria dictionary 717
media play parameters dictionary 721
media play parameters
MH/BE dictionaries 726, 727
named destination dictionary 553
number format dictionary 708
optional content properties dictionary 345, 345, 355
rectilinear measure dictionary 706
remote go-to action dictionary 617
thread action dictionary 623
transition dictionary 564, 565
Windows launch parameter dictionary 622
D guideline style (page boundaries) 895
d operator 166, 189, 914
D trigger event (annotation) 611, 613, 614
d0 operator 166, 390, 392, 914
d1 operator 166, 259, 390, 392, 393, 914
DA entry
field dictionary 635, 640, 641, 645, 654
free text annotation dictionary 589, 645
interactive form dictionary 635
DamagedRowsBeforeError entry (CCITTFaxDecode filter
parameter dictionary) 54, 55
Darken blend mode 491
and overprinting 535, 536, 541
dash array 187-188, 190
annotation borders 572, 576, 1019
page boundaries 895
dash phase 187-188, 190
annotation borders, unspecified for 572, 576
page boundaries, unspecified for 895
Dashed border style 849
data
binary 25
types for dictionary entries 131
Data entry (signature reference dictionary) 673, 689, 696
data structures 130-139
See also
dates
multi-language text arrays
name trees
number trees
rectangles
text streams
text strings
Data Structures and Algorithms (Aho, Hopcroft, and
Ullman) 117, 1059
dates 133
creation
document 769, 771, 772
Web Capture content set 882, 885
as dictionary values 131
expiration (Web Capture content set) 884, 885
modification
annotation 571
document 769, 771, 772, 777, 1030
form XObject 329, 777
page 119, 777
trap network 905
Web Capture content set 884, 885
in submit-form actions 665
DC entry (additional-actions dictionary) 613
DC trigger event (document) 613
DCS (Desktop Color Separation) images 159
DCT (discrete cosine transform) compression 43, 60-62
DCT filter abbreviation 324, 1007
DCTDecode filter 43, 60-62, 1008
color key masking, not recommended with 321
Index
1099
DCT abbreviation 324, 1007
parameters. See
DCTDecode filter parameter dictionar-
ies
in sampled images 310
DCTDecode filter parameter dictionaries 60, 61
ColorTransform entry 61
Decimal list numbering style 862
Decode arrays
color inversion with 316
image masks 310, 320
sampled images 306, 311, 314-316, 321
shadings 285, 288, 290, 294
Decode entry
image dictionary 65, 306, 311, 320, 522, 523, 557
inline image object 323
type 0 function dictionary 142, 143, 145-146
type 4 shading dictionary 285, 288
type 5 shading dictionary 290
type 6 shading dictionary 294
decode parameters dictionary 66
DecodeParms entry
inline image object 323
stream dictionary 38, 42, 83, 107
DP abbreviation 1006
decoding filters 41-62, 96, 951, 1006-1008
See also
ASCII85Decode filter
ASCIIHexDecode filter
CCITTFaxDecode filter
Crypt filter
DCTDecode filter
FlateDecode filter
JBIG2Decode filter
JPXDecode filter
LZWDecode filter
RunLengthDecode filter
decoding functions 214, 216, 217, 219, 221
Decorative font classification (Tagged PDF) 822
default appearance strings
FDF field 678
form field 640, 641-642
free text annotation 589
default color spaces 211, 227-228, 531, 900
DefaultCMYK 227, 230, 258, 449, 525
DefaultGray 227, 258, 449, 525
DefaultRGB 227, 228, 258, 449, 525
Default entry (type 5 halftone dictionary) 475
Default graphics state parameter value
black-generation function 191
halftone parameter 192
transfer function 192
undercolor-removal function 191
default user space 171, 171
for annotations 570, 572, 574, 575, 588, 590, 596
BLSEs, layout of 851, 852, 853, 855, 856
current transformation matrix (CTM) 180
in destinations 551
glyph space, mapping from 856
glyphs, scaling of 360
halftone angles 467
for page boundaries 120, 891
page size limits 921, 1033
pattern matrix 261
unit size 122, 171, 360, 921, 1033
for Web Capture pages 890
DefaultCMYK default color space 227, 230, 258, 449, 525
DefaultForPrinting entry (alternate image dictionary) 317
DefaultGray default color space 227, 258, 449, 525
DefaultRGB default color space 227, 228, 258, 449, 525
DEFLATE Compressed Data Format Specification (Internet
RFC 1951) 47, 1062
Delete annotation usage rights 694
Delete embedded files usage rights 695
delimiter characters 25, 26, 27, 32, 33
Department of Commerce, U.S. 1009
Departmental annotation icon 598
Desc entry (file specification dictionary) 156, 157, 600,
1021
descendant fonts (Type 0 font) 403, 423
DescendantFonts entry
CID-keyed font dictionary 405
Type 0 font dictionary 405, 423, 424
Descent entry (font descriptor) 427, 856
Design intent (optional content) 335, 338, 346, 350
Dest entry
link annotation dictionary 572, 587, 616
outline item dictionary 555, 616
destination handlers 937
destination profile (PDF/X output intent dictionary) 900,
1032
destinations 115, 551-553, 609
explicit 551-552, 617
for go-to actions 551, 616
handlers 937
for link annotations 551, 553, 587, 1020
magnification (zoom) factor 551, 552
named. See named destinations
for outline items 551, 553, 554, 555, 1018
plug-in extensions for 937
for remote go-to actions 551, 617
DestOutputProfile entry (PDF/X output intent
dictionary) 899, 900
Dests entry
Index
1100
document catalog 114, 553, 956, 971
name dictionary 125, 553
DevDepGS_BG entry (legal attestation dictionary) 702
DevDepGS_FL entry (legal attestation dictionary) 702
DevDepGS_HT entry (legal attestation dictionary) 702
DevDepGS_OP entry (legal attestation dictionary) 702
DevDepGS_TR entry (legal attestation dictionary) 702
DevDepGS_UCR entry (legal attestation dictionary) 702
device color spaces 207, 211-213
as alternate color space 237, 240
as base color space 232
blending in 490, 530
CIE-based spaces, conversion from 277, 447, 448-449
and color specification 205
conversion among 277, 447, 450-454
and
DeviceN spaces 238
flattening of transparent content to 545
implicit conversion of CIE-based colors to 228-230
in inline images 324
and overprinting 254
for page group 511, 530
process colors, rendered as 450
and rendering intents 181
and separations 234
setting color values in 257
for shadings 275, 277
for soft masks 515
in transparency groups 211, 525, 531
See also
DeviceCMYK color space
DeviceGray color space
DeviceRGB color space
device colorants 211
and overprinting 254, 255, 541
for preseparated pages 897
and transparent overprinting 534
device-dependent graphics state parameters 180, 182-183,
264, 448
device gamut 230, 231, 449
device-independent graphics state parameters 180, 180-
182, 185
device profiles 449
device space 169-170
current transformation matrix (CTM) 163, 174, 180
form space, mapping from 327
halftone cells, orientation relative to 457, 458, 467, 468,
470, 473
halftones defined in 457
resolution 457
scan conversion in 480-481
stroke adjustment in 481-482
text space, relationship with 380
threshold arrays defined in 464, 469, 473, 474
type 6 shadings (Coons patch meshes) 292, 293
URI actions, mouse position for 624
DeviceCMY process color model 906
DeviceCMYK color space 207, 211, 213, 238, 315
as alternate color space 223
as blending color space 489
CMYK abbreviation 323
color values 213
and
DeviceGray, conversion between 451, 456
and
DeviceN color spaces, compared 240
DeviceRGB, conversion from 451-453, 544
DeviceRGB, conversion to 454
in dynamic appearance streams 604
halftones for 476
implicit conversion from CIE-based 229
initial color value 213, 257
in inline image objects 324
as native color space 448, 450
overprint mode 182
and overprinting 255-256, 539-540
for page group 511
process colors, specification of 532
remapping to alternate color space 227, 228
in sampled images 304
and
Separation color spaces, compared 235
setting 210, 257
setting color values in 257, 258
for soft masks 515
specification 213
spot color components, effect on in transparency
groups 533
substituted for
CalCMYK 214
tint transformation function 148
transfer functions 456
in transparency groups 531
and transparent overprinting 534, 536, 537, 540
DeviceCMYK process color model 906
DeviceColorant entry (separation dictionary) 897
DeviceGray color space 207, 211, 212, 315
as alternate color space 223
and
DeviceRGB, conversion between 451
as blending color space 489
color values 212
and
DeviceCMYK, conversion between 451, 456
and
DeviceN color spaces, compared 240
in dynamic appearance streams 604
G abbreviation 323
halftones for 476
initial color value 212, 257
in inline image objects 324
as native color space 448, 450
and overprinting 541
for preseparated pages 897
remapping to alternate color space 227
Index
1101
in sampled images 304
and
Separation color spaces, compared 235
setting 210, 257
setting color values in 257, 258
for soft masks 515
specification 212
for thumbnail images 557
transfer functions 456
in transparency groups 531
DeviceGray process color model 906
DeviceN color space attributes dictionaries 241-242
Colorants entry 242, 245, 246
MixingHints entry 242, 243
Process entry 242
Subtype entry 239, 241, 242, 243
DeviceN color spaces 207, 232, 238-249, 316
All colorant name prohibited in 240
alternate color space for 148, 240-241, 242, 256, 277
alternate color space, prohibited as 237, 240
attributes. See
DeviceN color space attributes dictionar-
ies
as base color space 232, 233
blending color space, prohibited as 525
color values 240
colorant names 240-241
colorants dictionaries 242
DeviceN subtype 242
halftones for 476
initial color value 240, 257
NChannel subtype 242
None colorant name 240-241
nonzero overprint mode 255
number of components 240, 920
and overprinting 254, 539-540
parameters 239-241
for preseparated pages 898
remapping of alternate color space 228
in sampled images 304
and
Separation color spaces, compared 239
setting color values in 258
for shadings 277
in soft masks 520
specification 239
spot color components in 532
for spot colorants 450, 489
tint transformation function 148, 240-241, 242, 256,
277
tints 240, 257
in transparency groups 229
and transparent overprinting 537, 540
DeviceN mixing hints dictionaries 248
DotGain entry 245
PrintingOrder entry 244
Solidities entry 244
DeviceN process color model 906
DeviceN process dictionaries 242
ColorSpace entry 244
Components entry 244, 248
DeviceN subtype (DeviceN color spaces) 242
DeviceRGB color space 207, 211, 212-213, 315, 729, 764
as alternate color space 223
and
DeviceGray, conversion between 451
for annotations 572, 591, 594, 596
as base color space 232, 233
as blending color space 489
color values 212
DeviceCMYK, conversion from 454
DeviceCMYK, conversion to 451-453, 544
and
DeviceN color spaces, compared 240
in dynamic appearance streams 604
halftones for 476
initial color value 213, 257
in inline image objects 324
as native color space 448, 450
for outline items 555
and overprinting 541
for page boundaries 895
for page group 511
remapping to alternate color space 227, 228
RGB abbreviation 323
in sampled images 304
and
Separation color spaces, compared 235
setting 210, 257
setting color values in 257, 258
for soft masks 515
specification 212
for thumbnail images 557
transfer functions 454
in transparency groups 531
DeviceRGB process color model 906
DeviceRGBK process color model 906
devices, output
See output devices
Di entry (transition dictionary) 563, 564, 564
Diamond line ending style 593
Diamond predefined spot function 463
dictionaries
See dictionary objects
See also
3D activation dictionaries
3D annotation dictionaries
3D background dictionaries
3D stream dictionaries
3D view dictionaries
action dictionaries
additional-actions dictionaries
alternate image dictionaries
Index
1102
annotation dictionaries
appearance characteristics dictionaries
appearance dictionaries
application data dictionaries
attribute objects
bead dictionaries
border effect dictionaries
border style dictionaries
box color information dictionaries
box style dictionaries
button field dictionaries
CalGray color space dictionaries
CalRGB color space dictionaries
caret annotation dictionaries
CCITTFaxDecode filter parameter dictionaries
certificate seed value dictionaries
check box field dictionaries
choice field dictionaries
CIDFont dictionaries
CIDFont
FD dictionaries
CIDFont
Style dictionaries
CIDSystemInfo dictionaries
circle annotation dictionaries
class map
CMap dictionaries
cross-reference stream dictionaries
Crypt filter parameter dictionaries
crypt filter dictionaries
DCTDecode filter parameter dictionaries
decode parameters dictionary
DeviceN color space attributes dictionaries
DeviceN mixing hints dictionaries
DeviceN process dictionaries
DocMDP transform parameters dictionaries
document catalog
document information dictionary
embedded file parameter dictionaries
embedded file stream dictionaries
embedded font stream dictionaries
embedded go-to action dictionaries
encoding dictionaries
encryption dictionaries
FDF annotation dictionaries
FDF catalog
FDF dictionary
FDF field dictionaries
FDF named page reference dictionaries
FDF page dictionaries
FDF page information dictionaries
FDF template dictionaries
FDF trailer dictionary
field dictionaries
FieldMDP transform parameters dictionaries
file attachment annotation dictionaries
file specification dictionaries
file trailer dictionary
filter parameter dictionaries
fixed print dictionaries
FlateDecode filter parameter dictionaries
floating window parameters dictionaries
font descriptors
font dictionaries
form dictionaries
free text annotation dictionaries
function dictionaries
go-to-3D-view action dictionaries
go-to action dictionaries
graphics state parameter dictionaries
group attributes dictionaries
halftone dictionaries
hide action dictionaries
hint stream dictionaries
ICC profile stream dictionaries
icon fit dictionaries
image dictionaries
import-data action dictionaries
ink annotation dictionaries
interactive form dictionary
JavaScript action dictionaries
JavaScript dictionary
JBIG2Decode filter parameter dictionaries
Lab color space dictionaries
launch action dictionaries
legal attestation dictionaries
line annotation dictionaries
linearization parameter dictionary
link annotation dictionaries
LZWDecode filter parameter dictionaries
Mac OS file information dictionaries
mark information dictionary
marked-content reference dictionaries
markup annotation dictionaries
media clip dictionaries
media clip data dictionaries
media clip data
MH/BE dictionaries
media clip section dictionaries
media clip section
MH/BE dictionaries
media criteria dictionaries
media duration dictionaries
media offset dictionaries
media permissions dictionaries
media play parameters dictionaries
media players dictionaries
media screen parameters dictionaries
metadata stream dictionaries
minimum bit depth dictionary
minimum screen size dictionaries
movie action dictionaries
movie activation dictionaries
movie annotation dictionaries
Index
1103
movie dictionaries
multiple master font dictionaries
name dictionary
name tree nodes
named-action dictionaries
named destination dictionaries
navigation node dictionaries
number tree nodes
object reference dictionaries
OPI dictionaries
OPI version dictionaries
optional content configuration dictionaries
optional content group dictionaries
optional content membership dictionaries
optional content properties dictionary
optional content usage dictionaries
outline dictionary
outline item dictionaries
output intent dictionaries
page label dictionaries
page objects
page-piece dictionaries
page tree nodes
pattern dictionaries
PDF/X output intent dictionaries
permissions dictionaries
polygon annotation dictionaries
polyline annotation dictionaries
pop-up annotation dictionaries
PostScript XObject dictionaries
printer’s mark annotation dictionaries
printer’s mark form dictionaries
projection dictionaries
property lists
reference dictionaries
remote go-to action dictionaries
rendition action dictionaries
rendition dictionaries
rendition
MH/BE dictionaries
reset-form action dictionaries
resource dictionaries
role map
rubber stamp annotation dictionaries
screen annotation dictionaries
selector rendition dictionaries
separation dictionaries
set-OCG-state action dictionaries
shading dictionaries
signature dictionaries
signature field dictionaries
signature field lock dictionaries
signature field seed value dictionaries
signature reference dictionaries
slideshow dictionaries
soft-mask dictionaries
soft-mask image dictionaries
sound action dictionaries
sound annotation dictionaries
source information dictionaries
square annotation dictionaries
stream dictionaries
structure element dictionaries
structure tree root
submit-form action dictionaries
target dictionaries
text annotation dictionaries
text field dictionaries
text markup annotation dictionaries
thread action dictionaries
thread dictionaries
thread information dictionaries
timespan dictionaries
transition dictionaries
transition action dictionaries
transparency group attributes dictionaries
trap network annotation dictionaries
trap network appearance stream dictionaries
TrueType font dictionaries
Type 0 font dictionaries
Type 0 function dictionaries (sampled)
Type 1 font dictionaries
type 1 form dictionaries
type 1 halftone dictionaries
type 1 pattern dictionaries (tiling)
type 1 shading dictionaries (function-based)
type 2 function dictionaries (exponential interpola-
tion)
type 2 pattern dictionaries (shading)
type 2 shading dictionaries (axial)
Type 3 font dictionaries
type 3 function dictionaries (stitching)
type 3 shading dictionaries (radial)
type 4 shading dictionaries (free-form Gouraud-
shaded triangle mesh)
type 5 halftone dictionaries
type 5 shading dictionaries (lattice-form Gouraud-
shaded triangle mesh)
type 6 halftone dictionaries
type 6 shading dictionaries (Coons patch mesh)
type 7 shading dictionaries (tensor-product patch
mesh)
type 10 halftone dictionaries
type 16 halftone dictionaries
UR transform parameters dictionaries
URI action dictionaries
URI dictionaries
URL alias dictionaries
usage application dictionaries
user property dictionaries
viewer preferences dictionary
Index
1104
viewport dictionaries
watermark annotation dictionaries
Web Capture command dictionaries
Web Capture command settings dictionaries
Web Capture content sets
Web Capture image sets
Web Capture information dictionary
Web Capture page sets
widget annotation dictionaries
Windows launch parameter dictionaries
dictionary objects 35-36
adding new entries to 937, 1004
as attribute objects 801
capacity limit 35, 134
as dictionary values 131
duplicate keys 35
entries 35
keys 25, 35, 1004
metadata associated with 774, 775
null entries 28
as operands 126
syntax 35-36
values 35
version compatibility 1005
Difference blend mode 492
not white-preserving 536
Differences entry
encoding dictionary 390, 397, 441
FDF dictionary 664, 674
differencing (image compression) 50
diffuse achromatic highlight 218
diffuse achromatic shadow 218
diffuse black point 216, 218, 221
diffuse white point 216, 217, 218, 221
DigestLocation entry (signature reference dictionary) 690
DigestMethod entry (signature reference dictionary) 689,
1037
digests (digital signatures) 684-685
See also
byte-range digests
object digests
DigestValue entry (signature reference dictionary) 690,
690, 691
Digital Compression and Coding of Continuous-Tone Still
Images (ISO/IEC 10918-1) 1061
digital identifiers (Web Capture) 874, 878-879, 1031
in content database 875, 882, 884
for image 312, 889
in name dictionary 125, 875
for page 122, 889
in unique name generation 880
Digital Signature Appearances (Adobe Technical Note)
658, 1057
Digital Signature Standard (FIPS PUB 186-2) 1060
digital signatures
See signatures, digital
Dingbats glyph class 433, 434
Dingbats typeface
See ITC Zapf Dingbats
®
typeface
DingbatsRot glyph class 434
direct content items 825, 834
allocation rectangle 826
content rectangle 826
direct objects
in FDF files 672
in name trees 134
stream dictionaries 36
Direction entry (viewer preferences dictionary) 549, 569
DIS entry
3D activation dictionary 751
Disc list numbering style 862
displacement vector (glyph) 365
DW2 entry (CIDFont) 410-411
horizontal scaling 370
W2 entry (CIDFont) 411
See also
glyph displacement
display duration 121, 563, 565
DisplayDocTitle entry (viewer preferences dictionary) 548
displays, raster-scan 12
and halftones 456, 457, 465
primary colorants 234
resolution 13
scan conversion for 478
and
Separation color spaces 236
stroke adjustment for 481
Dissolve transition style 563
Distiller
®
, Acrobat
See Acrobat Distiller
®
Distribute ruby text alignment 857
div operator (PostScript) 149, 917
Div standard structure type 827, 828, 829, 833
DL entry (stream dictionary) 39
Dm entry (transition dictionary) 563, 564
Do operator 166, 302, 526, 527, 914
base images 309
and black-generation functions 544
colored tiling patterns 265
form XObjects 261, 313, 326, 327, 330, 344
and fully opaque objects 542
image XObjects 305
and logical structure elements 793, 794, 797
Index
1105
and marked content 782
PostScript XObjects 303
and rendering intents 543
shading patterns 273
uncolored tiling patterns 269
and undercolor-removal functions 544
Doc entry (JavaScript dictionary) 676
DocMDP entry (permissions dictionary) 690, 691, 700
DocMDP transform method 689, 690-692, 700, 701
DocMDP transform parameters dictionaries 691, 696
P entry 691, 692, 696
Type entry 692
V entry 692
DocOpen authorization event (crypt filters) 97, 107, 108
document catalog 112, 112-117, 1010-1011
AA entry 116, 611, 1011
AA entry (obsolete) 1011
AcroForm entry 116, 634, 949
Dests entry 114, 553, 956, 971
example 976, 978, 980
in file trailer 73
Lang entry 116, 864, 865, 866, 867
Legal entry 117, 701
in Linearized PDF 942, 944, 948, 949, 956, 971
MarkInfo entry 116, 784
Metadata entry 116, 774
Names entry 114, 124, 956, 971
OCProperties entry 116, 345, 355
OpenAction entry 115, 551, 609, 612, 624, 949, 952,
964, 969, 1034
Outlines entry 87, 115, 554, 975
OutputIntents entry 116, 898
PageLabels entry 114, 559, 1019
PageLayout entry 115, 1011, 1018
PageMode entry 115, 548, 945, 949, 953
Pages entry 114
Perms entry 117, 699
PieceInfo entry 116, 772, 776
private data in 771, 1002
SpiderInfo entry 116, 874
StructTreeRoot entry 116, 785, 827
Threads entry 115, 560, 623, 949, 971
Type entry 114
URI entry 116, 625, 723
Version entry 68, 75, 114, 717, 1002, 1003, 1004, 1010
ViewerPreferences entry 114, 547, 949
Document entry (UR transform parameters dictionary)
693
document information dictionary 73, 561, 771-773
Author entry 772
CreationDate entry 772
Creator entry 772
and file identifiers 776
keys in 771
Keywords entry 772
in Linearized PDF 949, 956
metadata streams, compared with 773
ModDate entry 772, 777
Producer entry 772
registered names not required in 938
Subject entry 772
Title entry 772
Trapped entry 772
version compatibility, use for 1030-1031
document interchange 21, 164, 769-912
pdfmark language extension (PostScript) 20
version compatibility 1001
See also
accessibility to users with disabilities
file identifiers
logical structure
marked content
metadata
page-piece dictionaries
prepress production
procedure sets
Tagged PDF
Web Capture plug-in extension
document outline 112, 115, 550, 554-556, 1018
hiding and showing 115, 548
hierarchy. See outline hierarchy
items. See outline items
outline dictionary 115, 975, 976, 978, 980
Document Properties dialog box (Acrobat) 1030
Document standard structure type 827, 828, 833
document structuring conventions, PostScript (DSC) 27
document windows
centering on screen 548
and destinations 551, 552
fitting to document 548
and remote go-to actions 617
title bar 548
documents 9, 24
additional-actions dictionary 116, 610-613
application-specific data 18
article threads 112, 115
authenticity, certification of 18
author 769, 771, 772
catalog. See document catalog
closing 613
collaborative editing 665
creation date 769, 771, 772
creator application 772
encryption 17, 31, 91-103, 1009
extensibility 18
extraction of content. See content extraction
Index
1106
incremental updates. See incremental updates
information dictionary 73, 561, 771-773
interactive form dictionary 116, 949
interchange. See document interchange
keywords 772
language identifier 116, 788
logical structure. See logical structure
mark information dictionary 116, 784-785
metadata 116, 769, 771-775, 1030-1031
modification date 769, 771, 772, 777, 1030
name dictionary 114, 124-125
named halftones 466
natural language specification 864, 866
open action 115, 551, 609
opening 609, 621, 622
outline. See document outline
output intent dictionaries 116
page labels 114
page layout 115, 1021-1022
page mode 115, 548
page objects. See page objects
page tree 112, 114, 117-124, 669, 975, 983
page tree root 114
printing 97, 436, 448, 613, 621, 622
private data associated with 776
producer application 772
reading order 549
saving 613
scan conversion 478
security 17-18
structure 23, 112-125
structure tree root 116
subject 772
title 769, 771, 772
trapping status 772
trigger events for 613
undoing changes 18
URI dictionary 116, 625
viewer preferences 114
Web Capture information dictionary 116
dollar sign (
$) character 413
domain
function 140, 141, 142, 143, 147-148, 278, 279, 281,
285, 290, 294
shading 148, 278, 279, 280, 281, 282
Domain entry
function dictionary 141, 142, 146, 147, 150
type 1 shading dictionary 278
type 2 shading dictionary 279
type 3 shading dictionary 281, 282
DoNotScroll field flag (text field) 653
DoNotSpellCheck field flag
choice field 656
text field 653
DOS (Disk Operating System) 20, 153
file names 154, 775
file system 155
DOS entry (file specification dictionary) 155, 156
DotGain entry
DeviceN mixing hints dictionary 245
dot-matrix printers 12
resolution 13
Dotted border style 849
double angle brackets (
<< >>)
as dictionary delimiters 35, 73, 672
Double border style 849
double left angle bracket (
<<) character sequence
as dictionary delimiter 35, 73, 672
double period (
..) character sequence
in relative file specifications 153
in uniform resource locators (URLs) 878
Double predefined spot function 460
double right angle bracket (
>>) character sequence
as dictionary delimiter 35, 73, 672
DoubleDot predefined spot function 459
down appearance (annotation) 578, 603
DP entry
additional-actions dictionary 613
inline image object 323
stream dictionary (abbreviation for
DecodeParms)
1006
DP operator 166, 340, 778, 779, 914
property list 778, 780
DP trigger event (document) 613
DR entry
interactive form dictionary 635, 641, 642, 646, 1023
Draft annotation icon 598
drag-and-drop 894
driver, printer 19, 20
dropped capitals 861, 871
DS entry
additional-actions dictionary 613
field dictionary 640, 646
free text annotation dictionary 589, 645
DS trigger event (document) 613
DSC. See document structuring conventions, PostScript
duotone color 238
examples 249-252
dup operator (PostScript) 149, 918
Dur entry
navigation node dictionary 567
page object 121, 562-563, 565
Duration entry (movie activation dictionary) 742, 742
DV entry
Index
1107
3D stream dictionary 753
field dictionary 638, 639, 648, 666
DVI (Device Independent) file format 19
DW entry (CIDFont dictionary) 407, 410
DW2 entry (CIDFont dictionary) 407, 410-411, 439
dynamic appearance streams 603, 634
alternate (down) caption 604
alternate (down) icon 605
background color 604
border color 604
for choice fields 678
icon fit dictionary 605
normal caption 604
normal icon 604
rollover caption 604
rollover icon 605
for text fields 654
E
E entry
additional-actions dictionary 611
hint stream dictionary 951
linearization parameter dictionary 947, 952, 1034
media clip section
MH/BE dictionaries 724, 725
property list 816, 820, 821, 834, 872, 873
sound object 740
source information dictionary 884, 885
structure element dictionary 788, 842, 844, 872, 820
E trigger event (annotation) 611, 613, 614, 627
EA entry (3D background dictionary) 764
EarlyChange entry (LZWDecode filter parameter
dictionary) 50
edge flags 285, 286-288, 295-297, 300-301
Edit field flag (choice field) 656
editing, collaborative 665
EF entry
file specification dictionary 156, 157, 162
UR transform parameters dictionary 695
EFF entry (encryption dictionary) 94, 1009
EFOpen authorization event (crypt filters) 107, 108
EI operator 166, 322, 324, 914
element identifiers (logical structure) 786, 787
Ellipse predefined spot function 461
EllipseA predefined spot function 462
EllipseB predefined spot function 462
EllipseC predefined spot function 462
ellipsis (
…) character 1000
em dash character, as word separator 823
embedded CIDFonts 405, 408
embedded CMaps 405, 418, 418, 1016
embedded file parameter dictionaries 158, 158
CheckSum entry 158
CreationDate entry 158
Mac entry 158
ModDate entry 158
Size entry 158
embedded file stream dictionaries 157-158, 675
EncryptionRevision entry 675
Params entry 158
Subtype entry 158, 721
Type entry 158
embedded file stream hint table (Linearized PDF) 952
embedded file streams 157-160
checksum 158
embedded go-to-actions 617
encryption 91, 94, 675
FDF 675
and file attachment annotations 600
hint table (Linearized PDF) 967-969
in Linearized PDF 956, 967
maintenance of file specifications 162
named 125
platform-specific 156
and reference XObjects 331
related files arrays 156, 159-160, 162
See also
embedded file stream dictionaries
embedded font programs 16, 357, 358, 382, 428, 436-440,
1017
base encoding 397
built-in encoding 397
compact 436, 438-439
filters in 437, 438
font descriptors and 426
in Linearized PDF 954, 972
OpenType 437, 438, 439-440
organization, by font type 436-437
overriding standard fonts 386
PaintType entry ignored 439
for portability 1017
snapshots (multiple master) 387
TrueType 387, 400, 409, 416, 428, 436, 437, 439
Type 0 compact CIDFonts 437, 438
Type 1 428, 436, 437, 1014-1015
Type 1 compact fonts 436, 438
unrecognized filters in 1007
embedded font stream dictionaries 428, 437-438
Length1 entry 437, 438
Length2 entry 437, 438
Length3 entry 437, 438
Metadata entry 438
Subtype entry 428, 436, 438
Index
1108
embedded font subsets 16, 440
embedded font subtypes 438
CIDFontType0C 408, 437, 438
OpenType 408, 437, 438
Type1C 436, 438
embedded go-to action dictionaries 618
D entry 618
F entry 618
NewWindow entry 618
S entry 618
T entry 618
embedded go-to actions 615, 617-621
See also
embedded go-to action dictionaries
Embedded object subtype 744
EmbeddedFDFs entry (FDF dictionary) 675
EmbeddedFile object type 158
EmbeddedFiles entry (name dictionary) 125, 156, 157, 617
EmbedForm field flag (submit-form field) 665
EMC operator 166, 340, 341, 641, 778, 779, 790, 914
Encapsulated PostScript (EPS) 486
Encode entry
type 0 function dictionary 142, 143
type 3 function dictionary 147
EncodedByteAlign entry (CCITTFaxDecode filter parameter
dictionary) 54, 55
Encoding array (Type 1 font program) 399
encoding dictionaries 384, 390, 397, 924, 928
BaseEncoding entry 397, 399, 401, 1016
Differences entry 390, 397, 441
Type entry 397
Encoding entry 396, 412
CID-keyed font dictionary 405
CIDFonts, absent in 406
FDF dictionary 674, 1025
TrueType font dictionar y 388, 399, 400, 401, 402
Type 0 font dictionary 405, 416, 419, 422, 423, 424
Type 1 font dictionary 384, 399
Type 3 font dictionary 390, 399, 1016
encoding filters 96
encoding formats, sound 740
ALaw 740
muLaw 740
Raw 740
Signed 740
Encoding object type 397
Encoding resource type 953
encodings
ASCII base-85 15, 41, 42, 43, 45-46
ASCII hexadecimal 43, 45, 58, 96
character. See character encodings
Encrypt entry (file trailer dictionary) 73, 91, 949
encryption 17, 31, 91-103, 1009
AES algorithm 95, 95, 108
algorithm revision number (FDF) 675
algorithms 93, 105-106
ASCII filters not useful with 42
crypt filters 107-111
dictionary. See encryption dictionary
in FDF files 675
general algorithm 94-96
key algorithm 100-101
keys. See encryption keys
metadata streams, not recommended for 773
password algorithms 101-103, 675, 1009
passwords 101-103, 675, 1009
public-key security handlers 105-106
security handlers 43, 92, 92, 96-103, 937
signature fields 684
encryption dictionary 73, 91-93, 96, 97
CF entry 66, 93, 93, 105, 107
EFF entry 94, 1009
encrypting contents of 94
EncryptMetadata entry 98
Filter entry 92, 92, 101, 104
Length entry 92, 93, 95, 101, 102
in Linearized PDF 949
O entry 98, 101, 101-102, 103
P entry 98, 101
for public-key security handlers 104-105
R entry 98, 101
Recipients entry 105, 106
for standard security handler 98, 101
standard 98-100, 1009
StmF entry 93, 93, 105, 106, 107, 108, 109, 110
StrF entry 93, 94, 105, 106, 107, 108, 109
SubFilter entry 92, 93, 104, 105, 106
U entry 98, 101, 102-103
V entry 92, 93, 95, 98, 101, 107, 1009
encryption keys 95
computing 98, 100-101
and encryption revision number 93
for FDF files 675
length 92, 93
owner password, authenticating 103
owner password, computing 102
public-key security handlers 105, 106
user password, computing 102, 103
using 95
EncryptionRevision entry (embedded file stream
dictionary) 675
EncryptMetadata entry
crypt filter dictionary 110, 1010
encryption dictionary 98
end edge 825
Index
1109
of allocation rectangle 860
border color 849
border style 849
border thickness 850
and content rectangle 860
in layout 826, 847, 852, 853, 854
padding width 850, 855
ruby text alignment 857
End inline alignment 854
end-of-data (EOD) marker 37, 48, 49, 54
for
ASCII85Decode (~>)45, 46
for
ASCIIHexDecode (>)45
for
RunLengthDecode 53
end-of-facsimile-block (EOFB) pattern (
CCITTFaxDecode
filter) 55
end-of-file (EOF) marker (
%%EOF) 73, 75, 672, 949, 1008
end-of-line (EOL)
conventions 15, 25
markers 14, 26, 30, 31, 36, 37, 38, 67, 70, 71
End placement attribute 847, 852, 861
End ruby text alignment 857
End text alignment 853
endbfchar operator (PostScript) 422, 424, 443
endbfrange operator (PostScript) 422, 443
endcidchar operator (PostScript) 422, 424
endcidrange operator (PostScript) 422
endcmap operator (PostScript) 422
endcodespacerange operator (PostScript) 422, 424, 443,
444
EndIndent standard structure attribute 824, 845, 852
endnotdefchar operator (PostScript) 422, 425
endnotdefrange operator (PostScript) 422, 425
endobj keyword 40, 78, 921
EndOfBlock entry (CCITTFaxDecode filter parameter
dictionary) 55
EndOfLine entry (CCITTFaxDecode filter parameter
dictionary) 55
endrearrangedfont operator (PostScript) 422
endstream keyword 36-37, 38, 921, 1006
endusematrix operator (PostScript) 422
entries, dictionary 35
Entrust.PPKEF signature handler 686
Entrust.PPKEF public-key security handler 104
enumerated color spaces (JPEG2000) 64
enveloped data (PKCS#7) 105
eoclip operator (PostScript) 916
EOD. See end-of-data
EOF. See end-of-file
eofill operator (PostScript) 913, 914
EOL. See end-of-line
EPS. See Encapsulated PostScript
eq operator (PostScript) 149, 918
error reporting (Acrobat) 1002-1003, 1004, 1007, 1008,
1011, 1012, 1013, 1017, 1018, 1020, 1022, 1023,
1030
escape character 30
escape sequences 30-31, 96
backslash (
\) 30, 379
backspace (BS) 30
carriage return (CR) 30
form feed (FF) 30
horizontal tab (HT) 30
left parenthesis (
() 30, 379
line feed (LF) 30
octal character code 30, 31
right parenthesis (
)) 30, 379
Unicode natural language escape 132, 865, 871, 872,
873
ET operator 166, 371, 375, 641, 779, 841, 914
ETen character set 413
ETenB5H predefined CMap 413, 416
ETenB5V predefined CMap 413, 416
ETenmsB5H predefined CMap 413, 416
ETenmsB5V predefined CMap 413, 416
EUC-CN character encoding 412, 413
EUCH predefined CMap 414, 417
EUC-JP character encoding 414
EUC-KR character encoding 415
EUCV predefined CMap 414, 417
EUC-TW character encoding 413
euro character 928
even-odd rule 203-204
clipping 205, 916
filling 200, 202, 913, 914
Event entry (usage application dictionary) 352, 353, 356
event types
Export 352, 353, 356
Print 352, 353, 356
View 352, 353, 355, 356
events, trigger
See trigger events
EX operator 127, 166, 339, 914
examples
abbreviation expansion 873
alternate image 317-318
appearance dictionary 579
article 561-562
CalGray color spaces 217
CalRGB color space 219
character encoding 397-398
Index
1110
check box field 648-649
choice field 657-658
CIDFont
FD dictionary 435
CIDFont,
W entry 410
CIDFont,
W2 entry 411
CMap 419-420, 420-421
conversion engine, internal name 889
cross-reference sections 71-72
cross-reference streams 79-81, 82, 87-91
crypt filters 110
DeviceCMYK color space, color specification 213
DeviceGray color space, color specification 212
DeviceN color space 246-249
DeviceRGB color space, color specification 212
dictionary syntax 35
document catalog 117
document information dictionary 773
document outline 556
duotone color spaces (
DeviceN) 249-252
embedded font program 438
embedded go-to actions 619-621
file specification string 152
file trailer 74
filter pipeline 41
font definition 359-360
font descriptor,
Style entry 432
form XObject 330
glyph positioning 364-365
go-to action 616
graphics state parameter dictionaries 193-194
hybrid-reference files 87-91
ICCBased color space 226-227
image coordinate system, transformation of 309
incremental updates 992-1000
Indexed color space 233
indirect object reference 40
indirect object specification 40
inline image 324-325
JBIG2 encoding 58-60
Lab color space 222
language specification hierarchy 866, 867-868, 868-
869
Linearized PDF 943-946
link annotation 588
link element (Tagged PDF) 837-838
logical structure 806-811
LZW (Lempel-Ziv-Welch) encoding 48-49
marked content and clipping 780-781, 781, 782-784
marked-content reference 792
marked-content identifiers 791, 793
measure dictionary 709-710
multiple master font 386-387
name tree 136-138
NChannel color space 247-249
nonzero overprint mode 255-256
object streams 79-81, 87-91
optional content 341, 342
optional content membership dictionaries 338
outline hierarchy 988-992
output intent dictionary 901-902
page labels 559
page object 123
page tree 118-119, 983-988
partial field name 639
PDF files
graphics 980-983
minimal 975-977
text 978-980
presentation parameters 565-566
quadtone color space (
DeviceN) 252-254
radio button field 651-652
related files array 159-160
relative file specifications 153
replacement text 872
resource dictionary 129-130
reverse-order show string 819
sampled image 313-314
Separation color space 237-238
showing of text 359
stream, encoded 42-44
stream, indirect length specification 40-41
stream, unencoded 42-45
structure elements
finding from content items 798-801
form XObjects in 793-796
text annotation 586-587
text field 654-655
text, special graphical effects for 361-363
thumbnail image 557
tiling pattern, colored 265-268
tiling pattern, uncolored 269-271
tint transformation function 251-252
ToUnicode CMap 443-445
transfer function 455
TrueType font 388-389
Type 0 font 423
type 0 (sampled) function 144-145
Type 1 font 384-385
type 1 halftone 468
Type 3 font 393-395
type 3 (radial) shading 283-284
type 4 (PostScript calculator) function 150
type 5 halftone 476-478
unencrypted metadata 110
unique name specification (Web Capture) 880-881
URL specification 161
URLs, same path 887
user properties 806
watermark annotations 608
Index
1111
exch operator (PostScript) 149, 918
exclamation point (
!) character
in ASCII base-85 encoding 45, 46
ExclFKey field flag (submit-form field) 665
ExclNonUserAnnots field flag (submit-form field) 665
Exclude action
FieldMDP transform parameters 695
signature field lock dictionary 659
Exclusion blend mode 492
not white-preserving 536
exp operator (PostScript) 149, 917
Experimental annotation icon 598
expert character set, standard 923, 924, 929-931
expert fonts 396, 924
expiration date (Web Capture content set) 884, 885
Expired annotation icon 598
explicit destinations 551-552
for remote go-to actions 617
syntax 552
explicit masking 319, 321, 1013
and object shape 495, 517
simulation of 319
and soft masks 518
See also
image masks
exponential interpolation functions
See type 2 functions
Export annotation usage rights 694
Export entry (optional content usage dictionary) 351, 353
Export event type (usage application dictionary) 352, 353,
356
Export form usage rights 694
ExportFormat field flag (submit-form field) 663, 665, 666
exporting
FDF fields 669, 670, 673, 1026
interactive form fields 9, 634, 637, 638, 657, 658
Tagged PDF 842, 843, 845, 856
text 440, 820, 829
ExportState entry (Export subdictionary, optional content
usage dictionary) 351, 353
ExtRKSJH predefined CMap 414, 417
ExtRKSJV predefined CMap 414, 417
Extend entry
type 2 shading dictionary 279, 280
type 3 shading dictionary 281, 282
Extends entry (object stream dictionary) 77, 78
extensibility of documents 18
Extensible Markup Language (XML) 1.1 (World Wide Web
Consortium) 666, 865, 1063
Extensible Stylesheet Language (XSL) 1.0 (World Wide Web
Consortium) 821, 1063
extent, stream 37
external objects (XObjects) 165, 302, 1013
in logical structure elements 796
and marked content 782
as named resources 129, 165
painting 302, 914
in structural parent tree 786
subtypes. See XObject subtypes
in Web Capture content database 875
See also
form XObjects
group XObjects
image XObjects
PostScript XObjects
reference XObjects
transparency group XObjects
XObject operator
external streams 37, 38, 41, 1006
digital identifiers, not used in 1031
ExternalOPIdicts entry (legal attestation dictionary) 702
ExternalRefXobjects entry (legal attestation dictionary)
702
ExternalStreams entry (legal attestation dictionary) 702
ExtGState entry
resource dictionary 129, 189, 190
type 2 pattern dictionary 272, 528
ExtGState object type 190
ExtGState resource type 129, 189, 190
extraction of document content
See content extraction
Extreme
®
printing systems 1027
F
F entry
additional-actions dictionary 613
annotation dictionary 571, 573, 611, 677, 678, 896, 904
FDF dictionary 665, 673, 1025, 1026
FDF field dictionary 677
FDF named page reference dictionary 681
file specification dictionary 155, 161
import-data action dictionary 668, 1025
inline image object 323
launch action dictionary 622
media offset frame dictionary 732
media play parameters dictionary 721
media play parameters
MH/BE dictionaries 726
media screen parameters
MH/BE dictionaries 729, 729
movie dictionary 741
number format dictionary 707
Index
1112
outline item dictionary 556
projection dictionary 760, 761
reference dictionary 332
remote go-to action dictionary 553, 617
stream dictionary 38, 739
submit-form action dictionary 662
thread action dictionary 553, 623
thread dictionary 561
user property dictionary 805
version 1.3 OPI dictionary 908, 1033
version 2.0 OPI dictionary 911, 1033
Web Capture command dictionary 886
Windows launch parameter dictionary 622
f keyword 70, 997
F operator 166, 200, 914
f operator 12, 166, 199, 200, 202, 914
and current color 206
ending path 195
and graphics state parameters 180
and patterns 259, 262, 265, 269, 273
and subpaths 202
F trigger event (form field) 613, 614
f* operator 166, 200, 202, 914
facsimile compression, CCITT
See compression, CCITT facsimile
Fade transition style 564
false (boolean object) 28
false operator (PostScript) 149, 918
fauxing of fonts 905, 1014
fax compression, CCITT
See compression, CCITT facsimile
FB entry (icon fit dictionary) 679, 1026
FD dictionaries
See CIDFont
FD dictionaries
FD entry
CIDFont font descriptor 432
number format dictionary 708
FDecodeParms entry (stream dictionary) 38, 42
FDF. See Forms Data Format
FDF annotation dictionaries 674, 681
FDF catalog 671, 672-676, 1025
FDF entry 673
Sig entry 673, 685
Version entry 671, 673, 1025
FDF dictionary 672-675, 1026
Annots entry 674
Differences entry 664, 674
EmbeddedFDFs entry 675
Encoding entry 674, 1025
F entry 665, 673, 1025, 1026
Fields entry 673, 674
ID entry 673, 1025
JavaScript entry 675
Pages entry 674, 679
Status entry 674, 1025
Target entry 675
FDF entry (FDF catalog) 673
FDF field dictionaries 673, 676-678
A entry 678
AA entry 678
AP entry 678, 1026
APRef entry 678
ClrF entry 678
ClrFf entry 677
F entry 677
Ff entry 677
field dictionaries, compared with 676, 677
IF entry 678, 678
Kids entry 677
Opt entry 674, 678
RV entry 678
SetF entry 677
SetFf entry 677
T entry 677, 1026
in template pages 680
V entry 654, 674, 677, 1026
widget annotation dictionaries, compared with 676
FDF fields
See fields, FDF
FDF files
body 670, 671-672
cross-reference table 670
document structure 670
file name extension (Windows and Unix) 670
file type (Mac OS) 670
generation numbers in 670
header 670, 671, 673, 1025
in import-data actions 668, 1025, 1026
incremental updates not permitted in 670
object numbers in 670
source file 673
structure 670-672
in submit-form actions 1026
target file 673
trailer 670, 672
version specification 670, 671, 673, 1025
FDF named page reference dictionaries 678, 680, 680-681
F entry 681
Name entry 681
FDF page dictionaries 674, 679-680
Info entry 680
Templates entry 680
FDF page information dictionaries 680
FDF template dictionaries 680
Fields entry 680
Index
1113
Rename entry 680, 1027
TRef entry 680, 680
FDF trailer dictionary 672
Root entry 672
Federal Information Processing Standards Publications
1060
Ff entry
certificate seed value dictionary 661
FDF field dictionary 677
field dictionary 637, 638, 647, 653, 656, 666, 677
signature field seed value dictionary 659, 661
time stamp dictionary 660
FFilter entry (stream dictionary) 38, 41
field dictionaries 634, 636-646
AA entry 610, 638
DA entry 635, 640, 641, 645, 654
DS entry 640, 646
DV entry 638, 639, 648, 666
FDF field dictionaries, compared with 676, 677
Ff entry 637, 638, 647, 653, 656, 666, 677
FT entry 637, 639, 658
Kids entry 637, 650, 651, 653
Parent entry 637
Q entry 635, 640, 641, 645
in reset-form actions 667
RV entry 640, 645, 646, 653
in submit-form actions 663, 665
T entry 637, 638, 639, 658
TM entry 637, 664
TU entry 637, 871
V entry 638, 639, 645, 648, 651, 654, 657, 658, 663, 666,
683, 685
for variable-text fields 640
widget annotation dictionaries, merged with 603, 634,
658
field flags 638, 677
NoExport 638, 663, 666
ReadOnly 574, 638
Required 638
See also
button field flags
choice field flags
reset-form field flag
signature flags
submit-form field flags
text field flags
field hierarchy 636, 637
FDF 673, 680
inheritance of attributes 634, 636
in Linearized PDF 956
and reset-form actions 667
and submit-form actions 663, 665
field names 638-639, 1023
alternate 637, 870-871
fully qualified. See fully qualified field names
mapping name 637, 664
partial 637, 638-639, 677, 1023
renaming 680, 1027
in submit-form actions 663, 664, 666
field types 647-661
Btn 637, 648, 651
Ch 637
Sig 637, 658
Tx 637, 642
field values 638, 677
for check box fields 648
for choice fields 656, 657
and default appearance strings 641
and dynamic appearance streams 642
for FDF fields 674
for radio button fields 651
for signature fields 658
in submit-form actions 663, 664, 665, 666
for text fields 653, 654
FieldMDP transform method 685, 689, 690, 695, 696
FieldMDP transform parameters dictionaries
Action entry 695
Fields entry 695, 695
Type entry 695
V entry 695
fields, FDF 676-679, 1026
actions for 678
additional-actions dictionary 678
default appearance strings 678
exporting 669, 670, 673, 1026
hierarchy. See field hierarchy
importing 669, 670, 673, 675, 676, 677, 680, 1025, 1026
name. See field names
renaming 680, 1027
root 673
value. See field values
fields, interactive form 9, 634
access permissions for 97, 99, 100
additional-actions dictionary 638
computation order 613, 635
default appearance string 640, 641-642
default value 638, 666
dynamic appearance streams 603, 634
exporting 9, 634, 637, 638, 657, 658
file-select controls 653, 654
flags. See field flags
Form standard structure type 841
formatting 613, 614
and hide actions 628
hierarchy. See field hierarchy
importing 9, 634
inheritance of attributes 634, 636
Index
1114
and JavaScript actions 668
mapping name 637, 664
name. See field names
nonterminal 637
quadding 640, 641
read-only 638
recalculation 613, 614, 635
root 635, 680
terminal 634, 637
trigger events for 612-613, 614, 638
type. See field types
unique name (Web Capture) 879, 880, 881
validation 613, 614
value. See field values
variable text. See variable text
See also
button fields
check box fields
choice fields
combo box fields
field dictionaries
list box fields
pushbutton fields
radio button fields
signature fields
text fields
widget annotations
Fields entry
FDF dictionary 673, 674
FDF template dictionary 680
FieldMDP transform parameters dictionary 695, 695
interactive form dictionary 635
reset-form action dictionary 667
signature field lock dictionary 659, 659
submit-form action dictionary 663, 665, 666
Figure standard structure type 841
standard layout attributes for 845, 853, 860
file attachment annotation dictionaries 600
FS entry 600
Name entry 600
Subtype entry 600
file attachment annotations 9, 157, 581, 600
See also
file attachment annotation dictionaries
file body
FDF 670, 671-672
PDF 66, 69, 975, 992
File Format for Color Profiles (International Color
Consortium) 1060
file formats
ACFM (Adobe Composite Font Metrics) 366
Acrobat
®
products, native 1005, 1012
Adobe Type 1. See Type 1 fonts
AFM (Adobe Font Metrics) 366, 386, 1058
AIFF (Audio Interchange File Format) 739, 1028
AIFF-C (Audio Interchange File Format,
Compressed) 739
ASCII (American Standard Code for Information
Interchange). See ASCII
AU (NeXT/Sun Audio Format) 1028
AVI (Audio/Video Interleaved) 1028
CFF (Compact Font Format) 6, 436, 437, 438
CGI (Common Gateway Interface) 878
CSS (Cascading Style Sheets) 821, 824, 843
DVI (Device Independent) 19
FDF (Forms Data Format). See Forms Data Format
GIF (Graphics Interchange Format) 770, 873, 874, 875,
876, 879
HPGL (Hewlett-Packard Graphics Language) 19
HTML (Hypertext Markup Language)
See
HTML
HTML Form format
JDF (Job Definition Format) 448, 891, 903, 906, 1032
JPEG (Joint Photographic Experts Group) 770, 873
MIDI (Musical Instrument Digital Interface) 1028
MOV (QuickTime) 1028
MP3 (MPEG Audio Layer-3) 1028
MP4 (MPEG-4) 1028
MPEG (MPEG-2 Video) 1028
OEB (Open eBook) 821, 843
OpenType. See OpenType fonts
PCL (Printer Command Language) 19
PDF/X (Portable Document Format, Exchange) 898,
899, 900
PJTF (Portable Job Ticket Format) 24, 448, 891, 903,
906, 1032
PostScript. See PostScript
®
page description language
RIFF (Resource Interchange File Format) 739
RTF (Rich Text Format) 812, 821, 824, 827, 843, 844
SGML (Standard Generalized Markup Language) 784
SMIL (Synchronized Multimedia Integration
Language) 1028
snd 739
SWF (Macromedia Flash) 1028
TIFF (Tag Image File Format) 47, 51, 911
TrueType. See TrueType fonts
XSL (Extensible Stylesheet Language) 821, 824
file header
FDF 670, 671, 673, 1025
PDF 66, 68-69, 75, 114, 1002, 1003, 1004, 1008, 1010
file identifiers 769, 775-776, 1031
encryption 101, 102
FDF 673
file specifications 156
file trailer 74
reference XObjects 332
Index
1115
file names
compatibility 154
DOS/Windows 154
drive identifier 153
empty 152
extension 154, 159, 670
and file identifiers 775
in file-select controls 653, 654
in file specifications 152
Mac OS 154
network resource name 153
platform-dependent 152, 153-154
server name 153
volume name 153
file-select controls 653, 654
file specification dictionaries 155-156, 161
Desc entry 156, 157, 600, 1021
DOS entry 155, 156
EF entry 156, 157, 162
F entry 155, 161
FS entry 155, 161
ID entry 156
Mac entry 155, 156
RF entry 156, 159, 162
Type entry 155, 156, 162
Unix entry 155, 156
V entry 156
file specification strings 152-155
DOS 156
Mac OS 156
UNIX 156
file specifications 151-162
absolute 152-153
conversion to platform-dependent file names 153-154
dictionaries. See file specification dictionaries
as dictionary values 131
embedded file streams 157-160, 675
in file-select controls 654
full 151
maintenance 161-162
for movie files 741
multiple-byte strings in 155
related files arrays 156, 159-160, 162
relative 152-153, 1025, 1026
simple 151
for sound files 739, 1022
strings. See file specification strings
URL 152, 161, 662
volatile files 156
file streams, embedded
See embedded file streams
file structure
FDF 670-672
PDF 66-75, 1008-1009
file systems 155
CD-ROM 154
handlers 937
hierarchy 153
local 151
naming conventions 151, 154
plug-in extensions for 937
URL 155
URL-based 152
file trailer
FDF 670, 672
hybrid-reference files 86
Linearized PDF 944, 948-949, 949, 956
PDF 67, 72-74, 75, 1008
example 975, 992, 993, 995, 998, 1000
See also
file trailer dictionary
file trailer dictionary 73-74, 86
custom data prohibited in 937
Encrypt entry 73, 91, 949
ID entry 74, 101, 102, 673, 775, 1009, 1031
Info entry 73, 771
Prev entry 73, 75, 84, 86, 87, 948, 956, 993, 995, 998,
1000
Root entry 68, 73, 83, 112, 949
Size entry 73, 83, 86, 949, 956
XRefStm entry, hybrid-reference file 74, 86, 86, 87, 88
file type (Mac OS) 159, 670
FileAttachment annotation type 581, 600
files
attached. See file attachment annotations
binary 15, 25
CIDFont 405
CMap. See CMap files
creator signature (Mac OS) 159
FDF. See FDF files
file type (Mac OS) 159, 670
file-select controls. See file-select controls
font. See font files
formats. See file formats
hybrid-reference 85
movie 741
related 159-160, 162
remote go-to action, target of 617
resource fork (Mac OS) 159
sampled image 908, 911
sound 739
specifications 131, 151-162, 654
text 15, 25
thread action, target of 623
URL specifications 152, 161, 662
volatile 156
FileSelect field flag (text field) 653, 654
Index
1116
Filespec object type 155, 162
fill operator (PostScript) 913, 914
FillIn form usage rights 694
filling
color. See nonstroking color, current
color space. See nonstroking color space, current
even-odd rule 200, 202, 203-204, 913, 914
glyphs 371, 439, 1014
nonzero winding number rule 200, 202, 202-203, 913,
914
paths 12, 163, 164, 184, 200, 202-204, 913, 914, 915,
980
scan conversion 480-481
text 12, 164, 371
text rendering mode 371, 439, 1014
and transparent overprinting 536, 538-539, 541
Filter entry
encryption dictionary 92, 92, 101, 104
inline image object 323
signature dictionary 686, 697
signature field seed value dictionary 660, 661
stream dictionary 38, 41, 83, 437, 522, 740
filter parameter dictionaries 38, 42
See also
CCITTFaxDecode filter parameter dictionaries
Crypt filter parameter dictionaries
DCTDecode filter parameter dictionaries
FlateDecode filter parameter dictionaries
JBIG2Decode filter parameter dictionaries
LZWDecode filter parameter dictionaries
filters 37, 38, 41-62, 1006-1008
abbreviations for 323-324, 1006-1007
ASCII 42, 45-46
compression 15, 22, 740
in content streams 126, 1004, 1007
decoding 41-62, 96, 951, 1006-1008
decompression 42, 47-62
in embedded font programs 437, 438, 1007
encoding 96
in form XObjects 1007
in image streams 310, 1007
in inline images 324, 1007
metadata streams, not recommended for 773
parameters. See filter parameter dictionaries
pipeline 41
standard 43
in thumbnail images 1007
in Type 3 glyph descriptions 1007
unrecognized 1007
See also
ASCII85Decode filter
ASCIIHexDecode filter
CCITTFaxDecode filter
Crypt filter
DCTDecode filter
FlateDecode filter
JBIG2Decode filter
JPXDecode filter
LZWDecode filter
RunLengthDecode filter
Final annotation icon 598
Find command (Acrobat) 1007
findfont operator (PostScript) 303
Fingerprint authentication method (digital signatures) 688
fingerprints (user authentication) 684
first-class names 158, 937-938
First entry
object stream dictionary 77
outline dictionary 554
outline item dictionary 555
FirstChar entry
Type 1 font dictionary 384, 384, 386, 1016
Type 3 font dictionary 390
first-page cross-reference table (Linearized PDF) 944, 948,
949, 960
document-level objects indexed by 949
hint streams in 950
linearization parameter dictionary in 946
and main cross-reference table 956
startxref line and 956, 969
FirstPage named action 628
See also named-action dictionaries
first-page section (Linearized PDF) 945, 952-954, 961,
1034
and primary hint stream, ordering of 950, 952, 969,
970
first-page trailer (Linearized PDF) 944, 948-949, 949
fit attribute (SMIL) 726
FitWindow entry (viewer preferences dictionary) 548
fixed-pitch fonts 363, 429
fixed print dictionaries 606, 607
H entry 607
Matrix entry 607
Type entry 607
V entry 607
FixedPitch font flag 429, 821, 822
FixedPrint entry (watermark annotation dictionary) 606,
607
FixedPrint object type 607
FL entry (graphics state parameter dictionary) 192, 478,
702
Fl filter abbreviation 324, 1007
flags
See
access flags
Index
1117
annotation flags
button field flags
choice field flags
edge flags
field flags
font flags
outline item flags
reset-form field flag
signature flags
submit-form field flags
text field flags
Web Capture command flags
Flags entry
font descriptor 427, 429, 430, 821, 822
reset-form action dictionary 667, 667
submit-form action dictionary 663, 665
Flate (zlib/deflate) compression 15, 43, 47-53
predictor functions 47, 50, 51-53, 310
FlateDecode filter 43, 47-53, 226, 1009
Fl abbreviation 324, 1007
parameters. See
FlateDecode filter parameter dictionar-
ies
predictor functions 51-53
in sampled images 310
FlateDecode filter parameter dictionaries 49-50
BitsPerComponent entry 50
Colors entry 50
Columns entry 50
Predictor entry 50, 51-52
flatness tolerance 183, 478-479
FL entry (graphics state parameter dictionary) 192, 478
i operator 189, 478, 914
and smoothness tolerance, compared 480
floating elements 826, 847, 852, 852
bounding box 824
floating window parameters dictionaries 730-731
D entry 730
O entry 730, 731
P entry 730, 731
R entry 730, 731
RT entry 730, 731
T entry 731
TT entry 731
Type entry 730
UC entry 731
floating windows
movies 626, 743
multimedia 729-731, 1029
floor operator (PostScript) 149, 917
Fly transition style 563, 564, 565
Fo entry (additional-actions dictionary) 611
Fo trigger event (annotation) 611
focus, input
See input focus
fold marks 893
folios 815
FOND resource (Mac OS) 388
font characteristics 813, 820-821
Italic 821
Proportional 821
Serifed 821
Smallcap 821
font CSS2 style attribute (rich text strings) 644
font descriptors 16, 382-383, 426-435, 978, 1017
Ascent entry 427, 856
AvgWidth entry 428
CapHeight entry 427
CharSet entry 428, 440
for CIDFonts. See CIDFont font descriptors
Descent entry 427, 856
embedded font programs 428, 436
FD dictionary. See CIDFont FD dictionaries
Flags entry 427, 429, 430, 821, 822
flags. See font flags
for font subsets 389, 1016
FontBBox entry 427
FontFamily entry 426, 822
FontFile entry 428, 436, 437, 954
FontFile2 entry 428, 436
FontFile3 entry 408, 428, 436, 438, 1017
FontName entry 389, 426, 428, 432
FontStretch entry 426, 822
FontWeight entry 427, 822
ItalicAngle entry 427
Leading entry 427
in Linearized PDF 953, 954
MaxWidth entry 428
MissingWidth entry 384, 428
StemH entry 427
StemV entry 427, 822
Style dictionary. See CIDFont Style dictionaries
for TrueType fonts 428
Type 0 fonts, lacking in 426
for Type 1 fonts 384, 428
Type 3 fonts, lacking in 426
Type entry 426
XHeight entry 427
font dictionaries 36, 357, 358, 381-382, 382
BaseFont entry 426
compact fonts 439
encoding 395, 396
font matrix 173
glyph metrics in 363, 364
metadata inapplicable to 775
as named resources 129, 359
in PostScript 382
Index
1118
standard fonts 386
Subtype entry 36, 358, 381
text font parameter 191
ToUnicode entry 441
in trap networks 905
Type entry 36
Widths entry 428
See also
CIDFont dictionaries
multiple master font dictionaries
TrueType font dictionaries
Type 0 font dictionaries
Type 1 font dictionaries
Type 3 font dictionaries
Font entry
graphics state parameter dictionary 191
resource dictionary 129, 303, 359, 368, 383, 406, 635,
641
font files 358, 436
embedded 358
external 357, 358
in font descriptors 383, 953
metadata 775
font flags 396, 427, 429-431
AllCap 429
FixedPitch 429, 821, 822
ForceBold 429, 430, 822
Italic 429, 821, 822
Nonsymbolic 429
Script 429, 822
Serif 429, 821, 822
SmallCap 429, 821, 822
Symbolic 429
font management 382
font matrix 173, 364, 390
rotation 391
and Type 3 glyph descriptions 391
font names 359
conventions 382
font subsets 389
multiple master 387
PostScript 381, 383, 386, 388-389, 423, 426
Type 0 fonts 423
Type 1 fonts 383
Type 3 fonts 390
Font Naming Issues (Adobe Technical Note #5088) 387,
1058
font numbers 404, 412, 418, 422, 423, 424
Font object type 36, 383, 390, 407, 423, 978
font programs 357, 358, 381, 382, 389
compact 436, 438-439
copyright permissions 436
embedded. See embedded font programs
encoding 382
external 382
font dictionaries, defined in 359
glyph metrics in 363, 364, 384
hints 383, 390
multiple master 386
in PostScript 382
TrueType 387
Type 1 383, 387, 1014-1015
Font resource type 129, 303, 359, 368, 383, 406, 635, 641,
953
font selector attributes (Tagged PDF) 821-822
FontFamily 822
FontSize 822
FontStretch 822
FontStyle 822
FontVariant 822
FontWeight 821, 822
GenericFontFamily 822
font stretch
Condensed 426
Normal 426
font subsets 389, 1016
BaseFont entry 389, 1016
character set 428
embedded 16, 440
font descriptors for 389, 1016
merging 389
name 389
PostScript name 389, 407
tag 389, 428, 432, 1016
font subtypes
See font types
font types 358, 381
MMType1 381, 386, 436
TrueType 36, 381, 388, 436, 437
Type0 381, 403, 423
Type1 36, 381, 383, 436, 437
Type3 381, 390
See also
CIDFont types
FontBBox entry
font descriptor 427
Type 3 font dictionary 390
FontDescriptor entry
CIDFont dictionary 407
Type 1 font dictionary 384, 384, 386, 1016
Type 3 font dictionary 391
FontDescriptor object type 426
FontDescriptor resource type 953
font-family CSS2 style attribute (rich text strings) 644
FontFamily entry (font descriptor) 426, 822
FontFamily font selector attribute 822
Index
1119
FontFauxing entry (trap network annotation dictionary)
905
FontFile entry (font descriptor) 428, 436, 437, 954
FontFile2 entry (font descriptor) 428, 436
FontFile3 entry (font descriptor) 408, 428, 436, 438, 1017
FontMatrix entry (Type 3 font dictionary) 364, 390, 391
FontName entry
font descriptor 389, 426, 428, 432
Type 1 font program 383
fonts 12, 23, 357, 358, 381-440, 978
all-cap 429
for appearance streams 635
ascent 427
availability 382
average glyph width 428
bounding box 390, 392, 393, 427, 914
cap height 427
CFF (Compact Font Format) 6, 436, 437, 438
character collections 404
character sets 358, 395-396, 404
characteristics. See font characteristics
CJK (Chinese, Japanese, and Korean) 389
content streams 126
current 12, 359, 360, 403
data structures 357, 381-382
descent 427
descriptor 16, 382-383
encoding. See character encodings
expert 396, 924
family 426
fauxing 905
files. See font files
fixed-pitch 363, 429
flags. See font flags
formats 16
glyph selection 382
glyph space 173, 364, 390, 427
glyphs in 25
in Linearized PDF 954, 972
interpreter 382, 383
italic 429
italic angle 427
kerning information 366
leading 427
management 15-16
matrix 173, 364, 390, 391
maximum glyph width 428
metadata for 775
metrics 15, 16, 21, 22, 363-366, 383, 384, 386, 426
monospaced 363
multiple master 386-387, 1017
name. See font names
nonsymbolic 396, 397, 400, 429, 430
number 404, 412, 418, 422, 423, 424
organization and use 358
PostScript files 22
proportional 363, 429
resources 359, 368
sans serif 429
scaling 360, 368
script 429
selection 357, 360
serifed 429
size 360
small-cap 429
standard. See standard 14 fonts
stem height 427
stem width 427
stretch 426
style information 16
subsets 16, 389, 440, 1016
substitution 15, 16, 22, 382, 386, 426, 433, 953, 954,
972, 1014, 1017
subtype. See font types
symbolic 396, 397, 429, 430
Tagged PDF, determination of characteristics in 820-
822
and text operators 163
type. See font types
variable-pitch 363, 429
weight 427
x height 427
See also
CID-keyed fonts
composite fonts
font descriptors
font dictionaries
font programs
simple fonts
TrueType
®
fonts
Type 0 fonts
Type 1 fonts
Type 3 fonts
Type 42 fonts
font-size CSS2 style attribute (rich text strings) 644
FontSize font selector attribute 822
font-stretch CSS2 style attribute (rich text strings) 644
FontStretch entry (font descriptor) 426, 822
FontStretch font selector attribute 822
font-style CSS2 style attribute (rich text strings) 644
FontStyle font selector attribute 822
FontVariant font selector attribute 822
font-weight CSS2 style attribute (rich text strings) 644
FontWeight entry (font descriptor) 427, 822
FontWeight font selector attribute 821, 822
footnotes
as BLSEs 829, 830
Index
1120
marked content 778
Note standard structure type 835
and page content order 817
placement of 835
as structure elements 787, 789
Tagged PDF 784
ForceBold font flag 429, 430, 822
ForComment annotation icon 598
form actions
See
import-data actions
JavaScript actions
reset-form actions
submit-form actions
form data (XFA forms) 681
form dictionaries 326, 327-330, 1013
for dynamic appearance streams 640-641
See also
printer’s mark form dictionaries
type 1 form dictionaries
Form entry (UR transform parameters dictionary) 694
form feed (FF) character 26, 32
escape sequence for 30
form fields
See fields, interactive form
form matrix 173, 327, 328
form space 173, 261, 327
and dynamic appearance streams 640
Form standard structure type 818, 836, 841
standard layout attributes for 845, 853, 860
form template (XFA forms) 681
form types 327
type 1 327-330
Form XObject subtype 302, 328
form XObjects 165, 302, 325-334, 524
and 3D artwork 758-759
annotation appearances 326, 577, 640, 896
annotation icons 604, 605
bounding box 328, 640
clipping to bounding box 327, 328
content stream 126, 325, 326, 327, 813, 814
defining 326
dictionaries. See form dictionaries
form matrix 173, 327, 328
form space 173, 261, 327, 640
form type 327
for importing content 326
and interactive forms, distinguished 325, 634
in logical structure elements 793-796
marked-content sequences in 792
metadata 329
modification date 329, 777
name 330
as OPI proxies 907, 1033
OPI version dictionary 329
optional content in 330, 344
page-piece dictionary 329
as page templates 326
painting 326, 327, 526, 527
patterns and 261
private data associated with 776, 777
for repeated graphical elements 326
resource dictionary 328, 905
resources 128, 328
soft masks 326
transparency groups 326, 1004
trap networks 903, 906
unrecognized filters in 1007
uses 326
See also
group XObjects
reference XObjects
transparency group XObjects
FormEx entry (UR transform parameters dictionary) 694
forms
See
form XObjects
interactive forms
Forms Data Format (FDF) 669-681
annotations in 669, 670, 674
catalog. See FDF catalog
differences stream 674
digital signatures 674
encryption 675
exporting 669, 670, 673, 694, 1026
fields. See fields, FDF
in file-select controls 654
files. See FDF files
in import-data actions 662, 667, 669
importing 669, 670, 673, 675, 676, 677, 680, 694, 1025,
1026
objects 670
options 674, 678
pages 679-681, 1027
PDF, compared with 670
PDF syntax 24, 670
in submit-form actions 663, 664, 665, 666, 674, 1024
template pages 680-681, 1027
trailer. See FDF trailer dictionary
and trigger events 614
version specification 670, 671, 673, 1025
See also
FDF annotation dictionaries
FDF dictionary
FDF field dictionaries
FDF named page reference dictionaries
Index
1121
FDF page dictionaries
FDF template dictionaries
FormType entry (form dictionary) 328
Formula standard structure type 841
standard layout attributes for 845, 853, 860
ForPublicRelease annotation icon 598
FOV entry (projection dictionary) 760, 761, 762
FP entry (additional-actions dictionary, obsolete) 1021
“fpgm” table (TrueType font) 439
FrameMaker
®
document publishing software 772
free-form Gouraud-shaded triangle meshes
See type 4 shadings
free text annotation dictionaries 589
CL entry 589
Contents entry 582
DA entry 589, 645
DS entry 589, 645
IT entry 589
Q entry 589
RC entry 589
Subtype entry 589
free text annotations 580, 582, 588-589
callouts 589
contents 582
default appearance string 589
intent 589
quadding 589
rich text 589
and text annotations, compared 588
See also
free text annotation dictionaries
FreeText annotation type 580, 589
FreeTextCallout annotation intent 589
FreeTextTypeWriter annotation intent 589
frequency (halftone screen) 458, 466, 467, 468, 470, 472
Frequency entry (type 1 halftone dictionary) 467
“from CIE” information (ICC color profile) 225, 900
FS entry
file attachment annotation dictionary 600
file specification dictionary 155, 161
FT entry (field dictionary) 637, 639, 658
FTP (File Transfer Protocol) 878
Fujitsu FMR character set 414
full file specifications 151
FullSave document usage rights 693
FullScreen page mode 115, 548
fully opaque objects 542-543
fully qualified field names 638-639
for FDF fields 676, 1026
in hide actions 628
in reset-form actions 667
in submit-form actions 663, 665, 666
function-based shadings
See type 1 shadings
function dictionaries 140-141
Domain entry 141, 142, 146, 147, 150
FunctionType entry 141
Range entry 141, 142, 144, 146, 150
See also
type 0 function dictionaries (sampled)
type 2 function dictionaries (exponential interpola-
tion)
type 3 function dictionaries (stitching)
type 4 function dictionaries (PostScript calculator)
Function entry
shading dictionary 276, 277
type 1 shading dictionary 278
type 2 shading dictionary 279, 280
type 3 shading dictionary 281, 282
type 4 shading dictionary 285, 286, 288
type 5 shading dictionary 290
type 6 shading dictionary 294, 296
function objects 139, 140, 276, 455
function types 140-141
type 0 (sampled) 140, 141, 142-145, 1011
type 2 (exponential interpolation) 140, 141, 146, 1011
type 3 (stitching) 141, 147-148, 1012
type 4 (PostScript calculator) 141, 148-151, 1012
functions 139-151
black-generation 453
clipping to domain 141, 143
clipping to range 141, 144
color (shadings). See color functions
color mapping 449
decoding 214, 216, 217, 219, 221
dictionaries. See function dictionaries
as dictionary values 131
dimensionality 141, 142
domain 140, 141, 142, 143, 147-148, 278, 279, 281,
285, 290, 294
function objects 139, 140, 276, 455
gamma 216, 217, 219, 530
gamut mapping 218, 449, 454
interpolation 284
range 140, 141, 142, 143, 144
spot. See spot functions
tint transformation. See tint transformation functions
transfer. See transfer functions
type. See function types
undercolor-removal 453
See also
type 0 functions (sampled)
type 2 functions (exponential interpolation)
type 3 functions (stitching)
type 4 functions (PostScript calculator)
Index
1122
Functions entry (type 3 function dictionary) 147
FunctionType entry (function dictionary) 141
Fundamentals of Interactive Computer Graphics (Foley and
van Dam) 1060
FWParams object type 730
FWPosition entry (movie activation dictionary) 743
FWScale entry (movie activation dictionary) 743, 1029
G
G color space abbreviation (inline image object) 323
G entry
soft-mask dictionary 521, 525
Web Capture command settings dictionary 888
G operator 166, 206, 210, 211, 212, 258, 259, 914
g operator 166, 206, 210, 211, 212, 258, 259, 306, 361, 914
gamma correction 206, 447, 454, 455, 456
CalGray color spaces 216
CalRGB color spaces 218
gamut mapping functions, distinguished from 454
Gamma entry
CalGray color space dictionary 216, 217
CalRGB color space dictionary 218, 218, 219, 515
gamma functions 216, 217, 219, 530
gamut
color space 220, 238, 449, 543, 544
device 230, 231, 449
source (page) 449
gamut mapping functions 218, 449
gamma correction, distinguished from 454
garbage collection 1031
GB 2312-80 character set 412, 413
GB 18030-2000 character set 413
GBEUCH predefined CMap 412, 416
GBEUCV predefined CMap 413, 416
GB18030-2000 character set 413
GBK character encoding 413, 1025
GBK character set 413
GBKEUCH predefined CMap 413, 416
GBKEUCV predefined CMap 413, 416
GBKpEUCH predefined CMap 413, 416
GBKpEUCV predefined CMap 413, 416
GBK2KH predefined CMap 413, 416
GBK2KV predefined CMap 413, 416
GBpcEUCH predefined CMap 413, 416
GBpcEUCV predefined CMap 413, 416
GDI (Graphics Device Interface) imaging model 19, 20
ge operator (PostScript) 149, 918
general graphics state operators 166
d 166, 189, 914
gs 166, 189, 192, 259, 367, 373, 448, 520, 914
i 166, 189, 478, 914
J 166, 189, 914
j 166, 189, 914
M 166, 189, 915
ri 166, 189, 230, 256, 259, 915
in text objects 375
w 166, 183, 189, 362, 916
general layout attributes 846-848
BackgroundColor 845, 848
BorderColor 845, 849, 850
BorderStyle 845, 849, 855
BorderThickness 845, 850
Color 845, 850
Padding 845, 848, 849, 850, 850, 855
Placement 826, 829, 833, 841, 842, 845, 846, 851, 852,
860, 861
WritingMode 824, 845, 848, 855, 863
generation numbers 39
attribute revision numbers, distinguished from 803
in cross-reference table 70, 71, 71, 921
and encryption 95
in FDF files 670
and incremental updates 75
in Linearized PDF 943
in updating example 992, 993, 997, 998
Generic character collections 417
Generic glyph class 433, 434
generic hint tables (Linearized PDF) 957, 966
generic hint tables, extended (Linearized PDF) 966-967
GenericFontFamily font selector attribute 822
GenericRot glyph class 434
“Geometrically Continuous Cubic Bézier Curves” (Seidel)
1059
Geschke, Chuck xxii
GET request (HTTP) 664, 884, 887
GetMethod field flag (submit-form field) 664, 664
GIF (Graphics Interchange Format) file format 770, 873,
874, 875, 876, 879
Glitter transition style 563, 564
“glyf” table (TrueType font) 437, 439, 440
glyph classes (CIDFonts) 432-435
Alphabetic 433, 434
AlphaNum 434
Dingbats 433, 434
DingbatsRot 434
Generic 433, 434
GenericRot 434
Hangul 434
Hanja 434
Hanzi 433
Index
1123
HKana 434
HKanaRot 434
HojoKanji 434
HRoman 433, 434
HRomanRot 433, 434
Kana 433, 434
Kanji 434
Proportional 433, 434
ProportionalRot 433, 434
Ruby 434
glyph coordinate system
See glyph space
glyph descriptions 357, 358
for character collections 405
and character encodings 395
in CID-keyed fonts 404, 405
in CIDFonts 406, 408
color 392, 393
in font subsets 16
and graphics state 392
restrictions on 259
text objects in 375
and
Tj operator 360
in TrueType fonts 399, 400, 401, 408, 416, 439
in Type 1 fonts 383
in Type 3 fonts 389, 390, 390, 391-392, 1007
glyph displacement 363, 365, 409
character spacing 368
in CIDFonts 410
displacement vector 365, 370
DW2 entry (CIDFont) 410-411
horizontal scaling 370
in right-to-left writing systems 818
simple fonts 382
text matrix, updating of 380
and text-positioning operators 377
text space 379
in Type 3 fonts 392, 393
W2 entry (CIDFont) 411
word spacing 369
glyph indices 409, 416
glyph names
glyph descriptions, TrueType 399, 401
.notdef 399
glyph orientation
Auto 858, 859
glyph origin 364
positioning 376, 410
in right-to-left writing systems 818, 819
and writing mode 365, 409
glyph space 173, 364, 390, 427
displacement vector 365
font descriptors expressed in 426
glyph widths 391
origin 364, 365, 376, 409, 410, 818, 819
text space, relationship with 364, 379, 390
and Type 3 glyph descriptions 392, 393
units 360, 364, 390
user space, mapping to 392, 856
glyph widths 363, 365
in CIDFonts 407, 409-410
CJK (Chinese, Japanese, and Korean) 410
d0 operator 392, 914
d1 operator 393, 914
default 407, 410
and horizontal scaling 370
in printing 1014
in reflow of content 1014
in right-to-left writing systems 818, 819
in searching of text 1014
in simple fonts 382
in Type 1 fonts 384, 1014-1015
in Type 3 fonts 391, 392, 392-393, 914
undefined 428
in viewing of documents 1014
GlyphOrientationVertical standard structure attribute 846,
858
glyphs, character 357, 358
Adobe imaging model 11
bold 430
bounding box 365
and characters, contrasted 25, 358
as clipping path 362, 371
descriptions. See glyph descriptions
displacement. See glyph displacement
emulating tiling patterns with 260
filling 371, 439, 1014
fixed-pitch 429
font management 16
in font subsets 1016
font substitution 15, 16
in fonts 358, 381, 382
indices 409, 416
italic 429
metrics 363-366, 382, 412
object shape 517
origin 364, 365, 376, 409, 410, 818, 819
painting 359, 360, 371-372, 538, 1014
position vector 365, 410-411
positioning 363-366, 376-377
in right-to-left writing systems 818
scaling 357, 368, 916
scan conversion 13, 14, 481
script 429
selection 382
serifs 429
shading patterns, painting with 273
Index
1124
size 360
small capitals 429
stencil masking 320
stroking 362, 371, 439, 1014
text knockout flag 193
text knockout parameter 373
in text objects 12
text operators 163
width. See glyph widths
go-to action dictionaries 616
D entry 616
S entry 616
go-to actions 615, 616
destination 551, 616
named destinations, targets of 553
and URI actions 588
See also
go-to action dictionaries
remote go-to actions
GoTo action type 615, 616
go-to-3D-view action dictionaries 633
S entry 633
TA entry 633
V entry 633
GoTo3DView action type 615, 633
go-to-3D-view actions 615, 632-633, 757
See also
go-to-3D-view action dictionaries
GoToE action type 615, 618
GoToR action type 615, 617
GoToRemote entry (legal attestation dictionary) 701
Gouraud interpolation 284, 288, 296, 1060
Gouraud-shaded triangle meshes
free-form. See type 4 shadings
lattice-form. See type 5 shadings
gradient fills 260
color conversion in 277
geometry independent of object painted 273
interpolation algorithms 276
sh operator 273
shading dictionaries 274
shading objects, defined by 272
smoothness tolerance 183
streams, defined by 276
in tiling patterns 273
Graph annotation icon 600
graphics 163-304, 975
and rendering, distinguished 164, 447
special text effects 361-363
three-dimensional. See 3D artwork
See also
clipping
color spaces
color values
coordinate systems
coordinate transformations
cubic Bézier curves
device space
external objects (XObjects)
graphics objects
graphics operators
graphics state
images, sampled
optional content
paths
patterns
rendering
text
transformation matrices
transparent imaging model
user space
Graphics Gems (Glassner, ed.) 1060
Graphics Gems II (Arvo, ed.) 1059
graphics objects 9, 11-12, 18, 164-168
artifacts 813
clipping of 195, 205
color spaces for 227
colors of 205, 225
in composite pages 897
compositing of 516, 527
coordinate spaces for 169, 170
coordinate transformations, unaffected by subsequent
177
in form XObjects 302, 325, 326, 327
in glyph descriptions 375, 390
in illustration elements (Tagged PDF) 841
in ILSEs (Tagged PDF) 860
invisible 782
logical structure, independent of 784
marked-content operators prohibited within 778
in marked-content sequences 778, 792
page content order 817
in pattern coordinate space 261, 263
rendering of 179, 448
shape (transparent imaging model) 204
in table cells (Tagged PDF) 859
in tiling patterns 260, 264, 528
in transparency groups 526
in transparent imaging model 534
and transparent overprinting 536
in trap networks 903, 906
types 164-165
visible 782, 782
graphics operators 163-164
in glyph descriptions 389, 390
in logical structure content 790
Index
1125
See also
clipping path operators
color operators
graphics state operators
inline image operators
path construction operators
path-painting operators
shading operator
text object operators
text-positioning operators
text-showing operators
text state operators
Type 3 font operators
XObject operator
graphics state 12, 163, 180-194
compatibility operators 127
and form XObjects 325, 327, 527
initialization 180, 527, 528
and marked-content sequences 778
and OPI proxies 907
page description level 166
parameter dictionaries 129
saving and restoring 184-185, 189, 196, 205, 264, 308,
327, 391, 527, 915
and shading patterns 272
stack 184-185, 189
and transparent patterns 528
and Type 3 glyph descriptions 392
See also
graphics state operators
graphics state parameter dictionaries
graphics state parameters
text state
graphics state operators 21, 163, 183, 184, 188-189
cm 166, 172, 180, 189, 308, 913
d 166, 189, 914
in default appearance strings 640, 641
general 166, 375
gs 166, 189, 192, 259, 367, 373, 448, 520, 914
i 166, 189, 478, 914
J 166, 189, 914
j 166, 189, 914
M 166, 189, 915
and marked-content operators 778
Q 166, 184, 189, 205, 264, 308, 327, 362, 372, 641, 782,
915, 920, 1033
q 166, 184, 189, 205, 264, 308, 327, 641, 782, 915, 920,
1033
ri 166, 189, 230, 256, 259, 915
special 166
w 166, 183, 189, 362, 916
graphics state parameter dictionaries 183, 189-194, 272,
914, 1004
AIS entry 193, 518
BG entry 191, 259, 453, 702
BG2 entry 191, 259, 453
BM entry 192, 516
CA entry 192, 519
ca entry 192, 519
D entry 190
FL entry 192, 478, 702
Font entry 191
HT entry 192, 259, 465, 702
LC entry 190
LJ entry 190
LW entry 183, 190
ML entry 190
as named resources 129
OP entry 191, 254, 702
op entry 191, 254
OPM entry 191, 255
RI entry 190, 230
SA entry 192, 482, 1018
SM entry 192, 479
SMask entry 192, 518
TK entry 193, 367, 373
TR entry 192, 259, 455, 702
TR2 entry 192, 259, 455
Type entry 190
UCR entry 191, 259, 453, 702
UCR2 entry 191, 259, 453
graphics state parameters 168, 180, 180-183
and
B operator 200
details 185-188
device-dependent 180, 182-183, 264, 448
device-independent 180, 180-182, 185
dictionaries. See graphics state parameter dictionaries
for filling 200
initialization 180, 527, 528
and
S operator 201
and sampled images 307
setting 189-190, 914-916
for shading patterns 272
for stroking 200, 201
transparency-related 528, 1018
See also
alpha source parameter
black-generation function
character spacing (T
c
) parameter
current alpha constant
current blend mode
current clipping path
current color
current color space
current halftone
current line width
current rendering intent
current soft mask
Index
1126
current transfer function
current transformation matrix (CTM)
flatness tolerance
horizontal scaling (T
h
) parameter
leading (T
l
) parameter
line cap style
line dash pattern
line join style
miter limit
overprint mode
overprint parameter
smoothness tolerance
stroke adjustment parameter
text font (T
f
) parameter
text font size (T
fs
) parameter
text knockout (T
k
) parameter
text line matrix (T
lm
)
text matrix (T
m
)
text rendering matrix (T
rm
)
text rendering mode (T
mode
)
text rise (T
rise
) parameter
text state parameters
undercolor-removal function
word spacing (T
w
) parameter
graphics state stack 184-185, 189
depth limit 920, 1033
gray color component 212
black, complement of 451
CMYK conversion 451
halftones for 476
RGB conversion 451
transfer function 455, 476
gray levels
CMYK conversion 451
color values 206
DeviceGray color space 212
G operator 258, 914
g operator 258, 914
halftones, approximation with 456-459, 464-465, 467
pixel depth 13
RGB conversion 451
gray ramps 890, 894
GrayMap entry (version 1.3 OPI dictionary) 910
grayscale color representation
and CMYK, conversion between 451, 456
DeviceGray color space 207, 212
in halftones 457
multitone components, specifying 238
in output devices 205, 450
rendering 14
and RGB, conversion between 451
Greek characters 433, 434
green color component
CMYK conversion 451, 454
DeviceRGB color space 211, 212
grayscale conversion 451
halftones for 476
in
Indexed color table 232
initialization 213
magenta, complement of 452
and threshold arrays 465
transfer function 455
green colorant
additive primary 211, 212, 213
display phosphor 234
PANTONE Hexachrome system 238
grestore operator (PostScript) 915, 920, 1033
Groove border style 849
group alpha
group backdrop, removal of 506
in isolated groups 507
notation 503, 505, 511
and overprinting 538
in page group 511
soft masks, deriving from 514, 520, 521
group attributes dictionaries 331
form XObject 329
page 121, 524, 545
S entry 331, 331, 524, 527
transparency group XObject 524, 527
Type entry 331
See also
transparency group attributes dictionaries
group backdrop 485, 502
blending color space 499
compositing with 499, 502, 503, 519, 525, 527, 529
isolated groups, unused in 507, 508
in knockout groups 510
in non-isolated groups 526
removal from compositing computations 506-507, 514
for soft masks 514, 520
group color
in compositing 499, 502, 526, 527
group backdrop, removal of 506
in isolated groups 507
in knockout groups 508
notation 503, 511
in page group 511
for soft masks 514, 515
group color space 211, 225, 229, 524, 525-526, 527, 529-
531
CIE-based 530, 531
and CompatibleOverprint blend mode 536-537
in isolated groups 530
in non-isolated groups 530
and overprinting 534, 535, 541
Index
1127
in page group 530
process colors, conversion to and from 532
rendering intents, target of 543
spot colors not converted to 532
group compositing function (Composite)
See Composite function
Group entry
page object 121, 524, 545
type 1 form dictionary 329, 330, 332, 524, 527, 578
group hierarchy 485, 499
group luminosity
soft masks, deriving from 486, 514-515, 520, 521
Group object type 331
group opacity 495
in compositing 485, 499, 502, 526, 527
in knockout groups 508
for soft masks 514
and spot color components 533
group shape 204, 495
in compositing 485, 499, 502, 526, 527
group backdrop, removal of 506
in isolated groups 507
notation 503, 505, 511
for soft masks 514, 515
and spot color components 533
group stack 499, 502
in isolated groups 507
in knockout groups 508
group subtypes 331, 331, 525
Transparency 331, 525, 527
group XObjects 165, 302, 329, 330-331, 524
subtype 331, 331, 525
See also
transparency group XObjects
grouped markup annotations 584
grouping elements
standard layout attributes for 846
grouping elements, standard
See standard grouping elements
groups, optional content
See optional content groups
groups, transparency
See transparency groups
gs operator 166, 189, 192, 259, 367, 373, 448, 520, 914
gsave operator (PostScript) 915, 920, 1033
gt operator (PostScript) 149, 918
GTS_PDFX output intent subtype 899
guideline styles (page boundaries)
D 895
S 895
guillemotleft character name, misspelled 928
guillemotright character name, misspelled 928
H
H entry
fixed print dictionary 607
hide action dictionary 628
inline image object 323
linearization parameter dictionary 947, 957, 1034
link annotation dictionary 587, 1020
software identifier dictionary 736, 736, 737
user property dictionary 805
Web Capture command dictionary 886, 888
widget annotation dictionary 603
h operator 166, 195, 197, 201, 914
H predefined CMap 414, 417
H standard structure type 830, 830, 833
H1–H6 standard structure types 830, 830, 833
halftone dictionaries 183, 192, 455, 465-478, 1017
HalftoneName entry 466-467
HalftoneType entry 465, 466
Type entry 466
See also
type 1 halftone dictionaries
type 5 halftone dictionaries
type 6 halftone dictionaries
type 10 halftone dictionaries
type 16 halftone dictionaries
Halftone object type 466, 467, 469, 472, 474, 475
halftone screens 14, 457-458
accurate screens algorithm 468
angle 458, 466, 467, 467, 468, 469, 470, 472, 473
cells. See cells, halftone
current transformation matrix (CTM), unaffected by
457
device space, defined in 457
frequency 458, 466, 467, 468, 470, 472
spot function 458-464, 466, 467, 467, 1017
See also predefined spot functions
threshold array 464-465, 466, 469, 470, 473, 474
transfer functions for 468, 469, 472, 474, 475
in type 5 halftones 466, 475
halftone streams 183, 192
halftone types
threshold arrays for 464
type 1 466, 467-468
type 5 466, 468, 469, 472, 475-478
type 6 466, 469, 472
type 10 466, 469-473, 473
type 16 466, 473-474
HalftoneName entry 466-467
type 1 halftone dictionary 467
Index
1128
type 5 halftone dictionary 475
type 6 halftone dictionary 469
type 10 halftone dictionary 472
type 16 halftone dictionary 474
halftones 14, 206, 447, 450, 456-478
accurate screens algorithm 468
cells. See cells, halftone
current transformation matrix (CTM), unaffected by
457
device space, defined in 457
name 466-467, 469, 472, 474, 475
proprietary 466
spot function 149, 458-464, 466, 467, 467, 1017
See also predefined spot functions
threshold array 464-465, 466, 469, 470, 473, 474
transfer functions, applied after 454, 455, 456
and transparency 542-543
See also
current halftone
halftone dictionaries
halftone screens
halftone types
type 1 halftones
type 5 halftones
type 6 halftones
type 10 halftones
type 16 halftones
HalftoneType entry 465, 466
type 1 halftone dictionary 467
type 5 halftone dictionary 475
type 6 halftone dictionary 469
type 10 halftone dictionary 472
type 16 halftone dictionary 474
handlers
action 937
annotation 570, 573, 937
destination 937
file system 937
security 92, 92, 96-103, 937
signature 684, 686
hanging indent 852
hangul characters 434
Hangul glyph class 434
hanja (hanzi, kanji) characters 432, 433, 434
Hanja glyph class 434
hanzi (kanji, hanja) characters 432, 433, 434
Hanzi glyph class 433
hard hyphen character (Unicode) 816
HardLight blend mode 486, 492
“head” table (TrueType font) 439
header, file
See file header
Headers standard structure attribute 863
headings 830
Hebrew writing systems 818, 848
Height entry
image dictionary 65, 310, 321, 523, 557
inline image object 323
type 6 halftone dictionary 469, 469, 472
type 16 halftone dictionary 473, 474, 474
Height standard structure attribute 841, 845, 846, 853,
859, 860
Height2 entry (type 16 halftone dictionary) 473, 474, 474
Help annotation icon 586
help systems 573, 627
Helvetica* typeface 16, 358, 359, 360, 923, 978
Helvetica standard font 385, 1015
HelveticaBold standard font 385, 1015
HelveticaBoldOblique standard font 385, 1015
HelveticaOblique standard font 385, 1015
Hewlett-Packard Company
PANOSE Classification Metrics Guide 432, 1060
Hexachrome color system, PANTONE 238, 239
hexadecimal strings 29, 32
“hhea” table (TrueType font) 439
HI entry (software identifier dictionary) 737, 737
Hid entry (obsolete page object) 1011
Hidden annotation flag 573, 627, 632, 1019, 1023
and real content 814
Hidden border style 849
hidden page elements 816-817
hide action dictionaries 628
H entry 628
S entry 628
T entry 628
Hide action type 615, 628, 1022
hide actions 615, 627-628, 1022-1023
and pop-up help systems 627
See also
hide action dictionaries
HideAnnotationActions entry (legal attestation
dictionary) 701
HideMenubar entry (viewer preferences dictionary) 548
HideToolbar entry (viewer preferences dictionary) 548
HideWindowUI entry (viewer preferences dictionary) 548
hiding and showing
annotations 573, 627, 628
document outline 115, 548
menu bar 548
navigation controls 548
optional content group panel 115, 548
scroll bars 548
Index
1129
thumbnail images 115, 548
tool bars 548
high-fidelity color 205, 207, 238
highlight
diffuse achromatic 218
specular 218
highlight annotation dictionaries
See text markup annotation dictionaries
Highlight annotation type 581, 596, 839
highlight annotations
See text markup annotations
highlighting mode (annotation) 587, 603
I (invert) 587, 603
N (none) 587, 603
O (outline) 587, 603
P (push) 587, 603
T (toggle) 603
hint stream dictionaries 951-952
A entry 951
B entry 952
C entry 952
E entry 951
I entry 951
L entry 952
O entry 951
S entry 951
T entry 951
V entry 951
hint streams (Linearized PDF) 943, 950-952
length 947, 957, 957, 958
offset 947, 957, 958
See also
hint stream dictionaries
overflow hint stream
primary hint stream
hint tables (Linearized PDF) 940, 957-969
and document retrieval 969, 970, 971
embedded file streams 952, 967-969
extended generic 966-967
generic 957, 966
in hint streams 942, 950, 957
information dictionary 951, 966
interactive form 951, 962, 967
logical structure 952, 962, 967
named destination 951, 966
and one-pass file generation 971
outline 951, 966
page label 952, 966
page offset 951, 955, 957, 958-961, 963, 971, 972, 1034
pages, locating from 952, 954
renditions name tree 952, 967
shared object 951, 955, 960, 961-964, 967, 971, 1034,
1035
standard 951-952
thread information 951, 966
thumbnail 951, 964-965
hints
in font programs 383, 390
in Linearized PDF
See
hint streams
hint tables
scan conversion 481
hiragana characters 433, 434
HKana glyph class 434
HKanaRot glyph class 434
HKscsB5H predefined CMap 413, 416
HKscsB5V predefined CMap 413, 416
HKSCS-2001 character set 414
“hmtx” table (TrueType font) 439
HojoKanji glyph class 434
Hong Kong SCS character encoding 413
Hong Kong SCS character set 413
horizontal scaling (T
h
) parameter 367, 370
text matrix, updating of 380
text space 376
TJ operator 1014
Tz operator 368, 916
horizontal tab (HT) character 26
in comments 27
escape sequence for 30
as white space 24, 32
HPGL (Hewlett-Packard Graphics Language) file format
19
<href> tag (HTML) 675
HRoman glyph class 433, 434
HRomanRot glyph class 433, 434
HSL (hue-saturation-luminance) color representation
for nonseparable blend modes 492
HSV (hue-saturation-value) color representation
blending color space, prohibited for 489
HT entry (graphics state parameter dictionary) 192, 259,
465, 702
HTML (Hypertext Markup Language)
digital identifiers 879
<href> tag 675
hypertext links 836, 837
importation of 770
layout model 824
and Linearized PDF 941
PDF logical structure compared with 784
standard attribute owners 843
Tagged PDF, conversion from 812, 821, 827
target attribute 675
Index
1130
“unsafe” characters in 878
weakly structured document organization 833
Web Capture 873, 874, 875, 881, 890
HTML-3.20 standard attribute owner 843, 844
HTML 4.01 Specification (World Wide Web Consortium)
625, 1063
HTML-4.01 standard attribute owner 843, 844
HTML Form format
in file-select controls 654
interactive form fields, converted to (Web Capture)
879
in submit-form actions 663, 666, 1026
HTTP (Hypertext Transfer Protocol) 74, 878, 885
GET request 664, 884, 887
and Linearized PDF 940, 941-942
POST request 664, 884, 887
request headers 886, 888
Hue blend mode 493
Huffman coding 47
hybrid-reference files 85-91
hidden and visible objects 86
hypertext links 21
link annotations 9, 587
link elements (Tagged PDF) 836, 837
named destinations, converted to (Web Capture) 879
pdfmark language extension (PostScript) 20
plug-in extensions for 1002
PostScript conversion 22
uniform resource identifiers (URIs) 624
Hypertext Transfer Protocol—HTTP/1.1 (Internet RFC
2616) 888, 1062
hyphen character (-)
hard 816
soft 816, 928
as word separator 823
hyphenation 816
and packing of ILSEs 826
I
I border style (inset) 576
I color space abbreviation (inline image object) 323
I entry
appearance characteristics dictionary 604
border effect dictionary 577
choice field dictionary 657
hint stream dictionary 951
inline image object 323
thread dictionary 561, 938, 955
transparency group attributes dictionary 525, 526
I highlighting mode (invert) 587, 603
i operator 166, 189, 478, 914
<i> XHTML element (rich text strings) 643
IANA (Internet Assigned Numbers Authority) 865
IC entry
circle annotation dictionary 594
line annotation dictionary 591
polygon annotation dictionary 596
polyline annotation dictionary 596
square annotation dictionary 594
ICC. See International Color Consortium
ICC Characterization Data Registry (International Color
Consortium) 899, 901, 1060
ICC color profiles 222-225
AToB transformation 225, 489, 900, 1032
for blending color spaces 225
BToA transformation 225, 489, 900
color spaces 224, 225
device classes 224
“from CIE” information 225, 900
for
ICCBased color spaces 214, 222-225
in JPEG2000 64
metadata 223, 775
for output devices 449
for output intents 225, 899, 900, 1032
profile types 224
rendering intents 225
“to CIE” information 225, 900, 1032
versions 223-224
ICC profile stream dictionaries 223
Alternate entry 223, 224
Metadata entry 223
N entry 223
Range entry 223, 257, 316
ICCBased color spaces 207, 214, 222-227, 316, 900
alternate color space for 223, 224
bidirectional 489
as blending color space 489, 525
CIE-based A color spaces, representing 215
CIE-based ABC color spaces, representing 215
color profile 222-225, 449
as default color space 228
as group color space 533
implicit conversion 229, 230
initial color value 257
metadata for 775
process colors, conversion to 532
rendering 448
setting color values in 258, 915
specification 222
spot color components, effect on in transparency
groups 533
sRGB (standard RGB) 226, 530
and transparent overprinting 541
Index
1131
icon fit dictionaries 678-679
A entry 679
for dynamic appearance streams 605
FB entry 679, 1026
S entry 679
SW entry 679
icons, annotation
See annotation icons
icSigCmykData ('CMYK') ICC profile color space 224
icSigColorSpaceClass ('spac') ICC profile device class 224
icSigDisplayClass ('mntr') ICC profile device class 224
icSigGrayData ('GRAY') ICC profile color space 224
icSigInputClass ('scnr') ICC profile device class 224
icSigLabData ('Lab ') ICC profile color space 224
icSigOutputClass ('prtr') ICC profile device class 224
icSigRgbData ('RGB ') ICC profile color space 224
ID entry
FDF dictionary 673, 1025
file specification dictionary 156
file trailer dictionary 74, 101, 102, 673, 775, 1009, 1031
image dictionary 312, 523, 889
page object 122, 889
reference dictionary 332
structure element dictionary 787, 863
version 1.3 OPI dictionary 908
Web Capture content set 882
ID operator 166, 322, 324, 914
Identity crypt filter 66, 93, 94, 97, 107, 109, 110
Identity mapping (CIDToGIDMap) 408, 416
Identity transfer function 192, 468, 469, 472, 474, 521
Identity transform method 673, 689, 696
IdentityH predefined CMap 415, 417, 419, 442
IdentityV predefined CMap 415, 417, 419, 442
idiv operator (PostScript) 149, 917
IDS entry (name dictionary) 125, 875, 876, 877, 878, 882,
889
IDTree entry (structure tree root) 786, 787
IEC. See International Electrotechnical Commission
IETF
See Internet Engineering Task Force (IETF)
IF entry
appearance characteristics dictionary 605
FDF field dictionary 678, 678
if operator (PostScript) 28, 149, 918
ifelse operator (PostScript) 28, 149, 918
illuminated characters 864, 871
illustration elements, standard
See standard illustration elements
illustrations
bounding box 824, 860
and page content order 817
Illustrator
®
graphics software 485, 486, 510
ILSEs. See inline-level structure elements
IM entry (inline image object) 323
image coordinate system 307-309
image dictionaries 306, 309-318, 323, 1013
Alternates entry 311, 319, 523
BitsPerComponent entry 310, 314, 315, 320, 321, 523,
557
ColorSpace entry 65, 210, 310, 311, 314, 320, 523, 524,
537, 557
Decode entry 65, 311, 320, 522, 523, 557
decoding of sample data 285, 288, 290, 294
Height entry 65, 310, 321, 523, 557
ID entry 312, 523, 889
ImageMask entry 65, 307, 310, 311, 311, 312, 319, 320,
523
Intent entry 230, 310, 523
Interpolate entry 311, 316, 523
Mask entry 311, 319, 321, 518, 523, 1013
Metadata entry 64, 312
Name entry 312, 523, 1013
OC entry 313, 319, 344
OPI entry 312, 523, 907
SMask entry 65, 182, 311, 312, 320, 518, 522, 523, 542,
1018
SMaskInData entry 65, 312, 518
StructParent entry 312, 523, 798
Subtype entry 310, 323, 523, 557
for thumbnail images 557
Type entry 310, 323, 523
Width entry 65, 310, 321, 523, 557
Image entry (alternate image dictionary) 317
image masks
color operators, exception to limitations on 259, 262
with colored tiling patterns 265
Decode array 310, 320
explicit masking 321, 495
image dictionaries for 309
image XObjects as 305
ImageMask entry (image dictionary) 311
Mask entry (image dictionary) 311
object shape 517
and sampled images, compared 320
with shading patterns 273
stencil masking 320-321
in Type 3 glyph descriptions 393
with uncolored tiling patterns 268, 269
See also
explicit masking
soft-mask images
stencil masking
image objects
Index
1132
See image XObjects
image sets, Web Capture
See Web Capture image sets
image space 173, 305, 307, 469, 473, 474
image streams 36, 305, 306, 310
filters in 310, 1007
Image XObject subtype 302, 310, 523, 557
image XObjects 12, 165, 302, 305
as alternate images 305, 309, 317-318
alternate images for 311
color space 210, 227, 557
fully opaque 542
in glyph descriptions 390
as image masks 305
and
JBIG2Decode filter 57-58, 59
JPXDecode filter and 62
in Linearized PDF 953, 954, 961, 972
name 312
as OPI proxies 907, 1033
optional content in 313, 344
painting 305
parameters 305
parent content set 312, 889
as poster images (movies) 741
reference counts (Web Capture) 883, 1031
and slideshows 744
as soft-mask images 522-524, 1018
in Tagged PDF 827
as thumbnail images 305, 309, 557
in Web Capture content database 875, 876, 883, 884,
1031
See also
image dictionaries
images, sampled
ImageB procedure set 770
ImageC procedure set 770
%%ImageCropRect OPI comment (PostScript) 912
%%ImageDimensions OPI comment (PostScript) 911
%%ImageFilename OPI comment (PostScript) 911
ImageI procedure set 770
%%ImageInks OPI comment (PostScript) 912
ImageMask entry
image dictionary 65, 307, 310, 311, 311, 312, 319, 320,
523
inline image object 323
%%ImageOverprint OPI comment (PostScript) 912
images, sampled 11, 25, 163, 304-325
alternate images 305, 309, 311, 317-318
base images 309, 317, 317, 321
color inversion 316
color space 304, 305, 306, 307, 310, 311, 314, 315, 321
color specification 206, 232
compression 41, 42, 43, 49, 53, 56, 60
coordinate system 307-309
data format 305, 306-307
DCS 159
Decode array 306, 311, 314-316, 321
dictionaries. See image dictionaries
embedded file streams 157
encoding 41
fully opaque 542
height 310
image masks. See image masks
image space 173, 305, 307, 469, 473, 474
image streams 36, 305, 306, 310
inline 57, 165, 305, 322-325, 913, 914
interpolation 311, 316-317, 321
JPEG2000 62
in Linearized PDF 953, 954
masking 319-321, 495, 1013
metadata 312
and multitone color 238
nonzero overprint mode, unaffected by 256
object shape 517
objects. See image XObjects
OPI proxies 907
OPI version dictionary 312
painting 305
parameters 305-306
in pattern cells 262, 264
poster (movie) 741
rendering intents 310
restrictions on painting 259
sample values. See sample values
scan conversion 481
soft-mask 311, 518, 519, 522-524, 1018
specification 305
threshold arrays compared to 464
thumbnail. See thumbnail images
tint values, source of 235, 240
and transparent overprinting 536, 541
Type 3 glyph descriptions, prohibited in 393
Web Capture content set 312
width 310
See also
image XObjects
imagesetters 12, 170, 234, 236
ImageType entry (version 1.3 OPI dictionary) 910
imaging model 10-14
See also
Adobe imaging model
opaque imaging model
transparent imaging model
immediate backdrop (transparency group element) 484,
500, 502
in knockout groups 508, 509
Index
1133
in non-isolated groups 510
implementation limits 919-921
architectural 919, 919-921
array capacity 34
character identifier (CID) value 404, 920
clipping paths, complexity of 319
DeviceN tint components 240, 920
dictionary capacity 35, 134
file size 919
graphics state nesting depth 920, 1033
indirect objects, number of 920
magnification (zoom) factor 921
memory 919, 920, 921
name length 33, 34, 920
numeric range and precision 28, 150, 424, 742, 920
page size 921, 1033-1034
sampled functions, dimensionality of 142
string length 29, 36, 920
thumbnail image samples 921
Web Capture 874
implicit color conversion 228-230
Import annotation usage rights 694
import-data action dictionaries 668
F entry 668, 1025
S entry 668
import-data actions 615, 662, 667-668, 1025
and named pages 669
See also
import-data action dictionaries
Import embedded files usage rights 695
Import form usage rights 694
ImportData action type 615, 668
importing
content 331-334
FDF fields 669, 670, 673, 675, 676, 677, 680, 1025, 1026
interactive form fields 9, 634
pages 329, 332
IN entry
3D view dictionary 633, 747, 753, 757
incidental artifacts 816-817
hidden page elements 816-817
hyphenation 816
text discontinuities 816
Include action
FieldMDP transform parameters 695
signature field lock dictionary 659
Include/Exclude field flag
reset-form field 667
submit-form field 663, 665, 666
IncludeAnnotations field flag (submit-form field) 664
IncludeAppendSaves field flag (submit-form field) 664,
674
IncludedImageDimensions entry (version 2.0 OPI
dictionary) 912
%%IncludedImageDimensions OPI comment (PostScript)
912
IncludedImageQuality entry (version 2.0 OPI dictionary)
912
%%IncludedImageQuality OPI comment (PostScript) 912
IncludeNoValueFields field flag (submit-form field) 663,
665, 666
incremental updates 18, 74-75, 975
cross-reference sections 69
cross-reference subsections 69
and digital signatures 75, 674, 1003
FDF files, not permitted in 670
and file identifiers 775
file structure for 66, 67
generation numbers 39, 75
and Linearized PDF 939-940, 950, 969, 973
and submit-form actions 664
and version numbers 68, 114, 1003-1004
independent software vendors (ISVs) 94
InDesign page layout software 510, 1013
Index entry (cross-reference stream dictionary) 83, 84, 84
index operator (PostScript) 149, 918
Index standard structure type 829, 834
Indexed color spaces 207, 232-234, 315, 316
alternate color space, prohibited as 237, 240
base color space of 228, 232-233, 277, 531, 537
base color space, prohibited as 232
blending color space, prohibited as 525
color table 232, 233, 524
color values 232
default color space, prohibited as 228
I abbreviation 323
initial color value 232, 257
in inline image objects 324
maximum index value 233
parameters 232-233
remapping of base color space 228
setting color values in 257
for shadings 277
for soft-mask images 524
specification 232-234
for thumbnail images 557
type 1, 2, and 3 shadings, prohibited in 278, 279, 281
unrecognized filters and 1007
indexes 829, 834
indexing of text 440, 812
indices, page
See page indices
indirect object references 40
to compressed objects 77
Index
1134
generation numbers in 40
hint stream dictionaries (Linearized PDF), prohibited
in 951
in name trees 134
to nonexistent object 39
operands, prohibited as 126, 128
and progressive document retrieval (Linearized PDF)
972
version compatibility 1005
indirect objects 27, 39-41, 69
cross-reference table 67
definition 40
in FDF files 671, 672
generation number. See generation numbers
number, limit on 920
object identifier. See object identifiers
object number. See object numbers
in object streams 40, 77
operands, not permitted as 126, 128
random access 69
references. See indirect object references
for stream lengths, not permitted in FDF files 670
streams 36
Info entry
FDF page dictionary 680
file trailer dictionary 73, 771
PDF/X output intent dictionary 899
information dictionary, document
See document information dictionary
information dictionary hint table (Linearized PDF) 951,
966
Information Technology—JPEG 2000 Image Coding System:
Extensions (ISO/IEC 15444-2) 63, 1061
inheritable standard structure attributes 844
inheritance
field attributes 634, 636
page attributes 119, 120, 123-124, 128
standard structure attributes 844
initial backdrop (transparency group) 502
compositing with 499, 502, 505
in isolated groups 502, 507, 508, 526
in knockout groups 508, 509, 526
in non-isolated groups 502, 510
notation 500
ink annotation dictionaries 598-599
BS entry 599
InkList entry 599
Subtype entry 598
Ink annotation type 581, 598
ink annotations 581, 598-599, 1021
border style 571, 575
border width 599
dash pattern 599
ink list 599
See also
ink annotation dictionaries
ink-jet printers 12
resolution 13
InkList entry (ink annotation dictionary) 599
Inks entry (version 2.0 OPI dictionary) 912
inline alignment 854
Center 854
End 854
Start 854
inline image objects 322-324
BitsPerComponent entry 323
color spaces, abbreviations for 323
CMYK (DeviceCMYK) 323
G (DeviceGray) 323
I (Indexed) 323
RGB (DeviceRGB) 323
ColorSpace entry 323, 324
Decode entry 323
DecodeParms entry 323
dictionary entries, abbreviations for 323
BPC (BitsPerComponent) 323
CS (ColorSpace) 323, 324
D (Decode) 323
DP (DecodeParms) 323
F (Filter) 323
H (Height) 323
I (Interpolate) 323
IM (ImageMask) 323
W (Width) 323
Filter entry 323
filters, abbreviations for 323-324, 1006-1007
A85 (ASCII85Decode) 324
AHx (ASCIIHexDecode) 324
CCF (CCITTFaxDecode) 324
DCT (DCTDecode) 324
Fl (FlateDecode) 324
LZW (LZWDecode) 324
RL (RunLengthDecode) 324
Height entry 323
image data 322, 324
ImageMask entry 323
Intent entry 323
Interpolate entry 323
Width entry 323
See also
inline images
inline image operators 166, 322
BI 166, 322, 913
EI 166, 322, 324, 914
ID 166, 322, 324, 914
inline images 57, 165, 305, 322-325, 913, 914
Index
1135
color space 227, 324
filters in 324, 1007
in Linearized PDF 941
parameters 305
See also
inline image objects
inline-level structure elements (ILSEs) 824, 829, 834-838
Annot 818, 836, 839
annotation elements 839
baseline shift 855
BibEntry 835
BLSEs, contained in 824, 834
BLSEs nested within 834, 856, 857
BLSEs, treated as 833, 847, 851
Code 835
content items in 827
general layout attributes for 846
illustrations as 824
Link 818, 835, 839
link annotations, association with 836, 839
link elements 836-838
Note 835
packing 825-826, 846
Quote 835
Reference 828, 829, 835
Ruby 836
ruby elements 839
Span 834, 839, 864
standard layout attributes for 845, 846
BaselineShift 846, 855
GlyphOrientationVertical 858
LineHeight 846, 856
RubyAlign 857
RubyPosition 858
TextDecorationColor 846, 856
TextDecorationThickness 846, 856
TextDecorationType 846, 857
usage guidelines 833
Warichu 836
warichu elements 839
Inline placement attribute 829, 845, 846, 851, 860, 861
inline-progression direction 824
illustrations, width of 860
in layout 825, 834, 846, 847, 852, 853, 854
local override 848
table expansion 863
writing mode 848
Inline ruby text position 858
InlineAlign standard structure attribute 825, 846, 854
inline-progression direction 858
input focus 611, 612, 613
Insert annotation icon 586
Inset border style 850
insideness 202-204
even-odd rule 203-204
nonzero winding number rule 202-203
and object shape 485, 509
and scan conversion 480
instantiation of 3D artwork 751-752
integer objects 27
as dictionary values 131
as number tree keys 138
range limits 28, 920
syntax 28
intellectual property 7-8
intent (markup annotations) 584
intent (optional content)
All 346
Design 335, 338, 346, 350
View 335, 338, 346
Intent entry
image dictionary 230, 310, 523
inline image object 323
optional content configuration dictionary 346, 350
optional content group dictionary 335, 335, 338, 339
interactive features 9, 21, 23, 547-702
pdfmark language extension (PostScript) 20
See
actions
annotations
articles
destinations
document outline
interactive forms
page labels
presentations
thumbnail images
viewer preferences
interactive form dictionary 116, 634-636
CO entry 613, 635
DA entry 635
DR entry 635, 641, 642, 646, 1023
Fields entry 635
in Linearized PDF 949
NeedAppearances entry 614, 635
Q entry 635
SigFlags entry 635
signature flags. See signature flags
XFA entry 635, 681, 682, 683, 1023
interactive form fields
See fields, interactive form
interactive form hint table (Linearized PDF) 951, 962, 967
interactive forms 9, 634-681
computation order 613, 635
default resource dictionary 1023
FDF (Forms Data Format). See Forms Data Format
Index
1136
fields. See fields, interactive form
and form XObjects, distinguished 325, 634
and import-data actions 1025
interactive form dictionary 116, 949
named pages 125, 669
template pages 125, 680-681, 1027
interchange
of content 9, 789, 801
of documents. See document interchange
interior color
annotations 591, 594
line endings 593
International Color Consortium (ICC) 222, 230, 1060
International Commission on Illumination 207
International Electrotechnical Commission (IEC) 226,
1061
International Organization for Standardization (ISO) 56,
57, 60, 132, 865
ISO 639 (Codes for the Representation of Names of
Languages) 132, 865, 1061
ISO 3166 (Codes for the Representation of Names of
Countries and Their Subdivisions) 132, 865, 1061
ISO/IEC 8824-1 (Abstract Syntax Notation One
(ASN.1): Specification of Basic Notation) 133, 1061
ISO/IEC 10918-1 (Digital Compression and Coding of
Continuous-Tone Still Images) 1061
ISO/IEC 15444-2 (Information Technology—JPEG 2000
Image Coding System: Extensions) 1061
International Telecommunications Union (ITU) 53, 1061
Internet
uniform resource identifiers (URIs) 624
Web Capture plug-in extension 770, 873
Internet Assigned Numbers Authority (IANA) 865
Internet Engineering Task Force (IETF) 1061
Public Key Infrastructure (PKIX) working group 697,
1062
See also
Internet RFCs (Requests for Comments)
Internet RFCs (Requests for Comments) 1061
1321 (The MD5 Message-Digest Algorithm) 95, 158,
776, 879, 1061
1738 (Uniform Resource Locators) 152, 161, 878, 1061
1808 (Relative Uniform Resource Locators) 152, 878,
887, 1061
1950 (ZLIB Compressed Data Format Specification) 47,
1062
1951 (DEFLATE Compressed Data Format
Specification) 47, 1062
2045 (Multipurpose Internet Mail Extensions (MIME),
Part One: Format of Internet Message Bodies) 654,
664, 720, 882, 887, 1062
2046 (Multipurpose Internet Mail Extensions (MIME),
Part Two: Media Types) 158, 1062
2083 (PNG (Portable Network Graphics) Specification)
51, 1062
2315 (PKCS #7
Cryptographic Message Syntax, Version 1.5) 104,
697
Cryptographic Message Syntax, Version 3.15) 1062
2396 (Uniform Resource Identifiers (URI)
Generic Syntax) 624, 737, 1062
2560 X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol—OCSP 698, 1062
2616 (Hypertext Transfer Protocol—HTTP/1.1) 888,
1062
3066 (Tags for the Identification of Languages) 431, 865,
1062
3161 (Internet X.509 Public Key Infrastructure Time-
Stamp Protocol (TSP)) 660, 1062
3174 (US Secure Hash Algorithm 1 (SHA1)) 1062
3280 (Internet X.509 Public Key Infrastructure, Certifi-
cate and Certificate Revocation List (CRL) Profile)
661, 698, 1062
Internet X.509 Public Key Infrastructure, Certificate and
Certificate Revocation List (CRL) Profile (Internet
RFC 3280) 661, 698, 1062
Internet X.509 Public Key Infrastructure Time-Stamp Proto-
col (TSP) (Internet RFC 3161) 660, 1062
Interpolate entry
image dictionary 311, 316, 523
inline image object 323
Interpolate function 142, 143-144, 148, 314
interpolation
bilinear 291, 292
cubic spline 143, 145
Gouraud 284, 288, 296, 1060
linear 143, 292, 1011
in sampled images 311, 316-317, 321
interpolation functions 284
“Interpolation Using Bézier Curves” (Elber) 1062
intrinsic duration (multimedia) 727
InvertedDouble predefined spot function 460
InvertedDoubleDot predefined spot function 459
InvertedEllipseA predefined spot function 462
InvertedEllipseC predefined spot function 462
InvertedSimpleDot predefined spot function 459
Invisible annotation flag 573
IRT entry (markup annotation dictionary) 583, 584, 585
IsMap entry (URI action dictionary) 624
ISO. See International Organization for Standardization
ISO-2022-JP character encoding 414
ISO Latin 1 character encoding 131
isolated groups 499, 506, 507-508, 526
blend mode 507
Index
1137
blending color space 499, 507, 525
compositing in 507, 508, 526
compositing of 507
group alpha 507
group backdrop unused in 507, 508
group color 507
group color space, explicit 530
group compositing formulas 508, 512
group shape 507
group stack 507
initial backdrop 502, 507, 508, 526
knockout 510
object alpha 507
object shape 507
page group as 510, 511, 525
pattern cells as 529
for soft masks 515
source color 507
and white-preserving blend modes 536
Issuer entry (certificate seed value dictionary) 661
IT entry
free text annotation dictionary 589
line annotation dictionary 591
markup annotation dictionary 584
polygon annotation dictionary 596
Italic font characteristic 821
Italic font flag 429, 821, 822
italic fonts 429
Italic outline item flag 556
ItalicAngle entry (font descriptor) 427
ITC Zapf Dingbats
®
typeface 16, 265, 923
items, outline. See outline items
ITU (International Telecommunications Union)
Recommendation X.509 (1997) 1061
Recommendations T.4 and T.6 53, 1061
IX entry (appearance characteristics dictionary) 605
J
J operator 166, 189, 914
j operator 166, 189, 914
jamo characters 434
Japanese
character collections 417
character sets 403, 404
CMaps 414-415
fonts 389
glyph widths 410
kana (katakana, hiragana) characters 433, 434
kanji (Chinese) characters 432, 433, 434
R2L reading order 549
ruby characters 434
Shift-JIS character encoding 404, 420
writing systems 848
Japanese Industrial Standard (JIS) X 4051-1995 840
Java programming language 802
JavaScript action dictionaries 668
JS entry 668
S entry 668
JavaScript action type 615, 668
JavaScript actions 615, 662, 668-669, 1025
document-level 125, 157, 668
invoking slideshows 744, 1029
and named pages 669
trigger events for 612, 613, 614
See also
JavaScript action dictionaries
JavaScript dictionary 675-676
After entry 676
AfterPermsReady entry 676
Before entry 676
Doc entry 676
JavaScript entry
FDF dictionary 675
name dictionary 125, 668, 676
JavaScript scripting language
and 3D artwork 746, 748, 751, 753, 754
functions 668, 675, 676
interpreter 662, 668
in rendition actions 631
scripts 662, 665, 668, 669, 675-676
Unicode, incompatible with 1025
See also
JavaScript actions
JavaScript dictionary
JavaScriptActions entry (legal attestation dictionary) 701
JBIG (Joint Bi-Level Image Experts Group) 15, 56
JBIG2 compression 15, 43, 56-60
JBIG2Decode filter 43, 56-60
inline images, prohibited in 323
parameters. See
JBIG2Decode filter parameter dictio-
naries
in sampled images 310
JBIG2Decode filter parameter dictionaries 58
JBIG2Globals entry 58, 59, 60
JBIG2Globals entry (JBIG2Decode filter parameter
dictionary) 58, 59, 60
JDF (Job Definition Format) 448, 891, 903, 906, 1032
JDF Specification (CIP4) 448, 903, 1061
JIS C 6226 character set 414
JIS X 0208 character set 414
JIS X 0213:1000 character set 415
JIS X 4051-1995 (Japanese Industrial Standard) 840
Index
1138
JIS78 character set 414
job tickets 448, 903, 906, 1032
JDF 448, 891, 903, 906, 1032
PJTF 24, 448, 891, 903, 906, 1032
JP2 format (JPEG2000 compression) 63
JPEG (Joint Photographic Experts Group) 60
baseline format 60, 62
compression 15, 43, 60, 62
file format 770, 873
progressive extension 62, 1008
JPEG: Still Image Data Compression Standard (Pennebaker
and Mitchell) 60, 1063
JPEG2000 62-65
channels 63-64
color spaces 64
compression 15, 43, 62-65
enumerated color spaces 64
JP2 format 63
JPX baseline 63
JPX format 63
opacity 64
resolution progression 62, 63
soft-mask images 65
JPX baseline (JPEG2000 compression) 63
JPX format (JPEG2000 compression) 63-64
JPXDecode filter 43, 62-65, 304, 306, 310, 312, 518
color spaces 64
image dictionary entries 65
inline images, prohibited in 323
JS entry
JavaScript action dictionary 668
rendition action dictionary 631
Justify block alignment 854
Justify ruby text alignment 857
Justify text alignment 853
K
K entry
additional-actions dictionary 612
CCITTFaxDecode filter parameter dictionary 54, 55
structure element dictionary 785, 787, 790, 796
structure tree root 785, 786, 827
transparency group attributes dictionary 526, 527
K operator 166, 206, 210, 211, 213, 258, 914
k operator 166, 206, 210, 211, 213, 258, 915
K trigger event (form field) 612, 614
kana (katakana, hiragana) characters 433, 434
Kana glyph class 433, 434
kanji (hanzi, hanja) characters 432, 433, 434
Kanji glyph class 434
KanjiTalk6 character set 414
KanjiTalk7 character set 414
katakana characters 433, 434
kerning 366
Key annotation icon 586
keyboard 9
annotations 568
check box fields 648
text fields 639, 647, 653
trigger events 612
keys
dictionary 25, 35, 1004
encryption. See encryption keys
name tree 134, 135
number tree 138, 139
keywords
endobj 40, 78, 921
endstream 36-37, 38, 921, 1006
f 70, 997
false 28, 34
n 70
null 39
obj 34, 40, 78
operators 126
R 40
startxref 73, 82, 949, 956, 969, 993, 995, 998, 1000
stream 36-37, 38, 1006
trailer 73, 83, 672
true 28, 34
xref 69, 73, 82, 948
Keywords entry (document information dictionary) 772
Kids entry
FDF field dictionary 677
field dictionary 637, 650, 651, 653
name tree node 135, 135
number tree node 139
page tree node 118
knockout groups 499, 508-510, 526
and backdrop color removal 507
blend mode 508
compositing in 509, 526
group backdrop 502, 510
group color 508
group compositing formulas 509, 512
group opacity 508
group stack 508
immediate backdrop (group elements) 508, 509
initial backdrop 508, 509, 526
isolated 510
non-isolated 510
non-isolated group, parent of 526
non-isolated groups nested within 510
object opacity 508
Index
1139
object shape 508, 509
and overprinting 538
result alpha 509
result color 509
result opacity 509
shading patterns implicitly enclosed in 528
soft clipping 518
for soft masks 515
source alpha 509
source opacity 509
source shape 509
text knockout parameter equivalent to 374
Korean
character collections 417
character sets 403, 404
CMaps 415
fonts 389
glyph widths 410
hangul characters 434
jamo characters 434
R2L reading order 549
KS X 1001:1992 character set 415
KSCEUCH predefined CMap 415, 417
KSCEUCV predefined CMap 415, 417
KSCmsUHCH predefined CMap 415, 417
KSCmsUHCHWH predefined CMap 415, 417
KSCmsUHCHWV predefined CMap 415, 417
KSCmsUHCV predefined CMap 415, 417
KSCpcEUCH predefined CMap 415, 417
L
L entry
hint stream dictionary 952
line annotation dictionary 590, 591
linearization parameter dictionary 947
media criteria dictionary 717
software identifier dictionary 736, 737
Web Capture command dictionary 886
l operator 166, 196, 201, 915
L standard structure type 830, 831, 861
L2R reading order 549
L*a*b* color representation 224
blending color space, prohibited for 489
Lab color space dictionaries 221
BlackPoint entry 221
Range entry 220, 221, 257, 315
WhitePoint entry 221
Lab color spaces 207, 214, 220-222, 315
as base color space 232
blending color space, prohibited as 489, 525
color values 220
default color space, prohibited as 228
and
ICCBased color spaces, compared 222, 225
initial color value 257
rendering 448
setting color values in 257
See also
Lab color space dictionaries
labeling ranges, page 114, 558-559, 560
labels, page
See page labels
Lang entry 816, 862, 864, 865, 871, 872
CIDFont font descriptor 431
document catalog 116, 864, 865, 866, 867
Language subdictionary, optional content usage
dictionary 350, 353
property list 834, 864, 865, 866, 867, 868
structure element dictionary 788, 842, 844, 864, 865,
867
language, natural
See natural language specification
language codes
IANA 865
ISO 639 132, 865
Language entry (optional content usage dictionary) 350,
353
language identifiers 116, 717, 788, 865
multi-language text arrays 869
laser printers 12
resolution 13
Last entry
outline dictionary 554
outline item dictionary 555
LastChar entry
Type 1 font dictionary 384, 384, 386, 1016
Type 3 font dictionary 390
LastModified entry
application data dictionary 777
page object 119, 904
trap network annotation dictionary 904, 905
type 1 form dictionary 329
LastPage named action 628
See also
named-action dictionaries
Latin character set, standard 923, 924, 925-928, 1017
character names 398-399, 441
encodings 396
glyph displacements 365
nonsymbolic fonts 396, 429, 430, 954
standard fonts 16, 358
Tj operator 360
Latin characters 432, 433, 434
metrics 433
Index
1140
Latin writing systems 395, 430
lattice-form Gouraud-shaded triangle meshes
See type 5 shadings
lattices, pseudorectangular 289
launch action dictionaries 622
F entry 622
Mac entry 622
NewWindow entry 622
S entry 622
Unix entry 622
Win entry 622, 1022
Launch action type 615, 622
launch actions 615, 621-623, 1022
See also
launch action dictionaries
Windows launch parameter dictionaries
LaunchActions entry (legal attestation dictionary) 701
layers
See optional content
layout, page 115, 1021-1022
Layout artifact type 814
layout artifacts 815
layout attributes, standard
See standard layout attributes
Layout standard attribute owner 843, 844, 845
Lbl standard structure type 828, 830, 831, 835, 861, 862
standard layout attributes for 852
LBody standard structure type 830, 831
standard layout attributes for 852
LC entry (graphics state parameter dictionary) 190
LE entry
line annotation dictionary 590
polyline annotation dictionary 595
le operator (PostScript) 149, 918
leader lines (line annotations) 591, 592
Leading entry (font descriptor) 427
leading (T
l
) parameter 367, 370-371
T* operator 376
TD operator 376, 916
TL operator 368, 916
left angle bracket (
<) character 26
double, as dictionary delimiter 35, 73, 672
as hexadecimal string delimiter 29, 32, 35, 155
left brace (
{) character 26
as delimiter in PostScript calculator functions 149
left bracket (
[) character 26
as array delimiter 34, 1034
left parenthesis (
() character 26
escape sequence for 30, 379
as literal string delimiter 29
legal attestation dictionaries 660, 691, 701
AlternateImages entry 702
Annotations entry 702
Attestation entry 701, 702
DevDepGS_BG entry 702
DevDepGS_FL entry 702
DevDepGS_HT entry 702
DevDepGS_OP entry 702
DevDepGS_TR entry 702
DevDepGS_UCR entry 702
ExternalOPIdicts entry 702
ExternalRefXobjects entry 702
ExternalStreams entry 702
GoToRemote entry 701
HideAnnotationActions entry 701
JavaScriptActions entry 701
LaunchActions entry 701
MovieActions entry 701
NonEmbeddedFonts entry 702
OptionalContent entry 702
SoundActions entry 701
TrueTypeFonts entry 702
URIActions entry 701
Legal entry (document catalog) 117, 701
LegalAttestation entry (signature field seed value
dictionary) 660, 661
Length entry
crypt filter dictionary 109
encryption dictionary 92, 93, 95, 101, 102
object stream dictionary 77
stream dictionary 37, 38, 40, 96, 276, 323, 437, 951,
975
Length1 entry (embedded font stream dictionary) 437,
438
Length2 entry (embedded font stream dictionary) 437,
438
Length3 entry (embedded font stream dictionary) 437,
438
Level1 entry (PostScript XObject dictionary) 303
lexical conventions 24-27
LI entry (software identifier dictionary) 736, 736, 737
LI standard structure type 830, 831, 861
ligatures 395, 445, 864, 871, 923
Lighten blend mode 491
lightness 489, 525
limits, implementation
See implementation limits
Limits entry
name tree node 135
number tree node 139
line annotation dictionaries 590-591
BS entry 590
Cap entry 591
Index
1141
IC entry 591
IT entry 591
L entry 590, 591
LE entry 590
LL entry 591
LLE entry 591
Subtype entry 590
Line annotation type 580, 590
line annotations 580, 590-593
border style 571, 575
dash pattern 590
interior color (line endings) 591, 593
leader lines 591, 592
line ending style. See line ending styles
line width 590, 595
See also
line annotation dictionaries
Line Breaking Properties (Unicode Standard Annex #14)
1063
line cap style 181, 186
butt 186, 186, 201
and dash pattern 188
J operator 189, 914
LC entry (graphics state parameter dictionary) 190
projecting square 186, 201
round 186, 201
and
S operator 201
and Type 3 glyph descriptions 392
line dash pattern 181, 187-188
for annotation borders 571, 572, 576
for circle annotations 594
D entry (graphics state parameter dictionary) 190
d operator 189, 914
dash array 187-188, 190, 572, 576, 895, 1019
dash phase 187-188, 190, 572, 576, 895
for ink annotations 599
for line annotations 590
for page boundaries 895
and
S operator 201, 202
for square annotations 594
and Type 3 glyph descriptions 392
line ending styles 593
Butt 593
Circle 593
ClosedArrow 593
Diamond 593
None 593
OpenArrow 593
RClosedArrow 593
ROpenArrow 593
Slash 593
Square 593
line feed (LF) character 26
in cross-reference tables 70
as end-of-line marker 26, 31, 37, 67, 70
escape sequence for 30
in HTTP requests 888
in stream objects 36, 37
as white space 24, 32
line height 856
Auto 856
Normal 856
line join style 181, 186
bevel 186, 187, 201
and dash pattern 188
j operator 189, 914
LJ entry (graphics state parameter dictionary) 190
miter 186, 201
round 186, 201
and
S operator 201
and Type 3 glyph descriptions 392
Line predefined spot function 458, 460
line width, current
See current line width
linear interpolation 143, 292, 1011
linearization parameter dictionary 944, 946-948, 1034
E entry 947, 952, 1034
file length in 969, 973
first-page object number in 947, 952
H entry 947, 957, 1034
hint stream offsets in 950, 958
L entry 947
Linearized entry 947
N entry 947
O entry 947, 952, 960, 964
P entry 948, 952
T entry 948, 971
Linearized entry (linearization parameter dictionary) 947
Linearized PDF 17, 68, 69, 124, 939-973
access strategies 969-973
background and assumptions 940-942
cross-reference streams in 943, 948
cross-reference tables 943, 958
first-page 944, 948, 949, 950, 956, 960, 969
main 946, 948, 949, 956
document catalog 942, 944, 948, 949, 956, 971
document structure 942-956
first-page section 945, 950, 952-954, 961, 969, 970,
1034
generation numbers 943
header 946
hint streams. See hint streams
hint tables. See hint tables
HTML (Hypertext Markup Language) 941
HTTP (Hypertext Transfer Protocol) 940, 941-942
incremental updates and 939-940, 950, 969, 973
Index
1142
indirect objects, numbering of 942-943, 950
inline images, retrieval of 941
linearization parameter dictionary 944, 946-948, 950,
952, 958, 969, 973, 1034
MIME (Multipurpose Internet Mail Extensions) 940,
941
object streams in 943
shared object signatures 963, 1035
shared objects section 954-955, 961, 963, 964, 1034
thumbnail shared objects section 955, 955, 965
trailer
first-page 944, 948-949, 949
main 956
URLs (uniform resource locators) 940, 941
version identification 947
and World Wide Web 940
LineHeight standard structure attribute 834, 846, 851, 856,
859
lines (text) 825
stacking within parent BLSE 825, 834
LineThrough text decoration type 857
lineto operator (PostScript) 22, 915
LineX predefined spot function 460
LineY predefined spot function 461
link annotation dictionaries 587-588
Dest entry 572, 587, 616
H entry 587, 1020
PA entry 588
QuadPoints entry 588
Subtype entry 587
Link annotation type 580, 582, 587, 674
link annotations 9, 580, 587-588, 610, 1020-1021
actions for 572
border color 572
border style 1020
destination 551, 553, 587, 1020
and go-to actions 616
highlighting mode 587
and link elements (Tagged PDF) 836-838
Link standard structure type 835
movie actions associated with 626
and trigger events 612
and URI actions 588, 1022
and Web Capture 588
See also
link annotation dictionaries
link elements (Tagged PDF) 836-838
Link standard structure type 818, 835, 839
links, hypertext
See hypertext links
list attribute, standard
See standard list attribute
list box fields 647, 656, 657
trigger events for 612
variable text in 639
list elements, standard
See standard list elements
list numbering style 862
Circle 862
Decimal 862
Disc 862
LowerAlpha 862
LowerRoman 862
None 862
Square 862
UpperAlpha 862
UpperRoman 862
List standard attribute owner 843, 844, 862
ListMode entry (optional content configuration
dictionary) 347
ListNumbering standard structure attribute 861, 862
literal strings 29-31
continuation lines 30-31
escape sequences 30-31
octal character codes in 30, 31
LJ entry (graphics state parameter dictionary) 190
LL entry (line annotation dictionary) 591
LLE entry (line annotation dictionary) 591
ln operator (PostScript) 149, 917
“loca” table (TrueType font) 439
Location entry (signature dictionary) 687, 688
Lock entry (signature field dictionary) 659
Locked annotation flag 574, 1020
Locked entry (optional content configuration dictionary)
348
log operator (PostScript) 149, 917
LOGFONT structure (Windows) 388
logical structure 9, 21, 23, 769, 784-811
annotation elements (Tagged PDF) 839
annotations, sequencing of 818
content 789-801
example 806-811
fragmented BLSEs, recognition of 830
link elements (Tagged PDF) 836
and page content order 864
page tree, distinguished from 118
pdfmark language extension (PostScript) 20
and real content 814
and reference XObjects 333-334
structural parent tree 122, 312, 329, 573
Tagged PDF and 769, 812, 813, 814
text discontinuities, recognition of 816
visible content, separation from 784
See also
Index
1143
content items
structure attributes
structure elements
structure hierarchy
structure tree root
structure types
logical structure hint table (Linearized PDF) 952, 962, 967
logical structure order 817
annotations, sequencing of 818
artifacts 817
lossless filters 42, 56, 62, 226
lossy filters 42, 56, 60, 62, 321
LowerAlpha list numbering style 862
LowerRoman list numbering style 862
LP entry (additional-actions dictionary, obsolete) 1021
LrTb writing mode 848
lt operator (PostScript) 149, 918
luminance 61
Luminosity blend mode 493
Luminosity soft-mask subtype 521, 525
L*u*v* color representation
blending color space, prohibited for 489
LW entry (graphics state parameter dictionary) 183, 190
LZW (Lempel-Ziv-Welch) compression 15, 41, 42, 43, 47-
53
clear-table marker 48, 49
predictor functions 47, 50, 51-53, 310
LZW filter abbreviation 324, 1007
LZWDecode filter 43, 47-53
LZW abbreviation 324, 1007
parameters. See
LZWDecode filter parameter dictionar-
ies
predictor functions 51-53
in sampled images 310
LZWDecode filter parameter dictionaries 49-50
BitsPerComponent entry 50
Colors entry 50
Columns entry 50
EarlyChange entry 50
Predictor entry 50, 51-52
M
M entry
annotation dictionary 571, 599, 1019
media offset marker dictionary 732
media screen parameters
MH/BE dictionaries 729, 730
minimum bit depth dictionary 718
minimum screen size dictionary 718
signature dictionary 687, 688
transition dictionary 563, 564
M operator 166, 189, 915
m operator 166, 196, 202, 915
Mac entry
embedded file parameter dictionary 158
file specification dictionary 155, 156
launch action dictionary 622
Mac OS file information dictionaries 158-159
Mac OS KH character set 415
Mac
®
OS operating system
Adobe PDF printer 19
application launch parameters 621, 622
character encoding 395, 396, 924, 928
file information 158-159
file names 154
file system 155
FOND resource 388
font names 388
Preferences folder 1025
QuickDraw imaging model 19
Script Manager 413, 414, 415
TrueType
®
font format 399
MacExpertEncoding predefined character encoding 396,
923, 924
as base encoding 397
for Type 1 fonts 384
and Unicode mapping 441
MacRomanEncoding predefined character encoding 396,
923, 924, 928
as base encoding 397
differences from Mac OS Roman encoding 401
for TrueType fonts 400, 401
for Type 1 fonts 384
and Unicode mapping 441
magenta color component
DeviceCMYK color space 211, 213
DeviceN color spaces 238
grayscale conversion 451, 456
green, complement of 452
halftones for 476
initialization 213
in multitones 238
overprinting 539, 540
RGB conversion 451, 452
transfer function 454, 455
transparent overprinting 540
undercolor removal 183, 452, 453
magenta colorant
overprinting 539, 540
PANTONE Hexachrome system 238
printing ink 234
process colorant 211, 213
subtractive primary 211, 213
transparent overprinting 540
Index
1144
magnification (zoom) factor 115, 122, 574, 890
in destinations 551, 552
implementation limits 921
for movies 743
main cross-reference table (Linearized PDF) 946, 948,
949, 956
and page retrieval 971
main trailer (Linearized PDF) 956
MainImage entry (version 2.0 OPI dictionary) 911
%%MainImage OPI comment (PostScript) 911
mapping name (form field) 637, 664
mark information dictionary 116, 784-785
Marked entry 785, 812
Suspects entry 785, 818
UserProperties entry 785, 805
Marked annotation state 585
marked clipping sequences 781-782, 783
in illustration elements (Tagged PDF) 841
marked content 18, 168, 769, 778-784
and clipping 780-784
in dynamic appearance streams 642
elements. See marked content elements
language identifiers 116, 788
metadata for 775
operators. See marked-content operators
property lists 778, 779, 780, 913, 914
and Tagged PDF 769
Marked entry (mark information dictionary) 785, 812
marked-content elements 778
empty 782, 783
tags 778
See also
marked-content points
marked-content sequences
marked-content identifiers 790-791
and natural language specification 867
parent structure element, finding from 797, 800
small values recommended for 797
in structure elements 787, 791
marked-content operators 164, 166, 769, 778-779
BDC 166, 340, 341, 778, 779, 780, 790, 913
BMC 166, 641, 778, 779, 913
DP 166, 340, 778, 779, 780, 914
EMC 166, 340, 341, 641, 778, 779, 790, 914
MP 166, 778, 779, 915
for optional content 340-343
tags 778
text object operators, combined with 779-780
in text objects 375
marked-content points 778, 779, 914, 915
and clipping 783
empty 782
marked-content reference dictionaries 787, 791-792
MCID entry 792
Pg entry 792
Stm entry 792
StmOwn entry 792
Type entry 792
marked-content sequences 329, 778, 779, 913, 914
abbreviation expansion 872
alternate descriptions 870
annotations, association with 818
annotations, sequencing of 818
in appearance streams 792
for artifact specification 814
and clipping 780-782
empty 782
in form XObjects 792
identifiers. See marked-content identifiers
as logical structure content items 329, 785, 786, 787,
790-796, 797, 798, 800, 818
marked clipping sequences 781-782, 783, 841
natural language specification 864, 866-868, 869
nesting of 778
reference dictionaries 787
replacement text 871
for reverse-order show strings 819
Span tag 834
marked-content tags 778, 779, 937
Artifact 814
Clip 841
OC 340, 341
ReversedChars 819
Span 834, 842, 864, 866, 867, 868, 869, 870, 871, 872
and structure types 790
TagSuspect 817-818
MarkInfo entry (document catalog) 116, 784
MarkStyle entry (printer’s mark form dictionary) 896
markup annotation dictionaries 581-584
CA entry 583
Contents entry 582
CreationDate entry 583
IRT entry 583, 584
IT entry 584
Popup entry 583, 599
RC entry 583, 591, 645
RT entry 583, 584, 584
Subj entry 584
T entry 583, 585, 599, 665
markup annotations 9, 581-584
grouped 584
intent 584
rich text strings 642
See also markup annotation dictionaries
Index
1145
Mask entry (image dictionary) 311, 319, 321, 518, 523,
1013
Mask object type 521
mask opacity 182, 192, 311, 495, 517
notation 496, 501, 505
soft masks 513
specifying 518-519, 1018
in transparency groups 499
mask shape 182, 192, 311, 495, 517
notation 496, 501, 505
soft masks 513
specifying 518-519, 1018
in transparency groups 499
masked images 319-321, 1013
shape (transparent imaging model) 495
See also
color key masking
explicit masking
soft masks
stencil masking
matrices, transformation
See transformation matrices
Matrix entry
CalRGB color space dictionary 218, 219, 515
fixed print dictionary 607
type 1 form dictionary 327, 328, 332, 520, 577
type 1 pattern dictionary 263, 327
type 1 shading dictionary 278
type 2 pattern dictionary 272, 327
matte color (soft-mask image) 522, 524
Matte entry (soft-mask image dictionary) 312, 522, 523,
524
max entry (Zoom subdictionary, optional content usage
dictionary) 351, 353
MaxLen entry (text field dictionary) 653, 654
“maxp” table (TrueType font) 439
MaxWidth entry (font descriptor) 428
MCD subtype (media clip object) 720
MCID entry
marked-content reference dictionary 792
property list 790, 834, 867, 868
MCR object type 792
MCS subtype (media clip object) 720
MD5 message-digest algorithm 689, 1037
checksum, embedded files 158
for digital identifiers (Web Capture) 878-879
for file identifiers 776, 1031
hash function 95, 100-101, 102, 675, 874, 963
for shared object signatures (Linearized PDF) 963,
1035
MD5 Message-Digest Algorithm, The (Internet RFC 1321)
95, 158, 776, 879, 1061
MD5 message-digest algorithm 95
MD5 object digest algorithm 689, 1037
MDP (modification detection and prevention) signatures
685, 690
See also
DocMDP transform method
validating 691
MDP entry (signature field seed value dictionary) 660
measure dictionaries 703-710
Subtype entry 704, 705
Type entry 705
See also
rectilinear measure dictionaries
Measure entry (viewport dictionary) 703, 704
Measure object type 705
measurement properties 703-710
media box 891
inheritance of 123
for media selection 893
in page imposition 1032
in page object 120
page placement, ignored in 893
in printing 893
in rendering 448
media clip data dictionaries 720-721, 734
Alt entry 721
BE entry 721
CT entry 720, 721, 1028
D entry 720, 721
MH entry 721
P entry 720, 722
PL entry 721, 721, 1028
See also
media clip data
MH/BE dictionaries
media clip data
MH/BE dictionaries 723
BU entry 722, 723
media clip data objects 720-722
See also
media clip data dictionaries
media clip dictionaries 719, 720
N entry 720
S entry 720, 720
Type entry 720
See also
media clip data dictionaries
media clip data
MH/BE dictionaries
media clip section dictionaries
media clip section
MH/BE dictionaries
media clip objects 720-725
MCD subtype 720
MCS subtype 720
media clip section 723-725
next-level 723, 725
See also
Index
1146
media clip dictionaries
media clip section dictionaries 723
Alt entry 723
BE entry 723
D entry 723
MH entry 723
See also
media clip section
MH/BE dictionaries
media clip section
MH/BE dictionaries 725
B entry 724, 725
E entry 724, 725
media clip section objects 723-725
beginning and ending offsets 724
See also
media clip section dictionaries
media criteria dictionaries 716-717
A entry 716
C entry 716
D entry 717
L entry 717
O entry 717
P entry 717
R entry 717
renditions 715
S entry 717
Type entry 716
V entry 717
Z entry 717
media duration dictionaries 726, 727
S entry 727
T entry 727
Type entry 727
media offset dictionaries 725, 732
S entry 732
Type entry 732
See also
media offset frame dictionaries
media offset marker dictionaries
media offset time dictionaries
media offset frame dictionaries 732
F entry 732
media offset marker dictionaries 732
M entry 732
media offset time dictionaries 732
T entry 732
media permissions dictionaries 720, 722, 722
TF entry 722
Type entry 722
media play parameters 725-727
See also
media play parameters dictionaries
media play parameters dictionaries 719, 725, 734
BE entry 725
D entry 721
F entry 721
MH entry 725
PL entry 718, 725
playback volume 713
Type entry 725
See also
media play parameters
MH/BE dictionaries
media play parameters
MH/BE dictionaries 726-727
A entry 726
C entry 726
D entry 726, 727
F entry 726
RC entry 727
V entry 713, 726
media player info dictionaries 733, 735
BE entry 735
MH entry 735
PID entry 735
Type entry 735
media players dictionaries 721, 725, 733-735
A entry 718, 734, 735
MU entry 718, 734, 735
NU entry 734, 735
Type entry 734
See also
media player info dictionaries
media rendition dictionaries 719
C entry 719
P entry 719
SP entry 718, 719
media renditions 715, 718-719, 725
See also
media rendition dictionaries
media screen parameters 728-733
See also
media screen parameters dictionaries
media screen parameters dictionaries 719, 728
BE entry 728
MH entry 728
Type entry 728
See also
media screen parameters
MH/BE dictionaries
media screen parameters
MH/BE dictionaries 728, 729
B entry 729
F entry 729, 729
M entry 729, 730
O entry 729
W entry 728
media types (multimedia) 711, 1028
MediaBox entry (page object) 120, 123, 606, 607, 891, 953
MediaClip object type 720
MediaDuration object type 727
Index
1147
MediaOffset object type 732
MediaPermissions object type 722
MediaPlayerInfo object type 735
MediaPlayers object type 734
MediaPlayParams object type 725
MediaScreenParams object type 728
medium, output
See output medium
membership dictionaries, optional content
See optional content membership dictionaries
menu bar, hiding and showing 548
menu items 636
as named actions 1023
meshes
Coons patch. See type 6 shadings
free-form Gouraud-shaded triangle. See type 4 shad-
ings
lattice-form Gouraud-shaded triangle. See type 5 shad-
ings
tensor-product patch. See type 7 shadings
metadata 769, 771-775, 1030-1031
date stamp 1030-1031
document information dictionary 771-773
for documents 116
encryption of 98, 110
for form XObjects 329
for
ICCBased color spaces 223
for marked content 775
for pages 122
for sampled images 312
unencrypted 101, 106, 107
version compatibility 1030
See also
document information dictionary
metadata streams
Metadata entry 774, 775
document catalog 116, 774
embedded font stream dictionary 438
ICC profile stream dictionary 223
image dictionary 64, 312
page object 122
property list 775
type 1 form dictionary 329
Metadata object type 774
metadata stream dictionaries 774
in property lists 775
Subtype entry 774
Type entry 774
metadata streams 771, 773-775, 1030-1031
document information dictionary, compared with 773
for documents 116
for embedded font programs 438
encryption not recommended for 773
filters not recommended for 773
for form XObjects 329
for
ICCBased color spaces 223
for pages 122
for sampled images 312
See also
metadata stream dictionaries
metadata subtypes
XML 774
MH dictionaries (multimedia objects) 713-714
MH entry
media clip data dictionary 721
media clip section dictionary 723
media play parameters dictionary 725
media player info dictionary 735
media screen parameters dictionary 728
rendition dictionary 715, 716
Mic annotation icon 601
Microsoft Corporation
TrueType 1.0 Font Files Technical Specification 387,
432, 1062
Windows
®
operating system 19, 387, 395
Microsoft Unicode character encoding 401
Middle block alignment 854
MIDI (Musical Instrument Digital Interface) file format
1028
MIME (Multipurpose Internet Mail Extensions)
application/pdf content type 664
application/vnd.fdf content type 670
application/x-www-form-urlencoded content type 886
and Linearized PDF 940, 941
media type name 158
multipart/form-data content type 654
text/html content type 882
min entry (Zoom subdictionary, optional content usage
dictionary) 351, 353
MinBitDepth object type 717
minimum bit depth dictionaries 717
M entry 718
Type entry 717
V entry 718
minimum screen size dictionaries 717, 718
M entry 718
Type entry 718
V entry 718
Minion
®
typeface 1213
MinScreenSize object type 718
minus sign () character 133
misregistration of colorants 605, 890, 902
MissingWidth entry (font descriptor) 384, 428
miter limit 181, 187
Index
1148
forced into valid range 184
M operator 189, 915
ML entry (graphics state parameter dictionary) 190
and
S operator 201
miter line join style 186, 201
Mix entry (sound action dictionary) 626, 1022
mixing hints. See
DeviceN mixing hints dictionary
MixingHints entry
DeviceN color space attributes dictionary 242, 243
MK entry
screen annotation dictionary 602
widget annotation dictionary 603, 1023
ML entry (graphics state parameter dictionary) 190
MMType1 font type 381, 386, 436
MN entry (printer’s mark annotation dictionary) 896
mod operator (PostScript) 149, 917
ModDate entry
document information dictionary 772, 777
embedded file parameter dictionary 158
Mode entry
movie action dictionary 627
movie activation dictionary 742
modification date
annotation 571
document 769, 771, 772, 777, 1030
form XObject 329, 777
page 119, 777
page-piece dictionaries and 119, 329, 777
trap network 905
Web Capture content set 884, 885
modification detection and prevention. See MDP
Modify annotation usage rights 694
Modify embedded files usage rights 695
Modify signatures usage rights 695
monitor specifiers 738
Monospace font classification (Tagged PDF) 822
monospaced fonts 363
mouse 9, 578, 613
annotations 568, 574, 578, 587, 603, 610
button fields 647
check box fields 648
document-level navigation 550
outline items 554
pop-up help labels 627
read-only form fields unresponsive to 638
submit-form actions, tracking in 664
trigger events related to 611, 614
URI actions, tracking in 624-625
widget annotations 604, 605
MOV (QuickTime) file format 1028
moveto operator (PostScript) 22, 915
movie action dictionaries 626-627
Annotation entry 627
Mode entry 627
and movie activation dictionaries, compared 626
Operation entry 627
S entry 627
Start entry 627
T entry 627
Movie action type 615, 627, 1022
movie actions 615, 626-627, 1022
and movie annotations 626, 627
operations. See movie operations
See also
movie action dictionaries
movie annotations
movies
movie activation dictionaries 741, 742-743
Duration entry 742
FWPosition entry 743
FWScale entry 743, 1029
Mode entry 742
and movie action dictionaries, compared 626
in movie annotations 602
Rate entry 742
ShowControls entry 742
Start entry 742
Synchronous entry 743
Volume entry 742
movie annotation dictionaries 601-602
A entry 572, 602, 741
Movie entry 601, 741
Subtype entry 601
Movie annotation type 581, 582, 601, 674
movie annotations 9, 581, 601-602, 741
annotation rectangle 626, 743
and file specifications 156
and movie actions 626, 627
plug-in extensions 579
title 627
See also
movie actions
movie annotation dictionaries
movies
movie dictionaries 741
Aspect entry 741, 743, 1029
F entry 741
in movie annotations 601
Poster entry 741
Rotate entry 741
Movie entry (movie annotation dictionary) 601, 741
movie files 741
movie operations 627
Pause 627
Index
1149
Play 627
Resume 627
Stop 627
MovieActions entry (legal attestation dictionary) 701
movies 9, 568, 741-743
asynchronous 743
bounding box 741
controller bar 742
and file specifications 156
magnification (zoom) factor 743
and movie actions 610, 626
and movie annotations 601
operations. See movie operations
play mode 742
poster image 741
rotation 741
synchronous 743
time scale 742
See also
movie actions
movie activation dictionaries
movie annotations
movie dictionaries
MP operator 166, 778, 779, 915
MP3 (MPEG Audio Layer-3) file format 1028
MP4 (MPEG-4) file format 1028
MPEG (MPEG-2 Video) file format 1028
MR rendition type 716
MS entry (3D view dictionary) 758
Msg entry (UR transform parameters dictionary) 693
MU entry (media players dictionary) 718, 734, 735
mul operator (PostScript) 149, 917
muLaw sound encoding format 740
multi-language text array 869-870
Multiline field flag (text field) 653
multimedia 711-739
floating windows 729-731, 1029
recommended media types 711, 1028
trigger events related to 611
viability of objects 713-714
See also
rendition actions
screen annotations
multimedia features 711-767
See
alternate presentations
movies
multimedia
sounds
multimedia objects
MH/BE dictionaries 713-714
playing specifications 725
viability 713-714
See also
rendition objects
multipart/form-data content type (MIME) 654
multiple-byte character codes
in CID-keyed fonts 403, 404
in file specifications 155
in font names 389
and text-showing operators 378, 379
and word spacing 370
multiple master font dictionaries 386-387
BaseFont entry 386
Subtype entry 386
multiple master fonts 386-387
instances 386, 387
naming conventions 387
PostScript name 386
snapshots 387
substitution 1017
See also
multiple master font dictionaries
Multiply blend mode 491, 507
Multipurpose Internet Mail Extensions (MIME), Part One:
Format of Internet Message Bodies (Internet RFC
2045) 654, 664, 720, 882, 887, 1062
Multipurpose Internet Mail Extensions (MIME), Part Two:
Media Types (Internet RFC 2046) 158, 1062
MultiSelect field flag (choice field) 656, 657
multitone color 205, 207, 238-239
duotone 238, 249-252
examples 249-254
quadtone 238, 252-254
must honor
See
MH dictionaries (multimedia objects)
Myriad
®
typeface 1213
N
N entry
appearance dictionary 579, 579, 640, 678, 747, 814,
896, 903, 905
bead dictionary 561, 973
ICC profile stream dictionary 223
linearization parameter dictionary 947
media clip dictionary 720
named-action dictionary 629
object stream dictionary 77
projection dictionary 760
rendition dictionary 715, 716
target dictionary 619
type 2 function dictionary 146
user property dictionary 805
Index
1150
N highlighting mode (none) 587, 603
n keyword 70
n operator 166, 200, 205, 780, 782, 915
NA entry (navigation node dictionary) 567, 568
name dictionary 114, 124-125
AlternatePresentations entry 125, 743
AP entry 125, 580
Dests entry 125, 553
EmbeddedFiles entry 125, 156, 157, 617
IDS entry 125, 875, 876, 877, 878, 882, 889
JavaScript entry 125, 668, 676
in Linearized PDF 971
Pages entry 125, 669
Renditions entry 125
Templates entry 125, 669
URLS entry 125, 875, 876, 877, 878, 882
Name entry
Crypt filter parameter dictionary 66, 107
FDF named page reference dictionary 681
file attachment annotation dictionary 600
image dictionary 312, 523, 1013
optional content configuration dictionary 346, 347
optional content group dictionary 334, 335
rubber stamp annotation dictionary 598
signature dictionary 687, 688
sound annotation dictionary 601
text annotation dictionary 586
Type 1 font dictionary 383, 1014
type 1 form dictionary 330, 1013
Type 3 font dictionary 390
User subdictionary, optional content usage dictionary
351, 353
viewport dictionary 704
name objects 26, 27, 32-34, 1005-1006
character encodings for 1006
for destinations 553
as dictionary keys 35, 466, 475
as dictionary values 131
hexadecimal character codes in 33, 158
length limit 33, 34, 920
syntax 32-34, 1005-1006
UTF-8 encoding 34
for version specifications 673
name registry, PDF 937-938
“name” table (TrueType font) 388
name tree nodes 135-136
intermediate 135
Kids entry 135, 135
leaf 135
Limits entry 135
Names entry 135, 135
root 135
name trees 134-138
for appearance streams 125, 580
for destinations 125, 553
dictionaries, compared with 134
as dictionary values 131
for element identifiers 786
for embedded file streams 125, 157
for JavaScript actions 125, 157, 668
keys in 134, 135
in name dictionary 124, 125
for named pages 125, 669
nodes. See name tree nodes
number trees, compared with 139
for template pages 125, 669
values in 134, 135
for Web Capture content sets 125, 875, 878, 882, 889
named-action dictionaries 629
N entry 629
S entry 629
Named action type 615, 629, 1023
named actions 615, 628-629, 1023
FirstPage 628
LastPage 628
NextPage 628
PrevPage 628
See also
named-action dictionaries
named destination dictionaries 553
D entry 553
named destination hint table (Linearized PDF) 951, 966
named destinations 551, 553
in document catalog 112, 114
go-to actions as targets of 553
in Linearized PDF 949, 956, 970, 971
in name dictionary 125
unique name (Web Capture) 879, 880
See also
named destination dictionaries
named page reference dictionaries
See FDF named page reference dictionaries
named pages 122, 125, 669
in import-data actions 669
invisible. See template pages
in JavaScript actions 669
named resources 128
color spaces as 129
external objects (XObjects) as 129, 165
font dictionaries as 129, 359
in form XObjects 328
graphics state parameter dictionaries as 129
in Linearized PDF 954
patterns as 129
procedure sets as 129, 770
property lists as 129, 775, 779, 780
Index
1151
shading dictionaries as 129
in type 3 fonts 391
names
appearance states 648, 651, 905
attribute classes 786, 788, 802, 803, 842
attribute owners 801
blend modes 490, 516
character encodings 384, 396, 397, 401, 441
characters. See character names
CMaps, predefined 412-415, 419, 423
color space families 210, 215, 232, 235, 239
color spaces 210, 232, 237, 240, 257, 324
colorants 235, 236, 237, 240, 241, 242, 466, 475, 912
conversion engines (Web Capture) 888
destinations 553
dictionary 114, 124-125
embedded spaces in 1005
first-class 158, 937-938
fonts. See font names
form XObjects 326, 330
glyph classes 433
graphics state parameter dictionaries 189, 190
halftones 466-467, 469, 472, 474, 475
images 312
JavaScript scripts 676
marked-content tags 779
object subtypes 36
object types 36
patterns 258, 264, 268, 269
registered 36, 92, 684, 778, 889, 899, 1004
See also name registry, PDF
rendering intents 190, 230, 310
resources 328, 391, 1016
second-class 938
shadings 273
spot functions, predefined 458, 1017
structure types 34, 787, 789
third-class 938
XX prefix 938
See also
name objects
Names entry
document catalog 114, 124, 956, 971
name tree node 135, 135
native color space (output device) 277, 447, 448, 450
CIE-based color mapping 449
and flattening of transparent content 545
and halftones 456, 476
and overprinting 541
page group, inherited by 511, 512, 516, 527
process colors, specification of 532, 533
rendering intents, target of 543, 544
transfer functions 454, 455, 456
and transparent overprinting 535
natural language specification 769, 863, 864-870
for CIDFont character encodings 431
for documents 864, 866
hierarchy 866-869
language identifiers 116, 788, 865
for marked-content sequences 864, 866-868, 869
for structure elements 864, 866, 867, 868-869
in Tagged PDF 816
in Unicode 132, 865, 871, 872, 873
navigation 550-566
document-level 550-557
See also
destinations
document outline
thumbnail images
page-level 558-566
See also
articles
page labels
presentations
sub-page 566-568
navigation controls, hiding and showing 548
navigation node dictionaries 567
Dur entry 567
NA entry 567, 568
Next entry 567, 567, 568
PA entry 567, 567, 568
Prev entry 567, 567, 568
Type entry 567
navigation nodes 122, 566-568
current 567, 568
NavNode object type 567
NChannel color spaces 239-245, 247-249
NChannel subtype (DeviceN color spaces) 242
ne operator (PostScript) 149, 918
NeedAppearances entry (interactive form dictionary) 614,
635
neg operator (PostScript) 149, 917
Netscape Communications Corporation
Client-Side JavaScript Reference 668, 1063
network access 68, 939, 940, 941, 969-973
See also Forms Data Format (FDF)
new features
PDF 1.5 5-6
PDF 1.6 4-5
New York typeface 388
newline characters 26, 30
NewParagraph annotation icon 586
NewWindow entry
launch action dictionary 622
remote go-to action dictionary 617
Next entry
Index
1152
action dictionary 610, 632
navigation node dictionary 567, 567, 568
outline item dictionary 554, 555
next-level media clip objects 723
next-level media object 725
NextPage named action 628
See also
named-action dictionaries
NM entry (annotation dictionary) 571, 583
no-op actions (obsolete) 616
NoExport field flag 638, 663, 666
nonbreaking space character 928
None annotation state 585
None border style 849
None colorant name
DeviceN color spaces 240-241
in
Separation color spaces 236
None decryption method (crypt filters) 108
None line ending style 593
None list numbering style 862
None page scaling 550
None predictor function (LZW and Flate encoding) 51, 52
None text decoration type 857
NonEmbeddedFonts entry (legal attestation dictionary)
702
NonFullScreenPageMode entry (viewer preferences
dictionary) 548
non-isolated groups 499, 506, 508
and backdrop color removal 507
bounding box 526
and CompatibleOverprint blend mode 537, 538
compositing in 526
group backdrop 526
group color space, inherited from parent group 530
group compositing formulas 510
immediate backdrop (group elements) 510
initial backdrop 502, 510
knockout 510
knockout groups, nested within 510
and overprinting 537, 538
page group as 510, 525
painting 526
patterns implicitly enclosed in 528
non-knockout groups 499
and CompatibleOverprint blend mode 537, 538
compositing in 508
and overprinting 537, 538
tiling patterns implicitly enclosed in 528
non-Latin character sets 396
in check box fields 653
non-Latin writing systems 396
in check box fields 650
nonprinting characters 30, 31
nonseparable blend modes 492-493
spot colors, inapplicable to 536
nonstroking alpha constant, current 182, 192, 519
and fully opaque objects 542
initialization 527
and overprinting 538, 539
setting 519
and transparency groups 519
nonstroking color, current 180, 184
DeviceCMYK color space 213, 258, 915
DeviceGray color space 212, 258, 914
DeviceN color spaces 240
DeviceRGB color space 213, 258, 915
f operator 202
Pattern color spaces 265, 269
sampled images 311
Separation color spaces 235
setting 206, 210, 258, 914, 915
stencil masking 307
text, showing 361
nonstroking color space, current 180
CIE-based color spaces 215
DeviceCMYK color space 213, 258, 915
DeviceGray color space 212, 258, 914
DeviceRGB color space 213, 258, 915
Indexed color spaces 232
Pattern color spaces 269
setting 206, 210, 257-258, 914
NonStruct standard structure type 829
Nonsymbolic font flag 429
nonsymbolic fonts 396, 400, 429, 430
base encoding 397
nonterminal fields 637
non-white-preserving blend modes
spot colors, inapplicable to 536
nonzero overprint mode 229, 255-256
and transparency 536-537
nonzero winding number rule 202-203
clipping 205, 372, 916
filling 200, 202, 913, 914
normal appearance (annotation) 578
and real content 814
for unknown annotation types 579
Normal blend mode 374, 486, 491
for annotations 578, 583
and backdrop color removal 506, 507
blend function 494
Compatible blend mode equivalent to 493, 536
and CompatibleOverprint 537, 541
current blend mode initialized to 527
Index
1153
as default blend mode 516
and fully opaque objects 542
in isolated groups 507
and overprinting 534, 535, 538
in page group 511
patterns, painting of 529
for spot colors 536
Normal font stretch 426
Normal line height 856
NoRotate annotation flag 574, 574, 575, 586
not operator (PostScript) 149, 918
NotApproved annotation icon 598
.notdef character name 398, 409, 425, 428
.notdef glyph name 399
notdef mappings 422, 424, 425
Note annotation icon 586
Note standard structure type 835
NotForPublicRelease annotation icon 598
NoToggleToOff field flag (button field) 648, 651
NoView annotation flag 574, 632
NoZoom annotation flag 574, 574, 586
NP entry (additional-actions dictionary, obsolete) 1021
NTSC (National Television Standards Committee) video
standard 451
NU entry (media players dictionary) 734, 734, 735
null (NUL) character 26
in unique names (Web Capture) 880
null object (
null) 27, 38, 39
in
AnnotStates arrays (trap networks) 905
as choice field value 657
as dictionary value 35, 39, 131
as indirect reference to nonexistent object 39, 40
number format arrays 705-709
number format dictionaries 705-708
C entry 707
D entry 708
F entry 707
FD entry 708
O entry 708
PS entry 708
RD entry 708
RT entry 708
SS entry 708
Type entry 707
U entry 707
number sign (
#) character
as hexadecimal escape character in names 33, 34, 389,
1005-1006
in uniform resource locators (URLs) 878
number tree nodes 139
intermediate 139
Kids entry 139
leaf 138, 139
Limits entry 139
Nums entry 139
root 138, 139
number trees 138-139
as dictionary values 131
keys 138, 139
name trees, compared with 139
nodes. See number tree nodes
for page labeling ranges 114, 559
structural parent tree 786, 797
values 139
numbers 29
See also numeric objects
numeric characters 434
numeric objects 28-29
as dictionary values 131
integer 28
range and precision 28
real 28
Nums entry (number tree node) 139
O
O entry
3D view dictionary 758, 758
additional-actions dictionary 611, 612, 1021
attribute object 801, 804, 843, 845, 862, 863
encryption dictionary 98, 101, 101-102, 103
floating window parameters dictionary 730, 731
hint stream dictionary 951
linearization parameter dictionary 947, 952, 960, 964
media criteria dictionary 717
media screen parameters
MH/BE dictionaries 729
number format dictionary 708
rectilinear measure dictionary 706
Web Capture content set 881, 882, 883, 889, 1031
Windows launch parameter dictionary 622
O highlighting mode (outline) 587, 603
O trigger event (page) 612
Obj entry (object reference dictionary) 796
obj keyword 34, 40, 78
object alpha 503, 504
in isolated groups 507
notation 505
object collections (object streams) 78
object color 504
and rendering intents 543
and soft masks 513
object digests 684
calculation of 1037-1044
Index
1154
See also
transform methods
transform parameters
object hierarchy
FDF 672
PDF 112
object identifiers 39
cross-reference table, reconstruction of 921
and encryption 95
and incremental updates 75
shared (Linearized PDF) 959, 960, 967
in updating example 992, 993, 995, 997, 998, 1000
object numbers 39
in cross-reference table 69-71, 73, 75
and encryption 95
in FDF files 670
in indirect object references 40
subsection entry constraints 70
in updating example 993, 997, 998
object opacity 495, 517
in knockout groups 508
notation 496, 501
and overprinting 535
patterns 528
specifying 518
and tiling patterns 496
object reference dictionaries 787, 796
Obj entry 796
Pg entry 796
Type entry 796
object references (logical structure) 797, 798
and
Form standard structure type 841
and link elements (Tagged PDF) 835, 836, 839
See also
object reference dictionaries
object shape 495, 504, 517
current clipping path 513
glyphs 517
image masks 517
in isolated groups 507
in knockout groups 508, 509
notation 496, 501, 505
path objects 517
patterns 517, 528
sample images 517
sh operator 517
shading patterns 517
specifying 517
tiling patterns 496, 517
and topmost object 542
in transparency groups 503
object signatures
See object digests
object stream dictionaries 77
Extends entry 77, 78
First entry 77
Length entry 77
N entry 77
Type entry 77
object streams 69, 76-81
compatibility with PDF 1.4 85-91
indirect objects in 40
in Linearized PDF 943
object collections 78
performance 78
stream data 78
See also
object stream dictionaries
object subtypes 35-36
Embedded 744
embedded files 158
external objects (XObjects) 302, 303
object types 35-36
3D 752
3DBG 764
3DRef 754
3DView 757
Action 610
Annot 570, 993, 998
Bead 561
Border 576
Catalog 114, 976, 978
CMap 419
CryptFilter 108
CryptFilterDecodeParms 66
EmbeddedFile 158
Encoding 397
ExtGState 190
Filespec 155, 162
FixedPrint 607
Font 36, 383, 390, 407, 423, 978
FontDescriptor 426
FWParams 730
Group 331
Halftone 466, 467, 469, 472, 474, 475
Mask 521
MCR 792
Measure 705
MediaClip 720
MediaDuration 727
MediaOffset 732
MediaPermissions 722
MediaPlayerInfo 735
MediaPlayers 734
MediaPlayParams 725
MediaScreenParams 728
Metadata 774
Index
1155
MinBitDepth 717
MinScreenSize 718
NavNode 567
OBJR 796
ObjStm 77
OCG 334
OCMD 336
OPI 908, 911
Outlines 554, 976, 978
OutputIntent 899
Page 119, 669, 976, 978, 993
PageLabel 559
Pages 118, 976, 978
Pattern 262, 272
Rendition 716
Sig 686
SigFieldLock 659
SigRef 689
SlideShow 744
SoftwareIdentifier 736
Sound 739
SpiderContentSet 882
StructElem 787
StructTreeRoot 786
SVCert 661
Template 669
Thread 561
Timespan 733
Trans 563
TransformParams 692, 693, 695
Viewport 704
XObject 302, 303, 310, 328, 523
XRef 83
objects 9, 23, 24
compressed 76
in FDF 670
fully opaque 542-543
generation number. See generation numbers
hierarchy 112, 672
identifier. See object identifiers
indirect references. See indirect object references
length 16
as logical structure content items 785, 786, 787, 790,
796-797, 797
number. See object numbers
processing 17
subtype. See object subtypes
syntax 27-41
topmost 542
type. See object types
See also
array objects
boolean objects
compressed objects
dictionary objects
direct objects
external objects (XObjects)
form XObjects
function objects
graphics objects
group XObjects
image XObjects
indirect objects
inline image objects
integer objects
multimedia objects
null object (
null)
numeric objects
page objects
path objects
PostScript XObjects
real objects
reference XObjects
shading objects
stream objects
string objects
text objects
transparency group XObjects
OBJR object type 796
ObjStm object type 77
OC entry
alternate image dictionary 317, 319
annotation dictionary 573
image dictionary 313, 319, 344
type 1 form dictionary 330
OC marked-content tag 340, 341
OCG object type 334
OCGs entry
optional content membership dictionary 336, 336,
337, 342
optional content properties dictionary 345
usage application dictionary 352, 353, 356
OCMD object type 336
OCProperties entry (document catalog) 116, 345, 355
OEB (Open eBook) file format
standard attribute owner 843
Tagged PDF 821
OEB-1.00 standard attribute owner 843, 844
Off appearance state
check box field 648
radio button field 651
OFF entry (optional content configuration dictionary) 346
OFF state (optional content groups) 335, 336, 337, 341,
346, 348, 353, 355, 629, 630
offset printing presses 902
OID entry (certificate seed value dictionary) 661
Index
1156
OLE (Object Linking and Embedding) 74
ON entry (optional content configuration dictionary) 346
ON state (optional content groups) 335, 336, 337, 341, 346,
348, 353, 354, 355, 629, 630
Once play mode (movie) 742
OneColumn page layout 115
OnInstantiate entry (3D stream dictionary) 753, 754
Online annotation usage rights 694
Online form usage rights 694
OP entry
graphics state parameter dictionary 191, 254, 702
rendition action dictionary 631
op entry (graphics state parameter dictionary) 191, 254
opacity 11, 165, 484-485
alpha source parameter 182, 193, 311
anti-aliasing 495
backdrop 497, 498
in basic compositing formula 488
computation 494-498
current alpha constant 182, 192, 311
fully opaque objects 542-543
in JPEG2000 images 64
notation for 487
soft masks 486, 495, 518
specifying 517-519
See also
constant opacity
group opacity
mask opacity
object opacity
result opacity
source opacity
opacity constant 496
opaque imaging model 11, 484, 1018
clipping 486, 513
graphics objects, painting of 165
graphics state, initialization for patterns 528
knockout groups compared to 508
masked images 319
overprinting 254, 534, 535, 539-541
page group, flattening of 512, 544
shading patterns 275
spot colors 532
Open entry
pop-up annotation dictionary 599
text annotation dictionary 586
open paths 195
Open play mode (movie) 742
Open Prepress Interface (OPI) 890, 907-912, 1033
proxies 333, 770, 890, 907-912
server 907, 908
versions 907, 908, 911
1.3 907, 908-911
2.0 907, 911-912, 1033
See also
OPI comments
OPI dictionaries
OPI version dictionaries
Open Prepress Interface (OPI) Specification (Adobe Techni-
cal Note #5660) 908, 1058, 1059
OpenAction entry (document catalog) 115, 551, 609, 612,
949, 952, 964, 969, 1034
URI actions ignored for 624
OpenArrow line ending style 593
OpenType embedded font subtype 408, 437, 438
OpenType font programs
“CFF” table 437, 439, 440
“cmap” table 439
embedded 16
OpenType Font Specification (Adobe Technical Note) 437,
439, 1058
OpenType fonts 6, 437, 438, 439-440
operands 11, 126, 164
Operation entry (movie action dictionary) 627
operators, PDF 11, 164, 913-916
' (apostrophe) 166, 368, 371, 377, 916
" (quotation mark) 166, 368, 371, 377, 916
B 166, 200, 538, 913
b 166, 195, 200, 538, 913
B* 166, 200, 538, 913
b* 166, 200, 538, 913
BDC 166, 340, 341, 778, 779, 780, 790, 913
BI 166, 322, 913
BMC 166, 641, 778, 779, 913
boolean 28
BT 166, 360, 371, 375, 641, 779, 841, 913
BX 127, 166, 339, 913
c 166, 196, 198, 913
categories 166
cm 166, 172, 180, 189, 308, 913
CS 166, 206, 210, 212, 213, 240, 257, 259, 261, 914
cs 166, 206, 210, 212, 213, 240, 257, 259, 261, 914
d 166, 189, 914
d0 166, 390, 392, 914
d1 166, 259, 390, 392, 393, 914
defined 126
Do 166, 261, 265, 269, 273, 302, 303, 305, 309, 313,
326, 327, 330, 344, 526, 527, 542, 543, 544, 782, 793,
794, 797, 914
DP 166, 340, 778, 779, 780, 914
EI 166, 322, 324, 914
EMC 166, 340, 341, 641, 778, 779, 790, 914
ET 166, 371, 375, 641, 779, 841, 914
EX 127, 166, 339, 914
F 166, 200, 914
Index
1157
f 12, 166, 180, 195, 199, 200, 202, 206, 259, 262, 265,
269, 273, 914
f* 166, 200, 202, 914
G 166, 206, 210, 211, 212, 258, 259, 914
g 166, 206, 210, 211, 212, 258, 259, 306, 361, 914
gs 166, 189, 192, 259, 367, 373, 448, 520, 914
h 166, 195, 197, 201, 914
i 166, 189, 478, 914
ID 166, 322, 324, 914
implementations of 770
J 166, 189, 914
j 166, 189, 914
K 166, 206, 210, 211, 213, 258, 914
k 166, 206, 210, 211, 213, 258, 915
l 166, 196, 201, 915
M 166, 189, 915
m 166, 196, 202, 915
MP 166, 778, 779, 915
n 166, 200, 205, 780, 782, 915
ordering rules 166-168
painting 11, 12, 21, 184, 204, 236, 237, 240, 241, 254,
256, 262, 263, 264, 273
postfix notation 126, 164
procedure sets 769, 770, 1030
Q 166, 184, 189, 205, 264, 308, 327, 362, 372, 641, 782,
915, 920, 1033
q 166, 184, 189, 205, 264, 308, 327, 641, 782, 915, 920,
1033
re 166, 195, 196, 197, 915
relational 28
RG 166, 206, 210, 211, 213, 258, 259, 915
rg 166, 206, 210, 211, 213, 258, 259, 531, 537, 915
ri 166, 189, 230, 256, 259, 915
S 12, 166, 180, 195, 199, 200, 201, 206, 259, 262, 273,
392, 915
s 166, 200, 915
SC 166, 206, 210, 212, 213, 234, 257, 259, 915
sc 166, 206, 210, 212, 213, 234, 258, 259, 288, 306, 915
SCN 166, 210, 234, 235, 240, 258, 259, 261, 264, 265,
268, 915
scn 166, 210, 234, 235, 240, 258, 259, 261, 264, 265,
268, 269, 915
sh 166, 259, 273, 274, 275, 479, 517, 528, 915
T* 166, 368, 371, 376, 915
Tc 166, 368, 915
TD 166, 371, 376, 916
Td 166, 360, 376, 915
Tf 36, 166, 191, 359, 360, 368, 406, 641, 916
TJ 166, 364, 368, 370, 378, 380, 916, 1014
Tj 166, 259, 260, 265, 269, 273, 360, 361, 362, 363, 364,
368, 377, 379, 424, 916, 1014
TL 166, 368, 916
Tm 166, 376, 641, 916
Tr 166, 362, 368, 916
Ts 166, 368, 916
Tw 166, 368, 916
Tz 166, 368, 916
v 166, 196, 199, 916
W 166, 195, 202, 204, 205, 780, 782, 916
w 166, 183, 189, 362, 916
W* 166, 195, 202, 204, 205, 780, 782, 916
y 166, 196, 199, 916
See also
clipping path operators
color operators
compatibility operators
graphics operators
graphics state operators
inline image operators
marked-content operators
path construction operators
path-painting operators
shading operator
text object operators
text-positioning operators
text-showing operators
text state operators
Type 3 font operators
XObject operator
operators, PostScript 358, 913-916
abs 149, 917
add 149, 917
and 149, 918
atan 149, 917
beginbfchar 422, 424, 443, 445
beginbfrange 422, 443, 445, 446
begincidchar 422, 424
begincidrange 422
begincmap 422
begincodespacerange 422, 424, 443, 444
beginnotdefchar 422, 425
beginnotdefrange 422, 425
beginrearrangedfont 422
beginusematrix 422
bitshift 149, 918
ceiling 149, 917
cleartomark 437, 438
clip 916
closepath 913, 914, 915
concat 913
copy 149, 918
cos 149, 917
curveto 913, 916
cvi 149, 917
cvr 149, 917
div 149, 917
dup 149, 918
endbfchar 422, 424, 443
endbfrange 422, 443
Index
1158
endcidchar 422, 424
endcidrange 422
endcmap 422
endcodespacerange 422, 424, 443, 444
endnotdefchar 422, 425
endnotdefrange 422, 425
endrearrangedfont 422
endusematrix 422
eoclip 916
eofill 913, 914
eq 149, 918
exch 149, 918
exp 149, 917
false 149, 918
fill 913, 914
findfont 303
floor 149, 917
ge 149, 918
grestore 915, 920, 1033
gsave 915, 920, 1033
gt 149, 918
idiv 149, 917
if 28, 149, 918
ifelse 28, 149, 918
index 149, 918
le 149, 918
lineto 22, 915
ln 149, 917
log 149, 917
lt 149, 918
mod 149, 917
moveto 22, 915
mul 149, 917
ne 149, 918
neg 149, 917
not 149, 918
or 149, 918
pop 149, 918
restore 1033
roll 149, 918
round 149, 917
save 1033
selectfont 916
setcachedevice 392, 914
setcharwidth 392, 914
setcmykcolor 914, 915
setcolor 915
setcolorspace 914
setdash 914
setflat 914
setgray 914
sethalftone 1017
setlinecap 914
setlinejoin 914
setlinewidth 916
setmiterlimit 915
setrgbcolor 915
setscreen 1017
shfill 915
show 916
sin 149, 917
sqrt 149, 917
stroke 913, 915
sub 149, 917
true 149, 918
truncate 149, 917
in type 4 (PostScript calculator) functions 149, 917-
918
usecmap 422
usefont 422
xor 149, 918
OPI. See Open Prepress Interface
OPI color types 910
Process 910
Separation 910
Spot 910
OPI comments (PostScript) 333, 907, 908-912, 1033
%ALDImageAsciiTag 911
%ALDImageColor 910
%ALDImageColorType 910
%ALDImageCropFixed 909
%ALDImageCropRect 909
%ALDImageDimensions 909
%ALDImageFilename 908
%ALDImageGrayMap 910
%ALDImageID 908
%ALDImageOverprint 910
%ALDImagePosition 909
%ALDImageResolution 909
%ALDImageTint 910
%ALDImageTransparency 910
%ALDImageType 910
%ALDObjectComments 908
%%ImageCropRect 912
%%ImageDimensions 911
%%ImageFilename 911
%%ImageInks 912
%%ImageOverprint 912
%%IncludedImageDimensions 912
%%IncludedImageQuality 912
%%MainImage 911
%%TIFFASCIITag 911
OPI dictionaries 157, 333, 907, 908-912, 1033
and trap networks 905
version 1.3 908-911
Color entry 910
ColorType entry 910
Comments entry 908
CropFixed entry 909
Index
1159
CropRect entry 909
F entry 908, 1033
GrayMap entry 910
ID entry 908
ImageType entry 910
Overprint entry 910
Position entry 909
Resolution entry 909
Size entry 909
Tags entry 911
Tint entry 910
Transparency entry 910
Type entry 908
Version entry 908
version 2.0 911-912
CropRect entry 912
F entry 911, 1033
IncludedImageDimensions entry 912
IncludedImageQuality entry 912
Inks entry 912
MainImage entry 911
Overprint entry 912
Size entry 911, 912
Tags entry 911
Type entry 911
Version entry 911
OPI entry
image dictionary 312, 523, 907
type 1 form dictionary 329, 907
OPI object type 908, 911
OPI: Open Prepress Interface Specification (Adobe Systems
Incorporated) 908, 1058
OPI version dictionaries 312, 329, 907-908, 911
1.3 entry 907
2.0 entry 907
OPM entry (graphics state parameter dictionary) 191, 255
Opt entry
check box field dictionary 650
choice field dictionary 657, 657, 1024
FDF field dictionary 674, 678
radio button field dictionary 652, 653
optimization of PDF files 17
optional content 334-356
with alternate images 317, 319
and annotations 344
configuring 344-356
in content streams 340-343
in form XObjects 330, 344
hiding 339
in image XObjects 344
intent 338, 346
visibility 336
optional content configuration dictionaries 345-349
AllPages list mode 347
alternate 345
AS entry 347, 349, 352, 353, 356
BaseState entry 346, 355
Creator entry 346
default 345
Intent entry 346, 350
ListMode entry 347
Locked entry 348
Name entry 346, 347
OFF entry 346
ON entry 346
Order entry 347, 348
RBGroups entry 348, 629
VisiblePages list mode 347
optional content group dictionaries 334-335
Intent entry 335, 335, 338, 339
Name entry 334, 335
Type entry 334, 335
Usage entry 335, 335, 350
optional content group panel, hiding and showing 115,
548
optional content groups 334-339, 344, 345
determining state 355-356
initialization 335
locking 348
OFF state 335, 336, 337, 341, 346, 348, 353, 355, 629,
630
ON state 335, 336, 337, 341, 346, 348, 353, 354, 355,
629, 630
setting state 629
Toggle state 629, 630
Unchanged state 346
See also
optional content group dictionaries
optional content membership dictionaries 330, 335-338,
344
OCGs entry 336, 337, 342
P entry 336, 337, 342, 344
Type entry 336
VE entry 336, 337, 344
visibility policy 335, 336
optional content properties dictionary 345
Configs entry 345, 345
D entry 345, 345, 355
OCGs entry 345
optional content usage dictionaries 350-355
CreatorInfo entry 350
Export entry 351, 353
Language entry 350, 353
PageElement entry 351
Print entry 351, 353
User entry 351, 353
View entry 351, 353
Index
1160
Zoom entry 351, 353, 355
OptionalContent entry (legal attestation dictionary) 702
or operator (PostScript) 149, 918
orange colorant
PANTONE Hexachrome system 238
Order entry
optional content configuration dictionary 347, 348
type 0 function dictionary 143, 145, 1011
Ordering entry (CIDSystemInfo dictionary) 406, 415, 433
orthographic projection (3D artwork) 760, 761
OS entry
projection dictionary 761
software identifier dictionary 736, 737
“OS/2” table (TrueType font) 432
outline, document
See document outline
outline dictionary 115, 554, 975, 976, 978, 980
Count entry 554
First entry 554
Last entry 554
Type entry 554
outline hierarchy 115, 554, 555
example 975, 988
in Linearized PDF 945, 949, 953, 955
root 554
outline hint table (Linearized PDF) 951, 966
outline item dictionaries 554-556
A entry 555, 609, 616
AA entry (obsolete) 1018
C entry 555
Count entry 555, 955
Dest entry 555, 616
F entry 556
First entry 555
Last entry 555
Next entry 554, 555
Parent entry 555
Prev entry 554, 555
SE entry 555
Title entry 555
outline item flags 556
Bold 556
Italic 556
outline items 554-556, 988, 990
actions for 554, 555, 609
activating 554, 555, 609, 1018
closed 554, 555, 990
color 555
destinations for 551, 553, 554, 555, 1018
flags 556
and go-to actions 616
movie actions associated with 626
open 554, 555, 988
structure elements associated with 555
and trigger events 612
URI actions ignored for 624
Outlines entry (document catalog) 87, 115, 554, 975
Outlines object type 554, 976, 978
output devices
additive 234, 236, 457
bilevel 12, 14, 457, 464
black-generation function 453
CMYK 229, 455
color 14, 211, 457, 465
continuous-tone 450, 456
default halftone 457
device space 169-170, 174
displays. See displays, raster-scan
gamut 230, 231, 449
halftones 456, 457, 466
high-resolution 468
ICC profile 449
monochrome 450, 455, 456, 465
native color space. See native color space
output intents 898-902, 1032
overprinting 254, 255
paper-based 213
physical limitations 891
PostScript 21, 303, 383, 544, 770, 1013, 1017, 1033
printers. See printers
process color model 254, 447, 450
raster 12-13, 169, 184, 305, 447, 448
rendering intents 230
resolution 13, 170, 181, 184, 275, 316, 468, 470
RGB 455
smoothness tolerance, limits on 479
subtractive 234, 236, 458
transfer functions 454
undercolor-removal function 453
output intent dictionaries 116, 229, 898-902
See also PDF/X output intent dictionaries
output intent subtypes 898, 899
GTS_PDFX 899
output intents 449, 770, 890, 898-902, 1032
ICC color profiles for 225
output intent dictionaries 116, 229
subtype 898, 899
output medium 235, 890, 893
backdrop color for compositing 510, 511
crop box 120, 891, 1032
film 235, 890
imposition of pages on 510-512, 525, 526, 893, 1032
media box 120, 891
paper 890
plates 890
Index
1161
properties of 448
OutputCondition entry (PDF/X output intent dictionary)
899
OutputConditionIdentifier entry (PDF/X output intent
dictionary) 899, 900
OutputIntent object type 899
OutputIntents entry (document catalog) 116, 898
Outset border style 850
over operator (Porter and Duff) 488
overflow hint stream (Linearized PDF) 946, 950
hint table offsets in 951
in linearization parameter dictionary 947, 1034
object offsets unaffected by 958
and one-pass file generation 971
primary hint stream, concatenated with 950, 957
use discouraged 971
Overlay blend mode 491
Overline text decoration type 857
overprint control 254-256
See also
overprint mode
overprint parameter
Overprint entry
version 1.3 OPI dictionary 910
version 2.0 OPI dictionary 912
overprint mode 182, 255-256
CompatibleOverprint blend mode, ignored by 541
K operator 258
k operator 258
nonzero 229, 255-256, 536-537
OPM entry (graphics state parameter dictionary) 191
summary 539, 539-540
and transparency 534, 536-537
overprint parameter 182, 184, 254-255
CompatibleOverprint blend mode, ignored by 541
and halftones 543
nonstroking 182, 191, 543
OP entry (graphics state parameter dictionary) 191
op entry (graphics state parameter dictionary) 191
stroking 182, 191, 543
summary 539, 539-540
and transfer functions 543
and transparency 534, 535, 536, 537, 538
overprinting 11
and alternate color space 237, 241
and blend modes 534-536, 538
in EPS files 1013
opaque and transparent, compatibility between 536-
537, 538
OPI proxies 910, 912
summary 539-541
and transparency 534-541
owner password 96, 98, 99, 1009
authenticating (algorithm) 103
computing (algorithm) 101-102
P
P entry
3D view dictionary 758, 760
annotation dictionary 571, 602, 632
attribute object for user properties 804, 805
bead dictionary 561, 973
DocMDP transform parameters dictionary 691, 692,
696
encryption dictionary 98, 101
floating window parameters dictionary 730, 731
linearization parameter dictionary 948, 952
media clip data dictionary 720, 722
media criteria dictionary 717
media rendition dictionary 718, 719
optional content membership dictionary 336, 337,
342, 344
page label dictionary 560
structure element dictionary 787
target dictionary 619
UR transform parameters dictionary 695
Web Capture command dictionary 886, 887
Windows launch parameter dictionary 623
P highlighting mode (push) 587, 603
P standard structure type 828, 830, 830, 833
<p> XHTML element (rich text strings) 643, 645
PA entry
link annotation dictionary 588
navigation node dictionary 567, 567, 568
packing of ILSEs 825-826, 846
floating elements exempt from 826
padding (Tagged PDF) 850
Padding standard structure attribute 845, 848, 849, 850,
850, 855
Paeth predictor function (LZW and Flate encoding) 51, 52
Page artifact type 814
page artifacts 815
page boundaries 770, 890-894, 1032
and bounding box 332
box colors 120
clipping to 549
color 895
dash pattern 895
display of 893-894
in printing 171, 549-550, 893
in viewing of documents 171, 549
See also
art box
Index
1162
bleed box
crop box
media box
trim box
page content order 812, 813, 817-819, 864
annotations, sequencing of 818
artifacts 817
illustration elements 824
and nested BLSEs 830
for reverse-order show strings 819
and text discontinuities 816
page description languages 10
See also PostScript
®
page description language
page description level 166, 168, 256
page descriptions 14, 23, 36
page device parameters (PostScript) 906
ProcessColorModel 906
Page entry
annotation dictionary (FDF files) 681
reference dictionary 332
page group 121, 486, 510-512, 524-525
backdrop 486, 507, 510, 511, 512
backdrop color 510
and black-generation functions 544
color space 511, 516, 527, 530, 541
compositing in 486, 511
compositing of 510, 511, 512
group alpha 511
group color 511
group color space, explicit 530
group compositing formula 511
isolated 510, 511, 525
non-isolated 510, 525
notation 511
and overprinting 541
and rendering intents 544
transparency stack 486, 542
and undercolor-removal functions 544
page indices 114, 558
in reference XObjects 332
See also
page labels
page label dictionaries 114, 559-560
P entry 560
S entry 560
St entry 560
Type entry 559
page label hint table (Linearized PDF) 952, 966
page labels 114, 558-560, 1019
label prefix 558, 560
labeling ranges 114, 558-559, 560
numbering style 560
in reference XObjects 332
See also
page indices
page label dictionaries
page layout 115, 1021-1022
page mode 115, 548
Page object type 119, 669, 976, 978, 993
page objects 112, 117, 119-123, 976, 978, 980, 993, 1011
AA entry 122, 610
and annotations 571
Annots entry 121, 570, 602, 606, 632, 818, 903, 905,
953, 993, 996, 997, 998, 1033
ArtBox entry 120, 891, 1032
article beads 560, 561
B entry 121, 560, 669, 953, 1011
BleedBox entry 120, 891, 1032
BoxColorInfo entry 120, 893
Contents entry 121, 128, 185, 340, 778, 905, 953, 975,
1011
CropBox entry 120, 120, 171, 549, 550, 891
in destinations 551
Dur entry 121, 562-563, 565
Group entry 121, 524, 545
Hid entry (obsolete) 1011
ID entry 122, 889
inheritance of attributes 119, 120, 123-124, 128
LastModified entry 119, 904
in Linearized PDF 952, 953, 954, 958-961
MediaBox entry 120, 123, 606, 607, 891, 953
Metadata entry 122
parent content set 122, 889
Parent entry 119, 669
PieceInfo entry 119, 122, 776
for preseparated pages 897
PresSteps entry 122, 566, 567, 568
PZ entry 122, 890
Resources entry 120, 128, 953, 955, 975
Rotate entry 121, 171, 564, 570, 574, 1032
SeparationInfo entry 122, 897
StructParents entry 122, 798, 800
in structural parent tree 786
Tabs entry 122, 569
TemplateInstantiated entry 122, 1044
Thumb entry 121, 557, 953
Trans entry 121, 562, 568
TrimBox entry 120, 891, 1032
Type entry 119
UserUnit entry 122, 171, 360, 1033
VP entry 122, 703
in Web Capture content database 875, 876, 881, 884
page offset hint table (Linearized PDF) 958-961, 1034
header 959-960, 963, 1034
and page retrieval 971, 972
per-page entries 958-959, 960-961, 1034
primary hint stream, first table in 951, 957
Index
1163
shared object hint table, references to 955
page-piece dictionaries 769, 776-777
for form Xobjects 329
and modification dates 119, 329, 777
for page objects 122
See also
application data dictionaries
page scaling 550
page sets, Web Capture
See Web Capture page sets
page tree 112, 117-124, 975, 983
in Linearized PDF 952, 955
named pages in 669
nodes. See page tree nodes
page objects. See page objects
root 114
page tree nodes 118, 118-119, 123, 976, 978, 980, 983
Count entry 118
Kids entry 118
in Linearized PDF 949, 952, 953
Parent entry 118
root 114
Type entry 118
PageElement entry (optional content usage dictionary)
351
PageLabel object type 559
PageLabels entry (document catalog) 114, 559, 1019
PageLayout entry (document catalog) 115, 1011, 1018
PageMaker
®
page layout software 1013
PageMode entry (document catalog) 115, 548, 945, 949,
953
pages 9, 23
additional-actions dictionary 122, 1011
annotation dictionaries 121
art box. See art box
article beads 121, 560, 561, 1011
bleed box. See bleed box
boundaries. See page boundaries
bounding box 551
box colors 120
composite 234, 532, 897
content streams in 121, 126, 813, 814, 975, 976, 978,
980, 1004, 1033
crop box. See crop box
current 11, 170, 172, 486, 499
in destinations 551, 552
display duration 121, 563, 565
FDF (Forms Data Format) 679-681, 1027
fully opaque objects 542
gamut 449
importing 329, 332
imposition on output medium 510-512, 525, 526, 893,
1032
indices 114, 332, 558
labels 114, 332, 558-560, 1019
logical structure elements on 787, 791, 792, 796
magnification factor 115, 122, 574, 890
media box. See media box
metadata 122
modification date 119, 777
movie actions associated with 626
named 125, 669
See also template pages
output medium 448
page-piece dictionary 122
placement in another document 510, 525, 526, 893
positioning on output medium 891, 893
private data associated with 776, 777
resource dictionary 120, 328, 391, 1016
rotation 121, 574
separation dictionary 122
size limits 921, 1033-1034
in structural parent tree 122, 786
in Tagged PDF 813
template 125, 680-681, 1027
thumbnail image 121
transition dictionary 121, 562-564
transparency group 121, 486, 510-512, 524-525
trap network annotation 903
trigger events for 612
trim box. See trim box
Web Capture content set 122
See also
page objects
Pages entry
document catalog 114
FDF dictionary 674, 679
name dictionary 125, 669
separation dictionary 897
Pages object type 118, 976, 978
Pagination artifact type 814
pagination artifacts 815
paint types (tiling patterns) 262
type 1 (colored) 262, 264
type 2 (uncolored) 262, 268
painting
external objects (XObjects) 302, 914
filling. See filling
form XObjects 326, 327, 526, 527
glyphs 359, 360, 371-372, 538, 1014
images 305, 305
non-isolated groups 526
nonzero overprint mode 256
opaque imaging model 484, 485, 486
overprint parameter 254
paths 12, 163, 164, 199-204, 273, 538-539
scan conversion 480-481
Index
1164
stroking. See stroking
transparency groups 526-527
transparent imaging model 484, 486
painting operators
All colorant name 236
clipping of 12, 204
current page 11
DeviceN color spaces 241
filling 200, 202-204, 913, 914, 915
and graphics state 12, 184
None colorant name 236
parameters 12
pattern cells 262, 263, 264
PostScript and PDF compared 21
Separation color spaces 236
shading patterns 273
stroking 12, 163, 164, 201-202, 913, 915
tint transformation functions 237, 240
PaintType entry
Type 1 font program 439
type 1 pattern dictionary 262, 529
Palindrome play mode (movie) 742
PANOSE Classification Metrics Guide (Hewlett-Packard
Company) 432, 1060
PANOSE classification system 432
Panose entry (CIDFont Style dictionary) 432
PANTONE Hexachrome color system 238, 239
Paperclip annotation icon 600
Paragraph annotation icon 586
paragraphlike elements, standard
See standard paragraphlike elements
parameters, graphics state
See graphics state parameters
Params entry (embedded file stream dictionary) 158
parent content set (Web Capture)
image 312, 889
page 122, 889
Parent entry
field dictionary 637
outline item dictionary 555
page object 119, 669
page tree node 118
pop-up annotation dictionary 599
parent tree, structural
See structural parent tree
parentheses (
( )) 26, 379
as literal string delimiters 29
unbalanced 29, 30, 31
ParentTree entry (structure tree root) 786, 797, 798
ParentTreeNextKey entry (structure tree root) 786, 797
Part standard structure type 827, 828, 833
partial field names 637, 638-639, 677, 1023
Password authentication method (digital signatures) 688
Password field flag (text field) 653
passwords 96, 99, 100
computing (algorithms) 101-103, 675, 1009
for FDF encryption 675
owner 96, 98, 99, 101-102, 103, 1009
in text fields 653
user 96, 98, 99, 100, 101, 102-103
patches, color
bicubic tensor-product 297, 298-300
Coons 291-293, 297, 298, 300
Patent Clarification Notice, Adobe 8, 1057
patents, Adobe 8
path construction operators 163, 166, 195-197
b 195
c 166, 196, 198, 913
in clipping paths 204
f 195, 199, 206
h 166, 195, 197, 201, 914
l 166, 196, 201, 915
m 166, 196, 202, 915
in path objects 12
re 166, 195, 196, 197, 915
S 201
in Type 3 glyph descriptions 392
v 166, 196, 199, 916
W 195
W* 195
y 166, 196, 199, 916
PATH environment variable (Windows) 1025
path objects 11-12, 164
as clipping paths 204, 780, 782
in glyph descriptions 390
graphics state, dependence on 168
m operator 168
object shape 517
and path operators 195
re operator 168
in Tagged PDF 827
path-painting operators 163, 166, 195, 199-204
B 166, 200, 538, 913
b 166, 200, 538, 913
B* 166, 200, 538, 913
b* 166, 200, 538, 913
in clipping paths 204
ending path 164
F 166, 200, 914
f 12, 166, 180, 200, 202, 259, 262, 265, 269, 273, 914
f* 166, 200, 202, 914
filling 200, 202-204, 913, 914, 915
n 166, 200, 205, 780, 782, 915
object shape 517
Index
1165
in path objects 12
S 12, 166, 180, 195, 199, 200, 201, 206, 259, 262, 273,
392, 915
s 166, 200, 915
shading patterns, compositing of 528
stroking 201-202, 913, 915
in Type 3 glyph descriptions 392
and transparent overprinting 538-539
paths 163, 184, 194-205, 273
clipping 163, 164, 204-205, 371, 372
construction 12, 163, 195-199, 913, 915, 916
current 196, 201, 205
current point 196, 197, 198
filling 12, 163, 164, 200, 202-204, 913, 914, 915, 980
for ink annotations 599
open 195
painting 12, 163, 164, 199-204, 273, 538-539
scan conversion 480-481
stroking 12, 163, 164, 181, 185, 186, 188, 201-202, 599,
913, 915
subpaths 195, 197, 204, 372, 914, 915
See also
path objects
pattern cells 260, 261, 264, 268
bounding box 263
clipping 263
colors 262, 263
compositing in 528
compositing of 528
and fully opaque objects 542
as isolated groups 529
key 263
spacing 263
text objects in 375
transparent objects in 528
Pattern color spaces 207, 232, 260, 316
alternate color space, prohibited as 223, 237, 240
base color space, prohibited as 232
blending color space, prohibited as 525
colored tiling patterns 264
default color space, prohibited as 228
initial color value 257
remapping of underlying color space 228
sampled images, prohibited in 310
setting 210, 257
setting color values in 258, 261
shadings, prohibited in 275
uncolored tiling patterns 268
underlying color space for 228, 258, 268, 531
underlying color space, prohibited as 268
pattern dictionaries 260, 260, 273
PatternType entry 260
See also
type 1 pattern dictionaries (tiling)
type 2 pattern dictionaries (shading)
Pattern entry (resource dictionary) 129, 258, 261, 264
pattern matrix 173, 261, 262, 263, 264, 272
Pattern object type 262, 272
pattern objects 260
Pattern resource type 129, 258, 261, 264
pattern space 173, 261, 263, 264, 273, 274
pattern types 262, 272
type 1 (tiling) 232, 260, 261-271
type 2 (shading) 190, 232, 260, 272-301
patterns 11, 205, 207, 259-301, 1013
for appearance streams 635
as color values 261
content streams 126, 262, 263, 264, 268, 272
dictionaries. See pattern dictionaries
explicit masks, simulating 320
and form XObjects 261
general properties 260-261
as named resources 129
object shape 517
page coordinate system, alignment with 261
parent content stream 261, 262, 264
Pattern color spaces 232
pattern matrix 173, 261, 262, 263, 264, 272
pattern objects 260
pattern space. See pattern space
resources for 128
and transparency 528-529
See also
shading patterns (type 2)
tiling patterns (type 1)
PatternType entry 260
type 1 pattern dictionary 262
type 2 pattern dictionary 272
Pause movie operation 627
PC entry (additional-actions dictionary) 611, 612
PC trigger event (annotation) 612
PCL (Printer Command Language) file format 19
PCM entry (trap network appearance stream dictionary)
906
PDF files 9
body 66, 69, 975, 992
conversion from PostScript 20-21
cross-reference table. See cross-reference table
embedded file streams. See embedded file streams
encryption 17, 31, 91-103, 1009
header 66, 68-69, 75, 114, 1002, 1003, 1004, 1008,
1010
incremental updates. See incremental updates
indirect generation 19-21
job tickets 448
network access 68, 939, 940, 941, 969-973
Index
1166
See also Forms Data Format (FDF)
optimization 17
portability 14-15, 25, 457, 740, 741, 1017
preseparated 897, 906
random access 17, 21, 66, 69, 91
single-pass generation 16-17
structure 21, 23, 66-75, 1008-1009
trailer 67, 72-74, 75, 1008
example 975, 992, 993, 995, 998, 1000
translation from other file formats 19
See also
file identifiers
PDF name registry
See name registry, PDF
PDF procedure set 770
PDF Signature Build Dictionary Specification for Acrobat
6.0 (Adobe Technical Note) 688, 1058
PDF versions
See versions, PDF
PDF/X (Portable Document Format, Exchange) file
format 898, 899, 900
PDF/X output intent dictionaries 899-900
DestOutputProfile entry 899, 900
Info entry 899
OutputCondition entry 899
OutputConditionIdentifier entry 899
RegistryName entry 899
S entry 898, 899
Type entry 899
PDFDocEncoding predefined character encoding 131, 132,
161, 923, 924
for alternate descriptions 871
euro character 928
for FDF fields 674, 1025
for JavaScript scripts 668, 1025
non-Latin writing systems and 650
for status strings 674
for text annotations 1000
pdfmark language extension (PostScript) 20
percent sign (
%) character 26
as comment delimiter 27
in uniform resource locators, “unsafe” 878
Perceptual rendering intent 231
period (
.) character
double, in relative file specifications 153
double, in uniform resource locators (URLs) 878
in field names 639, 1023
in file names 154
in handler names 684
in uniform resource locators (URLs) 878
in unique names (Web Capture) 880
permissions, access
See access permissions
permissions dictionaries 699
DocMDP entry 690, 691, 700
UR entry 685, 692, 693, 700, 1027
UR3 entry 685, 687, 692, 693, 694, 700
Perms entry (document catalog) 117, 699
perspective projection (3D artwork) 760, 761-763
Pg entry
marked-content reference dictionary 792
object reference dictionary 796
structure element dictionary 787, 791, 792, 796
photographs 12, 218, 230, 302
halftoning 14
Photoshop
®
image editing software 776, 1012
PI entry (additional-actions dictionary) 611, 612
PI trigger event (annotation) 612
PID entry (media player info dictionary) 735, 735
PieceInfo entry
document catalog 116, 772, 776
page object 119, 122, 776
type 1 form dictionary 329, 329, 776
PIN authentication method (digital signatures) 688
pixels 12
in halftone screens 457-459, 464-465, 467
representation in memory 13-14
scan conversion 480-481
PJTF (Portable Job Ticket Format) 24, 448, 891, 903, 906,
1032
PKCS #7 Cryptographic Message Syntax, Version 1.5 (Inter-
net RFC 2315) 104, 697, 1062
PKCS #1 - RSA Cryptography Standard 1063
PKCS#1 signatures 686, 697
adbe.x509.rsa_sha1 686, 686, 697
PKCS#7 encoding (public-key security handlers) 104
PKCS#7 objects
public-key encryption 105, 105-106, 109
public-key signatures 686, 687
revocation information 698
time stamp information 698
PKCS#7 signatures 697-699
adbe.pkcs7.detached 686, 686, 697
adbe.pkcs7.sha1 686, 686, 697
PL entry
media clip data dictionary 721, 721, 1028
media play parameters dictionary 718, 725
placement attributes 846-847
Before 847
Block 846, 852, 860
End 847, 852, 861
Inline 829, 845, 846, 851, 860, 861
Start 847, 852, 861
Index
1167
Placement standard structure attribute 826, 829, 833, 841,
842, 845, 846, 851, 852, 860, 861
plates, color
Plate 1, Additive and subtractive color 211
Plate 2, Uncalibrated color 214
Plate 3, Lab color space 220
Plate 4, Color gamuts 220
Plate 5, Rendering intents 230
Plate 6, Duotone image 238
Plate 7, Quadtone image 238, 252
Plate 8, Colored tiling pattern 265
Plate 9, Uncolored tiling pattern 269
Plate 10, Axial shading 280
Plate 11, Radial shadings depicting a cone 282, 283
Plate 12, Radial shadings depicting a sphere 283
Plate 13, Radial shadings with extension 283
Plate 14, Radial shading effect 283
Plate 15, Coons patch mesh 291
Plate 16, Transparency groups 485
Plate 17, Isolated and knockout groups 507, 508
Plate 18, RGB blend modes 490
Plate 19, CMYK blend modes 490
Plate 20, Blending and overprinting 537
play mode (movie) 742
Once 742
Open 742
Palindrome 742
Repeat 742
Play movie operation 627
plug-in extensions
action types 614
for actions 1022, 1023
annotation handlers 570, 579, 580
for annotations 1020
file systems 155
and Linearized PDF 950, 952, 957, 966
and logical structure 801
and marked content 778, 780
and metadata 771
modification dates, maintenance of 904
names, registering 937
output intents 1032
for RGB output 898, 937
signature handlers 684
sound formats 740
Web Capture. See Web Capture plug-in extension
WebLink 1022
and version compatibility 1001, 1002
plus sign (
+) character
in dates 133
in font subset names 389
PNG (Portable Network Graphics) predictor functions
51-52
algorithm tags 52
Average 51, 52
None 51, 52
Paeth 51, 52
Sub 51, 52
Up 51, 52
PNG (Portable Network Graphics) Specification (Internet
RFC 2083) 51, 1062
PO entry (additional-actions dictionary) 611, 612
PO trigger event (annotation) 612
Poetica
®
typeface 389
points (printers’ unit) 171
polygon annotation dictionaries
BE entry 576, 596
BS entry 595
IC entry 596
IT entry 596
Subtype entry 595
Vertices entry 595
Polygon annotation type 580, 595, 596
polygon annotations 580, 595-596
intent 596
PolygonCloud annotation intent 596
polyline annotation dictionaries
BS entry 595
IC entry 596
LE entry 595
Subtype entry 595
Vertices entry 595, 595
PolyLine annotation type 580, 595, 595
polyline annotations 580, 595-596
pop operator (PostScript) 149, 918
pop-up annotation dictionaries 599
Contents entry 582
Open entry 599
Parent entry 599
Subtype entry 599
pop-up annotations 581, 582, 583, 599
parent annotation 599
See also
pop-up annotation dictionaries
pop-up help systems 573, 627
pop-up windows 568, 572, 583, 588, 665
for circle annotations 593
for ink annotations 598
for line annotations 590
for pop-up annotations 599
for rubber stamp annotations 598
for sound annotations 870
for square annotations 593
for text annotations 586
for text markup annotations 596
Popup annotation type 581, 599
Index
1168
Popup entry (markup annotation dictionary) 583, 599
portability of PDF files 14-15, 25, 457, 740, 741, 1017
Portable Job Ticket Format (PJTF) 24, 448, 891, 903, 906,
1032
Portable Job Ticket Format (Adobe Technical Note #5620)
24, 448, 903, 906, 1059
Position entry (version 1.3 OPI dictionary) 909
position vector (glyph) 365
in CIDFonts 410-411
DW2 entry (CIDFont) 410-411
W2 entry (CIDFont) 411
POST request (HTTP) 664, 884, 887
“post” table (TrueType font) 399, 401
Poster entry (movie dictionary) 741
poster images (movies) 741
postfix notation 126, 164
PostScript calculator functions
See type 4 functions
PostScript Language Document Structuring Conventions
Specification (Adobe Technical Note #5001) 1058
PostScript Language Reference (Adobe Systems
Incorporated) 6, 149, 298, 383, 466, 903, 906, 917,
919, 1058
PostScript
®
page description language xxi
CMap files 421
CMap names 419
color rendering dictionary 449
composite fonts 403
conversion to PDF 19
current path 196
default user space 171
dictionary keys 35
document structuring conventions (DSC) 27
Encapsulated PostScript (EPS) 486
files 20, 1033
font dictionaries 382
font names 381, 383, 386, 388-389, 389, 407, 423, 426
forms 325
halftone dictionaries 466, 475
image space 173
imaging model 1, 6, 10
implementation limits 919
interpreter 151, 383, 421, 919
LanguageLevel 1 303, 1013
LanguageLevel 2 1013
LanguageLevel 3 1013
names, compatibility with 1006
null object 35
number syntax 28
OPI comments 333, 907
output devices 21, 303, 383, 544, 770, 1013, 1017, 1033
page descriptions 20
page group, flattening of 512
patterns 261
and PDF, compared 21-22
postfix notation 126
predefined spot functions, definitions of 459-463
procedure sets 770
ProcessColorModel page device parameter 906
scanner 151
sequential execution model 164
spot functions 466
transfer functions 466
transparent imaging model, compatibility with 544-
545
trapping instructions 903
Type 1 font programs 383, 438
Type 3 fonts 392
type 7 shadings, data format 298
Type 42 font format 387
See also
operators, PostScript
PostScript XObjects
type 4 functions (PostScript calculator)
PostScript XObject dictionaries 303
Level1 entry 303
Subtype entry 303
Type entry 303
PostScript XObjects 165, 302, 303-304
See also PostScript XObject dictionaries
PP entry (additional-actions dictionary, obsolete) 1021
PPK. See public/private-key authentication
preblending of soft-mask image data 522-524
predefined character encodings 923-936, 1016
for
Symbol font, built-in 923, 932-934
for
ZapfDingbats font, built-in 923, 935
See also
MacExpertEncoding predefined character encoding
MacRomanEncoding predefined character encoding
PDFDocEncoding predefined character encoding
StandardEncoding predefined character encoding
WinAnsiEncoding predefined character encoding
predefined CMaps 409, 412-418, 923
as base CMap 419
character collections for 416-418, 442
IdentityH 416, 442
IdentityV 416, 442
with Type 0 fonts 423
Unicode mapping 442
predefined spot functions 458-464, 467, 1017
CosineDot 460
Cross 463
Diamond 463
Double 460
DoubleDot 459
Index
1169
Ellipse 461
EllipseA 462
EllipseB 462
EllipseC 462
InvertedDouble 460
InvertedDoubleDot 459
InvertedEllipseA 462
InvertedEllipseC 462
InvertedSimpleDot 459
Line 458, 460
LineX 460
LineY 461
Rhomboid 463
Round 461
SimpleDot 458, 459
Square 463
Predictor entry
FlateDecode filter parameter dictionary 50, 51-52
LZWDecode filter parameter dictionary 50, 51-52
predictor functions (LZW and Flate encoding) 47, 50, 51-
53, 310
Average 51, 52
None 51, 52
Paeth 51, 52
PNG (Portable Network Graphics) 51-52
Sub 51, 52
TIFF (Tag Image File Format) Predictor 2 51, 52
Up 51, 52
preferences, viewer
See viewer preferences
Preferences folder (Mac OS) 1025
Preferred entry (Language subdictionary, optional content
usage dictionary) 350, 353
premultiplied alpha
See preblending of soft-mask image data
premultiplied opacity channel (JPEG2000) 64
“prep” table (TrueType font) 439
prepress production 10, 770, 890-912
See also
Open Prepress Interface (OPI)
output intents
page boundaries
printer’s marks
separation dictionaries
trapping
presentations 558, 562-566
display duration 121, 563, 565
sub-page navigation 566-568
transition dictionaries 121, 562-564
transition style 563-564
preseparated files 897
and trapping 906
PreserveRB entry (set-OCG-state action dictionary) 629
PresSteps entry (page object) 122, 566, 567, 568
Prev entry
cross-reference stream dictionary 84
file trailer dictionary 73, 75, 84, 86, 87, 948, 956, 993,
995, 998, 1000
navigation node dictionary 566, 567, 567, 568
outline item dictionary 554, 555
PrevPage named action 628
See also named-action dictionaries
primary colorants 234, 237
and halftones 457, 466
primary hint stream (Linearized PDF) 945, 950
in first-page cross-reference table 948
and first-page section, ordering of 950, 952, 969, 970
hint table offsets in 951, 957, 966
in linearization parameter dictionary 947, 950
object offsets, ignored by 957, 958, 960
and one-pass file generation 971
overflow hint stream, concatenated with 950, 957
Print annotation flag 573, 896, 904, 1019, 1020
Print entry (optional content usage dictionary) 351, 353
Print event type (usage application dictionary) 352, 353,
356
print scaling 550
Print Setup dialog 1032
PrintArea entry (viewer preferences dictionary) 549
PrintClip entry (viewer preferences dictionary) 550
printer driver 19, 20
printer’s mark annotation dictionaries 896
MN entry 896
Subtype entry 896
printer’s mark annotations 581, 605, 894-896
annotation rectangle 894
appearance streams for 896
See also
printer’s mark annotation dictionaries
printer’s mark form dictionaries 896-897
Colorants entry 897
MarkStyle entry 896
printer’s marks 770, 890, 891, 894-897
See also printer’s mark annotations
PrinterMark annotation type 581, 582, 674, 896
printers 170, 213
color 457, 475
dot-matrix 12, 13
and halftones 458
ink-jet 12, 13
laser 12, 13
process colorants 234
separations 236
printing 97
access permission 97, 99, 100
Index
1170
alternate images 317
annotations 573, 574, 578, 1020
embedded fonts, copyright restrictions on 436
glyph widths in 1014
by launch actions 621, 622
list numbering 862
n-up 549
OPI proxies 1033
output medium, dialog with user on 448
page boundaries 549-550, 893
PostScript XObjects 303
predefined spot functions 1017
Print Setup dialog 1032
procedure sets and 1030
R2L reading order 549
reference XObjects 333
trigger events associated with 613
printing presses, offset 902
PrintingOrder entry (DeviceN mixing hints dictionary)
244
PrintScaling entry (viewer preferences dictionary) 550
PrintState entry (Print subdictionary, optional content us-
age dictionary) 351, 353
Private entry (application data dictionary) 777
Private standard structure type 829
procedure sets 22, 769, 770, 976, 978, 980, 1030
ImageB 770
ImageC 770
ImageI 770
as named resources 129, 770
PDF 770
and PostScript XObjects 304
Text 375, 770
trap networks, excluded from 905
process color components
and overprinting 539-540
spot colors, treating as 533
and transparent overprinting 536, 537, 540, 541
process color model 254, 447, 450, 906
DeviceCMY 906
DeviceCMYK 906
DeviceGray 906
DeviceN 906
DeviceRGB 906
DeviceRGBK 906
process colorants
additive devices, inapplicable to 236
All colorant name 236
and alternate color space 237
in composite pages 234, 897
and current blend mode 516
DeviceCMYK color space 213
DeviceN color spaces 242
halftones for 476
and high-fidelity color 238
NChannel color spaces 243
and overprinting 539-540
process color model 450
Separation color spaces 234
spot colorants, approximation of 532
transfer functions 192
and transparency 532, 534
and transparent overprinting 535, 540
See also
black colorant
cyan colorant
magenta colorant
yellow colorant
process colors 450
and blending color space 489
and flattening of transparent content 545
group color space, conversion to and from 532
separations, previewing of 898
and transparency 532
and transparent overprinting 535
process dictionaries (
DeviceN color spaces) 242
Process entry (DeviceN color space attributes dictionary)
242
Process OPI color type 910
ProcessColorModel page device parameter (PostScript)
906
ProcSet entry (resource dictionary) 129, 770, 975, 976
ProcSet resource type 129, 770, 975, 976
producer applications, PDF 1
accessibility to users with disabilities 864
artifacts, generation of 813
encoding of data 41
glyph widths, specification of 1014
logical structure, use of 784
names, embedded spaces in 1005
names, registering 937
page tree, handling of 118
PDF version, updating 68, 114
predefined CMaps, support for 418
printer’s marks, generation of 894
procedure sets, specification of 770
ToUnicode CMaps 16
producer applications, Tagged PDF
annotations, sequencing of 818
footnotes, placement of 835
hyphenation, specification of 816
logical structure, definition of 817
page content order, establishment of 817
Private grouping element 829
standard structure elements, role mapping to 813
Unicode mapping 820
Index
1171
Producer entry (document information dictionary) 772
production, prepress
See prepress production
production conditions 898, 899
Custom 899
registry 899
profiles, ICC color
See ICC color profiles
projecting square line cap style 186, 201
projection dictionaries 758, 760-763
CS entry 760, 761
F entry 760, 761
FOV entry 760, 761, 762
N entry 760
OS entry 761
PS entry 761, 763
Subtype entry 758, 760, 761
projection, orthographic (3D artwork) 760, 761
projection, perspective (3D artwork) 760, 761-763
Prop_AuthTime entry (signature dictionary) 688
Prop_AuthType entry (signature dictionary) 688
Prop_Build entry (signature dictionary) 686, 688
Properties entry (resource dictionary) 129, 340, 779, 780
Properties resource type 129, 340, 779, 780
property lists 778, 779, 780, 913, 914
ActualText entry 820, 834, 871
Alt entry 820, 834, 870, 871
for artifacts 814-815
Attached entry (Tagged PDF artifact) 815
BBox entry (Tagged PDF artifact) 815
E entry 816, 820, 821, 834, 872, 873
Lang entry 834, 864, 865, 866, 867, 868
for logical structure content items 790
MCID entry 790, 834, 867, 868
Metadata entry 775
as named resources 129, 775, 779, 780
TagSuspect entry 817
Type entry (Tagged PDF artifact) 814, 815
Proportional font characteristic 821
proportional fonts 363, 429
Proportional glyph class 433, 434
proportional scaling 679
ProportionalRot glyph class 433, 434
proxies
OPI 333, 770, 890, 907-912
reference XObject 329, 331, 332, 333, 972
PS entry
number format dictionary 708
projection dictionary 761, 763
PS XObject subtype 302, 303
pseudorectangular lattices 289
public/private-key (PPK) authentication 684
publications, related 6-7
public-key encryption 105-106
public-key encryption formats
adbe.pkcs7.s3 104, 105, 106
adbe.pkcs7.s4 104, 105
adbe.pkcs7.s5 104, 105, 106
public-key security handlers 104-106
access permissions 104
Adobe.PPKLite 104
Adobe.PubSec 104
encryption algorithms 105-106
encryption dictionary 104-105
Entrust.PPKEF 104
PKCS#7 encoding 104
recipient lists 104, 105, 109
X.509 certificate 104
Push transition style 564, 564
Pushbutton field flag (button field) 648, 648, 651
pushbutton fields 647, 648, 648
appearances for 678
and reset-form actions 666
and submit-form actions 666
pushbuttons 636
PushPin annotation icon 600
PV entry (additional-actions dictionary) 611, 612
PV trigger event (annotation) 612
PZ entry (page object) 122, 890
Q
Q entry
field dictionary 635, 640, 641, 645
free text annotation dictionary 589
interactive form dictionary 635
Q operator 166, 189, 915
and clipping path 205, 362, 372
and current transformation matrix (CTM) 308
and dynamic appearance streams 641
and form XObjects 327
and graphics state stack 184
implementation limit 920, 1033
marked clipping sequences, prohibited in 782
and tiling patterns 264
q operator 166, 189, 915
and clipping path 205
and current transformation matrix (CTM) 308
and dynamic appearance streams 641
and form XObjects 327
and graphics state stack 184
implementation limit 920, 1033
marked clipping sequences, prohibited in 782
Index
1172
and tiling patterns 264
quadding
form field 640, 641
free text annotation 589
QuadPoints entry
link annotation dictionary 588
text markup annotation dictionary 596, 1021
quadtone color 238
example 252-254
QuarkXPress
®
publishing software 1013
QuickDraw imaging model 19, 20
quotation mark (") character
as text-showing operator 166, 368, 371, 377, 916
quotations
block 828
inline 835
Quote standard structure type 835
BlockQuote, distinguished from 835
R
R entry
appearance characteristics dictionary 604
appearance dictionary 579, 678, 896, 904
bead dictionary 561
encryption dictionary 98, 101
floating window parameters dictionary 730, 731
media criteria dictionary 717
rectilinear measure dictionary 705
rendition action dictionary 631
selector rendition dictionary 719, 719
signature dictionary 687
sound object 739, 740
structure element dictionary 788, 803
target dictionary 619
Web Capture image set 883
R keyword 40
R tab order (annotations) 122, 569
R transition style 563
R2L reading order 549
radial shadings
See type 3 shadings
radio button field dictionaries
Opt entry 652, 653
radio button fields 647, 648, 650-653
normal caption 604
Off appearance state 651
value 651
Radio field flag (button field) 648, 648, 651
RadiosInUnison field flag (button field) 648, 650, 651,
1024
raised capitals 861
random access to PDF files 17, 21, 66, 69, 91
range, function 140, 141, 142, 143, 144
Range entry
function dictionary 141, 142, 144, 146, 150
ICC profile stream dictionary 223, 257, 316
Lab color space dictionary 220, 221, 257, 315
raster 12
raster image processor (RIP) 902
raster output devices 12-13
device space 169
graphics state parameters 184
rendering 447
scan conversion 448
Rate entry (movie activation dictionary) 742
Raw sound encoding format 740
RB standard structure type 836, 840, 858
RBGroups entry (optional content configuration
dictionary) 348, 629
RC entry
appearance characteristics dictionary 604
free text annotation dictionary 589
markup annotation dictionary 583, 591, 645
media play parameters
MH/BE dictionaries 727
RC4 encryption algorithm 94, 95, 102, 103
copyright 94
for FDF 675
RClosedArrow line ending style 593
RD entry
caret annotation dictionary 597
circle annotation dictionary 595
number format dictionary 708
square annotation dictionary 595
re operator 166, 195, 196, 197, 915
reading order 549
ReadOnly annotation flag 574, 896, 904
ReadOnly field flag 638
and widget annotations 574, 638
real objects 27
precision limits 28, 920
range limits 28, 920
syntax 28
Reason entry (signature dictionary) 687, 688
Reasons entry (signature field seed value dictionary) 660,
661
recipient lists (public-key security handlers) 104, 105, 109
Recipients entry
crypt filter dictionary 109
encryption dictionary 105, 106
Rect entry (annotation dictionary) 570, 574, 575, 577, 588,
593, 594, 595, 597, 607, 624, 641, 658, 748, 839
Index
1173
rectangles 134
as dictionary values 131
path construction 197, 915
rectilinear measure dictionaries 705-707
A entry 706
CYX entry 707
D entry 706
O entry 706
R entry 705
S entry 706
T entry 706
X entry 706
Y entry 706
red color component
CMYK conversion 451, 454
cyan, complement of 452
DeviceRGB color space 211, 212
grayscale conversion 451
halftones for 476
in
Indexed color table 232
initialization 213
and threshold arrays 465
transfer function 454, 455
red colorant
additive primary 211, 212, 213
display phosphor 234
Ref entry (type 1 form dictionary) 329, 331
reference area 824
and allocation rectangle 859
and floating elements 826
layout within 846, 847, 848, 851, 852, 854, 855
and nested BLSEs 825
stacking of BLSEs 825, 847
reference counts (Web Capture image set) 883, 1031
reference dictionaries 329, 332
F entry 332
ID entry 332
Page entry 332
Reference entry (signature dictionary) 687, 688, 700
Reference standard structure type 828, 829, 835
reference XObjects 165, 302, 329, 331-334
and annotations 333
bounding box 332
clipping to bounding box 332
containing document 331
in Linearized PDF 972
and logical structure 333-334
printing 333
proxy 329, 331, 332, 333, 972
target document 331, 332
reflection
images 309
OPI proxies 909
transformation matrices 169
reflow of content 812
artifacts 814
glyph widths 1014
hidden page elements 817
illustrations 841
list numbering 862
page content order 813, 817
standard structure attributes 842, 845
standard structure types 827
word breaks 822
registered names
conversion engines (Web Capture) 889
dictionary keys 1004
first-class 158, 937-938
marked-content tags 778
object types 36
output intent subtypes 899
second-class 938
security handlers 92
signature handlers 684
third-class 938
registration targets 236, 890, 894
as printer’s mark annotations 605
Registry entry (CIDSystemInfo dictionary) 406, 415, 433
RegistryName entry (PDF/X output intent dictionary) 899
regular characters 25, 26, 27, 32
Rejected annotation state 585
related files arrays 156, 159-160, 162
related publications 6-7
relational operators 28
relative file specifications 152-153, 1025, 1026
Relative Uniform Resource Locators (Internet RFC 1808)
152, 878, 887, 1061
RelativeColorimetric rendering intent 181, 230, 231
remapping of colors 211, 227-228, 450, 525, 531, 900
remote go-to action dictionaries 617
D entry 617
F entry 553, 617
NewWindow entry 617
S entry 617
remote go-to actions 615, 617
destination 551, 553, 617
and Linearized PDF 970
target file 617
See also
go-to actions
remote go-to action dictionaries
Rename entry (FDF template dictionary) 680, 1027
rendering 10, 447-482
alternate color spaces 237
of CIE-based colors 448
Index
1174
color 206, 447-448
color conversion. See color conversion
coordinate transformations, inverting 179
current page 11, 14
curves 198
flatness tolerance. See flatness tolerance
and graphics, distinguished 164, 447
graphics state parameters, device-dependent 180
halftones 14, 183, 447, 456-478, 542-543
image interpolation 316
images 305
implicit color conversion 228
imported pages 333
intents. See rendering intents
marking 448
order of transformations 454
overprint control 254
scan conversion 13, 448, 478-482
smoothness tolerance. See smoothness tolerance
transfer functions 447, 454-456, 466, 542-543
and transparency 541-544
rendering intents 227, 230-231, 449
AbsoluteColorimetric 231
current 181, 310, 528, 541, 542, 543
ICC color profiles 225
and nested transparency groups 544
Perceptual 231
RelativeColorimetric 181, 230, 231
RI entry (graphics state parameter dictionary) 190
ri operator 189, 915
for sampled images 310
Saturation 231
and transparency 543-544
rendition action dictionaries 631
AN entry 631
JS entry 631
OP entry 631, 631
R entry 631
S entry 631
Rendition action type 615, 631
rendition actions 615, 630-632
See also rendition action dictionaries
rendition dictionaries 716
BE entry 715, 716
MH entry 715, 716
N entry 715, 716
S entry 716
Type entry 716
See also
media rendition dictionary
rendition
MH/BE dictionaries
selector rendition dictionary
rendition
MH/BE dictionaries 716
C entry 715, 716
Rendition object type 716
rendition objects 125, 715-719
See also
rendition dictionaries
Renditions entry (name dictionary) 125
renditions name tree hierarchy (Linearized PDF) 956
renditions name tree hint table (Linearized PDF) 952, 967
Repeat entry (sound action dictionary) 626
Repeat play mode (movie) 742
repeatCount attribute (SMIL) 727
replacement text 863, 871-872
example 872
font characteristics unavailable for 821
for marked-content sequences 871
for structure elements 788, 871-872
in Tagged PDF 816
and Unicode natural language escape 872
word breaks 823
replies (annotations) 583, 584, 585
Reproduction of Colour, The (Hunt) 1060
Required field flag 638
reserved words 25
reset-form action dictionaries 667
Fields entry 667
Flags entry 667, 667
S entry 667
reset-form actions 615, 662, 666-667
default value 638
flag. See reset-form field flag
See also
reset-form action dictionaries
reset-form field flag 667
Include/Exclude 667
ResetForm action type 615, 667
ResFork entry (Mac OS file information dictionary) 159
resolution (output devices) 13, 170, 181, 184, 275, 316,
468, 470
Resolution entry (version 1.3 OPI dictionary) 909
resolution progression, JPEG2000 62, 63
resource dictionaries 128-129, 975
base images in 317
ColorSpace entry 129, 210, 227, 257, 324, 525
and content streams 125, 328
current. See current resource dictionary
ExtGState entry 129, 189, 190
Font entry 129, 303, 359, 368, 383, 406, 635, 641
for form fields 635
for form XObjects 328, 905
for interactive forms 1023
in Linearized PDF 953
for pages 120, 328, 391, 905, 1016
Index
1175
Pattern entry 129, 258, 261, 264
ProcSet entry 129, 770, 975, 976
Properties entry 129, 340, 779, 780
Shading entry 129, 273
for Type 3 fonts 391, 1016
for variable-text fields 640, 641
XObject entry 129, 302, 309, 312, 326, 330
resource fork (Mac OS) 159
resource types 129
ColorSpace 129, 210, 227, 257, 324, 525
Encoding 953
ExtGState 129, 189, 190
Font 129, 303, 359, 368, 383, 406, 635, 641, 953
FontDescriptor 953
Pattern 129, 258, 261, 264
ProcSet 129, 770, 975, 976
Properties 129, 340, 779, 780
Shading 129, 273
XObject 129, 302, 309, 312, 326, 330
resources 22, 24, 120, 905
in Linearized PDF 953, 953, 954
See also
named resources
resource dictionaries
resource types
Resources entry
3D stream dictionary 753, 754
page object 120, 128, 953, 955, 975
slideshow dictionary 744, 744
stream dictionary 128
type 1 form dictionary 328, 640, 642
type 1 pattern dictionary 263
Type 3 font dictionary 391
restore operator (PostScript) 1033
result alpha
in compositing 494
in knockout groups 509
notation 488, 501
result color (transparent imaging model) 487
in compositing 488, 493, 494, 497, 527
in knockout groups 509
notation 488, 501, 511
and overprinting 534, 535, 536
and separable blend modes 490, 491
result opacity 497-498
in knockout groups 509
notation 497, 501
soft clipping 518
result shape 497-498
notation 497, 501
soft clipping 518
Resume movie operation 627
retinal scans (user authentication) 684
return-to-control (RTC) pattern (
CCITTFaxDecode filter)
55
reverse-order show strings 818-819
ReversedChars marked-content tag 819
revision numbers
FDF encryption algorithm 675
security handler 97, 98-99
structure attributes 788, 802, 803-804
structure elements 788, 803, 804
revocation information (PKCS#7 objects) 698
RF entry (file specification dictionary) 156, 159, 162
RFCs (Requests for Comments), Internet
See Internet RFCs
RG operator 166, 206, 210, 211, 213, 258, 259, 915
rg operator 166, 206, 210, 211, 213, 258, 259, 531, 537, 915
RGB color representation
for additive color 211
and CMYK, compared 213
CMYK, conversion from 454
CMYK, conversion to 183, 451-453, 544
DCTDecode filter, transformation by 61
DeviceRGB color space 207, 212
and grayscale, conversion between 451
in halftones 457
in output devices 205, 450
RGB color space (in Tagged PDF) 849, 850, 856
RGB color space abbreviation (inline image object) 323
Rhomboid predefined spot function 463
RI entry
appearance characteristics dictionary 605
graphics state parameter dictionary 190, 230
ri operator 166, 189, 230, 256, 259, 915
rich text strings 640, 642-646, 653
<b> XHTML element 643
<body> XHTML element 642
color CSS2 style attribute 644
default style string 645
font attributes 646, 1024
font CSS2 style attribute 644
font-family CSS2 style attribute 644
font-size CSS2 style attribute 644
font-stretch CSS2 style attribute 644
font-style CSS2 style attribute 644
font-weight CSS2 style attribute 644
free text annotations 589
<i> XHTML element 643
<p> XHTML element 643, 645
preserving character data 645
<span> XHTML element 643
text-align CSS2 style attribute 644
text-decoration CSS2 style attribute 644
vertical-align CSS2 style attribute 644
Index
1176
RichText field flag (text field) 640, 645, 653
Ridge border style 849
RIFF (Resource Interchange File Format) 739
right angle bracket (
>) character 26
double, as dictionary delimiter 35, 73, 672
as EOD marker 45
as hexadecimal string delimiter 29, 32, 35, 155
right brace (
}) character 26
as delimiter in PostScript calculator functions 149
right bracket (
]) character 26
as array delimiter 34
right parenthesis (
)) character 26
escape sequence for 30, 379
as literal string delimiter 29
right-to-left writing systems 818, 819
RIP (raster image processor) 902
RL filter abbreviation 324, 1007
RlTb writing mode 848
role map 786, 789
and Tagged PDF 813, 826, 827, 829, 841
RoleMap entry (structure tree root) 786
roll operator (PostScript) 149, 918
rollover appearance (annotation) 578
Root entry
FDF trailer dictionary 672
file trailer dictionary 68, 73, 83, 112, 949
root fields (interactive form) 635, 680
root font (Type 0 font) 403
ROpenArrow line ending style 593
Rotate entry
movie dictionary 741
page object 121, 171, 564, 570, 574, 1032
rotation
annotations 574, 586
font matrix 391
images 308
movies 741
OPI proxies 909
order of transformations 176
pages 121, 574
text space 376
transformation matrices 169, 174, 175
user space 574
round line cap style 186, 201
round line join style 186, 201
round operator (PostScript) 149, 917
Round predefined spot function 461
Row table scope attribute 863
Rows entry (CCITTFaxDecode filter parameter dictionary)
55
RowSpan standard structure attribute 863
RP standard structure type 836, 840
RSA Security, Inc. 94, 1063
RT entry
floating window parameters dictionary 730, 731
markup annotation dictionary 583, 584, 584
number format dictionary 708
RT standard structure type 836, 840, 858
RTF (Rich Text Format)
layout model 824
standard attribute owner 843, 844
Tagged PDF 821
Tagged PDF, conversion from 812, 827
RTF-1.05 standard attribute owner 843
rubber stamp annotation dictionaries 598
Name entry 598
Subtype entry 598
rubber stamp annotations 581, 598
See also
rubber stamp annotation dictionaries
ruby characters 434
Ruby glyph class 434
Ruby standard structure type 836, 840
ruby text
After position 858
Center alignment 857
Distribute alignment 857
End alignment 857
Inline position 858
Justify alignment 857
RubyAlign attribute 840, 846
RubyPosition attribute 840, 846
Start alignment 857
Start position 858
Warichu position 858
RubyAlign standard structure attribute 840, 846, 857
RubyPosition standard structure attribute 840, 846, 858
run-length encoding compression 43, 53
RunLengthDecode filter 43, 53
RL abbreviation 324, 1007
in sampled images 310
running heads 815
RV entry
FDF field dictionary 678
field dictionary 640, 645, 646, 653
S
S border style (solid) 576, 1020
S entry 35
action dictionary 610
Index
1177
border effect dictionary 577
border style dictionary 576
box style dictionary 895
embedded go-to action dictionary 618
go-to action dictionary 616
go-to-3D-view action dictionary 633
group attributes dictionary 331, 331, 524, 527
hide action dictionary 628
hint stream dictionary 951
icon fit dictionary 679
import-data action dictionary 668
JavaScript action dictionary 668
launch action dictionary 622
media clip dictionary 720, 720
media criteria dictionary 717
media duration dictionary 727
media offset dictionary 732
movie action dictionary 627
named-action dictionary 629
page label dictionary 560
PDF/X output intent dictionary 898, 899
rectilinear measure dictionary 706
remote go-to action dictionary 617
rendition action dictionary 631
rendition dictionary 716
reset-form action dictionary 667
set-OCG-state action dictionary 629
soft-mask dictionary 520, 521
sound action dictionary 625
source information dictionary 884
structure element dictionary 787, 826, 827
submit-form action dictionary 662
thread action dictionary 623
timespan dictionary 733
transition action dictionary 632
transition dictionary 563
transparency group attributes dictionary 525
URI action dictionary 624
Web Capture command dictionary 886, 888
Web Capture content set 882
Web Capture image set 883
Web Capture page set 882
S guideline style (page boundaries) 895
S operator 12, 166, 199, 200, 201, 915
and current color 206
ending path 195
in glyph descriptions 392
and graphics state parameters 180, 201
and patterns 259, 262, 273
and subpaths 201
s operator 166, 200, 915
S tab order (annotations) 570
SA entry (graphics state parameter dictionary) 192, 482,
1018
SamePath Web Capture command flag 887
SameSite Web Capture command flag 887
sample data
sounds 739, 740
type 0 functions 142, 143, 144
sample values (images) 12, 304
decoding 311, 314-316
in image masks 320
in image space 307
in inline images 322
order of specification 469, 473, 474
representation 306
in soft-mask images 522
source colors (transparent imaging model) 516
stream data 305
sampled functions
See type 0 functions
sampled images
See images, sampled
sans serif fonts 429
SansSerif font classification (Tagged PDF) 822
Saturation blend mode 493
Saturation rendering intent 231
save operator (PostScript) 1033
SC operator 166, 210, 257, 259, 915
in content streams 206
in
DeviceCMYK color space 213
in
DeviceGray color space 212
in
DeviceRGB color space 213
in
Indexed color spaces 234
and sampled images 206
sc operator 166, 210, 258, 259, 915
in content streams 206
and
Decode arrays 306
in
DeviceCMYK color space 213
in
DeviceGray color space 212
in
DeviceRGB color space 213
in
Indexed color spaces 234
and sampled images 206
and type 4 shadings 288
Scalable Vector Graphics (SVG) 1.0 Specification (World
Wide Web Consortium) 1029, 1063
scaling
anamorphic 679
annotations 574, 586, 679
fonts 360, 368
icons 679
line width 185
OPI proxies 909
order of transformations 176
of pages 1032
proportional 679
Index
1178
text space 361, 368, 370, 376
transformation matrices 169, 174, 175
user space 574
Web Capture pages 890
scan conversion 13-14, 180, 206, 448, 478-482
in Adobe Acrobat products 478
clipping 481
filling 480-481
flatness tolerance. See flatness tolerance
glyphs 14, 358, 481
images 481
for raster-scan displays 478
rules 480-481
smoothness tolerance. See smoothness tolerance
stroke adjustment 181, 185, 192, 201, 481-482
stroking 480
SCN operator 166, 210, 258, 259, 915
in
DeviceN color spaces 240
in
Indexed color spaces 234
in
Pattern color spaces 261, 264, 265, 268
in
Separation color spaces 235
scn operator 166, 210, 258, 259, 915
in
DeviceN color spaces 240
in
Indexed color spaces 234
in
Pattern color spaces 261, 264, 265, 268, 269
in
Separation color spaces 235
Scope standard structure attribute 863
screen annotation dictionaries
MK entry 602
Subtype entry 602
Screen annotation type 581, 602, 674
screen annotations 581, 602
page object 571
and rendition actions 602, 630
See also
screen annotation dictionaries
Screen blend mode 491, 537
screens, halftone
See halftone screens
Script font flag 429, 822
script fonts 429
scroll bars, hiding and showing 548
scrolling, text fields 653
SE entry (outline item dictionary) 555
searching of text 10, 440, 812, 820, 1014
second-class names 938
Sect standard structure type 827, 828, 833
security, document 17-18
See also
encryption
signatures, digital
security handlers 92, 92, 96-103, 937
Adobe.PPKLite 104
Adobe.PubSec 104
crypt filters 66, 108
encryption 43
Entrust.PPKEF 104
interoperability 92
public key 104-106
revision number 97, 98-99
standard 92, 96-103, 1009
selectfont operator (PostScript) 916
selective computation (object digests) 1039
selector rendition dictionaries 719
C entry 719
R entry 719
selector renditions 715, 719
See also selector rendition dictionary
separable blend modes 490-492
color space 490
for spot colors 490, 535
white-preserving 536
Separation color spaces 207, 232, 234-238, 238, 316
All colorant name 236
alternate color space for 237, 277
alternate color space, prohibited as 237, 240
as base color space 232, 233
blending color space, prohibited as 525
color values 235
colorant name 235-236, 237
DeviceN color spaces, colorant information for 242
and
DeviceN color spaces, compared 239
halftones for 476
initial color value 235, 257
None colorant name 236, 241
other color components, effect on in transparency
groups 533
and overprinting 254, 539-540
parameters 235-237
for preseparated pages 898
for printer’s marks 897
remapping of alternate color space 228
setting color values in 258
for shadings 277
in soft masks 520
specification 235
spot color components in 532, 533
for spot colorants 450, 489
tint transformation function 237, 277
tints 234, 235, 236, 257
in transparency groups 229
and transparent overprinting 537, 540
separation dictionaries 122, 897-898
ColorSpace entry 898
DeviceColorant entry 897
Index
1179
Pages entry 897
Separation OPI color type 910
SeparationColorNames entry (trap network appearance
stream dictionary) 906
SeparationInfo entry (page object) 122, 897
separations, color 205, 207, 234, 770, 890, 897
accurate screens algorithm 468
and colorants 235
composite pages, generation from 897
halftones for 475
and overprinting 254
preseparated files 897, 906
for spot color components 532
See also
separation dictionaries
Serif font classification (Tagged PDF) 822
Serif font flag 429, 821, 822
Serifed font characteristic 821
serifed fonts 429
set-OCG-state action dictionaries
PreserveRB entry 629
S entry 629
State entry 629, 630
set-state actions (obsolete) 615
setcachedevice operator (PostScript) 392, 914
setcharwidth operator (PostScript) 392, 914
setcmykcolor operator (PostScript) 914, 915
setcolor operator (PostScript) 915
setcolorspace operator (PostScript) 914
setdash operator (PostScript) 914
SetF entry (FDF field dictionary) 677
SetFf entry (FDF field dictionary) 677
setflat operator (PostScript) 914
setgray operator (PostScript) 914
sethalftone operator (PostScript) 1017
setlinecap operator (PostScript) 914
setlinejoin operator (PostScript) 914
setlinewidth operator (PostScript) 916
setmiterlimit operator (PostScript) 915
SetOCGState action type 356, 615, 629
set-OCG-state actions 615, 629-630
setrgbcolor operator (PostScript) 915
setscreen operator (PostScript) 1017
sFamilyClass field (TrueType font) 432
SGML (Standard Generalized Markup Language)
PDF logical structure compared with 784
sh operator 166, 259, 273, 915
background color ignored by 275
compositing 528
object shape 517
smoothness tolerance 479
target coordinate space 274
SHA-1 message digest 106
SHA1 object digest algorithm 689, 1037
SHA1 secure hash algorithm 689, 1037
shading dictionaries 148, 272, 274-276, 277
AntiAlias entry 275
Background entry 273, 275, 279, 280, 528
BBox entry 275, 278, 282
ColorSpace entry 273, 275, 276, 277
Function entry 276, 277
metadata 774
as named resources 129
sh operator 273
ShadingType entry 275, 278, 297
See also
type 1 shading dictionaries (function-based)
type 2 shading dictionaries (axial)
type 3 shading dictionaries (radial)
type 4 shading dictionaries (free-form Gouraud-
shaded triangle meshes)
type 5 shading dictionaries (lattice-form Gouraud-
shaded triangle meshes)
type 6 shading dictionaries (Coons patch meshes)
type 7 shading dictionaries (tensor-product patch
meshes)
Shading entry
resource dictionary 129, 273
type 2 pattern dictionary 272
shading objects 165
anti-aliasing 275
background color 275, 279, 280, 283
bounding box 275, 278, 279, 282
clipping 275
color space 227, 275, 276-277, 278, 279, 281, 285, 288,
290, 294
domain 148, 278, 279, 280, 281, 282
shading operator 273, 915
shading type 277-301
target coordinate space. See target coordinate space
See also
shading dictionaries
type 1 shadings (function-based)
type 2 shadings (axial)
type 3 shadings (radial)
type 4 shadings (free-form Gouraud-shaded
triangle meshes)
type 5 shadings (lattice-form Gouraud-shaded
triangle meshes)
type 6 shadings (Coons patch meshes)
type 7 shadings (tensor-product patch meshes)
shading operator 166, 273, 915
sh 166, 259, 273, 274, 275, 479, 517, 528, 915
Index
1180
shading patterns (type 2) 163, 232, 260, 272-301
color values, interpolation of 276-277
compositing of 528
extended graphics state 272, 528
gradient fill. See gradient fills
and graphics state parameter dictionaries 190
metadata for 774
nonzero overprint mode, unaffected by 256
object shape 517
smoothness tolerance 479
and transparent overprinting 536, 541
and type 3 (stitching) functions 148
See also
shading objects
type 2 pattern dictionaries
Shading resource type 129, 273
shading types 277-301
type 1 (function-based) 274, 275, 278-279
type 2 (axial) 274, 275, 277, 279-280
type 3 (radial) 274, 275, 277, 280-284
type 4 (free-form Gouraud-shaded triangle meshes)
274, 275, 284-288, 294
type 5 (lattice-form Gouraud-shaded triangle meshes)
274, 275, 289-291, 294
type 6 (Coons patch meshes) 274, 291-297, 297
type 7 (tensor-product patch meshes) 274, 297-301
ShadingType entry (shading dictionary) 275, 278, 297
shadow, diffuse achromatic 218
shape (transparent imaging model) 204, 484-485
alpha source parameter 182, 193, 311
anti-aliasing 495
backdrop 497, 498
in basic compositing formula 488
computation 494-498
current alpha constant 182, 192, 311
notation for 487
soft masks 486, 495, 518
specifying 517-519
See also
constant shape
group shape
mask shape
object shape
result shape
source shape
shape constant 495
shared object hint table (Linearized PDF) 951, 961-964,
1035
group entries 955, 960, 962, 963-964, 1034, 1035
header 962-963, 964, 1035
and page retrieval 971
shared object identifiers 960, 967
shared object identifiers (Linearized PDF) 959, 960, 967
shared object references (Linearized PDF) 959, 960, 960,
967
shared object signatures (Linearized PDF) 963, 1035
signature fields, distinguished from 963
ShellExecute function (Windows) 1022
shfill operator (PostScript) 915
shift direction 825, 855
Shift-JIS character encoding 404, 414, 420, 1006, 1025
show operator (PostScript) 916
show strings 358, 819, 821, 823
ShowControls entry (movie activation dictionary) 742
showing of text 358, 359-361, 975, 978
character encodings 395
CMaps 424, 425
IdentityH predefined CMap 416
IdentityV predefined CMap 416
operators 377-379, 1014
simple fonts 382
transparent overprinting 538
Type 3 fonts 391
SI entry (Web Capture content set) 882, 883, 884
Sig entry (FDF catalog) 673, 685
Sig field type 637, 658
Sig object type 686
SigFieldLock object type 659
SigFlags entry (interactive form dictionary) 635
signature dictionaries 684-688
ByteRange entry 684, 685, 686, 687, 688, 691, 693, 699,
700
Cert entry 686, 697
Changes entry 687
ContactInfo entry 687
Contents entry 67, 684, 686, 686, 687, 688, 697, 699
Filter entry 686, 697
Location entry 687, 688
M entry 687, 688
Name entry 687, 688
Prop_AuthTime entry 688
Prop_AuthType entry 688
Prop_Build entry 686, 688
R entry 687
Reason entry 687, 688
Reference entry 687, 688, 700
SubFilter entry 686, 686, 688, 697
Type entry 686
V entry 688
See also
signature field dictionaries
signature field lock dictionaries
signature field seed value dictionaries
signature reference dictionaries
Signature entry (UR transform parameters dictionary) 695
Index
1181
signature field dictionaries 658
FT entry 658
Lock entry 659
SV entry 659
T entry 658
V entry 658, 663
signature field lock dictionaries 659
Action entry 659
Fields entry 659
Type entry 659
signature field seed value dictionaries 659
Cert entry 660
Ff entry 659, 661
Filter entry 660
LegalAttestation entry 660, 661
MDP entry 660
Reasons entry 660
SubFilter entry 660
TimeStamp entry 660
Type entry 660
V entry 660
signature fields 635, 636, 637, 647, 658-661
access permissions 97, 99, 100
appearance 658
flags. See signature flags
shared object signatures (Linearized PDF), distin-
guished from 963
value 658
See also
signature field dictionaries
signatures,digital
signature flags 636
AppendOnly 636
SignaturesExist 636
signature handlers 684, 686
Adobe.PPKLite 686
CICI.SignIt 686
Entrust.PPKEF 686
name 684, 686
VeriSign.PPKVS 686
signature reference dictionaries 685-690
Data entry 673, 689, 696
DigestLocation entry 690
DigestMethod entry 689, 1037
DigestValue entry 690, 690, 691
TransformMethod entry 673, 685, 689, 690
TransformParams entry 685, 689
Type entry 689
signatures, digital 18, 100, 647, 684-702
in FDF files 674
Fingerprint authentication method 688
handlers 684, 686
and incremental updates 75, 674, 1003
and interactive forms 97, 99, 636
interoperability 697-699
Password authentication method 688
PIN authentication method 688
public/private-key (PPK) authentication 684
See also
digests
PKCS#1 signatures
PKCS#7 signatures
signature fields
SignaturesExist signature flag 636
Signed sound encoding format 740
SigRef object type 689
simple duration 727
simple file specifications 151
simple fonts 381, 382-403
descriptor 382-383
encodings. See character encodings
glyph selection 382
subsets 389, 1016
substitution 1017
Tj operator 360
ToUnicode CMaps, codespace ranges for 443
Unicode, mapping to 441
word spacing 369
See also
TrueType
®
fonts
Type 1 fonts
Type 3 fonts
SimpleDot predefined spot function 458, 459
sin operator (PostScript) 149, 917
single-byte character codes
in simple fonts 382
and text-showing operators 379
and word spacing 370
single-pass file generation 16-17
SinglePage page layout 115
SIS content set subtype (Web Capture) 882, 883
Size entry
cross-reference stream dictionary 83
embedded file parameter dictionary 158
file trailer dictionary 73, 83, 86, 949, 956
type 0 function dictionary 143, 144, 145
version 1.3 OPI dictionary 909
version 2.0 OPI dictionary 911, 912
skewing
images 309
OPI proxies 909
order of transformations 176
transformation matrices 169, 175
slash (
/) character 26, 126
as file specification delimiter 152, 155
Index
1182
as name delimiter 32, 34, 114, 428, 673
in uniform resource locators (URLs) 887
as UNIX file name delimiter 154
Slash line ending style 593
slideshow dictionaries 744
Resources entry 744
StartResource entry 744
Subtype entry 744
Type entry 744, 744
SlideShow object type 744
slideshows (alternate presentations) 744, 1029
SM entry (graphics state parameter dictionary) 192, 479
small-cap fonts 429
Smallcap font characteristic 821
SmallCap font flag 429, 821, 822
SMask entry
graphics state parameter dictionary 192, 518
image dictionary 65, 182, 311, 312, 320, 518, 522, 523,
542, 1018
SMaskInData entry (image dictionary) 65, 312, 518
SMIL (Synchronized Multimedia Integration Language)
file format 1028
SMIL (Synchronized Multimedia Integration Language)
standard
fit attribute 726
repeatCount attribute 727
simple duration 727
systemAudioDesc attribute 716
systemBitrate attribute 717
systemCaptions attribute 716
systemLanguage attribute 717
systemOperatingSystem attribute 737
systemScreenDepth attribute 717
systemScreenSize attribute 717
smoothness tolerance 183, 479-480
and color conversion 480
and flatness tolerance, compared 480
shading patterns 276
SM entry (graphics state parameter dictionary) 192
snd file format 739
soft clipping 192, 486, 495, 513, 518
and current clipping path, compared 192, 486, 513
and knockout groups 518
of multiple objects 518-519
and transparency groups 518
soft hyphen character (Unicode) 816, 820, 928
soft-mask dictionaries 182, 518, 520, 525, 1018
BC entry 520, 521
G entry 521, 525
S entry 521
TR entry 520, 521
Type entry 521
soft-mask image dictionaries 522, 523-524
Matte entry 312, 522, 523, 524
soft-mask images 311, 518, 519, 522-524, 1018
height 523
image data, preblending of 522-524
in JPEG2000 65, 312, 519
matte color 522, 524
source color 522
width 523
See also
soft-mask image dictionaries
soft masks 320, 486, 513-515
Alpha subtype 520, 521
alternate color space 520
for annotations 578
backdrop color 513, 514, 515, 521
bounding box 520
color space 515, 521, 522, 523, 524
coordinate system 520
current. See current soft mask
group backdrop 514, 520
Luminosity subtype 521, 525
mask values 520, 521
object color 513
opacity, as source of 486, 495, 518
shape, as source of 486, 495, 518
soft clipping 192, 486, 495, 513, 518
source color 513
specifying 518, 519-524
spot color components unavailable in 520
spot colors unavailable in 533
subtype 520, 521
transfer functions for 514, 515, 520, 521
transparency groups, deriving from 499, 520
group alpha 514, 520, 521
group luminosity 486, 514-515, 520, 521
See also
soft-mask dictionaries
soft-mask images
SoftLight blend mode 492
software identifier dictionaries 717, 734, 735, 736-738
H entry 736, 736, 737
HI entry 737
L entry 736, 737
LI entry 736
OS entry 736, 737
software URIs 737
Type entry 736
U entry 736, 737
version arrays 737
software identifier objects
See software identifier dictionaries
SoftwareIdentifier object type 736
Index
1183
Sold annotation icon 598
Solid border style 849
Solidities entry (DeviceN mixing hints dictionary) 244
“Solving the Nearest-Point-On-Curve Problem”
(Schneider) 1060
“Some Properties of Bézier Curves” (Goldman) 1060
Sony Trinitron
®
display 219
Sort field flag (choice field) 656
sound action dictionaries 625-626
Mix entry 626, 1022
Repeat entry 626
S entry 625
Sound entry 625, 739, 1022
Synchronous entry 626, 1022
Volume entry 626, 1022
Sound action type 615, 625
sound actions 615, 625-626, 1022
volume 626
See also
sound action dictionaries
sounds
sound annotation dictionaries 601
Contents entry 582
Name entry 601
Sound entry 601, 739
Subtype entry 601
Sound annotation type 581, 601
sound annotations 9, 581, 582, 600-601
activating 739
alternate text description 870
contents 582
and text annotations, compared 600, 601
See also
sound annotation dictionaries
sounds
Sound entry
sound action dictionary 625, 739, 1022
sound annotation dictionary 601, 739
sound files 739
AIFF 739
AIFF-C 739
RIFF 739
snd 739
Sound object type 739
sound objects 739-741
B entry 739, 740
C entry 739, 740
CO entry 740
CP entry 740
E entry 740
R entry 739, 740
and sound actions 625
and sound annotations 601
Type entry 739
SoundActions entry (legal attestation dictionary) 701
sounds 9, 568, 600, 609, 610, 625, 739-741, 1029
asynchronous 626
encoding format. See encoding formats, sound
mixing 626
in movies 601, 741, 742
synchronous 626
volume 626
See also
sound actions
sound annotations
sound objects
source alpha
in compositing 494
in knockout groups 509
notation 488, 501, 505
and overprinting 538
source color (transparent imaging model) 487
blending color space, conversion to 489
and CompatibleOverprint blend mode 536-537
compositing 493, 494
in isolated groups 507
and nonseparable blend modes 493
notation 488, 501, 505
and overprinting 534, 535
in patterns 528
and separable blend modes 490, 491, 492
and soft-mask images 522
and soft masks 513
specifying 516
in transparency groups 503, 505, 529
source gamut (page) 449
source information dictionaries (Web Capture) 882, 883-
885
AU entry 884
C entry 884
E entry 884, 885
S entry 884
TS entry 884, 885
source opacity 495-496, 498
in knockout groups 509
notation 496, 497, 501
source shape 495-496, 498
in knockout groups 509
notation 496, 497, 501, 505
SP entry (media rendition dictionary) 718, 719
space (SP) character 24, 26
clipping 372
in comments 27
in cross-reference table 70, 976
in font names 386, 388
Index
1184
in form field mapping names 664
in hexadecimal strings 32
in names 1005
nonbreaking 928
in reverse-order show strings 819
as word separator 823
word spacing 369
SpaceAfter standard structure attribute 845, 851, 860
SpaceBefore standard structure attribute 845, 851, 860
Span marked-content tag 834, 842, 864, 866, 867, 868, 869,
870, 871, 872
Span standard structure type 834, 839, 864
<span> XHTML element (rich text strings) 643
SpawnTemplate form usage rights 694
Speaker annotation icon 601
special color spaces 207, 232-254
blending color space, prohibited as 525
as default color spaces 228
inline images, prohibited in 324
for shadings 275
in transparency groups 531
See also
DeviceN color spaces
Indexed color spaces
Pattern color spaces
Separation color spaces
special graphics state operators 166
cm 166, 172, 180, 189, 308, 913
Q 166, 184, 189, 205, 264, 308, 327, 362, 372, 641, 782,
915, 920, 1033
q 166, 184, 189, 205, 264, 308, 327, 641, 782, 915, 920,
1033
specular highlight 218
spell-checking 653, 656, 812, 822
SpiderContentSet object type 882
SpiderInfo entry (document catalog) 116, 874
Split transition style 563, 564
spot color components 532
and alternate color space 532, 533
compositing of 532-533
in
DeviceN color spaces 532
and group opacity 533
and group shape 533
in multitones 238
and overprinting 539-540, 541
in
Separation color spaces 532, 533
separations for 532
soft masks, unavailable in 520
and tint transformation functions 532
tints for 532
transfer function 455
in transparency groups, painting of 532-533
and transparent overprinting 537, 540, 541
spot colorants 450
in composite pages 234, 532, 897
and current blend mode 516
DeviceN color spaces 242
and flattening of transparent content 545
and halftones 466, 476
in multitones 239
and overprinting 539-540
process colorants, approximation with 532
in
Separation color spaces 234
and transparent overprinting 534, 535, 540
spot colors
blending color space, not converted to 489
group color space, not converted to 532
in opaque imaging model 532
and separable blend modes 490, 535
soft masks, unavailable in 533
and transparency 532-533
and transparent overprinting 532, 535, 541
and white-preserving blend modes 535
spot functions 149, 458-464, 466, 467, 467, 1017
for color displays 465
predefined 149
and threshold arrays, compared 464
threshold arrays, converted internally to 465
See also
predefined spot functions
Spot OPI color type 910
SpotFunction entry (type 1 halftone dictionary) 467
SPS content set subtype (Web Capture) 882
sqrt operator (PostScript) 149, 917
square annotation dictionaries 594-595
BE entry 576, 594
BS entry 594
IC entry 594
RD entry 595
Subtype entry 594
Square annotation type 580, 594
square annotations 580, 593-595
border style 571, 575
border width 594
dash pattern 594
interior color 594
See also
square annotation dictionaries
Square line ending style 593
Square list numbering style 862
Square predefined spot function 463
Squiggly annotation type 581, 596
squiggly-underline annotation dictionaries
See text markup annotation dictionaries
Index
1185
squiggly-underline annotations
See text markup annotations
SR rendition type 716
sRGB (standard RGB) color space 226
group color space, unsuitable as 530
SS entry
number format dictionary 708
SS entry (transition dictionary) 565
St entry (page label dictionary) 560
stack
graphics state 184-185, 189
transparency. See transparency stack
stacking of BLSEs 825, 834, 846, 847, 848
floating elements exempt from 826
Stamp annotation type 581, 598
standard 14 fonts 16, 384, 385-386, 396, 821, 923, 978,
1015-1016
Courier 385, 1015
CourierBold 385, 1015
CourierBoldOblique 385, 1015
CourierOblique 385, 1015
Helvetica 385, 1015
HelveticaBold 385, 1015
HelveticaBoldOblique 385, 1015
HelveticaOblique 385, 1015
MacExpertEncoding not used for 924
Symbol 385, 396, 1015, 1017
TimesBold 385, 1015
TimesBoldItalic 385, 1015
TimesItalic 385, 1015
TimesRoman 385, 1015
ZapfDingbats 385, 396, 1015, 1017
standard attribute owners 801, 842-843
CSS-1.00 843, 844
CSS-2.00 843, 844
HTML-3.20 843, 844
HTML-4.01 843, 844
Layout 843, 844, 845
List 843, 844, 862
OEB-1.00 843, 844
RTF-1.05 843
Table 843, 844, 863
XML-1.00 843
standard blend modes 490-493, 516
standard character sets 923-936
expert 923, 924, 929-931
Latin 923, 924, 925-928, 1017
for
Symbol font 923, 932-934
for
ZapfDingbats font 923, 935-936
standard column attributes 861
ColumnCount 846, 861
ColumnGap 846, 861
ColumnWidths 846, 861
standard grouping elements 824, 827-829
Art 827, 828, 833
BlockQuote 828, 835
Caption 828, 831, 832
Div 827, 828, 829, 833
Document 827, 828, 833
Index 829, 834
NonStruct 829
Part 827, 828, 833
Private 829
Sect 827, 828, 833
strong structure 833
TOC 828, 834
TOCI 828, 828
usage guidelines 833
weak structure 833
standard illustration elements 824, 841-842
clipping in 841
Figure 841, 845, 853, 860
Form 818, 836, 841, 845, 853, 860
Formula 841, 845, 853, 860
standard layout attributes for 845, 853, 860-861
standard layout attributes 845-861
for BLSEs 845, 846, 851-855
BBox 839, 841, 845, 853
BlockAlign 825, 846, 854
EndIndent 824, 845, 852
Height 841, 845, 846, 853, 859, 860
InlineAlign 825, 846, 854
LineHeight 846
SpaceAfter 845, 851, 860
SpaceBefore 845, 851, 860
StartIndent 824, 845, 852, 852
TBorderStyle 846, 855
TextAlign 845, 853
TextIndent 845, 852, 852
TPadding 846, 855
Width 841, 845, 846, 853, 859, 860
general 846-848
BackgroundColor 845, 848
BorderColor 845, 849, 850
BorderStyle 845, 849, 855
BorderThickness 845, 850
Color 845, 850
Padding 845, 848, 849, 850, 850, 855
Placement 826, 829, 833, 841, 842, 845, 846, 851,
852, 860, 861
WritingMode 824, 845, 848, 855, 863
for grouping elements 846
for illustrations 845, 853, 860-861
for ILSEs 845, 846, 855-859
BaselineShift 834, 841, 846, 855, 860, 861
GlyphOrientationVertical 858
LineHeight 834, 846, 851, 856, 859
Index
1186
RubyAlign 857
RubyPosition 858
TextDecorationColor 846, 856
TextDecorationThickness 846, 856
TextDecorationType 834, 846, 857
for ruby text
RubyAlign 840, 846
RubyPosition 840, 846
for tables 853-855
for vertical text
GlyphOrientationVertical 846
standard list attribute 861-862
ListNumbering 861, 862
standard list elements 831, 833
L 830, 831, 861
Lbl 828, 830, 831, 835, 852, 861, 862
LBody 830, 831, 852
LI 830, 831, 861
standard paragraphlike elements 830, 852
H 830, 830, 833
H1–H6 830, 830, 833
P 828, 830, 830, 833
standard RGB (sRGB) color space 226
group color space, unsuitable as 530
standard ruby elements 839
RB 836, 840, 858
RP 836, 840
RT 836, 840, 858
Ruby 840
standard security handler (
Standard)92, 96-103, 1009
standard structure attributes 801, 812, 813, 826, 842-863
and basic layout model 823
inheritance 844
See also
standard attribute owners
standard column attributes
standard layout attributes
standard list attribute
standard table attributes
standard structure types 789, 812, 813, 826-842
and basic layout model 823
role map 786, 789
usage guidelines 833
See also
block-level structure elements (BLSEs)
inline-level structure elements (ILSEs)
standard grouping elements
standard illustration elements
standard table attributes 862-863
ColSpan 863
Headers 863
RowSpan 863
Scope 863
standard table elements 831-832, 833
standard layout attributes for 853-855
Table 830, 832, 845, 853
TBody 829, 832
TD 829, 832, 846, 848, 852, 853, 854, 859, 862, 863
TFoot 829, 832
TH 829, 832, 846, 852, 853, 854, 859, 862, 863
THead 829, 832
TR 829, 832, 848
standard warichu elements
Warichu 840
WP 836, 840
WT 836, 840
StandardEncoding predefined character encoding 396,
401, 923, 924
as implicit base encoding 397
standards warichu elements 839
start edge 825
of allocation rectangle 860
border color 849
border style 849
border thickness 850
in layout 826, 847, 852, 853, 854
padding width 850, 855
ruby text alignment 857
Start entry
movie action dictionary 627
movie activation dictionary 742
Start inline alignment 854
Start placement attribute 847, 852, 861
Start ruby text alignment 857
Start text alignment 853
StartIndent standard structure attribute 824, 845, 852, 852
StartResource entry (slideshow dictionary) 744
startxref keyword 73, 82, 949, 956, 969, 993, 995, 998,
1000
State entry
set-OCG-state action dictionary 629, 630
text annotation dictionary 585, 586
state, graphics. See graphics state
state models (annotation) 585, 586
StateModel entry (text annotation dictionary) 585, 586
states (annotation) 585
states (optional content groups) 335, 336, 337, 341, 346,
348, 353, 354, 355, 629, 630
Status entry (FDF dictionary) 674, 1025
StdCF crypt filter name 97
StemH entry (font descriptor) 427
StemV entry (font descriptor) 427, 822
stencil, uncolored tiling pattern as 262
stencil masking 307, 320-321
Index
1187
character glyphs, painting 320
and image interpolation 321
See also
image masks
stitching functions
See type 3 functions
Stm entry (marked-content reference dictionary) 792
StmF entry (encryption dictionary) 93, 93, 105, 106, 107,
108, 109, 110
StmOwn entry (marked-content reference dictionary) 792
Stop movie operation 627
stream dictionaries 36, 37, 38, 276, 323
DecodeParms entry 38, 42, 83, 107
DP abbreviation 1006
as direct objects 36
DL entry 39
F entry 38, 739
FDecodeParms entry 38, 42
FFilter entry 38, 41
Filter entry 38, 41, 83, 437, 522, 740
Length entry 37, 38, 40, 96, 276, 323, 437, 951, 975
Resources entry 128
See also
attribute objects
cross-reference stream dictionaries
embedded file stream dictionaries
ICC profile stream dictionaries
hint stream dictionaries
image dictionaries
metadata stream dictionaries
object stream dictionaries
PostScript XObject dictionaries
printer’s mark form dictionaries
sound objects
trap network appearance stream dictionaries
type 1 form dictionaries
type 1 pattern dictionaries (tiling)
type 4 shading dictionaries
type 5 shading dictionaries
type 6 halftone dictionaries
type 6 shading dictionaries
type 10 halftone dictionaries
stream keyword 36-37, 38, 1006
stream objects 25, 27, 36-38, 91, 1006
as attribute objects 801
in cross-reference table reconstruction 921
data 36, 38, 324
as dictionary values 131
extent 37
indirect objects 36
length 36, 670
metadata associated with 774, 775
strings, compared with 36
syntax 36-38, 1006
text streams 132
See also
stream dictionaries
streams
appearance. See appearance streams
CIDFont subsets 432
CMap files 384, 391, 412, 419, 423, 441
color table 233
content. See content streams
cross-reference. See cross-reference streams
embedded CIDFont programs 405
embedded CMaps 405, 418, 419
embedded file. See embedded file streams
embedded font programs 358, 382, 387, 428, 436, 437
encryption 91
external 37, 38, 41, 42, 1006, 1031
FDF differences 674
glyph descriptions 389, 391
halftone 465, 469, 472, 473
hint (Linearized PDF). See hint streams
HTTP form submissions 887
ICC profile 222, 900
See also ICC profile stream dictionaries
image 36, 305, 306, 310
JavaScript scripts 668, 676
and JBIG2 encoding 57, 58
metadata. See metadata streams
number of bytes in 39
object streams 76-81
page descriptions 36
pattern 260, 264
poster image (movie) 741
PostScript LanguageLevel 1 303
shading 272, 276, 285
sound objects 739-741
threshold arrays 466
ToUnicode CMaps 441
trap networks 906
type 0 (sampled) functions 142, 143
type 4 (PostScript calculator) functions 148
See also
stream objects
stream dictionaries
StrF entry (encryption dictionary) 93, 94, 105, 106, 107,
108, 109
strikeout annotation dictionaries
See text markup annotation dictionaries
StrikeOut annotation type 581, 596
strikeout annotations
See text markup annotations
string objects 25, 26, 27, 29-32
as dictionary values 131
length limit 29, 920
Index
1188
as name tree keys 134, 157, 553, 580, 668, 669
syntax 29-32
strings
color table 233
default appearance. See default appearance strings
destinations, names of 553
element identifiers (logical structure) 787
encryption 91, 94
file identifiers 775
file specification 152-155, 156
hexadecimal 29, 32
JavaScript scripts 668, 676
literal 29-31
production condition names 899
production condition registry 899
reverse-order show strings 818-819
showing. See showing of text
text. See text strings
text objects 357
Web Capture content types 882
See also
string objects
stroke adjustment, automatic 185, 481-482
for raster-scan displays 481
See also
stroke adjustment parameter
stroke adjustment parameter 181
S operator 201
SA entry (graphics state parameter dictionary) 192,
482
stroke operator (PostScript) 913, 915
stroking
color. See stroking color, current
color space. See stroking color space, current
glyphs 371, 439, 1014
ink annotations 599
paths 12, 163, 164, 181, 184, 185, 186, 188, 201-202,
599, 913, 915, 980
scan conversion 480
stroke adjustment 181, 185, 192, 201, 481-482
text 12, 164, 362, 371
text rendering mode 371, 439, 1014
and transparent overprinting 536, 538-539, 541
stroking alpha constant, current 182, 192, 519
and fully opaque objects 542
initialization 527
and overprinting 538, 539
setting 519
stroking color, current 180, 184
DeviceCMYK color space 213, 258, 914
DeviceGray color space 212, 258, 914
DeviceN color spaces 240
DeviceRGB color space 213, 258, 915
initial value 257
and
S operator 201
Separation color spaces 235
setting 206, 210, 257-258, 914, 915
text, showing 361, 371
stroking color space, current 180
CIE-based color spaces 215
color components, number of 257
DeviceCMYK color space 213, 258, 914
DeviceGray color space 212, 258, 914
DeviceRGB color space 213, 258, 915
Indexed color spaces 232
and
S operator 201
setting 206, 210, 257-258, 914
StructElem object type 787
StructParent entry 786, 797, 798, 798
annotation dictionary 573, 798
image dictionary 312, 523, 798
type 1 form dictionary 329, 798
StructParents entry 786, 797, 798, 798, 800, 867
page object 122, 798, 800
type 1 form dictionary 329, 798
StructTreeRoot entry (document catalog) 116, 785, 827
StructTreeRoot object type 786
structural parent tree 786, 797-801
annotations 573
form XObjects 329
image XObjects 312
next key 786, 797
page objects 122
structure, logical
See logical structure
structure attributes 801-806
attribute classes 786, 802
owner 801, 802
revision number 788, 802, 803-804
standard. See standard structure attributes
structure element dictionaries 787-788
A entry 788, 788, 802, 803, 804, 842, 844
ActualText entry 441, 788, 816, 820, 821, 823, 842, 844,
871, 872
Alt entry 788, 816, 820, 821, 842, 844, 870, 871, 872
C entry 788, 802, 803, 804, 842, 844
E entry 788, 820, 842, 844, 872
ID entry 787, 863
K entry 785, 787, 790, 796
Lang entry 788, 842, 844, 864, 865, 867
P entry 787
Pg entry 787, 791, 792, 796
R entry 788, 803
S entry 787, 826, 827
T entry 788
Type entry 787, 787
Index
1189
structure elements 784, 785
abbreviation expansion 788
access, dictionary entries for 798
alternate description 788, 815, 870, 871
annotations, sequencing of 818
attribute classes 788, 802
attribute objects associated with 788
and basic layout model (Tagged PDF) 823
block-level (BLSEs). See block-level structure elements
content items associated with 787, 789
content items, finding from 786, 797-801, 867
element identifier 786, 787
form XObjects in 793-796
inline-level (ILSEs). See inline-level structure elements
language identifier 116, 788
natural language specification 864, 866, 867, 868-869
non-graphical information (user properties) 804
outline items, associated with 555
replacement text 788, 871-872
revision number 788, 803, 804
structure type 787, 826, 827
Tagged PDF layout 827
title 788
See also
structure attributes
structure element dictionaries
structure types
structure hierarchy 785-788
and accessibility to users with disabilities 864, 866,
867, 868
in Linearized PDF 956
logical structure order 817
table of contents parallel to 828
See also
structure elements
structure tree root
structure tree
See structure hierarchy
structure tree root 116, 785-786
class map 786, 802, 842
ClassMap entry 786, 802, 842
and content extraction 827
IDTree entry 786, 787
K entry 785, 786, 827
ParentTree entry 786, 797, 798
ParentTreeNextKey entry 786, 797
role map 786, 789
RoleMap entry 786
Type entry 786
structure types 34, 787, 789
marked-content tags and 790
role map 786
standard. See standard structure types
Style dictionaries
See CIDFont
Style dictionaries
Style entry (CIDFont font descriptor) 431
sub operator (PostScript) 149, 917
Sub predictor function (LZW and Flate encoding) 51, 52
SubFilter entry
encryption dictionary 92, 93, 104, 105, 106
signature dictionary 686, 686, 688, 697
signature field seed value dictionary 660, 661
Subj entry (markup annotation dictionary) 584
Subject entry
certificate seed value dictionary 661
document information dictionary 772
submit-form action dictionaries 662-663
F entry 662
Fields entry 663, 665, 666
Flags entry 663, 665
S entry 662
submit-form actions 615, 662-666, 1024-1025, 1026
FDF differences stream 674
field flags, effects on 638
flags. See submit-form field flags
status string 674
See also
submit-form action dictionaries
submit-form field flags 662-665
CanonicalFormat 665
IncludeNoValueFields 663, 665, 666
EmbedForm 665
ExclFKey 665
ExclNonUserAnnots 665
ExportFormat 663, 665, 666
GetMethod 664, 664
Include/Exclude 663, 665, 666
IncludeAnnotations 664
IncludeAppendSaves 664, 674
SubmitCoordinates 664
SubmitPDF 663, 664, 664, 666
XFDF 664, 664, 665, 666
Submit Web Capture command flag 887
SubmitCoordinates field flag (submit-form field) 664
SubmitForm action type 615, 662
SubmitPDF field flag (submit-form field) 663, 664, 664,
666
SubmitStandalone form usage rights 694
sub-page navigation 566-568
subpaths 195, 197, 204, 372, 914, 915
subscripts 373
shift direction 855
subsets, font
See font subsets
subtractive color components
and blend functions 540
Index
1190
subtractive color representation 211
in blending color space 489, 525
and default color spaces 228
DeviceCMYK color space 213
and halftones 457
and overprinting 540
process color components 211
in soft-mask images 522
tints 235, 240, 532, 540
transfer functions, input to 455
subtractive colorants 234, 236
See also
black colorant
cyan colorant
magenta colorant
yellow colorant
subtractive output devices 234, 236, 458
Subtype entry 35-36
3D annotation dictionary 747
3D background dictionary 764
3D stream dictionary 752, 753, 758
annotation dictionary 570, 580
caret annotation dictionary 597
CIDFont dictionary 407
circle annotation dictionary 594
CreatorInfo subdictionary, optional content usage
dictionary 350
DeviceN color space attributes dictionary 239, 241,
242, 243
embedded file stream dictionary 158, 721
embedded font stream dictionary 428, 436, 438
external object (XObject) 302, 303
file attachment annotation dictionary 600
font dictionary 36, 358, 381
free text annotation dictionary 589
image dictionary 310, 323, 523, 557
ink annotation dictionary 598
line annotation dictionary 590
link annotation dictionary 587
Mac OS file information dictionary 159
measure dictionary 704, 705
metadata stream dictionary 774
movie annotation dictionary 601
multiple master font dictionary 386
PageElement subdictionary, optional content usage
dictionary 351
polygon annotation dictionary 595
polyline annotation dictionary 595
pop-up annotation dictionary 599
PostScript XObject dictionary 303
Print subdictionary, optional content usage dictionary
351
printer’s mark annotation dictionary 896
projection dictionary 758, 760, 761
rubber stamp annotation dictionary 598
screen annotation dictionary 602
slideshow dictionary 744
sound annotation dictionary 601
square annotation dictionary 594
text annotation dictionary 586
text markup annotation dictionary 596
trap network annotation dictionary 605, 905
TrueType font dictionar y 388
Type 0 font dictionary 403, 423
Type 1 font dictionary 383
type 1 form dictionary 328
Type 3 font dictionary 390
watermark annotation dictionary 606
widget annotation dictionary 603
subtypes, object
See object subtypes
SummaryView annotation usage rights 694
superscripts 373
shift direction 825, 855
Supplement entry (CIDSystemInfo dictionary) 406, 415,
433
supplement number (character collection) 406, 418, 442
Supporting the DCT Filters in PostScript Level 2 (Adobe
Technical Note #5116) 1059
Suspects entry (mark information dictionary) 785, 818
SV entry (signature field dictionary) 659
SVCert object type 661
SVG (Scalable Vector Graphics)(in slideshows) 1029
SW entry (icon fit dictionary) 679
SWF (Macromedia Flash) file format 1028
Sy entry (caret annotation dictionary) 597
Symbol font classification (Tagged PDF) 822
Symbol standard font 385, 396, 1015, 1017
character encoding, built-in 923, 932-934
character names 441
character set 923, 932-934
Symbol typeface 16
Symbolic font flag 429
symbolic fonts 396, 429, 430
base encoding 397
built-in encoding 396, 397, 923
Synchronized Multimedia Integration Language (SMIL 2.0)
(World Wide Web Consortium) 1064
Synchronous entry
movie activation dictionary 743
sound action dictionary 626, 1022
syntax, PDF 23-162
array objects 34
boolean objects 28
character set 25-26
Index
1191
comments 27, 1005
data structures 130-139
dates 133
dictionary objects 35-36
document structure 112-125
encryption 91-103, 1009
file specifications 151-162
file structure 66-75, 1008-1009
filters 41-62, 1006-1008
functions 139-151
indirect objects 39-41
integer objects 28
lexical conventions 24-27
name objects 32-34, 1005-1006
name trees 134-138
null object 39
number trees 138-139
numeric objects 28-29
objects 27-41
real objects 28
rectangles 134
stream objects 36-38, 1006
string objects 29-32
text strings 131-132
systemAudioDesc attribute (SMIL) 716
systemBitrate attribute (SMIL) 717
systemCaptions attribute (SMIL) 716
systemLanguage attribute (SMIL) 717
systemOperatingSystem attribute (SMIL) 737
systemScreenDepth attribute (SMIL) 717
systemScreenSize attribute (SMIL) 717
T
T entry
bead dictionary 561, 953
FDF field dictionary 677, 1026
field dictionary 637, 638, 639, 658
floating window parameters dictionary 731
hide action dictionary 628
hint stream dictionary 951
linearization parameter dictionary 948, 971
markup annotation dictionary 583, 585, 599, 665
media duration dictionary 727
media offset time dictionary 732
movie action dictionary 627
rectilinear measure dictionary 706
structure element dictionary 788
target dictionary 619
Web Capture page set 882
T highlighting mode (toggle) 603
T* operator 166, 368, 371, 376, 915
TA entry (go-to-3D-view action dictionary) 633
tab character
See horizontal tab (HT) character
tab order (annotations) 122, 569-570, 1019
table attributes, standard
See standard table attributes
table elements, standard
See standard table elements
Table standard attribute owner 843, 844, 863
Table standard structure type 830, 832
standard layout attributes for 845, 853
tables of contents 828, 834
Tabs entry (page object) 122, 569
Tag annotation icon 600
tag suspects (Tagged PDF) 785, 817
Tagged PDF 391, 769, 812-863
accessibility to users with disabilities 812, 813, 816,
827, 842
annotations, sequencing of 818
artifacts. See artifacts
basic layout model 812, 823-826
character properties, extraction of 819-821
content reflow. See reflow of content
exporting 842, 843, 845, 856
font characteristics, determination of 820-822
hidden page elements 816-817
hyphenation 816, 826
and logical structure 769, 812, 813, 814
logical structure order 817
mark information dictionary 116, 784-785
page content 812, 813-823
page content order 812, 813, 816, 817-819, 864
real content 813, 814, 814
reverse-order show strings 818-819
standard structure attributes. See standard structure at-
tributes
standard structure types. See standard structure types
tag suspects 785, 817
text discontinuities 816
Unicode, mapping to 441, 812, 813, 820
word breaks, identifying 812, 813, 819, 822-823
tags
algorithm (PNG predictor functions) 52
font subset 389, 428, 432, 1016
marked-content 778, 779, 937
TIFF 911
Tags entry
version 1.3 OPI dictionary 911
version 2.0 OPI dictionary 911
Tags for the Identification of Languages (Internet RFC
3066) 431, 865, 1062
TagSuspect entry
Index
1192
property list 817
TagSuspect marked-content tag 817-818
target attribute (HTML) 675
target coordinate space 274, 275, 278, 279, 281, 286, 290,
294, 300
target coordinate system (3D annotations) 748, 757, 758,
760, 761, 767
target dictionaries 618, 619
A entry 619
N entry 619
P entry 619
R entry 619
T entry 619
target document (reference XObject) 331, 332
Target entry (FDF dictionary) 675
TBody standard structure type 829, 832
TBorderStyle standard structure attribute 846, 855
TbRl writing mode 848
Tc operator 166, 368, 915
TD operator 166, 371, 376, 916
Td operator 166, 360, 376, 915
TD standard structure type 829, 832, 863
content rectangle 859
stacking direction 848
standard layout attributes for 846, 852, 853, 854
standard table attributes for 862
Technical Notes, Adobe
See Adobe Technical Notes
Template object type 669
template pages 125, 680-681, 1027
TemplateInstantiated entry (page object) 122, 1044
Templates entry
FDF page dictionary 680
name dictionary 125, 669
tensor-product patch meshes
See type 7 shadings
tensor-product patches, bicubic 297, 298-300
terminal fields 634, 637
text 357-446
alignment. See text alignment
exporting 440, 820, 829
extraction of 16, 97, 99, 100, 379, 842
filling 12, 164, 371
indexing 440, 812
in pattern cells 262
positioning 360
searching 10, 379, 440, 812, 820, 1014
special graphical effects 361-363
spell-checking 653, 656, 812, 822
stroking 12, 164, 371
subscripts 373, 855
superscripts 373, 825, 855
and transparent overprinting 536, 541
See also
fonts
glyphs, character
showing of text
text line matrix
text matrix
text objects
text operators
text rendering matrix
text rendering mode
text space
text state
writing mode
text alignment 853
Center 853
End 853
Justify 853
Start 853
text annotation dictionaries 586
IRT entry 585
Name entry 586
Open entry 586
State entry 585, 586
StateModel entry 585, 586
Subtype entry 586
Text annotation type 580, 586
text annotations 75, 99, 586-587, 1020
access permissions for 97
font 586
and free text annotations, compared 588
modification date, updating 1019
rotation, not subject to 586
scaling, not subject to 586
and sound annotations, compared 600, 601
text size 586
in updating example 992, 993, 995, 996, 997, 998, 1000
See also
text annotation dictionaries
Text Boundaries (Unicode Standard Annex #29) 823, 1063
text color (Tagged PDF) 850
text decoration type 857
LineThrough 857
None 857
Overline 857
Underline 857
text discontinuities 816
text field dictionaries 654
MaxLen entry 653, 654
text field flags 653
Comb 653
DoNotScroll 653
Index
1193
DoNotSpellCheck 653
FileSelect 653, 654
Multiline 653
Password 653
RichText 640, 645, 653
text fields 637, 647, 653-655
flags. See text field flags
trigger events for 612
value 653, 654
variable text in 639
See also
text field dictionaries
text files 15, 25
text font (T
f
) parameter 367
Font entry (graphics state parameter dictionary) 191
showing of text 359
Tf operator 368, 916
text font size (T
fs
) parameter 367
Font entry (graphics state parameter dictionary) 191
showing of text 359
text matrix, updating of 380
text space 376
Tf operator 360, 368, 916
unscaled text space units unaffected by 368
text/html content type (MIME) 882
text identifiers (Web Capture page sets) 879, 881, 882
text knockout (T
k
) parameter 367, 373-374
TK entry (graphics state parameter dictionary) 193
transparent overprinting independent of 538
text line matrix (T
lm
) 367, 374, 377
text markup annotation dictionaries 596
QuadPoints entry 596, 1021
Subtype entry 596
text markup annotations 596-597, 1021
See also
text markup annotation dictionaries
text matrix (T
m
) 173, 360, 367, 368, 374, 377, 379-380
text size 360
translation 378
text object operators 166, 374-375
BT 166, 360, 371, 375, 641, 779, 841, 913
ET 166, 371, 375, 641, 779, 841, 914
marked-content operators, combined with 779-780
text objects 12, 164, 357, 359, 374-380, 913, 914
as clipping paths 205, 371-372, 780, 782
and color operators 256
and default appearance strings 641
in glyph descriptions 390
and graphics state 168
illustration elements (Tagged PDF) prohibited within
841
operators in 375
showing text 359
text knockout parameter 193, 373, 516
text line matrix 367
text matrix 367
text rendering matrix 367
text state operators 367
text state parameters 367
Type 3 fonts in 375
See also
text object operators
text operators 163, 978
in text objects 357, 374
Text procedure set 375
See also
text object operators
text-positioning operators
text-showing operators
text state operators
Type 3 font operators
text position, current
See current text position
text-positioning operators 166, 376-377
in dynamic appearance streams 642
T* 166, 368, 371, 915, 376
TD 166, 371, 376, 916
Td 166, 360, 376, 915
in text objects 375, 377
Tm 166, 376, 641, 916
Text procedure set 375, 770
text rendering matrix (T
rm
) 367, 374, 380
text rendering mode (T
mode
) 367, 371-372, 439, 1014
and marked content 780, 782
special graphical effects 361, 362
Tr operator 368, 916
and transparent overprinting 538-539
Type 3 fonts unaffected by 362, 371
text rise (T
rise
) parameter 367, 373
text space 376, 379
Ts operator 368, 916
text-showing operators 166, 364, 377-379, 380, 916, 1014
' (apostrophe) 166, 368, 371, 377, 916
" (quotation mark) 166, 368, 371, 377, 916
and CMaps 405, 424
and composite fonts 403
in dynamic appearance streams 642
glyph positioning 364, 365, 376, 377
glyph selection 382
object shape 517
in text objects 375
TJ 166, 364, 368, 370, 378, 380, 916, 1014
Tj 166, 259, 260, 265, 269, 273, 360, 361, 362, 363, 364,
368, 377, 379, 424, 916, 1014
and Type 3 fonts 391, 392, 393
text space 173, 191, 376, 379-380
Index
1194
device space, relationship with 380
glyph positioning 365
glyph space, relationship with 364, 379, 390
origin 364, 376
rotation 376
scaling 361, 368, 370, 376
text size 360-361
and text state parameters 371
translation 363, 365, 376, 378
and Type 3 glyph descriptions 391
units 360-361, 378, 384
user space, relationship with 376, 377
text state 357, 366
See also
text state operators
text state parameters
text state operators 166, 188, 367-368
in default appearance strings 640, 641
initialization 367
Tc 166, 368, 915
in text objects 375
Tf 36, 166, 191, 359, 360, 368, 406, 641, 916
TL 166, 368, 916
Tr 166, 362, 368, 916
Ts 166, 368, 916
Tw 166, 368, 916
Tz 166, 368, 916
text state parameters 181, 357, 361, 366-367, 368-374
See also
character spacing (T
c
) parameter
horizontal scaling (T
h
) parameter
leading (T
l
) parameter
text font (T
f
) parameter
text font size (T
fs
) parameter
text knockout (T
k
) parameter
text line matrix (T
lm
)
text matrix (T
m
)
text rendering matrix (T
rm
)
text rendering mode (T
mode
)
text rise (T
rise
) parameter
word spacing (T
w
) parameter
text streams 132
text strings 131-132
as annotation names 131, 571
as article names 131
as bookmark names 131
as choice field options 657, 1024
as dictionary values 131
encodings for 131, 924
as FDF option names 678
as field names 638
as field values 650, 653, 654
as name tree keys 553
as page set titles (Web Capture) 882
as production condition names 899
as streams 132
as structure element titles 788
as trap network descriptions 906
See also
rich text strings
text streams
text-to-speech conversion 863
abbreviations and acronyms 872, 873
alternate descriptions 870
artifacts 815
hidden page elements 817
natural language specification 769
Unicode 820
word breaks 822
text-align CSS2 style attribute (rich text strings) 644
TextAlign standard structure attribute 845, 853
text-decoration CSS2 style attribute (rich text strings) 644
TextDecorationColor standard structure attribute 846, 856
TextDecorationThickness standard structure attribute 846,
856
TextDecorationType standard structure attribute 834, 846,
857
Text In dent standard structure attribute 845, 852, 852
TF entry (media permissions dictionary) 722
Tf operator 36, 166, 191, 359, 360, 368, 916
CIDFonts, inapplicable to 406
in default appearance strings 641
TFoot standard structure type 829, 832
TH standard structure type 829, 832, 863
content rectangle 859
standard layout attributes for 846, 852, 853, 854
standard table attributes for 862
THead standard structure type 829, 832
third-class names 938
thread action dictionaries 623
B entry 623
D entry 623
F entry 553, 623
S entry 623
Thread action type 615, 623
thread actions 615, 623
and Linearized PDF 970
and named destinations 553
target bead 623
target file 623
target thread 623
See also
thread action dictionaries
thread dictionaries 115, 560-561
F entry 561
I entry 561, 938, 955
Index
1195
in Linearized PDF 949, 953, 955
thread actions, target of 623
Type entry 561
thread information dictionaries 561
in Linearized PDF 949, 955
registered names not required in 938
thread actions, target of 623
thread information hint table (Linearized PDF) 951, 966
Thread object type 561
threads, article 558, 560, 561
in document catalog 112, 115
in Linearized PDF 953, 970, 971, 972, 973
and thread actions 623
See also
articles
beads
thread dictionaries
thread information dictionaries
Threads entry (document catalog) 115, 560, 623, 949, 971
three-dimensional graphics. See 3D artwork
threshold arrays 464-465, 466
device space, defined in 464, 469, 473, 474
height 469
and spot functions, compared 464
spot functions converted internally to 465
type 6 halftones 466, 469
type 10 halftones 466, 469, 470
type 16 halftones 466, 473, 474
width 469
Thumb entry (page object) 121, 557, 953
thumbnail hint table (Linearized PDF) 951, 964-965
header 964-965
per-page entries 964, 965
thumbnail images 550, 557
access permission 97, 100
color space 557
display of 112
hiding and showing 115, 548
image XObjects as 305, 309, 557
in Linearized PDF 955, 964-965
in page object 112, 121
sample limit 921
unrecognized filters in 1007
TI entry (choice field dictionary) 657
TID entry (Web Capture page set) 881, 882
TIFF (Tag Image File Format) Predictor 2 predictor
function 52
TIFF (Tag Image File Format) standard 47, 51, 911
%%TIFFASCIITag OPI comment (PostScript) 911
tilde, right angle bracket (
~>) character sequence
as EOD marker 45, 46
tiling patterns (type 1) 232, 260, 261-271
bounding box 263
colored 262, 264-268, 529
compositing in 528
compositing of 528
and fully opaque objects 542
gradient fills in 273
key pattern cell 263
metadata for 774
object opacity 496
object shape 496, 517
painting with 264
pattern cell. See pattern cells
resources 263
spacing 263
and text objects 375
uncolored 258, 262, 268-271, 529
See also
type 1 pattern dictionaries
tiling types (tiling patterns)
type 1 (constant spacing) 263
type 2 (no distortion) 263
type 3 (constant spacing and faster tiling) 263
TilingType entry (type 1 pattern dictionary) 263
time scale (movie) 742
time stamp dictionaries 660
Ff entry 660
URL entry 660
time stamp information (PKCS#7 objects) 698
Times* typeface 16, 358, 923
TimesBold standard font 385, 1015
TimesBoldItalic standard font 385, 1015
TimesItalic standard font 385, 1015
TimesRoman standard font 385, 1015
TimesNewRoman standard font name 1015
TimesNewRoman,Bold standard font name 1015
TimesNewRoman,BoldItalic standard font name 1015
TimesNewRoman,Italic standard font name 1015
timespan dictionaries 727, 732, 733
S entry 733
Type entry 733
V entry 733
Timespan object type 733
TimeStamp entry (signature field seed value dictionary)
660
Tint entry (version 1.3 OPI dictionary) 910
tint transformation functions 148, 223, 228, 237, 240-241
and color separations 898
for
DeviceN color spaces 240-241, 242, 256, 277
for
Separation color spaces 237, 277
and spot color components 532
tints
Index
1196
All colorant name 236
CS operator 257
DeviceN color spaces 240
in halftones 457
and overprint mode 255
and overprint parameter 254
Separation color spaces 234, 235, 236
for spot color components 532
subtractive color representation 235, 240, 532, 540
tint transformation function 240
title bar
document window 548
pop-up window 572, 583
Title entry
document information dictionary 772
outline item dictionary 555
TJ operator 166, 364, 368, 370, 378, 380, 916, 1014
Tj operator 166, 360, 377, 916, 1014
character spacing 368
and CMaps 424
glyph positioning 363, 364
with multiple glyphs 379
with patterns 259, 265, 269, 273
special graphical effects 361, 362
tiling patterns, emulating with 260
word spacing 368
TK entry (graphics state parameter dictionary) 193, 367,
373
TL operator 166, 368, 916
TM entry (field dictionary) 637, 664
Tm operator 166, 376, 916
in default appearance strings 641
“to CIE” information (ICC color profile) 225, 900, 1032
TOC standard structure type 828, 834
TOCI standard structure type 828, 828
Toggle state (optional content groups) 629, 630
ToggleNoView annotation flag 574, 1020
tokens, lexical 24, 25, 26, 27, 67, 121
tool bars, hiding and showing 548
tool tips
See pop-up help systems
topmost object 542
TopSecret annotation icon 598
ToUnicode CMaps 442-446, 1016
beginbfrange and endbfrange operators in 422
CMap format, based on 420
for content extraction 16
syntax 442-443, 445-446
in Tagged PDF 441, 820
for Type 0 fonts 423
for Type 1 fonts 384
for Type 3 fonts 391
ToUnicode entry 441
Type 0 font dictionary 423
Type 1 font dictionary 384
Type 3 font dictionary 391
ToUnicode Mapping File Tutorial (Adobe Technical Note
#5411) 443, 1059
TP entry (appearance characteristics dictionary) 605
TPadding standard structure attribute 846, 855
TR entry
graphics state parameter dictionary 192, 259, 455, 702
soft-mask dictionary 520, 521
Tr operator 166, 362, 368, 916
TR standard structure type 829, 832
stacking direction 848
TR2 entry (graphics state parameter dictionary) 192, 259,
455
trailer, file
See file trailer
trailer dictionaries 83
trailer keyword 73, 83, 672
Trans action type 615, 632
Trans entry
page object 121, 562, 568
transition action dictionary 632
Trans object type 563
transfer functions 447, 454-456, 466
additive colors produced by 455, 458
for CMYK devices 454
color inversion with 455
current. See current transfer function
for
DeviceGray color space 456
for halftone screens 468, 469, 472, 474, 475
halftones, applied before 454, 456
for soft masks 514, 515, 520, 521
and transparency 542-543
TransferFunction entry
type 1 halftone dictionary 468
type 6 halftone dictionary 469
type 10 halftone dictionary 472
type 16 halftone dictionary 474
transform methods (object signatures) 690-696
DocMDP 689, 690-692, 700, 701
FieldMDP 685, 689, 690, 695, 696
Identity 673, 689, 696
UR 685, 689, 692, 700
transform parameters (object signatures) 689, 690
DocMDP 691, 692, 696
FieldMDP 695
UR 693
transformation matrices 169, 174, 177-179
3D artwork 758, 765-767
CIE-based color space 216, 217, 218, 219, 221
Index
1197
reference XObject 332
specification 175, 178
type 1 (function-based) shading 278
See also
current transformation matrix (CTM)
font matrix
form matrix
pattern matrix
text line matrix
text matrix
text rendering matrix
transformations, coordinate
See coordinate transformations
TransformMethod entry (signature reference dictionary)
673, 685, 689, 690
TransformParams entry (signature reference dictionary)
685, 689
TransformParams object type 692, 693, 695
transition action dictionaries
S entry 632
Trans entry 632
transition actions 615, 632
transition dictionaries 121, 562-564
B entry 565
D entry 564, 565
Di entry 563, 564, 564
Dm entry 563, 564
M entry 563, 564
S entry 563
SS entry 565
Type entry 563
transition duration 565
transition style 563-564
Blinds 563, 564
Box 563, 564
Cover 564, 564
Dissolve 563
Fade 564
Fly 563, 564, 565
Glitter 563, 564
Push 564, 564
R 563
Split 563, 564
Uncover 564, 564
Wipe 563, 564
translation
images 308
order of transformations 176
text space 363, 365, 376, 378
transformation matrices 169, 174, 175
transparency
See transparent imaging model
Transparency entry (version 1.3 OPI dictionary) 910
transparency group attributes dictionaries 525-526
CS entry 521, 525, 527
I entry 525, 526
K entry 526, 527
S entry 525
Transparency group subtype 331, 525, 527
transparency group XObjects 165, 331, 524-527
graphics state parameters, initialization of 181, 182
soft masks, definition of 520, 521
version compatibility 1004
transparency groups 165, 331, 485-486, 499-513
alpha. See group alpha
as annotation appearances 526, 578
backdrop. See group backdrop
backdrop alpha 503
backdrop color 503
and black-generation functions 544
blend mode 485, 499, 505, 507, 508
blending color space. See blending color space
bounding box 527
clipping to bounding box 527
color. See group color
color space. See group color space
compositing computations. See compositing computa-
tions
compositing in 485, 486, 499, 502, 514, 525, 527, 529
compositing of 485, 486, 499, 502, 503, 520, 525, 526,
527, 529, 538
constant opacity 499
constant shape 499
elements 502, 504, 505, 507, 508, 510
group attributes dictionary 121
hierarchy 485, 499
immediate backdrop (group elements). See immediate
backdrop
initial backdrop. See initial backdrop
mask opacity 499
mask shape 499
nested 485, 499, 502, 544
and nonstroking alpha constant 519
notation 503
opacity. See group opacity
and overprinting 538, 541
page group 121, 486, 510-512, 524-525
painting 526-527
in pattern cells 528
and rendering intents 543
rendering parameters ignored for 542
shape. See group shape
soft clipping 518
soft masks, deriving from 499, 520
group alpha 514, 520, 521
group luminosity 486, 514-515, 520, 521
spot color components, painting of 532-533
Index
1198
stack. See group stack
structure and nomenclature 502
and undercolor-removal functions 544
See also
isolated groups
knockout groups
non-isolated groups
non-knockout groups
transparency group XObjects
transparency stack 165, 484
graphics objects and 516
group. See group stack
opacity 485
page group 486, 542
shape 485
and transparency groups 485, 499, 500
transparent imaging model 11, 165, 483-545
and alternate color space 237, 241, 489
appearance streams and 578
backdrop. See backdrop
halftones and 542-543
JPEG2000 and 64
opaque overprinting, compatibility with 536-537, 538
overprinting 534-541
overview 484-486
patterns and 528-529
PostScript, compatibility with 544-545
rendering intents and 543-544
rendering parameters and 541-544
spot colors and 532-533
text, showing of 371
text knockout parameter 193, 367, 373-374, 538
transfer functions and 542-543
version compatibility 1004-1005
See also
alpha
blend modes
blending color space
compositing
opacity
shape
soft masks
transparency groups
transparency stack
trap network annotation dictionaries 904-905
AnnotStates entry 904, 905
FontFauxing entry 905
LastModified entry 904, 905
Subtype entry 605, 905
Version entry 904, 905, 906, 1033
trap network annotations 581, 605-606, 903-905, 1033
appearance streams. See trap network appearances
See also
trap network annotation dictionaries
trap network appearance stream dictionaries 906
PCM entry 906
SeparationColorNames entry 906
TrapRegions entry 906
TrapStyles entry 906
trap network appearances 903, 905-906
See also trap network appearance stream dictionaries
trap networks 903-906
current 904
modification date 905
regeneration 904
validation 904, 1033
TrapNet annotation type 581, 582, 605, 674, 904, 905
Trapped entry (document information dictionary) 772
trapping 534, 605, 770, 890, 902-906
document status 772
instructions 903
parameters 903, 906
and preseparated files 906
zones 903, 906
See also
trap network annotations
trap network appearances
trap networks
TrapRegion objects (PJTF) 906
TrapRegions entry (trap network appearance stream
dictionary) 906
TrapStyles entry (trap network appearance stream
dictionary) 906
trees
balanced 117, 1059
of chained actions 610
interactive form 636
name. See name trees
number. See number trees
page 112, 114, 117-124, 669, 975, 983
structural parent 122, 312, 329, 573
structure. See structure hierarchy
TRef entry (FDF template dictionary) 680, 680
triangle meshes, Gouraud-shaded 294
free-form. See type 4 shadings
lattice-form. See type 5 shadings
trigger events 116, 609, 610-614, 1021-1022
for annotations 572, 611-612
Bl (annotation) 612
C (form field) 613, 614
C (page) 612
D (annotation) 611, 613, 614
DC (document) 613
for documents 613
DP (document) 613
DS (document) 613
E (annotation) 611, 613, 614, 627
Index
1199
F (form field) 613, 614
for FDF fields 678
Fo (annotation) 611
for form fields 612-613, 614, 638
K (form field) 612, 614
mouse-related 611, 614
for multimedia 611
O (page) 612
for pages 612
PC (annotation) 612
PI (annotation) 612
PO (annotation) 612
and pop-up help systems 627
PV (annotation) 612
U (annotation) 611, 613, 614
V (form field) 613, 614
WP (document) 613
WS (document) 613
X (annotation) 611, 613, 614, 627
trim box 891
clipping to 893
display of 895
in page object 120
page placement, ignored in 893
for page positioning 893
printer’s marks excluded from 894
in printing 893
TrimBox entry
box color information dictionary 895
page object 120, 891, 1032
Trinitron
®
display, Sony 219
tristimulus values 214, 216, 218, 219, 221
true (boolean object) 28
true operator (PostScript) 149, 918
TrueType 1.0 Font Files Technical Specification (Microsoft
Corporation) 387, 432, 1062
TrueType font dictionaries 388-389, 439
BaseFont entry 388-389
Encoding entry 388, 399, 400, 401, 402
Subtype entry 388
TrueType font programs
“cmap” table 399-402, 409, 439
“cvt ” table 439
embedded 16, 428, 436, 437, 439
“fpgm” table 439
“glyf ” table 437, 439, 440
“head” table 439
“hhea” table 439
“hmtx” table 439
“loca” table 439
“maxp” table 439
“name” table 388
“OS/2” table 432
“post” table 399, 401
“prep” table 439
sFamilyClass field 432
“vhea” table 439
“vmtx” table 439
TrueType font type 36, 381, 388, 436, 437
TrueType
®
fonts 6, 387-389
built-in encoding 399
character encodings 399-403, 439, 924
font descriptors for 428
format 358, 387
glyph descriptions 399, 400, 401, 408, 416, 439
glyph indices 409, 416
in Linearized PDF 954
PostScript name 388-389
in PostScript XObjects 303
subsets 389
synthesized styles 388
and Type 2 CIDFonts 406, 408, 416, 423
vertical metrics 439
See also
TrueType font dictionaries
TrueType font programs
TrueType Reference Manual (Apple Computer, Inc.) 387,
436, 1059
TrueTypeFonts entry (legal attestation dictionary) 702
truncate operator (PostScript) 149, 917
TS entry
source information dictionary 884, 885
Web Capture content set 882
Ts operator 166, 368, 916
TT entry (floating window parameters dictionary) 731
TU entry (field dictionary) 637, 871
Tw operator 166, 368, 916
TwoColumnLeft page layout 115
TwoColumnRight page layout 115
TwoPageLeft page layout 115
TwoPageRight page layout 115
Tx field type 637, 642
Type 0 CIDFont programs
compact 437, 438, 439
Type 0 CIDFonts 406
glyph selection 408
PostScript name 407, 423
See also
Type 0 CIDFont programs
Type 0 font dictionaries 403, 412, 422-423
BaseFont entry 423
DescendantFonts entry 405, 423, 424
Encoding entry 405, 423, 424
Subtype entry 403, 423
ToUnicode entry 423
Index
1200
Type entry 423
Type 0 fonts 381, 403-425
character identification 442
CID-keyed fonts as 405
CIDFonts 381
CIDFonts as descendants of 406, 423, 425, 442
CMap mapping 424, 1017
descendant fonts 403, 423
font descriptors lacking in 426
glyph selection 422-425
IdentityH predefined CMap 416
IdentityV predefined CMap 416
root font 403
undefined characters 425
See also
Type 0 font dictionaries
type 0 function dictionaries (sampled) 143
BitsPerSample entry 143, 144
Decode entry 142, 143, 145-146
Encode entry 142, 143
Order entry 143, 145, 1011
Size entry 143, 144, 145
type 0 functions (sampled) 140, 142-145, 1011
clipping to domain 143
clipping to range 144
clipping to sample table 143
decoding of output values 144
dimensionality 142
encoding of input values 143
interpolation 144
sample data 142, 143, 144
and smoothness tolerance 480
See also
type 0 function dictionaries
Type 1 font dictionaries 383-384, 386, 388, 1014-1015
BaseFont entry 34, 303, 383
Encoding entry 384, 399
FirstChar entry 384, 384, 386, 1016
FontDescriptor entry 384, 386, 1016
LastChar entry 384, 384, 386, 1016
Name entry 383, 1014
Subtype entry 383
ToUnicode entry 384
Type entry 383
Widths entry 384, 384, 386, 1016
Type 1 Font Format Supplement (Adobe Technical Note
#5015) 386, 1057, 1058
Type 1 font programs
clear-text portion 437, 438
compact 436, 438, 439
embedded 16, 428, 436, 437, 1014-1015
encrypted portion 437, 438
fixed-content portion 437, 438
PaintType entry 439
Type 1 fonts 6, 16, 383-387, 1014-1015
built-in encoding 384, 399, 924
character encodings 398-399, 924
compact 438
font descriptors for 428
FontName entry 383
format 358
glyph descriptions 383
glyph widths 384, 1014-1015
hints 383
in Linearized PDF 954
multiple master 386-387, 1017
in PostScript files 22
in PostScript XObjects 303
standard. See standard 14 fonts
subsets 389
and Type 0 CIDFonts 406
and Type 3 fonts, compared 390
See also
Type 1 font dictionaries
Type 1 font programs
type 1 form dictionaries 328-329
BBox entry 327, 328, 332, 526, 577, 640, 859, 860
FormType entry 328
Group entry 329, 330, 332, 524, 527, 578
LastModified entry 329
Matrix entry 327, 328, 332, 520, 577
Metadata entry 329
Name entry 330, 1013
OC entry 330
OPI entry 329, 907
PieceInfo entry 329, 329, 776
Ref entry 329, 331, 332
Resources entry 328, 640, 642
StructParent entry 329, 798
StructParents entry 329, 798
Subtype entry 328
Type entry 328
type 1 halftone dictionaries 467-468
AccurateScreens entry 467, 468
Angle entry 467
Frequency entry 467
HalftoneName entry 467
HalftoneType entry 467
SpotFunction entry 467
TransferFunction entry 468
Type entry 467
type 1 halftones 466, 467-468
See also type 1 halftone dictionaries
type 1 pattern dictionaries (tiling) 262-263
BBox entry 263, 263
Matrix entry 263, 327
PaintType entry 262, 529
PatternType entry 262
Index
1201
Resources entry 263
TilingType entry 263
Type entry 262
XStep entry 263
YStep entry 263
type 1 patterns (tiling)
See tiling patterns
type 1 shading dictionaries (function-based) 278
Domain entry 278
Function entry 278
Matrix entry 278
type 1 shadings (function-based) 274, 278-279
coordinate system 278
See also
type 1 shading dictionaries
Type 2 Charstring Format, The (Adobe Technical Note
#5177) 1059
Type 2 CIDFonts 406
encoding 423
glyph selection 408-409
and
IdentityH predefined CMap 416
and
IdentityV predefined CMap 416
PostScript name 407, 423
type 2 function dictionaries (exponential interpolation)
146
C0 entry 146
C1 entry 146
N entry 146
type 2 functions (exponential interpolation) 140, 141, 146,
1011
See also type 2 function dictionaries
type 2 pattern dictionaries (shading) 272, 273, 274
ExtGState entry 272, 528
Matrix entry 272, 327
PatternType entry 272
Shading entry 272
Type entry 272
type 2 patterns (shading)
See shading patterns
type 2 shading dictionaries (axial) 279
Coords entry 279
Domain entry 279
Extend entry 279
Function entry 279
type 2 shadings (axial) 274, 277, 279-280
parametric variable 279, 280
See also
type 2 shading dictionaries
Type 3 font dictionaries 381, 390-391
CharProcs entry 340, 390, 391, 392, 393, 399
Encoding entry 390, 399, 1016
FirstChar entry 390
FontBBox entry 390
FontDescriptor entry 391
FontMatrix entry 364, 390, 391
LastChar entry 390
Name entry 390
Resources entry 391
Subtype entry 390
ToUnicode entry 391
Type entry 390
Widths entry 391, 392, 393
Type 3 font operators 166, 392-393
d0 166, 390, 392, 914
d1 166, 259, 390, 392, 393, 914
Type 3 fonts 128, 173, 381, 389-395, 1016
bounding box 390, 392, 393, 914
character encodings 395, 399
font descriptors lacking in 426, 382
font matrix 364
glyph descriptions 389, 390, 390, 391-392, 1007
glyph widths 391, 392, 392-393, 914
hints unavailable in 390
metrics 364
PostScript and PDF, compared 392
resource dictionary 391, 1016
in text objects 375
text rendering mode, unaffected by 362, 371
and Type 1 fonts, compared 390
See also
Type 3 font dictionaries
Type 3 font operators
type 3 function dictionaries (stitching) 147
Bounds entry 147
Encode entry 147
Functions entry 147
type 3 functions (stitching) 141, 147-148, 1012
for inverting function domains 148
See also
type 3 function dictionaries
type 3 shading dictionaries (radial) 281
Coords entry 281
Domain entry 281
Extend entry 281
Function entry 281
type 3 shadings (radial) 274, 277, 280-284
blend circles 281-283
parametric variable 281
See also
type 3 shading dictionaries
type 4 functions (PostScript calculator) 141, 148-151,
1012
error detection and reporting 151
language limitations 149
null operands and results 28
operand stack 150
Index
1202
operand syntax 149
operators 149, 917-918
predefined spot functions, definitions of 459-463
as spot functions 1017
as transfer functions 455
type 4 shading dictionaries (free-form Gouraud-shaded
triangle mesh) 285
BitsPerComponent entry 285
BitsPerCoordinate entry 285
BitsPerFlag entry 285
Decode entry 285
Function entry 285
type 4 shadings (free-form Gouraud-shaded triangle
meshes) 274, 284-288
data format 285-288
edge flags 285, 286-288
parametric variable 285, 286, 288
See also
type 4 shading dictionaries
type 5 halftone dictionaries 468, 469, 472, 475
Default entry 475
HalftoneName entry 475
HalftoneType entry 475
keys 466
Type entry 475
type 5 halftones 466, 475-478
default halftone 475
transfer functions required for components 468, 469,
472
type 5 halftones, prohibited as components of 475
See also
type 5 halftone dictionaries
type 5 shading dictionaries (lattice-form Gouraud-shaded
triangle mesh) 290
BitsPerComponent entry 290
BitsPerCoordinate entry 290
Decode entry 290
Function entry 290
VerticesPerRow entry 290
type 5 shadings (lattice-form Gouraud-shaded triangle
meshes) 274, 289-291
data format 289, 290-291
parametric variable 290
See also
type 5 shading dictionaries
type 6 halftone dictionaries 469, 469
HalftoneName entry 469
HalftoneType entry 469
Height entry 469, 469, 472
TransferFunction entry 469
Type entry 469
Width entry 469, 469, 472
type 6 halftones 466, 469
and type 10 halftones, compared 469, 472
See also
type 6 halftone dictionaries
type 6 shading dictionaries (Coons patch mesh) 294, 297
BitsPerComponent entry 294
BitsPerCoordinate entry 294
BitsPerFlag entry 294
Decode entry 294
Function entry 294
type 6 shadings (Coons patch meshes) 274, 291-297
data format 294-297
edge flags 295-297
parametric variables 291, 292, 294, 296
See also
type 6 shading dictionaries
type 7 shading dictionaries (tensor-product patch mesh)
297
type 7 shadings (tensor-product patch meshes) 274, 297-
301
data format 300-301
edge flags 300-301
parametric variables 299
See also
type 7 shading dictionaries
type 10 halftone dictionaries 472
HalftoneName entry 472
HalftoneType entry 472
TransferFunction entry 472
Type entry 472
Xsquare entry 472
Ysquare entry 472
type 10 halftones 466, 469-473
and type 6 halftones, compared 469, 472
and type 16 halftones, compared 473
See also
type 10 halftone dictionaries
type 16 halftone dictionaries 474
HalftoneName entry 474
HalftoneType entry 474
Height entry 473, 474, 474
Height2 entry 473, 474, 474
TransferFunction entry 474
Type entry 474
Width entry 473, 474, 474
Width2 entry 473, 474, 474
type 16 halftones 466, 473-474
and type 10 halftones, compared 473
See also
type 16 halftone dictionaries
Type 42 fonts 22
inapplicable to PDF 387
Type entry 35-36
3D background dictionary 764
Index
1203
3D reference dictionary 754
3D stream dictionary 752
3D view dictionary 757
action dictionary 610
annotation dictionary 570
bead dictionary 561
border style dictionary 576
certificate seed value dictionary 661
CIDFont dictionary 407
CMap dictionary 419
cross-reference stream dictionary 83
crypt filter dictionary 108
Crypt filter parameter dictionary 66
DocMDP transform parameters dictionary 692
document catalog 114
embedded file stream dictionary 158
encoding dictionary 397
external object (XObject) 302
FieldMDP transform parameters dictionary 695
file specification dictionary 155, 156, 162
fixed print dictionary 607
floating window parameters dictionary 730
font descriptor 426
font dictionary 36
graphics state parameter dictionary 190
group attributes dictionary 331
halftone dictionary 466
image dictionary 310, 323, 523
marked-content reference dictionary 792
measure dictionary 705
media clip dictionary 720
media criteria dictionary 716
media duration dictionary 727
media offset dictionaries 732
media permissions dictionary 722
media play parameters dictionary 725
media player info dictionary 735
media players dictionary 734
media screen parameters dictionary 728
metadata stream dictionary 774
minimum bit depth dictionary 717
minimum screen size dictionary 718
navigation node dictionary 567
number format dictionary 707
object reference dictionary 796
object stream dictionary 77
optional content group dictionary 334, 335
optional content membership dictionary 336
outline dictionary 554
page label dictionary 559
page object 119
page tree node 118
PDF/X output intent dictionary 899
PostScript XObject dictionary 303
property list (Tagged PDF artifact) 814, 815
rendition dictionary 716
signature dictionary 686
signature field lock dictionary 659
signature field seed value dictionary 660
signature reference dictionary 689
slideshow dictionary 744, 744
soft-mask dictionary 521
software identifier dictionary 736
sound object 739
stream dictionary 302
structure element dictionary 787, 787
structure tree root 786
thread dictionary
561
timespan dictionary 733
transition dictionary 563
Type 0 font dictionary 423
Type 1 font dictionary 383
type 1 form dictionary 328
type 1 halftone dictionary 467
type 1 pattern dictionary 262
type 2 pattern dictionary 272
Type 3 font dictionary 390
type 5 halftone dictionary 475
type 6 halftone dictionary 469
type 10 halftone dictionary 472
type 16 halftone dictionary 474
UR transform parameters dictionary 693
User subdictionary, optional content usage dictionary
351, 353
version 1.3 OPI dictionary 908
version 2.0 OPI dictionary 911
viewport dictionary 704
Web Capture content set 882
Type0 font type 381, 403, 423
Type1 font type 36, 381, 383, 436, 437
Type1C embedded font subtype 436, 438
Type3 font type 381, 390
typefaces
Adobe Garamond
®
384
Courier 16, 923
Helvetica* 16, 358, 359, 360, 923, 978
ITC Zapf Dingbats
®
16, 265, 923
New York 388
Poetica
®
389
Symbol 16
Times* 16, 358, 923
types, object
See object types
Tz operator 166, 368, 916
U
U border style (underline) 576
Index
1204
U entry
additional-actions dictionary 611
encryption dictionary 98, 101, 102-103
number format dictionary 707
software identifier dictionary 736, 737
URL alias dictionary 885, 885
U trigger event (annotation) 611, 613, 614
U3D 3D stream subtype 752, 758
U3D format (3D artwork) 746, 753, 758
U3DPath entry
3D view dictionary 758
UC entry (floating window parameters dictionary) 731
UCR entry (graphics state parameter dictionary) 191, 259,
453, 702
UCR2 entry (graphics state parameter dictionary) 191,
259, 453
UCS-2 character encoding 412, 413, 414, 415
UHC (Unified Hangul Code) character encoding 415,
1025
unbalanced parentheses 29, 30, 31
Unchanged state (optional content groups) 346
uncolored tiling patterns 258, 262, 268-271
color value for painting 268
content stream 259
in transparent imaging model 529
Uncover transition style 564, 564
undefined characters (Type 0 fonts) 425
undercolor-removal function 183, 452, 453, 454
and transparency 541, 542, 543, 544
UCR entry (graphics state parameter dictionary) 191
UCR2 entry (graphics state parameter dictionary) 191
underline annotation dictionaries
See text markup annotation dictionaries
Underline annotation type 581, 596
underline annotations
See text markup annotations
Underline text decoration type 857
underlying color space (
Pattern color space) 228, 258, 268,
531
underscore (
_) character
in file specifications 154
in multiple master font names 386
undoing changes 18
UniCNSUCS2H predefined CMap 414, 417
UniCNSUCS2V predefined CMap 414, 417
UniCNSUTF16H predefined CMap 414, 417
UniCNSUTF16V predefined CMap 414, 417
Unicode character encoding 16
for alternate descriptions 871
byte order marker 132
for field names 1023
for field values 653, 674
hard hyphen character 816
JavaScript 1.2 incompatible with 1025
for JavaScript scripts 668, 1025
list numbering 862
Microsoft Unicode 401
natural language escape 132, 865, 871, 872, 873
soft hyphen character 816, 820, 928
Tagged PDF, mapping from 441, 812, 813, 820
for text strings 131-132, 924
TrueType character names, mapping to 401
UCS-2 412, 413, 414, 415
UTF-8 34, 1006
UTF-16BE 132, 412, 413, 414, 415, 445, 646
word breaks 823
Unicode Consortium 1063
Bidirectional Algorithm, The (Standard Annex #9) 848
Text Boundaries (Standard Annex #29) 823
Unicode Standard, The 131, 440, 820
Unicode Standard, The (Unicode Consortium) 131, 440,
820, 1063
Uniform Resource Identifiers (URI)
Generic Syntax (Internet RFC 2396) 624, 737, 1062
uniform resource identifiers (URIs) 624
for production condition registry 899
Uniform Resource Locators (Internet RFC 1738) 152, 161,
878, 1061
uniform resource locators (URLs)
file specifications 152, 155, 161, 662
and Linearized PDF 940, 941
redirection 885
in submit-form actions 662, 1024, 1025
“unsafe” characters in 878
Web Capture 125, 873, 874, 875, 876, 878, 884, 886,
887, 888, 1031
See also URL alias dictionaries
UniGBUCS2H predefined CMap 413, 416
UniGBUCS2V predefined CMap 413, 416
UniGBUTF16H predefined CMap 413, 416
UniGBUTF16V predefined CMap 413, 416
UniJISUCS2H predefined CMap 414, 417
UniJISUCS2HWH predefined CMap 415, 417
UniJISUCS2HWV predefined CMap 415, 417
UniJISUCS2V predefined CMap 415, 417
UniJISUTF16H predefined CMap 415, 415, 417
UniJISUTF16V predefined CMap 415, 417
UniKSUCS2H predefined CMap 415, 417
UniKSUCS2V predefined CMap 415, 417
UniKSUTF16H predefined CMap 415, 417
UniKSUTF16V predefined CMap 415, 417
Index
1205
Union function 497, 498, 500, 504, 506, 509, 512
unit size (default user space) 122, 171, 360, 921, 1033
universal resource identifiers (URIs), in software identifier
dictionaries 737
Universal Time (UT) 133
Unix entry
file specification dictionary 155, 156
launch action dictionary 622
UNIX
®
operating system
Acrobat “Print As Image” feature unavailable in 1009
application launch parameters 621, 622
conversion from PostScript to PDF 20
file names 154, 670
file system 155
Unmarked annotation state 585
Up predictor function (LZW and Flate encoding) 51, 52
updates, incremental
See incremental updates
UpperAlpha list numbering style 862
UpperRoman list numbering style 862
UR entry (permissions dictionary) 685, 692, 693, 700,
1027
UR transform method 685, 689, 692, 700
UR transform parameters dictionaries
Annots entry 694
Document entry 693
EF entry 695
Form entry 694
FormEx entry 694
Msg entry 693
P entry 695
Signature entry 695
Type entry 693
V entry 693
UR3 entry (permissions dictionary) 685, 687, 692, 693,
694, 700
URI action dictionaries 624
IsMap entry 624
S entry 624
URI entry 624
URI action type 615, 624
URI actions 116, 615, 624-625, 1022
for annotations 624
base URI 625
and go-to actions 588
and link annotations 588
OpenAction entry (document catalog), ignored for 624
outline items, ignored for 624
See also
URI action dictionaries
URI dictionaries
URI dictionaries 116, 625
Base entry 625
URI entry
document catalog 116, 625, 723
URI action dictionary 624
URIActions entry (legal attestation dictionary) 701
URIs. See uniform resource identifiers
URL alias dictionaries 884, 885, 1031
C entry 885
U entry 885, 885
URL entry
certificate seed value dictionary 661
time stamp dictionary 660
Web Capture command dictionary 886
URL file specifications 152, 161, 662
URL file system 155, 161
URLs. See uniform resource locators
URLS entry (name dictionary) 125, 875, 876, 877, 878, 882
US Secure Hash Algorithm 1 (SHA1) (Internet RFC 3174)
1062
usage application dictionaries 347, 352-356
Category entry 352
Event entry 352, 353, 356
OCGs entry 352, 353, 356
usage dictionaries (optional content) 335
Usage entry (optional content group dictionary) 335, 335,
350
usage rights 676, 692-695
annotation
Copy 694
Create 694
Delete 694
Export 694
Import 694
Modify 694
Online 694
SummaryView 694
document
Fullsave 693
embedded files
Create 695
Delete 695
Import 695
Modify 695
form
BarcodePlainText 694
Export 694
FillIn 694
Import 694
Online 694
SpawnTemplate 694
SubmitStandalone 694
signatures
Index
1206
Modify 695
validating signatures 693
See also
UR transform method
UseCMap entry (CMap dictionary) 419, 422, 443
usecmap operator (PostScript) 422
usefont operator (PostScript) 422
UseNone page mode 115, 548
UseOC page mode 115, 548
UseOutlines page mode 115, 548, 945, 949, 953
User entry (optional content usage dictionary) 351, 353
user interface
controller bars (movies) 742
field names 637, 870
icons 568, 572, 586, 586, 598, 600, 601, 1020
menu bar 548
menu items 636, 1023
navigation controls 548
Print Setup dialog 1032
pushbuttons 636
scroll bars 548
tool bars 548
windows
See
document windows
floating windows
pop-up windows
See also
actions
annotations
document outline
interactive forms
mouse
movies
page mode
presentations
sounds
thumbnail images
user password 96, 98, 99, 100, 101
computing (algorithm) 102-103
user properties 785, 804-806
See also
user property dictionaries
user property dictionaries 805
F entry 805
H entry 805
N entry 805
V entry 805
user space 170-172
current transformation matrix (CTM) 163, 174, 180
default. See default user space
form space, mapping from 327, 328
glyph space, mapping from 392
glyphs in 360
and graphics state parameters 371
image space, relationship with 305, 307
rotation 574
scaling 574
and
sh operator 273
shadings, target coordinate space for 274
soft-mask images in 523
text position in 360
text space, relationship with 376, 377
URI actions, mouse position for 624
UserProperties attribute owner 804
UserProperties entry (mark information dictionary) 785,
805
UserUnit entry (page object) 122, 171, 360, 1033
UseThumbs page mode 115, 548
UT (Universal Time) 133
UTF-8 character encoding 34, 1006
UTF-16BE character encoding 132, 412, 413, 414, 415,
445, 646
V
V entry
additional-actions dictionary 613
bead dictionary 561
DocMDP transform parameters dictionary 692
encryption dictionary 92, 93, 95, 98, 101, 107, 1009
FDF field dictionary 654, 674, 677, 1026
field dictionary 638, 639, 645, 648, 651, 654, 657, 658,
663, 666, 683, 685
FieldMDP transform parameters dictionary 695
file specification dictionary 156
fixed print dictionary 607
go-to-3D-view action dictionary 633
hint stream dictionary 951
media criteria dictionary 717
media play parameters
MH/BE dictionaries 713, 726
minimum bit depth dictionary 718
minimum screen size dictionary 718
signature dictionary 688
signature field seed value dictionary 660
timespan dictionary 733
UR transform parameters dictionary 693
user property dictionary 805
Web Capture information dictionary 874
v operator 166, 196, 199, 916
V predefined CMap 414, 417
V trigger event (form field) 613, 614
V2 decryption method (crypt filters) 97, 108, 109
VA entry
3D stream dictionary 633, 747, 749, 753, 753, 757
Index
1207
values
in dictionaries 35
in name trees 134, 135
in number trees 139
variable-pitch fonts 363, 429
variable text (form fields) 639-642
default resource dictionary 640, 641
resources 642
rich text strings 642
See also
default appearance strings
dynamic appearance streams
VE entry (optional content membership dictionary) 336,
337, 344
VeriSign.PPKVS signature handler 686
version compatibility, PDF 1-2, 1001-1035
compatibility sections 127
default color spaces 227
document outline 555
extensibility 18
go-to actions 616
logical structure 555
named destinations 553
procedure sets 770
version specification 68
Version entry
document catalog 68, 75, 114, 717, 1002, 1003, 1004,
1010
FDF catalog 671, 673, 1025
trap network annotation dictionary 904, 905, 906,
1033
version 1.3 OPI dictionary 908
version 2.0 OPI dictionary 911
versions, PDF 2
character collections 416-418, 442
color spaces 211, 214, 223, 227, 448
compatibility. See version compatibility, PDF
and FDF files 670, 671, 673, 1025
form XObjects, resources for 328
ICC profiles 224
imaging models 11, 165
linearization independent of 946
masked images 319-320
PostScript XObjects 303
specification 66, 68, 75, 114, 1002
TrueType font encodings 400
version numbers 1001-1004
major 1001, 1002
minor 1001, 1002, 1002-1003
vertical text attributes
GlyphOrientationVertical 846
vertical writing
character spacing 369
in CIDFonts 407, 410-411, 433, 434
glyph displacement 380
R2L reading order 549
word spacing 369
writing mode 1 365-366
vertical-align CSS2 style attribute (rich text strings) 644
Vertices entry
polygon annotation dictionary 595
polyline annotation dictionary 595, 595
VerticesPerRow entry (type 5 shading dictionary) 290
“vhea” table (TrueType font) 439
viability (multimedia objects) 713-714
View entry (optional content usage dictionary) 351, 353
View event type (usage application dictionary) 352, 353,
355, 356
View intent (optional content) 335, 338, 346
ViewArea entry (viewer preferences dictionary) 549
ViewClip entry (viewer preferences dictionary) 549
viewconsumerer applications, PDF
font management 357
viewer applications, PDF
annotation handlers, standard 570
annotation icons, predefined appearances for 586, 598,
600, 601
annotations, scaling and rotation of 575
articles, navigation facilities for 560
chained actions, execution of 610
color separations, previewing of 898
compatibility, cross-platform 19, 21
compatibility, version 1001-1035
date strings 571
font management 1014
form fields, variable text in 639, 640, 641, 642
implementation limits 919-921
launch actions, response to 622
Linearized PDF, processing of 939, 942, 953, 954, 955,
969, 970, 971, 972, 973
mouse, responding to 614
movies, asynchronous playing of 743
named actions 628
named pages, handling of 669
outline items, responding to 554
page boundaries, display of 120, 893-894
passwords, handling of 653
presentations 121, 562
private data ignored by 776
remote go-to actions, response to 617
scan conversion 481
signatures, digital 636
Sort choice field flag ignored by 656
sound formats 740
sounds, synchronous playing of 626
text annotations, font and size for 586
Index
1208
thumbnail images, display of 557
unknown annotation types, handling of 579
user interface 548-549
viewer preferences 547-550, 1018
viewer preferences dictionary 114, 547-550
CenterWindow entry 548
Direction entry 549, 569
DisplayDocTitle entry 548
FitWindow entry 548
HideMenubar entry 548
HideToolbar entry 548
HideWindowUI entry 548
NonFullScreenPageMode entry 548
PageLayout entry erroneously documented in 1011,
1018
PrintArea entry 549
PrintClip entry 550
PrintScaling entry 550
ViewArea entry 549
ViewClip entry 549
ViewerPreferences entry (document catalog) 114, 547, 949
viewing of documents 17
document window, size and positioning of 548
embedded fonts, copyright restrictions on 436
glyph widths in 1014
output medium, dialog with user on 448
page boundaries 549
page mode 115, 548
version compatibility 1001
viewport dictionaries 122, 704
BBox entry 703, 704
Measure entry 703, 704
Name entry 704
Type entry 704
Viewport object type 704
viewports 122, 703-704, 706
ViewState entry (View subdictionary, optional content us-
age dictionary) 351, 353
vignettes 495, 513
visibility expressions (optional content) 336-338
visibility policy (optional content membership
dictionaries) 335, 336
AllOff 336, 337, 342
AllOn 336, 337
AnyOff 336, 337
AnyOn 336, 337
VisiblePages list mode (optional content configuration
dictionary) 347
“vmtx” table (TrueType font) 439
Volume entry
movie activation dictionary 742
sound action dictionary 626, 1022
VP entry (page object) 122, 703
W
W entry
border style dictionary 576
box style dictionary 895
CIDFont dictionary 407, 410
cross-reference stream dictionary 83, 84
inline image object 323
media screen parameters
MH/BE dictionaries 728
W operator 166, 195, 202, 204, 205, 780, 782, 916
w operator 166, 183, 189, 362, 916
W* operator 166, 195, 202, 204, 205, 780, 782, 916
W2 entry (CIDFont dictionary) 407, 411, 439
Warichu ruby text position 858
Warichu standard structure type 836, 840
Warnock, John xxii
watermark annotation dictionaries
FixedPrint entry 606, 607
Subtype entry 606
Watermark annotation type 581, 606
watermark annotations 581, 606-609
See also
watermark annotation dictionaries
Web Capture command dictionaries 874, 884, 886-888
CT entry 886, 887
F entry 886
H entry 886, 888
L entry 886
P entry 886, 887
S entry 886, 888
URL entry 886
Web Capture command flags 886-887
SamePath 887
SameSite 887
Submit 887
Web Capture command settings dictionaries 886, 888-889
C entry 888
G entry 888
Web Capture content database 874
Web Capture content sets 875-877, 881-883
creation date 882, 885
CT entry 882
digital identifier 122, 312, 889
expiration date 884, 885
ID entry 882
modification date 884, 885
in name dictionary 125
O entry 881, 882, 883, 889, 1031
S entry 882
SI entry 882, 883, 884
Index
1209
source information 884, 885
subtype 882, 883
TS entry 882
Type entry 882
URLs for 878
See also
Web Capture image sets
Web Capture page sets
Web Capture image sets 875, 876, 877, 883, 1031
digital identifier 879
R entry 883
reference counts 883, 1031
S entry 883
Web Capture information dictionary 116, 874
C entry 874
V entry 874
Web Capture page sets 875, 876, 877, 881-882
digital identifier 879
form submission type 884
S entry 882
T entry 882
text identifier 879, 881, 882
TID entry 881, 882
title 882
Web Capture plug-in extension (AcroSpider) 116, 770,
873-890
commands
See
Web Capture command dictionaries
Web Capture command settings dictionaries
content database 875-877
content sets. See Web Capture content sets
digital identifiers 874, 875, 878-879, 882, 884, 1031
implementation limits 874
information dictionary. See Web Capture information
dictionary
and link annotations 588
object attributes related to 889-890
source information. See source information dictionar-
ies
unique name generation 879-881
URLs (uniform resource locators) 125, 873, 874, 875,
876, 878, 884, 886, 887, 888, 1031
See also URL alias dictionaries
version number 874
Web Content Accessibility Guidelines (World Wide Web
Consortium) 864, 1064
WebLink plug-in extension 1022
Western writing systems
character encodings 924
glyph displacements 365, 819
page content order 817
progression directions 824, 825, 834, 848
shift direction 855
writing mode 848
white point
diffuse 216, 217, 218, 221
of output medium 231
white-preserving blend modes 536
in isolated groups 536
for spot colors 535
white-space characters 24, 25-26, 1034
ASCII85Decode filter, ignored by 45
ASCIIHexDecode filter, ignored by 45
in hexadecimal strings 32
in inline images 322
in name objects 32, 33
WhitePoint entry
CalGray color space dictionary 216, 217
CalRGB color space dictionary 218, 219
Lab color space dictionary 221
widget annotation dictionaries 603
and dynamic appearance streams 641
FDF field dictionaries, compared with 676
field dictionaries, merged with 603, 634, 658
H entry 603
MK entry 603, 604, 1023
Subtype entry 603
Widget annotation type 581, 582, 603, 674
widget annotations 581, 603, 634
additional-actions dictionary 572
appearance dictionaries for 635, 648
appearance streams for 635, 640, 648
border style 1020
for FDF fields 677, 678
and
Form standard structure type 836, 841
and hide actions 628
highlighting mode 603
icon 678-679
for radio button fields 651, 653
and ReadOnly field flag 574, 638
rotation 604
scaling 679
and submit-form actions 664, 666
trigger events for 611, 612
See also
fields, interactive form
widget annotation dictionaries
Width entry
image dictionary 65, 310, 321, 523, 557
inline image object 323
type 6 halftone dictionary 469, 469, 472
type 16 halftone dictionary 473, 474, 474
Width standard structure attribute 841, 845, 846, 853, 859,
860
Width2 entry (type 16 halftone dictionary) 473, 474, 474
Index
1210
Widths entry
font dictionary 428
Type 1 font dictionary 384, 384, 386, 1016
Type 3 font dictionary 391, 392, 393
Win entry (launch action dictionary) 622, 1022
WinAnsiEncoding predefined character encoding 396, 923,
924
as base encoding 397
euro character 928
for TrueType fonts 400, 401
for Type 1 fonts 384
and Unicode mapping 441
windows
See
document windows
floating windows
pop-up windows
Windows launch parameter dictionaries 622-623, 1022
D entry 622
F entry 622
O entry 622
P entry 623
Windows
®
operating system
Adobe PDF printer 19
application launch parameters 621, 622
character encoding 395, 396, 924
Code Page 932 414
Code Page 936 412, 413
Code Page 949 415
Code Page 950 413
Code Page 1252 924
directories 622, 1025
file names 154, 622, 670
file system 155
font names 388
Graphics Device Interface (GDI) 19
LOGFONT structure 388
PATH environment variable 1025
ShellExecute function 1022
TrueType
®
font format 387, 399
WNetGetConnection function 153
Wipe transition style 563, 564
WMode entry (CMap dictionary) 410, 419
WNetGetConnection function (Windows) 153
word spacing (T
w
) parameter 364, 367, 369-370
and horizontal scaling 370
and quotation mark (
") operator 377
text matrix, updating of 380
Tw operator 368, 916
workflow 10, 228, 890, 898, 900, 907, 1032
World Wide Web
accessibility guidelines for 864
document distribution on 773, 898
form submission 662
Linearized PDF and 940
PDF specification available on xxi
See also
Web Capture plug-in extension
World Wide Web Consortium 51, 1063
Cascading Style Sheets, level 2 (CSS2) Specification
1063
Extensible Markup Language (XML) 1.1 666, 865, 1063
Extensible Stylesheet Language (XSL) 1.0 821, 1063
HTML 4.01 Specification 625, 1063
Scalable Vector Graphics (SVG) 1.0 Specification 1029,
1063
Synchronized Multimedia Integration Language (SMIL
2.0) 1064
Web Content Accessibility Guidelines 864, 1064
XHTML 1.0—The Extensible Hypertext Markup
Language 1064
WP entry (additional-actions dictionary) 613
WP standard structure type 836, 840
WP trigger event (document) 613
writing mode (fonts) 365-366, 409, 410
and character spacing 368
CMaps, specified by 412, 419
horizontal scaling independent of 370
leading independent of 371
simple fonts, horizontal only in 382
text matrix, adjustment of 380
text rise independent of 373
and
TJ operator 378
and word spacing 369
writing mode (Tagged PDF) 848
LrTb 848
RlTb 848
TbRl 848
writing systems
Arabic 818, 848
Asian 365, 404
Chinese 848
Hebrew 818, 848
Japanese 848
Latin 395, 430
non-Latin 396, 650
progression directions 824-825
right-to-left 818, 819
Western. See Western writing systems
WritingMode standard structure attribute 824, 845, 848,
855, 863
WS entry (additional-actions dictionary) 613
WS trigger event (document) 613
WT standard structure type 836, 840
Index
1211
X
X entry
additional-actions dictionary 611, 614
rectilinear measure dictionary 706
X trigger event (annotation) 611, 613, 614, 627
X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol—OCSP (Internet RFC 2396) 698,
1062
X.509 public-key certificate 104
XFA (XML Forms Architecture) 681-684
compatibility with PDF form fields 683
configuration information 682
form data 681
form template 681
packets 635, 681
XFA resource 635, 681
XFA Text Specification 642
XFA entry (interactive form dictionary) 635, 681, 682, 683,
1023
XFA Scripting Object Model (SOM) 683
XFA Specification (Adobe Technical Note) 681, 683, 1058
xfa:APIVersion attribute (<body> XHTML element) 643
xfa:contentType attribute (<body> XHTML element) 643
xfa:spec attribute (<body> XHTML element) 643
XFDF 666, 694
XFDF field flag (submit-form field) 664, 664, 665, 666
XHeight entry (font descriptor) 427
XHTML 642
elements, rich text strings 642
XHTML 1.0—The Extensible Hypertext Markup Language
(World Wide Web Consortium) 1064
XHTML elements (rich text strings)
<b> 643
<body> 642
<i> 643
<p> 643, 645
<span> 643
XML (Extensible Markup Language)
file-select controls, not supported for 654
language identifiers 865
for metadata streams 773-774
PDF logical structure compared with 784
standard attribute owner 843, 844
strongly structured document organization 833
Tagged PDF, conversion from 812, 821, 827
XML Data Package 635
XML Data Package Specification (Adobe Technical Note)
635, 681, 1058
XML Forms Architecture (XFA). See XFA
XML Forms Data Format Specification, Version 2.0 (Adobe
Technical Note) 666, 1058
XML metadata subtype 774
XML-1.00 standard attribute owner 843
xmlns attribute (<body> XHTML element) 643
XMP (Extensible Metadata Platform) framework 774
XMP: Extensible Metadata Platform (Adobe Systems
Incorporated) 774, 1058
XN entry (3D view dictionary) 757
XObject entry (resource dictionary) 129, 302, 309, 312,
326, 330
XObject object type 302, 303, 310, 328, 523
XObject operator 166, 302
Do 166, 261, 265, 269, 273, 302, 303, 305, 309, 313,
326, 327, 330, 344, 526, 527, 542, 543, 544, 782, 793,
794, 797, 914
XObject resource type 129, 302, 309, 312, 326, 330
XObject subtypes
Form 302, 328
Image 302, 310, 523, 557
PS 302, 303
XObjects
See external objects
xor operator (PostScript) 149, 918
xref keyword 69, 73, 82, 948
XRef object type 83
XRefStm entry (hybrid-reference file trailer dictionary) 74,
86, 86, 87, 88
XSL (Extensible Stylesheet Language) file format 821, 824
Xsquare entry (type 10 halftone dictionary) 472
XStep entry (type 1 pattern dictionary) 263
XX name prefix 938
XYZ color representation 224
Y
Y entry (rectilinear measure dictionary) 706
y operator 166, 196, 199, 916
yellow color component
blue, complement of 452
DeviceCMYK color space 211, 213
DeviceN color spaces 238
grayscale conversion 451, 456
halftones for 476
initialization 213
overprinting 539, 540
RGB conversion 451, 452
transfer function 454, 455
transparent overprinting 540
undercolor removal 183, 452, 453
Index
1212
yellow colorant
overprinting 539, 540
PANTONE Hexachrome system 238
printing ink 234
process colorant 211, 213
subtractive primary 211, 213
transparent overprinting 540
Yes appearance state (check box fields) 648
Ysquare entry (type 10 halftone dictionary) 472
YStep entry (type 1 pattern dictionary) 263
yuan symbol (
¥) character 413
YUV color representation 61
YUVK color representation 61
Z
Z entry (media criteria dictionary) 717
Zapf Dingbats typeface
See ITC Zapf Dingbats
®
typeface
ZapfDingbats standard font 385, 396, 1015, 1017
character encoding, built-in 923, 935
character set 923, 935-936
ZLIB Compressed Data Format Specification (Internet RFC
1950) 47, 1062
zlib/deflate compression
See Flate compression
zone theory of color vision 214
Zoom entry (optional content usage dictionary) 351, 353,
355
zoom factor
See magnification factor
1213
Colophon
This document was produced using Adobe
®
FrameMaker
®
, Adobe Illustrator
®
,
Adobe Photoshop
®
, Adobe Acrobat
®
Distiller
®
, and other application software
packages that support the PostScript
®
language and Type 1 fonts. The type used is
from the Adobe Minion
®
Pro and Myriad
®
Pro families. Heads are set in Myriad
Pro Semibold and the body text is set in 10.5-on-13-point Minion Pro.
Authors—Jim Meehan, Ed Taft, Stephen Chernicoff, Caroline Rose, Ron Karr
Key Contributors—Nabeel Al-Shamma, Steven Kelley Amerige, Bob Ayers, Tim
Bienz, Krish Chaudhury, Richard Cohn, Michelle Dalton, Stephen Deach, Jon
Ferraiolo, Matt Foley, Martin Fox, Ron Gentile, John Green, Jim King, Bennett
Leeds, Pierre Louveaux, Rob McAfee, Teryk Morris, Carl Orthlieb, Mike Ossesia,
Ajay Pande, Roberto Perelman, Scott Petersen, Jason Pittenger, Richard Potter,
Jim Pravetz, Dan Rabin, Loretta Guarino Reid, Paul Rovner, Ed Rowe, Craig
Rublee, Mike Schuster, Steve Schiller, Kelsey Schwind, Rudi Sherry, Abhishek
Shrivastava, John Warnock, Bob Wulff, Steve Zilles
Reviewers—Sunil Agrawal, Parviz Banki, Xintai Chang, L. Peter Deutsch, Mark
Donohoe, David Gelphman, Brian Havlin, Jim Lester, Raph Levien, Ken Lunde,
Eric Muller, John Nash, Terry O'Donnell, Dick Sites, Lydia Stang, Koichi
Yoshimura, and numerous others at Adobe Systems and elsewhere
Editing and Book Production—Stephen Chernicoff, Caroline Rose, Ron Karr,
Geneva Holloway
Index—Stephen Chernicoff, Ron Karr, Lucie Haskins
Illustrations—Kim Arney, Wendy Bell, Peter Constable, Lisa Ferdinandsen, Ron
Karr, Carol Keller, Pierre Louveaux, Jim Meehan, Mike Ossesia, Scott Petersen,
Dayna Porterfield, Jim Pravetz, Carl Yoshihara
Publication Management—Courtney Attwood, Ghislaine Maisonneuve
