Posts in Category "Building Fonts"

CMap Resource Updates & Change Policies

For those font developers who are not aware, the official CMap resource repository for our public ROSes is the CMap Resources open source project at Open @ Adobe, which is hosted by SourceForge. When CMap resources are updated, in addition to providing the updates through this portal, an announcement is made in the CMap Resources Forum.

The UTF-16 and UTF-32 CMap resources were introduced in August of 2001, beginning with Adobe-CNS1-4. Those for Adobe-Korea1-2 and Adobe-Japan2-0 followed in January of 2002, followed by those for Adobe-GB1-4 in June of the same year. The UTF-16 and UTF-32 CMap resources for Adobe-Japan1-5 were not released until November of 2002. From that point, the UCS-2 CMap resources were deprecated, and were no longer updated. Clients that used the UCS-2 CMap resources were encouraged to use the UTF-16 or UTF-32 ones instead. For OpenType font development, in terms of building the Unicode (Format 4 and 12) ‘cmap‘ subtables, the UTF-32 CMap resources are recommended.
Continue reading…

“All Of Unicode” CFR Object

As alluded to at the end of the May 9, 2012 CJK Type Blog article, I had plans to build additional CFR objects for testing purposes. That particular article supplied two 64K-glyph OpenType/CFF fonts, which provided BMP and Plane 1 coverage, and served as component fonts for the supplied CFR object, UnicodeGetaCFR.cfr. In today’s article, I will supply a CFR object that encompasses all of Unicode, meaning the BMP and the 16 Supplementary Planes, along with the component fonts that it references. In other words, coverage for 1,112,030 code points, each of which has a unique glyph. These represent valuable testing resources for developers who plan to support CFR objects in their products as a way to break the 64K glyph barrier.
Continue reading…

A very useful AFDKO ‘tx’ tool command line…

For those AFDKO users who use, plan to use, or would like to explore the broad capabilities of its tx tool, here’s a command line that is very useful when building new versions of existing fonts, especially when only a small number of glyphs have changed:

% tx -bc -sha1 -z 400 <font_file>

The <font_file> portion of the command line can be any type of font file, such as an OpenType font, a CFF resource, a CIDFont resource, or a name-keyed Type 1 font.
Continue reading…

Building a CID-keyed font with 64K glyphs & 256 FDArray elements

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) and 256 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.
Continue reading…

Building a CID-keyed font with 64K glyphs

Today, I want to demonstrate how the AFDKO mergeFonts tool can be used to quickly and easily build a CID-keyed font that includes 64K glyphs, meaning CIDs 0 through 65534. This is the maximum number of glyphs that a CIDFont resource can contain. This font, of course, will use the special-purpose Adobe-Identity-0 ROS, and although its is a CID-keyed font, it will include only one FDArray element.
Continue reading…

The Special-Purpose Adobe-Identity-0 ROS

Adobe has thus far released two CID-keyed OpenType/CFF fonts that use the special-purpose Adobe-Identity-0 ROS (“ROS” is an abbreviation for /Registry, /Ordering, and /Supplement, which represent the three /CIDSystemInfo dictionary elements that are present in CIDFont and CMap resources): Kazuraki SP2N L (かづらき SP2N L) and Kenten Generic. The former is a commercial OpenType/CFF font, and the latter is an open source one. I have also developed several Adobe-Identity-0 ROS OpenType/CFF fonts for testing purposes, many of which have been provided in recent CJK Type Blog articles, the most recent of which being the May 9th, 2012 article.

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?
Continue reading…

Towards Breaking The 64K Glyph Barrier…

In the April 20, 2012 CJK Type Blog article, I wrote about the publishing of ISO/IEC 14496-28:2012 (Composite Font Representation), which provides a venue for breaking the 64K glyph barrier that is inherent in all sfnt-based font formats, including name- and CID-keyed PostScript fonts. If the number of glyphs of the combined component fonts that are referenced by a CFR object exceed 64K, would constitute breaking the 64K glyph barrier.
Continue reading…

Know Your Documentation

For those who develop fonts—professionally or otherwise—it is prudent to know where the latest and greatest documentation is located. This is useful not only when searching for specific documentation, but also to check whether there are any updates to existing documentation.

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 AFDKO ‘tx’ Tool

Among the many excellent and powerful tools included in AFDKO (Adobe Font Development Kit for OpenType) is one with a two-letter name: tx. Although it has the shortest name, it is arguably one of the most powerful AFDKO tools.

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.
Continue reading…

CID vs GID (Cont’d)

In yesterday’s CJK Type Blog post, I introduced and provided three Perl tools for listing the CIDs and GIDs in font resources:,, and In my continued effort to provide font developers with useful tools, I spent a few minutes this morning to enhance two of these tools, specifically and
Continue reading…


When working with OpenType/CFF fonts, particularly those that are CID-keyed, CIDs (Character IDs) and GIDs (Glyph IDs) are often referenced as ways to uniquely identify glyphs in a font resource. But, how are CIDs and GIDs different, and perhaps more importantly, under what circumstances are they different, or the same? These are good questions, and the answers can be found in today’s article.
Continue reading…

The BlueValues Array & Setting Its Values

When hinting name- or CID-keyed fonts, appropriate hinting parameters are required. One of these parameters are alignment zones whose purpose is to snap shapes to pixel boundaries. Alignment zones are specified in the required /BlueValues array, and also in the optional /OtherBlues array.

The required /BlueValues array is specified in the /Private dictionary of name-keyed fonts, and in the /Private dictionary of each FDArray element of CID-keyed fonts. The purpose of this array is to specify alignment zones that are at the baseline or above, such as for the baseline, x-height, and cap-height. The optional /OtherBlues array is used to specify alignment zones that are below the baseline, such as for the descender. This article will demonstrate how the AFDKO stemHist tool can be used to determine appropriate alignment zone values.
Continue reading…

Always Check Your Outlines

The photo below, which was recently taken by my long-term Adobe colleague Dirk Meyer in Beijing, serves as a not-so-gentle reminder that intersecting outlines can result in very obvious printing errors:

The photo depicts the two ideographs 出口, which represent the word meaning exit. The glyphs are obviously designed through the use of components whose outlines necessarily intersect, and under some circumstances—including the circumstance that led to the printing of this signage—can result in a negative or reverse fill.
Continue reading…

Another CJK-related Adobe Tech Note has been revised…

I spent the better part of last weekend revising Adobe Tech Note #5099, which was originally published in 1998 (14 years ago). If memory serves, I wrote the bulk of the original version of this document while on vacation in Indonesia. It seemed like the thing to do at the time.
Continue reading…

Building UTF-32 CMap Resources

When using AFDKO to develop CID-keyed OpenType/CFF fonts, the most important CMap resources are the UTF-32 ones, for the following reasons:

  1. Unicode has become the de facto character encoding for today’s OSes and applications.
  2. When the font includes mappings outside the BMP (Basic Multilingual Plane), the Format 12 (UTF-32) ‘cmap‘ subtable is included. When a font includes only BMP mappings, the AFDKO makeotf tool is smart enough not to create a Format 12 ‘cmap’ subtable, and instead creates only a Format 4 (BMP-only UTF-16) one.
  3. UTF-32 is arguably the most human-readable of the Unicode Encoding Forms, because its big-endian hexadecimal representation is simply the Unicode Scalar Value without the “U+” prefix and zero-padded to eight digits.

The AFDKO makeotf tool is used to build a fully-functional font, and a UTF-32 CMap resource is specified as the argument of its “-ch” command-line option.
Continue reading…

IVD Version 2012-03-02 Released

As the IVD Registrar, I am very pleased to announce that a new version of the IVD (Ideographic Variation Database) was released on March 2nd, 2012. It incorporates the results of PRI 183 and PRI 187.
Continue reading…

A Tool For Enumerating FDArray Elements & Their CIDs

On this 29th day of February in the year 2012, which is a leap year, I decided that it would be a good idea to whip up a tool (written in Perl, of course) that enumerates the FDArray elements in a CID-keyed font, by name and index, and to list the CIDs that are assigned to it. Also reporting the ROS is useful. This tool, called, makes use of the AFDKO tx tool, and massages its output into a form that is much more human-readable, and which can be repurposed.
Continue reading…

A Better Method To Insert Corrected Glyphs Into CIDFont Resources

As I detailed in the February 24, 2012 CJK Type Blog post, the “first one wins” principle is useful when employing the AFDKO mergeFonts tool for replacing one or more glyphs in CIDFont resources. This comes at the expense of changing the FDArray indexes, at least for the example that was used. I noted that this is not a particularly important issue, but I felt that some clarification was necessary, thus the topic of today’s CJK Type Blog post.

What matters is the assignment of CIDs to FDArray elements (by name) and their associated hinting parameters and other attributes, and these are unchanged even if the FDArray index changes. When the “first one wins” principle is invoked, it means that two or more CIDFont resources include a glyph for the same CID, and the one that is used in the resulting CIDFont resource is the one that is first encountered, as specified by the order of the merge fonts on the command line. However, there are very useful command-line options that allow one to exclude (or include) CIDs so that the FDArray indexes can be preserved, if that is important to you.
Continue reading…

Simplifying CIDFont Glyph Corrections Using AFDKO Tools

The process of building a CIDFont resource, which serves as the source file for the ‘CFF‘ table of a CID-keyed OpenType/CFF font, usually entails “rolling up” or combining two or more name-keyed fonts into a larger CID-keyed one. Depending on which tools are used to build the CIDFont resource, fixing glyphs can become a cumbersome or time-consuming task. First, you need to map the CID to a glyph name in the name-keyed source fonts, and if you are fixing multiple glyphs, you may need to modify more than one name-keyed source font. Many font developers are not aware that some AFDKO tools, such as tx, mergeFonts, sfntedit, and autohint, can simplify this process, if used appropriately.
Continue reading…

How much interest in AFDKO for other platforms?

We have made AFDKO (Adobe Font Development Kit for OpenType) available for Mac OS X and Windows, but we also realize that these are not the only OSes that font developers prefer to use. In an effort to make AFDKO more appealing to more font developers, and more broadly available, we’d like to gauge the interest in supporting additional OSes, particularly Linux and other Unix-like OSes (mainly because AFDKO tools are, for the most part, batch- and command-line driven).
Continue reading…