An earlier post describes math context menus (right click somewhere in a math zone) for changing the display characteristics of math objects, like fractions and integrals. For example context menus offer options to convert a stacked fraction into a linear fraction and vice versa. Another post describes math context menus for aligning and/or manually breaking equations on binary and relational operators.

In particular, the second post shows how one can align a sequence of equations separated from one another by soft paragraph marks (Shift+Enter, instead of Enter). For this approach, one chooses the “Align at this character” option for the operator to be used for alignment in each equation. This method is quite general in that binary, relational, and punctuation characters can be used as alignment operators, even when inside math objects.

A useful alternative context menu option not described in those posts allows one to align a set of equations with the single menu choice, “Align at =”. This is less general than marking the alignment operators explicitly, since in each equation the first relational operator that’s not inside a math object is used. To access the option, select two or more equations separated from one another by soft paragraph marks. Then right click anywhere on the selected equations and choose the “Align at =” option. Here “=” is the most common choice for aligning multiple equations. But the “=” just stands for the first relational operator, which could be, for example, “≥” instead of “=”. Note that two or more whole equations have to be selected for the “Align at =” option to be offered. If the last equation is only partly selected, the option won’t appear.

The math context menus also include the options “Professional”, “Linear”, and “Save as New Equation…” The “Professional” option converts any linear format text that is selected in the math zone into the corresponding built-up “professional” form. If no text is selected, the whole math zone is build up. Conversely, the “Linear” option converts built-up math objects to the “built-down” linear format. The “Save as New Equation” option saves the selected equation(s) in the Equation drop down list appearing at the left side of the math ribbon. This gives you an easy way to insert them from the math ribbon. Alternatively you can add a Math Autocorrect entry with the linear format for any math expression/equation you’d like to insert via typed entry. To see this last method in action, try typing \quadratic <space> <space> in a math zone. This inserts the solutions to the quadratic equation.

A number of math display properties have document defaults. These are the ones used if you don’t explicitly override them, which you can usually do by invoking a math context-menu option. The properties all pertain to “displayed” math zones, that is, math zones that begin either at the start of the document or at a hard/shift Enter (CR/VT) and end at the following hard/shift Enter. The options determine math indents and things such as whether integral limits are positioned below and above the integral or as subscript and superscript. In Russia, it’s common to see the integral limits below and above the integral, while in the United States the limits are displayed as subscript and superscript.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

You can change the default settings to suit your tastes or a publisher’s conventions. In the math ribbon (type Alt+= to insert a math zone and then the math ribbon should appear), click on the Tools button over toward the left side of the ribbon. A dialog will be displayed that shows a variety of math display properties along with buttons to access the math autocorrect and recognized-function dialogs.

The document default math properties in this dialog are described in a somewhat technical way in the math section of the RTF specification. The properties belong to the RTF {\mmathPr…} group. They are also children of the <mathPr> OMML element. In this post, I describe the properties in a less technical way. For easy reference to the RTF specification, the relevant RTF control word is listed in parentheses. The dialog also has some options that are not document default math properties, such as “Copy MathML to the clipboard as plain text” instead of “Copy Linear Format to the clipboard as plain text.” Such options do not affect the layout of a document and hence are stored in the system registry rather than in the document.

Default font for math zones (\mmathFontN) Gives a drop-down list of math fonts that can be used as the default math font to be used in the document. Currently only Cambria Math has thorough math support, but others such as the STIX fonts are coming soon.

Reduce size of nested fractions in display equations (\msmallFracN) Specifies that nested fractions should be displayed such that the numerator and denominator are written in a script or scriptscript size instead of regular-text size. Specifically characters in the outermost fraction’s numerator and denominator are displayed using the full text size, characters in a nested fraction are displayed in the script size (about 70% as large as the text size), and fractions nested inside a nested fraction are displayed in scriptscript size (about 60% as large as the text size). TeX uses this “small fraction” choice by default, but Word 2007 does not, basically because in all the physics books I’ve read I don’t remember seeing reduced sizes used in display math. But if you prefer them, you can change them.

Break lines with binary and relational operators (\mbrkBinN) Document property specifying how binary operators are treated when they coincide with a line break. By default, the line break occurs before the binary operator. That is, the binary operator is the first control word on the wrapped line. But you can change it so that a line break occurs after the operator, or so that the operator is duplicated, that is, it appears at the end of the first line and at the start of the second.

Duplicate operators for subtraction as (\mbrkBinSubN) Document property specifying how the minus operator is treated when it coincides with a line break when break operators are duplicated. By default, the minus appears before and after the break, but you can choose a plus before the break and a minus after the break or vice versa.

Place integral limits to the side/centered above and below (\mintLimN) Document setting for default placement of integral limits when converting from linear format to professional (built-up) format in display mode (not inline). Limits can be either centered above and below the integral, or positioned just to the right of the operator. The default setting is to position to the right of the operator (subscript/superscript).

Place n-ary limits to the side/centered above and below (\mnaryLimN) Document setting for default placement of n-ary limits other than integrals when converted from linear format to Professional (built-up) format in display mode. Limits can be either centered above and below the n-ary operator, or positioned just to the right of the operator.  The default setting is above and below the operator.

Use the following settings for math on its own line (\mdispDefN) Document property to use the default math paragraph settings for equations, i.e., use values given by \mlMarginN, \mrMarginN, \mdefJcN, \mwrapIndentN, \mwrapRightN, etc. Default is to use the default math settings described below, but you can change it to use the text paragraph settings.

Left margin (\mlMarginN) Document property for the left margin for math. Math margins are added to the paragraph settings for margins.

Right margin (\mrMarginN) Right margin for math.

Justification (\mdefJcN) Document property for the default justification of displayed math zones. Individual equations can overrule the default setting. Displayed math zones can be left justified, right justified, centered, or centered as a group. When a displayed math zone is centered as a group, the equation(s) are ordinarily left aligned within a block, and the entire block is centered with respect to column margins. The user can use a context menu to align equations in more general ways, e.g., on the equal signs.

Indent wrapped lines by (\mwrapIndentN) Indent of wrapped line of an equation. The line or lines of a wrapped equation after the line break can either be indented by a specified amount from the left margin, or right-aligned. The default indent is 1”.

Right align wrapped lines (\mwrapRightN) If enabled, right justify wrapped lines of an equation. If disabled, the line or lines of a wrapped equation after the line break are indented by \mwrapIndentN from the left margin.

In addition to the properties above, the math RTF and OMML include four useful displacements for displayed math which unfortunately didn’t make it into Word 2007 (hopefully they will someday J). These properties are

Spacing before math paragraph (\mpreSpN).

Intraequation spacing between lines in an equation (\mintraSpN).

Spacing between equations within a display math paragraph (\minterSpN).

Spacing after math paragraph (\mpostSpN).

In addition two useful, but not yet implemented, document default math properties are 1) math style for differential d and related characters (U+2145..U+2149), and 2) which character to use for invisible times (U+2063) if a line break occurs at the invisible times. Ordinarily one would use the \times (U+00D7) for a visible times character, but a raised dot is another possibility. In the United States, the differential d is almost always displayed as a math italic d, but in Europe, an upright d is fairly standard. The latter choice emphasizes that the differential d is different from regular mathematical variables. Similarly the Naperian logarithm base e (U+2147) and the imaginary unit i (square root of -1, U+2148) are displayed as math italic in the United States and upright in Europe.

The Equations Options dialog also includes buttons to examine math autocorrect entries and recognized functions such as trigonometric functions.

MathML doesn't formalize document defaults for math, but MathML math zones can inherit them depending on the implementation. So such defaults are compatible with MathML and need to be expressed in a way outside of MathML.

One subject that seems to come up every other month or so is how RichEdit tables work. So I might as well post the answer. Hopefully RichEdit tables will eventually be described in the Windows SDK. They are not directly related to Math in Office, but I had mathematical expressions in mind when designing RichEdit’s table facility. Both mathematics and tables are recursive. For example you can have a fraction in the numerator of another fraction, and you can have a table in the cell of another table. So implementing tables seemed like a useful project that might also reveal how to implement a WYSIWYG implementation of mathematics. In fact, MathML <mtable>’s have a lot in common with general tables. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Most people at the time (1999) were recommending that a table cell should be represented by a whole RichEdit instance, which would give great generality. But I wanted a model that was much smaller, faster and worked with the built-in Find/Replace functionality and the RTF file converters. To this end, we needed a model, like Word’s, that was part of a single document instance, and could be overlaid on the existing paragraph structure. Accordingly RichEdit's table implementation is very efficient and fast, in fact, much faster than Word’s (although less general). Improvements have been made over the years, but the discussion that follows applies to RichEdit 4.0, which shipped with Office 2002, and RichEdit 4.1, which ships with Windows XP and Vista to this day. It also applies to later versions that ship with Office 2003 & 2007, which have additional features..

Specifically a cell containing a single line of text is represented only by that text, not by some larger structure. An empty cell consists of the single character, the cell mark U+0007. A cell containing multiple lines of text is expressed in terms of a structure that is substantially smaller than a complete edit instance, followed by the CELL mark. Tables can be nested up to 15 levels deep; higher nestings are represented by tab-delimited text. Cells can contain multiple paragraphs of any kind, e.g., bidirectional text, arbitrary tabs and alignments.

The Spring of 1999 was shortly after the Unicode Technical Committee added the U+FFF9..U+FFFB delimiter characters for describing ruby text in Japanese. These characters were available for more general use and seemed ideal for RichEdit’s internal table structure. This choice preceded the addition of the internal-use-only U+FDDO..U+FDEF characters that we use for mathematical structure characters, among other things.

In the (in-memory) backing store, a table row has the form

    {CR...}CR

where { stands for the Unicode STARTGROUP character U+FFF9, and CR  is the ASCII Carriage Return character U+000D. The delimiter } stands for the Unicode ENDGROUP character U+FFFB and ... stands for a sequence of cells, each consisting of cell text terminated by the CELL mark U+0007. For example, a row with three empty cells has the plain text understructure U+FFF9 U+000D U+0007 U+0007 U+0007 U+FFFB U+000D. The start and end group character pairs are assigned identical PARAFORMAT2 information that describe the row and cell parameters.  If rows with different parameters are needed, they may follow one another with appropriate PARAFORMAT2 parameters. A horizontally or vertically merged cell has two characters: NOTACHAR (0xFFFF) followed by CELL (0x7). Any text that appears in a merged cell is stored in the first cell of the set of merged cells.

One way to insert tables is to copy/paste tables from Word. RichEdit reads and writes table RTF. For more programmatic purposes, RichEdit 4.0 introduced the message EM_INSERTTABLEROW, which acts similarly to EM_REPLACESEL but inserts one or more table rows with empty cells instead of plain text. Specifically it deletes the text (if any) currently selected by the selection and then inserts empty table row(s) with the row and cell parameters given by wparam and lparam, respectively, as defined below. It leaves the selection pointing to the start of the first cell in the first row. The client can then populate the table cells by pointing the selection at the various cell end marks and inserting and formatting the desired text. Such text can include nested table rows, etc. Since wparam and lparam point at row and cell parameter structures, this API isn't compatible with Visual Basic and can't be easily added to RichEdit’s object model TOM, although TOM2 does have a general set of table interfaces.

The TABLEROWPARMS and TABLECELLPARMS structures are defined as

typedef struct _tableRowParms

{                           // EM_INSERTTABLE wparam is a (TABLEROWPARMS *)

    BYTE    cbRow;          // Count of bytes in this structure

    BYTE    cbCell;         // Count of bytes in TABLECELLPARMS

    BYTE    cCell;          // Count of cells

    BYTE    cRow;           // Count of rows

    LONG    dxCellMargin;   // Cell left/right margin (\trgaph)

    LONG    dxIndent;       // Row left (right if fRTL indent (similar to \trleft)

    LONG    dyHeight;       // Row height (\trrh)

    DWORD   nAlignment:3;   // Row alignment (like PARAFORMAT::bAlignment,

                            //  \trql, trqr, \trqc)

    DWORD   fRTL:1;         // Display cells in RTL order (\rtlrow)

    DWORD   fKeep:1;        // Keep row together (\trkeep}

    DWORD   fKeepFollow:1;  // Keep row on same page as following row (\trkeepfollow)

    DWORD   fWrap:1;        // Wrap text to right/left (depending on bAlignment)

                            // (see \tdfrmtxtLeftN, \tdfrmtxtRightN)

    DWORD   fIdentCells:1;  // lparam points at single struct valid for all cells

} TABLEROWPARMS;

typedef struct _tableCellParms

{                           // EM_INSERTTABLE lparam is a (TABLECELLPARMS *)

    LONG    dxWidth;        // Cell width (\cellx)

    WORD    nVertAlign:2;   // Vertical alignment (0/1/2 = top/center/bottom

                            //  \clvertalt (def), \clvertalc, \clvertalb)

    WORD    fMergeTop:1;    // Top cell for vertical merge (\clvmgf)

    WORD    fMergePrev:1;   // Merge with cell above (\clvmrg)

    WORD    fVertical:1;    // Display text top to bottom, right to left (\cltxtbrlv)

    WORD    wShading;       // Shading in .01% (\clshdng) e.g., 10000 flips fore/back

    SHORT   dxBrdrLeft;     // Left border width (\clbrdrl\brdrwN) (in twips)

    SHORT   dyBrdrTop;      // Top border width  (\clbrdrt\brdrwN)

    SHORT   dxBrdrRight;    // Right border width (\clbrdrr\brdrwN)

    SHORT   dyBrdrBottom;   // Bottom border width (\clbrdrb\brdrwN)

    COLORREF crBrdrLeft;    // Left border color (\clbrdrl\brdrcf)

    COLORREF crBrdrTop;     // Top border color (\clbrdrt\brdrcf)

    COLORREF crBrdrRight;   // Right border color (\clbrdrr\brdrcf)

    COLORREF crBrdrBottom;  // Bottom border color (\clbrdrb\brdrcf)

    COLORREF crBackPat;     // Background color (\clcbpat)

    COLORREF crForePat;     // Foreground color (\clcfpat)

} TABLECELLPARMS;

Note that paragraph-format information containing the TABLEROWPARMS and TABLECELLPARMS information is attached to the table-row delimiters as set up by the EM_ INSERTTABLEROW message, so merely duplicating the plain-text table structure in the backing store isn't enough to insert a working table. In fact, methods like ITextRange::SetText() convert the special delimiters U+FFF9.U+FFFB to spaces (U+0020). Note also that this table structure is nestable.

The definition of EM_INSERTTABLEROW is extensible, since in the future we'll probably have to support more parameters for table rows and cells. The API also inserts a consistent table row all at once, so that no illegal table parts are present on return. Hence if the document is saved after such an insertion, valid Word-compatible RTF will be written. lparam points at the TABLECELLPARMS structure for the first cell in an array of TABLECELLPARMS structures.  It's important that cbCell = sizeof(TABLECELLPARMS).  That way RichEdit knows how much cell information the client is specifying.  In particular, in the future if more cell parameters are defined, older clients can get away with specifying less and the new RichEdit can assign default values for the new parameters.  Similarly cbRow says how many bytes are defined by the client for TABLEROWPARMS, in case RichEdit is revised to support more row parameters that the client doesn't know about.

To make simple tables easier to define, if fIdenticalCells = 1, lparam points at a single TABLECELLPARMS structure that is valid for all cells in the row.  Note that a nonzero cell border width is guaranteed to give at least a one-pixel border.

The colors are limited to the standard 16 colors defined by

      RGB(  0,   0,   0),     // \red0\green0\blue0

      RGB(  0,   0, 255),     // \red0\green0\blue255

      RGB(  0, 255, 255),     // \red0\green255\blue255

      RGB(  0, 255,   0),     // \red0\green255\blue0

      RGB(255,   0, 255),     // \red255\green0\blue255

      RGB(255,   0,   0),     // \red255\green0\blue0

      RGB(255, 255,   0),     // \red255\green255\blue0

      RGB(255, 255, 255),     // \red255\green255\blue255

      RGB(  0,   0, 128),     // \red0\green0\blue128

      RGB(  0, 128, 128),     // \red0\green128\blue128

      RGB(  0, 128,   0),     // \red0\green128\blue0

      RGB(128,   0, 128),     // \red128\green0\blue128

      RGB(128,   0,   0),     // \red128\green0\blue0

      RGB(128, 128,   0),     // \red128\green128\blue0

      RGB(128, 128, 128),     // \red128\green128\blue128

      RGB(192, 192, 192),     // \red192\green192\blue192

plus two custom colors. The border widths are limited to the range 0 to 255 twips.

If the color index is not in the range 1..18, then autocolor is used, which usually ends up being the system Text or Background colors.

No this isn’t about some kind of science fiction, this is about five Unicode characters that are useful for mathematics, but are generally invisible or should be. The characters are the zero-width space (U+200B), function apply (U+2061), invisible times (U+2062), invisible comma (U+2063), and the new invisible plus (U+2064). This post discusses each one in the context of mathematical text.

The zero-width space is a handy character that has no glyph “ink” and hence no ascent (height above the base line), no descent (depth below the baseline) and no width. In Word 2007 math zones you can insert it (type 200B <Alt+x>) into an empty argument if you don’t want a dotted box character to appear. RichEdit uses it for optional empty arguments to suppress the dotted box except when the insertion point resides inside an empty argument.

The function-apply character (U+2061) is used in the linear format as a binary operator that builds into a math function object. For example in a math zone, if you type sin2061<Alt+x> x and click on “Professional”, you get the math function object sin x. Naturally it’s easier just to type sin<space>x and have formula autobuildup do this for you, but underneath it’s the function apply character that’s controlling the build up process.

The invisible times (U+2062) is a bona fide binary operator and you can break on it and align to it. Unfortunately we didn’t have enough time to develop the uses for invisible times, so it’s not currently very useful. Unlike in Word 2007, it shouldn’t display a glyph, except for a thin space if at the end of a math zone. With it you could then effectively break an equation before any character, not just on binary, relational and some other operators. It would be nice to be able to have it display a multiplication times symbol × if it ends up being the best point for an automatic break. Word 2007 displays the invisible times as a dotted box surrounding a times sign, which is the glyph for it in the Cambria Math font.

The invisible comma (or separator) is supposed to convey the semantic of separating two variables or indices. For example the indices ij on a matrix element aij could be separated by the invisible comma to emphasize that ij isn’t the product of i and j. Word 2007 displays the invisible comma as a dotted box surrounding a comma, which is the glyph for it in the Cambria Math font.

The invisible plus (U+2064) is new with Unicode 5.1 and is supposed to carry the semantic of connecting a whole number like 3 with a fraction like ½ to give a quantity 3½ that has the value 3.5, not 1.5 (3/2). The invisible plus is well intended, but it’s also tricky to use. For one thing in ordinary arithmetic, addition is considered to have lower precedence than multiplication. So the value of the expression 4×3 + 1/2 is 12.5, not 14 (4×3.5). But 4×3<invisible plus>1/2 has the value 14. In this usage, the invisible plus has a higher precedence than multiplication.

Some more discussion of the invisible operators is given in Section 2.14 of Unicode Technical Report #25.