Content      ..      1       2         ..

ISO 32000-1 Document management — Portable document format — Part 1: PDF 1.7 - page 1

7

Syntax

7.1

General

This clause covers everything about the syntax of PDF at the object, file, and document level. It sets the stage

for subsequent clauses, which describe how the contents of a PDF file are interpreted as page descriptions,

interactive navigational aids, and application-level logical structure.

PDF syntax is best understood by considering it as four parts, as shown in Figure 1:

•

Objects. A PDF document is a data structure composed from a small set of basic types of data objects.

Sub-clause 7.2, "Lexical Conventions," describes the character set used to write objects and other

syntactic elements. Sub-clause 7.3, "Objects," describes the syntax and essential properties of the objects.

Sub-clause 7.3.8, "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. Sub-

clause 7.5, "File Structure," describes the file structure. Sub-clause 7.6, "Encryption," describes a file-level

mechanism for protecting a document’s contents from unauthorized access.

•

Document structure. The PDF document structure specifies how the basic object types are used to

represent components of a PDF document: pages, fonts, annotations, and so forth. Sub-clause 7.7,

"Document Structure," describes the overall document structure; later clauses address the detailed

semantics of the components.

•

Content streams. A PDF content stream contains a sequence of instructions describing the appearance of

a page or other graphical entity. These instructions, while also represented as objects, are conceptually

distinct from the objects that represent the document structure and are described separately. Sub-clause

7.8, "Content Streams and Resources," discusses PDF content streams and their associated resources.

Objects

File

Content

structure

stream

Document

structure

Figure 1 - PDF Components

In addition, this clause 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: 7.9,

"Common Data Structures"; 7.10, "Functions"; and 7.11, "File Specifications."

NOTE

Variants of PDF’s object and file syntax are also used as the basis for other file formats. These include the

Forms Data Format (FDF), described in 12.7.7, "Forms Data Format", and the Portable Job Ticket Format

(PJTF), described in Adobe Technical Note #5620, Portable Job Ticket Format.

7.2

Lexical Conventions

7.2.1

General

At the most fundamental level, a PDF file is a sequence of bytes. These bytes can be grouped into tokens

according to the syntax rules described in this sub-clause. One or more tokens are assembled to form higher-

11

level syntactic entities, principally objects, which are the basic data values from which a PDF document is

constructed.

A non-encrypted PDF can be entirely represented using byte values corresponding to the visible printable

subset of the character set defined in ANSI X3.4-1986, plus white space characters. However, a PDF file is not

restricted to the ASCII character set; it may contain arbitrary bytes, subject to the following considerations:

•

The tokens that delimit objects and that describe the structure of a PDF file shall use the ASCII character

set. In addition all the reserved words and the names used as keys in PDF standard dictionaries and

certain types of arrays shall be defined using the ASCII character set.

•

The data values of strings and streams objects may be written either entirely using the ASCII character set

or entirely in binary data. In actual practice, data that is naturally binary, such as sampled images, is

usually represented in binary for compactness and efficiency.

•

A PDF file containing binary data shall be transported as a binary file rather than as a text file to insure that

all bytes of the file are faithfully preserved.

NOTE 1

A binary file is not portable to environments that impose reserved character codes, maximum line lengths, end-

of-line conventions, or other restrictions

NOTE 2

In this clause, the usage of the term character is entirely independent of any logical meaning that the value

may have when it is treated as data in specific contexts, such as representing human-readable text or

selecting a glyph from a font.

7.2.2

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. The rules defined in this sub-clause apply to

all characters in the file except within strings, streams, and comments.

The White-space characters shown in Table 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.

Table 1 - White-space characters

Decimal

Hexadecimal

Octal

Name

0

00

000

Null (NUL)

9

09

011

HORIZONTAL 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)

The CARRIAGE RETURN (0Dh) and LINE FEED (0Ah) characters, also called newline characters, shall be

treated as end-of-line (EOL) markers. The combination of a CARRIAGE RETURN followed immediately by a

LINE FEED shall be treated as one EOL marker. EOL markers may be treated the same as any other white-

space characters. However, sometimes an EOL marker is required or recommended—that is, preceding a

token that must appear at the beginning of a line.

NOTE

The examples in this standard use a convention that arranges tokens into lines. However, the examples’ use of

white space for indentation is purely for clarity of exposition and need not be included in practical use.

12

The delimiter characters (, ), <, >, [, ],

{,

},

/, and

% are special (LEFT PARENTHESIS (28h), RIGHT

PARENTHESIS (29h), LESS-THAN SIGN (3Ch), GREATER-THAN SIGN (3Eh), LEFT SQUARE BRACKET

(5Bh), RIGHT SQUARE BRACKET (5Dh), LEFT CURLY BRACE (7Bh), RIGHT CURLY BRACE (07Dh),

SOLIDUS (2Fh) and PERCENT SIGN (25h), respectively). They delimit syntactic entities such as arrays,

names, and comments. Any of these characters terminates the entity preceding it and is not included in the

entity. Delimiter characters are allowed within the scope of a string when following the rules for composing

strings; see 7.3.4.2, “Literal Strings”. The leading ( of a string does delimit a preceding entity and the closing ) of

a string delimits the string’s end.

Table 2 - Delimiter characters

Glyph

Decimal

Hexadecimal

Octal

Name

(

40

28

50

LEFT PARENTHESIS

)

41

29

51

RIGHT PARENTHESIS

<

60

3C

60

LESS-THAN SIGN

>

62

3E

62

GREATER-THAN SIGN

[

91

5B

133

LEFT SQUARE BRACKET

]

93

5D

135

RIGHT SQUARE BRACKET

{

123

7B

173

LEFT CURLY BRACKET

}

125

7D

175

RIGHT CURLY BRACKET

/

47

2F

57

SOLIDUS

%

37

25

45

PERCENT SIGN

All characters except the white-space characters and delimiters are referred to as regular characters. These

characters include bytes that are outside the ASCII character set. A sequence of consecutive regular

characters comprises a single token. PDF is case-sensitive; corresponding uppercase and lowercase letters

shall be considered distinct.

7.2.3

Comments

Any occurrence of the PERCENT SIGN (25h) outside a string or stream introduces a comment. The comment

consists of all characters after the PERCENT SIGN and up to but not including the end of the line, including

regular, delimiter, SPACE (20h), and HORZONTAL TAB characters (09h). A conforming reader shall ignore

comments, and treat them as single white-space characters. That is, a comment separates the token preceding

it from the one following it.

EXAMPLE

The PDF fragment in this example is syntactically equivalent to just the tokens abc and 123.

abc% comment ( /% ) blah blah blah

123

Comments (other than the %PDF-n.m and %%EOF comments described in 7.5, "File Structure") have no

semantics. They are not necessarily preserved by applications that edit PDF files.

7.3

Objects

7.3.1

General

PDF includes eight basic types of objects: Boolean values, Integer and Real numbers, Strings, Names, Arrays,

Dictionaries, Streams, and the null object.

13

7.9.2, "String Object Types," describes the encoding schemes used for the contents of string objects.

7.3.4.2

Literal Strings

A literal string shall be written as an arbitrary number of characters enclosed in parentheses. Any characters

may appear in a string except unbalanced parentheses

(LEFT PARENHESIS

(28h) and RIGHT

PARENTHESIS (29h)) and the backslash (REVERSE SOLIDUS (5Ch)), which shall be treated specially as

described in this sub-clause. Balanced pairs of parentheses within a string require no special treatment.

EXAMPLE 1

The following are valid literal strings:

( This is a string )

( Strings may contain newlines

and such . )

( 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 REVERSE SOLIDUS is used as an escape character. The character immediately

following the REVERSE SOLIDUS determines its precise interpretation as shown in Table 3. If the character

following the REVERSE SOLIDUS is not one of those shown in Table 3, the REVERSE SOLIDUS shall be

ignored.

Table 3 - Escape sequences in literal strings

Sequence

Meaning

\n

LINE FEED (0Ah) (LF)

\r

CARRIAGE RETURN (0Dh) (CR)

\t

HORIZONTAL TAB (09h) (HT)

\b

BACKSPACE (08h) (BS)

\f

FORM FEED (FF)

\(

LEFT PARENTHESIS (28h)

\)

RIGHT PARENTHESIS (29h)

\\

REVERSE SOLIDUS (5Ch) (Backslash)

\ddd

Character code ddd (octal)

A conforming writer may split a literal string across multiple lines. The REVERSE SOLIDUS (5Ch) (backslash

character) at the end of a line shall be used to indicate that the string continues on the following line. A

conforming reader shall disregard the REVERSE SOLIDUS and the end-of-line marker following it when

reading the string; the resulting string value shall be identical to that which would be read if the string were not

split.

EXAMPLE 2

( These \

two strings \

are the same . )

( These two strings are the same . )

An end-of-line marker appearing within a literal string without a preceding REVERSE SOLIDUS shall be treated

as a byte value of (0Ah), irrespective of whether the end-of-line marker was a CARRIAGE RETURN (0Dh), a

LINE FEED (0Ah), or both.

15

When writing a name in a PDF file, a SOLIDUS (2Fh) (/) shall be used to introduce a name. The SOLIDUS is

not part of the name but is a prefix indicating that what follows is a sequence of characters representing the

name in the PDF file and shall follow these rules:

a) A NUMBER SIGN (23h) (#) in a name shall be written by using its 2-digit hexadecimal code (23), preceded

by the NUMBER SIGN.

b) Any character in a name that is a regular character (other than NUMBER SIGN) shall be written as itself or

by using its 2-digit hexadecimal code, preceded by the NUMBER SIGN.

c) Any character that is not a regular character shall be written using its 2-digit hexadecimal code, preceded

by the NUMBER SIGN only.

NOTE 1

There is not a unique encoding of names into the PDF file because regular characters may be

coded in either of two ways.

White space used as part of a name shall always be coded using the 2-digit hexadecimal notation and no white

space may intervene between the SOLIDUS and the encoded name.

Regular characters that are outside the range EXCLAMATION MARK(21h) (!) to TILDE (7Eh) (~) should be

written using the hexadecimal notation.

The token SOLIDUS (a slash followed by no regular characters) introduces a unique valid name defined by the

empty sequence of characters.

NOTE 2

The examples shown in Table 4 and containing # are not valid literal names in PDF 1.0 or 1.1.

Table 4 - Examples of literal names

Syntax for Literal name

Resulting Name

/Name1

Name1

/ASomewhatLongerName

ASomewhatLongerName

/A;Name_With-Various***Characters?

A;Name_With-Various***Characters?

/1 . 2

1 . 2

/$$

$$

/@pattern

@pattern

/.notdef

.notdef

/lime#20Green

Lime Green

/paired#28#29parentheses

paired( )parentheses

/The_Key_of_F#23_Minor

The_Key_of_F#_Minor

/A#42

AB

In PDF, literal names shall always be introduced by the SOLIDUS character (/), unlike keywords such as true,

false, and obj.

NOTE 3

This standard follows a typographic convention of writing names without the leading SOLIDUS 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 standard) as /Type and /FullScreen.

The length of a name shall be subject to an implementation limit; see Annex C. The limit applies to the number

of characters in the name’s internal representation. For example, the name /A#20B has three characters (A,

SPACE, B), not six.

17

7.3.8.2

Stream Extent

Every stream dictionary shall have 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 shall be the number of bytes of encoded data.) In addition,

most filters are defined so that the data shall be 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 shall be consistent.

EXAMPLE

An image with 10 rows and 20 columns, using a single colour component and 8 bits per component,

requires exactly 200 bytes of image data. If the stream uses a filter, there shall 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.

Table 5 - Entries common to all stream dictionaries

Key

Type

Value

Length

integer

(Required) The number of bytes from the beginning of the line

following 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 7.3.8.2,

"Stream Extent", for further discussion.

Filter

name or array

(Optional) The name of a filter that shall be applied in

processing the stream data found between the keywords

stream and endstream, or an array of zero, one or several

names. Multiple filters shall 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

shall be set to the filter’s parameter 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 nondefault

values, DecodeParms shall 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.

F

file specification

(Optional; PDF 1.2) The file containing the stream data. If this

entry is present, the bytes between stream and endstream

shall be ignored. However, the Length entry should still specify

the number of those bytes (usually, there are no bytes and

Length is 0). The filters that are applied to the file data shall be

specified by FFilter and the filter parameters shall be specified

by FDecodeParms.

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 zero, one or several 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

dictionaries, used by the filters specified by FFilter. The same

rules apply as for DecodeParms.

20

Table 5 - Entries common to all stream dictionaries (continued)

Key

Type

Value

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 determine, for example, whether enough disk space is

available to write a stream to a file.

This value shall be considered a hint only; for some stream

filters, it may not be possible to determine this value precisely.

7.3.9

Null Object

The null object has a type and value that are unequal to those of any other object. There shall be only one

object of type null, denoted by the keyword null. An indirect object reference (see 7.3.10, "Indirect Objects") to

a nonexistent object shall be treated the same as a null object. Specifying the null object as the value of a

dictionary entry (7.3.7, "Dictionary Objects") shall be equivalent to omitting the entry entirely.

7.3.10

Indirect Objects

Any object in a PDF file may be labelled 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 shall consist of two parts:

•

A positive integer object number. Indirect objects may be numbered sequentially 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 shall have generation

numbers of 0. Nonzero generation numbers may be introduced when the file is later updated; see sub-

clauses 7.5.4, "Cross-Reference Table" and 7.5.6, "Incremental Updates."

Together, the combination of an object number and a generation number shall uniquely identify an indirect

object.

The definition of an indirect object in a PDF file shall consist of its object number and generation number

(separated by white space), followed by the value of the object bracketed between the keywords obj and

endobj.

EXAMPLE 1

Indirect object definition

12 0 obj

( Brillig )

endobj

Defines an indirect string object with an object number of 12, a generation number of 0, and the value

Brillig.

The object may be referred to from elsewhere in the file by an indirect reference. Such indirect references shall

consist of the object number, the generation number, and the keyword R (with white space separating each

part):

12 0 R

Beginning with PDF 1.5, indirect objects may reside in object streams (see 7.5.7, "Object Streams"). They are

referred to in the same way; however, their definition shall not include the keywords obj and endobj, and their

generation number shall be zero.

21

•

Decompression filters enable decoding of data that has been compressed. The compressed data shall be

in binary format, even if the original data is ASCII text.

NOTE 1

ASCII filters serve no useful purpose in a PDF file that is encrypted; see 7.6, “Encryption”.

NOTE 2

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,

resulting in a loss of quality when the data is decompressed. Compression in which no loss of data occurs is

called lossless. Though somehow obvious it might be worth pointing out that lossy compression can only be

applied to sampled image data (and only certain types of lossy compression for certain types of images).

Lossless compression on the other hand can be used for any kind of stream.

The standard filters are summarized in Table 6, which also indicates whether they accept any optional

parameters. The following sub-clauses describe these filters and their parameters (if any) in greater detail,

including specifications of encoding algorithms for some filters.

Table 6 - 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,

reproducing the original binary data.

LZWDecode

yes

Decompresses data encoded using the LZW (Lempel-Ziv-

Welch) adaptive compression method, reproducing the original

text or binary data.

FlateDecode

yes

(PDF 1.2) Decompresses data encoded using the zlib/deflate

compression method, reproducing the original text or binary

data.

RunLengthDecode

no

Decompresses data encoded using a byte-oriented run-length

encoding 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,

reproducing the data as it was before encryption.

EXAMPLE 3

The following example 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.

1 0 obj

<< /Length 534

/Filter

[ /ASCII85Decode /LZWDecode ]

>>

23

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 patterns 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.

NOTE 1

Because of its cascaded adaptive Huffman coding, Flate-encoded output is usually much more compact than

LZW-encoded output for the same input. Flate and LZW decoding speeds are comparable, but Flate encoding

is considerably slower than LZW encoding.

NOTE 2

Usually, both Flate and LZW encodings compress their input substantially. However, in the worst case (in

which no pair of adjacent bytes 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.

7.4.4.2

Details of LZW Encoding

Data encoded using the LZW compression method shall consist of a sequence of codes that are 9 to 12 bits

long. Each code shall represent 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 shall be 9 bits and the LZW table shall contain only entries for the 258 fixed codes. As

encoding proceeds, entries shall be appended to the table, associating new codes with longer and longer

sequences of input characters. The encoder and the decoder shall 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 number of entries in the table, they shall increase the number of

bits per code by 1. The first output code that is 10 bits long shall be the one following the creation of table entry

511, and similarly for 11 (1023) and 12 (2047) bits. Codes shall never be longer than 12 bits; therefore, entry

4095 is the last entry of the LZW table.

The encoder shall execute the following sequence of steps to generate each output code:

a) 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.

b) Emit the code corresponding to that sequence.

c) Create a new table entry for the first unused code. Its value is the sequence found in step (a) followed by

the next input character.

EXAMPLE 1

Suppose the input consists of the following sequence of ASCII character codes:

45 45 45 45 45 65 45 45 45 66

Starting with an empty table, the encoder proceeds as shown in Table 7.

Table 7 - Typical LZW encoding sequence

Input

Output

Code added

Sequence

sequence

code

to table

represented

by new code

-

256 (clear-table)

-

-

45

45

258

45 45

45 45

258

259

45 45 45

26

Table 7 - Typical LZW encoding sequence (continued)

Input

Output

Code added

Sequence

sequence

code

to table

represented

by new code

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)

-

-

Codes shall be packed into a continuous bit stream, high-order bit first. This stream shall then be divided into

bytes, high-order bit first. Thus, codes may straddle byte boundaries arbitrarily. After the EOD marker (code

value 257), any leftover bits in the final byte shall be 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):

EXAMPLE 2

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. The encoder shall begin

by issuing a clear-table code. It shall issue a clear-table code when the table becomes full; it may do so sooner.

7.4.4.3

LZWDecode and FlateDecode Parameters

The LZWDecode and FlateDecode filters shall accept optional parameters to control the decoding process.

NOTE

Most of these parameters are related to techniques that reduce the size of compressed sampled images

(rectangular arrays of colour values, described in 8.9, "Images"). For example, image data typically changes

very little from sample to sample. Therefore, subtracting the values of adjacent 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 colour components (red-green-blue or cyan-

magenta-yellow-black) per sample, taking the difference between the values of corresponding components in

adjacent samples, rather than between different colour components in the same sample, often reduces the

output data size.

Table 8 shows the parameters that may optionally be specified for LZWDecode and FlateDecode filters.

Except where otherwise noted, all values supplied to the decoding filter for any optional parameters shall match

those used when the data was encoded.

Table 8 - 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 shall assume that the normal algorithm was used to

encode the data, without prediction. If the value is greater than 1, the

filter shall assume that the data was differenced before being encoded,

and Predictor selects the predictor algorithm. For more information

regarding Predictor values greater than 1, see 7.4.4.4, "LZW and

Flate Predictor Functions." Default value: 1.

Colors

integer

(May be used only if Predictor is greater than 1) The number of

interleaved colour components per sample. Valid values are 1 to 4

(PDF 1.0) and 1 or greater (PDF 1.3). Default value: 1.

27

Table 8 - Optional parameters for LZWDecode and FlateDecode filters (continued)

Key

Type

Value

BitsPerComponent

integer

(May be used only if Predictor is greater than 1) The number of bits

used to represent each colour component in a sample. Valid values

are 1, 2, 4, 8, and (PDF 1.5) 16. Default value: 8.

Columns

integer

(May be 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 shall be postponed

as long as possible. If the value is 1, code length increases shall occur

one code early. This parameter is included because LZW sample code

distributed by some vendors increases the code length one code

earlier than necessary. Default value: 1.

7.4.4.4

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.

PDF supports two groups of predictor functions. The first, the TIFF group, consists of the single function that is

Predictor 2 in the TIFF 6.0 specification.

NOTE 1

(In the TIFF 6.0 specification, Predictor 2 applies only to LZW compression, but here it applies to Flate

compression as well.) TIFF Predictor 2 predicts that each colour component of a sample is the same as the

corresponding colour component of the sample immediately 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 recommendation, documented in Internet RFC 2083, PNG

(Portable Network Graphics) Specification (see the Bibliography).

The term predictors is used here instead 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).

Table 9 - PNG predictor algorithms

PNG

Description

Predictor

Algorithms

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, shall be indicated by the Predictor filter parameter (see Table 8),

whose value shall be one of those listed in Table 10.

28

For LZWDecode and FlateDecode, a Predictor value greater than or equal to 10 shall indicate that a PNG

predictor is in use; the specific predictor function used shall be 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.

Table 10 - Predictor values

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)

The two groups of predictor functions have some commonalities. Both make the following assumptions:

•

Data shall be presented in order, from the top row to the bottom row and, within a row, from left to right.

•

A row shall occupy a whole number of bytes, rounded up if necessary.

•

Samples and their components shall be packed into bytes from high-order to low-order bits.

•

All colour components of samples outside the image (which are necessary for predictions near the

boundaries) shall be 0.

The predictor function groups also differ in significant ways:

•

The postprediction data for each PNG-predicted row shall begin with an explicit algorithm tag; therefore,

different rows can be predicted with different algorithms to improve compression. TIFF Predictor 2 has no

such identifier; the same algorithm applies to all rows.

•

The TIFF function group shall predict each colour component from the prior instance of that component,

taking into account the number of bits per component and components per sample. In contrast, the PNG

function group shall predict each byte of data as a function of the corresponding byte of one or more

previous image samples, regardless of whether there are multiple colour components in a byte or whether

a single colour component spans multiple bytes.

NOTE 2

This can yield significantly better speed at the cost of somewhat worse compression.

7.4.5

RunLengthDecode Filter

The RunLengthDecode filter decodes data that has been encoded in a simple byte-oriented format based on

run length. The encoded data shall be a sequence of runs, where each run shall consist 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 shall be copied literally during decompression. If length is in the range 129 to 255, the following single

byte shall be copied 257 - length (2 to 128) times during decompression. A length value of 128 shall denote

EOD.

29

NOTE

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.

7.4.6

CCITTFaxDecode Filter

The CCITTFaxDecode filter decodes image data that has been encoded using either Group 3 or Group 4

CCITT facsimile (fax) encoding.

NOTE 1

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 colour images, grayscale images,

or general data.

NOTE 2

The CCITT encoding standard is defined by the International Telecommunications 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 standard but can be

found in ITU Recommendations T.4 and T.6 (see the Bibliography). For historical reasons, we refer to these

documents as the CCITT standard.

CCITT encoding is bit-oriented, not byte-oriented. Therefore, in principle, encoded or decoded data need not

end at a byte boundary. This problem shall be dealt with in the following ways:

•

Unencoded data shall be 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 shall ordinarily be treated as a continuous, unbroken bit stream. The EncodedByteAlign

parameter (described in Table 11) may be used to cause each encoded scan line to be filled to a byte

boundary.

NOTE 3

Although this is not prescribed 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 shall always skip to the next byte boundary following the encoded data.

The filter shall not perform any error correction or resynchronization, except as noted for the

DamagedRowsBeforeError parameter in Table 11.

Table 11 lists the optional parameters that may be used to control the decoding. Except where noted otherwise,

all values supplied to the decoding filter by any of these parameters shall match those used when the data was

encoded.

Table 11 - 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 may

be followed by at most K − 1 lines encoded two-

dimensionally

The filter shall distinguish among negative, zero, and positive

values of K to determine how to interpret the encoded data;

however, it shall not distinguish between different positive K

values. Default value: 0.

30

Table 11 - Optional parameters for the CCITTFaxDecode filter (continued)

Key

Type

Value

EndOfLine

boolean

A flag indicating whether end-of-line bit patterns shall be

present in the encoding. The CCITTFaxDecode filter shall

always accept end-of-line bit patterns. If EndOfLine is true

end-of-line bit patterns shall be present.Default value: false.

EncodedByteAlign

boolean

A flag indicating whether the filter shall expect extra 0 bits

before each encoded line so that the line begins on a byte

boundary. If true, the filter shall skip over encoded bits to

begin decoding each line at a byte boundary. If false, the filter

shall not expect extra bits in the encoded representation.

Default value: false.

Columns

integer

The width of the image in pixels. If the value is not a multiple

of 8, the filter shall adjust the width of the unencoded image

to the next multiple 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 shall be terminated by an end-of-block bit

pattern or by the end of the filter’s data. Default value: 0.

EndOfBlock

boolean

A flag indicating whether the filter shall expect the encoded

data to be terminated by an end-of-block pattern, overriding

the Rows parameter. If false, the filter shall stop 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 shall be the CCITT end-of-facsimile-block

(EOFB) or return-to-control

(RTC) appropriate for the K

parameter. Default value: true.

BlackIs1

boolean

A flag indicating whether 1 bits shall 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 that shall be tolerated

before an error occurs. This entry shall apply only if

EndOfLine is true and K is non-negative. Tolerating a

damaged row shall mean locating its end in the encoded data

by searching for an EndOfLine pattern and then substituting

decoded data from the previous row if the previous row was

not damaged, or a white scan line if the previous row was

also damaged. Default value: 0.

NOTE 4

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 encoding, 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.

7.4.7

JBIG2Decode Filter

The JBIG2Decode filter (PDF 1.4) decodes monochrome (1 bit per pixel) image data that has been encoded

using JBIG2 encoding.

NOTE 1

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 colour images, grayscale images, or general data. The algorithms used by the encoder, and

31

the details of the format, are not described here. See ISO/IEC 11544 published standard for the current JBIG2

specification. Additional information can be found through the Web site for the JBIG and JPEG (Joint

Photographic Experts Group) committees at < http://www.jpeg.org >.

In general, JBIG2 provides considerably better compression than the existing CCITT standard (discussed in

7.4.6, "CCITTFaxDecode Filter"). The compression it achieves depends 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 shall build a table of unique symbol bitmaps found in the image, and other symbols found

later in the image shall be matched against the table. Matching symbols shall be replaced by an index into the

table, and symbols that fail to match shall be added to the table. The table itself shall be compressed using

other means.

NOTE 2

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 includes algorithms for

compressing regions of an image that contain dithered halftone images (for example, photographs).

The JBIG2 compression method may also be used for encoding multiple images into a single JBIG2 bit stream.

NOTE 3

Typically, these images are scanned pages of a multiple-page document. Since a single table of symbol

bitmaps is used to match symbols across multiple pages, this type of encoding can result in higher

compression 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 inline image (as described in

8.9, "Images"); however, the JBIG2Decode filter shall not be used with inline images.

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 shall use 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 specification.) The optional 2-byte combination (marker)

mentioned in the specification shall not be used in PDF. JBIG2 bit streams in random-access organization

should be converted to the embedded file organization. Bit streams in sequential organization need no

reorganization, except for the mappings described below.

•

The JBIG2 file header, end-of-page segments, and end-of-file segment shall not be 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 shall contain all segments 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 association field contains 0),

these segments shall be placed in a separate PDF stream, and the filter parameter listed in Table 12

should refer to that stream. The stream can be shared by multiple image XObjects whose JBIG2

encodings use the same global segments.

Table 12 - Optional parameter for the JBIG2Decode filter

Key

Type

Value

JBIG2Globals

stream

A stream containing the JBIG2 global (page 0) segments. Global

segments shall be placed in this stream even if only a single JBIG2

image XObject refers to it.

32

Content      ..      1       2         ..

///////////////////////////////////////