March 11, 2010
As I mentioned in the Typblography article on January 2nd, 2010, the type designer of our groundbreaking new OpenType Japanese font, Kazuraki (かづらき), won an award in 2002 for her earlier, but similar, typeface design. I am very pleased to announce that Kazuraki, an Adobe Originals typeface design by Adobe’s own Ryoko Nishizuka (西塚涼子), recently won its first award, specifically that it is among the winning TDC2 2010 typeface designs.
We’d like to extend to Ryoko our sincere congratulations for this noteworthy and well-deserved achievement. 本当におめでとうございます！ It is quite an honor to have her on our team.
January 2, 2010
Our groundbreaking new OpenType Japanese font, Kazuraki (かづらき), is now available for sale on our Type Showroom, including those for Japan, France, and Germany. Click here to be taken to the ordering page, which also includes links to its Specimen Book and Glyph Complement PDFs.
Kazuraki was designed by Adobe Systems’ Senior Typeface Designer, Ryoko Nishizuka (西塚涼子), which began as a typeface called Teika that won the Silver Prize in the Kanji Category at Morisawa’s 2002 International Typeface Competition.
Although Kazuraki is branded as a kana font, and includes a full complement of glyphs for hiragana and katakana, it also includes glyphs for 1,082 kanji, symbols, and punctuation, along with fifty vertical two-, three-, and four-character hiragana ligatures. A defining characteristic of Kazuraki is that is fully-proportional in both writing directions. Some glyphs are wider than they are tall, and vice versa, and this is reflected in the glyph metrics. Below is an example:
For those who wish to read about the production details, Adobe Tech Note #5901 is available, and a Japanese translation is provided.
September 12, 2009
I’d like to use this opportunity to share some recent artwork from Type Development at Adobe Systems. This is a thumbnail of a Kazuraki poster that was designed for an internal Tech Fair that will take place during the coming week. Kazuraki is genuinely proportional Japanese font that is based on the writings of Fujiwara-no-Teika, and designed by Adobe’s own Ryoko Nishizuka. This poster was also designed by the font’s designer. (Click on it to see a larger version.)
August 29, 2009
Finally. Yesterday, Friday, August 28th, 2009 is significant, at least for me, in that it represents the release date for Mac OS X Version 10.6 (aka, Snow Leopard). What is important about Snow Leopard is that it is the first OS that provides built-in support for IVSes (Ideographic Variation Sequences). Up until now, IVSes had been supported in specific Adobe products, such as Acrobat Version 9.0 and Adobe Reader Version 9.0 in the context of Forms, Flash Player Version 10, and InDesign CS4.
For those who are unaware of IVSes, they represent standardized Unicode behavior that allows otherwise unencoded variants of CJK Unified Ideographs to be represented using “plain text” that survives conditions that would cause rich text to fail. IVSes are registered via IVD (Ideographic Variation Database) Collections. The first IVD Collection to be registered at the end of 2007, was Adobe-Japan1, and is currently aligned with the Adobe-Japan1-6 character collection. See: http://www.unicode.org/ivd/
OpenType Japanese fonts can be IVS-enabled by building a Format 14 ‘cmap’ subtable. The AFDKO tools (in particular, MakeOTF and spot) are IVS-savvy, as well as DTL OTMaster (and the Light version).
February 20, 2009
For those who were not aware, late last year we launched the CJK Type blog, which is meant to focus on CJK-related aspects of type (hence its name).
August 31, 2008
Over on Typophile, Nick Shinn asked: “What is the difference between a code page, a glyph list, and a Unicode chart?” (By that last I think he meant “Unicode range.”) Nick also made some mentions of “encoding” in the same thread, so I thought I would define the whole lot of them. I expect this will be useful to font developers, and perhaps some other folks as well. I’ve just dashed this off, so I reserve the right to twiddle the descriptions for more accuracy and/or clarity. Especially if my readers point out errors.
August 28, 2008
About two years ago I posted my thoughts on extended Cyrillic character sets. Now we’re finally ready to talk about future extended Latin character sets, and to better document what we consider to be the existing Latin character sets as well. The largest character sets here (Adobe Latin 4 and Adobe Latin 5) are drafts; I welcome any feedback, especially (though not only) on things that “ought to be in Adobe Latin 5” but aren’t there yet.
This post owes a special thanks to my colleague Miguel Sousa, who spent many hours compiling lists based on my spreadsheets and directions, and checked my data repeatedly in various ways. Any errors are probably mine, but he created the linked tables of HTML which are linked from this page, as well as the tab-delimited text files which are linked in turn from those pages.
August 11, 2008
Every so often I get a request (either from within or outside Adobe) for a “Unicode font.” Unfortunately, that term is not very meaningful to me. The obvious interpretations are:
1) To me as a font geek, the phrase “a Unicode font” “logically” means “a font with a unicode encoding (cmap table).” That would be pretty much every one of the 2400+ OpenType fonts Adobe has in our type library. So that interpretation doesn’t really narrow things much.
2) They could mean “a font that covers all of Unicode.” However, Unicode today has over 100,000 defined code points, and as there is no font format that can include more than 65,535 glyphs, such a font is not technically possible. (There’s a separate question as to whether it would be desirable – see below.)
3) They could also mean “a font that covers some useful subset of Unicode that is more than just the basic WinANSI or MacRoman 8-byte (256-character) set.” However, for that to be meaningful, they’d have to define exactly what writing systems or languages are important to them.
June 5, 2008
Some folks have been asking, so I thought it would be handy to summarize the language and OpenType layout support in the Flash Player 10 public beta.
April 22, 2008
Failure to support the dotless i character in Turkish cell phone causes two deaths. Note to unnamed cell phone company: fix your bug.
No, it’s not April 1st any more, and I couldn’t make up a story this good. I got tipped to it from this article in Gizmodo.
Basically, in Turkish the dotless i is a different character than the i with a dot. Incorrectly leaving the dot on in displaying an SMS message from another cell phone led to a misunderstanding which culminated in a self-defence killing and a suicide.
Reportedly, most cell phones in Turkey don’t support the dotless i (which in the article is called a “closed i” – I’m using the font geek term instead).
Now, one might wonder why the cell phones lack Turkish localization support. Is it because of the expense of localizing (tailoring to a specific market) or globalizing (supporting more or all markets)? Are many Turkish cell phones grey market imports because they can be had cheaper that way?
Even if all cell phone companies were to localize their Turkish offerings, the same story could have happened with Turkish immigrants living in another country. In a perfect world, we would have cell phones everywhere that supported all the world’s languages. Of course, that’s not about to happen any time soon.
But at least it helps raise awareness of the issue, and perhaps more folks will think about how much language support they can squeeze into a product, and the costs and benefits of doing so.