(この記事中の貂の写真はすべて Adobe Stock で見つけることができます)
English (英語) here
この記事の目的は、Typekit から提供される「貂明朝」(Ten Mincho) の書体とフォント開発について技術的詳細を説明することにあります。貂明朝は、これまでどんな日本語フォントも到達しなかった領域に足を踏み入れました。貂明朝の書体デザインについての詳細については、Typekit Blog 上の公式アナウンスメント (英語) の方をご覧ください。この長文の技術的な記事よりも、そちらの方に興味を持たれるかもしれません。公式アナウンスメントに述べられているように、この新しい Adobe Originals の和文書体にはユニークな特長が数多くあります。そのため、日本や各国の書体メーカー、タイプデザイナーの方々はこの書体からインスピレーションを受けられることでしょう。
(All of the marten photos that are used in this article can be found on Adobe Stock)
日本語 (Japanese) はこちら
The purpose of this article is to provide technical details of how the Ten Mincho—貂明朝 in Japanese—typeface and its fonts, which are initially being offered as a Typekit exclusive, were developed, and how they boldly go where no Japanese font has gone before. For more details about the Ten Mincho typeface design itself, which is probably much more interesting than this really long and technical article, I encourage you to read the official announcement (日本語) on the Typekit Blog. As stated in the official announcement, this new Adobe Originals Japanese typeface is unique in many ways, and should serve as inspiration for type foundries and typeface designers in Japan and elsewhere.
Today’s article provides useful details for our relatively small number of customers who author documents with our flagship Creative Cloud apps and make use of CID-keyed OpenType SVG fonts. A rather broadly-deployed CID-keyed OpenType SVG typeface is the open source Source Han Code JP family, whose development details are described in the very first section of this article.
While it is fully possible to build OpenType fonts—CID-keyed or otherwise—that include an 'SVG ' (Scalable Vector Graphics) table, the infrastructure to support them in apps is still maturing. That is the purpose of this article, so please continue reading if the details interest or otherwise affect you.
Earlier this month, I decided to move the Adobe-Japan1-6 character collection specification to the Adobe Type Tools organization on GitHub, which was partly motivated by constantly-changing URLs on our Font Technical Notes page. Another motivation was to make the specification itself easier to maintain. At some point, I will be adding a more complete list of Supplement 7 (aka Adobe-Japan1-7) candidates to its wiki.
To this end, I decided to do the same for the Adobe-CNS1-7 and Adobe-GB1-5 character collection specifications while on vacation in South Dakota. For the former, I also used the opportunity to update the specification to include Supplement 7 (aka Adobe-CNS1-7), by adding its representative glyphs and other details.
So, that’s three down, and one to go.
This is a very brief article whose purpose is to simply state that—due to recent events beyond my control*—the Adobe-Japan1-6 character collection specification is now an open source project that is hosted on GitHub as a new repository in the Adobe Type Tools organization.
Most of my morning was consumed by porting the original text from Adobe InDesign to GitHub-flavored Markdown, and, while I was touching the text, I decided to seize the opportunity to make several corrections and updates. The 500-glyphs-per-page representative glyph charts are now in a separate PDF file. I also used the opportunity to update the aj16-kanji.txt datafile, and also added the latest-and-greatest Adobe-Japan1-6 UVS (Unicode Variation Sequence) definition file. All good stuff, I think.
* Adobe’s IT folks apparently felt compelled to (once again) change the URLs for all of the font-related Adobe Tech Notes, including Adobe Tech Note #5078 (The Adobe-Japan1-6 Character Collection). Its URL is somewhat broadly referenced, including in the IVD_Collection.txt file of the latest version of the IVD (Ideographic Variation Database). The bottom line is that I needed a stable URL.
It is difficult to imagine that it has been over 20 years since a new RO—or Adobe CID-keyed glyph set—was born. Of course, I am referring to the static glyph sets, not the ones based on the special-purpose Adobe-Identity-0 ROS.
“RO” stands for Registry and Ordering, which represent compatibility names or identifiers for CID-keyed glyph sets that are referred to as character collections. Adobe CID-keyed glyph sets are usually referred to as ROSes, with the final “S” being an integer that refers to a specific Supplement. The first Supplement, of course, is 0 (zero).
One of my recent projects is to revitalize and modernize our Korean glyph set, Adobe-Korea1-2 (see Adobe Tech Note #5093), which was last modified on 1998-10-12 by defining Supplement 2 that added only pre-rotated versions of the proportional and half-width glyphs that are referenced by the effectively-deprecated 'vrt2' (Vertical Alternates and Rotation) GSUB feature. Instead of defining a new Supplement, I decided that it would be better to simply define a completely new glyph set for a variety of reasons. The tentative Registry and Ordering names are Adobe and KR (meaning “Adobe-KR”), and unlike other ROSes for which Supplements are defined incrementally, my current plan is to simultaneously define seven Supplements, 0 through 6.
Per a suggestion by a friend named Leroy, I recently renamed the multiple-style and multiple-family OTCs (OpenType Collections) in this open source repository which includes such OTCs that are based on the Adobe-branded Source Han and Google-branded Noto CJK families. These multiple-style and multiple-family OpenType Collections were described in this article from April of this year. The purpose of this particular article is to introduce better names for them besides Super OTC.
First, some background about Super OTCs…
Shortly after Source Han Sans and Noto Sans CJK were released, I came up with the idea of creating a single OpenType Collection that includes all languages and all weights, and the name Super OTC was coined. This was included in the Version 1.001 update (2014-09-12) as a fourth deployment format for both families, and each one included 28 fonts. These were expanded to 36 fonts when the HW (half-width, ASCII-only) fonts, which covered only the Regular and Bold weights, were added as part of the Version 1.002 update (2015-04-20). Source Han Serif and Noto Serif CJK included a Super OTC in their Version 1.000 release (2017-04-03).
There has been a flurry of IVD (Ideographic Variation Database) activity this year.
First, UTS #37 (Unicode Ideographic Variation Database) was updated at the end of January to allow characters with the “Ideographic” property to serve as valid base characters in an IVS (Ideographic Variation Sequence). This effectively means that the Tangut (西夏文) and Nüshu (女书/女書) scripts can now participate in the IVD.
At seemingly every opportunity, whether via this blog or during public speaking engagements, I have made it abundantly clear that the Adobe-branded Source Han families share the same glyph set as the corresponding Google-branded Noto CJK families. That is simply because it is true. What requires a bit of explanation, however, is how the two typeface designs—Source Han Sans and Source Han Serif—differ. That is what this particular article is about.
As the Project Architect of these Pan-CJK typeface families, I have my fingers on all of the data that was used during their development, and for preparing each release. I can therefore impart some useful tidbits of information that cannot be found elsewhere.
To take the previous article further—and because I tend to have an urge to stress-test environments—I added two more Super OTCs to the Source Han Super OTC open source project this morning.
The release of Source Han Serif earlier this month, on 2017-04-03, gave me an opportunity to build yet another resource for stress-testing environments, particularly those that consume OpenType/CFF Collections. (This also continues to simplify file management by combining three Super OTCs into a much larger one.)
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.
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.
Or, perhaps more accurately, the project that has been keeping me busy for the past couple of years.
The Adobe-branded Source Han Serif (named 源ノ明朝 in Japanese, 본명조 in Korean, 思源宋体 in Simplified Chinese, and 思源宋體 in Traditional Chinese) and Google-branded Noto Serif CJK open source Pan-CJK typeface families, which represent the serif-style counterparts to the similarly-named and also open source Source Han Sans and Noto Sans CJK Pan-CJK typeface families, were released on 2017-04-03. You can read more about the Source Han Serif release here (日本語—한국어—简体中文—繁體中文), which includes a six-minute promotional video.
This article provides information that you would not expect to find in the official announcements for Source Han Serif or Noto Serif CJK, mainly because such information is intended for a completely different audience, which is primarily comprised of font developers.
Unless noted otherwise, all further references to Source Han Serif or Source Han Sans will apply to Noto Serif CJK or Noto Sans CJK, respectively.
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.
The IVD (Ideographic Variation Database) is all about ideograph variants. Up until earlier this year, its scope was limited to CJK Unified Ideographs, per UTS #37 (Unicode Ideographic Variation Database). Its scope now includes characters with the Ideographic property that are not canonically nor compatibly decomposable, which still excludes CJK Compatibility Ideographs.
In an ideal world, a particular glyph—whether it’s considered the standard (aka encoded) form or an unencoded variant of the standard form—would be associated with a single registered IVS (Ideographic Variation Sequence) within an IVD collection. However, we do not live in a perfect world, and several real-world conditions can lead to duplicate sequence identifiers within an IVD collection.
I will open this article by stating that OpenType features are almost always GSUB (Glyph SUBstitution) or GPOS (Glyph POSitioning). The former table specifies features that substitute glyphs with other glyphs, usually in a 1:1 fashion, but not always. The latter table specifies features that alter the metrics of glyphs, or the inter-glyph metrics (aka kerning).
The focus of this particular article will be the 'vert' (Vertical Alternates) feature, which substitutes a glyph with the appropriate glyph for vertical writing, and is invoked when in vertical writing mode. In other words, it’s a GSUB feature, and one that needs to be invoked for proper vertical writing. Current implementations that support the 'vert' GSUB feature, which tend to be CJK fonts, substitute glyphs with their vertical forms on a 1:1 basis, though language-tagging may affect the outcome for Pan-CJK fonts, such as the Adobe-branded Source Han Sans and the Google-branded Noto Sans CJK, which support multiple languages.
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.