Posts in Category "Building Fonts"

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…

The “cidfontinfo” File

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…

Managing XUID Arrays

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…

Japan’s Jōyō Kanji set has just been revised. So, what comes next?

Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development

Jōyō Kanji (常用漢字) represents the kanji that are in common use in Japan. Prior to 1981, it was known as Tōyō Kanji (当用漢字) and included 1,850 kanji. The last time that Japan’s Jōyō Kanji set was revised was in 1981, and 95 kanji were added, bringing the number of kanji to 1,945.

For the first time in nearly 30 years, the Jōyō Kanji set has been revised. The announcement was made on November 30, 2010. The final outcome was that 196 kanji were added, and five kanji were removed. Thus, the total number of Jōyō Kanji is now 2,136.

Perhaps more interesting is the effect that the Jōyō Kanji revision has on the Jinmei-yō Kanji (人名用漢字) set. The relationship between these two sets of kanji is important: the Jinmei-yō Kanji set includes kanji, above and beyond Jōyō Kanji, that have been deemed suitable for use in personal names. Thus, any kanji in the Jōyō Kanji set can be used for personal names. The Jinmei-yō Kanji set currently includes 985 kanji. When compared to the new Jōyō Kanji set, 129 kanji are now common, and can thus be removed from the Jinmei-yō Kanji set. Also, because Jōyō Kanji and Jinmei-yō Kanji together serve as the foundation for the kanji used in personal names, any kanji that are removed from the Jōyō Kanji set should be grandfathered by adding them to the Jinmei-yō Kanji set. There are five such cases.

Continue reading…

The “Hanyo-Denshi” IVD Collection has been registered!

Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development

I reported in the April 9, 2010 Typblography post that the “Hanyo-Denshi” (汎用電子) IVD Collection was submitted for registration, as PRI 167 (Public Review Issue #167). I am pleased to announce to readers of this blog that the “Hanyo-Denshi” IVD Collection was registered on November 14, 2010, and includes 4,195 IVSes. This represents a great achievement, specifically that it represents the second IVD collection to be successfully registered. The first, of course, was the “Adobe-Japan1″ IVD Collection on December 14, 2007.

Continue reading…



Continue reading…



  一款凝聚着许多人心血的新字体终于面世了,第一件大事自然是要起个好名字,当然不能象起”小名”般随意,因为这名字将要登记在册,写入”家谱”,未来要登上Windows 、Mac OS X这样的平台,出入各式各样的App(Application)。那么什么样的名字才是好名字呢?

Continue reading…



作者:Daniel “daan” Strebe (Senior Computer Scientist,Adobe Systems Incorporated) 原稿

  请欢迎 “Tin“, Adobe最新的开源项目。”Tin” 是一个用于处理基于SFNT 文件格式字库的C++类库。Tin源码可以实时快速地更新大量字库,并且仅依赖开源组件。(请注意:Tin既不是一个字形编辑器,也不是查找、安装或管理字库的程序或某种处理系统字库的服务)

Continue reading…

The results from a 7.5-year experiment are in: Unicode and OpenType are successes!

和文 中文
Dr. Ken Lunde
Approximately 7.5 years ago — at the end of 2002 — I commissioned the suite of Unicode CMap resources for Adobe-Japan1-x (it was Adobe-Japan1-5 at that time, and Adobe-Japan1-6 was finalized less than two years later), specifically for UTF-8, UTF-16, and UTF-32.
When I built these new Unicode CMap resources, one of the reasons was to add support for JIS X 0213:2000, which includes over 4,000 additional characters. I also considered adding the appropriate character code to CID mappings to the existing Shift-JIS and EUC-JP CMap resources, but chose not to do so, because I felt that Unicode had matured to the point that supporting these legacy encodings was not required. I still built the necessary tab-delimited tables so that I could easily and quickly add these mappings in case we received any requests to do, or if doing so became a product requirement.

Continue reading…

IVS Support: The Current Status and the Next Steps


Dr.Ken Lunde

For those who are not aware, IVSes (Ideographic Variation Sequences) are a standardized Unicode mechanism for representing otherwise unencoded variant forms of CJK Unified Ideographs using “plain text,” specifically via a sequence of a Base Character (aka, a CJK Unified Ideograph) followed by a Variation Selector (one of the 240 in Plane 14). This sequence maps to a glyph that corresponds to a registered IVS, which is part of a registered IVD (Ideographic Variation Database) Collection.

Continue reading…