Content      ..     6      7      8      9     ..

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

9.7.5.2

Predefined CMaps

Several of the CMaps define mappings from Unicode encodings to character collections. Unicode values

appearing in a text string shall be 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.

NOTE 1

Table 118 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.

Table 118 - Predefined CJK CMap names

Name

Description

Chinese (Simplified)

GB-EUC-H

Microsoft Code Page 936 (lfCharSet 0x86), GB 2312-80 character set, EUC-CN

encoding

GB-EUC-V

Vertical version of GB-EUC-H

GBpc-EUC-H

Mac OS, GB 2312-80 character set, EUC-CN encoding, Script Manager code 19

GBpc-EUC-V

Vertical version of GBpc-EUC-H

GBK-EUC-H

Microsoft Code Page 936 (lfCharSet 0x86), GBK character set, GBK encoding

GBK-EUC-V

Vertical version of GBK-EUC-H

GBKp-EUC-H

Same as GBK-EUC-H but replaces half-width Latin characters with proportional

forms and maps character code 0x24 to a dollar sign ($) instead of a yuan symbol

(¥)

GBKp-EUC-V

Vertical version of GBKp-EUC-H

GBK2K-H

GB 18030-2000 character set, mixed 1-, 2-, and 4-byte encoding

GBK2K-V

Vertical version of GBK2K-H

UniGB-UCS2-H

Unicode (UCS-2) encoding for the Adobe-GB1 character collection

UniGB-UCS2-V

Vertical version of UniGB-UCS2-H

UniGB-UTF16-H

Unicode (UTF-16BE) encoding for the Adobe-GB1 character collection; contains

mappings for all characters in the GB18030-2000 character set

UniGB-UTF16-V

Vertical version of UniGB-UTF16-H

Chinese (Traditional)

B5pc-H

Mac OS, Big Five character set, Big Five encoding, Script Manager code 2

B5pc-V

Vertical version of B5pc-H

HKscs-B5-H

Hong Kong SCS, an extension to the Big Five character set and encoding

HKscs-B5-V

Vertical version of HKscs-B5-H

ETen-B5-H

Microsoft Code Page 950 (lfCharSet 0x88), Big Five character set with ETen

extensions

ETen-B5-V

Vertical version of ETen-B5-H

ETenms-B5-H

Same as ETen-B5-H but replaces half-width Latin characters with proportional

forms

273

Table 118 - Predefined CJK CMap names (continued)

Name

Description

ETenms-B5-V

Vertical version of ETenms-B5-H

CNS-EUC-H

CNS 11643-1992 character set, EUC-TW encoding

CNS-EUC-V

Vertical version of CNS-EUC-H

UniCNS-UCS2-H

Unicode (UCS-2) encoding for the Adobe-CNS1 character collection

UniCNS-UCS2-V

Vertical version of UniCNS-UCS2-H

UniCNS-UTF16-H

Unicode

(UTF-16BE) encoding for the Adobe-CNS1 character collection;

contains mappings for all the characters in the HKSCS-2001 character set and

contains both 2- and 4-byte character codes

UniCNS-UTF16-V

Vertical version of UniCNS-UTF16-H

Japanese

83pv-RKSJ-H

Mac OS, JIS X 0208 character set with KanjiTalk6 extensions, Shift-JIS encoding,

Script Manager code 1

90ms-RKSJ-H

Microsoft Code Page 932 (lfCharSet 0x80), JIS X 0208 character set with NEC

and IBM® extensions

90ms-RKSJ-V

Vertical version of 90ms-RKSJ-H

90msp-RKSJ-H

Same as 90ms-RKSJ-H but replaces half-width Latin characters with proportional

forms

90msp-RKSJ-V

Vertical version of 90msp-RKSJ-H

90pv-RKSJ-H

Mac OS, JIS X 0208 character set with KanjiTalk7 extensions, Shift-JIS encoding,

Script Manager code 1

Add-RKSJ-H

JIS X 0208 character set with Fujitsu FMR extensions, Shift-JIS encoding

Add-RKSJ-V

Vertical version of Add-RKSJ-H

EUC-H

JIS X 0208 character set, EUC-JP encoding

EUC-V

Vertical version of EUC-H

Ext-RKSJ-H

JIS C 6226 (JIS78) character set with NEC extensions, Shift-JIS encoding

Ext-RKSJ-V

Vertical version of Ext-RKSJ-H

H

JIS X 0208 character set, ISO-2022-JP encoding

V

Vertical version of H

UniJIS-UCS2-H

Unicode (UCS-2) encoding for the Adobe-Japan1 character collection

UniJIS-UCS2-V

Vertical version of UniJIS-UCS2-H

UniJIS-UCS2-HW-H

Same as UniJIS-UCS2-H but replaces proportional Latin characters with half-

width forms

UniJIS-UCS2-HW-V

Vertical version of UniJIS-UCS2-HW-H

UniJIS-UTF16-H

Unicode

(UTF-16BE) encoding for the Adobe-Japan1 character collection;

contains mappings for all characters in the JIS X 0213:1000 character set

UniJIS-UTF16-V

Vertical version of UniJIS-UTF16-H

Korean

274

Table 118 - Predefined CJK CMap names (continued)

Name

Description

KSC-EUC-H

KS X 1001:1992 character set, EUC-KR encoding

KSC-EUC-V

Vertical version of KSC-EUC-H

KSCms-UHC-H

Microsoft Code Page 949 (lfCharSet 0x81), KS X 1001:1992 character set plus

8822 additional hangul, Unified Hangul Code (UHC) encoding

KSCms-UHC-V

Vertical version of KSCms−UHC-H

KSCms-UHC-HW-H

Same as KSCms-UHC-H but replaces proportional Latin characters with half-

width forms

KSCms-UHC-HW-V

Vertical version of KSCms-UHC-HW-H

KSCpc-EUC-H

Mac OS, KS X 1001:1992 character set with Mac OS KH extensions, Script

Manager Code 3

UniKS-UCS2-H

Unicode (UCS-2) encoding for the Adobe-Korea1 character collection

UniKS-UCS2-V

Vertical version of UniKS-UCS2-H

UniKS-UTF16-H

Unicode (UTF-16BE) encoding for the Adobe-Korea1 character collection

UniKS-UTF16-V

Vertical version of UniKS-UTF16-H

Generic

Identity-H

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.

Identity-V

Vertical version of Identity-H. The mapping is the same as for Identity-H.

NOTE 2

The Identity-H and Identity-V CMaps may 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 Identity-H or Identity-V, the string to be shown

shall contain pairs of bytes representing CIDs, high-order byte first. When the current font is a CIDFont, the

string to be shown shall contain pairs of bytes representing CIDs, high-order byte first. When the current font is

a Type 2 CIDFont in which the CIDToGIDMap entry is Identity and if the TrueType font is embedded in the PDF

file, the

2-byte CID values shall be identical glyph indices for the glyph descriptions in the TrueType font

program.

NOTE 3

Table 119 lists the character collections referenced by the predefined CMaps for the different versions of PDF.

A dash (—) indicates that the CMap is not predefined in that PDF version.

Table 119 - Character collections for predefined CMaps, by PDF version

CMAP

PDF 1.2

PDF 1.3

PDF 1.4

PDF 1.5

Chinese (Simplified)

GB-EUC-H/V

Adobe-GB1-0

Adobe-GB1-0

Adobe-GB1-0

Adobe-GB1-0

GBpc-EUC-H

Adobe-GB1-0

Adobe-GB1-0

Adobe-GB1-0

Adobe-GB1-0

GBpc-EUC-V

—

Adobe-GB1-0

Adobe-GB1-0

Adobe-GB1-0

GBK-EUC-H/V

—

Adobe-GB1-2

Adobe-GB1-2

Adobe-GB1-2

GBKp-EUC-H/V

—

—

Adobe-GB1-2

Adobe-GB1-2

275

Table 119 - Character collections for predefined CMaps, by PDF version (continued)

CMAP

PDF 1.2

PDF 1.3

PDF 1.4

PDF 1.5

GBK2K-H/V

—

—

Adobe-GB1-4

Adobe-GB1-4

UniGB-UCS2-H/V

—

Adobe-GB1-2

Adobe-GB1-4

Adobe-GB1-4

UniGB-UTF16-H/V

—

—

—

Adobe-GB1-4

Chinese (Traditional)

B5pc-H/V

Adobe-CNS1-0

Adobe-CNS1-0

Adobe-CNS1-0

Adobe-CNS1-0

HKscs-B5-H/V

—

—

Adobe-CNS1-3

Adobe-CNS1-3

ETen-B5-H/V

Adobe-CNS1-0

Adobe-CNS1-0

Adobe-CNS1-0

Adobe-CNS1-0

ETenms-B5-H/V

—

Adobe-CNS1-0

Adobe-CNS1-0

Adobe-CNS1-0

CNS-EUC-H/V

Adobe-CNS1-0

Adobe-CNS1-0

Adobe-CNS1-0

Adobe-CNS1-0

UniCNS-UCS2-H/V

—

Adobe-CNS1-0

Adobe-CNS1-3

Adobe-CNS1-3

UniCNS-UTF16-H/V

—

—

—

Adobe-CNS1-4

Japanese

83pv-RKSJ-H

Adobe-Japan1-1

Adobe-Japan1-1

Adobe-Japan1-1

Adobe-Japan1-1

90ms-RKSJ-H/V

Adobe-Japan1-2

Adobe-Japan1-2

Adobe-Japan1-2

Adobe-Japan1-2

90msp-RKSJ-H/V

—

Adobe-Japan1-2

Adobe-Japan1-2

Adobe-Japan1-2

90pv-RKSJ-H

Adobe-Japan1-1

Adobe-Japan1-1

Adobe-Japan1-1

Adobe-Japan1-1

Add-RKSJ-H/V

Adobe-Japan1-1

Adobe-Japan1-1

Adobe-Japan1-1

Adobe-Japan1-1

EUC-H/V

—

Adobe-Japan1-1

Adobe-Japan1-1

Adobe-Japan1-1

Ext-RKSJ-H/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

UniJIS-UCS2-H/V

—

Adobe-Japan1-2

Adobe-Japan1-4

Adobe-Japan1-4

UniJIS-UCS2-HW-H/V

—

Adobe-Japan1-2

Adobe-Japan1-4

Adobe-Japan1-4

UniJIS-UTF16-H/V

—

—

—

Adobe-Japan1-5

Korean

KSC-EUC-H/V

Adobe-Korea1-0

Adobe-Korea1-0

Adobe-Korea1-0

Adobe-Korea1-0

KSCms-UHC-H/V

Adobe-Korea1-1

Adobe-Korea1-1

Adobe-Korea1-1

Adobe-Korea1-1

KSCms-UHC-HW-H/V

—

Adobe-Korea1-1

Adobe-Korea1-1

Adobe-Korea1-1

KSCpc-EUC-H

Adobe-Korea1-0

Adobe-Korea1-0

Adobe-Korea1-0

Adobe-Korea1-0

UniKS-UCS2-H/V

—

Adobe-Korea1-1

Adobe-Korea1-1

Adobe-Korea1-1

UniKS-UTF16-H/V

—

—

—

Adobe-Korea1-2

Generic

Identity-H/V

Adobe-Identity-0

Adobe-Identity-0

Adobe-Identity-0

Adobe-Identity-0

276

A conforming reader shall support all of the character collections listed in Table 119. As noted in 9.7.3,

"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 shall be valid when interpreted by a conforming reader supporting

the same or a later PDF version. When interpreted by a conforming reader 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 version, no characters are displayed for those codes; see 9.7.6.3, "Handling Undefined

Characters".

The Identity-H and Identity-V CMaps shall not be used with a non-embedded font. Only standardized character

sets may be used.

NOTE 4

If a conforming writer 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.

The CMap programs that define the predefined CMaps are available through the ASN Web site.

9.7.5.3

Embedded CMap Files

For character encodings that are not predefined, the PDF file shall contain a stream that defines the CMap. In

addition to the standard entries for streams (listed in Table 5), the CMap stream dictionary contains the entries

listed in Table 120. The data in the stream defines the mapping from character codes to a font number and a

character selector. The data shall follow the syntax defined in Adobe Technical Note #5014, Adobe CMap and

CIDFont Files Specification (see bibliography).

Table 120 - Additional entries in a CMap stream dictionary

Key

Type

Value

Type

name

(Required) The type of PDF object that this dictionary describes; shall

be CMap for a CMap dictionary.

CMapName

name

(Required) The name of the CMap. It shall be the same as the value of

CMapName in the CMap file.

CIDSystemInfo

dictionary

(Required) A dictionary

(see

9.7.3, "CIDSystemInfo Dictionaries")

containing entries that define the character collection for the CIDFont

or CIDFonts associated with the CMap.

The value of this entry shall 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 specifies the writing mode for any CIDFont with

which this CMap is combined. The value shall be 0 for horizontal or 1

for vertical. Default value: 0.

The value of this entry shall be the same as the value of WMode in the

CMap file.

UseCMap

name or

(Optional) The name of a predefined CMap, or a stream containing a

stream

CMap. If this entry is present, the referencing CMap shall specify only

the character mappings that differ from the referenced CMap.

9.7.5.4

CMap Example and Operator Summary

Embedded CMap files shall conform to the format documented in Adobe Technical Note #5014, subject to

these additional constraints:

277

< 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

9.7.6

Type 0 Font Dictionaries

9.7.6.1

General

A Type 0 font dictionary contains the entries listed in Table 121.

Table 121 - Entries in a Type 0 font dictionary

Key

Type

Value

Type

name

(Required) The type of PDF object that this dictionary describes; shall

be Font for a font dictionary.

Subtype

name

(Required) The type of font; shall be Type0 for a Type 0 font.

BaseFont

name

(Required) The name of the font. 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.

NOTE

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

Encoding

name or

(Required) The name of a predefined CMap, or a stream containing a

stream

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 shall be

a predefined CMap name (see 9.7.4.2, "Glyph Selection in CIDFonts").

279

Table 121 - Entries in a Type 0 font dictionary (continued)

Key

Type

Value

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 9.10, "Extraction of Text Content").

EXAMPLE

This code sample shows a Type 0 font.

14 0 obj

<<

/Type /Font

/Subtype /Type0

/BaseFont /HeiseiMin-W5-90ms-RKSJ-H

/Encoding /90ms-RKSJ-H

/DescendantFonts [ 15 0 R ]

>>

endobj

9.7.6.2

CMap Mapping

The Encoding entry of a Type 0 font dictionary specifies a CMap that specifies how text-showing operators

(such as Tj) shall interpret the bytes in the string to be shown when the current font is the Type 0 font. This sub-

clause describes how the characters in the string shall be decoded and mapped into character selectors, which

in PDF are always CIDs.

The codespace ranges in the CMap (delimited by begincodespacerange and endcodespacerange) specify

how many bytes are extracted from the string for each successive character code. A codespace range shall be

specified by a pair of codes of some particular length giving the lower and upper bounds of that range. A code

shall be 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 shall not be

greater than 4.

A sequence of one or more bytes shall be extracted from the string and matched against the codespace ranges

in the CMap. That is, the first byte shall be matched against 1-byte codespace ranges; if no match is found, a

second byte shall be extracted, and the 2-byte code shall be matched against 2-byte codespace ranges. This

process continues for successively longer codes until a match is found or all codespace ranges have been

tested. There will be at most one match because codespace ranges shall not overlap.

The code extracted from the string shall be 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 shall be looked up in the notdef mappings, as described in the next sub-

clause.

The results of the CMap mapping algorithm are a font number and a character selector. The font number shall

be used as an index into the Type 0 font’s DescendantFonts array to select a CIDFont. In PDF, the font

number shall be 0 and the character selector shall be a CID; this is the only case described here. The CID shall

then be used to select a glyph in the CIDFont. If the CIDFont contains no glyph for that CID, the notdef

mappings shall be consulted, as described in 9.7.6.3, "Handling Undefined Characters".

9.7.6.3

Handling Undefined Characters

A CMap mapping operation can fail to select a glyph for a variety of reasons. This sub-clause 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 shall be consulted to obtain a substitute character selector. These mappings are delimited by the

280

operators beginnotdefchar, endnotdefchar, beginnotdefrange, and endnotdefrange within an embedded

CMap file. They shall always map to a CID. If a matching notdef mapping is found, the CID selects a glyph in

the associated descendant, which shall be a CIDFont. If no glyph exists for that CID, the glyph for CID 0 (which

shall be present) shall be substituted.

NOTE 5

The notdef mappings are similar to the . notdef character mechanism in simple fonts.

If the CMap does not contain either a character mapping or a notdef mapping for the code, descendant 0 shall

be selected and the glyph for CID 0 shall be 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 shall be

reset to its original position in the string, and a modified mapping algorithm chooses the best partially matching

codespace range:

a) 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 shall be chosen.

b) Otherwise (that is, if there is a partial match), for each additional byte extracted, the code accumulated so

far shall be matched against the beginnings of all longer codespace ranges until the longest such partial

match has been found. If multiple codespace ranges have partial matches of the same length, the one

having the shortest codes shall be chosen.

The length of the codes in the chosen codespace range determines the total number of bytes to consume from

the string for the current mapping operation.

9.8

Font Descriptors

9.8.1

General

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 conforming reader 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 shall not be used with Type 0 fonts. Beginning with PDF 1.5, font descriptors may be used with

Type 3 fonts.

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 122. Additional entries in the font

descriptor for a CIDFont are described in 9.8.3, "Font Descriptors for CIDFonts". All integer values shall be

units in glyph space. The conversion from glyph space to text space is described in 9.2.4, "Glyph Positioning

and Metrics".

Table 122 - Entries common to all font descriptors

Key

Type

Value

Type

name

(Required) The type of PDF object that this dictionary describes; shall

be FontDescriptor for a font descriptor.

FontName

name

(Required) The PostScript name of the font. This name shall be the

same as the value of BaseFont in the font or CIDFont dictionary that

refers to this font descriptor.

FontFamily

byte string

(Optional; PDF 1.5; should be used for Type 3 fonts in Tagged PDF

documents) A byte string specifying the preferred font family name.

EXAMPLE 1

For the font Times Bold Italic, the FontFamily is

Times.

281

Table 122 - Entries common to all font descriptors (continued)

Key

Type

Value

FontStretch

name

(Optional; PDF 1.5; should be used for Type 3 fonts in Tagged PDF

documents) The font stretch value. It shall be one of these names

(ordered

from

narrowest

to

widest):

UltraCondensed,

ExtraCondensed,

Condensed,

SemiCondensed,

Normal,

SemiExpanded, Expanded, ExtraExpanded or UltraExpanded.

The specific interpretation of these values varies from font to font.

EXAMPLE 2

Condensed in one font may appear most similar to

Normal in another.

FontWeight

number

(Optional; PDF 1.5; should be used for Type 3 fonts in Tagged PDF

documents) The weight (thickness) component of the fully-qualified

font name or font specifier. The possible values shall be 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 shall

indicate a normal weight; 700 shall indicate bold.

The specific interpretation of these values varies from font to font.

EXAMPLE 3

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 9.8.2, "Font Descriptor Flags").

FontBBox

rectangle

(Required, except for Type

3 fonts) A rectangle

(see

7.9.5,

"Rectangles"), expressed in the glyph coordinate system, that shall

specify the font bounding box. This should be 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 vertical, of the dominant vertical strokes of the font.

EXAMPLE 4

The 9-o’clock position is 90 degrees, and the 3-

o’clock position is -90 degrees.

The value shall be 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. The height of glyphs for

accented characters shall be excluded.

Descent

number

(Required, except for Type 3 fonts) The maximum depth below the

baseline reached by glyphs in this font. The value shall be 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 vertical 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

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

282

Table 122 - Entries common to all font descriptors (continued)

Key

Type

Value

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

specified in a font dictionary’s Widths array. This shall have 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 9.9,

"Embedded Font Programs").

FontFile2

stream

(Optional; PDF 1.1) A stream containing a TrueType font program (see

9.9, "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 126).

CharSet

ASCII string

(Optional; meaningful only in Type 1 fonts; PDF 1.1) A string listing the

or

byte

character names defined in a font subset. The names in this string

string

shall be in PDF syntax—that is, each name preceded by a slash (/).

The names may appear in any order. The name . notdef shall be

omitted; it shall exist in the font subset. If this entry is absent, the only

indication of a font subset shall be the subset tag in the FontName

entry (see 9.6.4, "Font Subsets").

At most, only one of the FontFile, FontFile2, and FontFile3 entries shall be present.

9.8.2

Font Descriptor Flags

The value of the Flags entry in a font descriptor shall be an unsigned 32-bit integer containing flags specifying

various characteristics of the font. Bit positions within the flag word are numbered from 1 (low-order) to 32

(high-order). Table 123 shows the meanings of the flags; all undefined flag bits are reserved and shall be set to

0 by conforming writers. Figure 48 shows examples of fonts with these characteristics.

Table 123 - Font flags

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 shall not both be set or both be

clear.

4

Script

Glyphs resemble cursive handwriting.

6

Nonsymbolic

Font uses the Adobe standard Latin character set or a subset of it.

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.

283

Table 123 - Font flags (continued)

Bit position

Name

Meaning

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 description after Note 1 in this sub-clause.

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 D.2, "Latin Character Set and Encodings". If the font contains any glyphs outside this set, the

Symbolic flag shall be set and the Nonsymbolic flag shall be clear. In other words, any font whose character set

is not a subset of the Adobe standard character set shall be considered to be symbolic. This influences the

font’s implicit base encoding and may affect a conforming reader’s font substitution strategies.

Fixed-pitch font

The quick brown fox jumped.

Serif font

The quick brown fox jumped.

Sans serif font

The quick brown fox jumped.

Symbolic font

✴❈❅ ❑◆❉❃❋ ❂❒❏◗■ ❆❏❘ ❊◆❍❐❅❄✎

Script font

The quick brown fox jumped.

Italic font

The quick brown fox jumped.

All-cap font

The quick brown fox jumped

Small-cap font

The quick brown fox jumped.

Figure 48 - Characteristics represented in the Flags entry of a font descriptor

NOTE 1

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) shall determine whether bold glyphs shall be painted with extra pixels even at very

small text sizes by a conforming reader. If the ForceBold flag is set, features of bold glyphs may be thickened at

small text sizes.

NOTE 2

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.

284

EXAMPLE

This code sample illustrates a font descriptor whose Flags entry has the Serif, Nonsymbolic, and

ForceBold flags (bits 2, 6, and 19) set.

7 0 obj

<<

/Type /FontDescriptor

/FontName /AGaramond-Semibold

/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

9.8.3

Font Descriptors for CIDFonts

9.8.3.1

General

In addition to the entries in Table 122, the FontDescriptor dictionaries of CIDFonts may contain the entries

listed in Table 124.

Table 124 - 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 9.8.3.2, "Style").

Lang

name

(Optional; PDF 1.5) A name specifying the language of the font, which may be

used for encodings where the language is not implied by the encoding itself.

The value shall be one of the codes defined by Internet RFC 3066, Tags for the

Identification of Languages or (PDF 1.0) 2-character language codes defined

by ISO 639 (see the Bibliography). If this entry is absent, the language shall be

considered to be unknown.

FD

dictionary

(Optional) A dictionary whose keys identify a class of glyphs in a CIDFont.

Each value shall be a dictionary containing entries that shall override the

corresponding values in the main font descriptor dictionary for that class of

glyphs (see 9.8.3.3, "FD").

CIDSet

stream

(Optional) A stream identifying which CIDs are present in the CIDFont file. If

this entry is present, the CIDFont shall contain only a subset of the glyphs in

the character collection defined by the CIDSystemInfo dictionary. If it is

absent, the only indication of a CIDFont subset shall be the subset tag in the

FontName entry (see 9.6.4, "Font Subsets").

The stream’s data shall be organized as a table of bits indexed by CID. The bits

shall be stored in bytes with the high-order bit first. Each bit shall correspond to

a CID. The most significant bit of the first byte shall correspond to CID 0, the

next bit to CID 1, and so on.

9.8.3.2

Style

The Style dictionary contains entries that define style attributes and values for the CIDFont. Only the Panose

entry is defined. The value of Panose shall be a 12-byte string consisting of these elements:

285

Table 125 - Glyph classes in CJK fonts

Character Collection

Class

Glyphs in Class

Adobe-GB1

Alphabetic

Full-width Latin, Greek, and Cyrillic glyphs

Dingbats

Special symbols

Generic

Typeface-independent glyphs, such as line-drawing

Hanzi

Full-width hanzi (Chinese) glyphs

HRoman

Half-width Latin glyphs

HRomanRot

Same as HRoman but rotated for use in vertical writing

Kana

Japanese kana (katakana and hiragana) glyphs

Proportional

Proportional Latin glyphs

ProportionalRot

Same as Proportional but rotated for use in vertical

writing

Adobe-CNS1

Alphabetic

Full-width Latin, Greek, and Cyrillic glyphs

Dingbats

Special symbols

Generic

Typeface-independent glyphs, such as line-drawing

Hanzi

Full-width hanzi (Chinese) glyphs

HRoman

Half-width Latin glyphs

HRomanRot

Same as HRoman but rotated for use in vertical writing

Kana

Japanese kana (katakana and hiragana) glyphs

Proportional

Proportional Latin glyphs

ProportionalRot

Same as Proportional but rotated for use in vertical

writing

Adobe-Japan1

Alphabetic

Full-width Latin, Greek, and Cyrillic glyphs

AlphaNum

Numeric glyphs

Dingbats

Special symbols

DingbatsRot

Same as Dingbats but rotated for use in vertical writing

Generic

Typeface-independent glyphs, such as line-drawing

GenericRot

Same as Generic but rotated for use in vertical writing

HKana

Half-width kana (katakana and hiragana) glyphs

HKanaRot

Same as HKana but rotated for use in vertical writing

HRoman

Half-width Latin glyphs

HRomanRot

Same as HRoman but rotated for use in vertical writing

Kana

Full-width kana (katakana and hiragana) glyphs

Kanji

Full-width kanji (Chinese) glyphs

Proportional

Proportional Latin glyphs

ProportionalRot

Same as Proportional but rotated for use in vertical

writing

Glyphs used for setting ruby (small glyphs that serve to

Ruby

annotate other glyphs with meanings or readings)

Adobe-Japan2

Alphabetic

Full-width Latin, Greek, and Cyrillic glyphs

Dingbats

Special symbols

HojoKanji

Full-width kanji glyphs

287

Table 125 - Glyph classes in CJK fonts (continued)

Character Collection

Class

Glyphs in Class

Adobe-Korea1

Alphabetic

Full-width Latin, Greek, and Cyrillic glyphs

Dingbats

Special symbols

Generic

Typeface-independent glyphs, such as line-drawing

Hangul

Hangul and jamo glyphs

Hanja

Full-width hanja (Chinese) glyphs

HRoman

Half-width Latin glyphs

HRomanRot

Same as HRoman but rotated for use in vertical writing

Kana

Japanese kana (katakana and hiragana) glyphs

Proportional

Proportional Latin glyphs

ProportionalRot

Same as Proportional but

rotated for

use

in vertical

writing

EXAMPLE 2

This example illustrates an FD dictionary containing two entries.

/FD

<<

/Proportional

25 0 R

/HKana 26 0 R

>>

25 0 obj

<<

/Type /FontDescriptor

/FontName /HeiseiMin-W3-Proportional

/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 /HeiseiMin-W3-HKana

/Flags 3

/AvgWidth 500

/MaxWidth 500

/MissingWidth 500

/StemV 50

/StemH 75

/Ascent 720

/Descent 0

/Leading 83

>>

endobj

9.9

Embedded Font Programs

A font program may be embedded in a PDF file as data contained in a PDF stream object.

NOTE 1

Such a stream object is also called a font file by analogy with font programs that are available from sources

external to the conforming writer.

288

Font programs are subject to copyright, and the copyright owner may impose conditions under which a font

program may be used. These permissions are recorded either in the font program or as part of a separate

license. One of the conditions 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 operation 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, embedded font programs shall be used only to view and print the document and not for any other

purposes.

Table 126 summarizes the ways in which font programs shall be embedded in a PDF file, depending on the

representation of the font program. The key shall be the name used in the font descriptor to refer to the font file

stream; the subtype shall be 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 126 - 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 may 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 may appear in the font descriptor for

a TrueType font dictionary or

(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 may

appear in the font descriptor for a Type1 or MMType1 font

dictionary.

FontFile3

CIDFontType0C

(PDF 1.3) Type 0 CIDFont program represented in the Compact

Font Format (CFF), as described in Adobe Technical Note #5176,

The Compact Font Format Specification. This entry may appear in

the font descriptor for a CIDFontType0 CIDFont dictionary.

289

Table 126 - Embedded font organization for various font types (continued)

Key

Subtype

Description

FontFile3

OpenType

(PDF 1.6) OpenType® font program, as described in the OpenType

Specification v.1.4

(see the Bibliography). OpenType is an

extension of TrueType that allows inclusion of font programs that

use the Compact Font Format (CFF).

A FontFile3 entry with an OpenType subtype may appear in the

font descriptor for these types of font dictionaries:

• A TrueType font dictionary or a CIDFontType2 CIDFont

dictionary, if the embedded font program contains a “glyf” table.

In addition to the “glyf” table, the font program must include

these tables: “head”, “hhea”, “hmtx”, “loca”, and “maxp”. The

“cvt ” (notice the trailing SPACE), “fpgm”, and “prep” tables must

also be included if they are required by the font instructions.

• A CIDFontType0 CIDFont dictionary, if the embedded font

program contains a “CFF ” table (notice the trailing SPACE) with

a Top DICT that uses CIDFont operators (this is equivalent to

subtype CIDFontType0C). In addition to the “CFF ” table, the

font program must include the “cmap” table.

• A Type1 font dictionary or CIDFontType0 CIDFont dictionary, if

the embedded font program contains a “CFF ” table without

CIDFont operators. In addition to the “CFF ” table, the font

program must include the “cmap” table.

The OpenType Specification describes a set of required tables;

however, not all tables are required in the font file, as described for

each type of font dictionary that can include this entry.

NOTE

The absence of some optional tables (such as those

used for advanced line layout) may prevent editing of

text containing the font.

The stream dictionary for a font file shall contain the normal entries for a stream, such as Length and Filter

(listed in Table 5), plus the additional entries listed in Table 127.

Table 127 - Additional entries in an embedded font stream dictionary

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, 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 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 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 shall be

added by the conforming reader.

Subtype

name

(Required if referenced from FontFile3; PDF 1.2) A name specifying the format of

the embedded font program. The name shall be Type1C for Type 1 compact fonts,

CIDFontType0C for Type 0 compact CIDFonts, or OpenType for OpenType fonts.

Metadata

stream

(Optional; PDF 1.4) A metadata stream containing metadata for the embedded font

program (see 14.3.2, "Metadata Streams").

NOTE 2

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 perhaps followed

290

function value, and so on. If two pixels have the same spot function value, their relative order shall be chosen

arbitrarily.

PDF provides built-in definitions for many of the most commonly used spot functions that a conforming reader

shall implement. A halftone may simply specify any of these predefined spot functions by name instead of

giving an explicit function definition.

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 proportional to the gray level. The name Line designates 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.

Table 128 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 7.10.5, "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. Pixels corresponding to darker points in the image are whitened later than

those corresponding to lighter points.

Table 128 - Predefined spot functions

Name

Appearance

Definition

SimpleDot

1 − (x ² + y ² )

{ dup mul exch dup mul add 1 exch sub }

InvertedSimpleDot

x ² + y ² − 1

{ dup mul exch dup mul add 1 sub }

DoubleDot

sin (360 × x)

+ ------------------------------

2

2

{

360 mul sin 2 div exch 360 mul sin 2 div add }

InvertedDoubleDot

⎛sin(360 × x)

⎞

–

+ ------------------------------

⎝

⎠

2

2

{

360 mul sin 2 div exch 360 mul sin 2 div add neg }

303

Table 128 - Predefined spot functions (continued)

Name

Appearance

Definition

CosineDot

cos (180 × x)

+ -------------------------------

2

2

{

180 mul cos exch 180 mul cos add 2 div }

Double

⎛

⎞

sin

360

×

-

⎝

2⎠

-------------------------------

+ ------------------------------

2

2

{

360 mul sin 2 div exch 2 div 360 mul sin 2 div add }

InvertedDouble

⎛

⎛

x⎞

⎞

sin

360

× --

⎜

⎝

2⎠

⎟

-

⎜-------------------------------

+ ------------------------------⎟

⎜

2

2

⎟

⎝

⎠

{

360 mul sin 2 div exch

2 div 360 mul sin 2

div add neg }

Line

−| y|

{ exch pop abs neg }

LineX

x

{ pop }

LineY

y

{ exch pop }

304

Table 128 - Predefined spot functions (continued)

Name

Appearance

Definition

Round

if |x| + |y|

≤ 1 then 1 − (x ² + y ²)

else (| x| − 1) ² + (| y| − 1) ² − 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

2

⎛

y

⎞²

x

+

⎝0.75⎠

if w < 0 then

1

- ------------------------------

4

2

⎛1- y

⎞²

(1- x )

+

⎝

0.75

⎠

else if w > 1 then

----------------------------------------------------- - 1

4

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

}

EllipseA

1 − (x ² + 0.9 × y ² )

{ dup mul 0.9 mul exch dup mul add 1 exch sub }

InvertedEllipseA

x ² + 0.9 × y ² − 1

{ dup mul 0.9 mul exch dup mul add 1 sub }

305

Table 128 - Predefined spot functions (continued)

Name

Appearance

Definition

EllipseB

1

-

x²

+

-

×

y²

8

{ dup 5 mul 8 div mul exch dup mul exch add sqrt

1 exch sub }

EllipseC

1 − (0.9 × x² + y² )

{ dup mul exch dup mul 0.9 mul add 1 exch sub }

InvertedEllipseC

0.9 × x ² + y ² − 1

{ dup mul exch dup mul 0.9 mul add 1 sub }

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

0.9 × x

+ y

2

{ abs exch abs 0.9 mul add 2 div }

306

Table 128 - Predefined spot functions (continued)

Name

Appearance

Definition

Diamond

if |x| + |y| ≤ 0.75 then 1 − (x ² + y ²)

else if | x| + | y| ≤ 1.23 then 1 − (0.85 × | x | + | y | )

else ( | x | − 1) ² + ( | y | − 1) ² − 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 du

mul add 1 sub }

ifelse

}

ifelse

}

Figure 49 illustrates the effects of some of the predefined spot functions.

150 per inch at 45

100 per inch at 45

50 per inch at 45

75 per inch at 45

Round dot screen Round dot screen Round dot screen

Line screen

Figure 49 - Various halftoning effects

10.5.4

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 arbitrary 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 shall be defined

entirely in device space. Depending on the halftone type, the threshold values occupy 8 or 16 bits each.

Threshold values nominally represent gray levels in the usual way, from 0 for black up to the maximum (255 or

65,535) for white. The threshold array shall be replicated to tile the entire device space: each pixel in device

space shall be 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 shall proceed as follows:

a) For each device pixel that is to be painted with some gray level, consult the corresponding threshold value

from the threshold array.

b) If the requested gray level is less than the threshold value, paint the device pixel black; otherwise, paint it

white. Gray levels in the range 0.0 to 1.0 correspond to threshold values from 0 to the maximum available

(255 or 65,535).

307

A threshold value of 0 shall be 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, where each pixel can

directly represent intermediate gray levels in addition to black and white. For any device pixel that is specified

with some in-between gray level, the halftoning algorithm shall consult 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

representable gray levels.

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.

NOTE

A halftone defined in this way can also be used with colour displays that have a limited number of values for

each colour component. The red, green, and blue components are simply treated independently as gray

levels, applying the appropriate 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.)

10.5.5

Halftone Dictionaries

10.5.5.1

General

In PDF 1.2, the graphics state includes a current halftone parameter, which determines the halftoning process

that a conforming reader shall use to perform painting operations. The current halftone may be specified as the

value of the HT entry in a graphics state parameter dictionary; see Table 58. 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 clause 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 shall have a HalftoneType entry whose value shall be an integer 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 129.

Table 129 - PDF halftone types

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 colour component (including both primary and spot colorants). The

keys in this dictionary 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.

NOTE 1

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 exceptions:

308

The PDF dictionaries may contain a Type entry with the value Halftone, identifying the type of PDF object that

the dictionary describes.

Spot functions and transfer functions are represented by function objects instead of PostScript procedures.

Threshold arrays are specified as streams instead of files.

In type 5 halftone dictionaries, the keys for colorants shall 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 shall be used, overriding any other halftone

parameters specified in the dictionary.

NOTE 2

This provides a way for PDF files to select the proprietary halftones supplied by some device manufacturers,

which would not otherwise be accessible because they are not explicitly defined in PDF.

If there is no HalftoneName entry, or if the requested halftone name does not exist on the device, the halftone’s

parameters shall be defined by the other entries in the dictionary, if any. If no other entries are present, the

default halftone shall be used.

NOTE 3

See 11.7.5, "Rendering Parameters and Transparency" and, in particular, “Halftone and Transfer Function” in

11.7.5.2 for further discussion of the role of halftones in the transparent imaging model.

10.5.5.2

Type 1 Halftones

Table 130 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 130 - Entries in a type 1 halftone dictionary

Key

Type

Value

Type

name

(Optional) The type of PDF object that this dictionary describes;

if present, shall be Halftone for a halftone dictionary.

HalftoneType

integer

(Required) A code identifying the halftone type that this

dictionary describes; shall be 1 for this type of halftone.

HalftoneName

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

NOTE

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 shall be adjusted for different gray

levels, or the name of one of the predefined spot functions (see

Table 128).

AccurateScreens

boolean

(Optional) A flag specifying whether to invoke a special halftone

algorithm that is extremely precise but computationally

expensive; see Note 1 for further discussion. Default value:

false.

309

Table 130 - Entries in a type 1 halftone dictionary (continued)

Key

Type

Value

TransferFunction

function or name

(Optional) A transfer function, which overrides the current

transfer function in the graphics state for the same component.

This entry shall be present if the dictionary is a component of a

type

5 halftone

(see

“Type

5 Halftones” in

10.5.5.6) and

represents either a nonprimary or nonstandard primary colour

component (see 10.4, "Transfer Functions"). The name Identity

may be used to specify the identity function.

If the AccurateScreens entry has a value of true, a highly precise halftoning algorithm shall be substituted in

place of the standard one. If AccurateScreens is false or not present, ordinary halftoning shall be used.

NOTE 1

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 accuracy is

important mainly for making colour separations on high-resolution devices. However, it may be computationally

expensive and therefore is ordinarily disabled.

NOTE 2

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 exceed 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

The following shows a halftone dictionary for a type 1 halftone.

28 0 obj

<< /Type /Halftone

/HalftoneType 1

/Frequency 120

/Angle 30

/SpotFunction /CosineDot

/TransferFunction /Identity

>>

endobj

10.5.5.3

Type 6 Halftones

A type 6 halftone defines a halftone screen with a threshold array. The halftone shall be represented as a

stream containing the threshold values; the parameters defining the halftone shall be specified by entries in the

stream dictionary. This dictionary may contain the entries shown in Table 131 in addition to the usual entries

common to all streams (see Table 5). The Width and Height entries shall specify the dimensions of the

threshold array in device pixels; the stream shall contain Width × Height bytes, each representing a single

threshold value. Threshold values are defined in device space in the same order as image samples in image

space (see Figure 34), with the first value at device coordinates (0, 0) and horizontal coordinates changing

faster than vertical coordinates.

Table 131 - 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, shall be Halftone for a halftone dictionary.

HalftoneType

integer

(Required) A code identifying the halftone type that this

dictionary describes; shall be 6 for this type of halftone.

HalftoneName

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

310

Table 131 - Additional entries specific to a type 6 halftone dictionary (continued)

Key

Type

Value

TransferFunction

function or name

(Optional) A transfer function, which shall override the current

transfer function in the graphics state for the same component.

This entry shall be present if the dictionary is a component of a

type

5 halftone

(see

“Type

5 Halftones” in

10.5.5.6) and

represents either a nonprimary or nonstandard primary colour

component (see 10.4, "Transfer Functions"). The name Identity

may be used to specify the identity function.

10.5.5.4

Type 10 Halftones

Type 6 halftones specify a threshold array with a zero screen angle; they make no provision for other angles.

The type 10 halftone removes this restriction and allows the use of threshold arrays for halftones with nonzero

screen angles as well.

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 original cell but are much easier to store

and manipulate. In addition, they can be mapped easily into the internal representation used for all rendering.

NOTE 1

Figure 50 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 50 - Halftone cell with a nonzero angle

NOTE 2

Figure 51 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 52). The last row in the first square is immediately adjacent to the first

row in the second square and starts in the same column.

311

X

Y

*

Figure 51 - Angled halftone cell divided into two squares

Y

X

X

a

a

a a

a a

a a a

a a a

a a a a

a a a a

a a a a a

a a a a a

Y

a a a a a a

a a a a

b

b

a a a a a

a a a

b b

b b

a a a a

a a

b b b

b b b

a a a

a

b b b b

b b b b

a a

b b b b b

b b b

* b

Y

a

b b b b b b

b b b b

c

c b b b b b

b b b

X

c c

c c b b b b

b b

c c c

c c c b b b

b

c c c c

c c c c

b b

c c c c c

c c c

b

* c

c c c c c c

c c c c

c c c c c

c c c

c c c c

c c

c c c

c

c c

Y

c

Figure 52 - Halftone cell and two squares tiled across device space

NOTE 3

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 corresponding point in the adjacent cell, such as those

marked by asterisks in Figure 52. 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

frequency

= -----------------------

X²

+

Y²

and the angle by

⎛

⎞

angle

= atan

--

⎝

X⎠

312

Content      ..     6      7      8      9     ..