Part 2 of this series will demonstrate how AFDKO tools can be used to specify multiple FDArray elements (aka, hint dictionaries) when converting name-keyed fonts into CID-keyed ones. The same technique can be used to convert a CID-keyed font with a single FDArray element into one with multiple FDArray elements.

The sample font in Part 1 of this series does not have enough script "richness" to demonstrate this technique, so I crafted a different sample font for demonstration purposes. Again, the technique is easily scalable, and can thus handle thousands or tens of thousands of glyphs.

Someone kindly pointed out that I failed to do one important thing in Part 1 of this series, specifically to enumerate reasons why one would want to convert a name-keyed OpenType font into a CID-keyed one. So, before I begin Part 2 in earnest, I will provide three benefits of CID-keyed fonts:

Up to 256 FDArray elements can be specified, and each can have its own hinting parameters, meaning alignment zones (/BlueValues and /OtherBlues arrays), stem values (/StdHW and /StdVW values, and /StemSnapH and /StemSnapV arrays), and /LanguageGroup setting.Explicit control over the mapping from character codes, such as Unicode, to glyphs is possible through the use of a CMap resource. Name-keyed fonts use glyph names to drive the mapping from character codes to glyphs, which is implicit control.If the glyph set corresponds to an existing CID-keyed character collections, or is a subset thereof, that character collection's resources can be leveraged to ease font development.

The AFDKO mergeFonts tool is used to specify multiple FDArray elements, which is done through the use of multiple mergeFonts mapping files (at a minimum, one per FDArray element) and by specifying the FDArray element name as the argument for the "mergeFonts" text that is the first line of the mergeFonts mapping file. The /LanguageGroup setting can also be specified as a second argument. Click here to download an archive that includes the various files and resources that are referenced in this article, including the original name-keyed Type 1 font (named font.pfa).

Consider the name-keyed Type 1 font, font.pfa, that includes the following 48 glyphs:

.notdef

space

A

B

C

D

E

F

a

b

c

d

e

f

uni3000

uni3001

uni3002

uni3041

uni3041v

uni3042

uni3043

uni3043v

uni3044

uni3045

uni3045v

uni3046

uni30A1

uni30A1v

uni30A2

uni30A3

uni30A3v

uni30A4

uni30A5

uni30A5v

uni30A6

uni30FB

uni4E9C

uni54C0

uni5516

uni5A03

uni611B

uni963F

uniFE10

uniFE11

uniFE12

uniFF0C

uniFF0E

uniFF0Ev

In addition to mapping these glyph names to Adobe-Japan1-6 CIDs, we will also arrange them into five FDArray elements, mainly based on glyph class.

Step 1: Create the mergeFonts Mapping Files

The character coverage of this sample font corresponds rather nicely to the Adobe-Japan1-6 character collection (see Adobe Tech Note #5078), specifically to a tiny subset of the /Supplement 0 portion. After a mapping to Adobe-Japan1-6 CIDs is established, it can be used to construct the following five mergeFonts mapping files, which effectively separate the glyphs into separate FDArray elements based on glyph class, script, or usage:

generic.map:

mergeFonts KozGoAJ10-ExtraLight-Generic 1

0 .notdef

proportional.map:

mergeFonts KozGoAJ10-ExtraLight-Proportional 0

1 space

34 A

35 B

36 C

37 D

38 E

39 F

66 a

67 b

68 c

69 d

70 e

71 f

dingbats.map:

mergeFonts KozGoAJ10-ExtraLight-Dingbats 1

633 uni3000

634 uni3001

635 uni3002

636 uniFF0C

637 uniFF0E

638 uni30FB

7887 uniFE11

7888 uniFE12

8268 uniFE10

8274 uniFF0Ev

kana.map:

mergeFonts KozGoAJ10-ExtraLight-Kana 1

842 uni3041

843 uni3042

844 uni3043

845 uni3044

846 uni3045

847 uni3046

925 uni30A1

926 uni30A2

927 uni30A3

928 uni30A4

929 uni30A5

930 uni30A6

7918 uni3041v

7919 uni3043v

7920 uni3045v

7928 uni30A1v

7929 uni30A3v

7930 uni30A5v

kanji.map:

mergeFonts KozGoAJ10-ExtraLight-Kanji 1

1125 uni4E9C

1126 uni5516

1127 uni5A03

1128 uni963F

1129 uni54C0

1130 uni611B

It is important to note that the argument after the "mergeFonts" text in the first line of each mergeFonts mapping file specifies the name of an FDArray element. Thus, if two different mergeFonts mapping files specify the same argument, the glyphs will share the same FDArray element. Here are the FDArray element names:

KozGoAJ10-ExtraLight-Generic

KozGoAJ10-ExtraLight-Proportional

KozGoAJ10-ExtraLight-Dingbats

KozGoAJ10-ExtraLight-Kana

KozGoAJ10-ExtraLight-Kanji

Step 2: Create the CIDFont Resource

As soon as the mergeFonts mapping files and a "cidfontinfo" file are prepared, the following mergeFonts command line can be executed to produce a CIDFont resource named "cidfont.raw" that has five FDArray elements:

% mergeFonts-cid cidfontinfo cidfont.raw generic.map font.pfa proportional.map font.pfa dingbats.map font.pfa kana.map font.pfa kanji.map font.pfa

The AFDKO tx tool can be used to verify that there are indeed five FDArray elements (shown after "## FontDict[*]" lines), and what their hinting parameters are:

% tx-0 cidfont.raw

## Filename cidfont.1

## Top Dict

Notice "Kozuka Gothic is either a registered trademark or trademark of Adobe Systems Incorporated in the United States and/or other co"

FullName "Kozuka Gothic AJI0 OpenType ExtraLight"

FontBBox {0,-95,964,841}

XUID {1,11,9273858}

cid.CIDFontName "KozGoAJ10-ExtraLight"

cid.Registry "Adobe"

cid.Ordering "Japan1"

cid.Supplement 0

cid.CIDFontVersion 1.000

cid.CIDCount 8275

sup.flags 0x00000001 (ABF_CID_FONT)

sup.srcFontType Type 1 (cid-keyed)

sup.nGlyphs 48

## FontDict[0]

FontName "KozGoAJ10-ExtraLight-Generic"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 50

StdVW 50

LanguageGroup 1

## FontDict[1]

FontName "KozGoAJ10-ExtraLight-Proportional"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 50

StdVW 50

## FontDict[2]

FontName "KozGoAJ10-ExtraLight-Dingbats"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 50

StdVW 50

LanguageGroup 1

## FontDict[3]

FontName "KozGoAJ10-ExtraLight-Kana"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 50

StdVW 50

LanguageGroup 1

## FontDict[4]

FontName "KozGoAJ10-ExtraLight-Kanji"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 50

StdVW 50

LanguageGroup 1

The tx tool can also be used to verify per-CID FDarray element assignment (the "iFD" value) in text form:

% tx-1 cidfont.ps

(removed lines that are the same as when specifying the "-0" option)

## glyph[tag] {cid,iFD,LanguageGroup}

glyph[0] {0,0,1}

glyph[1] {1,1,1}

glyph[2] {34,1,1}

glyph[3] {35,1,1}

glyph[4] {36,1,1}

glyph[5] {37,1,1}

glyph[6] {38,1,1}

glyph[7] {39,1,1}

glyph[8] {66,1,1}

glyph[9] {67,1,1}

glyph[10] {68,1,1}

glyph[11] {69,1,1}

glyph[12] {70,1,1}

glyph[13] {71,1,1}

glyph[14] {633,2,1}

glyph[15] {634,2,1}

glyph[16] {635,2,1}

glyph[17] {636,2,1}

glyph[18] {637,2,1}

glyph[19] {638,2,1}

glyph[20] {842,3,1}

glyph[21] {843,3,1}

glyph[22] {844,3,1}

glyph[23] {845,3,1}

glyph[24] {846,3,1}

glyph[25] {847,3,1}

glyph[26] {925,3,1}

glyph[27] {926,3,1}

glyph[28] {927,3,1}

glyph[29] {928,3,1}

glyph[30] {929,3,1}

glyph[31] {930,3,1}

glyph[32] {1125,4,1}

glyph[33] {1126,4,1}

glyph[34] {1127,4,1}

glyph[35] {1128,4,1}

glyph[36] {1129,4,1}

glyph[37] {1130,4,1}

glyph[38] {7887,2,1}

glyph[39] {7888,2,1}

glyph[40] {7918,3,1}

glyph[41] {7919,3,1}

glyph[42] {7920,3,1}

glyph[43] {7928,3,1}

glyph[44] {7929,3,1}

glyph[45] {7930,3,1}

glyph[46] {8268,2,1}

glyph[47] {8274,2,1}

Step 3: Apply Hinting Parameters

Of course, it doesn't make much sense for multiple FDArray elements to share the same hinting parameters, so after adjusting the hinting parameters to be appropriate values and running the AFDKO autohint tool to apply them, the tx output is different:

% tx-0 cidfont.ps

tx:---cidfont.ps

## Filename cidfont.ps

## Top Dict

Notice "Kozuka Gothic is either a registered trademark or trademark of Adobe Systems Incorporated in the United States and/or other co"

FullName "Kozuka Gothic AJI0 OpenType ExtraLight"

FontBBox {0,-95,964,841}

XUID {1,11,9273858}

cid.CIDFontName "KozGoAJ10-ExtraLight"

cid.Registry "Adobe"

cid.Ordering "Japan1"

cid.Supplement 0

cid.CIDFontVersion 1.000

cid.CIDCount 8275

sup.flags 0x00000001 (ABF_CID_FONT)

sup.srcFontType Type 1 (cid-keyed)

sup.nGlyphs 48

## FontDict[0]

FontName "KozGoAJ10-ExtraLight-Generic"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 50

StdVW 50

LanguageGroup 1

## FontDict[1]

FontName "KozGoAJ10-ExtraLight-Proportional"

## Private

BlueValues {-12,0,536,548,756,767}

OtherBlues {-234,-222}

StdHW 31

StdVW 35

## FontDict[2]

FontName "KozGoAJ10-ExtraLight-Dingbats"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 29

StdVW 29

StemSnapH {12,29}

LanguageGroup 1

## FontDict[3]

FontName "KozGoAJ10-ExtraLight-Kana"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 32

StdVW 32

StemSnapH {17,32}

LanguageGroup 1

## FontDict[4]

FontName "KozGoAJ10-ExtraLight-Kanji"

## Private

BlueValues {-250,-250,1100,1100}

StdHW 30

StdVW 30

StemSnapH {12,30}

LanguageGroup 1

Step 4: Build the OpenType Font

This CIDFont resource declares the Adobe-Japan1-0 ROS, meaning that existing Adobe-Japan1-6 resources, such as the "UniJIS-UTF32-H" or "UniJIS2004-UTF32-H" CMap resources for building the 'cmap' table, and 'GSUB' features, can be leveraged. This simplifies development, because these resources can be used, either as-is (CMap resources) or in modified form ('GSUB' features). The "FontMenuNameDB" and "features" files still need to be created. The following AFDKO makeotf command line will produce a fully-functional OpenType font:

% makeotf-f cidfont.ps-r

Please stay tuned for Part 3 in this series…