Office 2013 has undergone a substantial shift to a relatively new display facility, Direct2D, and a new text facility, DirectWrite. These are the display facilities that are used on Windows Phone 8, the new Windows RT slates, and optionally on Windows 7 & 8. Up through Office 2010, the Windows Graphics Device Interface (GDI) and complex script support by Uniscribe were used. RichEdit 8.0 interfaces to both kinds of display technologies, but a given RichEdit instance uses only one of them. This post describes some of the advantages of using the new display facilities along with some of the problems we encountered in supporting them. One of the challenges was ensuring that math display wasn’t broken in the Direct2D/DirectWrite world. Another was to implement higher-level BiDi protocols using DirectWrite, which was designed to support the Unicode Bidi Algorithm (UBA) only.

Direct2D and DirectWrite are modern components that can take advantage of graphics acceleration hardware. DirectWrite supports better text placement using subpixel, device independent layout along with ClearType or other antialiasing methods. So in principle, it’s a big win to move forward to these components. Meanwhile GDI and Uniscribe have been around for years and have been taught to handle all sorts of nonobvious problems. It’s not easy to produce new code with their generality. Furthermore, RichEdit needs to be able to use either DirectWrite Version 1.0, which ships with Windows 7, or the more powerful DirectWrite Version 2.0 that ships with Windows 8. As a result, it was a bit of a tour de force to generalize RichEdit to interface smoothly to these three different display models. The factorization we’ve done has simplified getting RichEdit onto other platforms as well, such as the Android and iOS operating systems.

As an example of GDI tricks, if you specify the charset in creating a font object, GDI will ensure that you get a font that handles that charset. Admittedly charsets cover only a subset of the world’s languages (no Indic, Syriac, etc.), but they do cover many important languages. Another trick is if a character is an end-user-defined character (EUDC) in the Unicode Private Use Area, GDI will ensure that you see a glyph by searching through registered EUDC fonts. These characters are not defined in the Unicode Standard, so you can’t use them reliably for text interchange. But they are popular in CJK locales and a given machine may have fonts with the glyphs that the user wants.

Uniscribe was developed alongside LineServices to support both the UBA and rich-text higher-level protocols. This approach is important for RichEdit rich-text instances, since they use the keyboard and math higher-level BiDi protocols. In addition, digit substitution support requires breaking out numeric runs, which Uniscribe does. DirectWrite creates runs giving the same script value to alphabetic characters and numeric digits that are considered by context to be part of that script. The method we found to identify the digits in an Arabic run given by DirectWrite, for example, is that they are given a BiDi level of 2, whereas the strong RTL characters have a BiDi level of 1. We’ve dreamt up a number of other ways to ensure that Latin letters are rendered LTR (except in plain text with an RLO override embedding). And then you get little problems such as two Thai characters surrounding the Arabic comma U+060C. Since U+060C is considered common to several scripts, DirectWrite happily puts it in the Thai script run. But a Thai font cannot handle it. Font fallback is one way to see a glyph; RichEdit breaks the run and uses an Arabic font.

For the new immersive environment on slates and the Windows Phone 8, not only are GDI and Uniscribe absent, so are the functions handled by the venerable user.dll and OLE dll’s. The user.dll program library includes the OS SendMessage, MessageBox, CreateWindow, etc. In the immersive environment, RichEdit is only available in windowless mode. The client can still send RichEdit messages via the ITextServices::TxSendMessage() method. The advantage of dropping user.dll and the OLE dll’s is the relative simplicity of the model and the correspondingly reduced size. But doing so omits significant functionality, at least in the initial version. At the same time, the touch functionality is dramatically improved on Windows 8 and in the immersive environment.

OneNote 2013 is the first Office application that has a fully immersive version, thanks, in part, to the fact that RichEdit 8.0 can run in a fully immersive environment. OneNote 2013 has the math display facility and you can edit math using alt+= to insert math zones and the linear format to enter equations. One problem with OneNote 2013 is that for some zoom factors, horizontal lines are snapped vertically to the wrong pixel boundary. There wasn’t enough time to fix this problem for OneNote 2013, so you may notice some square roots with misaligned bars.

Another side effect of these huge changes is that we have had no time to improve the Office math editing and display facility for Office 2013. The main accomplishment math-wise is not to lose any math functionality, aside from misaligned bars in OneNote. Hopefully next time we can add some cool math features.