Although this article shares its title with an article from four years ago that was about the excitement associated with attending ATypI Hong Kong 2012, this particular one will focus on efforts to properly support Hong Kong SAR (aka HK or Hong Kong) in the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK typeface families, but also in infrastructure, such as OSes and apps.
In other words, this article is not about traveling to Hong Kong, but rather about properly supporting Hong Kong in OSes, apps, and fonts.
As a way to help in the testing efforts toward this goal, I built a tiny twelve-glyph CID-keyed OpenType/CFF font called LOCL Test (LOCLTest-Regular.otf) that includes five region-specific glyphs for U+904D (遍) and for which the default glyph is that for JP (Japan) use, along with five digraphs that represent the regions and for which the default glyph is "JP" that is mapped from "J" (U+004A) and "j" (U+006A). (The purpose of the digraphs is to serve as an indicator for those who are not sensitive to subtle differences in the glyphs for CJK Unified Ideographs.) The other four regions—for 遍, J, and j—are supported via the 'locl' (Localized Forms) GSUB feature and language-tagging. Four of the five region-specific glyphs for 遍 were derived from Source Han Sans Regular, and the fifth glyph—the one for HK (Hong Kong SAR) use—was created using components from the CN (PRC) and TW (ROC) glyphs.
The image below, which is from language-tagged text displayed in Chrome, shows, from left to right, the glyphs for JP (default), KR, CN, TW, and HK (in red) use:
This also works perfectly in Firefox. However, our friends over at Apple still have work to do for Safari, but that's about supporting the 'locl' feature in general, and is not specific to Hong Kong support.
It is somewhat embarrassing for me to report that while OpenType supports two styles of Traditional Chinese—using the Adobe InDesign supports only a single notion of Traditional Chinese. In other words, it is currently not possible to language-tag text in InDesign for Hong Kong. On a positive note, there are efforts underway to remedy this issue.
Now, in terms of HK support in fonts, the HKSCS (Hong Kong Supplementary Character Set) standard is currently being revised, and a new version is expected to be published sometime later this year. An important aspect of this forthcoming revision is that the Big Five subset is explicitly included, representative glyphs and all. This is very important for developers. I am currently working with a technical draft, which has proven to be useful in scoping out the effort it will take to properly support HK in Source Han Sans and Noto Sans CJK for the Version 2.000 update, as a fifth language. This also provides to me an opportunity to provide meaningful feedback to Hong Kong prior to this standard being published. In any case, I have a boatload of work ahead of me, but in the end it will be worth it.
For those who are not aware, Source Han Sans and Noto Sans CJK support HKSCS-2008 in terms of code point coverage, but the glyphs adhere to the Taiwan MOE (Ministry of Education) glyph standard. While a large number of existing TW glyphs can be used for HK, but only within the scope of Big Five, I have encountered four types of changes that will be necessary to properly support HK:
Existing CN, JP, or KR glyphs can be used for HKExisting HK glyphs can be nuked—because existing CN, JP, or KR glyphs can be used for HKExisting HK glyphs need to be modifiedNew HK glyphs need to be designed
The first type of change simply involves mapping particular code points to the appropriate glyphs in the UTF-32 CMap resource for HK use. The second type of change is trivial because it involves removing glyphs—a Very Good Thing™, and directly benefits the fourth type of change—and remapping the affected code points. The third type of change is also trivial in that there is no net increase in the number of glyphs. The fourth type of change is a bit more tricky in that additional glyphs are necessary, and to effect this, there needs to be a greater degree of glyph sharing across languages because the glyph set is full. The Good News™ is that I already lined up several hundred candidates for glyph sharing, which should accommodate the additional glyphs that will be necessary for proper HK support.
P.S. For good measure, and to spice things up a bit, I added the IVSes for the (unregistered) PanCJKV IVD collection to the LOCLTest-Regular.otf font, and for all eleven regions.
