Typblography

‘Myriad’ in Arabic and Hebrew scripts

The ever-popular Myriad type family now has new Arabic and Hebrew members! These have recently been added as part of a suite-wide effort to provide better support for languages of the Middle East and North Africa (MENA). These new typefaces were designed and developed by the Adobe type team in San Jose and have already be recognized for their excellence as one of the winners of the Letter.2 competition conducted by the Association Typographique Internationale. A core set of styles from these type families is bundled with Adobe Creative Suite 6 applications. This core set includes four basic styles: Regular, Bold, Italic, and Bold Italic. However, the type styles bundled with CS6 include only a small subset of the new Myriad Arabic and Myriad Hebrew type systems that were created to provide a wider range typographic options for designers. To preview and purchase additional styles or the full families, see our pages for Myriad Arabic and Myriad Hebrew. In the future, these pages will include glyph complement showings for the fonts, likewise full digital specimens with text showings are still forthcoming.

I am pleased to announce that this year Adobe is one of the sponsors of the Indian Institute of Technology’s Typography Day at its Industrial Design Centre in Mumbai. In connection with this event, I will be presenting on the typesetting capabilities for Indian scripts in Adobe InDesign. This will only be the beginning of my journey….

In order to benefit individuals active in the field of typeface design, I will also be hosting a series of one-day type development workshops in several Indian cities. These workshops will be targeted at helping to foster local type designers and engineers within India and will thus be limited to persons residing in the region.

Continue reading…

Rupee glyphs from various type styles

How often do you write out the words “dollars,” “pounds sterling,” or “euros”? I’d wager that you seldom do as the symbols $, £, €, and ¢ are so easily to write and to access via computer and mobile keyboards. We may take these currency signs for granted, however not every major currency has its own mark. In particular, the Indian rupee has not had its own symbol until the past year. In early 2009, the Indian government announced a competition calling for the development of a character that would symbolize its national currency, the rupee, at home and in international markets. The final design, a symbol created by Udaya Kumar, was chosen and was ratified July 15, 2010¹. In a rare case of good timing and swift action, the rupee symbol was encoded in the latest revision of the Unicode standard, version 6.0, which went into effect October 11, 2010².

Indian rupee symbol from Minion Pro Regular

Despite having been made official less than a year ago, it seems that the Indian rupee symbol is quickly gaining widespread use within India. This has resulted in several of Adobe’s major international customers requesting font support for this character. In order to accommodate these requests, the type team at Adobe has added the rupee symbol to the following typeface families: Minion Pro³, Myriad Pro⁴, Courier Std⁵, and Letter Gothic Std⁶.

Continue reading…

Japan’s Agency for Cultural Affairs (文化庁) published the official revision of the Jōyō Kanji (常用漢字) set less than a week ago, on November 30, 2010. For those who are unaware, Jōyō Kanji represent the kanji in common usage in Japan, and this set now includes 2,136 kanji. The 2010 revision is significant for several reasons, and I will briefly explore them in this post.
Continue reading…

One benefit of web fonts that many designers may not immediately think of is the potential to serve fonts for languages that website visitors may not have font support for on their local devices. In case you may have missed this information in earlier communications, the web fonts we are serving on Typekit are full analogues of desktop fonts. This means that the web versions of all our fonts have all the same glyphs and all of the OpenType features found in their counterparts. Although there is currently no mechanism for exploring language support on Typekit, I have been assured that this will be forthcoming. In the meantime, I thought it would be worthwhile to review the language support provided by our current set of web fonts.
Continue reading…

A little over one week ago, the Japan NB (National Body) submitted to The Unicode Consortium their first IVD Collection for registration, which is being referred to as PRI 167 (Public Review Issue #167), but its actual name is the “Hanyo-Denshi” (汎用電子) IVD Collection. I was very pleased to see this, because it represents the second such submission.

The first IVD Collection to be successfully registered, of course, was the “Adobe-Japan1″ IVD Collection, which was declared final on December 14, 2007. We have thus far IVS-enabled fifty of our OpenType Japanese fonts based on these registered IVSes. Since then, the two major OSes, specifically Mac OS X (from Version 10.6) and Windows 7, have become IVS-enabled. Adobe Acrobat (from Version 9.0), Adobe Flash Player (from Version 10), and Adobe InDesign (from CS4) were the first products to become IVS-enabled.

My initial examination of PRI 167 found that there are 4,214 glyphs included, 1,924 of which represent standard or default forms. This meant 2,290 variant forms. Of these 2,290 variant forms, I found that 633 could map to Adobe-Japan1-6 CIDs, meaning to “Adobe-Japan1″ IVSes, though 28 could be argued either way due to subtle glyph differences.

I submitted my first round of PRI 167 comments to the submitter on April 8, 2010, which included a mapping table for the 2,557 (1,924 + 633) glyphs that can map between the IVD Collections. I plan to finish a second round of comments by the end of this month.

Because IVD Collection submissions require a ninety-day public review, I encourage others who are qualified to review its contents to do so.

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).

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.

Continue reading…

I’m cross-posting this with the OpenType mailing list to try to get a wider cross-section of views.

As has been mentioned here and elsewhere, in new fonts Adobe is moving away from using Unicode Private Use Area (PUA) encodings for glyphs that are alternates or variants of another glyph that is encoded as the default form for a character. About the only thing we’d use PUA for in new fonts would be ornaments or dingbats that really don’t have their own codepoints.

We’re working on a general tune-up of our whole type library, and one of the questions which arose is, should we make such a change in revising already shipping fonts?

Continue reading…