Leveraging AFDKO Tools to Convert Name-keyed OpenType Fonts to CID-keyed — Part 2

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:

  1. 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.
  2. 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.
  3. 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…

Comments are closed.