1. A name-keyed Type 1 font that includes at least the .notdef glyph (this will serve as the glyph for CID+0) and another glyph that will be used for CIDs 1 through 65534
2. A cidfontinfo file
3. A mergeFonts mapping file that maps the glyphs in the name-keyed Type 1 font to CIDs 0 through 65534

The name-keyed font includes the following two glyphs: .notdef and P_zero_one (“P01″). As a side note, the extract-names.pl tool, which is a simple wrapper for the AFDKO tx tool, can be used to list the glyphs in a name-keyed font, and is used as follows, with sample output given after the command line (it skips the .notdef glyph in its output):

% extract-names.pl font.pfa
P_zero_one

The cidfontinfo file is below (and can be copied to a file with the same name):

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

The mergeFonts mapping file contains 65,536 lines, the first of which indicates that it is a mergeFonts mapping file, followed by the name of the FDArray element. The second and subsequent lines map glyph names to CIDs. Below is an excerpt:

mergeFonts UnicodeP01-0
0      .notdef
1      P_zero_one
2      P_zero_one
3      P_zero_one
4      P_zero_one
5      P_zero_one
<65,524 lines omitted>
65530  P_zero_one
65531  P_zero_one
65532  P_zero_one
65533  P_zero_one
65534  P_zero_one

The mergeFonts command line, which is used to build the CIDFont resource is as follows:

% mergeFonts -cid cidfontinfo cidfont.ps map.txt font.pfa

That’s it! The result is a CIDFont resource named cidfont.ps that contains 65,535 CIDs (CIDs 0 through 65534). Because there is a name- to CID-keyed conversion, the “-cid” option and a cidfontinfo file is required when using the mergeFonts tool.

The next CJK Type Blog article, which will follow in a day or two, will demonstrate how the same CID-keyed font can be built, but with 256 FDArray elements, which is the maximum for a CIDFont resource. Again, the mergeFonts tool will be used.

The big question that may be on a font developer’s mind is under what circumstances is it appropriate to use the Adobe-Identity-0 ROS?

The answer is surprisingly simple:

If the glyphs correspond to one of the public ROSes—Adobe-CNS1-6, Adobe-GB1-5, Adobe-Japan1-6, or Adobe-Korea1-2—or a subset thereof, then using a public ROS is recommended. It is never a problem to build fonts that include only a subset of the glyphs in a public ROS.

Otherwise, the Adobe-Identity-0 ROS is a better choice.

One advantage of using a public ROS is that existing resources can be leveraged, such as CMap resources, GSUB feature definitions, and so on. When using the Adobe-Identity-0 ROS, these resources must be created. The March 7, 2012 CJK Type Blog article details how to build UTF-32 CMap resources, including an example for the Adobe-Identity-0 ROS.

The UnicodeGetaBMP.otf component font includes 65,534 instances of the same glyph, specifically that of the geta symbol (U+3013 〓 GETA MARK; written 下駄 in Japanese), and maps all 63,486 BMP code points (U+0000 through U+D7FF and U+E000 through U+FFFD) to a unique CID. Below is a screenshot of the glyph for CID+65534:

The UnicodeGetaP01.otf component font also includes 65,534 instances of the same glyph, though to distinguish them from those in the UnicodeGetaBMP.otf component font, they have been rotated 90 degrees. This component font maps all 65,534 Plane 1 code points (U+10000 through U+1FFFD) to a unique CID. Below is a screenshot of the glyph for CID+65534:

The CFR object, UnicodeGetaCFR.cfr, registers itself as a font named UnicodeGetaCFR, and specifies UnicodeGetaBMP.otf and UnicodeGetaP01.otf as its component fonts. Although not necessary for this particular example, the CFR object explicitly uses the <UnicodeCharSet> element to specify the Unicode ranges of each component font.

I plan to develop additional CFR objects that exercise other aspects of ISO/IEC 14496-28:2012, which will be made available in future CJK Type Blog articles.

I am grateful that my esteemed colleague, Miguel Sousa, created special (and private) versions of specific faces of the Adobe Originals Myriad Pro and Minion Pro that included, as alternate glyphs, tabular versions of the following characters: ‘a’ through ‘f’, ‘x’, ‘A’ through ‘G’, ‘U’, ‘V’, ‘X’, and ‘+’. These glyphs were made accessible through the use of the ‘ss03‘ (Stylistic Set 3) GSUB feature. When I set up the Adobe InDesign character styles for character codes, for use in body text and in tables, I was able to specify this particular OpenType feature. I also specified the ‘zero‘ (Slashed Zero) GSUB feature so that all instances of 0 (zero) were slashed to better distinguish them.

In terms of design, Miguel not only needed to make the glyphs tabular, to match the widths of the (default) tabular figures, he also needed to make the uppercase height match that of the figures.

Below is an excerpt from the book, specifically Table 4-3 that appears on page 198 in Chapter 4 (Encoding Method), which shows the tabular Myriad Pro glyphs being used:

Below is another excerpt from the book, from page xxviii of the Preface, which shows the tabular Minion Pro glyphs being used:

I continue to use these private versions of Myriad Pro and Minion Pro for other document-writing purposes.

In my experience, there are three important words to embrace: Never Say Never.

While perusing IWATA Corporations’s website, I came across the page about their extension to Kyodo News’ U-PRESS character set, which included a convenient PDF. I checked all of the characters, mainly to establish as many mappings to Adobe-Japan1-6 as possible, and found that 8 of the kanji were not in Unicode, and this effort involved checking the latest version of Extension E (aka IRG N1830), which is soon to become standardized. The image below highlights in yellow the 8 kanji that are not yet in Unicode:

What this demonstrates is simply that CJK Unified Ideographs are genuinely an open-ended script, and that there is always a possibility that new characters will be coined or discovered.

Click ☞ here ☜ to get the PDF version of the Kazuraki poster.

Enjoy! And for those in Japan, have a safe and enjoyable Golden Week!

The right-side navigation bar of this blog’s landing page includes links to relevant documentation and resource pages, such as for font-related Adobe Technical Notes, the OpenType Specification (hosted on Microsoft’s website), and even AFDKO (Adobe Font Development Kit for OpenType). Also, don’t forget about the excellent font developer resources offered by Apple (Fonts), FontLab, and Microsoft (Microsoft Typography).

The tx tool is best thought of as a multi-purpose font-file–manipulation tool. For those who don’t leverage this tool in the font development activities, I strongly encourage you to explore its capabilities, which is best done by perusing its built-in help and through experimentation.

Executing this tool using the “-u” or “-h” command-line options provides basic help and usage information, but specifying the “-h” command-line option after a command-line option that invokes a particular mode, such as “-t1″ or “-cff,” additional mode-specific documentation is displayed. For example, consider the following command line:

% tx -t1 -h

The subr-check.pl and fdarray-check.pl tools that were introduced in the February 3, 2012 and February 29, 2012 CJK Type Blog articles, respectively, are driven by the tx tool.

If no mode is specified, the text-dump mode is assumed, which can be explicitly specified with the “-dump” command-line option. This mode is useful to view high-level font information, private dictionary information, glyph names, and even human-readable charstrings. What information is presented depends on the level that is specified, which can range from “-0″ through “-6″ (“-1″ is the default if no level is specified). For example, I can display the human-readable charstring for CID+1200 by using the following command line:

% tx -6 -g 1200 KozGoPr6N-Bold.otf
tx: --- KozGoPr6N-Bold.otf
## glyph[tag] {cid,iFD,LanguageGroup,path}
glyph[1200] {1200,11,1,
  1000 width
  324 455 hstem
  36 966 vstem
  36 324 move
  966 324 line
  966 455 line
  36 455 line
  endchar}

The “-pdf” command-line option invokes PDF mode, which is most useful for producing a glyph synopsis in the form of a PDF file. If the “-g” command-line option is not specified, all of the glyphs in the specified font file are included in the glyph synopsis. The “-g” command-line option can be used to specify specific glyphs or glyph ranges, such as the following, which produces a glyph synopsis that includes all of the kanji glyphs in the Adobe-Japan1-6 ROS KozGoPr6N-Heavy.otf OpenType/CFF font:

% tx -pdf -g 656,1125-7477,7633-7886,7961-8004,8266,8267,8284,8285,8359-8717,13320-15443,16779-20316,21071-23057 KozGoPr6N-Heavy.otf glyphs.pdf

The “-afm” command-line option invokes AFM mode, and produces an AFM file.

The “-t1″ command-line option deserves some explanation, because it supports both name- and CID-keyed fonts. It is possible to convert a CID-keyed font into a name-keyed font by additionally specifying the “-decid” command-line option. If the specified glyphs span more than one FDArray element, the “-usefd” command-line option, along with an FDArray index as its argument, must also be specified. The resulting Type 1 name-keyed font includes glyphs that are named according to their CID, specifically “cid” followed by one to five decimal digits, such as “cid1200″ for CID+1200.

The tx tool can operate on a wide variety of font files, such as Type 1 fonts, CIDFont resources, CFFs, OpenType/CFF fonts (it references only the ‘CFF‘ table), and even TrueType fonts.

I could go on and on…

If you are an avid AFDKO user, and even if you are not, and have not yet explored the capabilities of the tx tool, I suggest that you take the opportunity to do so. You are likely to find a capability that can save you a lot of time and effort. What I have described above is merely the tip of the proverbial iceberg.

The two other systems, the Kunrei system (訓令式 kunrei shiki) and the Nippon system (日本式 nippon shiki), represent long vowels with a circumflex (U+005E CIRCUMFLEX ACCENT or U+0302 COMBINING CIRCUMFLEX ACCENT) diacritic. It was common for Latin fonts to include glyphs for circumflexed vowels, meaning U+00C2/U+00E2 (Ââ), U+00CA/U+00EA (Êê), U+00CE/U+00EE (Îî), U+00D4/U+00F4 (Ôô), and U+00DB/U+00FB (Ûû), by virtue of being included in ISO/IEC 8859-1 (aka Latin 1). However, due to limitations of Shift-JIS encoding, even Japanese fonts did not include glyphs for these characters.

I can think of three specific things that paved the way to broader use of macroned vowels:

First and foremost, Unicode and its de facto status for representing digital text was a key factor, and laid the foundation. These characters are encoded at U+0100/U+0101 (Āā), U+0112/U+0113 (Ēē), U+012A/U+012B (Īī), U+014C/U+014D (Ōō), and U+016A/U+016B (Ūū).

Second, to enable macroned vowels in mainstream Japanese fonts, a standard glyph set needed to include their glyphs. When I was developing Adobe-Japan1-4 in the late 1990s, glyphs for macroned vowels were early candidates, and eventually became CIDs 9361 through 9370. Of course, they are encoded according to Unicode in the Unicode CMap resources.

Third, mainstream Latin fonts began including glyphs for macroned vowels, mainly thanks to Unicode, and OpenType’s excellent support for Unicode. In terms of Adobe’s glyph sets, glyphs for macroned vowels are included in fonts that support Adobe Latin 3 (aka Adobe CE) or better.

Now, thanks to these efforts, it is relatively easy to transliterate 東京 using the more common Tōkyō, as opposed to the less common Tôkyô. The difference is shown below at a larger size:

Tōkyō versus Tôkyô

Composite fonts are generally used for authoring purpose, either to (virtually) extend a font resource with additional component fonts, or to (virtually) replace existing glyphs with those that are referenced in a different font resource. In the context of Japanese, it is common for legacy composite font implementations to replace the glyphs for kana with those of a different font. This is based on the premise that typical Japanese text includes more kana than kanji, and changing the kana can significantly alter the look and feel of the text.

Fallback fonts are used to display glyphs for a maximum number of code points, by selecting among various font resources, either by simple terms, such as a prioritized list, or more carefully by specifying fonts for particular code point ranges. Web browsers are ideal consumers of fallback fonts. Fallback fonts generally have less fidelity than composite fonts. Then again, the scope of composite fonts is generally more narrow, and composite fonts can serve as one of the component fonts in a fallback font.

Both composite fonts and fallback fonts have the potential to reference more than 64K due to the referencing of multiple font resources, each of which is limited to 64K glyphs.

Of course, publishing the ISO standard represents only the first step. The next steps involve establishing support for CFR in various places, ideally to replace existing composite font and fallback font implementations, almost all of which are proprietary. CFR has great potential in the cloud and for social media, mainly because it represents an interchange format for composite fonts and fallback fonts.

Although the text of this standard cannot be provided here, due to obvious copyright reasons, I can provide its DTD for those who are interested in examining it. For those who use Mac OS X, I would like to point out that CFR is largely based on Apple’s SplicedFont format, whose DTD can be found in /System/Library/DTDs/SplicedFont.dtd on the filesystem of that particular OS.