Historically, there have been two methods of supporting vertical writing in CID-keyed OpenType/CFF fonts, in terms of specifying the ‘vert‘ (Vertical Alternates) GSUB feature. One method involved using a vertical CMap resource, which was supplied to the AFDKO makeotf tool as an argument to its no-longer-supported “-cv” command-line option, that was used to synthesize the ‘vert’ GSUB feature. The other method, which is the preferred one, involves defining a ‘vert’ GSUB feature in the “features” file that is supplied to the AFDKO makeotf tool. In this brief article, I will explain why the first method is no longer supported, but more importantly, why the second method is preferred.
First and foremost, CJK fonts require support for vertical writing, and the preferred mechanism is via the ‘vert’ GSUB feature, which should be automatically invoked when the writing direction is vertical. The affected characters are typically punctuation and some symbols, but for Japanese it also affects the so-called small kana, whose glyphs shift from the lower-left corner of the em-box to the upper-right corner.
If one peruses the CMap Resources project, almost all of the CMap resources have a vertical counterpart, whose CMapName strings end with “-V.” However, if one explores the Source Han Sans project, there are no vertical CMap resources to be found, because they are not necessary.
CMap resources unidirectionally map character codes, such as Unicode, to CIDs, and the corresponding ‘cmap‘ tables in OpenType fonts also unidirectionally map character codes to GIDs. Both of these mappings are limited to operating on character codes. The method of using a vertical CMap resource to synthesize the ‘vert’ GSUB feature thus excludes two important classes of vertical substitutions: those for unencoded glyphs such as variants, and those for characters whose glyphs are represented through the use of sequences.
A good example of the former class are the short versions of U+300C through U+300F (「」『』), whose glyphs are included in Adobe-Japan1-6 as CIDs 12123 through 12126, and are ‘aalt‘ (Access All Alternate) GSUB feature alternates of their standard (encoded) forms at CIDs 686 through 689. The example below shows the standard version of U+300E (『) and its vertical form, along with the corresponding short versions:
The following Adobe-Japan1-6 ‘aalt’ and ‘vert’ GSUB feature excerpts show how U+300E (CID+688) is substituted with its short form (CID+12125), which is then substituted for its appropriate vertical form (CID+12135):
feature aalt useExtension {
substitute \688 from [\510 \7913 \12072 \12125 \12135];
} aalt;
feature vert {
substitute \12125 by \12135;
} vert;
A prime example of the latter class is JIS X 0213 1-06-88, which must be represented as the sequence <31F7 309A> (ㇷ゚) in Unicode. A graphic that depicts the horizontal and vertical forms of this character is at the very beginning of this article. The ‘ccmp‘ (Glyph Composition/Decomposition) GSUB feature first converts the sequence of two glyphs into a single glyph, which is then substituted with its vertical form via the ‘vert’ GSUB feature. In Source Han Sans, U+31F7 and U+309A map to CIDs 1862 and 1540, respectively, and the following ‘ccmp’ and ‘vert’ GSUB feature excerpts show how they become the appropriate glyphs for horizontal and vertical writing:
feature ccmp {
substitute \1862 \1540 by \61782;
} ccmp;
feature vert {
substitute \61782 by \65484;
} vert;
In other words, CID-keyed OpenType/CFF font developers should not be concerned with vertical CMap resources, and should instead focus their energies on the ‘vert’ GSUB feature, taking into account UTR #50 (Unicode Vertical Text Layout).
In closing, I would like to state that the vertical CMap resources in the CMap Resources project will continue to be maintained, mainly for consistency, and for historic and legacy reasons.
Comments