Author Archive: Dr. Ken Lunde

Top Ten List: Reasons To Abandon Shift-JIS Encoding

In the spirit of encouraging developers, especially those in Japan, to provide better or more broad support for Unicode, which usually entails abandoning Shift-JIS encoding, I became inspired this evening to put together a Top Ten List that provides various Reasons To Abandon Shift-JIS Encoding, similar to the Unicode Beyond-BMP one that I prepared a couple years ago.

While humor is intended in such Top Ten Lists, there is also a serious side to this issue: Given that today’s systems work together, by clinging to Shift-JIS, developers can adversely affect other systems that do support Unicode.


「CSS Orientation Test OpenType Fonts」について

[This Japanese version of the May 31, 2013 article entitled CSS Orientation Test OpenType Fonts is courtesy of Hitomi Kudo (工藤仁美).]

五月三十一日にアドビの新しいオープンソースプロジェクトで、「CSS Orientation Test OpenType Fonts」をリリースしたのでお知らせします。このオープンソースプロジェクトは、Unicodeの次期UTR #50(「Unicode Vertical Text Layout」)のエディタである石井宏治氏のリクエストをもとに開発された、二つのOpenType/CFFフォントを含みます。これらフォントの目的は、フォント開発者がより簡単にグリフの方向に関するテストを行えるよう考慮したものです。
Continue reading…

CSS Orientation Test OpenType Fonts

I am pleased to announce that the new CSS Orientation Test OpenType Fonts open source project was launched on Adobe’s open-source portal, Open@Adobe, today. This open source project consists of two OpenType/CFF fonts that were developed at the request of Koji Ishii (石井宏治), the editor of Unicode’s forthcoming UTR #50 (Unicode Vertical Text Layout). The purpose of these fonts is for developers to be able to more easily test whether glyph orientation in their implementation is correct or not.
Continue reading…

OpenType ‘cmap’ Table Ramblings

OpenType fonts are ‘sfnt’ (scalable font) resources that are comprised of several well-defined tables. One of these tables, which is the topic of today’s article, is the ‘cmap‘ (character map) table. The ‘cmap’ table, put simply, maps characters codes to Glyph IDs (GIDs) that refer to glyphs in the ‘glyf‘ or ‘CFF‘ (Compact Font Format) table, depending on the “flavor” of the OpenType font. What is important about the ‘cmap’ table is that it makes the glyphs usable. Without the ability to map from character codes, which are used by virtually all applications and OSes, the glyphs in a font are useless, and cannot be readily accessed or used.
Continue reading…

Gothic/Myungjo or Dotum/Batang?

The prototypical Serif and Sans Serif typeface style distinction in Korean has traditionally used the names Myeongjo (명조체/明朝體 myeongjoche) and Gothic (고딕체/고딕體 godikche), respectively. But, in 1993, the Republic of Korea (South Korea) Ministry of Culture, in an attempt to standardize typographic terms, recommended the use of Batang (바탕 batang) and Dotum (돋움 dotum) as the proper names for these two typeface styles.

At the time the Ministry of Culture recommendation was made, which was a period when printing was the most common use of fonts, Batang was meant for body text, and Dotum was for display or emphasis purposes. Mobile devices have provided a new use for Dotum, because its lack of serifs provided superior readability on mobile devices with smaller screens that necessitated smaller point sizes, and the original rationale for these new names seems to no longer apply.

From what I can tell, Korean type foundries have not embraced the Batang and Dotum names, and have actually resisted their use. What probably didn’t help was the fact that Microsoft released TrueType fonts with these exact names, with no additional qualifiers: Batang and Dotum. In other words, it seems that Microsoft’s use of these names polluted their chance at more widespread use, because they were treated as typeface names, not typeface style names.

In closing this brief article, I am curious about what our blog readership thinks about this particular issue. I welcome any and all comments.


[This (Simplified) Chinese version of the May 1, 2013 Typblography article entitled Adobe contributes font rasterizer technology to FreeType is courtesy of Gu Hua (顾华).]

今天我们很荣幸地宣布Adobe向FreeType提供了CFF字体光栅处理程序。可测试的代码已经包含在最新的FreeType Beta版中。该开源项目是由Adobe,Google和FreeType三方合作,旨在改善使用FreeType的设备和环境上的CFF字体渲染质量。

现代字库有两种字形轮廓格式可供选择—TrueType或者CFF。TrueType是Apple于1990年开发的,而CFF(Compact Font Format)格式是Adobe基于1984年首次发布的Type 1格式(常称为PostScript字库)衍生出的第二代格式。无论是TrueType还是CFF都可被用于OpenType字库中。它们有很多共性,但也有两个主要区别:它们使用不同的数学运算方法描述字形曲线,以及使用不同的hinting技术(Hinting:提供光栅化提示,以确保在有限的像素里尽可能地准确显示每个字形)。TrueType侧重于在字体中构建指令,而Type1和CFF更多地依赖光栅器的智能处理。这使得光栅器质量显得尤为重要,对于这次合作,Adobe期望在使用FreeType环境上能显著改善CFF字体显示效果。
Continue reading…


[This Japanese version of the May 1, 2013 Typblography article entitled Adobe contributes font rasterizer technology to FreeType is courtesy of Hitomi Kudo (工藤仁美).]


近年のフォントは、TrueTypeかCFFどちらかのフォーマットを使用するのが通例です。TrueTypeは1990年にアップルによって開発されたフォーマットですが、CFF(Compact Font Format)は、アドビが1984年にリリースした(PostScriptフォントとして知られている)Type 1フォントフォーマットの第2世代にあたるフォーマットです。OpenTypeフォントでは、TrueTypeとCFFどちらも使用可能となっています。この二つのフォーマットは多くの共通点がありますが、最大の違いは次の2点です。カーブの表現に違う数式が使用されること、そして「ヒント」の形式が違うことです。(「ヒント」とは、限定されたピクセル数の中でも書体が最適の条件で表現されるようラスタライザーに指示を与えること)TrueTypeは殆どのヒント情報をフォント内のデータとして保持していますが、Type 1やCFFフォントの場合は高度なインテリジェンスをもつラスタライザーに多くを依存しています。
Continue reading…

Heisei “StdN” Fonts

We recently released alternate versions of two Heisei (平成) fonts, specifically Heisei Mincho StdN W3 (平成明朝 StdN W3) and Heisei Kaku Gothic StdN W5 (平成角ゴシック StdN W5). As the “StdN” designator suggests, JIS2004 glyphs are the default for these two fonts (the Heisei “Std” fonts use JIS90 glyphs by default).

These two fonts also differ from the Heisei “Std” fonts in that they include significantly more glyphs. The Heisei fonts were developed by a consortium of companies, and Adobe is one of the member companies. Interestingly, JIS X 0213:2004 glyph data was developed only for Heisei Mincho W3 and Heisei Kaku Gothic W5, and JIS X 0212-1990 glyph data was developed only for the former font. So, one of my projects last year was to map as many of these glyphs as possible to Adobe-Japan1-6 CIDs.
Continue reading…

Adobe Blank: Another Adobe-Identity-0 Implementation

As I wrote nearly a year ago, the Adobe-Identity-0 ROS is useful for building special-purpose fonts, especially CJK ones whose glyph coverage does not match one of our public ROSes. Our latest Adobe-Identity-0 ROS font is the open-source Adobe Blank, whose purposes and implementation details are described on our sister blog, Typblography.


Sequences are important in the context of Unicode, and UAX #34 (Unicode Named Character Sequences) is a good reference for Unicode sequences. The first type of sequence that typically comes to mind in the context of Japanese are Ideographic Variation Sequences (IVSes), which are registered and maintained by The Unicode Consortium via the Ideographic Variation Database (IVD). There are also Standardized Variation Sequences that are much more closely bound to the standard.
Continue reading…

Standardized Variants—Part 3

I will close this particular topic by detailing how to support these proposed standardized variants in OpenType/CFF fonts.

For fonts that are currently IVS-enabled, such as those that include Format 14 ‘cmap’ subtables with Adobe-Japan1 or Hanyo-Denshi IVSes, it is important to note that the proposed standardized variants can co-exist with them, at least in terms of being specified in the font. For the former, I created an Adobe-Japan1_sequences.txt file that includes all registered Adobe-Japan1 IVSes, along with 89 of the 1,002 proposed standardized variants. The 89 standardized variants are at the end of the file. AFDKO tools, such as makeotf and spot, already support these standardized variants. When building OpenType/CFF fonts using the makeotf tool, this file is specified as the argument of the “-ci” command-line option.
Continue reading…

Standardized Variants—Part 2

To continue from the December 26, 2012 article, I should first point out that there is a relationship between these 1,002 proposed standardized variants and IVSes (Ideographic Variation Sequences). Standardized variants are standardized, hence their name. IVSes, on the other hand, are registered via a process that is described in UTS #37 and administered by the IVD Registrar (which happens to me at the moment).
Continue reading…

Standardized Variants—Part 1

One problem that has been plaguing CJK Compatibility Ideographs is the fact that they are adversely affected by normalization. Regardless of which of the four normalization forms is applied—NFC, NFD, NFKC, or NFKD—they are converted to their canonical equivalents, which are CJK Unified Ideographs. This is a problem, particularly for Japan, because 75 kanji in JIS X 0213:2004 kanji map to CJK Compatibility Ideograph code points. Furthermore, 57 of these 75 kanji correspond to Jinmei-yō Kanji (人名用漢字), meaning that they are used for personal names. The bottom-line problem with CJK Compatibility Ideographs is that any application of normalization, by any process, will permanently remove any distinctions between a CJK Compatibility Ideograph and its canonical equivalent. Not all processes are under one’s direct control, meaning that it is impossible to guarantee that normalization will not be applied. My opinion is that it is prudent to assume that normalization will be applied, and that preemption is the best solution.
Continue reading…

Old Hangul—Redux

In the December 4, 2012 Old Hangul article I mentioned that the ‘ccmp’ GSUB feature that is referenced in Microsoft’s Developing OpenType Fonts for Korean Hangul Script document is not necessary. Jaemin Chung kindly pointed out to me that environments that do not yet support Unicode Version 5.2 still require the ‘ccmp‘ (Glyph Composition/Decomposition) GSUB feature to be present, otherwise proper shaping will not happen.

The main purpose of this short article is to provide a revised Perl script, named, that adds a complete ‘ccmp’ GSUB feature definition for environments that do not yet support Unicode Version 5.2 (or greater). The sample glyph-map.txt datafile that maps the Unicode-based glyph names to CIDs is unchanged.

Old Hangul

Okay. It is time to put some “K” into CJK…

Seriously, much of the content of this blog has been focused on Chinese and Japanese issues. This article will provide some much-deserved Korean content.

I spent the last few days coming to grips with Old Hangul (옛한글 yethangeul), specifically how to implement proper shaping using the three registered OpenType GSUB features, ‘ljmo‘ (Leading Jamo Forms), ‘vjmo‘ (Vowel Jamo Forms), and ‘tjmo‘ (Trailing Jamo Forms).
Continue reading…

These are a few of my favorite things…

I like ASCII. Do I like ASCII because of all the wonderful things one can do with its extraordinarily large repertoire of 94 printable characters? Actually, yes. Before I defend that answer, I’d like to point out that ASCII has three important strengths: simplicity, robustness, and ubiquity. In other words, ASCII is simple in that it has a relatively small number of characters; it forms a subset of virtually every encoding, Unicode or otherwise; and is supported everywhere. In fact, ASCII can be used to represent Unicode through the use of notations. Richard Ishida‘s excellent Unicode Code Converter is an excellent way to explore the various notations that are currently in use.
Continue reading…

Turning CID-Keyed Fonts Into OpenType Fonts Using AFDKO


10月10日水曜日、香港で開催されたATypI Hong Kong 2012にてAFDKOワークショプをおこないました。とても専門的な内容にもかかわらず、多くの方にご参加いただきありがとうございました。

3時間のワークショプの前半2時間は、Ken Lundeによる「Manipulating CID-Keyed Fonts Using AFDKO Tools」が行われ、後半1時間「Turning CID-Keyed Fonts Into OpenType Fonts Using AFDKO」を私が担当しました。
Continue reading…

Combining 3 Tools Into 1:

For those who make use of the,, or tools, all of which are AFDKO tx tool filters and are included in AFDKO, and whose purpose is to list the glyphs in the specified font resource, I’d like to introduce a new tool, named, which combines their functionality, thus making font development simpler.
Continue reading…

Kazuraki: Under The Hood

I had the opportunity this morning to present at ATypI Hong Kong 2012 about Kazuraki, specifically the details about its OpenType implementation. Hence, the title of the presentation is Kazuraki: Under The Hood. The purpose of this article is simply to make the presentation available.

Manipulating CID-Keyed Fonts Using AFDKO Tools

Yesterday—meaning Wednesday, October 10th, 2012, Hong Kong Time (UTC+8)—I had the honor and privilege to present the first two hours of a three-hour ATypI Hong Kong 2012 workshop entitled Manipulating CID-Keyed Fonts Using AFDKO Tools. When I did a rough count, there were nearly 30 people in attendance. I’d like to use this opportunity to thank those who were able to attend, which meant that they made the effort to travel to this conference, and also chose to attend this workshop in lieu of attending presentations from the Typography & Reading and Typography & Culture tracks, or other concurrent workshops. I’d also like to provide to those who attended, and to those who were not able to attend, the presentation that I used to drive these two hours, which includes material that can be studied and referenced.

In addition to installing the latest-and-greatest version of AFDKO, the workshop attendees were also provide with the actual sample font data that I used to demonstrate the various workflows and techniques.

My hope is that these materials are useful to those who attended this workshop, and to those who were not able to do so. Enjoy!

Speaking of enjoy, that is what I plan to do for the remaining four days of this five-day conference. ☺