Skip to content

PDF20 Spec 08 Coordinate

Marc Jones edited this page Dec 30, 2025 · 1 revision

8.2 Coordinate Systems

Part of: PDF20-Spec-08-Graphics

Navigation: PDF20-Spec-08-General | PDF20-Spec-Index | PDF20-Spec-08-Graphics-State


8.2

Graphics objects

As discussed in 7.8.2, "Content streams", the data in a content stream shall be 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 shall be written sequentially using postfix notation. Although this notation resembles the sequential execution model of the PostScript 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 © ISO 2020 – All rights reserved

145

ISO 32000-2:2020(E)

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 shall be 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 clipping boundary.

•

An external object (XObject) is an object defined outside the content stream and referenced as a named resource (see 7.8.3, "Resource dictionaries"). The interpretation of an XObject depends on its type. An image XObject defines a rectangular array of colour samples to be painted; a form XObject is an entire content stream to be treated as a single graphics object. Specialised types of form XObjects shall be 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 clause 11, "Transparency").

•

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 colour is an arbitrary function of position within the shape. (A shading can also be treated as a colour 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 introduced a transparent imaging model in which objects 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 colours of the object and backdrop according to their respective opacity characteristics. The objects at any given point on the page form a transparency stack, where the stacking order is defined to be the order in which the objects shall be specified, bottommost object first. All objects in the stack can potentially contribute to the result, depending on their colours, shapes, and opacities. PDF’s graphics parameters are so arranged that objects shall be painted by default with full opacity, reducing the behaviour of the transparent imaging model to that of the opaque model. Accordingly, the material in this clause applies to both the opaque and transparent models except where explicitly stated otherwise; the transparent model is described in its full generality in clause 11, "Transparency". Although the painting behaviour described above is often attributed to individual operators making up an object, it is always the object as a whole that is painted. "Figure 9 — Graphics objects" shows the ordering rules for the operations that define graphics objects. Only those operators that are listed in "Figure 9 — Graphics objects" for each type of graphics object or in the intervals between graphics objects (called the content stream level in the figure) shall be used in that context. Every content stream begins at the content stream level, where changes may be made to the graphics state, such as colours and text attributes, as discussed in the following subclauses. In "Figure 9 — Graphics objects", arrows indicate the operators that mark the beginning or end of each 146 © ISO 2020 – All rights reserved

ISO 32000-2:2020(E)

type of graphics object. Some operators are identified individually, others by general category. "Table 50 — Operator categories" summarises these categories for all PDF operators. Table 50 — Operator categories Category

Operators

Location

General graphics state

w, J, j, M, d, ri, i, gs, q, Q

"Table 56 — Graphics state operators"

Special graphics state

cm

"Table 56 — Graphics state operators"

Path construction

m, l, c, v, y, h, re

"Table 58 — Path construction operators"

Path painting

S, s, f, F, f*, B, B*, b, b*, n

"Table 59 — Path-painting operators"

Clipping paths

W, W*

"Table 60 — Clipping path operators"

Text objects

BT, ET

"Table 105 — Text object operators"

Text state

Tc, Tw, Tz, TL, Tf, Tr, Ts

"Table 103 — Text state operators"

Text positioning

Td, TD, Tm, T*

"Table 106 — Text-positioning operators"

Text showing

Tj, TJ, ', "

"Table 107 — Text-showing operators"

Type 3 fonts

d0, d1

"Table 111 — Type 3 font operators"

Colour

CS, cs, SC, SCN, sc, scn, G, g, RG, rg, K, k

"Table 73 — Colour operators"

Shading patterns

Sh

"Table 76 — Shading operator"

Inline images

BI, ID, EI

"Table 90 — Inline image operators"

XObjects

Do

"Table 86 — XObject operator"

Marked-content

MP, DP, BMC, BDC, EMC

"Table 351 — Entries in a data dictionary"

Compatibility

BX, EX

"Table 33 — Compatibility operators"

© ISO 2020 – All rights reserved

147

ISO 32000-2:2020(E)

Figure 9 — Graphics objects 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 content stream level.

NOTE 1

"Table 50 — Operator categories" and "Figure 9 — Graphics objects" were updated in this document (2020).

NOTE 2

A PDF reader can process a content stream whose operations violate these rules for describing graphics objects and can produce unpredictable behaviour, even though it can display and print the stream correctly. PDF processors that attempt to extract graphics objects for editing or other purposes often depend on the objects being well formed. The rules for graphics objects are also important for the proper interpretation of marked-content (see 14.6, "Marked content").

A graphics object also implicitly includes all graphics state parameters that affect its behaviour. For instance, a path object depends on the value of the current colour parameter at the moment the path 148

© ISO 2020 – All rights reserved

ISO 32000-2:2020(E)

object is defined. The effect shall be as if this parameter were specified as part of the definition of the path object. However, the operators that are invoked at the content stream level to set graphics state parameters shall not be considered to belong to any particular graphics object. Graphics state parameters should be specified only when they change. A graphics object can 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 arrangement of graphics state operators. When processing a PDF content stream a PDF processor may change an arrangement of graphics state operators to any other arrangement that achieves the same values of the relevant graphics state parameters for each graphics object. PDF processors shall not infer any higher-level logical semantics from the arrangement of tokens constituting a graphics object. A separate mechanism, marked-content (see 14.6, "Marked content"), allows such higher-level information to be explicitly associated with the graphics objects.


Navigation: PDF20-Spec-08-General | PDF20-Spec-Index | PDF20-Spec-08-Graphics-State

Clone this wiki locally