Archive for February, 2012

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…

CJK Unified/Compatibility Ideographs in Unicode Version 6.1

Unicode Version 6.1 was released on 01/31/2012, and now includes 74,617 CJK Unified Ideographs, along with 1,002 CJK Compatibility Ideographs. 732 characters were added, and there are now a staggering 110,116 characters in the standard.

Speaking of staggering, as Unicode grows, it becomes more important to keep track of what character is encoded where, and sometimes it is useful to know when a character was encoded. For this purpose, the DerivedAge.txt datafile is an incredibly useful resource.

In terms of CJK Unified Ideographs and CJK Compatibility Ideographs, I spent part of the morning assembling a single-page PDF file that encapsulates many important details of their history. I hope that readers of this blog find it to be useful.

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…

What if…

…Adobe were to host a font-development workshop in Japan, with a focus on leveraging specific AFDKO tools to simplify the effort needed to develop OpenType Japanese fonts? Tools, such as tx, mergeFonts, rotateFont, autohint, and stemHist, immediately come to mind. While there are currently no concrete plans in place, if there were to be sufficient demand for such an event, along with suggestions for specific topics to be covered, a tentative agenda could be produced.

Until such an event is scheduled and actually takes place, Adobe Tech Note #5900 (AFDKO Version 2.0 Tutorial: mergeFonts, rotateFont & autohint), which includes a Japanese translation, should prove to be useful. This document is included in AFDKO as part of its documentation, but its link is provided above for convenience.

I encourage anyone with an interest in attending such a workshop, to be held in Japan, to post comments that include suggestions for topics to be covered.


To Subroutinize, Or Not To Subroutinize

One of the benefits of OpenType/CFF, whether you’re building name- or CID-keyed fonts, is that the ‘CFF‘ table can be subroutinized. And, the AFDKO makeotf tool can be used to apply subroutinization when building OpenType/CFF fonts. The tx tool, by using its “+S” option, can do so as well.
Continue reading…

CMap Resource Names Explained

For the longest time I have felt that the names used for many of our CMap resources deserve some amount of explanation. I see these names written in books from time to time, and it usually gives me a chuckle, mainly because I am the one responsible for coining many of them. This post is an opportunity for me to provide (some) definitive answers, along with some history. Of course, if this post raises more questions, please submit a comment, and I will make an honest effort to provide a timely answer.

In general, and with few exceptions, a CMap resource name is composed of a character set name, and encoding name, and a writing direction. For the most part, it is the character set names that deserve some explanation, because the encoding and writing direction names are fairly straight-forward. Also, whenever I mention a CMap resource name, it almost always has a corresponding vertical CMap resource.
Continue reading…