Short-sighted text processing #6: OpenType and Apple and OpenType

by Michael S. Kaplan, published on 2011/01/06 06:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/01/06/10111881.aspx


Previous blogs in this series:

Now the other day in Part #4, I really went into a bunch of detail about text support in MacOffice 2011.

I made a couple of random points about Apple as well, though not too much.

But there are some things about Apple that I would like to cover that didn't really fit well into that blog. So I am going to cover them in this blog, today.

Now in that post and also in prior posts, there are two interesting facts that I had mentioned:

At first glance, these two points seem kind of contradictory, don't they?

I mean, Apple is obviously quite used to be considered "cooler" than its competitors, so it would hardly be a surprise to them if the developers (in this case the font developers) like their platform better. After all, they like theirs better too!

So why would Apple move to start using OpenType?

The answer can be found in a bit of the text in Wikipedia's description of OpenType, in the "Comparison to other formats" section, here (bold emphasis mine):

Compared with Apple Computer’s "GX Typography"—now called Apple Advanced Typography (AAT)—and with the SIL’s Graphite technology, OpenType is less flexible in typographic options, but superior in language-related options and support.

OpenType has been much more successful than AAT and Graphite. There are many more fonts and supporting applications, despite AAT being an older technology. The single-platform nature of AAT and the lack of support from any major software vendor other than Apple itself are both likely factors in this. The free software Graphite technology is not endorsed by major software vendors.

From a font developer’s perspective, OpenType is, for many common situations, easier to develop for than AAT or Graphite. First, the simple declarative substitutions and positioning of OpenType are more readily understood than AAT’s more complex state tables or the Graphite description language that resembles C syntax. Second, Adobe’s strategy of licensing at no charge the source code developed for its own font development, AFDKO (Adobe Font Development Kit for OpenType), allowed third-party font editing applications such as FontLab and FontMaster to add support with relative ease. Although Adobe’s text-driven coding support is not as visual as Microsoft’s separate tool, VOLT (Visual OpenType Layout Tool), the integration with the tools being used to make the fonts has been well received.

Another difference is that an OpenType support framework (such as Microsoft’s Uniscribe) needs to provide a fair bit of knowledge about special language processing issues to handle (for example: Arabic). With AAT or Graphite, the font developer has to encapsulate all that expertise in the font. This means that AAT and Graphite can handle any arbitrary language, but that it requires more work and expertise from the font developers. On the other hand, OpenType fonts are easier to make, but can only support complex text layout if the application or operating system knows how to handle them.

Prior to supporting OpenType, Adobe promoted multiple master fonts and expert fonts for high-end typography. Multiple master fonts lacked the controls for alternate glyphs and languages provided by OpenType, but provided smooth transitions between styles within a type family. Expert fonts were intended as supplementary fonts, such that all the special characters that had no place in the Adobe Standard Encoding character set – ligatures, fractions, small capitals, etc. – were placed in the expert font instead. Usage in applications was tricky, with, for example, typing a Z causing the ffl ligature to be generated. In modern OpenType fonts all these glyphs are encoded with their Unicode indices and selection method (i.e. under what circumstances that glyph should be used).

So now we are in a middle stage, where AAT is still on OS X but OpenType is coming along.

The support within Microsoft's Mac Office >= 2011, with its Uniscribe.framework component, may not be tied to how fast OS X and its support comes along, which could lead to lots of interesting situations when crossing the vendor barrier with text. But I think that in the long run this will be okay no master what small discrete bugs may pop up as support by both Apple and Microsoft moves forward in the fits and starts of new versions.

I really do like things moving more to OpenType, though I think in the long run the ability of font vendors to be able to override behavior when they are going beyond the writing systems that the "OpenType support provider" will become more and more important.

Now I think having some formal means in OpenType to specify an unknown writing system within a known script that vendors support may be the most important way that OpenType can be magnanimous in victory and work to support the scenarios that cause AAT and Graphite to sometimes be more desirable. And really all we are talking about is the ability of a font to opt-out of some or all functionality that components like Uniscribe provide.

And although I know such feedback is regularly given by people, in my opinion there needs to be more pressure to make sure this get done. Bottom line? Microsoft needs smart people like Andrew West to not have to post blogs like Prototyping Tangut IMEs, or Why Windows 7 Sucks, and more blogs in this series need to have their issues fixed in a formal way that makes sure OpenType can be #1 in supporting not only what it supports, but in what it does not support....


no comments

go to newer or older post, or back to index or month or day