CJK Type Blog

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…

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…

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…

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…

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…

Unicode Version 6.1 was released today (January 31, 2012). This release triggered an update to the Unicode CMap resources for Adobe-Japan1-6 and Adobe-Korea1-2. The updated CMap resources are now available at the CMap Resources open source project that is hosted at Open @ Adobe. Details have been posted.

Given that Unicode has become the de facto encoding for digital text for modern environments, I encourage readers of this blog to explore for themselves what is new in Unicode Version 6.1.

I spent the early part of this week updating Adobe Tech Note #5079 (The Adobe-GB1-5 Character Collection). The number of glyphs remained the same (30,284), as did the glyphs themselves. So, why the update? Well, mainly to bring it in line, format-wise, with the other three related Adobe Tech Notes: #5078 (The Adobe-Japan1-6 Character Collection), #5080 (The Adobe-CNS1-6 Character Collection), and #5093 (The Adobe-Korea1-2 Character Collection). The biggest effort was to create its 61-page glyph table. Besides announcing the update, building the glyph table is the substance of this blog post.
Continue reading…