The Passing of My Mentor

On Thursday, December 3rd of 2015, a great man—and a man of faith—passed from our world to the next. Professor Edward Daub, my mentor and youngest son’s namesake, passed away at the age of 91.
Continue reading…

What’s in a ‘name’ (Table)?

By default, the AFDKO makeotf tool includes Macintosh (platformID=1, encodingID=0, languageID=0) ‘name‘ table strings, and if specified in the “FontMenuNameDB” or “features” files, localized Macintosh ‘name’ table strings will also be included. The next release of AFDKO will include “-omitMacNames” as a new command-line option for makeotf whose purpose is to exclude Macintosh ‘name’ table strings, other than any that are explicitly specified in the “features” file.
Continue reading…

IUC39 Presentation

IUC39 (The 39th Internationalization & Unicode Conference) took place in Santa Clara earlier this week, and Adobe was once again proud to be a Gold Sponsor. It was another outstanding and successful conference, and as usual, one of the greatest benefits of the conference—besides the many excellent presentations—was the opportunity for face-to-face exchanges with Unicode leaders, experts, and enthusiasts.
Continue reading…

Introducing FDArray Test

(The introductory graphic illustrates how the character (U+5263) is displayed using the fonts that are introduced in this article. The code point for this character maps to a glyph that displays as “63” in the FDArray Test 257 font, which is the hexadecimal equivalent of the decimal index of the FDArray element to which its glyph is assigned, which is 99. Likewise, the code point for this character maps to a glyph that displays as “52” in the FDArray Test 65535 font, which is the hexadecimal equivalent of the decimal index of the FDArray element to which its glyph is assigned, which is 82.)

I have built several CID-keyed OpenType/CFF fonts that are specifically designed to test various limits, by exercising various implementation limits, such as the number of glyphs (65,535 is the architectural limit), the number of FDArray elements (256 is the architectural limit), and the number of mappings in the ‘cmap‘ table (when the surrogates and non-characters are factored out, Unicode has 1,111,998 possible mappings in its 17 planes). I have sometimes made these fonts available, such as in this May of 2012 article that explains how such fonts can be built.

Anyway, I spent pretty much all day yesterday—except for a somewhat longer than usual lunch break that was actually used to watch The Martian (2015) with my wife—preparing a pair of open source CID-keyed OpenType/CFF fonts that exercise these limits but to different degrees, and I also managed to prepare and release the project on GitHub as FDArray Test.
Continue reading…

Two Biángs Are Better Than One

The Unicode Consortium is planning to once again propose the encoding of the well-attested ideograph whose reading is biáng. Previous attempts at encoding this ideograph have failed due to the lack of sufficient evidence, such as appearing in a dictionary or other printed source. This time, however, there is sufficient evidence, and the simplified form of this ideograph will also be included in the proposal. Both forms, along with their U-Source references UTC-00791 and UTC-01312, are depicted below:

Continue reading…

To V, Or Not To V

Historically, there have been two methods of supporting vertical writing in CID-keyed OpenType/CFF fonts, in terms of specifying the ‘vert‘ (Vertical Alternates) GSUB feature. One method involved using a vertical CMap resource, which was supplied to the AFDKO makeotf tool as an argument to its no-longer-supported “-cv” command-line option, that was used to synthesize the ‘vert’ GSUB feature. The other method, which is the preferred one, involves defining a ‘vert’ GSUB feature in the “features” file that is supplied to the AFDKO makeotf tool. In this brief article, I will explain why the first method is no longer supported, but more importantly, why the second method is preferred.
Continue reading…

IUC39 Preparations

I am scheduled to present at IUC39 (The 39th Internationalization & Unicode Conference) in late October, and the title of my presentation is Pan-CJK Font Development Techniques, Tips, Tricks & Pitfalls. While the related presentations that I delivered at IUC38 last November focused on actual Source Han Sans and Noto Sans CJK development details, this presentation will be more general, and will instead focus more on techniques and best practices when developing large multilingual fonts, drawing on the experience of developing and deploying those two joined-at-the-hip typeface families when necessary.

I am currently dealing with properly categorizing the various tidbits of the presentation as Techniques, Tips, Tricks, or Pitfalls. I decided to combine Tips and Tricks into the single category Tips & Tricks, because they’re roughly the same, but mainly because I found an excellent image that conveys the meaning of tricks. ☺

Anyway, I still have a lot of work left to do on this presentation, but at least I have another two months to complete it.

As I may have mentioned in past articles, the benefits of this conference go beyond the scheduled presentations, and much of the value is the golden opportunity for face-to-face interaction with developers who are involved in the development of Unicode, or who are working with Unicode on a daily basis.

For those who are planning to attend IUC39, I look forward to meeting you there. 🍷

Managing XUID Arrays—Redux

To follow up on my June 2011 article about managing XUID arrays in CIDFont resources, which still conveys accurate information, it has come to our attention that the integer values for the second and subsequent XUID array elements should not exceed seven digits, meaning that 9999999 is the largest integer value that should be used. Integer values that exceed seven digits can result in some implementations treating the XUID arrays of different fonts within the same printing job the same, which affects font caching, and which can result in the wrong font being used to render some characters. This printing issue may happen even if the glyphs display correctly in the PDF file on screen.

Another solution is to simply omit the XUID array from the CIDFont resource header, which effectively disables font caching. For modern printers, font caching has little or no benefit.

Lastly, for those font developers who still include a UIDBase value in their CIDFont resource headers, it can be safely removed. In fact, I strongly recommend that it be removed.

IRG44

(Uni-chan image designed by Mary Jenkins)

IRG44 (ISO/IEC JTC1/SC2/WG2/IRG Meeting #44), which was originally scheduled to take place from 2015-06-15 through 2015-06-19 in Seoul, Republic of Korea and was canceled due to MERS, will instead take place during the first part of next week in Beijing, People’s Republic of China, from 2015-08-24 through 2015-08-26.

Besides the obvious work on Extensions F1 and F2, other items of interest are the three UNC (Urgently Needed Character) proposals that will be discussed, from the UTC (two characters in IRG N2068), Japan (five characters in IRG N2078), and Macao SAR (36 characters in IRG N2071). Of particular interest is IRG N2071, because Section C.2 of IRG Principles and Procedures (IRG N2016) states that UNC submissions should not include more than 30 characters.

2015-08-21 Update: The revised version of Macao SAR’s IRG N2017 (N2071R) includes only 23 characters, meaning that it is now within the terms set forth in Section C.2 of IRG Principles and Procedures.

I have personal interest in IRG N2074, which provides preliminary details about Hong Kong SAR’s forthcoming HKCS (Hong Kong Character Set) 2015 standard, which is intended to replace Hong Kong SCS-2008. One reason for my interest is that I plan to support HKCS 2015 in the Source Han Sans Version 2.000 glyph set.

Although I cannot attend IRG44, a colleague and friend who works in our Beijing office will be attending as my proxy.

Exploring Typekit’s New Dynamic Kits

While I won’t repeat here any of the exciting details in Typekit’s recent announcement for East Asia web font support (简体中文, 繁體中文, 日本語, 한국어) that employs dynamic kits, I’d like to seize this opportunity to demonstrate some of the default behavior that this new development exposes in various browsers.
Continue reading…