Posts in Category "Unicode"

オントロ & グスーム?

What in the world could オントロ (ontoro) and グスーム (gusūmu) possibly mean? (If you wait a few seconds, a hint will flash in the animated GIF above.)
Continue reading…

2019 “State of the Unification” Report

The UTC #160 meeting took place last week at Microsoft’s HQ in Redmond, Washington.

For CJK enthusiasts, the big news is that the UTC accepted CJK Unified ideographs Extension G (aka IRG Working Set 2015), which includes 4,939 characters. Additional CJK Unified Ideographs were appended to the URO (13), Extension A (10), and Extension B (7). As a result, the Extension A block will be completely full, and the URO and Extension B blocks will be nearly full. The total number of CJK Unified Ideographs in Unicode Version 13.0 is expected to be 92,856, which will represent approximately 65% of its characters.

The Pipeline accurately reflects the additional CJK Unified Ideographs that are targeted for Unicode Version 13.0. I suspect that the image at the beginning of this article will be helpful, and when clicked, will provide a PDF version that also includes a table for CJK Compatibility Ideographs.

These additions reflect two issues about which developers need to be aware:

  • Plane 3 (aka TIP or Tertiary Ideographic Plane) is now open for business, and Extension G represents the first block encoded among its 65,534 available code points.
  • This is the first time that CJK Unified Ideographs have been appended to a block other than the URO.



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.001 Update

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.



To UVS, Or Not To UVS

Several months ago I updated the Adobe-Japan1-UCS2 “ToUnicode” mapping file in the open source Mapping Resources for PDF project specifically to accommodate the two Adobe-Japan1-7 CIDs, CIDs 23058 and 23059.

However, that ToUnicode mapping file is long overdue for a rather extensive update for other reasons, and part of the delay was intentional on my part. The purpose of this article is to outline the reason for the delay, along with providing more concrete update plans.
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…

Contextual Spacing GPOS Features—Redux

On this date last year, I published the Contextual Spacing GPOS Features article, and this briefer article serves as an update.
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…

Four of a Kind: KS X 1001 & KPS 9566

What do U+AE40 김 and U+6A02 樂 have in common? 🤔

I enjoy working with standards.

Interestingly, standards that were published by the Koreas—South Korea (aka ROK) and North Korea (aka DPRK)—include characters that appear more than once.

In the case of South Korea, it is well known that 268 of the 4,888 ideographs (aka hanja) in the KS X 1001 standard are duplicates, which affects ideographs for which there are more than one reading. This, of course, means that there are 4,620 unique ideographs in that standard.

In the case of North Korea, their original KPS 9566 standard that is dated 1997 separately encodes the modern hangul syllables that represent the names of the previous (at the time) and current (again, at the time) leaders.
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…

Adobe-Japan1-6 vs Source Han

Prompted by recent activity on Twitter, I assembled a new mapping file that correlates Adobe-Japan1-6 CIDs (aka glyphs) to Source Han ones, but only for the 6,879 characters in the JIS X 0208 standard. Because the Source Han Sans and Source Han Serif glyphs sets are different, they require separate columns in the mapping file. Also, for the 161 kanji in JIS X 0208 that have both JIS90 (aka JIS X 0208-1990) and JIS2004 (aka JIS X 0213:2004) forms, the CIDs that correspond to the JIS2004 forms are indicated, and those for the JIS90 forms are in brackets.
Continue reading…

CMap Resources—Redux

I spent part of last week preparing the Adobe-Japan1-7 character collection specification update, which will be released sometime in early April, shortly after Japan announces the name of their new era name. (Until the update is released next month, Adobe-Japan1-6 is still reflected in the open source project.) The announcement is expected to take place on 2019-04-01, and while this date represents the start of a new fiscal year in Japan, it is an unfortunate choice for elsewhere.

Anyway, while performing said update, I came across a reference to Adobe Tech Note #5094, Adobe CJKV Character Collections and CMaps for CID-Keyed Fonts, which I last updated a dozen years ago. I decided to use this as an opportunity to obsolete yet another Adobe Tech Note by incorporating its meaningful content into the open source CMap Resources project. I did precisely that last week, which involved updating its content in the process.


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.



Preparing for MSCS—Macao Supplementary Character Set

Macao SAR (SAR stands for Special Administrative Region)—written 澳門特別行政區 or 澳門特區—is in the process of standardizing MSCS (Macao Supplementary Character Set or 澳門增補字符集 in Chinese), which is character set standard that is designed as a supplement to HKSCS (Hong Kong Supplementary Character Set), and by extension, as a supplement to Big Five. One reliable source told me that MSCS can be described as HKSCS plus approximately 150 additional characters.
Continue reading…

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…