In Part 1 and Part 2 of this series, I demonstrated how AFDKO tools can be used to convert name-keyed fonts into CID-keyed ones. Part 1 resulted in a font that uses the special-purpose Adobe-Identity-0 ROS, and Part 2 resulted in one that uses a standard character collection, specifically the Adobe-Japan1-0 ROS.
Part 3 in this series will demonstrate how GSUB features—using the ‘vert‘ GSUB feature as an example—can be added to both types of fonts. Click here to download an archive that includes the various files and resources that are referenced in this article.
The name-keyed OpenType font that was the basis for Part 1 included the ‘vert’ GSUB feature, whose definition can be displayed by using the AFDKO spot tool as follows:
% spot -tGSUB=7 KozGoKanaNK-Heavy.otf
# Printing lookup 0 in feature 'vert' for script 'DFLT' language 'dflt'.
# --- Start Lookup [0])
# -------- SubTable 0
sub uni3001 by uniFE11;
sub uni3002 by uniFE12;
sub uniFF1A by uniFF1Av;
sub uni30FC by uni30FCv;
sub uni2015 by uniFE31;
sub uni301C by uni301Cv;
sub uni2016 by uni2016v;
sub uni2026 by uniFE19;
sub uniFF08 by uniFE35;
sub uniFF09 by uniFE36;
sub uni3014 by uniFE39;
sub uni3015 by uniFE3A;
sub uniFF3B by uniFE47;
sub uniFF3D by uniFE48;
sub uni3008 by uniFE3F;
sub uni3009 by uniFE40;
sub uni300A by uniFE3D;
sub uni300B by uniFE3E;
sub uni300C by uniFE41;
sub uni300D by uniFE42;
sub uni300E by uniFE43;
sub uni300F by uniFE44;
sub uni3010 by uniFE3B;
sub uni3011 by uniFE3C;
sub uniFF1D by uniFF1Dv;
sub uni2192 by uni2193;
sub uni2190 by uni2191;
sub uni2191 by uni2192;
sub uni2193 by uni2190;
sub uni3041 by uni3041v;
sub uni3043 by uni3043v;
sub uni3045 by uni3045v;
sub uni3047 by uni3047v;
sub uni3049 by uni3049v;
sub uni3063 by uni3063v;
sub uni3083 by uni3083v;
sub uni3085 by uni3085v;
sub uni3087 by uni3087v;
sub uni308E by uni308Ev;
sub uni30A1 by uni30A1v;
sub uni30A3 by uni30A3v;
sub uni30A5 by uni30A5v;
sub uni30A7 by uni30A7v;
sub uni30A9 by uni30A9v;
sub uni30C3 by uni30C3v;
sub uni30E3 by uni30E3v;
sub uni30E5 by uni30E5v;
sub uni30E7 by uni30E7v;
sub uni30EE by uni30EEv;
sub uni30F5 by uni30F5v;
sub uni30F6 by uni30F6v;
sub uni3095 by uni3095v;
sub uni3096 by uni3096v;
# --- End Lookup [0])
# Skipping lookup 0 in feature 'vert' for script 'kana' language 'dflt' because already dumped in script 'DFLT', language 'dflt'.
# Skipping lookup 0 in feature 'vert' for script 'latn' language 'dflt' because already dumped in script 'DFLT', language 'dflt'.
If you remember, Step 1 of Part 1 resulted in a “final.txt” file that I stated would be useful for subsequent parts of this series. Indeed, it is useful for this part. The first and fourth columns correlated the CIDs in the newly-built CID-keyed font with the glyph names of the original name-keyed font. While this mapping is essential when converting glyph names to CIDs when using the AFDKO mergeFonts tool, it is also useful for converting glyph names to their corresponding CIDs in GSUB feature definitions.
The conversion process is simple: replace the glyph names with their corresponding CIDs (being sure to prefix the CIDs with a single blackslash character), then declare the ‘vert’ GSUB feature according to “feature” file syntax. Assuming that the spot output above is in a file named “vert.raw,” the name2cid.pl Perl tool that I crafted for this purpose performs the necessary text processing for this task:
% name2cid.pl vert.txt
Here is the contents of the “vert.txt” file:
feature vert {
substitute \4 by \218;
substitute \5 by \262;
substitute \6 by \217;
substitute \8 by \9;
substitute \9 by \10;
substitute \10 by \11;
substitute \11 by \8;
substitute \15 by \215;
substitute \16 by \216;
substitute \19 by \227;
substitute \20 by \228;
substitute \21 by \225;
substitute \22 by \226;
substitute \23 by \229;
substitute \24 by \230;
substitute \25 by \231;
substitute \26 by \232;
substitute \27 by \223;
substitute \28 by \224;
substitute \30 by \221;
substitute \31 by \222;
substitute \32 by \263;
substitute \33 by \264;
substitute \35 by \265;
substitute \37 by \266;
substitute \39 by \267;
substitute \41 by \268;
substitute \67 by \269;
substitute \99 by \270;
substitute \101 by \271;
substitute \103 by \272;
substitute \110 by \273;
substitute \117 by \274;
substitute \118 by \275;
substitute \121 by \276;
substitute \123 by \277;
substitute \125 by \278;
substitute \127 by \279;
substitute \129 by \280;
substitute \155 by \281;
substitute \187 by \282;
substitute \189 by \283;
substitute \191 by \284;
substitute \198 by \285;
substitute \205 by \286;
substitute \206 by \287;
substitute \212 by \288;
substitute \239 by \219;
substitute \240 by \220;
substitute \254 by \289;
substitute \256 by \290;
substitute \259 by \233;
substitute \260 by \234;
} vert;
The contents of the “vert.txt” file can simply be added to the “features” file that was created in Part 1 (incrementing the head.FontRevision value is good practice), and the AFDKO makeotf tool can be used to build a new version of this CID-keyed OpenType font that now includes a fully-functional ‘vert’ GSUB feature, using the exact same command line as in Part 1:
% makeotf -f cidfont.ps -cs 1 -r -ch cmap.txt
The CID-keyed OpenType font that was the result of Part 2 was based on a standard character collection, Adobe-Japan1-0, and instead of synthesizing GSUB features, existing resources can be leveraged. Specifically, the standard ‘vert’ GSUB feature definition can be used, but it must be modified to exclude substitutions for which the glyphs are not present in the font. Given the glyph complement of the sample font of Part 2, the following is a complete ‘vert’ GSUB feature definition:
feature vert {
substitute \634 by \7887;
substitute \635 by \7888;
substitute \636 by \8268;
substitute \637 by \8274;
substitute \842 by \7918;
substitute \844 by \7919;
substitute \846 by \7920;
substitute \925 by \7928;
substitute \927 by \7929;
substitute \929 by \7930;
} vert;
Of course, the “features” file that was provided in Part 2 included this same ‘vert’ GSUB feature definition, and the purpose of this section is to simply explain how it was created.
Both techniques—converting glyph names to CIDs in GSUB (or GPOS) feature definitions, or simply referencing existing feature definitions when the CID-keyed font is based on a standard character collection—scale easily for thousands or tens of thousands of glyphs, especially if you write simple tools to help with these text-processing tasks.
Comments