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.
弊社のAFDKO（Adobe© OpenType©フォント開発キット）を利用されてフォント制作を行われている開発者の方々を対象としたワークショップとなります。それぞれのツールについて有効な利用法について、弊社米国本社のKen Lunde（ケン・ランディ）を含む弊社スタッフが説明する予定です。ぜひご参加ください。
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.
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.
For those who develop fonts—professionally or otherwise—it is prudent to know where the latest and greatest documentation is located. This is useful not only when searching for specific documentation, but also to check whether there are any updates to existing documentation.
The right-side navigation bar of this blog’s landing page includes links to relevant documentation and resource pages, such as for font-related Adobe Technical Notes, the OpenType Specification (hosted on Microsoft’s website), and even AFDKO (Adobe Font Development Kit for OpenType). Also, don’t forget about the excellent font developer resources offered by Apple (Fonts), FontLab, and Microsoft (Microsoft Typography).
Among the many excellent and powerful tools included in AFDKO (Adobe Font Development Kit for OpenType) is one with a two-letter name: tx. Although it has the shortest name, it is arguably one of the most powerful AFDKO tools.
The tx tool is best thought of as a multi-purpose font-file–manipulation tool. For those who don’t leverage this tool in the font development activities, I strongly encourage you to explore its capabilities, which is best done by perusing its built-in help and through experimentation.
In yesterday’s CJK Type Blog post, I introduced and provided three Perl tools for listing the CIDs and GIDs in font resources: extract-cids.pl, extract-gids.pl, and mkrange.pl. In my continued effort to provide font developers with useful tools, I spent a few minutes this morning to enhance two of these tools, specifically extract-cids.pl and mkrange.pl.
When working with OpenType/CFF fonts, particularly those that are CID-keyed, CIDs (Character IDs) and GIDs (Glyph IDs) are often referenced as ways to uniquely identify glyphs in a font resource. But, how are CIDs and GIDs different, and perhaps more importantly, under what circumstances are they different, or the same? These are good questions, and the answers can be found in today’s article.
When hinting name- or CID-keyed fonts, appropriate hinting parameters are required. One of these parameters are alignment zones whose purpose is to snap shapes to pixel boundaries. Alignment zones are specified in the required /BlueValues array, and also in the optional /OtherBlues array.
The required /BlueValues array is specified in the /Private dictionary of name-keyed fonts, and in the /Private dictionary of each FDArray element of CID-keyed fonts. The purpose of this array is to specify alignment zones that are at the baseline or above, such as for the baseline, x-height, and cap-height. The optional /OtherBlues array is used to specify alignment zones that are below the baseline, such as for the descender. This article will demonstrate how the AFDKO stemHist tool can be used to determine appropriate alignment zone values.
The photo below, which was recently taken by my long-term Adobe colleague Dirk Meyer in Beijing, serves as a not-so-gentle reminder that intersecting outlines can result in very obvious printing errors:
The photo depicts the two ideographs 出口, which represent the word meaning exit. The glyphs are obviously designed through the use of components whose outlines necessarily intersect, and under some circumstances—including the circumstance that led to the printing of this signage—can result in a negative or reverse fill.
I spent the better part of last weekend revising Adobe Tech Note #5099, which was originally published in 1998 (14 years ago). If memory serves, I wrote the bulk of the original version of this document while on vacation in Indonesia. It seemed like the thing to do at the time.
When using AFDKO to develop CID-keyed OpenType/CFF fonts, the most important CMap resources are the UTF-32 ones, for the following reasons:
- Unicode has become the de facto character encoding for today’s OSes and applications.
- When the font includes mappings outside the BMP (Basic Multilingual Plane), the Format 12 (UTF-32) ‘cmap‘ subtable is included. When a font includes only BMP mappings, the AFDKO makeotf tool is smart enough not to create a Format 12 ‘cmap’ subtable, and instead creates only a Format 4 (BMP-only UTF-16) one.
- UTF-32 is arguably the most human-readable of the Unicode Encoding Forms, because its big-endian hexadecimal representation is simply the Unicode Scalar Value without the “U+” prefix and zero-padded to eight digits.
The AFDKO makeotf tool is used to build a fully-functional font, and a UTF-32 CMap resource is specified as the argument of its “-ch” command-line option.
As the IVD Registrar, I am very pleased to announce that a new version of the IVD (Ideographic Variation Database) was released on March 2nd, 2012. It incorporates the results of PRI 183 and PRI 187.
On this 29th day of February in the year 2012, which is a leap year, I decided that it would be a good idea to whip up a tool (written in Perl, of course) that enumerates the FDArray elements in a CID-keyed font, by name and index, and to list the CIDs that are assigned to it. Also reporting the ROS is useful. This tool, called fdarray-check.pl, makes use of the AFDKO tx tool, and massages its output into a form that is much more human-readable, and which can be repurposed.