As mentioned at the end of the May 15, 2012 CJK Type Blog article, I will demonstrate in this article how to build a CID-keyed font with 64K glyphs (CIDs 0 through 65534)and256 FDArray elements. These represent two limits that are inherent in CIDFont resources.

Again, the incredibly powerful AFDKO mergeFonts tool will perform most of the work.

The same name-keyed Type 1 font will be used, along with the same cidfontinfo file, provided below for convenience:

FontName (UnicodeP01)

FullName (Unicode P01)

FamilyName (Unicode P01)

Weight (Regular)

version (1.000)

Registry (Adobe)

Ordering (Identity)

Supplement 0

XUID [1 11 9273868]

AdobeCopyright (Copyright 2012 Adobe Systems Incorporated. All Rights Reserved.)

Trademark ()

FSType 8

isFixedPitch true

Serif false

IsBoldStyle false

IsItalicStyle false

Because there will be 256 FDArray elements, 256 mergeFonts mapping files will be required. But, before we worry about building the 256 mergeFonts mapping files, we need to build a name-keyed font that includes 257 glyphs. We do this by using mergeFonts to build a name-keyed fonts with 257 glyphs, the first of which is the required .notdef glyph, along with 256 instances of the same glyph, named P_zero_one. Of course, a mergeFonts mapping file is required, which I named font.map. The following command line produces a name-keyed font, named font-new.pfa, that contains the 257 glyphs:

% mergeFontsfont-new.pfa font.map font.pfa

With this 257-glyph name-keyed font, font-new.pfa, whose glyphs are named .notdef and cid1 through cid256, we are now ready to build the CID-keyed font.

To aid in the creation of the mergeFonts mapping files, I wrote a short Perl script, named mk64k256fdarray.pl, that performs the following operations:

Generates 256 mergeFonts mapping files, one for each FDArray element.Names each of the FDArray elements according to the FontName as specified in the cidfontinfo file, followed by an integer value from 0 to 255. This is done by specifying this string as the argument of "mergeFonts" that is the first line of each mergeFonts mapping file.Generates, as STDOUT, a shell script that executes three mergeFonts command lines.

It would be appropriate to ask why three mergeFonts command lines are necessary. The reason is simply because the current version of mergeFonts cannot handle 256 FDArray elements at once, so two mergeFonts command lines are used to build two interim CIDFont resources, each with 128 FDArray elements. The third mergeFonts command line combines the two interim CIDFont resources into a single one with 256 FDArray elements. The only duplicate CID in the two interim CIDFont resources is CID+0, which is mandatory.

Below are the two command lines, the second of which executes the shell script that was generated by the first one:

% mk64k256fdarray.plUnicodeP01>cidbuild.sh

% sh ./cidbuild.sh

Note that the command-line argument, UnicodeP01, is a string that is used as part of the names for the FDArray elements. The result will be a CIDFont resource named cidfont.ps that includes 64K glyphs arranged in 256 FDArray elements. The interim CIDFont resources with 128 FDArray elements, named cidfont.1 and cidfont.2, can be removed.

If you carefully examine the Perl script, mk64k256fdarray.pl, you will note that it special-cases the following three FDArray elements:

0: The mandatory .notdef glyph is added to the corresponding mergeFonts mapping file, which serves as CID+0 in the first interim CIDFont resource, cidfont.1.127: A new mergeFonts command line begins, for FDArray elements 128 through 255. And, the mandatory .notdef glyph is once again added to the corresponding mergeFonts mapping file, which serves as CID+0 in the second interim CIDFont resource, cidfont.2.255: Because the maximum CID is 65534, the last FDArray element, which includes the number 255 in its name, must include only 254 glyphs, not 256. The end range of the foreach loop is adjusted accordingly.

This article should have demonstrated that the assignment of CIDs to FDArray elements can be easily controlled by carefully constructing mergeFonts mapping files, and that the entire process can be scripted, in whatever scripting language you prefer, whether it is awk, Perl, Python, or Ruby.

Stay tuned until next week, when I will demonstrate how to use this CID-keyed font to build a fully-functional OpenType/CFF font.