Early last August, I celebrated the release of Microsoft’s Windows 10 Anniversary Update (Version 1607, and also known as Redstone 1 or RS1), mainly because it represented the very first version of Windows OS to support OpenType/CFF Collections (aka OTCs). Alas, my favorite Source Han Sans—and now Source Han Serif—deployment format, the Super OTC that packs all of the fonts into a single and easy-to-manage font resource, could not be installed.
It seems that not a day goes by that I am not using Adobe InDesign CC.
It is my preferred document-authoring app, whether I am preparing a relatively simple single-page document or one that is much longer and complex.
Besides being the world’s first open source serif-style Pan-CJK typeface families, the Adobe-branded Source Han Serif and the Google-branded Noto Serif CJK also represent the first broad deployment of two highly-complex and related ideographs that are in the process of being encoded. Their glyphs are shown above in all seven weights. Although it may be hard to believe, the fourth line illustrates the simplified version.
Perhaps as a continuation of this article from almost a year ago with a clever image, I’d like to use this opportunity to mention that the AFDKO tx tool is about to get a new and improved CFF subroutinizer.
The tx tool has actually had a CFF subroutinizer for quite some time, since late 2008 or so, which is invoked by using the “+S” command-line option in combination with the “-cff” command-line option, and while it was noticeably faster than the AFDKO makeotf tool’s built-in subroutinizer, there were issues that prevented me from using it, such as recursion depth and the inability to limit the number of local and global subroutines.
Based on my testing thus far—using my trusty 2014 Apple MacBook Pro—the tx tool’s new subroutinizer is over three orders of magnitude faster that the makeotf tool’s built-in one. Yes, over one-thousand times faster! CIDFont resources that once took hours to subroutinize now take mere seconds, and with comparable results both in terms of number of subroutines and reduced CFF size. The 65,535-glyph Source Han Sans CIDFont resources take approximately 30 seconds to become subroutinized CFFs, and the 23,058-glyph Kozuka Gothic Pr6N (小塚ゴシック Pr6N) and Kozuka Mincho Pr6N (小塚明朝 Pr6N) ones take less than 10 seconds each.
Anyway, the next release of AFDKO will include a version of the tx tool that includes this new and improved subroutinizer. Of course, the primary beneficiaries of this new version are those who build OpenType/CFF fonts that include thousands or tens of thousands of glyphs, like me.
In closing, I’d like to draw attention to the open source otfcc project on GitHub, which apparently provides similar CFF subroutinization results, in terms of speed and the end result.
This article is largely a test, but also serves to start the process of resurrecting L2/14-006 (Proposal to add standardized variation sequences for nine characters) for discussion at UTC #151 in early May.
Liang Hai (梁海) brought up this document for discussion at UTC #150 last week, and while I had an opportunity to have it accepted by the UTC, to be included in Unicode Version 10.0 (June, 2017), I decided that it was prudent to instead prepare a revised proposal that is more complete, mainly because L2/14-006 was submitted and discussed prior to the first release of the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK Pan-CJK typeface families. This functionality was implemented in those typeface families via the 'locl' GSUB feature, which requires the text to be language-tagged. In other words, I learned a lot since L2/14-006 was discussed, and prefer to submit a more complete proposal, even if it means waiting for Unicode Version 11.0 (June, 2018).
As recorded on the very first page of Adobe Tech Note #5078, Adobe-Japan1-6 was released on 2004-03-05, and one of the glyphs that was added was CID+20958. According to the Adobe-Japan1-6 ordering file, its glyph name is freedial, and is assigned to the Dingbats FDArray element for the purpose of hinting. Of course, if you look for CID+20958 in Adobe Tech Note #5078, you can find it on the bottom of page 54, immediately to the right of CID+20957 that maps from U+26BD ⚽ SOCCER BALL, though it is blank. This is simply because Adobe does not have the rights to use NTT’s trademarked FreeDial mark. CID+20958 was included in Adobe-Japan1-6 for the benefit of font developers who do have the rights to use this mark, and can thus include the glyph in their fonts.
Please pardon the apparent non-CJK interruption in the form of this particular article, but I wanted to bring to the readership’s attention a new open source project that has a very long history: ehandler.ps.
Unlike the first and second similarly-titled articles that I published last month, this article will focus on a minor efficiency for the combining jamo feature of the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK Pan-CJK typeface families.
To (significantly) expand yesterday’s super exciting article, and in the continued interest of (stress-)testing the extent to which combining jamo works in various browsers—and when being served as a fully-functional webfont via Adobe Typekit—if you click here, you will open a 40MB HTML file that includes all 1,626,875 possible three-character combining jamo sequences (125 leading consonants, 95 vowels, and 137 trailing consonants) rendered using Adobe Clean Han and its 'ljmo' (Leading Jamo Forms), 'vjmo' (Vowel Jamo Forms), and 'tjmo' (Trailing Jamo Forms) GSUB features.
In the interest of testing the extent to which combining jamo works in various browsers—and when being served as a fully-functional webfont via Adobe Typekit—if you click here, you will open a 200K HTML file that includes all 11,875 possible two-character combining jamo sequences (125 leading consonants and 95 vowels) rendered using Adobe Clean Han and its 'ljmo' (Leading Jamo Forms), 'vjmo' (Vowel Jamo Forms), and 'tjmo' (Trailing Jamo Forms) GSUB features.
Again. I arrived on the afternoon of 2016-10-16.
This month provided to me yet another opportunity to visit Japan, the Land of the Rising Sun and my wife’s home country, thanks to IRG #47 (Ideographic Rapporteur Group Meeting #47) being hosted there. This trip was also the first time for me to visit an island of Japan other than Honshū (本州), specifically Shikoku (四国).
As a follow on to our seven-year-old May of 2009 article of the same name, several things have happened with the Adobe Clean family that have yet to be reported, and which have CJK implications. Hence the reason for spending my Sunday morning writing this article.
In the following year, 2010, I developed and deployed a Japanese version of Adobe Clean named Ryo Clean PlusN (りょう Clean PlusN in Japanese), and then in 2015, I developed and deployed a Pan-CJK version named Adobe Clean Han (Adobe Clean 黑体 in Simplified Chinese, Adobe Clean 黑體 in Traditional Chinese, Adobe Clean 角ゴシック in Japanese, and Adobe Clean 고딕 in Korean). These typeface families are Adobe corporate fonts that are meant to be used for product literature, for serving to Adobe websites, and for use by Adobe apps. They are not meant to be used by our customers, but I suspect that the readership of this blog may be interested in some of the development details. If this interests you, please continue reading.
August 2, 2016 is the official release date for Microsoft’s Windows 10 Anniversary Update (aka Redstone or RS1). Although I do not use Windows OS, I am jumping for joy, for the benefit of those who do use this modern and world-class OS.
Thanks to our friends at Microsoft, the DirectWrite that ships with the Windows 10 Anniversary Update supports OpenType/CFF Collections (aka OTCs), such as those deployed as part of the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK open source projects, to include their all-inclusive “one font to rule them all” Super OTCs.
It seems that I am on roll, having released two new open source fonts on GitHub within the past week. The previous—and brief—article that was about the LOCL Test OpenType/CFF font simply pointed to the repository. This article will be longer. I promise.
—Humans make mistakes—
—Anything made by humans has the potential to include mistakes—
The most important things about mistakes are that 1) we recognize them, lest they propagate; 2) we learn from them; 3) we make an effort not to repeat them; and 4) we try to fix them, if possible.
Some mistakes are more easily fixed than others. Mistakes that cannot be fixed must be worked around.
With that said, an interesting event of historical significance occurred in June of 2000:
The first version of the IVD (Ideographic Variation Database) was issued on 2007-12-14, meaning over eight years ago, and there have been three subsequent revisions, the latest being issued on 2014-05-16. There are currently three registered IVD collections: Adobe-Japan1, Hanyo-Denshi, and Moji_Joho. A significant number of IVSes are shared between the latter two IVD collections, 9,685 to be exact. While I cannot speak to the latter two IVD collections, the Adobe-Japan1 one is supported by hundreds of OpenType fonts via the Format 14 (Unicode Variation Sequences) ‘cmap‘ subtable. Furthermore, the number of apps and OSes that support UVSes has reached critical mass.
With all that said, there is a rather substantial missing link in terms of IVD support infrastructure: the all-important input method.
One of my longer term goals for the open source Source Han Sans project has been to eventually register a Pan-CJK IVD (Ideographic Variation Database) collection that would allow the regional variants to display and be preserved in “plain text” environments, and I think that I may have achieved a breakthrough the other day.
While I won’t repeat here any of the exciting details in Typekit’s recent announcement for East Asia web font support (简体中文, 繁體中文, 日本語, 한국어) that employs dynamic kits, I’d like to seize this opportunity to demonstrate some of the default behavior that this new development exposes in various browsers.
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