Murray Sargent: Math in Office : RichEdit

RichEdit versions

MurrayS — Sat, 14 Oct 2006 03:48:00 GMT

Recurring questions are what RichEdit's are available, where they are installed and what features they have. A relatively new question is which RichEdit's support the new Office math editing and display. So this post attempts to answer these questions. To answer the last question first, only RichEdit 6.0 has the Office math facility, although RichEdit 5.0 has a preliminary math capability that was good enough to get people intrigued with doing something well.

Before answering the other question, here's a quick summary of what RichEdit is in case you haven't heard of it: RichEdit 6.0 is a facility for getting plain/rich-text, single/multiline Unicode/ANSI edit controls and combo/list boxes in single world-wide binary that runs on all Windows operating systems. It has multilevel undo, message & com interfaces, considerable Word compatibility, richly formatted text, outline view, zoom, support for the latest IMEs, speech and handwriting input, rich complex script support (e.g., BiDi, Indic, and Thai), pagination, multilevel tables, autocorrect, hyphenation, kerning, ClearType support, autoURL detection, East Asian features such as vertical text, text wrap around embedded objects, font binding, and support for Unicode surrogate pairs and most Unicode 4.0 scripts. To some degree all RichEdit versions since 3.0 have had these features; although the support for them has improved greatly from version to version (Indic support was first available in 4.0). The rich-ink support was added in 5.0 (4.1 is used in the Ink Edit control that ships with the Tablet PC).

This post continues with a summary table, followed by a list of new features for each version. For the most part, each version has all the features of versions with lower version numbers. One exception is that the Japanese version of RichEdit 1.0 had vertical text display, which wasn't supported by later versions until RichEdit 4.0. Another is that RichEdit 1.0 was also pen-enabled and understood gestures for use with Pen Windows, while only the RichEdit 4.1 ink control and later versions have rich ink support.

Version	Ships ('ed) with	dll name
1.0	Windows 95/98/ME/NT	riched32.dll
1.0	Exchange 4.0 for Windows 3.1/WFW	richedit.dll
2.0	Office 97, Windows NT/98	riched20.dll
2.1	BiDi Office 97	riched20.dll
2.5	Windows CE, Pocket Word	riched20.dll
3.0	Office 2000, Windows ME/2000/XP	riched20.dll
1.0 emulator	Office 2000, Windows 2000/XP/Vista	riched32.dll
3.1	Windows Server 2003, Vista	riched20.dll
3.5	Windows CE, eBooks	ebriched.dll
4.0	Office XP	riched20.dll
4.1	Windows XP SP1, Tablet, Vista	msftedit.dll
5.0	Office 2003	riched20.dll
5.1	Windows CE, Pocket Word	riched20.dll
6.0	Office 2007, Encarta Math Calculator	riched20.dll

If you want to use the Office 2007 RichEdit 6.0, you'll find it in the private subdirectory \Program Files\Common Files\Microsoft Shared\OFFICE12. Similarly the Encarta Math Calculator is stored in a private Encarta subdirectory. The OS versions are located in \Windows\system32. Maybe someday Windows will have the good fortune to have a more recent RichEdit than 4.1J But then we'd have to document all the new features L (Wouldn't be that hard…)

RichEdit 1.0 Features

Basic nonUnicode editing, cut/copy/paste, file streaming
Basic set of character/paragraph formatting properties
Message-based interface plus OLE interfaces: IRichEditOle and IRichEditOleCallback
Vertical text and IME support (FE builds only).
WYSIWYG editing using printer metrics
Different builds for different scripts
Common-control notifications plus some new ones
Plain text and RTF files
Pen-enabled and understood gestures for use with Pen Windows

RichEdit 2.0 Additions

Unicode internally + able to read/write using codepages
International line breaking algorithm
Find Up/Down. Magellan mouse support.
Multilevel undo
BiDi (RE 2.1) and FE support including level 2/3 IME, dual font, keyboard linking, smart font apply
AutoURL recognition. Word UI
Plain/rich, single-line/multiline, scalable architecture
Password and accelerator control options
Windowless interfaces (ITextHost/ITextServices)
Better display (mixed fonts use off-screen bitmap), system selection colors, transparency support
TOM (Text Object Model) dual interfaces
Character formatting additions include background color, locale ID, underline type, superscript/subscript.
Paragraph formatting additions include space before/after, line spacing.
Roundtrip all Word Format Font/Para dialog properties
Extensive code stabilization, testing, performance increase

RichEdit 2.5 Additions

First Windows CE version. Used by Pocket Word
Outline view, normal and heading styles
RTF additions
Minor UI improvements
Western languages only

RichEdit 3.0 Additions

Used for emulating RichEdit 1.0's
Zoom
Italics caret/cursor. URL hand cursor
Paragraph numbering (alpha, numeric, Roman)
Simple tables (no wrap in cells)
More underline types, underline coloring, hidden text
More of Word's default hot keys, e.g., accent dead keys, outline view, numbering
Smart quotes (English only), soft hyphens
Use Office's LineServices component to break/display lines. Used for complex scripts and options like center, right, decimal tabs, fully justified text
Complex script support for BiDi, Indic, and Thai with help from LineServices and Uniscribe components
Font Binding based on charset, which acts as writing system ID
Codepage-specific stream in/out
UTF-8 RTF. Used preferentially for cut/copy/paste. Can be streamed in/out.
Office 9 IME support (MSIME98) including Reconversion, Document feed, Mouse Operation, and Caret position features
AIMM component IME support for nonFE systems.
Increased freeze and undo/redo control
Font increment/decrement function
System edit control, list box, and combo box controls
Alt+x input method
Used to emulate RichEdit 1.0's

RichEdit 3.5 Additions

Second Windows CE release. Used by eBooks
Screen-size pagination
Text wrap around objects flushed left/right
Custom ClearType support
Enhanced East Asian typography

RichEdit 4.0 Additions

Multilevel tables
Autocorrect
Improved autoURL detection
Friendly name hyperlinks
Font binding according to writing system (generalization of charset)
Indic support
Vertical text
Support for the latest IMEs
Speech and handwriting input (Windows Text Services Framework)
More standard hot keys
Many security fixes (3.0 has also)

RichEdit 5.0 Additions

Multiselection, smart drag&drop
Better nested tables, horizontally merged cells
Better font binding/international support
More underline styles, small cap & shadow emulation
Binary file format: "parsed XML"
Partial XHTML reader/writer
Subpixel ClearType support
Better RTF handling, e.g., multilevel lists
URL tooltips
Many bug/minor-request fixes
Improved ink support, especially for OneNote
Advanced East Asian typography
Initial PTS integration, including object tight wrap
Infrastructure for math, ruby, warichu, tatenakayoko
Text trackers and blobs

RichEdit 5.1

Third Windows CE release. Used by Pocket Word
Various UI and RTF enhancements

RichEdit 6.0 Additions

High-quality editing & display of math
Formula autobuildup
Create and support math linear format
More list numbering options
Simple "visi" mode
URL improvements
Multistory: high-perf cut/copy/paste, rich scratchpads, WP infrastructure
Text Object Model 2
Display enhancements, e.g., word underline, horizontal scaling
Table UI adds, e.g., column resizing
OfficeArt/PowerPoint enhancements
Overlapping lines, drop caps & other ePeriodicals improvements
Device independent layout
Virtualized OS: "hDC" is totally opaque
Multiple columns
Myriad security fixes

MathML and Ecma Math (OMML)

MurrayS — Sat, 07 Oct 2006 02:18:00 GMT

Before comparing these two math XMLs, I'm excited to point you at Jennifer Michelstein's nifty post on Equations in Word 2007. It comes complete with instructive videos demonstrating how to enter mathematical expressions using the Equation Ribbon as well as using the linear format discussed in my earlier postings. Jennifer plans to add other posts on this subject to the Microsoft Office Word blog. It's worth pointing out that Outlook 2007 also has Word's math facility since Outlook 2007 uses Word 2007 for editing all email body text.

I'm currently busily connecting RichEdit's math facility to external clients, using three file formats: RTF, MathML, OMML (Office MathML). These are all high-level formats compared to the linear format we use for equation input. Naturally RichEdit has to handle RTF math, since RTF has been RichEdit's main file format since RichEdit 1.0 shipped back in 1993 for the Windows 3.1 mail client. RTF math is essentially just OMML with RTF braces {} instead of XML tags. With it, it's easy to copy technical text to and from Word 2007. RichEdit is used by the Microsoft Math graphing calculator, which ships with the Encarta Student Edition, but the calculator communicates with RichEdit using RichEdit's text object model (TOM) instead of a file format. RichEdit also handles text in OneNote, but the math facility isn't turned on there yet.

Meanwhile it would be great to connect RichEdit with the incredible math engines out there like OpenMaple, Mathematica, etc., and clearly MathML is the lingua franca for that. So I've been developing MathML and OMML writers for RichEdit and Misha (Mikhail Baranovsky) is developing the readers (they're harder!) In the process, we've been comparing these two math XMLs.

Naturally there's been a lot of discussion as to why we even have OMML, since MathML is really good. Brian Jones has addressed that issue in some detail in his Open XML Formats blog. The main problem is that Word needs to allow users to embed arbitrary span-level material (basically anything you can put into a Word paragraph) in math zones and MathML is geared toward allowing only math in math zones. A subsidiary consideration is the desire to have an XML that corresponds closely to the internal format, aiding performance and offering readily achievable robustness. Since both MathML and OMML are XMLs, XSLTs can (and have) been created to convert one into the other. So it seems you can have your cake and eat it too. Thank you XML!

The spirits of MathML and OMML are somewhat different. By MathML, I'm referring to the MathML presentation tag set, rather than the content tag set, since our main emphasis is on presentation. A quick summary of the difference in spirits is

MathML built-up objects may be described by an infix notation, while OMML's are described by a prefix notation
MathML built-up object arguments are defined positionally, while OMML's are tagged explicitly

With MathML when you find an <mrow>, you look at the next tag(s) to see what's inside. If you find an <mo> entry, you have an operator, which you look up in your operator table to figure what kind of a possibly built-up object is involved. It could be an open fence (parentheses, brackets, braces, etc.), an n-ary operator, a function-apply (for trigonometric and other math functions), or one of many operators that don't get built up. For fences MathML also has the <mfenced> tag, which is essentially the same as OMML's delimiter <d> tag.

Each way of representing fences has its advantages, the infix approach allowing embellished fences (such as underlined fences) and the <mfenced> approach allowing a sequence of separated arguments. OMML's <d> can't represent embellished fences, but fortunately for OMML, they aren't common. At least, we couldn't find any in my shelves of physics and math books, but you never know for sure about these mathematicians J. Built-up expressions like subscripts and superscripts are represented by prefix notations in both MathML and OMML.

The following table summarizes the built-up objects in the Office math model along with the OMML and target MathML tags

Built-up Office Math Object	OMML tag	MathMl
Accent	acc	mover/munder
Bar	bar	mover/munder
Box	box	menclose (approx)
BoxedFormula	borderBox	menclose
Delimiters	d	mfenced
EquationArray	eqArr	mtable (with alignment groups)
Fraction	f	mfrac
FunctionApply	func	&FunctionApply; (binary operator)
LeftSubSup	sPre	mmultiscripts (special case of)
LowerLimit	limLow	munder
Matrix	m	mtable
Nary	nary	mrow followed by n-ary mo
Phantom	phant	mphantom and/or mpadded
Radical	rad	msqrt/mroot
GroupChar	groupChr	mover/munder
Subscript	sSub	msub
SubSup	sSubSup	msubsup
Superscript	sSup	msup
UpperLimit	limUpp	mover

OMML tags are always written with a math namespace prefix like "m:" and I recommend this convention for MathML as well. The reason is that these XMLs are useful in many contexts, not just in HTML(5) and using namespace prefixes allows the XML parser to delegate to the appropriate tag-set owner.

Comparing the two ways of representing the built-up fraction, we see how OMML has explicit argument tags, whereas MathML determines arguments by position. The built up version of the fraction a/b in OMML is represented by (aside from possible properties)

<m:oMath xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math">
<m:f>
    <m:num>
      <m:r>
        <m:t>a</m:t>
      </m:r>
    </m:num>
    <m:den>
      <m:r>
        <m:t>b</m:t>
      </m:r>
     </m:den>
   </m:f>
</m:oMath>

where we see how the numerator and denominator are tagged explicitly. In MathML, these arguments are given by the next entity and the one after that, respectively:

<m:mfrac>
<m:mi>a</m:mi>
<m:mi>b</m:mi>
</m:mfrac>

This comparison reveals that OMML can be more verbose than MathML. A less verbose comparison results for the fraction (a+b)/c, since in OMML it's

<m:f>
  <m:num>
    <m:r><m:t>a+b</m:t></m:r>
  </m:num>
  <m:den>
    <m:r><m:t>c</m:t></m:r>
  </m:den>
</m:f>

whereas in MathML, it's

<m:mfrac>
  <m:mrow>
    <m:mi>a</m:mi>
    <m:mo>+</m:mo>
    <m:mi>b</m:mi>
  </m:mrow>
  <m:mi>c</m:mi>
</m:mfrac>

Here the <m:mrow> is needed for the numerator to make it the first entity following the <m:mfrac>. For both a/b and (a+b)/c, the linear format sure has the shortest representation!

Another difference between MathML and OMML is in the positioning of the radical (root) degree and prescript arguments relative to their respective bases. In OMML these arguments are positioned so that the left and right arrow keys traverse the objects unidirectionally. Specifically for the radical, the degree argument precedes the radicand, while for MathML it follows the radicand. By having it precede, a right arrow key at the start of the radical moves into the degree and then into the radicand, exactly the way one would expect geometrically. Similarly OMML's prescripts precede the base, whereas in MathML's multiscripts object they follow the base.