Murray Sargent: Math in Office

WordPad Numbering Limit

2009-06-19T16:16:00Z

In Windows 7, WordPad has undergone many improvements even though it uses RichEdit 4.1+ for editing and display. Time and time again, the excellent Hyderabad team responsible for enhancing the Windows 7 WordPad requested very reasonable extensions to RichEdit 4.1, extensions that have been included in later versions of RichEdit. They’ve also requested features that aren’t in the latest RichEdit (7.0) which ships with Office 2010, but that’s another story. One of their many requests has to do with limiting numbered paragraphs to a maximum number of 255. Why not 1000 or 10000? The reason for the small numbering maximum is that RichEdit 4.1 doesn’t cache paragraph number offsets and calculating the offsets on the fly can require substantial execution time. Without the limit, the RichEdit team had bugs claiming that RichEdit was literally hanging. Interestingly enough, later versions of RichEdit don't have this limit. Let's see why.

When the original OneNote was created in the Office 2003 time frame, it used RichEdit 5.0 and needed some special Page/Table Services (PTS) features. PTS is a component library complementing LineServices. PTS is responsible for laying out pages and tables, whereas LineServices is responsible for laying out individual lines. PTS requires “names” for each paragraph (soft or hard), so Sasha Gil of the RichEdit team added special “NMP” runs for the purpose. Fortuitously, this run infrastructure provides a convenient place to cache paragraph number offsets and allowed us to remove RichEdit’s numbering maximum of 255.

Ironically OneNote has always handled paragraph numbering itself, but nevertheless RichEdit numbering has benefitted by OneNote’s need for PTS. Bidirectional (BiDi) layout involving Hebrew and/or Arabic text and math processing also benefit since the NMP runs greatly speed up paragraph boundary navigation. In fact RichEdit 6.0 and later versions automatically enable NMP runs whenever numbered paragraphs, BiDi and/or math are present in a document even if PTS itself isn’t enabled.

A footnote to this saga is some sage advice given to me by Eliyezer Kohen, the leader of the original teams that developed Microsoft’s TrueType implementation, the OpenType specification, LineServices, and PTS. I was designing and implementing RichEdit’s binary format for, you guessed it, the first version of OneNote (OneNote 2010 has switched to a different format). Eliyezer strongly recommended that RichEdit’s binary format tag paragraph boundaries explicitly, even though RichEdit didn’t formally need such tagging. He was absolutely right. From both structural and performance standpoints, knowledge of paragraph boundaries is very valuable in text editing and display.

Entering Math via the Linear Format

2009-05-07T02:16:00Z

The previous blog post is on the cool math handwriting recognition shipped with Windows 7. The post includes a description of a race I had entering equations using the linear format with formula autobuildup against a member of the math handwriting recognition team, who entered equations using the Windows 7 Math Input Panel. Since the result was essentially a tie, you might like to see how I enter equations using the linear format. If so or if you’re interested in keyboard entry of math in general, run my first math video on You Tube or live.com. It includes a variety of tips that help you to enter equations fast and easily. In the video I’m not racing and, in fact, I somehow manage to restrain myself to be slow and pedagogical. I type in the binomial theorem and a definite integral useful in laser mode locking theory. Many thanks to MS External Research for producing the video.

Math Handwriting Recognition

2009-05-07T02:12:00Z

The next version of Windows, Windows 7, includes a cool applet called the Math Input Panel. This applet lets you enter mathematical text using a pen or a mouse. It recognizes what you enter and displays the result using a special private version of RichEdit 6. It also lets you copy the results to Word, Mathematica, or any other application that reads Presentation MathML.

Many people may find that writing equations by hand with this applet is the easiest and fastest way to enter them into a computer. Since I’ve made similar claims for linear format entry in Word 2007, we decided to have a race. I chose nine equations from theoretical physics and we started entering. The person entering via hand writing beat me by a nose, but had two errors, whereas I had none. But really we both won, since we demonstrated that we could enter equations into Word 2007 remarkably fast.

I’ll continue to use the linear format for writing my technical papers, since I know it so well (I’ve been using it in one form or another for 25 years). In fact, see the following blog post for a video demonstration. But I heartily recommend installing the Release Candidate for Windows 7 and checking out the Math Input Panel. You’ll probably also love Windows 7!

Empty Math Zone Place Holders

2009-04-27T16:35:00Z

You type Alt+= or click the Insert ribbon Equation button, and presto! You’ve inserted an empty math zone place holder that states “Type equation here.” in the language you’re using. Then you type a^2+b^2<space> and you see a²+b², except in better typography. The empty math zone place holder seems simple and intuitive, but behind the scenes a fair amount of software is handling a variety of situations that probably don’t come to mind when you do the things above.

For example, if you cursor away from the math zone, either by using the arrow keys or the mouse, the empty math zone place holder remains; it’s just not selected anymore. If you save the file and reopen it, you’ll see the place holder just where you inserted it. If you select the place holder, possibly with text surrounding it, and copy paste it somewhere else in the document, you’ll see it pasted at the target location.

Furthermore if you return to the place holder, either using the arrow keys or the mouse, the place holder will automatically be reselected. So if you then type something, what you type replaces the place holder. Yet another characteristic: if you type Backspace in a math zone until the last character is deleted, the empty math zone place holder reappears and is selected. Naturally if you type Backspace yet one more time, the place holder is deleted, just as it is if you type the Delete key.

Now what if you type Alt+= immediately before or after an unselected empty math zone place holder? You guessed it! Instead of inserting a new place holder, the current one is reselected. There are other variations that Word 2007 doesn’t get quite right: if you select a bunch of text including one or more empty math zone place holders and then type Alt+=, you’d probably expect the included empty math zone place holders to be deleted, since they’re inside a math zone and nested math zones aren’t permitted. But Word 2007 doesn’t catch this relatively unlikely scenario (it doesn’t crash either, thank goodness!)

The bottom line is that the seemingly simple idea of having a place holder for inserting some math isn’t as straightforward as you might expect.

What do to in the future? The empty math zone place holder is clearly a useful math user interface feature, even if it is tricky to implement correctly. In addition, particularly for educational purposes, one might like to have other place holders within nonempty math zones to ask the user to type, for example, the numerator of a fraction or the integrand of an integral. Such place holders also could be copied and saved to file and reselected by moving the insertion point into them.

Restricted Math Zone Character Formatting

2009-03-04T15:46:00Z

A number of character formatting properties are treated differently in a math zone than they are in ordinary text. These include underline, strikeout, math font face and size, subscript and superscript. This post discusses how these properties differ in math zones, sometimes to the surprise of users.

For starters, the ordinary subscript and superscript attributes are not allowed in math zones, since they are insufficient to handle the more elaborate kinds of scripts found in mathematics. In particular they are only one level; a subscripted superscript cannot be represented with them, nor can a superscript be aligned over a subscript. On a more subtle level, the special “cut-in” kerning of math fonts like Cambria Math isn’t available in nonmath fonts. In principle, it would be possible to support the Ctrl+= hot key for subscript and the Ctrl+Shift+= hot key for superscript along with the corresponding ribbon tools, but it might be confusing and simple linear format commands like e^x for superscripting the x are easier to type in spite of their substantially increased generality.

The underline and overstrike attributes are automatically extended throughout the math zone. We tried allowing them to apply on the usual per glyph basis, but that can lead to visual chaos, with underlines up and down throughout a multilevel equation. So to give feedback to the user, we draw a uniform underline and/or a strikeout throughout the math zone. If you want to underline a particular expression, use the underbar math object (linear format \underbar(…), where … is what you want to underline. This measures the … and draws a uniform underline under it . Similarly \overbar(…) draws a bar above the … . If you want to strike through an expression put it in a rectangle using \rect(…) and use the context menus to choose the horizontal strike option. You also need to hide the rectangle borders, since these are shown by default.

Onto the math font. Only one is allowed in a given math zone and it must be the same size throughout that math zone. Furthermore if the math font can display a character, it must be displayed by the math font and not by some other font, unless the character is marked as "Normal text". The only cases where other fonts are allowed in a math zone is for characters not supported by the math font, such as Chinese and Indic characters, or for Normal text embedded in the math zone.

At first these restrictions to a single math font and size seem overly cautious. Users love to use multiple fonts for one purpose or another. But the restrictions are there for very good reasons. Mathematical typography has extensible entities such as fraction bars, the line over the radicand of a square root, and a myriad bracket types that grow to fit their arguments. There are many font-size depended parameters that support the varioushorizontal and vertical placements in mathematical expressions. One needs to have a uniform size throughout the math zone to render these things properly. Also mathematical expressions just look better when displayed consistently with the same font. However, one case where it might be handy to use another font on occasion is when the math font doesn’t support the full Unicode math character set, which is the case with Cambria Math. The STIX font does have glyphs for all the math characters. Hopefully it will support the other features of a math font needed for high-quality math typography.

You might want to call attention to some math characters within a math zone. Changing the math style isn’t what you need, since that would change the meaning of the variables. One method that I’ve used over the years in lectures is to distinguish variables by color. For example, three-mode laser light has the frequencies ω₁, ω₂, and ω₃, in order of increasing frequency. To emphasize their relationships, I’d color them and their ray lines as red (ω₁), green (ω₂), and blue (ω₃), since in the visible light spectrum red has lower frequency (longer wavelength) than green, which, in turn, has lower frequency than blue. The laser mode frequencies were much closer together in frequency than those colors, but people understood what was meant. In fact, color is sufficiently important for such purposes that MathML has foreground and background color attributes. OMML doesn’t, but should. Word uses embedded WordProcessingML to represent color in math zones, but this isn’t as interoperable as having color attributes directly in OMML.

RichEdit Paragraph Indents

2009-02-16T21:38:00Z

RichEdit paragraph indents are based on the original RichEdit 1.0 definitions. These differ somewhat from Microsoft Word’s definitions and hence from TOM’s (RichEdit’s Text Object Model), which were developed in collaboration with the Word team. In addition, the RTF file format uses Word’s definitions, naturally. RichEdit’s paragraph indents can be set using the EM_SETPARAFORMAT message and retrieved using EM_GETPARAFORMAT both of which use either the PARAFORMAT or PARAFORMAT2 structures. The differences in these definitions have led to considerable confusion over the years, so this post is dedicated to explaining the relationships. These definitions differ, in turn, from those used in math paragraphs, as discussed in recent blog posts.

The PARAFORMAT[2] structure has the indent variables

LONG dxStartIndent;

LONG dxOffset;

LONG dxRightIndent;

The PARAFORMAT2 structure also contains the variable

WORD wNumberingTab;

Meanwhile Word, TOM, and RTF have the variables (in TOM terminology) FirstLineIndent, LeftIndent, RightIndent, and ListTab. They look similar to the corresponding PARAFORMAT2 variables, but the first two have different meanings and hence the confusion, since RichEdit clients typically end up using a mixture of the APIs.

First consider cases having a zero value of wNumberingTab, which equals the TOM ListTab. Then the first line is indented by LeftIndent + FirstLineIndent. Meanwhile in PARAFORMAT notation, the first line is indented by PARAFORMAT::dxStartIndent. Subsequent lines in the paragraph are indented by the TOM LeftIndent, while in PARAFORMAT notation, they are indented by PARAFORMAT::dxStartIndent + PARAFORMAT::dxOffset. Summarizing the TOM/PARAFORMAT relationships, we have

TOM/Word	PARAFORMAT
FirstLineIndent	−dxOffset
LeftIndent + FirstLineIndent	dxStartIndent
LeftIndent	dxStartIndent + dxOffset
ListTab	wNumberingTab
RightIndent	dxRightIndent

Here the third relationship follows from the first two, but it’s included for clarity.

Now consider cases with nonzero wNumberingTab or equivalently ListTab. This value is the width reserved for the list (numbering) text on the first line of a numbered/bulleted paragraph provided its value exceeds both dxOffset (−FirstLineIndent) and the width of the list text itself. In particular, if ListTab < −FirstLineIndent, ListTab has no effect. Since FirstLineIndent is negative in most scenarios (e.g., when you type the Ctrl+Shift+L hot key to turn on a bulleted list), FirstLineIndent often determines the space allocated to the numbering text instead of ListTab. But for a positive FirstLineIndent, ListTab determines the space so long as it’s wider than the numbering text. Summarizing these relationships, the start of text on the numbered line is indented by (using PARAFORMAT2 variables)

dxStartIndent + max(list text width, wNumberingTab, dxOffset)

or equivalently with TOM variables

LeftIndent + FirstLineIndent + max(list text width, ListTab, −FirstLineIndent)

RTF control words for these variables are \fiN (FirstLineIndent), \liN (LeftIndent), \riN (RightIndent), and \pnindentN (ListTab). Here \pnindent is a control word in the original Word list notation. Later control words are described in the RTF specification under the heading “List Tables”.

OMML Specification, Version 2

2009-01-16T19:36:00Z

The OMML (Office math markup language) specification has been improved in response to the great feedback we received from the ISO reviews. It’s part of the full OpenXML documentation Version 2 and is very handy to have if you’re working with OMML. The full OpenXML documentation itself is also very useful if you’re working more generally with OpenXML.

To get the documentation, click on http://www.ecma-international.org/publications/standards/Ecma-376.htm. Then click on ECMA-376 2nd edition Part1 to start a 50 MB download of the file entitled “ECMA-376, Second Edition, Part 1 - Fundamentals And Markup Language Reference.zip”. Browse the zip file and copy “Part 1: Fundamentals and Markup Language Reference”, a 34 MB pdf file to somewhere convenient on your disk drive. Then open that file with the Adobe Reader. In the left pane of the Reader, click on the Bookmarks icon to navigate this huge file.

To get to the OMML documentation, click on SharedMLs Reference Material, and then on Math. You’ll see three entries, “Table of Contents”, “Elements”, and “Simple Types”. You can click on the “Elements” to see each OMML element referenced. Clicking in turn on one of them, you get the full documentation on that element. Similarly you can investigate the "Simple Types".

The Math Paragraph

2008-12-19T05:07:00Z

The earlier post Breaking Equations into Multiple Lines describes equation line breaking and alignment. In particular, long equations often do not fit on a single line and need to be broken up for display on multiple lines. Word 2007 offers two approaches: automatic and manual line breaking. A related feature is alignment of multiple equations, such as aligning the equal signs in a group of equations, which is described in that post and in More on Math Context Menus.

The present post describes how these features are implemented in Microsoft Office using the mathematical paragraph, or “math para” for short, and mentions support for some additional properties supported by the underlying layout component (PTS) that aren’t yet implemented in Word or RichEdit, such as elegant equation numbering and customized vertical spacing. The post concludes with some observations about representing the math para in OMML, RTF and MathML. At some time I’ll post more about PTS, Page/Table Services, which is the intimate companion of LineServices, the Microsoft line layout component.

What’s a math para?

A math para is a group of one or more “equations” attached to a line in a text paragraph. The text paragraph is the ordinary paragraph discussed in the blog post Paragraphs and Paragraph Formatting (it may be helpful to read that post first). If a math para ends the text paragraph, the math para is terminated by the CR (inserted by typing Enter) that terminates the text paragraph. In all other cases, the math para ends with a VT (inserted by typing Shift+Enter) and is followed by a nonempty text line to which it is attached. If the math para contains more than one “equation”, they are separated by VT’s, and each equation consists of one or more math lines. Here “equation” is quoted because the entity involved is actually a display math zone which might only be a mathematical expression instead of a whole equation. But display math zones usually are equations and hence the name. It’s handy also to refer to text ending with a VT as a “soft paragraph”, as distinguished from text ending with a CR, which is a “hard paragraph”. This terminology is explained further in Paragraphs and Paragraph Formatting.

Okay, what’s a display math zone? First note that a math zone is a text range within which math typography rules usually apply and outside of which math typography rules do not apply. The caveat “usually” appears because math zones can contain specially marked normal text runs for which math typography rules don’t apply. Such text is handy for making equations like rate = distance/time, in which text occurs that should be displayed in normal upright style rather that in the math italic style used for most mathematical variables.

Math zones can be inline or display, corresponding to TeX’s $ and $$ toggle keys, respectively. If a math zone fills an entire soft or hard paragraph, it is a display math zone, i.e., it is displayed on its own line(s). If a math zone is preceded and/or followed by nonmath text other than a CR or VT, the math zone is inline and is rendered in a more compact fashion. Inline math zones usually consist of math expressions or variables, whereas display math zones usually consist of equations or formulas. Inside Microsoft Office, math zones are identified internally by a character-format effect bit like bold. Hence if you delete the ordinary text separating two math zones, you get a single merged math zone. (With hindsight, less overall code would have been required if we had delimited the math zones with special characters, rather than using a character-format effect, but that’s another story).

Note that a text paragraph can contain more than one math para as is often the case in technical documents and books.

Math Para Properties

In addition to the underlying plain-text structure of math paras described in the preceding section, there are math para properties representing equation alignment, manual breakpoints, and various horizontal and vertical parameters. The ways you can specify equation alignment and manual breaks are discussed in Breaking Equations into Multiple Lines and More on Math Context Menus. An alignment point is represented internally (and in OMML/RTF) by an operator character format property, not by a character of its own. The operator character so used for alignment can be any kind of operator and can be nested arbitrarily deeply inside a mathematical expression.

An equation break also occurs on an operator character and is represented by a character format property of that operator. But the operators that can be used for equation breaks are restricted in both type and context. First, equation breaks occur only on relational or binary operators. Second, context restricts the break possibilities further. For example, there’s no breaking inside a subscript or superscript object, unless the script or base being broken is bracketed. The reason for this restriction is for readability. The software could break a math expression most anywhere, but for readability, it’s important to know the scope of the expression being broken. Parentheses or brackets reveal such scope, as does the math zone itself if the operator isn’t contained within any math object, like a fraction or superscript object.

The manual break property also specifies to which operator on the first line of the broken equation the break should be aligned. As discussed in Breaking Equations into Multiple Lines, this choice can be made using the Tab key.

A math paragraph has its own alignment and indents, independent from the parent text paragraph. The blog post Default Document Math Properties includes discussion of the default math para alignment and various horizontal and vertical spacing parameters. The math para alignment can be one of: Center as a Group, Left, Right, Center. This kind of alignment is different from aligning a set of equations at various operators. It affects the whole math para as a block. In principle the alignment and positioning parameters could be specified on individual math paras as well, but Word 2007 only implements the math para alignment for individual math paras. The various positioning parameters are math para space before/after, inter/intra equation spacing, left/right indent, and wrap indent. Wrapped lines of an equation can either go to the wrapped indent or be aligned left/right/center. Word 2007 implements the indents on a document default basis, but doesn’t implement the vertical spacings.

Another important feature of the math para is optional equation numbers for one or more equations within the math para. The equation numbers are specified by soft paragraphs of their own and can be placed to the left or right of the equation with a variety of vertical alignment options. Hopefully someday Office will take advantage of this important functionality.

OMML, RTF, and MathML Representations of Math Paragraphs

The OMML tag <oMathPara> contains a math para and similarly the RTF group {\*\moMathPara..} contains a math para, which can contain multiple equations consisting of display math zones with the various alignment and breaking options described above. MathML doesn’t have the concept of a math paragraph. It could be modeled using MathML’s <mtable> entity, but it’s simpler to represent it as a sequence of one or more <math display="block"> entities separated by soft paragraph marks and terminated by a soft or hard paragraph mark. These marks are part of the parent document format into which the MathML is embedded. The equation alignment and breaking properties can be represented in MathML 3.0 using the ID attribute. The math para properties can be specified in the parent document format.

Paragraphs and Paragraph Formatting

2008-11-22T02:25:00Z

What paragraphs are and how they are formatted are questions that continually come up both inside and outside of Microsoft. So this post describes Word/RichEdit paragraphs in general. A subsequent post will describe the “math paragraph”, which is part of a regular paragraph and is used for displayed equations, as distinguished from inline mathematical expressions.

The paragraph is a very important structure in written language. About six years ago, I developed the RichEdit binary format, which shipped with RichEdit 5.0 (Office 2003) as RichEdit’s preferred copy/paste format and was used by OneNote 2003 and 2007. In the design stage I talked with Eliyeser Kohen, of TrueType, OpenType, LineServices, and Page/Table Services fame. I was inclined to have four parallel streams: plain text, character formatting, paragraph formatting, and embedded objects, a format corresponding to the internal RichEdit representation. Eliyezer agreed such parallel streams were important, but insisted that they should be broken up into paragraphs. At the time, this seemed like extra overhead to me and I naturally didn’t want to slow things down. But I followed his advice and it’s right on! First, what’s a paragraph? Then what’s paragraph formatting? Then what’s a “soft” paragraph? And finally, what’s the final EOP?

What’s a paragraph?

From a natural language point of view, a paragraph is one or (preferably) more closely related sentences that naturally belong together without becoming too long. From the Word/RichEdit point of view, a paragraph is a string of text in any combination of scripts and inline objects, including possible “soft” line breaks and “math paragraphs”, with uniform “paragraph formatting” up to and including a carriage return. The carriage return (CR) is given by the Unicode character U+000D, which you insert by typing the Enter key. In plain text on PC’s, the paragraph is usually terminated by a CRLF (U+000D U+000A) combination, but not ordinarily inside a Word document or RichEdit instance. Just the CR is used.

<rant> It’s quite convenient to use a single character. It takes up less space than the CRLF and it’s easier to parse/manipulate, since it’s an atomic entity. In fact, Unix already used a single character, the line feed (LF—U+000A), back in 1972, several years before the PC operating systems were developed. Unfortunately, the PC with its DEC heritage preferred CRLF, a holdover from the old teletype days, and Word and the Mac shortened it to CR instead of LF. Windows NotePad still isn’t able to display Unix/Linux LF terminated paragraphs correctly after all these years (note that 2008 > 1972). I’m on a mission to fix that, but please don’t hold your breath! Anyhow I like CR better than LF, mostly because of habit. Clearly it would have been better to have a single standard. In this connection, it’s interesting to note that Word and RichEdit can handle CR, LF, and CRLF terminated paragraphs, even though they prefer CR. </ rant>

What’s paragraph formatting?

A key characteristic of a paragraph is its formatting, which is represented by a pretty large set of properties. Most of these properties are settable using a paragraph formatting dialog. In particular, there’s alignment (left, right, center, justify, along with a variety of East Asian options), space before/after, line spacing (single, double, multiple, at least, exactly), left/right margins and wrapped line indent, line/page breaks, tabs (oh, how I wish HTML had tab support!), and bullets/numbering. Internally, paragraphs and their formatting get overloaded with such entities as tables and drop caps, but let’s not get distracted. Using hot keys like Ctrl+E for centering or the paragraph formatting dialog, you can set the formatting for the paragraph(s) in which the current selection occurs. If you just have an insertion point (the blinking caret), only the paragraph containing the insertion point gets the new formatting.

What’s a soft paragraph?

When you create a numbered list, you may want to have an entry with one or more line breaks but no new number or bullet. To insert a line break without ending the paragraph, type Shift+Enter, which inserts a Vertical Tab (VT—U+000B). Even though you get a line break, you don’t end the current paragraph, so no new line number appears. All the paragraph properties remain the same with the new line and the space-before property doesn’t apply to the new line, since the line is inside the paragraph. Sometimes it’s handy to refer to a sequence of lines terminated by such a line break as a “soft paragraph”. In HTML, these “soft line breaks” are represented by the <BR> tag, whereas “hard” paragraphs are identified by the <P> tag.

Thinking of numbered entities, you might want to change the character formatting of the number or bullet out in front. For example, you might want to use a larger font size or a different font. To do this, change the appropriate character formatting of the CR that ends the paragraph.

Final EOP

To provide a place to attach paragraph formatting for the last paragraph, every Word document and every RichEdit rich-text instance has a “final EOP” (end of paragraph), represented by a CR (CRLF in RichEdit 1.0). You cannot delete the final EOP, nor can you move the insertion point past it. In the Word and RichEdit object models, the ranges can select up through the final EOP, but they cannot collapse to an insertion point that follows the final EOP. The farthest they can go is up to just before the final EOP. Similarly messages like EM_EXSETSEL cannot make the RichEdit selection go beyond the final EOP.

RichEdit also supports plain-text controls, which are characterized by uniform paragraph formatting and don’t need, or have, a final EOP. An empty plain-text control is really empty, whereas a rich-text control always has at least one character, the final EOP.

More on Math Context Menus

2008-11-04T20:45:00Z

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.

Default Document Math Properties

2008-10-27T04:27:00Z

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.

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.

RichEdit’s Nested Table Facility

2008-09-15T05:36:00Z

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.

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_INSERTTABLE (WM_USER + 232), 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_ INSERTTABLE 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_INSERTTABLE 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.

The Invisibles

2008-08-26T01:37:00Z

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 a_ij 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.

Improved MathML support in Word 2007

2008-07-28T04:57:00Z

Two very interesting developments are happening that will improve Word 2007’s MathML support. The first is key for helping in getting Word 2007 math text into the scientific and technical publisher workflows and the second may help in this regard too. Specifically new transforms are now available in beta versions enabling Word to read and write MathML. These XSLT files are responsible for converting between Word’s native math format OMML and MathML 2.0. If you’d like to try out the new files (omml2mml.xsl and mml2omml.xsl), you can download them from the Microsoft Connect site using the invitation code: 0707-84P4-DPWT. Once you’ve downloaded the files, copy them to C:\Program Files\Microsoft Office\Office12 subdirectory, or wherever winword.exe is. Before doing so, you might want to change the current omml2mml.xsl and mml2omml.xsl files to omml2mml.xsl.bak and mml2omml.xsl.bak, respectively, in case you want to back out the update at a later date. But I doubt you will. The new ones are significantly better.

The second development is that Word 2007 will have a service pack release that enables it to read and write the ISO standard odf files as well as the native ISO standard OOXML files. In the odf standard, math zones are represented by MathML 2.0. So when Word converts to and from odf, it will use MathML 2.0 for all math zones. And it will use the files above to do the translations.

Subscript and Superscript Bases

2008-06-29T05:08:00Z

For proper math typography, it’s important to know the base of a subscript or superscript expression. For example, in Einstein’s equation E = mc², the superscript expression c² appears and c is the base, not mc. Knowing what the base is allows proper kerning of the base relative to the script (superscript or subscript) as well as providing more accurate semantics in interoperating with mathematical calculation engines.

This post describes the subscript/superscript base rules used by Word 2007 and RichEdit 6 in building up math text from the linear format. The rules are good, but not infallible, and users can overrule them either directly in the linear format or after they are built up into the Professional format.

Unicode math alphabetics: Ordinarily when a user types an ASCII letter or a Greek lower case letter α..ω (along with some variants), the letter is automatically converted to the corresponding Unicode math italic letter. These special mathematical letters, along with the basic set of Latin letters in Fraktur, script, and open-face math styles, are reserved for mathematical variables . Accordingly if a subscript or superscript follows such a letter, that letter is considered to be the base. In linear format if you type E=mc^2<space>, you get E = mc², where the letters are given by math italic characters (not used here in this blog post). In particular, c would be given by the math italic c, U+1D450, rather than by the ASCII c, U+0063. This single math italic c is the base of the superscript expression c². For more information on the math alphabetics, please see Section 2.1 of the Unicode Technical Report #25.

Numbers: A consecutive string of ASCII digits is treated as a base. So in the expression 100², the 100 is the base of the superscript expression and has the mathematical meaning of “one hundred squared”. This quantity is typed in as 100^2.

ASCII letter strings: Since mathematical variables are almost always represented by math alphabetics, a consecutive string of ASCII letters is treated as a base. So in the superscript expression sin^-1, the base is “sin”. Actually this case is usually handled by the function name mechanism described next. You can enter an ASCII letter string by turning off the italic button before you type or by selecting the corresponding math italic letters and then turning off the italic button. Be sure to turn the italic button back on if you want to enter math italic variables.

Function names: when a consecutive string of English alphabetics is typed followed by a space or bracket of some kind, the resulting math italic string is “folded” down to the corresponding ASCII letter string and compared to entries in a mathematical function dictionary. If found, the folded version of the string is used followed by the function-apply operator U+2061. The dictionary includes trigonometric functions like sin, cos, tan, etc., along with many other famous math function names. Users can modify this dictionary. If the function-apply operator is then followed by a subscript or superscript, that script is transferred to the function name, and the function name becomes the base of the script expression. This is handy for typing in expressions like sin^-1x.

Embellished operators: If an operator character precedes a subscript or superscript, the operator is the base. For example, in the expression +₂, the + is the base.

Built-up math objects: If a built-up math object such as a stacked fraction precedes a subscript or superscript, that object is the base.

Superscript a subscript object: Exceptions to the rule above occur for superscripting a subscript object and subscripting a superscript object. In both of these cases, the combination is turned into a subsup object, which has special typography, typically placing the superscript over the subscript.

Opaque strings: Opaque strings are whatever is inside a \begin \end expression. Such strings are bases if followed by a subscript or superscript. This is the catch-all method of letting most any mathematical text be a subscript/superscript base. The user is cautioned to use reasonable choices so that the result is understandable to readers.

Complex script characters: In Indic scripts like Devanagari, a number of Unicode characters may be combined to form a character “cluster”. If such a cluster is followed by a subscript or superscript, the cluster becomes the base. However, this doesn’t occur for Arabic ligatures, for which only the last character is treated as the base. One can force the whole ligature to be the base by putting it inside a \begin \end expression, i.e., by making it an opaque string.

Ordinary text: Expressions resulting from the linear format “rate” are called ordinary text and are useful as variables when you want to spell out the variables’ names. Such ordinary text strings are treated as bases.