CJK Type Blog

I will close this particular topic by detailing how to support these proposed standardized variants in OpenType/CFF fonts.

For fonts that are currently IVS-enabled, such as those that include Format 14 ‘cmap’ subtables with Adobe-Japan1 or Hanyo-Denshi IVSes, it is important to note that the proposed standardized variants can co-exist with them, at least in terms of being specified in the font. For the former, I created an Adobe-Japan1_sequences.txt file that includes all registered Adobe-Japan1 IVSes, along with 89 of the 1,002 proposed standardized variants. The 89 standardized variants are at the end of the file. AFDKO tools, such as makeotf and spot, already support these standardized variants. When building OpenType/CFF fonts using the makeotf tool, this file is specified as the argument of the “-ci” command-line option.
Continue reading…

To continue from the December 26, 2012 article, I should first point out that there is a relationship between these 1,002 proposed standardized variants and IVSes (Ideographic Variation Sequences). Standardized variants are standardized, hence their name. IVSes, on the other hand, are registered via a process that is described in UTS #37 and administered by the IVD Registrar (which happens to me at the moment).
Continue reading…

One problem that has been plaguing CJK Compatibility Ideographs is the fact that they are adversely affected by normalization. Regardless of which of the four normalization forms is applied—NFC, NFD, NFKC, or NFKD—they are converted to their canonical equivalents, which are CJK Unified Ideographs. This is a problem, particularly for Japan, because 75 kanji in JIS X 0213:2004 kanji map to CJK Compatibility Ideograph code points. Furthermore, 57 of these 75 kanji correspond to Jinmei-yō Kanji (人名用漢字), meaning that they are used for personal names. The bottom-line problem with CJK Compatibility Ideographs is that any application of normalization, by any process, will permanently remove any distinctions between a CJK Compatibility Ideograph and its canonical equivalent. Not all processes are under one’s direct control, meaning that it is impossible to guarantee that normalization will not be applied. My opinion is that it is prudent to assume that normalization will be applied, and that preemption is the best solution.
Continue reading…

In the December 4, 2012 Old Hangul article I mentioned that the ‘ccmp’ GSUB feature that is referenced in Microsoft’s Developing OpenType Fonts for Korean Hangul Script document is not necessary. Jaemin Chung kindly pointed out to me that environments that do not yet support Unicode Version 5.2 still require the ‘ccmp‘ (Glyph Composition/Decomposition) GSUB feature to be present, otherwise proper shaping will not happen.

The main purpose of this short article is to provide a revised Perl script, named mkoldhangul-ccmp.pl, that adds a complete ‘ccmp’ GSUB feature definition for environments that do not yet support Unicode Version 5.2 (or greater). The sample glyph-map.txt datafile that maps the Unicode-based glyph names to CIDs is unchanged.

Okay. It is time to put some “K” into CJK…

Seriously, much of the content of this blog has been focused on Chinese and Japanese issues. This article will provide some much-deserved Korean content.

I spent the last few days coming to grips with Old Hangul (옛한글 yethangeul), specifically how to implement proper shaping using the three registered OpenType GSUB features, ‘ljmo‘ (Leading Jamo Forms), ‘vjmo‘ (Vowel Jamo Forms), and ‘tjmo‘ (Trailing Jamo Forms).
Continue reading…