We’d like to thank everyone who tested the Adobe CFF Engine and reported issues during the beta period. The code was released as a “mature” beta but testers did find a few issues and an improved version of the rasterizer is now being delivered to all devices that use the latest version on FreeType (version 2.5.0.1).

So what does this mean? As discussed in our initial blog article, the inclusion of the Adobe CFF engine in FreeType improves font rasterization for CFF fonts in environments that use FreeType. Since FreeType is used by more than a billion devices, including Android and Chrome OS, both Adobe and Google see the contribution as one that will improve the CFF font experience for lots and lots of users. The experience with CFF fonts will match the one users have enjoyed for many years on Windows and OS X.

We could talk again about the rasterizer’s technical improvements, but a picture is worth… (well you know the saying!). The following image was shown in our initial announcement, and we think it does a great job illustrating the improvements made by the Adobe rasterizer.

As you can see, the Adobe CFF Engine in FreeType consistently produces smoother and more readable text. And now that it has been accepted by FreeType, and is on by default, we are one step closer to achieving great quality rasterization for CFF fonts on devices that use FreeType.  We expect  this new feature to be picked up by products in the coming months and we will keep you in the loop as adoption increases. Stay tuned!

To read Google’s blog post please visit http://google-opensource.blogspot.com/2013/06/youve-got-cff.html.

Modern fonts use one of two outline formats – TrueType or CFF. TrueType was developed by Apple in 1990, while CFF (the Compact Font Format) was developed by Adobe as a second-generation form of the Type 1 format (often called PostScript fonts) that Adobe first released in 1984. Either TrueType or CFF can be used in OpenType fonts. The two share many qualities, but differ in two primary ways: they use different math to describe the curves in letterforms, and they have different styles of “hinting.” (Hinting = providing guidance to the rasterizer to ensure each letterform is represented as faithful as possible in a limited set of pixels.) TrueType puts most of the emphasis on instructions built into the font, while Type 1 and CFF rely more on intelligence in the rasterizer. This makes the quality of the rasterizer particularly important, and Adobe expects its contribution to FreeType will produce a noticeable improvement for CFF fonts in environments that use FreeType.

FreeType, an open source library for font rendering, is used either partially or exclusively by Android, Chrome OS, iOS, GNU/Linux and other free Unix operating system derivatives such as FreeBSD and NetBSD. This makes FreeType the font rendering software of choice for more than a billion devices. As a user of FreeType in their products, Google was looking to get the same high-quality text rendering for CFF fonts that their users currently enjoy with TrueType fonts. Google approached Adobe about getting Adobe’s rasterizer technology into FreeType and has been a key financial supporter of this project ever since. And because Google is such a strong supporter of open-sourced technology, all users of FreeType, as well as FreeType developers, will benefit from this contribution.

As a long time developer of fonts and font rendering technology, Adobe saw this contribution to FreeType as an opportunity to make CFF fonts look great on a multitude of devices. Similar to Adobe’s collaboration with Apple and Microsoft 12 years ago to get native support for Type 1 and CFF fonts into the desktop OSes, and more recent collaboration with Microsoft to get the CFF rasterizer into WPF and DirectWrite, contributing the Adobe CFF Engine to FreeType will dramatically improve the CFF font experience for a large number of users. Users of devices that incorporate the new version of FreeType will have the same font rendering experience for CFF fonts that they have enjoyed for many years on Windows and OS X.

The examples below illustrate some of the differences users will see on devices that use FreeType with the Adobe CFF Engine. Samples on the left are CFF fonts rendered with the native FreeType hinter, those in the middle are rendered with FreeType’s light-auto hinter and the ones on the right are using FreeType with the Adobe CFF Engine. Clicking on these images will display a higher (1:1) resolution image.

The above examples illustrate the cumulative effect many small improvements can make when it comes to font rendering. Adobe CFF Engine features, such as adding an extra pixel in height to help separate stems in many glyphs, and increasing stem widths to enhance contrast without creating blobs and — when there are not enough pixels — leaving selected stems unhinted, improves the readability of CFF fonts.

Although CFF fonts have been widely popular on the desktop over the last decade, the Web and mobile devices almost exclusively use TrueType. This reflects the legacy of low-resolution monochrome displays, an area where “superhinted” TrueType fonts could produce better results.

With the addition of high-quality CFF font support, developers will have a much richer set of fonts from which to choose. Not only is CFF the world’s most popular font format, it is a great format for the Web and mobile, as Miguel Sousa discussed in an earlier blog post. Two of its most significant benefits are smaller file size than TrueType and a flexible and powerful method of hinting which ensures excellent rendering across a wide range of environments and devices. As Miguel points out, it’s easy to see why smaller font files are desirable for the web and for resource-limited devices.

If you are interested in testing the Adobe rasterizer code in FreeType, visit www.freetype.org. The code is beta and off by default, so you have to explicitly select it using the new hinting-engine property of the CFF driver. Additional instructions are available in the FreeType ‘CHANGES‘ file. If you are looking for a set of CFF fonts with which to test, we recommend that you download one of Adobe’s free, open-source typefaces, Source Sans or Source Code, available from the Open@Adobe portal on SourceForge.

For additional information from Google please visit http://google-opensource.blogspot.com/2013/05/got-cff.html.

The version that was initially released was approximately 80K in size, and included 257 glyphs, 256 of which were functional in the sense that they are mapped from 1,111,998 Unicode code points, though they are intentionally non-spacing and non-marking. I further analyzed the tables, and found a way to trim the size further by increasing the number of glyphs to 2,049, 2,048 of which are functional. The size is now a more modest 32K.

The table that was included in the original article is repeated below, with the data for the 2,049-glyph font added in:

Interestingly, the largest table is now the ‘name‘ table, which is 10,066 bytes. This is primarily due to the inclusion of its full open source license as its name.ID=13 (License Description) string.

In closing, I am also thinking to jettison its vertical tables, meaning ‘VORG‘, ‘vhea‘, and ‘vmtx‘, which will reduce the size a further 4K or so, but I’ll leave that for another day.

P.S. As of earlier this afternoon, the Adobe Blank sources are now available on GitHub.

With the typophile in mind, and others who are interested in font design, we produced our latest set of type specimens. These specimens, now available as PDFs on www.adobe.com/type, delve into the design of four recent Adobe Original typefaces – Trajan Sans, Trajan Pro 3, Myriad Arabic and Myriad Hebrew. We hope you enjoy reading this material and learning more about these typefaces.

• All Unicode code points are covered.
• All code points are rendered using a non-spacing and non-marking glyph.

I decided to take on this task, because I immediately recognized that the special-purpose Adobe-Identity-0 ROS was the appropriate vehicle for developing such a font.

The font itself was developed early this year, and I finally got around to releasing it on Open@Adobe as a new open-source project named Adobe Blank OpenType Font. I will soon mirror it on GitHub for those who prefer to get their open-source material from there.

So, what in the world is such a font good for? According to the developer who made the request, Joel Brandt, it serves the following two purposes:

• Invoking this font, as a temporary measure, prevents OS- or application-level font-fallback from kicking in before the intended font can be rendered.
• Related to the above, using the font allows one to detect when a web font is actually loaded, which is arguably a hack to overcome a limitation in CSS.

About the second purpose, the actual usage is as follows:

1. Include Adobe Blank as a data URI in the CSS file.
2. Specify ‘font-family: SomeWebFont, “Adobe Blank” in the CSS rule for some DOM element that contains text (and would therefore have a non-zero width when rendered using a regular font). One example would be a <span> element that is absolutely positioned offscreen.
3. Check the width of the DOM element. If it’s zero, SomeWebFont hasn’t loaded yet. If it’s greater than zero, it has.

An example real-world use case for Adobe Blank is the Adobe Edge Web Fonts extension for Brackets, which is available on GitHub.

In terms of implementation details, I tried the following three approaches, in terms of the number of actual glyphs in the font resource:

• 2 glyphs: The mandatory “.notdef” glyph at GID+0 plus a single functional (though non-spacing and non-marking) glyph at GID+1.
• 257 glyphs: The mandatory “.notdef” glyph at GID+0 plus 256 functional (though non-spacing and non-marking) glyphs from GIDs 1 through 256.
• 65,535 glyphs: The mandatory “.notdef” glyph at GID+0 plus 65,534 functional (though non-spacing and non-marking) glyphs from GIDs 1 through 65534.

For those who are curious, the non-spacing and non-marking glyph description is as follows:

0 width endchar

The other aspect of the implementation details is about mapping all Unicode code points to these glyphs. 1,111,998 Unicode code points are covered. Note that the 2,048 High and Low Surrogates (U+D800 through U+DFFF), the two noncharacters in the BMP and in each of the 16 Supplementary Planes (FFFE and FFFF), and the 32 noncharacters in the range U+FDD0 through U+FDEF are explicitly and intentionally excluded. This involved creating a UTF-32 CMap resource with 1,111,998 mappings.

What I found is that the version that includes 257 glyphs provided the best efficiency, in terms of the number of glyphs and the number of mapping ranges in the ‘cmap‘ table, and that is what was released. Interestingly, the two-glyph version could not be built. I even tried ttx, but apparently 1,111,998 single mappings are too many. The table below shows the sizes, in bytes, of the ‘CFF‘, ‘cmap‘, ‘hmtx‘, and ‘vmtx‘ tables of all three versions:

It should be obvious from the data in the table above why the 257-glyph version was chosen to be released. Of course, this font was built using only AFDKO tools.

In closing, I’d be interested to hear from other developers whether they can think of other use cases for Adobe Blank…

…beyond anecdotally suggesting that government and other bureaucratic agencies use it for rendering and printing their documents. ☺

A few weeks back my co-worker Miguel Sousa blogged about the fundraising adventure our team embarked on to help raise money for the Hamilton Wood Type Museum. Now that we have all of the donations tallied and matching requests submitted, I am happy to announce that our crazy idea of selling cupcakes in-a-jar for Valentine’s Day raised $7,500 for the Hamilton Museum. As lovers of type, and supporters of the Hamilton Museum, we couldn’t be happier with how this fundraiser turned out.

As you can see from the following video footage, we all got our hands—and kitchens—dirty as we baked cupcakes and mastered the art of frosting cupcakes in a jar.

Luckily, all that work paid off during the Valentine’s Day sale. Adobe employees at the San Jose and San Francisco campuses purchased more than 360 cupcake jars. When they picked up their jars, they got another surprising treat: we had tables set up with genuine samples of wood type for them to touch and caress, along with beautiful posters from the Hamilton Museum for them to look at. As shown in the following footage, everyone had a “sweet” time.

A lot of people were behind this fundraising effort and helped to make it a success. I would first like to thank all of my team members who baked several dozen cupcakes for the fundraiser and assembled the cupcake jars. I would also like to thank all the Adobe employees who purchased our cupcake jars, and in many cases donated extra funds to this very worthwhile cause. And, I would like to give a special thanks to Miguel Sousa for creating an amazing set of promotional material for the event.

And, I can’t stop there. Even though Miguel mentioned these folks in his blog, I’d like to again acknowledge Matthew Kelsey, John Sullivan of Logos Graphics, Jamie Saunders of Neenah Paper and Tiffany Wardle. Without them we could not have created such amazing displays for our cupcake jars. And, I’d like to give my husband, Wellington Minoza, a special thank you for capturing these efforts on video and putting together these videos.

I hope you enjoyed reading this post and seeing the footage. And, I hope you will all consider donating to the Hamilton Museum. Their move is scheduled for the end of March, and they are still working hard to meet their goal of raising $250,000.

As you may have heard, the Hamilton Wood Type & Printing Museum has been asked to vacate its current site, and so is seeking for donations to help pay for the move and purchasing a new facility. The museum is located in Two Rivers, Wisconsin, and houses the world’s largest collection of wood type, estimated to be over 1.5 million pieces. The building that bears its name is the place where the long extinct Hamilton Wood Type company began producing type in 1880 and within 20 years became the largest provider in the United States.

As lovers of type, our team couldn’t pass on the opportunity of contributing to this effort and to help save an important piece of Americana. We discussed a few fundraising ideas and the winning one was… cupcakes in-a-jar! That’s right, we loved Nicole Minoza’s proposal of putting the whole team’s baking skills to the test. The concept was fun, bold, timely (upcoming Valentine’s Day), and would surely entice a broad range of people.

There was a lot of work ahead of us, so we set goals for ourselves and started working on it right away. Nicole was in charge of all the logistics, from acquiring the baking supplies to booking the advertising spots, and I became responsible for designing the promotional materials. We knew our campaign had to be extraordinary in order to grab people’s attention.

To make sure everyone understood the product and the purpose behind it, we decided to have one jar on display in each break room (around 40 in San Jose and San Francisco), with a paper stand that would carry our message. And we couldn’t be happier with how things have gone. When we deployed the campaign last week, people’s reaction was phenomenal. In just a couple of days we reached half of our goal, and we’re on track to sellout today.

Kudos to Caleb Belohlavek and his wife Sandy, for baking and assembling the sample batch of cupcakes. They were so successful that a handful of jars didn’t make it to the end of the week. I truly sympathize with the Adobe colleagues who did such a feat, because I must confess that I couldn’t resist the temptation either. The yummy-looking jar I had was truly tasty!

And a special Thank You to the people outside our team that helped us put this effort together. To Matthew Kelsey for donating the letterpress printing of the stands for the break rooms. To John Sullivan of Logos Graphics for donating the photopolymer plate. To Jamie Saunders of Neenah Paper for donating the paper (CLASSIC CREST® Cover, SAWGRASS 80C, Smooth Finish). And to my wife, Tiffany Wardle, for leveraging her social cloud and connecting our team to these generous individuals.

Stay tuned because next week we’ll have more news and some footage of the team in action. Meanwhile, please consider donating to the Hamilton museum.

Ying Ning

Tonny Xu

Vincent Ding

Hai Liang

Takesato Hayashi

Without them, and all of the other individuals we mentioned in December, this program would not be a success.

To learn more about the Adobe Type Community Translation program, refer to Typblography project page. If you have any questions or requests related to the Type Community Translation program feel free to reach out to us at type-translations@adobe.com.

This year, Mr. Hunt will also be hosting a three-day type development workshop directly after the conference in Guwahati from 11–13 March, 2013. The workshop location is currently slated for Guwahati, however if there is not enough interest at this location or if there is more interest for a workshop in Delhi, the location is subject to change. Therefore applications are now being considered for both Guwahati and Delhi and the final workshop location will be decided by popular response. This workshop is targeted at helping to foster local type designers and engineers within Indian subcontinental region and will thus be limited to persons residing in this area.

The workshop is intended to be an in-depth review of the font development process to assist typeface designers in taking their design and font development skills to the next level. Whether you are a novice who wants to turn letter drawings into type, or you have had some experience designing and developing fonts, this workshop will present a range of topics that will help you to improve the technical quality of your font output. During this workshop series Mr. Hunt will demonstrate general type design principles using FontLab Studio 5 and the Adobe Font Development Kit for OpenType (AFDKO), however these principles will also be applicable to other type design environments.

The workshop size will be kept to 15 participants so that sufficient attention can be given to each attendee. There will be no registration costs associated with the workshops, however applicants will be selected based on relevant prior experience and demonstrated aptitude. Attendees will benefit most if they are able to bring their own laptop. No additional supplies will be provided.

Following is a tentative schedule:

• Mon 11: Introduction to general typeface design concepts
• Tue 12: Advanced font development concepts
• Wed 13: Font production with the Adobe Font Development Kit for OpenType

For more details, please contact Mr. Hunt directly: phunt(at)adobe.com.
To apply for the workshop, please do so using the online form.
Accepted applicants will be notified by 15 February 2013.

(Updated 4 Feb 2013 to update information on potential locations)

This year’s holiday card was set entirely in Source Code Pro, designed by Paul D. Hunt, making use of its monospaced nature. Design and layout was done by Frank Grießhammer, who is a big fan of Unicode’s Box Drawing characters (U+2500 – U+259F).

Happy Holidays, and the best wishes for 2013 from the whole Adobe Type team:

Caleb Belohlavek
Frank Grießhammer
Gu Hua
Masataka Hattori
Paul D. Hunt
David Lemon
Ken Lunde
Ernest March
Nicole Minoza
Ryoko Nishizuka
Read Roberts
Steve Ross
Robert Slimbach
Christopher Slye
Miguel Sousa
Taro Yamamoto