The Adobe Type Team blog

Posts in Category "OpenType Specification"

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.

One of the things we had kind of left behind in the migration to OpenType was compatibility. More specifically, we renamed all our fonts so that people could use the OpenType versions alongside the old Type 1 versions. Making them deliberately not compatible then freed us to extend kerning, expand the character set a bit, and make other fixes and changes of varying degrees.

But still, people want to know which OpenType fonts match which Type 1 fonts, and what will happen if they take existing documents and replace the old fonts with the new ones (which of course means changing style definitions or using search and replace). Will they get reflow, and how much? First, we did documents about mapping from Type 1 (including multiple master) fonts to OpenType: a short HTML doc for MM to OpenType, and a huge PDF for regular Type 1 to OpenType.

Then, just a couple of weeks ago I finished a long and complicated migration FAQ on compatibility, reflow, and what exactly we changed. I’ve been working on this on and off for months, just as a background task, adding more things as I thought of them. It’s still not perfect – for example, I left out explanations about pi fonts, or at least linking to the pi font readme, which I should have done.

So, I expect I will continue to evolve the migation/compatibility FAQ for a year or two, and I welcome feedback for future revisions. Feel free to post your comments here.

A couple of posts back, I was writing very much from the type designer’s perspective, sharing in their angst over the vast new opportunities (=work) that await them these days with multilingual OpenType fonts with lots of typographic features. But, as my colleague David Lemon pointed out after reading that article, the flip side of this coin is the customers’ point of view and their high expectations.

Our end users are easily confused and occasionally disappointed by OpenType. After all, everybody talks about the wonderful capabilities of the format. But the reality is, none of the fonts that are available has all those capabilities in just a single package, and no application supports all possible OpenType features. In fact, even of Adobe’s own fonts, fewer than half have significant OpenType features. Just because a font is in OpenType format doesn’t mean it has small caps, oldstyle figures or lots of ligatures. And it doesn’t say anything about having any added language support, either. And worse, it’s not like there are just two classes of fonts, “big” and “small,” but there are many possible levels of support, both typographic and linguistic….

I was planning on making my next post about contextual alternates and features in OpenType. Instead, I’m writing today because I’m really tired, and want to say that one complaint I’ve heard from some font developers is largely true.

Some typeface designers have been saying in the last year or two, in posts on Typophile and elsewhere, that there’s one main problem with making fonts that have tons of typographic features and extended language support. It’s a whole bunch more work to make such fonts. They don’t think they can charge enough extra to make it worth the extra work. Plus, they end up spending more time on fewer designs, and the proportion of their type design time that’s spent creatively is going down. But it’s a general trend, and some feel they don’t have much choice but to go along with it.

Note: if you don’t already know about OpenType, read one or more of the following.

So, I’ve been sitting here the last week working hard on my upcoming typeface, Hypatia Sans™ Pro Most of what I’ve been doing is the thrilling, death-defying task of assembling accented characters using composites and mark attachment in FontLab Studio 5. Somewhere along the way, I got a bit worn out, and I am wanting to express my commiseration with my fellow type designers and offer a few thoughts about the challenges we face in this “brave new world”….

This OpenType stuff is often pretty fun. Some of the most fun and the flashiest demos (though not necessarily the most typographical utility) comes from fonts that make heavy use of contextual substitutions or sometimes ligatures that imitate contextual substitutions.

What are contextual substitutions? Basically, a case where what glyphs get substituted depends on what other glyphs are around them. Originally, the primary purpose of this was to do better connecting script fonts. These are typographical flash for English and western languages, but some of the contextual functionality is necessary just to do basic good typography for Arabic, or the Indic languages.

Of course, as is the way with such things, in the past couple of years type designers have taken the technology and put it to uses which its inventors never dreamed of. So, today’s blog entry will look at contextual typefaces, from fancy scripts to improbably weird effects in experimental fonts.

About the Type

Typblography uses Adobe Clean, a typeface designed by Robert Slimbach for Adobe's exclusive use, which is delivered to this blog via Typekit, Adobe's font subscription service.

This blog looks best with ClearType turned on, if using Microsoft Windows. If the text looks jagged or rough, please check your Windows settings to ensure that ClearType is turned on. For more details, see the Typblography09/28/2010 and 10/13/2010 posts on this topic.