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.
Continue reading…
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.
Continue reading…
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!)
Continue reading…
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.
Continue reading…
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:
subscribe: opentype-migration-sub@indx.co.uk
unsubscribe: opentype-migration-unsub@indx.co.uk
messages: opentype-migration-list@indx.co.uk
Here’s the text of our posts, with handy links.
Continue reading…
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).
Continue reading…
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.
Continue reading…
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?
Continue reading…
December 23, 2005
With Unicode and OpenType, there are specifications about how certain things should be done: particularly encodings and OpenType layout features. But some things are not as well or easily supported in applications, which leads to the temptation for font developers to “lie” about the encoding or alternate glyphs, in order to get something that works more easily. What specific kinds of lies are font developers tempted by, and is this lying a Good Thing or a Bad Thing?
I’ve been talking about this a lot lately in discussions on the public OpenType list and in the Typophile forums, and I thought I should put all my thoughts in one place.