To follow up on my June 2011 article about managing XUID arrays in CIDFont resources, which still conveys accurate information, it has come to our attention that the integer values for the second and subsequent XUID array elements should not exceed seven digits, meaning that 9999999 is the largest integer value that should be used. Integer values that exceed seven digits can result in some implementations treating the XUID arrays of different fonts within the same printing job the same, which affects font caching, and which can result in the wrong font being used to render some characters. This printing issue may happen even if the glyphs display correctly in the PDF file on screen.
Another solution is to simply omit the XUID array from the CIDFont resource header, which effectively disables font caching. For modern printers, font caching has little or no benefit.
Lastly, for those font developers who still include a UIDBase value in their CIDFont resource headers, it can be safely removed. In fact, I strongly recommend that it be removed.
Due to an inadvertent error on my part, the glyphs for the vertical-only kana were incorrect in Source Han Sans Version 1.002 (and, by extension, in Version 1.003 because there were no glyph changes). Many thanks to the person who identified and reported this issue, and I’d like to convey my sincere apologies to those who were affected by it.
[This article was written by Masataka HATTORI (服部正貴) and translated into English by yours truly.]
Source Han Code JP（日本語メニューネーム：源ノ角ゴシック Code JP）は、自分がほしくて個人的にはじめたオープンソースプロジェクトでした。Source Han Sans（源ノ角ゴシック）と Source Code Pro をフォールバックするエディタで使うと、漢字・仮名とくらべ英数字が小さくなってしまい全体的に読みにくいと感じていました。そんなとき、友人のプログラマーから、日本語も使えてコーディングにも適したフォントはないか？と相談されて、これは自分で作ってしまえと考えました。
オリジナルの Source Code Pro は、600 ユニット字幅を採用した欧文専用のモノスペースフォントで、まぎらわしいアルファベットや数字をディスプレイで判別しやすくするために、文字のデザインが工夫されています。それを、Source Han Sans JP（源ノ角ゴシック JP）の日本語と合わせてもフィットするようにサイズやウエイトを調整しました。文字幅は 660 ユニットあたりがちょうど良いと思いました。もともと読みやすさの観点から半角欧文はすこしコンデンスすぎると感じていたので、思い切って 2/3（667 ユニット）字幅を採用することにしました。一般的な半角（500 ユニット字幅）の等幅フォントにくらべ、全角文字との正確なインデントには向きませんが、読みやすさを確保しつつ、使い方次第で様々な表現ができると思いました。Source Han Code JP は、オリジナルの Source Han Sans JP と同じ７ウェイトのファミリーですが、ウェイトを切り替えても文字列の長さは変わりません。
結果的に、日本語を含むプログラミングやマークアップなどソースコードの表示や編集に使用できる Adobe Source シリーズの派生フォントとして、Adobe Fonts GitHub サイトから公開することになりました。
Read in English
Although it has been less than two months since the Source Han Sans Version 1.002 update was released, a Version 1.003 maintenance update was released on 2015-06-09 to address two particular issues. No glyphs nor Unicode mappings were added or modified.
Google’s corresponding Noto Sans CJK fonts, which continue to differ from Source Han Sans only by name, were also updated to Version 1.003 at the same time, and reflect the same changes.
The Source Han Sans Version 1.002 update was released on 2015-04-20, which involved turning a very large crank on something that has a very large number of moving parts. The updated region-specific subset OTFs are also available on Typekit via desktop sync.
Google’s corresponding Noto Sans CJK fonts, which differ from Source Han Sans only by name, were also updated to Version 1.002 at the same time, and reflect the same changes.
Yesterday morning I came up with the idea to produce a font for testing the extent to which applications and other text-handling environments support IVSes (Ideographic Variation Sequences), and ended up devoting the better part of this Easter weekend assembling, testing, and releasing the font as open source on GitHub. The font is named IVS Test, and as usual for me, it is an Adobe-Identity-0 ROS CID-keyed OpenType/CFF font.
I started the process of migrating to GitHub the font-related open source projects that I maintain, and recently finished. In some cases, the projects were split between SourceForge and GitHub, with the installable font resources (and sources) on the former, and only the sources on the latter. Some projects were available only on SourceForge.
There are a couple of motivations for this migration. First, GitHub provides a great user experience for posting, tracking, and responding to “Issues” for a project. In fact, I made good use of the mobile app for Android while vacationing in Wisconsin late last July. Second, we prefer the control that GitHub offers in terms of updating projects. I use the GitHub command-line tools, along with the SourceTree app for OS X, when initiating or updating projects on GitHub.
Well, it’s April 1st, which represents an ideal time to release and introduce Adobe Blank 2, which is a new version of the popular Adobe Blank font.
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…
Let it be known that the “OpenType Collection” (OTC) format was born on 09/21/2011 at Pho Minh Restaurant in Cupertino, California. Present from Adobe were the following: David Lemon, Ken Lunde, Sairus Patel, and Read Roberts. Present from Apple were Antonio Cavedoni, Julio Gonzalez, Yasuo Kida, Peter Lofting, and Tony Tseung. — Adobe & Apple
The above declaration paved the way for supporting (CFF-based) OpenType Collections in Apple’s OS X (beginning from Version 10.8) and in Adobe’s applications (beginning from CS6).
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 Communications for designing the glyphs for these characters.
As I described in an article earlier this year, GB 18030 artificially imposes a visual difference between Radicals #74 (⽉) and #130 (⾁) for character pairs that differ only in this component, though conventions for Simplified Chinese use a unified form that looks like Radical #74. In that article I pinpointed a case for which the character that uses Radical #130 is in error, because its left-side radical uses the Radical #74 form, and the corresponding character that uses Radical #74 is outside the scope of GB 18030 (at least for now).
Thanks to Jaemin Chung, I was able to find three errors within the scope of GB 18030, as shown below:
According to the principles imposed by GB 18030, the characters on the left are in error, and should be visually distinct from those on the right in terms of their left-side radical.
For the first time in my life, I visited three East Asian countries in a single trip: China, South Korea, and Japan. I have had trips that involved two countries—South Korea & Japan, China & South Korea—but never three. This particular one was also done in the span of only one week.
The purpose of this trip was to visit the three type foundries who were involved in the Source Han Sans/Noto Sans CJK project: Changzhou SinoType (常州华文) in Changzhou, China; Iwata (イワタ) in Tōkyō, Japan; and Sandoll Communications (산돌커뮤니케이션) in Seoul, South Korea. In addition to thanking each company in person, we also used the opportunity to discuss particulars of the project, in terms of what worked well and what didn’t, and I also demonstrated the processes that I used to take their raw glyph data and turn it into the final fonts. All three companies gave us a warm welcome, and were very gracious hosts. We had excellent lunches and dinners with all three companies, which allowed for greater social interaction.
Masataka HATTORI (服部正貴) from our Tōkyō office traveled with me to China and South Korea, and Jinho KANG from our Seoul office participated in the meeting with Sandoll Communications. In addition to Masataka, Taro YAMAMOTO (山本太郎) participated in the meeting with Iwata.
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. ☺
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.
For those who are not aware, there are twelve IDCs (Ideographic Description Characters) in Unicode, from U+2FF0 through U+2FFB, that are used in IDSes (Ideographic Description Sequences) which are intended to visually describe the structure of ideographs by enumerating their components and arrangement in a hierarchical fashion. Any Unicode character can serve as a IDS component, and the IDCs describe their arrangement. The IRG uses IDSes as a way to detect potentially duplicate characters in new submissions. All existing CJK Unified Ideographs have an IDS, and new submissions require an IDS.
This article describes a technique that uses IDSes combined with OpenType functionality to pseudo-encode glyphs that are unencoded or not yet encoded. If memory serves, it was Taichi KAWABATA (川幡太一) who originally suggested this technique.
[For those who are interested in reading my own release notes for the Adobe-Japan1-6 UTF-32 CMap resource history, which includes the non-JIS2004 ones, I made them available here on January 20, 2016.]
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.