Posts in Category "Testing Fonts"

Tales from the “Green Book” — ehandler.ps

Posted on December 18, 2016 by Dr. Ken Lunde | Comments (0)

Please pardon the apparent non-CJK interruption in the form of this particular article, but I wanted to bring to the readership’s attention a new open source project that has a very long history: ehandler.ps.
Continue reading…

Combining Jamo Test #3

Posted on December 2, 2016 by Dr. Ken Lunde | Comments (0)

Unlike the first and second similarly-titled articles that I published last month, this article will focus on a minor efficiency for the combining jamo feature of the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK Pan-CJK typeface families.
Continue reading…

Combining Jamo Test #2—Please Ignore

Posted on November 4, 2016 by Dr. Ken Lunde | Comments (0)

To (significantly) expand yesterday’s super exciting article, and in the continued interest of (stress-)testing the extent to which combining jamo works in various browsers—and when being served as a fully-functional webfont via Adobe Typekit—if you click here, you will open a 40MB HTML file that includes all 1,626,875 possible three-character combining jamo sequences (125 leading consonants, 95 vowels, and 137 trailing consonants) rendered using Adobe Clean Han and its 'ljmo' (Leading Jamo Forms), 'vjmo' (Vowel Jamo Forms), and 'tjmo' (Trailing Jamo Forms) GSUB features.

🐡

Combining Jamo Test #1—Please Ignore

Posted on November 3, 2016 by Dr. Ken Lunde | Comments (0)

In the interest of testing the extent to which combining jamo works in various browsers—and when being served as a fully-functional webfont via Adobe Typekit—if you click here, you will open a 200K HTML file that includes all 11,875 possible two-character combining jamo sequences (125 leading consonants and 95 vowels) rendered using Adobe Clean Han and its 'ljmo' (Leading Jamo Forms), 'vjmo' (Vowel Jamo Forms), and 'tjmo' (Trailing Jamo Forms) GSUB features.

🐡

Standards 101

Posted on September 13, 2016 by Dr. Ken Lunde | Comments (0)

Attention, students! Class is in session.

In my experience, the following two statements about standards are seemingly conflicting yet accurate:

  1. Standards are incredibly useful—and required—for product development.
  2. Standards cannot be completely trusted.

On one hand, developing products, such as typeface designs and their fonts, depends on standards.

On the other hand, standards themselves are developed by humans, meaning that they are prone to error, especially when they happen to be character set or glyph standards that include thousands or tens of thousands of representative glyphs.
Continue reading…

Introducing “LOCL Test”

Posted on April 8, 2016 by Dr. Ken Lunde | Comments (0)

Inspired by the font that I prepared for and referenced in the previous article, I decided to launch a dedicated open source project for this useful test font, LOCL Test.

Enjoy!

🐡

The Joy of tx

Posted on March 31, 2016 by Dr. Ken Lunde | Comments (0)

One of the most powerful font-development tools available today is tx (Type eXchange), which is included in AFDKO (Adobe Font Development Kit for OpenType) and whose sources are also available on GitHub. Despite its two-letter name, this command-line utility is packed with an enormous amount of features and functionality.

Four years ago I wrote a similar article, but it seems like a good time to revisit tx and the useful things that it can do. I still recommend that its “-u” and -h” command-line options be used to explore its vast capabilities.
Continue reading…

Introducing FDArray Test

Posted on October 16, 2015 by Dr. Ken Lunde | Comments (0)

(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…

Managing XUID Arrays—Redux

Posted on August 27, 2015 by Dr. Ken Lunde | Comments (0)

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.

Exploring Typekit’s New Dynamic Kits

Posted on June 16, 2015 by Dr. Ken Lunde | Comments (0)

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…