Standards | CJK Type Blog

Posts in Category "Standards"

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.

Unicode Version 9.0

Posted on July 17, 2016 by Dr. Ken Lunde | Comments (0)

For those who missed the memo, Unicode Version 9.0 was released on June 21, 2016, which added exactly 7,500 characters to the standard. Unicode now includes a total 128,172 characters, which is just shy of 3,000 characters under two full 256×256 planes.

While Version 9.0 does not add any new CJK Unified Ideographs, I used this opportunity to enhance my single-page CJK Unified/Compatibility Ideographs document to better track unassigned code points for the relevant blocks and planes. The image at the top of this article shows the first half of the document, and if you click on it, you’ll access the original PDF file that can be squirreled away for reference purposes.

I also used this opportunity to update my tentative Unicode Version 10.0 document in the same way.

As usual, enjoy!

🐡

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.

🐡

25 Years of Unicode

Posted on May 12, 2016 by Dr. Ken Lunde | Comments (2)

The Unicode Consortium celebrated its 25th anniversary in January of this year. The photo above is the celebratory (U+1F955 CARROT; a Unicode Version 9.0 candidate) cake that was enjoyed during the UTC (Unicode Technical Committee) #146 meeting that was hosted by IBM in San José from January 25th through 28th, 2016.
Continue reading…

Soon To Open: Plane 3, the Tertiary Ideographic Plane

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

Guess what.

🤔

Plane 2, the SIP (Supplementary Ideographic Plane), is almost full.

Right off the bat, in Unicode Version 3.1 (March of 2001), Extension B filled it nearly two-thirds of the way with its 42,711 characters, along with 542 CJK Compatibility Ideographs. Extension C with 4,149 characters was added in Version 5.2 (October of 2009), Extension D with a mere 222 characters was added in Version 6.0 (October of 2010), and Extension E with 5,762 characters was added in Version 8.0 (June of 2015). On tap for Unicode Version 10, scheduled for a June of 2017 release, is Extension F that currently includes 7,473 characters (U+2CEB0 through U+2EBE0).
Continue reading…

Badges? We don’t need no stinkin’ badges!

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

Actually, we do.

As pointed out in Matthew Rechs‘ recent and excellent Typekit Blog article about Unicode’s Adopt a Character campaign, these badges were designed by the very talented Jake Giltsoff of the Typekit team at Adobe. Mine for U+1F421 🐡 BLOWFISH is shown above.
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: