If you, as a font developer, prefer to use an OS other than Mac OS X or Windows as your primary development environment, please post a comment, being sure to indicate the details of the OS on which you’d like AFDKO tools to run.

Until such an event is scheduled and actually takes place, Adobe Tech Note #5900 (AFDKO Version 2.0 Tutorial: mergeFonts, rotateFont & autohint), which includes a Japanese translation, should prove to be useful. This document is included in AFDKO as part of its documentation, but its link is provided above for convenience.

I encourage anyone with an interest in attending such a workshop, to be held in Japan, to post comments that include suggestions for topics to be covered.

どうぞ自由に日本語で書いて下さい。

When subroutinizing smaller fonts, meaning those with relatively few glyphs, there really is no concern that subroutine limits will be reached. When the number of glyphs is significant, such as over 10,000, there is reason to be concerned because there are both implementation-specific and architecture limits on the number of subroutines. The architectural limit is “64K minus 3″ (65,533), and there are known implementation-specific limits that are “32K minus 3″ (32,765). The known implementations that limit the number of subroutines to “32K minus 3″ are Mac OS X Version 10.4 (aka, Tiger) and earlier, and Adobe Acrobat Distiller Version 7.0 and earlier.

When dealing with name-keyed fonts, these subroutine limit figures are applied to the global subroutines, because there are no local ones. Things get a bit more complex with CID-keyed fonts because the number of subroutines is determined by adding the number of local subroutines for each FDArray element with the number of global ones. In other words, the combination of the global subroutines plus those from any one FDArray element (local) cannot exceed the limit.

The AFDKO tx tool can be used to display the number of global and local subroutines through the use of the appropriate command-line options. I spent yesterday evening writing subr-check.pl, which is a wrapper for tx that is written in Perl. The output below demonstrates why the Kozuka Mincho Pr6N family was released in unsubroutinized form:

% subr-check.pl KozMinPr6N-Regular.cff
Global Subroutines: 29933 (388715 bytes)
Local Subroutines:
  FD=0: 1696 (36302 bytes)
  FD=1: 154 (2530 bytes)
  FD=2: 1633 (30574 bytes)
  FD=3: 6 (120 bytes)
  FD=4: 168 (1680 bytes)
  FD=5: 65 (747 bytes)
  FD=6: 151 (2327 bytes)
  FD=7: 163 (2437 bytes)
  FD=8: 60 (1058 bytes)
  FD=9: 87 (1332 bytes)
  FD=10: 1057 (109449 bytes)
  FD=11: 7143 (173874 bytes) > 32K-3 limit: 37076 (7143 + 29933)
  FD=12: 1785 (41891 bytes)
  FD=13: 807 (17851 bytes)
  FD=14: 809 (17682 bytes)
  FD=15: 181 (10099 bytes)
Total Subroutine Size: 838668 bytes

The subr-check.pl tool is expected to be included in the next release of AFDKO, which should happen this year. But, until then, developers can use this tool now.

In general, and with few exceptions, a CMap resource name is composed of a character set name, and encoding name, and a writing direction. For the most part, it is the character set names that deserve some explanation, because the encoding and writing direction names are fairly straight-forward. Also, whenever I mention a CMap resource name, it almost always has a corresponding vertical CMap resource.

Let’s begin where it all started, meaning OCF (Original Composite Format) names…

OCF Names That Became Adobe-Japan1-x Names

It makes a lot of sense to cover some of the names used in our OCF fonts, all of which carried forward to our CID-keyed fonts, specifically as the CMap resource names for the Adobe-Japan1-0 character collection. These OCF names provided some amount of inspiration for the names of new CMap resources.

The only encoding name that deserves an explanation is RKSJ, which is short for [single-byte] Roman, [half-width] Katakana, and Shift-JIS.

Perhaps the most controversial character set name is 83pv, which is used only for the 83pv-RKSJ-H CMap resource, and which corresponds to the Apple Macintosh Japanese character set up through KanjiTalk6. It is clear that the “83″ portion refers to 1983, which in turn refers to JIS X 0208-1983 (or probably JIS C 6226-1983, which was its original designation). What may be unclear is what “pv” actually stands for. The two common theories at Adobe are that it refers to “plus verticals” or “proportional [plus] verticals.” I asked the person who coined most of the names used in OCF fonts, and he indicated that the former is the correct interpretation. 83pv-RKSJ-H is unique in that it has no corresponding vertical CMap resource because the vertical variants are encoded using separate code points, hence the use of “pv” in its name, and the single-byte ASCII range maps to proportional Latin glyphs.

Another interesting name is Ext, which corresponds to the NEC Japanese character set, and which is obviously short for “Extended.”

Yet another interesting name is Add, which corresponds to the Fujitsu FMR Japanese character set. My source indicated that it is short for “Additional.”

The NWP name is an abbreviation for “NEC Word Processor.”

Note that everything that follows is specific to CMap resources for CID-keyed fonts, meaning that the names were never used by OCF fonts.

Adobe-Japan1-x Names

The 83pv-RKSJ-H CMap resource was intended to support (up to) the KanjiTalk6 character set. When the KanjiTalk7 character set was established, a new CMap resource was necessary. Not being one who likes to break from tradition, and because the KanjiTalk7 character set was based on JIS90 (aka, JIS X 0208-1990), I chose to use 90pv-RKSJ-H as the name. I even created an accompanying vertical CMap resource, 90pv-RKSJ-V. An accompanying vertical CMap resource for 83pv-RKSJ-H was never made, but it was considered. Given that it was used for so long without an accompanying vertical CMap resource, it was deemed unnecessary.

When Adobe-Japan1-2 was defined, which added the glyphs for the kanji necessary to support the IBM Japanese character set, it was now possible to support the Microsoft Windows Japanese character set. If memory serves, this was based on Windows Version 3.1. This character set is based on JIS X 0208-1990, with Microsoft’s extensions, and encoded according to Shift-JIS, so 90ms-RKSJ-H is what I came up with. When we needed to make a version of this CMap resource that mapped the single-byte ASCII range to proportional Latin glyphs, I simply appended a “p” to the character set name: 90msp-RKSJ-H.

After JIS X 0213:2004 (aka, JIS2004) was established, and Microsoft, followed by Apple, decided to support its prototypical glyphs as the default in the fonts bundled in their respective OSes, I needed to come up with new CMap resource names. Although I am getting a bit ahead of myself by talking about Unicode, the only CMap resources that support JIS2004 are ones that support Unicode. I simply appended “2004″ to the character set portion of the existing Unicode CMap resources, as follows:

Adobe-GB1-x Names

The GB name, of course, refers to GB 2312-80, which is the most widely implement Simplified Chinese character set standard. It serves as the foundation for GB/T 12345-90, GBK, and GB 18030. The GBT name refers to GB/T 12345-90 (the “GB” and “T”), and not to the Traditional version of GB 2312-80.

The pc identifier is used after both GB versus GBT, and refers to “proportional characters,” and not “personal computer.” The reasoning here is that the default, at the time, single-byte Latin set was half-width, not proportional.

The GBK character set name, of course, refers to GBK. When GB 18030 was established, in 2000, which was an extension of GBK, I opted to use GBK2K (GBK 2000) as the character set name.

Adobe-CNS1-x Names

The most common encoding name for these CMap resources is B5, which is short for Big Five. Like with Adobe-GB1-x CMap resources, the pc identifier refers to “proportional characters,” and is used for Macintosh.

The HKm314 and HKm471 character set names refer to two different Hong Kong extensions to Big Five that were defined by Monotype Imaging. The numbers, 314 and 471, referred to the number of characters above and beyond Big Five. Likewise, the HKdla and HKdlb character set names refer to two different Hong Kong extensions to Big Five that were defined by DynaComware. The HKgccs name corresponds to Hong Kong GCCS (Government Chinese Character Set), which was an initial attempt at defining a national standard for Hong Kong. All of these character set names have been effectively superseded by the HKscs character set name, which corresponds to Hong Kong SCS (Supplementary Character Set), whose latest version is 2008 (previous versions were dated 1999, 2001, and 2004).

Adobe-Korea1-x Names

It is somewhat unfortunate that I chose to use KSC as a character set name, which corresponded to KS C 5601. I should have used KS. Keep in mind that this name was coined in 1995, and on August 20, 1997, KS C 5601 was redesignated as KS X 1001.

As described in the Adobe-GB1-x section, the pc identifier refers to “proportional characters.” It is used for the KSCpc-EUC-H CMap resource. Again, the reasoning here is that the default, at the time, single-byte Latin set was half-width, not proportional.

Interestingly, the use of ms in the KSCms-UHC-H CMap resource name is somewhat redundant, because the UHC (Unified Hangul Code) is specific to Microsoft Windows.

Unicode CMap Resources

I built the first Unicode CMap resources in the earlier half of 1996, mainly as an experiment. The first ones were for Japanese (Adobe-Japan1-x). Before I knew it, and because they were deemed to be very useful, they were bundled with a product, specifically Illustrator Version 7.0.

In any case, I chose to use “Uni” followed by another identifier, usually tied to an ROS (/Registry, /Ordering, and /Supplement, which correspond to the three elements of the /CIDSystemInfo dictionary in CIDFont and CMap resources), as the character set name. The table below details the names that I came up with:

Of course, most of these names make sense.

For Adobe-Japan2-0, which supported JIS X 0212-1990, I obviously couldn’t use “JIS,” because UniJIS was already being used by Adobe-Japan1-x. In retrospect, I could have used UniJIS0212, but I opted to use UniHojo instead. “Hojo” corresponds to 補助 (hojo) in Japanese, which means “supplemental,” and is part of the name of JIS X 0212-1990: 情報交換用漢字符号—補助漢字 (jōhō kōkan yō kanji fugō—hojo kanji).

For Adobe-Korea1-x, note that I used UniKS, and not UniKSC.

In summary, and in retrospect, I could have used different, better, or more descriptive names for CMap resources, but changing names after they were established would do more harm than good. Perhaps what is more important is the history of the names that were chosen for use in our CMap resources, and I hope that this post provides some answers.

Given that Unicode has become the de facto encoding for digital text for modern environments, I encourage readers of this blog to explore for themselves what is new in Unicode Version 6.1.

Because I need to guarantee that the glyph for each CID (Character ID) is the correct one, I needed to create the data as InDesign Tagged Text, which is a markup language used by Adobe InDesign. There is special syntax for specifying glyphs by CID. The following is used to specify CID+23058:

<cSpecialGlyph:23058><001A><cSpecialGlyph:>

I used the following Perl script to create the InDesign Tagged Text data:

#!/usr/bin/perl

print STDOUT "\n";

I simply specified “65534″ as the argument to create an InDesign Tagged Text file that covers all possible CIDs (0 through 65534), as follows:

% mkcidtable-indd-tt.pl 65534 > data-65534.txt

The next step is to import the InDesign Tagged Text file, data-65534.txt, into an InDesign document, then format it as a multiple-page table. Note that each CID that is specified is surrounded by U+230D and U+230C characters. I built a special-purpose (name-keyed) OpenType font that includes non-spacing glyphs for registration marks, which I encoded using these code points. I’d rather not enter 65,535 pairs of registration marks manually, so they are included as part of the InDesign Tagged Text file.

Other than formatting the table, I needed to create the following four named Character Styles: GlyphTableFont, GlyphTableFontInvisible, Tombo, and TomboInvisible. The Character Styles that include “Invisible” in the name have no color specified, meaning that the characters do not display, and are thus are invisible. The “Tombo” Character Style specifies red as the character color. BTW, tombo (トンボ) is the Japanese word for registration mark. Once I have a fully-formatted table, I create a second layer called “Registration Marks,” and copy the entire table to that layer. I now have the same table in two layers. In the “Main Text” layer, I apply the “GlyphTableFont” Character Style to the 65,535 glyphs. This is easily done by searching for “<001A>” using the Find/Replace feature, and applying the Character Style. The same is done in the “Registration Marks” layer, but the “GlyphTableFontInvisible” Character Style is applied instead. The registration marks are handled in a similar way, by searching for “<230D>” and “<230C>,” then applying the “TomboInvisible” and “Tombo” Character Styles in the “Main Text” and “Registration Marks” layers, respectively.

When exporting the document to PDF, be sure that the PDF version is 1.5 or greater, which is the first version to support layers, and to select the option to include the layers. For these glyph tables, I lock the main layer, because it doesn’t make much sense to allow readers to make that portion of the document invisible. The “Registration Marks” layer is the interesting one, because toggling it on and off will make the registration marks appear and disappear.

What I ended up with is a multiple-page two-layer InDesign table that can be repurposed in the future, and is not bound to any specific ROS. Given that the maximum CID is 65534, I saved myself a ton of work by building a table that encompasses all 65,535 possible CIDs.

My first use of this table was to update Adobe Tech Note #5079, which was done quickly and easily.

I built an “extreme” OpenType font last year, and spent the morning making it even more extreme. Given that “extreme” fonts are useful for stress-testing software that consumes fonts, I figured that this post would be a good opportunity to make it available to developers who may benefit by testing with this font.

Did I mention that I like building fonts? ☺

When I first developed this OpenType font, called UnicodeAll, last year, it included the following two “extreme” characteristics:

• The Format 12 (UTF-32) ‘cmap‘ subtable includes mappings for all 1,112,030 Unicode code points. In other words, all of the code points for the BMP (Basic Multilingual Plane) plus the 16 Supplementary Planes, but excluding the 2,048 Surrogates in the BMP, and excluding 0xFFFE and 0xFFFF in the BMP and in the 16 Supplementary Planes.
• The ‘CFF‘ table includes 256 FDArray elements (aka, hint dictionaries), which is the maximum.

This CID-keyed font advertised the special-purpose Adobe-Identity-0 ROS (/Registry, /Supplement, and /Ordering), and included only 257 glyphs. CID+0 acted as the .notdef glyph, and CIDs 1 through 256 used glyphs that correspond to the geta (下駄; U+3013) character, like this (sans registration marks, of course):

CIDs 1 through 256 were simply mapped from UTF-32 values that ended in 0x00 (CID+1) through 0xFF (CID+256).

The third “extreme” characteristic that I added to this font today was the following:

• The ‘CFF‘ table includes 65,535 glyphs (CIDs 0 through 65534) are included, which is the maximum number of glyphs for a CIDFont resource.

CID+0 continues to act as the .notdef glyph, and CIDs 1 through 65534 map from their respective code points in the range 0x0000 (CID+1) through 0xFFFD (CID+65534) in the BMP and in each of the 16 Supplementary Planes. The glyphs for CIDs 1 through 65534 are the same, and are still that of the geta character.

I would like to point out that AFDKO tools, specifically tx, mergeFonts, and makeotf, were used to build the CIDFont resource, and the subsequent OpenType font. Of course, a couple of carefully-crafted Perl scripts were used to build some of the datafiles, such as the mergeFonts mapping files and mappings for the CMap resource.

Click here to download this font.

And, enjoy!

Supplements 1 and 2 were defined at the same time, sometime during 1993, and were implemented as separate Supplements simply because it was thought that some fonts might support only the glyphs in Supplement 1 (75 additional glyphs: CIDs 8284–8358) and not those in Supplement 2 (361 additional glyphs: CIDs 8359–8719). The primary purpose of Supplement 2 was to support the IBM extensions for JIS X 0208.

Supplement 3 (634 additional glyphs: CIDs 8720–9353) was defined in September of 1998, in the very early days of OpenType. Its purpose was to add pre-rotated forms of all glyphs that were not full-width, which meant proportional and half-width glyphs, which are made accessible via the OpenType ‘vrt2‘ GSUB feature.

Supplement 4 (6,090 additional glyphs: CIDs 9354–15443), which was declared final on February 21, 2000, was the first time that one of our CJK glyph sets leaped beyond coverage of character set standards, and intended to include glyphs that are deemed important for professional and commercial publishing. Thus, Adobe-Japan1-4 fonts were the first to use the “Pro” designator in their names. It was quite an undertaking, which involved working with several key Japanese type foundries, such as Asahi Shimbun, Dainippon Screen, Fontworks, Morisawa, Motoya, and TypeBank, along with experts, such as Yasushi Naoi (直井靖). I keep a thick stack of papers and notes that detail much of the work, and from time to time I consult this stack to find answers to obscure questions. I even kept its three drafts, dated June 1, 1999, August 7, 1999, and November 5, 1999.

Supplement 5 (4,873 additional glyphs: CIDs 15444–20316) was declared final in September of 2002, and primarily involved working with Apple, to turn their APGS (Apple Publishing Glyph Set) into what would become Adobe-Japan1-5. I worked very closely with Yasuo Kida (木田泰夫) of Apple during this project. Another goal of Adobe-Japan1-5 included complete coverage of JIS X 0213:2000, which was also a goal of APGS.

Supplement 6 (2,741 glyphs: CIDs 20317–23057), which is the latest and greatest, was declared final on March 5, 2004. The two goals of Adobe-Japan1-6, besides ensuring support of JIS X 0213:2004, was to complete support for JIS X 0212-1990, which had the side effect of obsoleting, and subsequently deprecating, the Adobe-Japan2-0 character collection. Supporting the U-PRESS character set was also a goal, and naturally, almost immediately after Adobe-Japan1-6 was finalized, a small number of characters were added to U-PRESS.

Although there is no schedule at this time, I have already begun (very) preliminary work on Supplement 7, which mainly amounts to maintaining a list of glyph candidates (such as the characters that were subsequently added to U-PRESS).

Please join me in celebrating the first 20 years of Adobe-Japan1-6!

Adobe-GB1-5 GSUB Features

The “ag15-gsub.txt” file includes definitions for the following nine GSUB features (in lookup order): aalt, dlig, fwid, hwid, nalt, pwid, trad, vert, and vrt2.

Note that these GSUB feature definitions can be used as-is for Supplement 4 and 5 fonts, because the highest CID that is referenced is CID+29063, which is in Adobe-GB1-4.

Adobe-CNS1-6 GSUB Features

The “ac16-gsub.txt” file includes definitions for the following 10 GSUB features: aalt, ccmp, dlig, fwid, hwid, nalt, pwid, liga, vert, and vrt2.

Note that these GSUB feature definitions can be used as-is for Supplement 3 through 6 fonts, because the highest CID that is referenced is CID+18832, which is in Adobe-CNS1-3.

Adobe-Japan1-3 GSUB Features

When building Adobe-Japan1-3 fonts, there are three basic glyph sets to consider. The most basic is Adobe-Japan1-3 proper (CIDs 0–9353), which is used to build fonts that use the “Std” identifier in their names. The “aj13-gsub.txt” file includes definitions for the following 14 GSUB features: aalt, dlig, expt, fwid, hwid, jp04, jp78, nlck, pwid, liga, trad, zero, vert, and vrt2.

When building JIS2004-savvy Adobe-Japan1-3 fonts, which use the “StdN” identifier in their names, an additional 144 glyphs outside the scope of Adobe-Japan1-3 (but still within Adobe-Japan1-6) should be included (CIDs 9354, 9779, 12101, 12870, 13320–13327, 13330, 13332–13333, 13335–13341, 13343, 13345–13355, 13358–13369, 13371, 13373–13382, 13385–13388, 13391–13400, 13402, 13460, 13495, 13538, 13624, 13650, 13673, 13731, 13803, 13860, 13893, 13915, 13949, 13964, 14013, 14066, 14074, 14111, 14116, 14196, 14272, 14290, 16977, 17041, 18760, 19312, 19346, 20175, 20222, 20263–20296, 20301–20305, 20307, 20314, and 21072–21074). The “aj13-gsub-jp04+144.txt” file includes definitions for the following 14 GSUB features: aalt, dlig, expt, fwid, hwid, jp78, jp90, nlck, pwid, liga, trad, zero, vert, and vrt2. Note that jp90 is included in lieu of jp04.

The third Adobe-Japan1-3–based glyph set to consider is a subset that is intended for building fonts that include glyphs only for (full-width) kana plus a small number of punctuation and symbols (CIDs 0–1, 232–233, 238–240, 243, 245–258, 262, 290, 292, 295, 326–331, 503–514, 633–642, 651–655, 659–661, 663, 665–666, 668, 670–679, 682–693, 695–697, 708–709, 711–719, 723–739, 780–789, 842–1010, 7612, 7887–7888, 7891–7892, 7894–7895, 7897, 7899–7904, 7907–7939, 7958–7960, 8009–8014, 8210, 8264–8265, 8268, 8273–8283, 8307, 8313–8316, 8720, 8951–8952, 8957–8959, 8962, 8964–8977, 8981, 9009, 9011, 9014, 9048, 9084–9089, and 9265–9275). The “aj13-kana-gsub.txt” file includes definitions for only the following five GSUB features: aalt, fwid, hwid, vert, and vrt2.

Adobe-Japan1-4 GSUB Features

When building Adobe-Japan1-4 fonts, there are two basic glyph sets to consider. The most basic is Adobe-Japan1-4 proper (CIDs 0–15443), which is used to build fonts that use the “Pro” identifier in their names. The “aj14-gsub.txt” file includes definitions for the following 31 GSUB features: aalt, afrc, ccmp, frac, numr, dnom, dlig, expt, fwid, hkna, hojo, hwid, jp04, jp78, jp83, nalt, nlck, pwid, ital, liga, qwid, ruby, subs, sinf, sups, trad, twid, zero, vert, vkna, and vrt2.

When building JIS2004-savvy Adobe-Japan1-4 fonts, which use the “ProN” identifier in their names, an additional 81 glyphs outside the scope of Adobe-Japan1-4 (but still within Adobe-Japan1-6) should be included (CIDs 16413, 16444–16449, 16467–16468, 16889, 16905, 16977, 17014, 17041, 17168, 17205, 18759–18760, 19061, 19312, 19346, 20175, 20222, 20263–20296, 20299–20310, 20312–20315, 21071–21074, 21558, 21933, 22010, and 22920). The “aj14-gsub-jp04+81.txt” file includes definitions for the following 31 GSUB features: aalt, afrc, ccmp, frac, numr, dnom, dlig, expt, fwid, hkna, hojo, hwid, jp78, jp83, jp90, nalt, nlck, pwid, ital, liga, qwid, ruby, subs, sinf, sups, trad, twid, zero, vert, vkna, and vrt2. Note that jp90 is included in lieu of jp04.

Adobe-Japan1-5 GSUB Features

When building Adobe-Japan1-5 fonts, there are two basic glyph sets to consider. The most basic is Adobe-Japan1-5 proper (CIDs 0–20316), which is used to build fonts that use the “Pr5″ identifier in their names. The “aj15-gsub.txt” file includes definitions for the following 32 GSUB features: aalt, afrc, ccmp, frac, numr, dnom, dlig, expt, fwid, hkna, hojo, hwid, jp04, jp78, jp83, nalt, nlck, pkna, pwid, ital, liga, qwid, ruby, subs, sinf, sups, trad, twid, zero, vert, vkna, and vrt2. (The additional GSUB feature, when compared to Adobe-Japan1-4, is pkna.)

When building JIS2004-savvy Adobe-Japan1-5 fonts, which use the “Pr5N” identifier in their names, an additional ten glyphs outside the scope of Adobe-Japan1-5 (but still within Adobe-Japan1-6) should be included (CIDs 21071–21074, 21371, 21558, 21722, 21933, 22010, and 22920). The “aj15-gsub-jp04+10.txt” file includes definitions for the following 32 GSUB features: aalt, afrc, ccmp, frac, numr, dnom, dlig, expt, fwid, hkna, hojo, hwid, jp78, jp83, jp90, nalt, nlck, pkna, pwid, ital, liga, qwid, ruby, subs, sinf, sups, trad, twid, zero, vert, vkna, and vrt2. Note that jp90 is included in lieu of jp04.

Adobe-Japan1-6 GSUB Features

When building Adobe-Japan1-6 fonts, there is only one glyph set, specifically Adobe-Japan1-6 proper (CIDs 0–23057), which is used to build fonts that use the “Pr6″ or “Pr6N” identifier in their names. The “aj16-gsub.txt” file includes definitions for the same set of 32 GSUB features as included in the “aj15-gsub.txt” file, but some of the features include additional substitutions that take advantage of the additional glyphs provided in Supplement 6.

When building JIS2004-savvy Adobe-Japan1-6 fonts, which use the “Pr6N” identifier in their names, the “aj16-gsub-jp04.txt” file, which includes definitions for the same set of 32 GSUB features as included in the “aj15-gsub-jp04+10.txt” file, should be used (though, like the “aj16-gsub.txt” file, some of the features include additional substitutions that take advantage of the additional glyphs provided in Supplement 6).

Adobe-Korea1-2 GSUB Features

The “ak12-gsub.txt” file includes definitions for the following 11 GSUB features: aalt, dlig, fwid, hngl, hwid, nalt, pwid, sinf, sups, vert, and vrt2.

The “ak12-hangul-gsub.txt” file, which is intended for use with Korean fonts that exclude the glyphs for the 4,620 hanja (CIDs 3436–8055) and thus included only CIDs 0–3435 and 8056–18351, is identical to the “ak12-gsub.txt,” but excludes the hngl GSUB feature.

Whew…

1. 500 glyphs are shown per page, comprised of 25 rows and 20 columns. By comparison, the old-style glyph table shows only 120 glyphs per page. Of course, the glyphs are smaller, but keep in mind that the old-style glyph table comes from an era when documents were expected to be printed, while today’s documents are expected to be viewable on displays, and being able to zoom into individual glyphs is the norm.
2. Each glyph includes registration marks, whose purpose is to denote relative width (in an implicit way), and the height of the em-box. This is no different than the old-style glyph table, but the new-style adds the ability to turn off the display of the (red) registration marks. This is done thanks to layers. InDesign supports layers, and as long as the PDF is exported for Acrobat Version 6.0 or greater (aka, PDF Version 1.5 or greater), the layers are preserved in the PDF file. For some purposes, the glyph registration marks are helpful, but can sometimes be a distraction. Being able to make them go away is a clear benefit of this new-style glyph table.

To better illustrate the second benefit, I have excerpted part of a page from one of the updated Adobe Tech Notes, showing its default state (all layers are visible) when opened in Acrobat or Reader:

The Layers Panel allows layers to be toggled on/off, in terms of their visibility, and below is the same page, but with the “Registration Marks” layer turned off:

About the Adobe Tech Note updates, in terms of their content…

Adobe Tech Note #5080 (The Adobe-CNS1-6 Character Collection) was updated to reflect Supplement 6, which added 68 glyphs, all of which are hanzi, to support the Hong Kong SCS-2008 character set standard.

Adobe Tech Note #5093 (The Adobe-Korea1-2 Character Collection) was updated to correct the representative glyph for CID+4419. Its left-side component was missing one stroke. CID+4419 currently maps from U+90DE (郞) and U+F92C (郎), the latter of which is a CJK Compatibility Ideograph. As soon as Unicode Version 6.1 is released, there will be a third mapping for this glyph, specifically U+FA2E, which is also a CJK Compatibility Ideograph.

I am planning to update Adobe Tech Note #5078 (The Adobe-Japan1-6 Character Collection) in the next month or two, mainly to make adjustments to bring the explanatory material up-to-date. The representative glyphs will not be changed.

As a reminder to font developers, particularly those who develop CJK fonts, the latest versions of the CMap resources that are associated with our public character collections—Adobe-GB1-5, Adobe-CNS1-6, Adobe-Japan1-6, and Adobe-Korea1-2—are made available at the CMap Resources open source project that is hosted at Open @ Adobe.