When developing OpenType/CFF fonts, in particular CJK ones or those with a large number of glyphs, one question that I am often asked by developers is whether it should be name-keyed or CID-keyed. The answer to this question is not simple, though it truly is a binary condition.
Hoping not to detract from the attention that Paul Hunt‘s Source Sans Pro, Adobe’s first open source typeface family, deserves, I’d like to use this opportunity to point out that another font, a single typeface design with a very small number of glyphs, was Adobe’s first entry in the open source world, in terms of font offerings. Kenten Generic was released on November 4th, 2010 at the Open @ Adobe portal. It includes only thirteen glyphs—ten of which are functional—that are intended for use in typesetting emphasis marks, which are referred to as kenten (圏点) in Japanese, hence the font’s name. The easiest way to view its glyphs is to download its Unicode-based glyph synopsis.
I just spent a few minutes perusing the ATypI Hong Kong 2012 program. OMG. This is a literal dream come true for those interested in East Asian (aka CJK) typographic issues. Never before has this collection of experts gathered in a single location. My only regret is that I am unable to clone myself, because there are concurrent sessions in which I interested, or sessions that are taking place at the same time I am scheduled to present.
Again, if you’re on the fence about attending ATypI Hong Kong 2012, I urge you to attend. Such an opportunity is unlikely to present itself for a long time.
Given that this is the first time that ATypI will take place in East Asia, the number of CJK-related presentations is relatively high, and this should be expected considering its venue. To those who are on the fence about attending, I urge you to attend because ATypI is not likely to take place in East Asia for many more years. It is an opportunity that should not be missed. And, like other conferences, one of the greatest benefits—not listed on the program—is the opportunity for one-on-one interactions with others in this industry.
As a side note, I am very much looking forward to speaking at and attending ATypI Hong Kong 2012, and meeting new and familiar faces while there.
On July 25, 2012, Apple released to the world Mac OS X Version 10.8 (aka Mountain Lion). Among the many new features in this latest iteration of Mac OS X is support for CFR objects. For those who are not aware, CFR objects are based on ISO/IEC 14496-28:2012 (Composite Font Representation), and are used to define both composite fonts and fallback fonts. CFR objects effectively break the 64K glyph barrier. Mac OS X Version 10.8 is thus the first implementation that has broken the 64K glyph barrier.
I spent the second half of June in Korea (attending IRG 38) and Japan (to present at the Tokyo AFDKO Workshop), and am now spending the first two weeks of July in Hot Springs, South Dakota, on vacation. These place are worlds apart, in terms of location and cultural differences.
Still, I enjoy traveling to these places. Of course, not much happens in terms of font development in South Dakota, unless some crisis arises that requires my attention. There are many interesting places to visit in this area, such as Mount Rushmore (the photo below was taken in August of last year).
I am enjoying this vacation, but I also look forward to returning to work in about two weeks.
Once again, to those who were able to attend the Tokyo AFDKO Workshop that was held at Morisawa‘s Tokyo office on June 25th, thank you for your participation! Not counting those from Adobe and Morisawa, a total of 21 people attended. (Details about the AM session were covered in the previous article.)
For those who attended, and for those who could not attend, the presentation for Masataka Hattori’s (服部正貴) portion of the workshop is now available for download. Besides demonstrating how to build OpenType/CFF fonts based on the Adobe-Japan1-x and Adobe-Identity-0 ROSes, one of the highlights of Masataka’s presentation was demonstrating how to build a font that includes fully-proportional kana glyphs, based on the proven techniques which were used to develop Kazuraki (かづらき) that are detailed in Adobe Tech Note #5901 (Special-Purpose OpenType Japanese Font Tutorial: Kazuraki).
To those who were able to attend the Tokyo AFDKO Workshop that was held at Morisawa‘s Tokyo office on June 25th, thank you for your participation (and for enduring my poor Japanese speaking abilities)! I hope that you learned new ways in which particular AFDKO tools can be used to make your CID-keyed font production work (or workflow) more effective and less time-consuming.
These tools are tx filters, and simply output the list of CIDs or GIDs in a font. I had been using another tool, mkrange.pl, to turn the list into ranges. One of the enhancements, which is the addition of an “-r” option, makes the mkrange.pl tool no longer necessary. In other words, the following two command lines have the same result:
% extract-cids.pl -r <font>
% extract-cids.pl <font> | mkrange.pl
The extract-cids.pl tool was additionally enhanced with an “-s” option, which outputs the ranges on a single line using a comma separator. This makes the output very convenient in terms of repurposing it, such as copying it, then pasting it into a new command line as the argument of the “-g” option that is supported by many AFDKO tools. Consider the following two command lines and their output:
% extract-cids.pl -r cidfont.ps
% extract-cids.pl -r -s cidfont.ps
I am currently in Gyeongju (경주시/慶州市), Republic of Korea (ROK), attending IRG 38. For those who are not aware, the IRG (Ideographic Rapporteur Group) is an ad hoc subcommittee of ISO/IEC JTC1/SC2/WG2 (aka WG2), and is charged with all matters related to CJK Unified Ideographs. In other words, all CJK Unified Ideograph repertoires, the latest being Extension D, are the direct result of work by the IRG. I am attending IRG 38 as the sole US and Unicode delegate, and this is the fifth IRG meeting I have attended. IRG meetings are week-long working meetings, and are held twice per year.
For those who signed up to attend the AFDKO Workshop that takes place on the 25th of this month in Tokyo, be warned that I will be conducting my portion, which is from 10AM until noon, in Japanese, or at least in my rendition of Japanese. ☺
Seriously, though, I hope that my Japanese skills, or lack thereof, don’t serve as an impediment for those who attend this workshop. My focus will be to demonstrate how particular AFDKO tools, such as tx, mergeFonts, rotateFont, autohint, and so on, can be used to not only build, but also to directly manipulate CID-keyed fonts. My hope is that I can convey useful information that can serve as inspiration for making font production workflows more efficient and less time-consuming.
For those who are attending, note that materials will be provided that will be based on a small subset of Kozuka Gothic Medium. If any attendee wants to use their own font data for this purpose, I suggest that you bring along an Adobe-Japan1-0 or greater OpenType/CFF font or CIDFont resource. I have prepared scripts that will quickly create the same materials, but using a different base font.
Wish me luck in finishing the accompanying presentation, which currently has 24 slides. In Japanese.
I am very much looking forward to meeting everyone who has signed up to attend this workshop!
I am spending most of my time preparing for the Tokyo AFDKO Workshop that Morisawa is hosting at their Tokyo office on the 25th of this month, which is a Monday. At this point, most of the sample data is ready, and I now need to prepare the accompanying presentation slides.
This will be my first opportunity to engage a larger number of font developers, and to convey to them useful tips, tricks, and techniques for several AFDKO tools, particularly tx, mergeFonts, and rotateFont. My portion of the workshop, which will consume the entire morning, will be about building and manipulating CID-keyed fonts, to include controlling the assignment of CIDs (glyphs) to FDArray elements. I will also cover the use of the special-purpose Adobe-Identity-0 ROS. I am very much looking forward to this event, and working directly with many font developers.
Note that this workshop will be conducted in Japanese.
As alluded to in the February 8, 2012 CJK Type Blog article, there is a good chance that an AFDKO Workshop will take place in Japan, very soon. Please stay tuned to this blog for details, which may emerge in less than a week.
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.
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.