Microsoft *does* support OpenType!

by Michael S. Kaplan, published on 2006/06/16 17:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/16/634291.aspx

The other day, Ruben suggested in two comments to an unrelated post that Microsoft does not support OpenType (you can jump to those comments for the exact reasoning behind his opinion).

The bit of the mini-rant from Ruben about Microsoft intentionally attacking Adobe in its lack of support was mildly amusing, since almost at the same time people were reading that post, folks from Adobe in the Bay area were in Redmond talking with folks from MS Typography about various OpenType and related issues. I can assure that if nothing else, there are definitely parts of both Microsoft and Adobe who have no hatred or anger in them about real or unintended slights -- since I work down the hall from several of the MS folks and regularly talk with several of the Adobe ones. :-)

As far as whether Microsoft supports OpenType, considering all of the work that has gone into standardizing it, enhancing it, implementing parts of it for product, and providing a methodlogy for using it on Windows, the notion that we don't support is odd....

The rest of the post made me think about OTLS, which inspired in my mind the following little commercial:

(apologies to the Dodge Caliber marketing folks for having to put up with me modifying their fine commercial!)

It is easy to look at a massive programmatic layer over a complex spec and come to the conclusion that it isn't something cute. But of course that doesn't mean that the features will not eventually be available in easy to use forms in actual applications!

Now the honest truth is that GDI+ was created before some of the exciting extensions to OpenType were even created, let alone before OTLS (OpenType Layout Services) had its advanced linguistic/typographic features integrated into Uniscribe with the following new functions in Vista:

Now much of Ruben's issues stem from the fact that the ability to make use of the many advanced, optional features in OpenType was not added to Uniscribe until Vista (via these new functions). And you can't build the house before the foundation exists.

So clearly, asking GDI+ (whose text rendering support is basically in maintenance mode, as I have discussed previously) to support these things is unrealistic. And even expecting all applications to support new user interfaces to allow/expose these optional and advanced features before they have a chance to create them is unrealistic.

There has to be time, now that the foundation exists, to let people build the house!

Another piece of that rant was about issues with the dual outline formatL TrueType vs. CFF/PostScript, and the support in GDI+, which is genuinely not there since it does require the TrueType tables to do its work, though it does support many of the OpenType tables that are there for various scripts. But this has less to do with one company trying to hurt another than the way the implementation works -- and the limitations it may have.

One can make the same claims in the other direction and act like many of Adobe's fonts don't support OpenType because of what they are missing -- but that sorta misses the point, which is that applications that use advanced typographic features will support the ones that they need to support and ignore the rest. And if they do not find the features they need, they may not work properly.

Avalon is indeed the first piece of technology that has this functionality built in at a non-API function level, but isn't that how technology always works? Something has to be first!

Now there are some exciting advancements here in the platform for OTLS. And there are some very exciting features in Avalon (a.k.a. WPF, a.k.a. Windows Presentation Foundation), which I will be talking about soon.

So hang in there Ruben, there is still time to be excited about what is coming....

Michael, as you know I'm always ready to point out to my font developer colleagues Microsoft's excellent support for OpenType Layout in the context of complex script shaping e.g. in Arabic, Indic, etc. For a long time now, Adobe and Microsoft have been converging on broad OTL support: Adobe beginning with rich typography for European and Japanese scripts and moving toward support for complex script shaping*, and Microsoft beginning with complex script support and moving toward the rich typography support now glimmering on the WPF horizon.

But let's face it, there is a huge gaping hole in this picture of gradual convergence, and that is Office. I look forward to the fruits of WPF, but the fact is that 'Microsoft support for OTL typography' for most people means support in Office applications, particularly support in Word. Now here is Office 2007 and yet again the Office team have failed to show any sign of even being interested in quality typography. I'm afraid until Office show join the party, you are going to continue to suffer complaints like Ruben's, and no amount of reasoned discourse about how well Microsoft is supporting OpenType in other areas is going to put an end to them.

* The first implementation for which, outside of the specialised Middle East versions of Adobe Creative Suite apps, was Arabic, Hebrew and Thai support in Acrobat 7.0.5, for which my company provided the OT fonts.

I can understand you're trying to counter my rant, but to me it actually feels like you're saying I'm right all along. :-)

The OpenType standard (specs, whatever) was there with Windows 2000. We're living in what year now? Low level API functions do not cut it anymore. But, that can be a matter of discussion.

And GDI+ being put in maintenance mode, and being *designed* not to support anything but TrueType? (Yeah, I know, I'm rephrasing your words.) Well...

We had the following font outline formats supported by GDI when GDI+ was released: TrueType, OpenType and Type 1. GDI had mixed rendering support right there. Even in the Win3.x era (albeit kludgy, I know), no 'one outline to rule them all'. But someone chose explicitly not to allow such diversity for GDI+. I think this IS fair criticism. VERY fair citicism.

And without mixed rendering support, no OpenType support. There cannot be any discussion here, just check the specs. CFF outline support is NOT optional.

And yes, GDI+ has been in maintenance mode. For the last 5 years now. I know! It's been in maintenance mode since it was released. The folks programming with it for e.g. WinForms are painfully aware of this.

So, what about Office and the RichEdit (didn't even think of that beast yet)? Nope, some complex script support, sure, but that's it.

With GDI+, .NET/WinForms, RichEdit, Office, all those additional API's are not available. Period. Which equals NO support for these 'platforms'.

And let's face it: even complex script support is incredibly fragmented and patchy: GDI, GDI+, Win32 input controls, RichEdit, Office (general), Word (in particular), .NET/WinForms, Internet Explorer. They're all sufficiently different as far as their support is concerned. Which really tells something about those API's you're talking about.

And all that sweet talk about ironing out the specs, and there being a first for everything is a cop out. Come on!

That's what I was talking about. And it still stands like a house (like they say where I'm from). There were holes in my rant, and I know it. Instead, you're only providing support to my rant.

You haven't convinced me one bit, sorry :-)

But as it stands, let's lay this discussion to rest. Maybe next year, when WPF is out, things will look a lot brighter.

Well, letting it rest is fine, except for a few false statements, which I'll cover here.

1) GDI+ makes use of several tables that are defined in OpenType, not TrueType -- which makes even your initial argument false to fact.

Did they go as far as I would have liked? No.

But I actually was so worried about the GDI+ situation a few years back that I sent mail to a senior VP about my concerns. And I have posted here about the language limitations in GDI+ for some time as well.

2) As for CFF, it *is* supported. But GDI+ needs more that just CFF outlines -- if that is all a font has then that font has bubkes. There are plenty of tools from other vendors that pay no attention to specific features, so this is hardly unique to Microsoft.

My advice -- best tack should be to use the tools that make the best use of the features of the OpenType spec that you are interested in, and not assume that all of them need to support all of the features. Since that is unlikely to ever happen....

3) WinForms, RichEdit, and Office are not platforms. Not by any means. It is a failure of these applications and components that they do not fully support these features. YES. But calling something what it is will speed up the time in which it can be addressed, since it makes the request more accurate. :-)

Will other appliactions and components pick up the support of mathematics that RichEdit 6.0 has? Probably not. Does that mean they are all broken? NO, they are not broken.

4) Nothing in what I posted was a cop-out, although I can see how any time someone who expects something to work that they will consider any attemot to explain why what they want may not be possible (yet or ever) is a cop-out.

I'd suggest that you look to WPF for an example of an implementastion that supports advanced typographic features, and provide feedback on THAT to the appropriate places. Because the best way to see features in MS products is to say what is good and bad about that feature in other MS products, so everyone has a chance to improve!

(OK, I'll bite.)

What first argument are you referring to that's false to fact? I'm not saying anything in the first few paragraphs about GDI+ not supporting OpenType layout tables. I'm talking about the OpenType outline variant. So okay, maybe I should have said TT/OpenType. OUTLINES, not layout tables. That's the whole point. OUTLINES. I'll come back to that. As far as I'm concerned, GDI+ is perfectly adequate as far as its support for OpenType layout tables is concerned. (Adequate, mind you.)

Besides, old fashioned TrueType fonts don't support most OpenType layout tables either. Like, say, the Symbol or Wingdings fonts. But they can still be rendered by GDI+. So that's not it.

GDI+ can't *RENDER* CFF/OpenType fonts.

Simplistically put, for those not in the know about TT vs. CFF OpenType fonts:

TrueType outlines = quadratic splines + hinting programs, invented by Apple once, lated adopted and evangelized by MS;

CFF outlines = cubic splines + declarative hints, invented by Adobe, derrived from Type 1 outlines, also by Adobe.

(Adding a second outline format to the TrueType file format made Adobe's life soooo much easier with their FontFolio product, containing thousands of Type 1 fonts. Which could simply be converted, without quality loss, into the brand new OpenType format.)

Both renderers are quite complex (mildly put) and have nothing in common. That's the reason why MS licenced the Type 1/CFF renderer from Adobe for GDI. Just like Apple did for OSX. (And if you look at the quality of GhostScript font rendering, you'll see why: it's very hard to implement right. It took Adobe many years to get to the current quality.)

So, you see, I know perfectly well why GDI+ doesn't support CFF/OpenType. (It doesn't, you hear.) And it never will. Ever. Just like WinForms and System.Drawing never will. It's not worth it, financially speaking. And last time I checked, MS was still a commercial company. (Big understatement there.) And GDI+/System.Drawing has been put in maintenance mode, just like WinForms will be, very soon.

Let's face it: I'm Don Quichotte. (No wonder my country looks full of windmills ;-)

And as far as the OpenType support in WPF: so far there's little to complain about. Honest. Even ClearType rendering for CFF fonts (unlike GDI). Yay! Horizontal + vertical anti-aliasing and probably the best renderer for TT *and* CFF out there yet. Swoon! Typographic layout tables support. Yay! Up-to-date complex script support. What more could one want from an OpenType savvy rendering system? Well, like: now? Gimme gimme :-)

(Well... Just in case anyone else is tuning in. This post is being linked from MS' own typography site after all. So, a font dialog that doesn't filter out the CFF/OpenType fonts, like the System.Windows.Forms font dialog you're supposed to use. An MS provided OpenType-oriented font dialog would not only be great for developers and UI consistency, but also great advertisement for WPF's OpenType support. v2 right? Oh, and Type 1 support too. Type 1 fonts are a technical horror, true. But there's too many of them. And it must be cheaper for MS/Adobe to implement support in WPF than for ten customers to upgrade their font library from Type 1 to OpenType. Those things are damn expensive you know! vNever, right? Sigh... I know I'm not the only one that's asked for these things, but it never hurts to ask again.)

> They use the other outlines -- and someone else can call any app that only supports the CFF outlines as not supporting OpenType either.

Exactly. There are such programs, believe it or not. (I've had some traumatic experiences with TeX in this area, so I know first hand.)

> Technically they are both wrong in claming that this mean OpenType is not supported.

So if I write an application that only supports plain ASCII, does that mean I can say it supports UTF-8? Of course not. Programs that support only the TrueType part of the OpenType specs only support TrueType + (possibly) some OpenType extensions. But not OpenType itself.

Tomaytoes, Tomahtoes.

Or, like the documentation for System.Drawing.Font says: "Windows Forms applications support TrueType fonts and have limited support for OpenType fonts." Which is probably more to your liking ;-)

> This is something addressed by Adobe tools, so it looks like you are all set for your CFF needs. :-)

Fair enough. But afaik Adobe doesn't provide a public API to support a simple DrawString, only apps. And no tool extends GDI+ like Adobe's Type Manager used to extend GDI on Windows 3.x and 9x. Which means no luck for your WinForms apps. Nor does it help Visio users. So I fail to see the 'addressed' part here.

But at least we can finally agree that GDI+ definitively doesn't support CFF flavoured OpenType fonts.

OK. I'm done here. I think we've both gotten our points across by now. :-) Please don't let me hold you up on the serious blog posts. It might not have looked like it, but you've got a fan here.