Posts in Category "Building Fonts"

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 fdarray-check.pl, 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…

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…

CMap Resource Updates

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.

Excruciating details about the Adobe Tech Note #5079 update

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…

An “Extreme” OpenType Font

I like building fonts. I especially like building fonts with a large number of glyphs. Fortunately, my job entails developing OpenType CJK fonts, which means that I need to deal with fonts with thousands or tens of thousands of glyphs.

I built an “extreme” OpenType font last year, and spent the morning making it even more extreme. Given that “extreme” fonts are useful for stress-testing software that consumes fonts, I figured that this post would be a good opportunity to make it available to developers who may benefit by testing with this font.

Did I mention that I like building fonts? ☺
Continue reading…

Adobe-Japan1-6 Turns 20 Years Old

The Adobe-Japan1-6 Character Collection, which has become the de facto glyph set for today’s mainstream OpenType Japanese fonts, celebrates its 20th anniversary this year. This glyph set began its life in 1992, as Adobe-Japan1-0 (Supplement 0). Given that I have been at Adobe longer than 20 years, and was involved in the development of this glyph set, I will use this opportunity to detail some of its history, at least as seen through my eyes.
Continue reading…

AFDKO “features” File Tips & Tricks, Part 2: GSUB Features for Public ROSes

When developing CID-keyed OpenType/CFF fonts that are based on one of our public ROSes—meaning Adobe-GB1-5, Adobe-CNS1-6, Adobe-Japan1-6, or Adobe-Korea1-2 (including their earlier Supplements)—it is a good idea to leverage existing resources. One of these resources are the registered GSUB (Glyph SUBstitution) features that we define when building OpenType/CFF fonts that are based on these ROSes. Of course, if you build an OpenType/CFF font based on the special-purpose Adobe-Identity-0 ROS, you’re pretty much on your own in terms of defining its GSUB features, but this CJK Type Blog post from earlier this month demonstrated how existing GSUB features for our public ROSes can be used as the basis for such fonts.
Continue reading…

Two Adobe Tech Note Updates

Two of our font- and CJK-related Adobe Tech Notes were updated this week. One aspect of the update is for issuing a new Supplement or to correct representative glyphs. Another aspect is to typeset the document according to latest practices. For these Adobe Tech Notes, the latter aspect involved changing their static glyph tables into a form that is more efficient, more useful, and more dynamic.
Continue reading…

AFDKO “features” File Tips & Tricks, Part 1: ‘vmtx’ Table Overrides

Given that I seem to be on a roll, it seems appropriate to begin a new AFDKO series that focuses on the all-important “features” file that is used to define GSUB and GPOS features, and to override the settings of various tables. Let’s begin with something relatively simple, such as overriding the ‘vmtx‘ table for a very specific class of glyphs: full-width Latin or Latin-like glyphs that rest on a Latin baseline, but which should be centered along the Y-axis when in vertical writing mode. Click here to download an archive that includes the various files and resources that are referenced in this article.
Continue reading…

Leveraging AFDKO Tools to Convert Name-keyed OpenType Fonts to CID-keyed — Part 3

In Part 1 and Part 2 of this series, I demonstrated how AFDKO tools can be used to convert name-keyed fonts into CID-keyed ones. Part 1 resulted in a font that uses the special-purpose Adobe-Identity-0 ROS, and Part 2 resulted in one that uses a standard character collection, specifically the Adobe-Japan1-0 ROS.

Part 3 in this series will demonstrate how GSUB features—using the ‘vert‘ GSUB feature as an example—can be added to both types of fonts. Click here to download an archive that includes the various files and resources that are referenced in this article.
Continue reading…

Leveraging AFDKO Tools to Convert Name-keyed OpenType Fonts to CID-keyed — Part 2

Part 2 of this series will demonstrate how AFDKO tools can be used to specify multiple FDArray elements (aka, hint dictionaries) when converting name-keyed fonts into CID-keyed ones. The same technique can be used to convert a CID-keyed font with a single FDArray element into one with multiple FDArray elements.

The sample font in Part 1 of this series does not have enough script “richness” to demonstrate this technique, so I crafted a different sample font for demonstration purposes. Again, the technique is easily scalable, and can thus handle thousands or tens of thousands of glyphs.
Continue reading…

Leveraging AFDKO Tools to Convert Name-keyed OpenType Fonts to CID-keyed — Part 1

The easiest method for representing an arbitrary name-keyed OpenType font as a CID-keyed one is to specify the special-purpose Adobe-Identity-0 ROS (/Registry, /Ordering, and /Supplement, referring to the three elements of the /CIDSystemInfo dictionary that is present in CIDFont resource headers), and in my experience, the easiest path to conversion is to leverage specific AFDKO tools, such as tx, mergeFonts, stemHist, autohint, and makeotf. As you should discover after reading this article, the conversion process is relatively straight-forward and simple.

The first part in this series will focus on the basic conversion process, from name-keyed to CID-keyed, ignoring any OpenType features that were present in the original name-keyed OpenType font, and also not taking advantage of multiple FDArray elements (aka, hint dictionaries) that are possible in CID-keyed fonts. Subsequent parts in this series will cover those topics.
Continue reading…