As I wrote nearly a year ago, the Adobe-Identity-0 ROS is useful for building special-purpose fonts, especially CJK ones whose glyph coverage does not match one of our public ROSes. Our latest Adobe-Identity-0 ROS font is the open-source Adobe Blank, whose purposes and implementation details are described on our sister blog, Typblography.
Posts in Category "Building Fonts"
I will close this particular topic by detailing how to support these proposed standardized variants in OpenType/CFF fonts.
For fonts that are currently IVS-enabled, such as those that include Format 14 ‘cmap’ subtables with Adobe-Japan1 or Hanyo-Denshi IVSes, it is important to note that the proposed standardized variants can co-exist with them, at least in terms of being specified in the font. For the former, I created an Adobe-Japan1_sequences.txt file that includes all registered Adobe-Japan1 IVSes, along with 89 of the 1,002 proposed standardized variants. The 89 standardized variants are at the end of the file. AFDKO tools, such as makeotf and spot, already support these standardized variants. When building OpenType/CFF fonts using the makeotf tool, this file is specified as the argument of the “-ci” command-line option.
To continue from the December 26, 2012 article, I should first point out that there is a relationship between these 1,002 proposed standardized variants and IVSes (Ideographic Variation Sequences). Standardized variants are standardized, hence their name. IVSes, on the other hand, are registered via a process that is described in UTS #37 and administered by the IVD Registrar (which happens to me at the moment).
One problem that has been plaguing CJK Compatibility Ideographs is the fact that they are adversely affected by normalization. Regardless of which of the four normalization forms is applied—NFC, NFD, NFKC, or NFKD—they are converted to their canonical equivalents, which are CJK Unified Ideographs. This is a problem, particularly for Japan, because 75 kanji in JIS X 0213:2004 kanji map to CJK Compatibility Ideograph code points. Furthermore, 57 of these 75 kanji correspond to Jinmei-yō Kanji (人名用漢字), meaning that they are used for personal names. The bottom-line problem with CJK Compatibility Ideographs is that any application of normalization, by any process, will permanently remove any distinctions between a CJK Compatibility Ideograph and its canonical equivalent. Not all processes are under one’s direct control, meaning that it is impossible to guarantee that normalization will not be applied. My opinion is that it is prudent to assume that normalization will be applied, and that preemption is the best solution.
In the December 4, 2012 Old Hangul article I mentioned that the ‘ccmp’ GSUB feature that is referenced in Microsoft’s Developing OpenType Fonts for Korean Hangul Script document is not necessary. Jaemin Chung kindly pointed out to me that environments that do not yet support Unicode Version 5.2 still require the ‘ccmp‘ (Glyph Composition/Decomposition) GSUB feature to be present, otherwise proper shaping will not happen.
The main purpose of this short article is to provide a revised Perl script, named mkoldhangul-ccmp.pl, that adds a complete ‘ccmp’ GSUB feature definition for environments that do not yet support Unicode Version 5.2 (or greater). The sample glyph-map.txt datafile that maps the Unicode-based glyph names to CIDs is unchanged.
Okay. It is time to put some “K” into CJK…
Seriously, much of the content of this blog has been focused on Chinese and Japanese issues. This article will provide some much-deserved Korean content.
I spent the last few days coming to grips with Old Hangul (옛한글 yethangeul), specifically how to implement proper shaping using the three registered OpenType GSUB features, ‘ljmo‘ (Leading Jamo Forms), ‘vjmo‘ (Vowel Jamo Forms), and ‘tjmo‘ (Trailing Jamo Forms).
For those who make use of the extract-cids.pl, extract-gids.pl, or extract-names.pl tools, all of which are AFDKO tx tool filters and are included in AFDKO, and whose purpose is to list the glyphs in the specified font resource, I’d like to introduce a new tool, named glyph-list.pl, which combines their functionality, thus making font development simpler.
Yesterday—meaning Wednesday, October 10th, 2012, Hong Kong Time (UTC+8)—I had the honor and privilege to present the first two hours of a three-hour ATypI Hong Kong 2012 workshop entitled Manipulating CID-Keyed Fonts Using AFDKO Tools. When I did a rough count, there were nearly 30 people in attendance. I’d like to use this opportunity to thank those who were able to attend, which meant that they made the effort to travel to this conference, and also chose to attend this workshop in lieu of attending presentations from the Typography & Reading and Typography & Culture tracks, or other concurrent workshops. I’d also like to provide to those who attended, and to those who were not able to attend, the presentation that I used to drive these two hours, which includes material that can be studied and referenced.
In addition to installing the latest-and-greatest version of AFDKO, the workshop attendees were also provide with the actual sample font data that I used to demonstrate the various workflows and techniques.
My hope is that these materials are useful to those who attended this workshop, and to those who were not able to do so. Enjoy!
Speaking of enjoy, that is what I plan to do for the remaining four days of this five-day conference. ☺
One of the most useful bits of feedback that I received from my portion of the June 25, 2012 AFDKO Workshop was that I include workflow diagrams that visually explain how various tools and control files work together. While preparing to present the same material at ATypI Hong Kong 2012 on the afternoon of October 10, 2012, I spent last Friday and this week creating additional presentation slides that include such workflow diagrams.
As I wrote earlier today on our sibling blog, Typblography, a new version of AFDKO was release earlier this month. I want to use this opportunity to point out some of the changes and enhancements that affect font developers who work with CID-keyed fonts. The details are buried in the detailed Release Notes that Read Roberts prepared.
As described in the August 24, 2012 article, I am currently updating most of our OpenType Japanese fonts. One aspect of the update is to include the 32 additional IVSes, based on the March 2, 2012 version of the IVD (Ideographic Variation Database), which means that all of the kanji in Adobe-Japan1-6 now have a “plain text” representation. Another aspect of this particular update is to use the latest UTF-32 CMap resources, which include three additional mappings, one of which is U+9FCC that was appended to the URO (Unified Repertoire & Ordering) in Unicode Version 6.1. But, the topic of this article is about fixing a small number of glyphs, and the techniques that I used to do so.
I spent part of this week staging the data for some minor glyph corrections for our Kozuka Mincho and Kozuka Gothic fonts—and those that are derived from them—and was reminded that the techniques I described in the February 27, 2012 article are incredibly useful and indeed time-saving. These same techniques were also conveyed during the AM session of the June 25, 2012 AFDKO Workshop, as shown is the presentation slide below:
Many thanks to Nozomu KATŌ (加藤望) for bringing to my attention that the Adobe-Japan1-6 Unicode CMap resources were missing the following mapping:
U+207F → CID+15908
I decided to add this mapping to the following eight Adobe-Japan1-6 Unicode CMap resources this evening:
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.
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