Posts in Category "Type"

横組みと縦組みのどちらにも対応する可変字幅のバリアブルフォントによる実現方法

English (英語) here

(翻訳:Adobe Type チーム 山本太郎)

グリフの可変字幅を可能にしながら、縦組みでのグリフの回転が必要となる欧文や和文組版における縦中横(縦組み行の中に横組みの要素が入る)の組み方も取り扱えるモデルを、最近考案しました。

本記事の目的は、私が開発したオープンソースのフォントと、その動作モデルの記述に関心を寄せていただくことにあります。そのフォントに対応するアプリケーションソフトウェアとレイアウトエンジンを実装する開発者に活用していただくことを意図したものです。
Continue reading…

Adobe-Japan1-7 GSUB Features

For Adobe-Japan1–based OpenType/CFF Japanese fonts that support the glyph or glyphs for U+32FF ㋿ SQUARE ERA NAME REIWA (Unicode Version 12.1), meaning Adobe-Japan1-7 CID+23058 or CIDs 23058 and 23059, font developers need to be aware that adjustments to a small number of GSUB (Glyph SUBstitution) features are necessary to make them more easily accessible or simply usable.
Continue reading…

Horizontal & Vertical Compression/Expansion via Variable Fonts

日本語 (Japanese) はこちら

I recently came up with a Variable Font model to handle glyph compression and expansion in horizontal and vertical layout that includes support for characters whose glyphs rotate in vertical layout, such as the glyphs for Western characters, along with TCY (縦中横 tatechūyoko in Japanese, which literally means “horizontal in vertical”) support.

The purpose of this article is to call attention to the open source test font that I developed, along with a description of the model itself, which are intended to be used by developers to implement such support in apps and layout engines.
Continue reading…

Source Han Mono Version 1.000 Technical Nuggets

As the readership of this blog should know, I updated the Source Han Sans and Noto Sans CJK fonts to Version 2.001 early last month, mainly to accommodate the glyphs for U+32FF ㋿ SQUARE ERA NAME REIWA, which is the two-ideograph square ligature form of Japan’s new era, Reiwa (令和), that began on 2019-05-01. I then seized the opportunity to update our corporate Adobe Clean Han typeface family, to bring it into alignment with Source Han Sans Version 2.001. The updated Adobe Clean Han fonts are now being served to this blog.

I then decided to embark on a somewhat ambitious project to develop a new open source typeface named Source Han Mono, which is best described as a Pan-CJK version of Source Han Code JP, first developed four years ago by my esteemed colleague in our Tōkyō office, Masataka Hattori (服部正貴). You can read the background here. This effectively closes Issue #2 in the Source Han Code JP project.

Source Han Mono is a derivative typeface design of Source Han Sans, designed by my colleague Ryoko Nishizuka (西塚涼子), and Source Code Pro, designed by my colleague Paul D. Hunt. Its localized names are 源ノ等幅 (Japanese), 본모노 (Korean), 思源等宽 (Simplified Chinese), 思源等寬 (Traditional Chinese—Taiwan), and 思源等寬 香港 (Traditional Chinese—Hong Kong SAR). (As an aside, the reason why the Traditional Chinese—Hong Kong SAR name, 思源等寬 香港, appears correctly is due to the updated Adobe Clean Han fonts. This benefitted the glyphs for U+7B49 and U+9999 .)

This article will detail some of the challenges that I faced, along with some of the decisions that I made, while developing this new Pan-CJK typeface family.
Continue reading…

Adobe Clean Han Version 2.001

The recent Source Han Sans Version 2.001 update provided to me an excellent opportunity to bring Adobe Clean Han, Adobe’s corporate Pan-CJK typeface, into alignment. I am pleased to announce that, as of yesterday, the updated Adobe Clean Han fonts are now being served to this blog via Adobe Fonts.

To celebrate this significant update, I decided that it would be appropriate to illustrate—using live text that can be easily copied and repurposed elsewhere—the 68 ideographs that include five separate glyphs, one for each of the five supported regions/languages:

Continue reading…

Simplified Chinese
傑僭割劘匾叟喝塌姿嬴幰廋扇扉搨摩榻溲潛瀛瘦瞎磨窖竇箭篠簉糙綢纛羸翁翦翩肓臝艘花裯褐謁譖豁贏轄返迷途造週遍遭選遼鄰釁閼雕靠靡颼飯驎鬣魔麗麟

Adobe Blank VF & Friends

I spent the last couple of weeks developing a Variable Font version of the infamous Adobe Blank, and the open source project, named Adobe Blank VF & Friends, was released yesterday evening. But, before I detail what makes the Variable Font versions special, besides being Variable Fonts, let’s briefly go over the history of Adobe Blank and Adobe Blank 2.

Adobe Blank

First released in 2013 as open source, Adobe Blank simply maps all 1,111,998 Unicode code points to non-spacing and non-marking glyphs. What made the project interesting for me was to find the right balance between the number of glyphs and the size of the 'cmap' table. When mapping over a million code points, this becomes a valid concern. After some experimentation, I found that 2,049 glyphs was the sweet spot that resulted in 'CFF ' and 'cmap' tables of a relatively small size.

Adobe Blank 2

Adobe Blank 2, which was first released in 2015, is a two-glyph version of Adobe Blank that includes a Format 13 (Many-to-one range mappings) 'cmap' subtable that maps all 1,111,998 Unicode code points to GID+1. At the time, there was no convenient way to create a Format 13 subtable, so I used ttx, and supplied the actual hex values of the compiled subtable. The current version of ttx can successfully compile a Format 13 subtable by explicitly specifying all 1,111,998 mappings.

That then brings us to the Variable Font versions…
Continue reading…

Source Han Sans Version 2.001

The earlier part of this year was spent preparing new and revised glyphs for the Source Han Sans and Google-branded Noto Sans CJK Version 2.001 update, which also involved changing several mappings. The fonts for the former Pan-CJK typeface family were released today, and as usual, the all-inclusive—and highly-recommended—45-font Super OTC (OpenType Collection) is easily downloaded from the latest release page. See the official ReadMe (will download if clicked) for more details about this release. 70 of the Source Han Sans Version 2.001 fonts are also available via Adobe Fonts (formerly Adobe Typekit).
Continue reading…

Adobe-Japan1-7 Published!

 

Japan announced the name of their new era, 令和 (reiwa), today. This announcement has set several things into motion, one of which is the publishing of the Adobe-Japan1-7 specification that adds CIDs 23058 and 23059 as the respective horizontal and vertical forms of the two-kanji square ligature form that will be encoded as U+32FF ㋿ SQUARE ERA NAME REIWA in Unicode Version 12.1. Font developers can now reference the Adobe-Japan1-7 specification.
Continue reading…

A Brief History of Japan’s Era Name Ligatures

In exactly 10 days, Japan is expected to reveal the name of its next era that will begin on 2019-05-01.

This article will cover several important standards or events that are related to the two-kanji square ligature forms of the current era name, the previous three, and the forthcoming one.
Continue reading…

Source LOCL Test

This is a brief article to draw readers’ attention to my latest test font, which is a 12-font 65,535-glyph OpenType/CFF Collection that is intended to test how well an app or other font-consuming environment supports language tagging for East Asian text, to include the handling of localized strings, such as those for menu names in the 'name' table, and for named Stylistic Set 'GSUB' features.

The Variable Font Collection test fonts that were made available at the beginning of this month serve this purpose to some extent, but they also require an environment that supports not only Variable Fonts (aka OpenType/CFF2 fonts), but also Variable Font Collections (aka OpenType/CFF2 Collections). The main intent of this OpenType/CFF Collection is to remove the Variable Font baggage from the testing requirement. It also includes support for Macao SAR as a third form of Traditional Chinese, which was described in the previous article.

Please visit the open source Source LOCL Test project for more details, or to download the pre-built OpenType/CFF Collection binary from the Latest Release page.

Enjoy!

🐡

Variable Font Collections

This is a short article that is simply meant to draw developers’ attention to three OpenType/CFF2 Collections (aka Variable Font Collections) that I built this week, which are now available in the open source Variable Font Collection Test project. As stated in the project, the purpose of these Variable Font Collections is to simulate the Source Han and Noto CJK fonts deployed as Variable Fonts, to help make sure that the infrastructure—OSes, apps, layout engines, libraries, and so on—will support them. Remember that it took several years for Microsoft to support OpenType/CFF Collections (OTCs), which finally happened on 2016-08-02. In other words, this is not trivial.
Continue reading…

さらば、CID フォント!

“Everything that has a beginning, has an end. I see the end coming.” — The Oracle

To first provide some background, I started to work at Adobe right before we invented CID-keyed fonts. The first desktop (aka non-printer) deployment of CID-keyed fonts was in the form of “Naked-CID fonts” in 1993 or so, which required ATM (Adobe Type Manager) to be installed. While such fonts were available for Macintosh and Windows OSes, Naked-CID fonts for the latter OS were incredibly short-lived and therefore rare, and were subsequently replaced with OpenType/CFF fonts in the late 1990s. Naked-CID fonts for the former OS were replaced by “sfnt-wrapped CIDFonts” (aka “sfnt-CID fonts”) in the mid-1990s, and also required that ATM be installed. Adobe Tech Note #5180, entitled “CID-Keyed sfnt Font File Format for the Macintosh,” details the sfnt-wrapped CIDFont format, which is specific to Macintosh due to its use of a resource fork.

With that stated, fonts are among the most perpetual and resilient of digital resources, meaning that discontinuing support for legacy font formats cannot be done quickly, and many years must pass before it can be realistically considered.
Continue reading…

Source Han Sans Version 2.000 Technical Tidbits

日本語 (Japanese) はこちら

(Everything that is stated in this article applies to the corresponding Google-branded Pan-CJK typeface family, Noto Sans CJK. Likewise, any reference to Source Han Serif also applies to Noto Serif CJK.)

The last time that a new version of the Source Han Sans family, along with the Google-branded version, Noto Sans CJK, was released was in June of 2015 in the form of Version 1.004. I know from personal experience that a lot of planning, preparation, and work took place during the three years that followed, and the end result is Version 2.000 of both Pan-CJK typeface families.

If you’re interested in learning more details about some of the changes, enhancements, and additions that Version 2.000 offers, please continue reading this article.
Continue reading…

Ten Mincho Redux: SVG & Text

日本語 (Japanese) はこちら

Flashback to almost exactly a year ago.

We released Ten Mincho (貂明朝) Version 1.000 during MAX Japan 2017, and I published this marten-laced article that provided technical details about its fonts. Now, a year later, and during MAX Japan 2018, we have released Version 2.003 of this cute and mischievous typeface family. Please continue to read if you have interest in details about the new and updated fonts that are included as part of this Japanese typeface family.
Continue reading…

帰ってきた「貂明朝」:SVG と「テキスト」

English (英語) here

(翻訳:Adobe Type チーム 山本太郎、西村美苗)

あれからほぼ一年たった。

貂明朝のバージョン 1.000 をリリースしたのは、昨年の MAX Japan 2017 開催中のことだった。そのフォントの技術的な詳細に関しては、この記事を書いて、おまけに、貂の写真を何枚も貼り付けておいた。さて 1 年後の今、同じく MAX Japan 2018 の開催期間中に、この妖しくも可愛い書体ファミリーのバージョン 2.003 をリリースした。この日本語書体ファミリーに新たに追加されたフォントやその他の改善点について、技術的詳細を知りたい方はこの記事を参照されたい。
Continue reading…

「源ノ角ゴシック」バージョン 2.000 の技術的な特長について

English (英語) here

(翻訳:Adobe Type チーム 山本太郎、西村美苗)

(この記事中の事項はすべて、Google の Pan-CJK 書体ファミリー、Noto Sans CJK にもあてはまる。源ノ明朝に言及している場合には Google の Noto Serif CJK にもあてはまる。)

源ノ角ゴシックファミリーを、Google により製品化されたバージョンである Noto Sans CJK ファミリーも含めて、バージョン 1.004 にアップデートしたのは、2015 年 6 月だった。以来、さまざまな計画を立案し、また膨大な量の準備と作業を積み重ねてきた。その結果、Pan-CJK フォントファミリー:源ノ角ゴシックと Noto Sans CJK のバージョン 2.000 が誕生した。

バージョン 2.000 での変更・改良点の詳細について関心があれば、以下を参照されたい。
Continue reading…

“Strange Things Are Afoot at the Circle K” → U+327F ㉿

This week once again proved that one is never too old to learn something new.

My friends at Sandoll Communications (산돌커뮤니케이션) kindly informed me earlier this week that the offical Korean Standards Association (한국표준협회/韓國標準協會) logo, U+327F ㉿ KOREAN STANDARD SYMBOL, which has been encoded in Unicode from the very beginning (Version 1.1), is generic, both in terms of typeface design and weight, and that there is an actual specification for its design. This character is included in Unicode because it was also included in the KS X 1001 (정보 교환용 부호(한글 및 한자)) standard at position 02-62. The very bottom of the specification page on the KSA website includes a link to a ZIP file that contains the image for the KSA logo in two forms: a 592×840-pixel JPEG image and an Adobe Illustrator vector image file.
Continue reading…

About Adobe-Japan1-7 Font Names

日本語 (Japanese) はこちら

The feedback that we received from the previous article on this subject has been extraordinarily valuable. Our proposal to leave the names of Adobe-Japan1-7 subset fonts unchanged met with virtually unanimous agreement, but given the relatively minor nature of the Adobe-Japan1-7 additions, to the tune of only two glyphs, the same naming policy seems to benefit Adobe-Japan1-6 fonts as well.

In other words, fonts that currently support Adobe-Japan1-6 in its entirety can be updated to Adobe-Japan1-7 without changing their names. Of course, the advertised Supplement value as recorded in the 'CFF ' table should reflect 7. The following is a revised version of the table from the previous article on this subject:

Supplement Designator JIS2004-Savvy Designator /CIDFontName & Menu Name Examples
3 Std StdN KozMinStd-Regular, 小塚明朝 Std R
KozMinStdN-Regular, 小塚明朝 StdN R
4 Pro ProN KozMinPro-Regular, 小塚明朝 Pro R
KozMinProN-Regular, 小塚明朝 ProN R
5 Pr5 Pr5N KozMinPr5-Regular, 小塚明朝 Pr5 R
KozMinPr5N-Regular, 小塚明朝 Pr5N R
6 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R
7 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R

Of course, we still welcome any and all feedback about this font-naming issue.

🐡

Adobe-Japan1-7 のフォント名について

English (英語) here

先のブログ記事について、既にいくつか貴重なフィードバックを受け取っている。Adobe-Japan1-7 のサブセットとなるフォントの名前を変えずにそのままにしておくという提案については、ほぼ大方の賛同を得ることができたが、Adobe-Japan1-7 での追加が二つのグリフだけに限定されるため、Adobe-Japan1-6 対応のフォントについても、名前を変えない方が良いという意見があった。

言い換えれば、現時点で Adobe-Japan1-6 に対応しているフォントは、名前を変更せずに Adobe-Japan1-7 にアップデートできるということだ。もちろん、CFF テーブルに記録されるべき Supplement の値は「7」に設定しておく必要がある。この考えに沿って、前回の記事の表を以下のように修正した。

Supplement Designator JIS2004-Savvy Designator /CIDFontName & Menu Name Examples
3 Std StdN KozMinStd-Regular, 小塚明朝 Std R
KozMinStdN-Regular, 小塚明朝 StdN R
4 Pro ProN KozMinPro-Regular, 小塚明朝 Pro R
KozMinProN-Regular, 小塚明朝 ProN R
5 Pr5 Pr5N KozMinPr5-Regular, 小塚明朝 Pr5 R
KozMinPr5N-Regular, 小塚明朝 Pr5N R
6 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R
7 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R

もちろん、このフォント名の問題についてすべてのフィードバックを歓迎する。

🐡

Adobe-Japan1-7 のサブセットフォント

English (英語) here

新元号に対応した Adobe-Japan1-7 サブセットフォント作成方法の提案とフィードバックのお願い

前回の記事で述べたように、日本で新しい元号が発表されると、まもなく Adobe-Japan1-6 文字コレクションの仕様が Adobe-Japan1-7 へ更新される。この記事では、フォントの更新に必要となる作業を説明、提案する。読者からのフィードバックを歓迎する。)

Adobe-Japan1-6 に含まれる 23,058 個のグリフを全てサポートしている日本語の OpenType フォントについては、Adobe-Japan1-7 に更新するのは比較的シンプルだ。二つのグリフとそれに関連するマッピングを追加、そして Adobe-Japan1-7 の識別子を使用してそのフォントに名前をつければ完成だ。だが、もちろん、すべてのフォントに新年号用合字を加えて、Adobe-Japan1-7 にアップデートする必要はない。この記事はアップデートしたいフォントがある場合に、フォント開発者に参照していただきたい。

まず、「OpenType Font Development」のサブセクションの「JIS2004-Savvy OpenType Fonts」にある表は以下のようにアップデートする必要があることは明らかだ。

Supplement Designator JIS2004-Savvy Designator /CIDFontName & Menu Name Examples
3 Std StdN KozMinStd-Regular, 小塚明朝 Std R & KozMinStdN-Regular, 小塚明朝 StdN R
4 Pro ProN KozMinPro-Regular, 小塚明朝 Pro R & KozMinProN-Regular, 小塚明朝 ProN R
5 Pr5 Pr5N KozMinPr5-Regular, 小塚明朝 Pr5 R & KozMinPr5N-Regular, 小塚明朝 Pr5N R
6 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R & KozMinPr6N-Regular, 小塚明朝 Pr6N R
7 Pr7 Pr7N KozMinPr7-Regular, 小塚明朝 Pr7 R & KozMinPr7N-Regular, 小塚明朝 Pr7N R

だが、下位の Supplement だけをサポートする JIS90 対応のフォント、あるいは、上位の Supplements から少数のグリフのみを取り入れて JIS2004 対応としているフォントについては、どのように対処すべきだろうか。以下に詳述する。

全ての日本語フォントが Adobe-Japan1-6 で指定された 23,058 個のグリフ全てを含んでいるわけではなく、多くのフォントが Adobe-Japan1-3 だけをサポートしている。その中には、JIS2004 対応とするために、上位 Supplements 4 ~ 6 の中から、144 個のグリフを追加したものもある。例えば、macOS にバンドルされた最新のヒラギノフォントは Adobe-Japan1-3 か Adobe-Japan1-5 をサポートし、JIS2004 に対応している。日本語書体のグリフをデザインするには膨大な時間と労力が必要だ。しかも、23,000 個以上のグリフが必要とされている場合でも、23,000 個のグリフ全てが頻繁に使われるわけではない。

そこで Adobe-Japan1-6 をフルにサポートしていないフォントをサポートするよう拡張するより、新元号の漢字から成る合字のグリフのみを追加したいという要求がまず生ずるだろう。そのために必要となる作業は以下のとおりだ。

JIS90 準拠の OpenType フォント

JIS90 に準拠する OpenType フォントの開発は比較的容易だった。というのもこれらのフォントはすでに定義されていた Supplements の中から一つを選び、そこに定義されているグリフ含めればよかったからだ。一般的な多くのフォントが、Adobe-Japan1-3(グリフ数 9,453)、Adobe-Japan1-4(グリフ数 15,444)、Adobe-Japan1-5(グリフ数 20,317)のいずれかとなっている。

Adobe-Japan1-7 と新元号用の二つのグリフを検討する場合、Supplement 3(別名 StdN)フォントには CID+23058(横書き用)だけが必要だ。現在と以前の年号の縦書き用合字は、Supplement 4 で初めて加えられたので、Supplement 3 ではサポート範囲外と見なすことができる。Supplement 4 とそれ以上のフォントでは、CID+23058 と CID+23059(縦書き用)を単に追加するだけだ。フォント名中の識別子 Pro、Pr5、Pr6 はそのままにし、CFF テーブル中、Supplement の値は「7」とする。

JIS2004 準拠の OpenType フォント

Adobe-Japan1-6 の文字コレクションは「OpenType Font Development」のサブセクションの「JIS2004-Savvy OpenType Fonts」にある下記の表の通りだ。JIS2004 に準拠するために上位の Supplements からのどのグリフを下位の Supplement をサポートするフォントに追加すべきかがわかる。

Supplement Additional Glyphs Designator CIDs & CID Ranges
3 144 StdN 4—9354, 9779, 12101, 12870, 13320–13327, 13330, 13332–13333, 13335–13341, 13343, 13345–13355, 13358–13369, 13371, 13373–13382, 13385–13388, 13391–13400, 13402, 13460, 13495, 13538, 13624, 13650, 13673, 13731, 13803, 13860, 13893, 13915, 13949, 13964, 14013, 14066, 14074, 14111, 14116, 14196, 14272, 14290
5—16977, 17041, 18760, 19312, 19346, 20175, 20222, 20263–20296, 20301–20305, 20307, 20314
6—21072–21074
4 81 ProN 5—16413, 16444–16449, 16467–16468, 16889, 16905, 16977, 17014, 17041, 17168, 17205, 18759–18760, 19061, 19312, 19346, 20175, 20222, 20263–20296, 20299–20310, 20312–20315
6—21071–21074, 21558, 21933, 22010, 22920
5 10 Pr5N 6—21071–21074, 21371, 21558, 21722, 21933, 22010, 22920

以下の表では、Adobe-Japan1-7 とその二つの新しいグリフを考慮に入れた場合、下位 Supplements をサポートするフォントがどのように調整されるべきかを示す。

Supplement Additional Glyphs Designator CIDs & CID Ranges
3 145 StdN 4—9354, 9779, 12101, 12870, 13320–13327, 13330, 13332–13333, 13335–13341, 13343, 13345–13355, 13358–13369, 13371, 13373–13382, 13385–13388, 13391–13400, 13402, 13460, 13495, 13538, 13624, 13650, 13673, 13731, 13803, 13860, 13893, 13915, 13949, 13964, 14013, 14066, 14074, 14111, 14116, 14196, 14272, 14290
5—16977, 17041, 18760, 19312, 19346, 20175, 20222, 20263–20296, 20301–20305, 20307, 20314
6—21072–21074
7—23058
4 83 ProN 5—16413, 16444–16449, 16467–16468, 16889, 16905, 16977, 17014, 17041, 17168, 17205, 18759–18760, 19061, 19312, 19346, 20175, 20222, 20263–20296, 20299–20310, 20312–20315
6—21071–21074, 21558, 21933, 22010, 22920
7—23058–23059
5 12 Pr5N 6—21071–21074, 21371, 21558, 21722, 21933, 22010, 22920
7—23058–23059

容易に見て取れるように、Supplement 3 のサブセットは Supplement 7 からの CID+23058 のみを含む。JIS90 準拠のフォントの項で説明したように、CID+23059 が含まれなくていい理由は現在と以前の三つの元号 U+337B「㍻」、U+337C「㍼」、U+337D「㍽」及び U+337E「㍾」の縦書き用合字が Supplement 4 に含まれていて、Supplement 3(別名 StdN)には含まれていないからだ。これらの合字のCIDは、Supplement 4 において、12041 から 12044 となっている。なお、「StdN」グリフセット(Adobe-Japan1-3 と Supplements 4 から 6 までの 144 個のグリフ)は 10 年以上安定しており、元号の縦書き用合字への要望はいままでなかったことを付け加えておく。

最後に、CFF テーブル中の Supplement の値は CID の末尾の値に合わせるべきであることを強調しておきたい。例えば、CID+23058 を含む Adobe-Japan1-3 フォントは「Std」フォントであっても「StdN」フォントであっても、「7」を Supplement 値に指定するべきである。

この記事に関してのフィードバックをお送りいただきたい。ここで提案した方法は理にかなっていると思うが、他のオプションを検討する時間もまだ十分にある。

🐡