October 8, 2013
It all started late in 2009. The Adobe Type Team pointed to the fact that Unicode was moving towards standardizing emoji (emoticons common among Japanese mobile providers). They asked: How can we get this into fonts?
In the words of the inimitable Taro Yamamoto of Adobe Type, Japan, considering “the rather active and colorful nature of emoji,” we could not use Compact Font Format (CFF) or TrueType outlines. We needed a graphics format capable of richer expressiveness.
At the time, Flash was central to Adobe’s vision for mobile, so we planned to add a multimedia table to OpenType that could represent colored animated glyphs in Flash (SWF) or other media formats. Embedded SWF descriptions would be played within a security sandbox in Flash. We christened the table with the four-character tag ‘MUME’—a contraction for multimedia—and had fun with its pronunciation. Should it be mummy or moo me?
We never decided on that detail, because, since then, instead of moving forward with multiple media options, we converged on a single open standard format in which to define the glyphs: Scalable Vector Graphics (SVG), a part of HTML5. The table tag was simply ‘SVG ’ (note the trailing space). In October 2011, a W3C community group was formed to drive the project. Most of the specification work has taken place within the group, with help from the larger font community, including tool vendors. The work will be formally presented for font standardization in January 2014 at the Moving Picture Experts Group (MPEG) meeting in San Jose, California. Continue reading…
January 23, 2012
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.
May 14, 2010
[I’d like to preface this article by stating that it was written and contributed by our esteemed colleague, Daniel “daan” Strebe, who works in our Seattle office. – KL]
Please welcome Tin, Adobe’s newest open source project. Tin is a C++ source-code library for manipulating fonts based on the SFNT file format, such as TrueType and OpenType.
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).
September 10, 2008
We’re looking for some feedback from the font developer community on how you want the AFDKO/FontLab/FontMaster code syntax to work for mark attachment. Please comment! Comments received by Friday September 29th will be most likely to influence our implementation.
In OpenType fonts, mark attachment is the GPOS (glyph positioning) rule which dynamically positions diacritical marks (accents and the like) relative to base characters or other marks.
The currently available version of Adobe’s Font Development Kit for OpenType (AFDKO) does not support OpenType mark attachment. Hence, other tools based on the AFDKO, such as FontLab or DTL FontMaster, do not support it either. We’re currently implementing such support, which will in turn determine the underlying code used by such third party tools. This also means extending the syntax of the AFDKO language to represent mark attachment. However, mark attachment is complicated, and gets even more so when one makes it contextual. The best way to represent it in the same style as other AFDKO code is not entirely clear. Here’s what we’d like your feedback on.
(Special thanks to Read Roberts, AFDKO engineer, for the remainder of this post!)
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.
January 29, 2008
Adobe and Microsoft just posted a notice on the OpenType mailing list about a draft of version 1.5 of the OpenType spec, and requesting suggestions/proposals for version 1.6.
If you’re interested in the mailing list:
Here’s the text of our posts, with handy links.
June 8, 2007
Very quietly a couple of years ago, with Acrobat 7.05, Adobe shipped Adobe Arabic, an original OpenType typeface commissioned by Adobe with production by Tiro Typeworks, created by type designer Tim Holloway with Fiona Ross and John Hudson. The typeface won recognition from the TDC and has generally been well received.
Tiro recently had inquiries about showing the VOLT source code for Adobe Arabic to a third-party font developer. We’re fine with that, but we thought that to be fair to all developers I should simply post the code here for any interested party. So here you are (73K Zip file).
April 3, 2007
Adobe InDesign® CS3 has a ton of new features, many of which can be seen on its Web site. But there are also many features that aren’t quite big enough to be seen on that august location. I thought I’d mention a few of them that are of particular interest to my fellow font geeks.
May 12, 2006
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?