I have advocated the use of the special-purpose and language-neutral Adobe-Identity-0 ROS over the past few years, and have developed several CID-keyed fonts that take advantage of this ROS, but keep in mind that its use can act like a double-edge sword.
On one hand, it provides font developers with great flexibility, in terms of the glyph complement of a font. In other words, font developers need not be restricted to one of our public CJK ROSes, such as Adobe-Japan1-6, or a subset thereof. Kazuraki is an example of a Japanese font whose glyph set requirements didn’t fit Adobe-Japan1-6, so the Adobe-Identity-0 ROS was used.
On the other hand, font developers need to develop all of the necessary resources, such as the UTF-32 CMap Resource that is used as the basis of the ‘cmap‘ table, which maps Unicode code points to glyphs in the font, along with any GSUB features. In addition, and because the Adobe-Identity-0 ROS is language-neutral in that its designation does not specify or suggest a primary language, some applications may incorrectly assign a primary language to such fonts. This, of course, is due to heuristics (発見的教授法 in Japanese), or more specifically, their failure.
In my experience, there are several ways that the font developer can help applications that are heuristic-driven, in order to provide them with enough information to correctly identify the primary language of an Adobe-Identity-0 font. These are listed below:
- Populate the ‘name‘ table with strings that are tagged with the primary language of the font. In the case of Kazuraki, Japanese-language strings, including those for the name of the font that are to be used in application font menus, were specified in its ‘name’ table.
- Although Adobe-Identity-0 ROS fonts do not require a Macintosh (pre–OS X) ‘cmap’ subtable, the AFDKO makeotf tool creates a “stub” one, meaning that it exists, but includes no usable mappings. The makeotf “-cs” option can be used to specify a Macintosh ScriptID as its argument, and specifying the appropriate value can help some applications. Suitable values include 1 (Japanese), 2 (Traditional Chinese), 3 (Korean), and 25 (Simplified Chinese).
- Manually set the ‘OS/2‘ table’s “UnicodeRange” and “CodePageRange” bits. This is especially important if the glyph complement does not trigger heuristics in makeotf to set specific bits that indicate that a particular Unicode block or legacy Code Page is intended to be supported, even if partially.
Of course, in addition to the above suggestions, adequate testing in real-world environments is important, which can help determine the extent to which a particular font is being treated appropriately by an application.
Comments