ISO/IEC 10646:2012 (Third Edition) was just published. This is the first version of the standard that includes multiple-column Code Charts for Extension B, and for CJK Compatibility Ideographs. Another significant aspect of ISO/IEC 10646:2012 is that it is equivalent to Unicode Version 6.1.
For Adobe, the publishing of this new version of the standard represents a significant milestone, because it means that every Adobe-Japan1-6 kanji is either directly encoded, or is directly associated with a registered IVS in the IVD (Ideographic Variation Database).
Speaking of Unicode Version 6.1, the printed version of the Core Specification is available via POD from Lulu, and at a very attractive price.
I just received good news, in the form of confirmation that both of my ATypI Hong Kong 2012 presentation abstracts were accepted, which means that I will definitely be attending this conference. I alluded to this in the March 30th, 2012 CJK Type Blog article. One of the abstracts is for a 30-minute presentation entitled Kazuraki: Under The Hood, which will immediately follow a 30-minute presentation entitled Kazuraki: Its Art & Design, that will be presented by my colleagues Taro Yamamoto (山本太郎) and Ryoko Nishizuka (西塚涼子). For those who are not aware, Ryoko is the typeface designer of Kazuraki (かづらき), which is the centerpiece of both 30-minute presentations. The other is for a three-hour workshop entitled Manipulating CID-keyed Fonts Using AFDKO Tools, which will be co-presented by my colleague Masataka Hattori (服部正貴).
I am very much looking forward to attending an ATypI conference for the first time, and meeting many people. If you are planning to attend ATypI Hong Kong 2012, please be sure to introduce yourself to me, in case I don’t introduce myself to you first.
For those font developers who are not aware, the official CMap resource repository for our public ROSes is the CMap Resources open source project at Open @ Adobe, which is hosted by SourceForge. When CMap resources are updated, in addition to providing the updates through this portal, an announcement is made in the CMap Resources Forum.
The UTF-16 and UTF-32 CMap resources were introduced in August of 2001, beginning with Adobe-CNS1-4. Those for Adobe-Korea1-2 and Adobe-Japan2-0 followed in January of 2002, followed by those for Adobe-GB1-4 in June of the same year. The UTF-16 and UTF-32 CMap resources for Adobe-Japan1-5 were not released until November of 2002. From that point, the UCS-2 CMap resources were deprecated, and were no longer updated. Clients that used the UCS-2 CMap resources were encouraged to use the UTF-16 or UTF-32 ones instead. For OpenType font development, in terms of building the Unicode (Format 4 and 12) ‘cmap‘ subtables, the UTF-32 CMap resources are recommended.
Years ago, I wrote a Perl script, called unicode-rows.pl, that takes a fully-qualified PostScript name—composed of a CIDFont resource name, two hyphens, and a UTF-32 CMap resource name—then generates a PostScript file that can be distilled into a PDF. The resulting PDF file is a Unicode table, arranged in groups of 256 code points. If the UTF-32 CMap resource includes even a single mapping for a particular group of 256 code points, a page is created.
I have prepared examples that are based on the UniJIS2004-UTF32-H and UniJIS-UTF32-H CMap resources.
As alluded to at the end of the May 9, 2012 CJK Type Blog article, I had plans to build additional CFR objects for testing purposes. That particular article supplied two 64K-glyph OpenType/CFF fonts, which provided BMP and Plane 1 coverage, and served as component fonts for the supplied CFR object, UnicodeGetaCFR.cfr. In today’s article, I will supply a CFR object that encompasses all of Unicode, meaning the BMP and the 16 Supplementary Planes, along with the component fonts that it references. In other words, coverage for 1,112,030 code points, each of which has a unique glyph. These represent valuable testing resources for developers who plan to support CFR objects in their products as a way to break the 64K glyph barrier.
For those AFDKO users who use, plan to use, or would like to explore the broad capabilities of its tx tool, here’s a command line that is very useful when building new versions of existing fonts, especially when only a small number of glyphs have changed:
% tx -bc -sha1 -z 400 <font_file>
The <font_file> portion of the command line can be any type of font file, such as an OpenType font, a CFF resource, a CIDFont resource, or a name-keyed Type 1 font.
As mentioned at the end of the May 15, 2012 CJK Type Blog article, I will demonstrate in this article how to build a CID-keyed font with 64K glyphs (CIDs 0 through 65534) and 256 FDArray elements. These represent two limits that are inherent in CIDFont resources.
Again, the incredibly powerful AFDKO mergeFonts tool will perform most of the work.
Today, I want to demonstrate how the AFDKO mergeFonts tool can be used to quickly and easily build a CID-keyed font that includes 64K glyphs, meaning CIDs 0 through 65534. This is the maximum number of glyphs that a CIDFont resource can contain. This font, of course, will use the special-purpose Adobe-Identity-0 ROS, and although its is a CID-keyed font, it will include only one FDArray element.
Adobe has thus far released two CID-keyed OpenType/CFF fonts that use the special-purpose Adobe-Identity-0 ROS (“ROS” is an abbreviation for /Registry, /Ordering, and /Supplement, which represent the three /CIDSystemInfo dictionary elements that are present in CIDFont and CMap resources): Kazuraki SP2N L (かづらき SP2N L) and Kenten Generic. The former is a commercial OpenType/CFF font, and the latter is an open source one. I have also developed several Adobe-Identity-0 ROS OpenType/CFF fonts for testing purposes, many of which have been provided in recent CJK Type Blog articles, the most recent of which being the May 9th, 2012 article.
The big question that may be on a font developer’s mind is under what circumstances is it appropriate to use the Adobe-Identity-0 ROS?
In the April 20, 2012 CJK Type Blog article, I wrote about the publishing of ISO/IEC 14496-28:2012 (Composite Font Representation), which provides a venue for breaking the 64K glyph barrier that is inherent in all sfnt-based font formats, including name- and CID-keyed PostScript fonts. If the number of glyphs of the combined component fonts that are referenced by a CFR object exceed 64K, would constitute breaking the 64K glyph barrier.