Posts in Category "Building Fonts"

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…

August 2, 2016—A Date Which Will Live In Dignity

Posted on August 1, 2016 by Dr. Ken Lunde | Comments (2)

August 2, 2016 is the official release date for Microsoft’s Windows 10 Anniversary Update (aka Redstone or RS1). Although I do not use Windows OS, I am jumping for joy, for the benefit of those who do use this modern and world-class OS.

Thanks to our friends at Microsoft, the DirectWrite that ships with the Windows 10 Anniversary Update supports OpenType/CFF Collections (aka OTCs), such as those deployed as part of the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK open source projects, to include their all-inclusive “one font to rule them all” Super OTCs.


Continue reading…

Glyph Names versus CIDs

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

This will be a short, sweet, and to-the-point article. Sorry, no graphics nor photos.

When developing name-keyed fonts, glyph names matter. They matter a lot. When developing new fonts, the glyph names should either be explicitly listed in AGLFN (Adobe Glyph List For New Fonts) or derivable via the AGL Specification. Glyph names that adhere to AGLFN or the AGL Specification result in fonts with well-formed 'cmap' tables, which means that their glyphs will behave better in a broader range of environments. I cannot stress the importance of this.

CIDs (Character IDs), on the other hand, represent a completely different beast. If a font is genuinely CID-keyed, it means that there are absolutely no glyph names, regardless of whether the source font or fonts that were used to build the CID-keyed font were named-keyed. Once a font resource becomes CID-keyed, the original glyph names are literally jettisoned, and the only way in which to map Unicode values to glyphs is via the 'cmap' table, which is usually done using a UTF-32 CMap resource. In other words, when developing fonts that are intended to be deployed in a CID-keyed fashion, the source glyph names play absolutely no role in how such fonts are processed.

🐡

XUID Arrays: One Less Thing To Worry About

Posted on June 11, 2016 by Dr. Ken Lunde | Comments (0)


By ESO/José Francisco Salgado (josefrancisco.org) — ALMA antennas under the Milky Way

Five years ago, I wrote this article that described how to manage XUID arrays. Then last year, I wrote this article that suggested that XUID arrays are no longer necessary.

Anyway, there are two messages that are being conveyed in today’s article.

The first message is short and sweet, and meant to be strong: Adobe advises against including XUID arrays in all new and updated font-related resources, meaning fonts themselves and their corresponding CMap resources. The good news is that omitting the XUID array represents one less thing to worry about during font development.

The second message is longer, meant to provide some background information, and describes why Adobe advises against including XUID arrays in font-related resources.
Continue reading…

Tofu, Or Not Tofu

Posted on May 20, 2016 by Dr. Ken Lunde | Comments (0)

One of my more popular open source fonts is Adobe Blank, and to a less extent the related Adobe Blank 2 because it uses a 'cmap' table format, Format 13, that is not broadly supported. Actually, Adobe Blank provides absolutely nothing, because it maps all 1,111,998 Unicode code points to a range of 2,048 non-spacing and non-marking glyphs, yet such a font is useful for particular scenarios, such as addressing the FOUT (Flash Of Unstyled Text) problem.

Allow me to introduce Adobe NotDef, which is modeled after Adobe Blank in that it covers all of Unicode and maps to a range of 2,048 glyphs, but differs in that the functional glyphs are spacing and marking. The original suggestion for Adobe NotDef came from Dave Crossland. The glyphs match the shape and advance width of the standard Adobe .notdef glyph that is invoked in environments that do not support font fallback when the selected font does not include a glyph for a particular character, and as Dave wrote, Adobe NotDef is useful for font fallback purposes in that it can be used to prevent the display of non-standard .notdef glyphs that may be present in some fonts in the font fallback chain.
Continue reading…

Introducing “Width Test”

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

It seems that I am on roll, having released two new open source fonts on GitHub within the past week. The previous—and brief—article that was about the LOCL Test OpenType/CFF font simply pointed to the repository. This article will be longer. I promise.
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!

🐡

Hong Kong or Bust!—Redux

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

Although this article shares its title with an article from four years ago that was about the excitement associated with attending ATypI Hong Kong 2012, this particular one will focus on efforts to properly support Hong Kong SAR (aka HK or Hong Kong) in the Adobe-branded Source Han Sans and Google-branded Noto Sans CJK typeface families, but also in infrastructure, such as OSes and apps.

In other words, this article is not about traveling to Hong Kong, but rather about properly supporting Hong Kong in OSes, apps, and fonts.
Continue reading…

Something fell between the cracks!

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

A peculiar series of events that took place on April 1st (no joke) and 2nd of this year led to the discovery of what can only be described as somewhat of a revelation: A small number of CJK Compatibility Ideographs are necessary for China. This is important, because I made the following statement on page 168 of CJKV Information Processing, Second Edition:


Continue reading…

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…