pdf viewer control in asp net c# : Add photo pdf control application platform web page html winforms web browser PDF32000_200827-part2344

© 
Adobe Systems Incorporated 2008 – All rights reserved
263
PDF 32000-1:2008
NOTE
This flexibility in character encoding is valuable for two reasons: 
It permits showing text that is encoded according to any of the various existing conventions. For example, the 
Microsoft Windows and Apple Mac OS operating systems use different standard encodings for Latin text, and 
many conforming writers use their own special-purpose encodings. 
It permits conforming writers to specify how characters selected from a large character set are to be encoded. 
Some character sets consist of more than 256 characters, including ligatures, accented characters, and other 
symbols  required  for  high-quality  typography  or  non-Latin  writing  systems.  Different  encodings  may  select 
different subsets of the same character set. 
One commonly used font encoding for Latin-text font programs is often referred to as StandardEncoding or 
sometimes as the Adobe standard encoding. The name StandardEncoding shall have no special meaning in 
PDF, but this encoding does play a role as a default encoding (as shown in Table 114). The regular encodings 
used  for  Latin-text  fonts  on  Mac  OS  and  Windows  systems  shall  be  named MacRomanEncoding  and 
WinAnsiEncoding, respectively. An encoding named MacExpertEncoding may be used with “expert” fonts 
that contain additional characters useful for sophisticated typography. Complete details of these encodings and 
of the characters present in typical fonts are provided in Annex D. 
In  PDF, a  font is classified as  either nonsymbolic  or symbolic according to  whether all of its  characters are 
members of the standard  Latin character set; see D.2,  “Latin Character  Set and  Encodings”.  This  shall  be 
indicated  by  flags  in  the  font  descriptor;  see  9.8.2,  "Font  Descriptor  Flags".  Symbolic  fonts  contain  other 
character sets, to which the encodings mentioned previously ordinarily do not apply. Such font programs have 
built-in  encodings  that  are  usually  unique  to  each  font.  The  standard  14  fonts  include  two  symbolic  fonts, 
Symbol and ZapfDingbats, whose encodings and character sets are documented in Annex D. 
 font  program’s  built-in  encoding  may  be  overridden  by  including  an Encoding  entry  in  the  PDF  font 
dictionary. The possible encoding modifications depend on the font type. The value of the Encoding entry shall 
be  either  a  named  encoding  (the  name  of  one  of  the  predefined  encodings MacRomanEncoding, 
MacExpertEncoding, or WinAnsiEncoding) or an encoding dictionary. An encoding dictionary contains the 
entries listed in Table 114.
The value of the Differences entry shall be an array of character codes and character names organized as 
follows: 
code
1
name
1,1
name
1,2
Table 114 –  Entries in an encoding dictionary  
Key
Type
Value
Type
name
(Optional) The type of PDF object that this dictionary describes; if 
present, shall be Encoding for an encoding dictionary. 
BaseEncoding
name
(Optional) The  base  encoding—that is, the encoding from which the 
Differences entry (if present) describes differences— shall be the name 
of  one  of  the  predefined  encodings MacRomanEncoding, 
MacExpertEncoding, or WinAnsiEncoding (see Annex D). 
If this entry is absent, the Differences entry shall  describe differences 
from an implicit base encoding. For a font program that is embedded in 
the PDF file, the implicit base encoding shall be the font program’s built-in 
encoding,  as  described  in  9.6.6,  "Character  Encoding"  and  further 
elaborated  in  the sub-clauses  on specific  font  types.  Otherwise,  for  a 
nonsymbolic font, it shall be StandardEncoding, and for a symbolic font, 
it shall be the font’s built-in encoding. 
Differences
array
(Optional; should not be used with TrueType fonts) An array describing 
the  differences  from  the  encoding  specified  by BaseEncoding  or,  if 
BaseEncoding is absent, from an implicit base encoding. The 
Differences array is described in subsequent sub-clauses. 
Add photo pdf - insert images into PDF in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Sample C# code to add image, picture, logo or digital photo into PDF document page using PDF page editor control
add jpg to pdf preview; adding jpg to pdf
Add photo pdf - VB.NET PDF insert image library: insert images into PDF in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Guide VB.NET Programmers How to Add Images in PDF Document
add jpeg signature to pdf; add an image to a pdf acrobat
PDF 32000-1:2008
264
© 
Adobe Systems Incorporated 2008 – All rights reserved
code
2
name
2,1
name
2,2
code
n
name
n,1
name
n,2
Each code shall be the first index in a sequence of character codes to be changed. The first character name 
after the code becomes the name corresponding to that code. Subsequent names replace consecutive code 
indices until the next code appears in the array or the array ends. These sequences may be specified in any 
order but shall not overlap. 
EXAMPLE
In the encoding dictionary in this example, the name quotesingle ( ' ) is associated with character code 39, 
Adieresis (Ä) with code 128, Aring (Å) with 129, and trademark (™) with 170. 
25  0  obj
<<   /Type  /Encoding
/Differences
  39  /quotesingle
96  /grave
128  /Adieresis  /Aring  /Ccedilla  /Eacute  /Ntilde  /Odieresis  /Udieresis
/aacute  /agrave  /acircumflex  /adieresis  /atilde  /aring  /ccedilla
/eacute  /egrave  /ecircumflex  /edieresis  /iacute  /igrave  /icircumflex
/idieresis  /ntilde  /oacute  /ograve  /ocircumflex  /odieresis  /otilde
/uacute  /ugrave  /ucircumflex  /udieresis  /dagger  /degree  /cent
/sterling  /section  /bullet  /paragraph  /germandbls  /registered
/copyright  /trademark  /acute  /dieresis
174  /AE  /Oslash
177  /plusminus
180  /yen  /mu
187  /ordfeminine  /ordmasculine
190  /ae  /oslash  /questiondown  /exclamdown  /logicalnot
196  /florin
199  /guillemotleft  /guillemotright  /ellipsis
203  /Agrave  /Atilde  /Otilde  /OE  /oe  /endash  /emdash  /quotedblleft
/quotedblright  /quoteleft  /quoteright  /divide
216  /ydieresis  /Ydieresis  /fraction  /currency  /guilsinglleft  /guilsinglright
/fi  /fl  /daggerdbl   /periodcentered  /quotesinglbase  /quotedblbase
/perthousand  /Acircumflex  /Ecircumflex  /Aacute  /Edieresis  /Egrave
/Iacute  /Icircumflex  /Idieresis  /Igrave  /Oacute  /Ocircumflex
241  /Ograve  /Uacute  /Ucircumflex  /Ugrave  /dotlessi  /circumflex  /tilde
/macron  /breve  /dotaccent   /ring  /cedilla  /hungarumlaut  /ogonek
/caron
>>
endobj
9.6.6.2
Encodings for Type 1 Fonts
A Type 1 font program’s glyph descriptions are keyed by glyph names, not by character codes. Glyph names 
are  ordinary  PDF  name  objects.  Descriptions  of  Latin  alphabetic  characters  are  normally  associated  with 
names consisting of single letters, such as A or a. Other characters are associated with names composed of 
words,  such  as  three,  ampersand,  or  parenleft.  A  Type  1  font’s  built-in  encoding  shall  be  defined  by  an 
Encoding array that is part of the font program, not to be confused with the Encoding entry in the PDF font 
dictionary. 
An Encoding  entry  may  override  a  Type  1  font’s  mapping from  character  codes  to character  names.  The 
Differences array may map a code to the name of any glyph description that exists in the font program, 
regardless of whether that glyph is referenced by the font’s built-in encoding or by the encoding specified in the 
BaseEncoding entry. 
VB.NET Image: Mark Photo, Image & Document with Polygon Annotation
What's more, if coupled with .NET PDF document imaging add-on, the VB.NET annotator SDK can easily generate polygon annotation on PDF file without using
adding a png to a pdf; add image to pdf java
VB.NET Image: Image Cropping SDK to Cut Out Image, Picture and
VB.NET image cropper control SDK; VB.NET image cropping method to crop picture / photo; you can adjust the size of created cropped image file, add antique effect
adding an image to a pdf file; add jpg to pdf file
© 
Adobe Systems Incorporated 2008 – All rights reserved
265
PDF 32000-1:2008
All  Type  1 font programs shall contain an actual glyph named . notdef. The effect  produced  by showing the 
. notdef glyph is at the discretion of the font designer. If an encoding maps to a character name that does not 
exist in the Type 1 font program, the . notdef glyph shall be substituted. 
9.6.6.3 Encodings for Type 3 Fonts
A Type 3 font, like a Type 1 font, contains glyph descriptions that are keyed by glyph names; in this case, they 
appear as explicit keys in the font’s CharProcs dictionary. A Type 3 font’s mapping from character codes to 
glyph names shall be entirely defined by its Encoding entry, which is required in this case. 
9.6.6.4 Encodings for TrueType Fonts
A TrueType font program’s built-in encoding maps directly from character codes to glyph descriptions by means 
of an internal data structure called a “cmap” (not to be confused with the CMap described in 9.7.5, "CMaps"). 
This sub-clause describes how the PDF font dictionary’s Encoding entry shall be used in conjunction with a 
“cmap” to map from a character code in a string to a glyph description in a TrueType font program.
A  “cmap” table  may  contain  one  or more  subtables that represent  multiple encodings  intended  for use  on 
different platforms (such as Mac OS and Windows). Each subtable shall be identified by the two numbers, such 
as (3, 1), that represent a combination of a platform ID and a platform-specific encoding ID , respectively. 
Glyph names are not required in TrueType fonts, although some font programs have an optional “post” table 
listing glyph  names  for the glyphs.  If  the conforming  reader  needs to select  glyph  descriptions  by name,  it 
translates from glyph names to codes in one of the encodings given in the font program’s “cmap” table. When 
there is no character code in the “cmap” that corresponds to a glyph name, the “post” table shall be used to 
select a glyph description directly from the glyph name.
Because some aspects of TrueType glyph selection are dependent on the conforming reader or the operating 
system,  PDF files that use TrueType fonts  should follow certain guidelines  to ensure  predictable behaviour 
across all conforming readers:
The font program should be embedded. 
 nonsymbolic  font  should  specify MacRomanEncoding  or WinAnsiEncoding  as  the  value  of  its 
Encoding entry, with no Differences array. 
A font that is used to display glyphs that do not use MacRomanEncoding or WinAnsiEncoding should 
not specify an Encoding entry. The font descriptor’s Symbolic flag (see Table 123) should be set, and its 
font  program’s  “cmap”  table  should  contain  a  (1, 0)  subtable.  It  may  also  contain  a  (3, 0)  subtable;  if 
present, this subtable should map from character codes in the range 0xF000 to 0xF0FF by prepending the 
single-byte codes in the (1, 0) subtable with 0xF0 and mapping to the corresponding glyph descriptions.
NOTE 1
Some popular TrueType font programs contain incorrect encoding information. Implementations of TrueType 
font interpreters have evolved heuristics for dealing with such problems; those heuristics are not described 
here.  For  maximum  portability,  only  well-formed  TrueType  font  programs  should  be  used  in  PDF  files. 
Therefore, a TrueType font program in a PDF file may need to be modified to conform to these guidelines.
The following paragraphs describe the treatment of TrueType font encodings beginning with PDF 1.3.
If the font has a named Encoding entry of either MacRomanEncoding or WinAnsiEncoding, or if the font 
descriptor’s Nonsymbolic flag (see Table 123) is set, the conforming reader shall create a table that maps from 
character codes to glyph names:
If the Encoding entry is one of the names MacRomanEncoding or WinAnsiEncoding, the table shall be 
initialized with the mappings described in Annex D. 
VB.NET Image: Image Scaling SDK to Scale Picture / Photo
To help you know more about this VB.NET image scaling control add-on, we scaling control SDK API, developer can only scale one image / picture / photo at a
add photo pdf; add an image to a pdf with acrobat
C# Image: How to Add Antique & Vintage Effect to Image, Photo
this C#.NET antique effect creating control add-on is widely used in modern photo editors, which powerful & profession imaging controls, PDF document, tiff
add png to pdf acrobat; add picture to pdf in preview
PDF 32000-1:2008
266
© 
Adobe Systems Incorporated 2008 – All rights reserved
If  the Encoding entry is a dictionary, the table  shall be  initialized with the entries  from  the  dictionary’s 
BaseEncoding entry (see Table 114). Any entries in the Differences array shall be used to update the 
table. Finally, any undefined entries in the table shall be filled using StandardEncoding.
If a (3, 1) “cmap” subtable (Microsoft Unicode) is present:
A character code shall be first mapped to a glyph name using the table described above. 
The glyph name shall then be mapped to a Unicode value by consulting the Adobe Glyph List (see the 
Bibliography). 
Finally, the Unicode value shall be mapped to a glyph description according to the (3, 1) subtable. 
If no (3, 1) subtable is present but a (1, 0) subtable (Macintosh Roman) is present:
A character code shall be first mapped to a glyph name using the table described above. 
The  glyph  name  shall  then  be  mapped  back  to  a  character  code  according  to  the  standard  Roman 
encoding used on Mac OS. 
Finally, the code shall be mapped to a glyph description according to the (1, 0) subtable.
In any of these cases, if the glyph name cannot be mapped as specified, the glyph name shall be looked up in 
the font program’s “post” table (if one is present) and the associated glyph description shall be used. 
The standard Roman encoding that is used on Mac OS is the same as the MacRomanEncoding described in 
Annex D, with the addition of 15 entries and the replacement of the currency glyph with  the Euro  glyph, as 
shown in Table 115.
Table 115 –  Differences between MacRomanEncoding and Mac OS Roman encoding  
Name
Code (Octal)
Code (DEcimal)
notequal
255
173
infinity
260
176
lessequal
262
178
greaterequal
263
179
partialdiff
266
182
summation
267
183
product
270
184
pi
271
185
integral
272
186
Omega
275
189
radical
303
195
approxequal
305
197
Delta
306
198
lozenge
327
215
Euro
333
219
apple
360
240
VB.NET Image: Image Resizer Control SDK to Resize Picture & Photo
VB.NET Image & Photo Resizing Overview. The practical this VB.NET image resizer control add-on, can powerful & profession imaging controls, PDF document, image
how to add picture to pdf; add picture to pdf reader
VB.NET Image: How to Save Image & Print Image Using VB.NET
NET programmers save & print image / photo / picture from NET method and demo code to add image printing printing multi-page document files, like PDF and Word
how to add image to pdf; add image to pdf
© 
Adobe Systems Incorporated 2008 – All rights reserved
267
PDF 32000-1:2008
When the font has no Encoding entry, or the font descriptor’s Symbolic flag is set (in which case the Encoding
entry is ignored), this shall occur: 
If the font contains a (3, 0) subtable, the range of character codes shall be one of these: 0x0000 - 0x00FF, 
0xF000 - 0xF0FF, 0xF100 - 0xF1FF,  or  0xF200 - 0xF2FF. Depending on  the range  of  codes,  each byte 
from the string shall be prepended with the high byte of the range, to form a two-byte character, which shall 
be used to select the associated glyph description from the subtable.
Otherwise, if the font contains a (1, 0) subtable, single bytes from the string shall be used to look up the 
associated glyph descriptions from the subtable.
If a character cannot be mapped in any of the ways described previously, a conforming reader may supply a 
mapping of its choosing. 
9.7 Composite Fonts
9.7.1
General
composite font, also called a Type 0 font, is one whose glyphs are obtained from a fontlike object called a 
CIDFont. A composite font shall be represented by a font dictionary whose Subtype value is Type0. The Type 
0 font is known as the root font, and its associated CIDFont is called its descendant. 
NOTE 1
Composite fonts in PDF are analogous to composite fonts in PostScript but with some limitations. In particular, 
PDF  requires  that the character  encoding be  defined  by  a CMap,  which is only  one of  several  encoding 
methods available in PostScript. Also, PostScript allows a Type 0 font to have multiple descendants, which 
might also be Type 0 fonts. PDF supports only a single descendant, which shall be a CIDFont.
When the current font is composite, the text-showing operators shall behave differently than with simple fonts. 
For simple fonts, each byte of a string to be shown selects one glyph, whereas for composite fonts, a sequence 
of one or more bytes are decoded to select a glyph from the descendant CIDFont. 
NOTE 2
This facility supports the use  of very  large  character sets, such as those for  the Chinese, Japanese, and 
Korean languages. It also simplifies the organization of fonts that have complex encoding requirements. 
This sub-clause first introduces the architecture of CID-keyed fonts , which are the only kind of composite font 
supported  in  PDF.  Then  it  describes  the CIDFont  and CMap  dictionaries,  which  are  the  PDF  objects  that 
represent the correspondingly named components  of a  CID-keyed font. Finally,  it  describes the  Type 0 font 
dictionary, which combines a CIDFont and a CMap to produce a font whose glyphs may be accessed by means 
of variable-length character codes in a string to be shown. 
9.7.2
CID-Keyed Fonts Overview
CID-keyed fonts provide a convenient and efficient method for defining multiple-byte character encodings and 
fonts with a large number of glyphs. These capabilities provide great flexibility for representing text in writing 
systems for languages with large character sets, such as Chinese, Japanese, and Korean (CJK). 
The CID-keyed font architecture specifies  the external representation of certain font programs, called CMap
and CIDFont files, along with some conventions for combining and using those files. As mentioned earlier, PDF 
does not support the entire CID-keyed font architecture, which is independent of PDF; CID-keyed fonts may be 
used in other environments. 
NOTE
For complete documentation on the architecture and the file formats, see Adobe Technical Notes #5092, CID-
Keyed Font Technology Overview, and #5014, Adobe CMap and CIDFont Files Specification. This sub-clause 
describes only the PDF objects that represent these font programs. 
The term CID-keyed font reflects the fact that CID (character identifier) numbers are used to index and access 
the glyph descriptions in the font. This method is more efficient for large fonts than the method of accessing by 
character name, as is used for some simple fonts. CIDs range from 0 to a maximum value that may be subject 
to an implementation limit (see Table C.1). 
VB.NET Image: Tutorial for Flipping Image Using Our .NET Image SDK
version of .NET imaging SDK and add the following becomes a mirror reflection of the photo on the powerful & profession imaging controls, PDF document, tiff
add image to pdf reader; add image to pdf in preview
C# PDF remove image library: remove, delete images from PDF in C#.
Support removing vector image, graphic picture, digital photo, scanned signature, logo, etc. Remove Image from PDF Page Using C#. Add necessary references:
add a picture to a pdf document; how to add photo to pdf in preview
PDF 32000-1:2008
268
© 
Adobe Systems Incorporated 2008 – All rights reserved
character collection  is  an ordered set  of glyphs. The  order of  the  glyphs  in  the  character  collection  shall 
determine  the  CID  number  for  each  glyph.  Each  CID-keyed  font  shall  explicitly  reference  the  character 
collection on which its CID numbers are based; see 9.7.3, "CIDSystemInfo Dictionaries". 
CMap (character map) file shall specify the correspondence between character codes and the CID numbers 
used to identify glyphs. It is equivalent to the concept of an encoding in simple fonts. Whereas a simple font 
allows a maximum of 256 glyphs to be encoded and accessible at one time, a CMap can describe a mapping 
from multiple-byte codes to thousands of glyphs in a large CID-keyed font. 
EXAMPLE
A CMap can describe Shift-JIS, one of several widely used encodings for Japanese. 
A CMap file may reference an entire character collection or a subset of a character collection. The CMap file’s 
mapping yields a font number (which in PDF shall be 0) and a character selector (which in PDF shall be a CID). 
Furthermore, a CMap file may incorporate another CMap file by reference, without having to duplicate it. These 
features enable character collections to be combined or supplemented and make all the constituent characters 
accessible to text-showing operations through a single encoding. 
CIDFont contains the glyph descriptions for a character collection. The glyph descriptions themselves are 
typically in a format similar to those used in simple fonts, such as Type 1. However, they are identified by CIDs 
rather than by names, and they are organized differently. 
In PDF, the data from a CMap file and CIDFont shall be represented by PDF objects as described in 9.7.4, 
"CIDFonts" and 9.7.5, "CMaps". The CMap file and CIDFont programs themselves may be either referenced by 
name or embedded as stream objects in the PDF file. 
A CID-keyed font, then, shall be the combination of a CMap with a CIDFont containing glyph descriptions. It 
shall be represented as a Type 0 font. It contains an Encoding entry whose value shall be a CMap dictionary, 
and  its DescendantFonts   entry  shall  reference  the  CIDFont  dictionary  with  which  the  CMap  has  been 
combined. 
9.7.3
CIDSystemInfo Dictionaries
CIDFont  and  CMap  dictionaries  shall  contain  a CIDSystemInfo  entry  specifying  the  character  collection 
assumed by the CIDFont associated with the CMap—that is, the interpretation of the CID numbers used by the 
CIDFont.  A  character  collection  shall  be  uniquely  identified  by  the Registry, Ordering,  and Supplement
entries in the CIDSystemInfo dictionary, as described in Table 116. In order to be compatible, the Registry and 
Ordering values must be the same.
The CIDSystemInfo entry in a CIDFont is a dictionary that shall specify the CIDFont’s character collection. The 
CIDFont  need  not  contain  glyph descriptions  for  all  the  CIDs  in  a  collection;  it  may  contain a  subset. The 
CIDSystemInfo entry in a CMap file shall be either a single dictionary or an array of dictionaries, depending on 
whether it associates codes with a single character collection or with multiple character collections; see 9.7.5, 
"CMaps". 
For proper behaviour, the CIDSystemInfo  entry  of a  CMap shall be compatible  with  that of  the CIDFont or 
CIDFonts with which it is used. 
Table 116 –  Entries in a CIDSystemInfo dictionary  
Key
Type
Value
Registry
ASCII 
string
(Required) A string identifying the issuer of the character collection. For 
information  about  assigning  a  registry  identifier,  contact  the  Adobe 
Solutions Network or consult the ASN Web site (see the Bibliography). 
© 
Adobe Systems Incorporated 2008 – All rights reserved
269
PDF 32000-1:2008
9.7.4
CIDFonts
9.7.4.1 General
A CIDFont program contains glyph descriptions that are accessed using a CID as the character selector. There 
are two types of CIDFonts:
A Type 0 CIDFont contains glyph descriptions based on CFF
NOTE
The term “Type 0” when applied to a CIDFont has a different meaning than for a “Type 0 font”.
A Type 2 CIDFont contains glyph descriptions based on the TrueType font format
A CIDFont dictionary is a PDF object that contains information about a CIDFont program. Although its Type
value is Font, a CIDFont is not actually a font. It does not have an Encoding entry, it may not be listed in the 
Font subdictionary of a resource dictionary, and it may not be used as the operand of the Tf operator. It shall be 
used only as a descendant of a Type 0 font. The CMap in the Type 0 font shall be what defines the encoding 
that maps character codes to CIDs in the CIDFont. Table 117 lists the entries in a CIDFont dictionary. 
Ordering
ASCII 
string
(Required) A string that uniquely names the character collection within the 
specified registry.
Supplement
integer
(Required) The supplement number of the character collection. An original 
character collection has a supplement number of 0. Whenever additional 
CIDs are assigned in a character collection, the supplement number shall 
be increased. Supplements shall not alter the ordering of existing CIDs in 
the  character  collection.  This  value  shall  not  be  used  in  determining 
compatibility between character collections. 
Table 117 –  Entries in a CIDFont dictionary  
Key
Type
Value
Type
name
(Required) The type of PDF object that this dictionary describes; 
shall be Font for a CIDFont dictionary. 
Subtype
name
(Required) The type of CIDFont shall be CIDFontType0 or 
CIDFontType2
BaseFont
name
(Required) The PostScript name of the CIDFont. For Type 0 
CIDFonts, this shall be the value of the CIDFontName entry in the 
CIDFont program. For Type 2 CIDFonts, it shall be derived the same 
way as for a simple TrueType font; see 9.6.3, "TrueType Fonts". In 
either case, the name may have a subset prefix if appropriate; see 
9.6.4, "Font Subsets". 
CIDSystemInfo
dictionary
(Required) A dictionary containing entries that define the character 
collection of the CIDFont. See Table 116. 
FontDescriptor
dictionary
(Required; shall be an indirect reference) A font descriptor describing 
the CIDFont’s  default metrics other than its glyph widths (see  9.8, 
"Font Descriptors"). 
DW
integer
(Optional) The default width for glyphs in the CIDFont (see 9.7.4.3, 
"Glyph Metrics in CIDFonts"). Default value: 1000 (defined in user 
units). 
Table 116 –  Entries in a CIDSystemInfo dictionary  (continued)
Key
Type
Value
PDF 32000-1:2008
270
© 
Adobe Systems Incorporated 2008 – All rights reserved
9.7.4.2
Glyph Selection in CIDFonts
Type 0 and Type 2 CIDFonts handle the mapping from CIDs to glyph descriptions in somewhat different ways. 
For Type 0, the CIDFont program contains glyph descriptions that are identified by CIDs. The CIDFont program 
identifies  the  character  collection  by  a CIDSystemInfo  dictionary,  which  should  be  copied  into  the  PDF 
CIDFont dictionary. CIDs shall be interpreted uniformly in all CIDFont programs supporting a given character 
collection, whether the program is embedded in the PDF file or obtained from an external source. 
When the CIDFont contains an embedded font program that is represented in the Compact Font Format (CFF), 
the FontFile3 entry in the font descriptor (see Table 126) may be CIDFontType0C or OpenType. There are 
two cases, depending on the contents of the font program:
The  “CFF”  font  program  has  a  Top  DICT  that  uses  CIDFont  operators:  The  CIDs  shall  be  used  to 
determine the GID value for  the glyph procedure using the charset table in the CFF program. The GID 
value shall then be used to look up the glyph procedure using the CharStrings INDEX table. 
NOTE
Although in many fonts the CID value and GID value are the same, the CID and GID values may differ. 
The “CFF” font program has a Top DICT that does not use CIDFont operators: The CIDs shall be used 
directly as GID values, and the glyph procedure shall be retrieved using the CharStrings INDEX.
For Type 2, the CIDFont program is actually a TrueType font program, which has no native notion of CIDs. In a 
TrueType font program, glyph descriptions are identified by glyph index values. Glyph indices are internal to the 
font and are not defined consistently  from one font to another. Instead, a TrueType font program contains a 
“cmap” table that provides mappings directly from character codes to glyph indices for one or more predefined 
encodings. 
W
array
(Optional) A description of the widths for the glyphs in the CIDFont. 
NOTE
The array’s elements have  a  variable format that  can 
specify  individual  widths  for consecutive CIDs  or  one 
width for a range of CIDs (see 9.7.4.3, "Glyph Metrics in 
CIDFonts"). 
Default value: none (the DW  value shall be used for all glyphs). 
DW2
array
(Optional; applies only to CIDFonts used for vertical writing) An array 
of two numbers specifying the default metrics for vertical writing (see 
9.7.4.3, "Glyph Metrics in CIDFonts"). Default value: [ 880 
1000 ]. 
W2
array
(Optional;  applies  only  to  CIDFonts  used  for  vertical  writing) A 
description  of  the  metrics for  vertical  writing  for  the  glyphs in the 
CIDFont (see 9.7.4.3, "Glyph Metrics  in CIDFonts"). Default value: 
none (the DW2 value shall be used for all glyphs). 
CIDToGIDMap
stream 
or name
(Optional; Type 2 CIDFonts only) A specification of the mapping from 
CIDs to glyph indices. If the value is a stream, the bytes in the stream 
shall contain the mapping from CIDs to glyph indices: the glyph index 
for a particular CID value c shall be a 2-byte value stored in bytes 
×
c and 2 
×
c 
+
1, where the first byte shall be the high-order byte. 
If  the  value  of CIDToGIDMap  is  a  name,  it  shall  be Identity , 
indicating that the mapping between CIDs and glyph indices is the 
identity mapping. Default value: Identity. 
This entry may appear only in a Type 2 CIDFont whose associated 
TrueType font program is embedded in the PDF file. 
Table 117 –  Entries in a CIDFont dictionary  (continued)
Key
Type
Value
© 
Adobe Systems Incorporated 2008 – All rights reserved
271
PDF 32000-1:2008
TrueType font programs are integrated with the CID-keyed font architecture in one of two ways, depending on 
whether the font program is embedded in the PDF file:
If the TrueType font program is embedded, the Type 2 CIDFont dictionary shall contain a CIDToGIDMap
entry that maps CIDs to the glyph indices for the appropriate glyph descriptions in that font program. 
If the TrueType font program is not embedded but is referenced by name, the Type 2 CIDFont dictionary 
shall not contain a CIDToGIDMap entry, since it is not meaningful to refer to glyph indices in an external 
font program. In this case, CIDs shall not participate in glyph selection, and only predefined CMaps may be 
used  with this  CIDFont  (see 9.7.5, "CMaps").  The  conforming  reader  shall  select glyphs by  translating 
characters from the encoding specified by the predefined CMap to one of the encodings in the TrueType 
font’s “cmap” table. The means by which this is accomplished are implementation-dependent. 
Even  though  the  CIDs  are  not  used  to  select  glyphs  in  a  Type  2  CIDFont,  they  shall  always  be  used  to 
determine the glyph metrics, as described in the next sub-clause. 
Every CIDFont shall contain a glyph description for CID 0, which is analogous to the . notdef character name in 
simple fonts (see 9.7.6.3, "Handling Undefined Characters"). 
9.7.4.3 Glyph Metrics in CIDFonts
As  discussed  in  9.2.4,  "Glyph  Positioning  and  Metrics",  the width  of  a  glyph  refers  to  the  horizontal 
displacement between the origin of the glyph and the origin of the next glyph when writing in horizontal mode. 
In this mode, the vertical displacement between origins shall be 0. Widths for a CIDFont are defined using the 
DW and W entries in the CIDFont dictionary. These widths shall be consistent with the actual widths given in 
the CIDFont program.
The W array allows the definition of widths for individual CIDs. The elements of the array shall be organized in 
groups of two or three, where each group shall be in one of these two formats: 
c [ w
1
w
2
… w
n
]
c
first
c
last
w
In the first format, c shall be an integer specifying a starting CID value; it shall be followed by an array of n
numbers that shall specify the widths for n consecutive CIDs, starting with c. The second format shall define the 
same width, w, for all CIDs in the range cfirst to clast . 
EXAMPLE 1
In this example, the glyphs having CIDs 120, 121, and 122 are 400, 325, and 500 units wide, respectively. 
CIDs in the range 7080 through 8032 all have a width of 1000 units. 
W
entry example: 
/W  [  120  [ 400  325  500 ]
 7080  8032  1000
]
Glyphs from a CIDFont may be shown in vertical writing mode. This is selected by the WMode entry in the 
associated CMap dictionary; see 9.7.5, "CMaps". To be used in this way, the CIDFont shall define the vertical 
displacement for each glyph and the position vector that relates the horizontal and vertical writing origins. 
The default position vector and vertical displacement vector shall be specified by the DW2 entry in the CIDFont 
dictionary. DW2 shall be an array of two values: the vertical component of the position vector v and the vertical 
component  of the  displacement vector w1 (see Figure 40). The horizontal component of the position vector 
shall be half the glyph width, and that o
f the displacement vector shall be 0. 
EXAMPLE 2
If the DW2 entry is 
/ DW2 [ 880 
1000 ]
PDF 32000-1:2008
272
© 
Adobe Systems Incorporated 2008 – All rights reserved
then a glyph’s position vector and vertical displacement vector are 
where w0 is the width (horizontal displacement) for the same glyph. 
NOTE
A negative value for the vertical component places the origin of the next glyph below  the current glyph because 
vertical coordinates in a standard coordinate system increase from bottom to top. 
The W2 array shall define vertical metrics for individual CIDs. The elements of the array shall be organized in 
groups of two or five, where each group shall be in one of these two formats: 
c [ w1
1y
v
1x
v
1y
w1
2y
v
2x
v
2y
… ]
c
first
c
last
w1
1y
v
1x
v
1y
In the first format, c is a starting CID and shall be followed by an array containing numbers interpreted in groups 
of  three. Each group shall consist of  the  vertical component  of the vertical displacement  vector w1 (whose 
horizontal component shall be 0) followed by the horizontal and vertical components for the position vector v. 
Successive  groups shall define  the vertical metrics  for consecutive CIDs starting  with c. The second format 
defines a range of CIDs from cfirst to clast , that shall be followed by three numbers that define the vertical 
metrics for all CIDs in this range.
EXAMPLE 3
This W2 entry defines the vertical displacement vector for the glyph with CID 120 as (0, 
1000) and the 
position vector as (250, 772). It also defines the displacement vector for CIDs in the range 7080 through 
8032 as (0, 
1000) and the position vector as (500, 900).
/W2  [  120  [ 
1000  250  772 ]
7080  8032 
1000  500  900
 ]
9.7.5
CMaps
9.7.5.1
General
A CMap shall specify the mapping from character codes to character selectors. In PDF, the character selectors 
shall be CIDs in a CIDFont (as mentioned earlier, PostScript CMaps can use names or codes as well). A CMap 
serves a function analogous to the Encoding dictionary for a simple font. The CMap shall not refer directly to a 
specific  CIDFont; instead, it shall be combined with it as part of a CID-keyed font,  represented in PDF as a 
Type 0 font dictionary (see 9.7.6, "Type 0 Font Dictionaries"). Within the CMap, the character mappings shall 
refer to the associated CIDFont by font number, which in PDF shall be 0. 
PDF also  uses a  special type of CMap to map  character codes to  Unicode  values (see  9.10.3,  "ToUnicode 
CMaps").
 CMap  shall  specify  the  writing  mode—horizontal  or  vertical—for  any  CIDFont  with  which  the  CMap  is 
combined. The writing mode determines which metrics shall be used when glyphs are painted from that font. 
NOTE
Writing mode is specified as part of the CMap because, in some cases, different shapes are used when writing 
horizontally and vertically. In such cases, the horizontal and vertical variants of a CMap specify different CIDs 
for a given character code.
A CMap shall be specified in one of two ways: 
As a name object identifying a predefined CMap, whose value shall be one of the predefined CMap names 
defined in Table 118.
As a stream object whose contents shall be a CMap file.
v
w0 2
÷
880
(
,
)
=
w1
0 1000
( ,–
)
=
Documents you may be interested
Documents you may be interested