In early 2008, as part of writing and typesetting CJKV Information Processing, Second Edition and preparing the latest version of Adobe Tech Note #5078 (The Adobe-Japan1-6 Character Collection), I built a small—in terms of the number of glyphs—special-purpose font for displaying registration marks for glyphs, and named it Tombo. Such registration marks are incredibly useful for showing the relative position of a glyph within its em-box, and for conveying the visual horizontal advance (aka glyph width). The excerpt above shows this font’s use in the Source Han Sans ReadMe (note that the PDF file will download if clicked).
One of the questions one may ask about the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK open source Pan-CJK typeface families is whether they are GB 18030–compliant. Compliant? Sort of. Certified? Not yet.
Let me explain…
For those familiar with typeface design, there is no doubt that the Latin and Latin-like glyphs—to include those for Greek and Cyrillic—in Source Han Sans are based on Source Sans Pro. One may also wonder about the half-width Latin glyphs in Source Han Sans and how they compare to those in Source Code Pro. The purpose of this short article is to make these relationships and differences clear, or at least clearer.
One of the reasons why Source Han Sans—and obviously the Google-branded Noto Sans CJK—can be considered the world’s first Pan-CJK typeface family is due to its support for Korean hangul. While it is common to support modern hangul in Korean fonts, supporting archaic hangul is relatively uncommon. One of the more challenging aspects of developing Source Han Sans was implementing support for archaic hangul, which also included handling 500 high-frequency archaic hangul syllables. This article will thus detail what went into supporting archaic hangul in Source Han Sans. I’d like to once again thank our talented friends at Sandoll Communication for designing the glyphs for these characters.
This week’s festivities have thus far included attending IUC38 in Santa Clara, California. I presented twice, both times about Source Han Sans and Noto Sans CJK development.
For those who were unable to attend this excellent conference, the slides for my two presentations, Developing & Deploying The World’s First Open Source Pan-CJK Typeface Family and Building Source Han Sans & Noto Sans CJK, are now available.
P.S. The image shown above, which was used on page 47 of my first presentation to describe the Super OTC deployment configuration, became popular during IUC38, and was used by at least three other presentations. ☺
Before I begin the series of articles about what went into building Source Han Sans, I think that it is worth writing a few things about actually installing and using the fonts, including how to determine which of the four deployment formats best suits your needs.
Unless you have been living in a cave or under a rock, you’ve no doubt heard of Source Han Sans or Noto Sans CJK through the initial announcements from Adobe or Google who jointly developed them, or elsewhere. These two Pan-CJK typeface families, which are joined at the hip because they differ only in name, were released to the world at large, as open source fonts, on the afternoon of July 15, 2014 in the US, which was the morning of July 16, 2014 in East Asia, their target audience. Click on the preview below to view a single-page PDF that shows all 65,535 glyphs from one of these fonts:
Over the next several months I plan to publish a series of articles on this blog that will detail various aspects of the development process that I employed for building these two typeface families. Although the subsequent articles will mention only Source Han Sans by name, they also pertain to its twin, Noto Sans CJK.
Although today is April 1st, this is actually a brief non-joke article. Honestly and truly. (However, I cannot say the same about Toshiya SUZUKI’s WG2 N4572. ☺)
The background is that during my last visit to Japan, which was mainly to attend IRG #41 in Tokyo during the latter half of November of 2013, Kunihiko OKANO (岡野邦彦) requested an Adobe-Japan1-6 version of Adobe Blank during a dinner at a restaurant called かつ吉. The purpose of such a font is to serve as a template for font development purposes, meaning that its structure—in terms of ‘sfnt’ tables, FDArray elements, and number of glyphs (CIDs 0 through 23057)—is identical to a genuine Adobe-Japan1-6 font, but that all of its functional glyphs are non-spacing and blank, like Adobe Blank.
I am pleased to announce that the Adobe-Japan1-6 version of Adobe Blank, called Adobe Blank AJ16, is now available in the Downloads section of the open source project, specifically in the AJ16 subdirectory. Of course, this font is not intended to be installed and used in applications, but rather to be opened or inspected by font development tools.
Okano-san also requested Adobe-Japan1-3, Adobe-Japan1-4, and kana subset versions, which will soon be added to the “Adobe Blank OpenType Font” open source project.
I was recently asked, indirectly via Twitter, about changes and additions that were made to our JIS2004-savvy CMap resources, specifically UniJIS2004-UTF32-H and UniJISX02132004-UTF32-H. The former also includes UTF-8 (UniJIS2004-UTF8-H) and UTF-16 (UniJIS2004-UTF16-H) versions that are kept in sync with the master UTF-32 version by being automagically generated by the CMap resource compiler (and decompiler), cmap-tool.pl, which I developed years ago.
Of course, all of these CMap resources also have vertical versions that use a “V” at the end of their names in lieu of the “H,” but in the context of OpenType font development, the vertical CMap resources are virtually unused and worthless because it is considered much better practice to explicitly define a ‘vert‘ GSUB feature for handling vertical substitution. In the absence of an explicit definition, the AFDKO makeotf tool will synthesize a ‘vert’ GSUB feature by using the corresponding vertical CMap resources.
With all that being said, what follows in this article is a complete history of these two CMap resources, which also assign dates, and sometimes notes, to each version.
[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フォントを含みます。これらフォントの目的は、フォント開発者がより簡単にグリフの方向に関するテストを行えるよう考慮したものです。
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.
[This (Simplified) Chinese version of the May 1, 2013 Typblography article entitled Adobe contributes font rasterizer technology to FreeType is courtesy of Gu Hua (顾华).]
现代字库有两种字形轮廓格式可供选择—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字体显示效果。
[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は１９９０年にアップルによって開発されたフォーマットですが、CFF（Compact Font Format）は、アドビが１９８４年にリリースした(PostScriptフォントとして知られている）Type 1フォントフォーマットの第２世代にあたるフォーマットです。OpenTypeフォントでは、TrueTypeとCFFどちらも使用可能となっています。この二つのフォーマットは多くの共通点がありますが、最大の違いは次の２点です。カーブの表現に違う数式が使用されること、そして「ヒント」の形式が違うことです。（「ヒント」とは、限定されたピクセル数の中でも書体が最適の条件で表現されるようラスタライザーに指示を与えること）TrueTypeは殆どのヒント情報をフォント内のデータとして保持していますが、Type 1やCFFフォントの場合は高度なインテリジェンスをもつラスタライザーに多くを依存しています。
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.
Following again in the tradition of Adobe’s first open source font, Kenten Generic, the Adobe Type team announced today the release of their second open source typeface family, Source Code Pro. This monospaced typeface family was designed by our team’s own type designer Paul Hunt, who based the work on Source Sans Pro, Adobe’s first open source typeface family, released just last month. Six weights of Source Code Pro, along with its source files, can be download from the Open@Adobe portal on SourceForge, and for those who want to clone and fork the project, please refer to the GitHub location. The fonts are also available for Web use through Typekit, WebINK, and Google Web Fonts.
To learn more about the inspiration behind Source Code Pro, and how its design was adapted from Source Sans Pro, please refer to Paul Hunt’s Typblography article.