English (英語) here

（翻訳：Adobe Type チーム 山本太郎）

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

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

テストフォント

テストフォントは二つの軸をもつバリアブルフォントで、1,111,998 個の Unicode のコードポイントを、UAX #50（Unicode Vertical Text Layout）のデータファイル「VerticalOrientation.txt」の Unicode 12.1 のバージョンに基づいて、次のグリフのどちらか一方に対応づけています。

• Vertical_Orientation（「vo」）の属性値に「R」または「Tr」が割り当てられている 785,553 個のコードポイントは欧文グリフに対応づけます。
• 「vo」属性値に「U」あるいは「Tu」が割り当てられている 326,445 個のコードポイントは CJK のグリフに対応づけます。

縦組みのレイアウトでは、姿勢が直立か、回転させたものかの違いが重要となるため、上記のコードポイントとグリフとの対応づけは妥当と考えられます。

ここで紹介するテストフォントには、欧文と CJK のグリフそれぞれ 256 個のインスタンスが含まれ、GID は 1 から 256 までと GID が 257 から 512 になります。その形とパラメータは下記のとおりです。

• 欧文のグリフは中空の矩形で、デフォルトの字幅は 600 ユニットで、欧文のベースライン（y = 0）に乗っていて、可変字幅の範囲は 450 から 750 までで、デフォルトの字幅から 25% まで狭いか広い字幅が可能です。
• CJK のグリフは全角の正方形で、デフォルトの字幅は 1000 ユニットで、欧文のベースラインより 12% 下方の位置にあります（Y = −120 から Y = 880 まで）。可変字幅の範囲は 750 から 1250 まで、デフォルトの字幅から 25% まで狭いか広い字幅が可能です。

それぞれのグリフに 256 のインスタンスを持たせている理由は、それによって「cmap」テーブルで指定される Unicode の対応づけを簡略化できるからです。このことは、対応関係が百万を超えるような場合に重要となります。

GID+513 は、縦中横で用いられる明示的に字幅が半角のグリフで、「hwid」（Half Widths—字幅半角）の GSUB フィーチャーを用いて欧文のグリフを置換するために用いられます。

このテストフォントには既に登録済みの「wdth」（Width—字幅）と未登録の「VWID」（Vertical Width—縦組み用字幅）のデザインのバリエーションの軸が含まれます。「縦組み用字幅」という訳語については、むしろ「垂直字送り量」という呼称が技術的にはより正確だとは認識していましたが、「字幅」の方が「wdth」軸との組み合わせという点では良いと思います。この両方の軸について、デフォルトの設定は 500 となっています。それは、横組みの欧文グリフの字送り量が 600 ユニットであることと、CJK グリフの 1000×1000 の正方形（字幅全角）のボディに対応したものです。設定値の最小値は 1 で、最大値は 1000 となっており、それぞれが 25% 狭い字幅と 25% 広い字幅とに対応します。

このテストフォントは GitHub 上のオープンソースの「Width & Vertical Width VF」プロジェクトにおいて、OpenType/CFF2 と TrueType の両方の形式で入手可能になっています。

横組みでの可変字幅のレイアウト

横組みのレイアウトを行う場合には、この記事の中で記述されているモデルは比較的単純です。「wdth」軸がグリフを望み通りに X 軸に沿って狭くしたり広げたりするために利用されます。「VWID」軸はそのデフォルトの設定に固定され、CJK のグリフ用の全角の字幅または 1000 ユニットに対応しています。言いかえれば、相対的なグリフの高さは横組みでは変化しないということです。

次に示す GIF アニメーションは、このテストフォントを用いて作成したもので、可変字幅の横組みのレイアウトを示したものです（ここで使った文字コード列は実は「かなABC漢字」に対応していますが、矩形グリフだけで表示されているので、それは明示されません）。

可変字幅が狭くなるときも、広くなるときも、グリフの高さが変化しないのは、「VWID」軸がデフォルトの設定に固定されているからです。アニメーションの時間設定については、デフォルトの設定が 5 秒間、二つの両極に 2 秒間、中間の設定に 1 秒間を割り当てています。

縦組みでの可変字幅のレイアウト

縦組みのレイアウトを行うときには、縦組みでも直立の姿勢で変化しない CJK のグリフについては、比較的単純明快です。垂直の Y 軸に沿って可変字幅を好みに合わせて狭くしたり広げたりするために「VWID」軸が利用され、「wdth」軸は CJK グリフの全角の字幅または 1000 ユニットのデフォルトの設定に固定されます。特別な取り扱いが必要な場合には次の二つの場合があります。

• 縦組みで回転する必要のある欧文などのグリフの取り扱いは複雑です。「VWID」軸の設定が「wdth」軸に対して適用され、「VWID」軸はデフォルトの設定に固定されます。言いかえれば、横組みで配列したテクストを単純に回転したものと等しくなるということです。回転されたグリフは縦組みの中で狭くなったり広くなったりできますが、相対的な高さは変化しません。
• 縦中横を取り扱うのは、特殊な場合であって、「VWID」軸の設定がそのまま利用され、「wdth」軸はデフォルトの設定に固定されます。言いかえれば、縦中横は CJK グリフと同じように動作し、グリフは縦組みのレイアウト中で低くなったり、高くなったりしますが、幅は固定で変化しません。このテストフォントには、「hwid」GSUB フィーチャーが含まれており、欧文グリフを用いて 2 文字の縦中横をシミュレートすることができます。

次に示す GIF アニメーションは、このテストフォントを用いて作成したもので、可変字幅の縦組みのレイアウトを示したもので、回転した文字列と縦中横を含んでいます。（先の例と同様、ここで使った文字コード列は「あAB漢字12国」に対応したものですが、矩形グリフだけで表示されているので、それは明示されません）。

回転した欧文グリフが狭くなるときも、広くなるときも、相対的な高さは変化しません。回転した欧文グリフの相対的な高さは、CJK グリフの字幅に固定されています。同様に、縦中横のグリフの高さは、低くなったり、高くなったりしますが、その字幅は［縦中横の対象が 2 文字に限られる場合には］CJK グリフの字幅に固定されます。アニメーションの時間設定については、上記の横組み用のものと同じです。

モデルの要約

次の表は、このモデルに関して、上述の二つのセクションで述べたレイアウト上の諸条件で、二つのデザインのバリエーションの軸の設定と設定範囲を要約したものです。

もちろん、ここで実際に使われている設定と設定範囲は、私が開発したテストフォントを基にしたもので、このモデルに従って作られた他のバリアブルフォントが少し異なる値を使用することはありえます。ここで肝要なことは、複数の軸の内の一つはデフォルトの設定に固定されることで、私が開発したフォントの場合には 500 になるということです。

UI において考慮すべき点

「wdth」と「VWID」のデザインのバリエーションの軸は、一つのバリアブルフォント中では別個の軸として実装され、それらの軸のうち一つは上述のように固定される必要がありますが、UI は「可変字幅」という名前をつけた、機能している一つの軸だけを表示するのが適切でしょう。横組みか縦組みかというレイアウトの方向、または文字が回転されるか縦中横の文脈で用いられるかに依存して、そこでの設定が適切な軸に適用されることが肝要です。もう一つ別のありうる方法は、デフォルトでは複数の軸のうちの一つを固定しますが、そのデフォルトの動作を上書きして、その固定を外すことができるようにするというものです。

どちらの場合でも、これら複数の軸がどのようにアプリケーションの UI 上で表示されるかは、アプリケーション自体がどれだけ洗練されたものであるかに大きく依存するかもしれません。あまり洗練されていないアプリケーションの場合には、機能的な軸を一つだけ表示するのが好ましいでしょうし、より洗練されたアプリケーションの場合には、上で述べたように、どちらの軸も表示してデフォルトの動作を上書きすることができるようにすることも可能でしょう。

デザインのバリエーションの軸の登録

もしこの記事で説明したモデルが一般に受け入れられるなら、「VWID」というデザインのバリエーション軸を登録することが必要になるでしょう。そうすれば、「vwid」や「vadv」などと同様に、すべて小文字で表記された名前を持つことになります。

最後に、この記事に書かれている事柄はすべて、現時点ではまだ、横組みにおいても縦組みにおいても可変字幅（狭い字幅・広い字幅あるいはその両方）に対応できる CJK バリアブルフォントを実装する場合の標準的な方法になればよいと私が考えているモデルの提案の段階にあります。

ぜひ、コメントをお持ちの場合には、お知らせください。

🐡

日本語 (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.

The Test Font

The test font is a two-axis Variable Font that maps all 1,111,998 Unicode code points to one of two glyphs, based on the Unicode Version 12.1 version of the UAX #50 (Unicode Vertical Text Layout) data file, VerticalOrientation.txt:

• 785,553 code points that are assigned the Vertical_Orientation (“vo”) property value of “R” or “Tr” map to Western glyphs
• 326,445 code points that are assigned the “vo” property value of “U” or “Tu” map to CJK glyphs

Given that upright versus rotated orientation plays an important role in vertical layout, the above mappings seemed quite appropriate.

The test font includes 256 instances of the Western and CJK glyphs, from GIDs 1 through 256 and GIDs 257 through 512, respectively, whose shapes and parameters are described as follows:

• The Western glyphs are hollow rectangles whose default width is 600 units, rest on the Western baseline (Y=0), and which compress or expand 25% (from 450 to 750 units)
• The CJK glyphs are solid rectangles whose default width is 1000 units, rest 12% below the Western baseline (from Y=−120 to Y=880), and which compress or expand 25% (from 750 to 1250 units)

Why 256 instances of each glyph? It simplified the Unicode mappings that are specified in the 'cmap' table. This is important when dealing with over a million mappings.

GID+513 is an explicit half-width glyph that is intended to be used for TCY purposes, and is used to substitute the Western glyphs via the 'hwid' (Half Widths) GSUB feature.

The test font includes the registered 'wdth' (Width) and unregistered 'VWID' (Vertical Width; and yes, I am aware that “Vertical Advance” would be technically more correct, but the use of “Width” better pairs with the 'wdth' axis) design-variation axes. For both axes, the default setting is 500, which corresponds to a 600-unit horizontal advance for the Western glyphs, and a 1000×1000 box (aka full-width) for the CJK glyphs. The minimum and maximum axis settings are 1 and 1000, which corresponds to 25% compression and 25% expansion, respectively.

The test font is available in the open source Width & Vertical Width VF project on GitHub in both OpenType/CFF2 and TrueType formats.

Compression/Expansion in Horizontal Layout

The model that is being described in this article is relatively simple when performing horizontal layout: the 'wdth' axis is used to compress or expand glyphs along the X-axis as desired, and the 'VWID' axis is constrained to its default setting, which corresponds to full-width or 1000 units for the CJK glyphs. In other words, the relative height of the glyphs remains unchanged in horizontal layout.

The animated GIF below was created using the test font, and illustrates compression and expansion in horizontal layout (although it’s not obvious, the character string that was used was “かなABC漢字”):

Note how the glyph height remains unchanged regardless of the compression or expansion, which is due to constraining the 'VWID' axis to its default setting. In terms of animation timing, the default setting is five seconds, the two extremes are two seconds, and the intermediate settings are one second.

Compression/Expansion in Vertical Layout

When performing vertical layout, the handling of CJK glyphs that remain upright is relatively straight-forward: the 'VWID' axis is used to compress or expand glyphs along the Y-axis as desired, and the 'wdth' axis is constrained to its default setting, which corresponds to full-width or 1000 units for the CJK glyphs. The following are the two cases that require special handling:

• The handling of glyphs that rotate in vertical layout, such as Western ones, makes this more complex: the 'VWID' axis setting is instead applied to the 'wdth' axis, and the 'VWID' axis is constrained to its default setting. In other words, it is equivalent to simply rotating text that was laid out horizontally. The rotated glyphs can become narrower or wider in vertical layout, but their relative height remains unchanged.
• The handling of TCY is a special case whereby the 'VWID' axis setting is actually used, and the 'wdth' axis is constrained to its default setting. In other words, TCY behave like CJK glyphs: the glyphs become shorter or taller in vertical layout, but their width remains unchanged. The test font includes the 'hwid' GSUB feature so that two-character TCY can be simulated using the Western glyphs.

The animated GIF below was created using the test font, and illustrates compression and expansion in vertical layout, which includes both rotated and TCY strings (once again, it’s not obvious that the character string that was used was “あAB漢字12国”):

Note how the rotated Western glyphs become narrower or wider, but that their relative height remains unchanged. The relative height of the rotated Western glyphs is bound to the width of the CJK glyphs. Likewise, the height of the TCY glyphs become shorter or taller, but their widths are bound to the width of the CJK glyphs. The animation timing is identical to the horizontal one.

Model Summary

The following table summarizes the model, in terms of the settings and setting ranges for the two design-variation axes in the layout conditions that were described in the previous two sections of this article:

Of course, the actual settings and setting ranges are based on the test font that I developed, and other Variable Fonts that follow this particular model may use slightly different values. The main point is that one of the axes is constrained to its default setting, which is 500 in the test font that I developed.

UI Considerations

Although the 'wdth' and 'VWID' design-variation axes are implemented as separate axes in a Variable Font, and given that one of the axes needs to be constrained per the descriptions above, UIs should expose only a single functional axis, named “Width,” whose setting is applied to the appropriate axis, depending on the layout direction—horizontal or vertical—and whether the characters are rotated or used in a TCY context. Another alternative is to lock one of the axes by default, but to permit unlocking to override the default behavior.

In any case, how these axes are exposed to users in app UIs may largely depend on the sophistication of the apps themselves. Less-sophisticated apps would benefit by exposing only a single functional axis, and more-sophisticated ones may allow the default behavior to be overridden by exposing both as described at the end of the previous paragraph.

Design-Variation Axis Registration

If the model described in this article becomes generally accepted, the 'VWID' design-variation axis will need to be registered, which means that it would become an all-lowercase tag, such as 'vwid', 'vadv', or similar.

In closing, everything that is described in this article is a proposal for a model that I hope will become the standard way in which CJK Variable Fonts that support compression, expansion, or both, in horizontal and vertical layout, is implemented.

Of course, comments are welcome and encouraged.

🐡

The new open source Source Han Mono (源ノ等幅 in Japanese, 본모노 in Korean, 思源等宽 in Simplified Chinese, 思源等寬 in Traditional Chinese—Taiwan, and 思源等寬 香港 in Traditional Chinese—Hong Kong SAR) typeface was released only four days ago, and this article provides details about its 70-font Super OTC (OpenType/CFF Collection). This article simply serves as an announcement for the Version 1.001 update that was released today. There are two main changes about which users should be aware:

• The alignment zones and hinting parameters for the FDArray elements whose glyphs were derived from Source Code Pro were improved. Many thanks to Twitter user @KiYugadgeter for raising this issue here, and for confirming the fix here.
• Our designer, Ryoko Nishizuka (西塚涼子), opted to improve the glyphs for the half-width katakana (半角片仮名) that were expanded to have 667-unit horizontal advances via anisotropic techniques. The image above shows glyphs from Source Han Sans, then from Source Han Mono Version 1.000, and then from Source Han Mono Version 1.001.

I also updated the 143-font Source Han Mega OTC and 216-font Ultra OTC in the Source Han & Noto CJK Mega/Ultra OTCs project earlier today.

Enjoy!

🐡

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.

Source Han Mono is deployed only as a 70-font OpenType/CFF Collection (OTC) that supports seven weights—EL (ExtraLight), L (Light), N (Normal), Regular, M (Medium), Bold, and Heavy (H)—five languages—Japanese, Korean, Simplified Chinese, and two flavors of Traditional Chinese (Taiwan and Hong Kong SAR)—and two styles—upright and italic. This deployment format saves approximately 15MB, which is equivalent to a 10-font weight-specific OTC that supports the five languages and two styles. In other words, the size savings is approximately 15%, which is significant. This savings is due to the sharing of large 'sfnt' tables across weights, such as the 'cmap' and 'GSUB' tables.

The image below is Genesis 11:1, shown in three of the weights, in all of the supported languages, and in both styles:

Three Horizontal Advances

One of the main guiding principles of Source Han Mono is that all of the glyphs must have one of three possible horizontal advances with no exceptions: 0 (zero), 667, or 1000 units. For kana, ideographs, and full-width symbols, the Source Han Sans glyphs could be used as-is. For the Western glyphs that are proportional, it meant replacing the Source Sans Pro–derived glyphs with Source Code Pro–derived ones. Following in the footsteps of Source Han Code JP, I scaled the Source Code Pro glyphs to 111.2%, which resulted in expanding their horizontal advances from 600 to 667 units.

The glyphs for hangul (한글) letters and syllables, which have 920-unit horizontal advances in Source Han Sans, along with those for half-width katakana (半角片仮名), which have 500-unit horizontal advances, presented an interesting design challenge whose solution will be described later in this article.

Torpedoed Glyphs

Some of the glyphs in Source Han Sans have no purpose being included in Source Han Mono, because they are too wide, too tall, or redundant. The glyphs for U+2E3A ⸺ TWO-EM DASH and U+2E3B ⸻ THREE-EM DASH fall into the first two categories—remember that they include vertical forms that are two- and three-em tall, respectively. The glyphs for U+3031 VERTICAL KANA REPEAT MARK and U+3032 VERTICAL KANA REPEAT WITH VOICED SOUND MARK fall into the second category. The explicit half-width glyphs fall into the third category. Other glyphs were excluded because they have no corresponding glyph in Source Code Pro, specifically U+FB00 ff LATIN SMALL LIGATURE FF, U+FB03 ffi LATIN SMALL LIGATURE FFI, U+FB04 ffl LATIN SMALL LIGATURE FFL, U+1F16A 🅪 RAISED MC SIGN, U+1F16B 🅫 RAISED MD SIGN, and U+1F16C 🅬 RAISED MR SIGN.

In order to make room for several hundred italic glyphs, I decided to remove the glyphs for the 500 high-frequency archaic hangul syllables. These 500 syllables are still supported via combining jamo.

Two Styles, One Glyph Set

Unlike conventional fonts that use a separate glyph set for the Italic style, such as Source Code Pro, Source Han Mono includes the italic glyphs in a unified glyph set. For CJK or Pan-CJK fonts, this makes a lot of sense, because only a small number of glyphs need to be italic, and maintaining separate glyph sets would be comparable to the tail wagging the dog. The upright (non-italic) font instances are able to access the italic glyphs by either selecting the Italic style in apps that support style-linking, or via the 'ital' (Italics) GSUB feature.

In addition, and because all CIDs are precious when developing a Pan-CJK typeface, Western glyphs that do not vary in the Italic style, at least in Source Code Pro, such as for characters that are used for rudimentary math, are excluded from the glyph set. Those characters simply map to the non-italic glyphs in the Italic style. The number of affected Latin characters is 26.

Anisotropic Techniques

Two particular glyph classes presented an interesting challenge, because their glyphs didn’t match one of the three horizontal advances. The hangul letters and syllables, which have 920-unit horizontal advances in Source Han Sans, were one class. Half-width katakana, with 500-unit horizontal advances, were another class. For both glyph classes, I ended up leveraging anisotropic techniques to expand the glyphs for these two glyph classes to 1000 and 667 units, respectively. The animated image below compares text set using Source Han Sans and Source Han Mono, and the second and fourth lines include glyphs that resulted from applying anisotropic techniques:

For the half-width katakana glyphs, only the katakana in the range U+FF66 through U+FF9D were adjusted in this way. The glyphs for the half-width punctuation, parentheses, and annotations were adjusted only by expanding their horizontal advances to 667 units, and repositioning their glyphs along the X-axis as necessary. The glyph for U+FF65 ･ HALFWIDTH KATAKANA MIDDLE DOT in the above image illustrates this point well.

The technique involved first expanding the ExtraLight and Heavy masters to the desired horizontal advance by specifying a transformational matrix via the AFDKO (Adobe Font Development Kit for OpenType) rotatefont tool. The command lines below were used to expand the thousands of hangul letters and syllables from 920 to 1000 units (I needed to first convert the masters into UFOs):

rotatefont -ufo -matrix 1.087 0 0 1 0 0 Hangul_0_920.ufo Hangul_0_1000.ufo
rotatefont -ufo -matrix 1.087 0 0 1 0 0 Hangul_1_920.ufo Hangul_1_1000.ufo

The next step was to create a designspace file that specified two axes, weight ('wght') and width ('wdth') that are defined by the original (920-unit) and expanded (1000-unit) ExtraLight and Heavy masters. I also needed to define two instances that would become the new 1000-unit ExtraLight and Heavy masters, for which the xvalue of the weight axis is adjusted so that the outlines are interpolated at different rates (the yvalue was set to 0 and 1000 for the two instances, respectively), and for which the xvalue of the width axis is set to 1000 for both instances to maintain the desired 1000-unit width throughout the interpolation. I determined that xvalues of −25 (ExtraLight) and 900 (Heavy) gave the desired results for the weight axis. The command line below was used to produce the new ExtraLight and Heavy masters for the hangul letters and syllables:

makeinstancesufo -a -c --ufo-version 2 -d Hangul.designspace

My extraordinarily talented colleague, Miguel Sousa, taught this technique to me, which should be used only for relatively minor adjustments. If the degree to which the glyphs are expanded—or compressed—is too great, the design will begin to degrade.

Slashed Zero

In order to distinguish 0 (zero) from O (uppercase letter), Source Code Pro uses a center dot for the former glyphs. I wrote “glyphs” in the plural, because there are four glyphs for zero with a center dot: upright and italic, of course, but also standard and cap-height versions for both styles. The cap-height glyphs for zero, along with the nine other digits, are default (encoded), and language-tagging the text as English will invoke the standard-height digits. This behavior is identical to Source Han Sans and Source Han Serif.

Oh, right. Source Code Pro also includes slashed forms of the zero glyph, and Source Han Mono therefore includes all four versions, like for the center-dot form. The slashed form is accessible via the aptly-tagged 'zero' (Slashed Zero) GSUB feature.

More Extensive Style Linking

Like Source Han Sans and Source Han Serif, the Source Han Mono font instances are style-linked, but more extensively thanks to the presence of italic glyphs and the separate italic font instances whose 'cmap' tables map to them. The fonts for the former two families style-link only the Regular weight to the Bold weight. For Source Han Mono, all weights are additionally style-linked to the corresponding italic font instance. This is useful in apps that support style-linking via buttons or controls for the Bold and Italic styles.

Source Han & Noto CJK Mega/Ultra OTCs—Updated!

The last time that I updated the Mega OTCs and Ultra OTC was over a year ago, and the release of Source Han Mono gave me a good reason to update the entire project. The Source Han and Noto CJK Mega OTCs now have 143 (was 78) and 73 (was 64) fonts, respectively. The former Mega OTC grew to approximately 400MB (was approximately 300MB). The Ultra OTC that combines the two Mega OTCs now has 216 (was 142) fonts, but is a mere 200K larger than the Source Han Mega OTC due to massive 'sfnt' table sharing between the Source Han and Noto CJK families.

I would like to emphasize that the 216-font Ultra OTC is incredibly size-efficient. The total footprint of its 216 font instances, if they were installed as 216 separate OpenType/CFF fonts, would be nearly 4GB. I can therefore claim that the Ultra OTC deployment format literally decimates the footprint at approximately 400MB. That also means that each 65,535-glyph font instance represents less than 2MB.

Oh, and guess which OTC I currently have installed.

For More Information…

For more information about Source Han Mono, I encourage that you take the time to read the extensive ReadMe (a PDF will download if clicked) that I prepared. Heck, you may even notice that I used Source Han Mono to typeset it.

🐡

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:

It’s comforting to know that I can now language-tag text in CJK Type Blog articles using five different languages, whereas I was previously limited to only four.

🐡

On this date last year, I published the Contextual Spacing GPOS Features article, and this briefer article serves as an update.

Two important steps toward implementation were taken during the past year:

1. I started the process of registering the two GPOS features: 'chws' (“Contextual Half-width Spacing”) and 'vchw' (“Vertical Contextual Half-width Spacing”). There was some discussion on the OpenType and OFF (Open Font Format; aka the ISO/IEC 14496:22 standard that is available free here) mailing lists, and the conclusion was that the originally-proposed feature tags and their friendly names, 'cspc' (“Contextual Spacing”) and 'vcsp' (“Vertical Contextual Spacing”), didn’t convey an important characteristic of the features, specifically that they involve half-width spacing.
2. Thanks to feedback received from that article, especially that from Koji Ishii (石井宏治), I modified the contextual rules and produced SourceHanSerifCSP-Heavy.otf Version 1.005. The raw features file that uses Unicode-based working glyph names is a helpful resource to understand the scope of these GPOS features.

With regard to the second step, the changes that were made, compared to Version 1.004, were 1) the @ColonExclamQuestion and @ColonExclamQuestionVert glyph classes that include the glyphs for the exclamation and question marks, along with left-justified forms of the colon and semicolon, were removed, as were their contexts; 2) quarter-width metrics adjustments were removed; 3) contexts that include centered punctuation followed by another centered punctuation or a full-width space were removed; and 4) contexts that include a justified period or comma followed by centered punctuation were added.

In closing, the animated image below is identical to the one in the previous article, but has been made using the latest font (none of the changes affected this particular text), and better illustrates the advantages of these GPOS features in environments with limited line-layout capabilities:

As usual, any and all feedback is greatly appreciated!

🐡

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.

NEC Row 13

The first version of the JIS X 0208 standard was published as JIS C 6226-1978. (As an aside, this standard’s designation was changed from JIS C 6226 to JIS X 0208 on 1987-03-01.)

Shortly after—but definitely before 1983—NEC, as part of JIPS (Japanese Information Processing System or ジップス), added 82 characters to Row 13 (aka NEC Row 13), which was empty in JIS X 0208. A small number of the NEC Row 13 symbols were added to the 1983 revision of the JIS X 0208 standard, but they remained in NEC Row 13. Among the characters in this vendor-specific row were the two-kanji square ligature forms of the Meiji (明治), Taishō (大正), and Shōwa (昭和) era names at positions 13-77 (Shift-JIS 0x878D), 13-78 (Shift-JIS 0x878E), and 13-79 (Shift-JIS 0x878F), respectively: ㍾, ㍽, and ㍼. Note how the ordering is from oldest to newest.

Several companies adopted NEC Row 13 into their own vendor character sets, in particular Apple and Microsoft.

Heisei Era: NEC or Microsoft? Apple’s KanjiTalk7?

The Heisei (平成) era began on 1989-01-08. Because Microsoft adopted NEC Row 13 into its Japanese character set, it is not known whether NEC or Microsoft added the two-kanji square ligature form of 平成 at position 13-63 (Shift-JIS 0x877E): ㍻.

Instead of adjusting their KanjiTalk6 character set, Apple decided to significantly change their extension to JIS X 0208 when they developed their KanjiTalk7 character set, which was released in 1992. The (now) four two-kanji square ligature forms of Japan era names were moved to Row 14 at positions 14-71 (Shift-JIS 0x87E5) through 14-74 (Shift-JIS 0x87E8): ㍾, ㍽, ㍼, and ㍻. Note how the ordering is from oldest to newest.

Unicode

Unicode Version 1.0 was released in October of 1991, and included the four two-kanji square ligature forms of Japan era names at code points U+337B through U+337E: ㍻, ㍼, ㍽, and ㍾. Note how the ordering is from newest to oldest. Interestingly, the “Unicode Preview” included these four characters at code points U+3190 through U+3193, ordered from oldest to newest, and the relevant page is dated 1990-08-11.

Fontworks’ OCF Fonts

Fontworks (フォントワークス) developed OCF (Original Composite Font) fonts in the early 1990s, and they included vertical forms of these two-kanji square ligatures whose component kanji were stacked vertically, as shown below:

This was quite novel, and will become important later.

(Incidentally, their fonts also included vertical forms of full-width Latin, Greek, and Cyrillic whose glyphs were centered along the Y-axis for proper placement in vertical writing mode. This is accomplished in OpenType via 'vmtx' table overrides, which doesn’t require separate glyphs.)

JIS X 0213:2000

When the JIS X 0213 standard was developed, NEC Row 13 in its entirety was incorporated, mainly for compatibility with existing implementations, though the characters that were duplicates of those in the 1983 revision of JIS X 0208 were obviously excluded. The four two-kanji square ligature forms of Japan era names were included using the same NEC Row 13 positions.

Adobe-Japan1-4

Before I dive into Adobe-Japan1-4, I should first state that Supplement 0 of Adobe’s public Japanese glyph set, Adobe-Japan1-0 (1992), included glyphs for ㍾, ㍽, and ㍼ from CIDs 7621 through 7623. These were inherited from Adobe’s original Japanese glyph set that was used for OCF fonts. The glyph for ㍻ was added in Supplement 1, Adobe-Japan1-1 (1993), as CID+8323.

Fontworks’ coining of the vertical forms of the era name square ligatures inspired me to include their glyphs in Supplement 4, Adobe-Japan1-4 (2000-02-21). They were added in the second draft (dated 1999-08-07) as CIDs 11986 through 11989, and their CIDs remained unchanged in the third draft (dated 1999-11-05). Their final CIDs were 12041 through 12044.

Going back to Unicode for a moment, the vertical forms are shown in the Vertical column of Table 2 of UAX #50 (Unicode Vertical text Layout).

2019-04-01 Announcement

As stated at the beginning of this article, Japan is expected to announce the name of its new era on 2019-04-01, and because a precedent has been set to encode its two-kanji square ligature form, Unicode has reserved U+32FF as its code point, which will be standardized in Unicode Version 12.1. The code point selection criteria was based on U+32FF being the closest unassigned code point to the other four similar characters.

Adobe-Japan1-7

Related to the encoding of U+32FF, Supplement 7 of Adobe’s public Japanese glyph set, Adobe-Japan1-7, was defined to include glyphs for the two-kanji square ligature forms of Japan’s new era name, for horizontal and vertical, using CIDs 23058 and 23059. The actual Adobe-Japan1-7 specification cannot be published until the name of the new era is revealed, but its CMap resources were released last year.

JIS X 0213 Revision?

In closing, one point of curiosity for me is whether Japan will bother to revise the JIS X 0213 standard to include the new two-kanji square ligature. When considering the small number of available positions in Plane 1, position 1-13-62 (Shift-JIS 0x877D, though it is no longer very relevant) looks to be the best candidate. It is closest unassigned position to the position that corresponds to U+337B ㍻, which is 1-13-63. The same criteria was used to select U+32FF for the Unicode code point.

🐡

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!

🐡

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.

In addition to being collections, these Variable Font Collections are also meant to exhibit characteristics that may have been overlooked in environments that support Variable Fonts, such as multiple FDArray elements, and also include a large number of glyphs and Unicode mappings. These are the characteristics of Pan-CJK fonts, meaning that these Variable Font Collections accurately simulate genuine real-world use cases. In terms of Adobe’s own apps, I am pleased to state that these Variable Font Collections are responsible for a half-dozen bug reports. None of my colleagues went into shock after learning that these fonts broke our apps.

Why collections? Deploying Pan-CJK fonts as separate language-specific Variable Fonts doesn’t make much sense, mainly because it defeats one of the purposes of Variable Fonts, which is a reduced footprint.

BTW, I built what may have been the very first Variable Font Collection on 2019-01-08 using Variable Fonts that my colleague, Masataka Hattori (服部正貴), prepared. I then built what may have been the very first Variable Font with multiple FDarray elements on 2019-01-29. Good stuff.

In closing, I’d like to thank my colleague, Miguel Sousa, for preparing the CFF2 glyph data that I used as the basis for these Variable Font Collections. They should serve as excellent testing fodder for developers of font-consuming software.

🐡

“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.

To get to the point of this article, we (Adobe) recently announced that CIDFont support in our Creative Cloud apps—such as Illustrator, InDesign, and Photoshop—will be discontinued starting from the next major release in 2019. The CC 2019 apps that were released in October of 2018, along with any dot releases thereof, will continue to support CIDFonts. Although sfnt-wrapped CIDFonts were obsoleted by OpenType/CFF fonts approximately 20 years ago, a non-trivial number of such fonts were distributed over many years. This effectively means that a non-zero number of customers will be affected, including myself. If you are an affected customer, the prudent thing to do is to start making preparations accordingly.

In other words, the proverbial writing has been on the wall for years, so this announcement should not be construed as a shock by any stretch of the imagination.

To put this announcement into an actionable and practical perspective, Naked-CID fonts and sfnt-wrapped CIDFonts have serious disadvantages when compared to OpenType/CFF fonts, in particular, the lack of Unicode support, which is a big deal for modern environments. In essence, these legacy font formats are restricted to legacy encodings, such as Shift-JIS for Japanese, are not cross-platform, do not work in mobile OSes, and have limited typographic features and functionality. Of course, CIDFont resources will continue to serve as one of the source files for CID-keyed OpenType/CFF fonts, at least when using AFDKO‘s makeotf to develop such fonts.

For more information about these legacy font formats, I encourage you to read this pp 387 through 393 excerpt from Chapter 6 of CJKV Information Processing, Second Edition.

🐡