CJK Type Blog

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…

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…

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…

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…

I realized today, thanks to a tweet by @mashabow, that we have never fully documented the “cidfontinfo” file.

This file started out as the primary control file for our first-generation CIDFont resource compiler, called mkcidfont, which ran only on SunOS.
Continue reading…

One question that I am often asked by OpenType CJK font developers is related to the XUID array, which is used by some environments for caching purposes. I decided to use this opportunity to write a brief tutorial on how to manage XUID arrays when developing OpenType CJK fonts.
Continue reading…