Murray Sargent: Math in Office

RichEdit Character Formatting

MurrayS3 — Wed, 08 Feb 2012 19:21:00 GMT

RichEdit’s name derives from its ability to represent rich text. Such text is comprised of text runs with different sets of character and paragraph formatting properties along with embedded objects, such as images. Some discussion of paragraph formatting is given in an earlier post. The present post discusses how character formatting is represented in RichEdit and how it differs from CSS (cascading style sheet) formatting used, for example, with HTML.

Typical character formatting properties include bold, italic, underline, text color, background color and font. These properties affect how the characters are displayed. Other properties may attach special behaviors to the text in addition to affecting the display. Such properties include the hidden-text, math-zone, protected-text, and hyperlink effects. Much relevant information is given in the documentation of RichEdit’s character formatting APIs, such as the EM_SETCHARFORMAT message and the ITextFont interface.

The APIs can change most any combination of properties. This capability is implemented by allowing properties to have a NINCH value (no input, no change). As such, any or even all properties can remain unchanged by the API. For EM_SETCHARFORMAT, property NINCHs are represented by zero mask flags in CHARFORMAT::dwMask. For ITextFont duplicates, the ITextFont::Reset(tomDefault) method sets all properties to be the NINCH value.

The ability to specify a partial set of properties is reminiscent of CSS. For CSS, a subset of properties can be applied to a text node in a document tree. Properties that are not specified for a node are inherited from those active at a higher node in the tree. A full set of properties is defined at the highest node (the root). A feature of such a structure is that if a root property is changed, the new property value is used for lower nodes unless one or more intervening nodes have explicit values for that property.

RichEdit has a relatively flat model with two formatting levels: the edit instance’s default formatting set and modified sets resulting from invoking formatting APIs on text runs. The former is a little like root-node formatting. But these two levels do not work as a two-level CSS tree. Internally RichEdit stores character formatting properties in a CCharFormat structure, which contains a superset of the public CHARFORMAT2 properties. Unlike CHARFORMAT2, CCharFormat does not have a mask (dwMask); all its properties are defined.

To see how this differs from the CSS inheritance approach, start with an empty instance and insert some plain text like “Hello world” that doesn’t result in any automatic character formatting. That is, all the characters can be displayed using the default font, no complex scripts are involved, no automatic hyperlinks or math zones exist, etc. As such there is a single text run with character formatting completely specified by the default CCharFormat.

Let’s suppose that the default character formatting isn’t bold and apply bold to the “Hello”. That text run will then have a new CCharFormat that’s identical to the default CCharFormat except for being bold. What’s different about this model from CSS is that once a new CCharFormat is created, it remains unchanged if the default properties are changed later on. In this example, if the default CCharFormat is now changed to be underlined, the bold “Hello” will not be underlined, but the “world” will be underlined, since the “world” still uses the default format.

Another way of saying this is that a CCharFormat is a fully populated character-formatting property set. It’s not a “property bag” that contains only some properties, allowing the remaining properties to be inherited from higher nodes.

A good example of where RichEdit needs to add property bags is to store OpenType properties. Such a property has a 32-bit identifier id and a 32-bit value value. By default the text has no such properties. A generic mode could apply default OpenType properties to the text, e.g., properties like standard English ligatures and pair kerning. To apply discretionary properties, such as elegant swash glyph variants, the RichEdit client could call ITextFont2::SetProperty(id, value). The ITextFont2 interface was defined in RichEdit 6.0 along with several other interfaces which I’ll post about sometime soon. Up through RichEdit 8.0, which will ship with the next version of Office, support of discretionary OpenType properties isn’t implemented. Of course, a lot of OpenType features have been supported for a while, including those for complex scripts (since RichEdit 3.0) and for mathematical typography (since RichEdit 6.0).

In principle this property-bag approach could be used for the CCharFormat properties instead of creating CCharFormat’s for text runs. This alternative would allow the default character format properties to be used on text runs that don’t have explicit values for those properties in a property bag. This two-level model is not as fast as using fully defined CCharFormat’s, but the flexibility might be worth the performance hit.

Math in Office Links

MurrayS3 — Mon, 09 Jan 2012 16:30:00 GMT

I started this blog in 2006 and now it’s 2012. How time flies! At this point it seems worthwhile to post links to previous posts grouped according to subject. The present post provides links relevant to the main theme of the blog, math editing and display in Microsoft Office. Eventually it would be nice to have a book on this subject. A future post will provide links to a secondary theme, RichEdit-specific documentation.

A number of readers have provided auxiliary information, “cheat sheets”, short cuts, etc. I’d like to collect a list of these, so if you have links to such information please send them to me and I’ll post them. Also please feel free to add such links as comments to this post.

Editing Math Using Keyboard

Math Accents

Formula Autobuildup in Word 2007

Linear Format Version 3

Keyboard Entry of Subscripts and Superscripts

Math Keyboard Shortcuts

Negated Operators

Keyboard Operator Shortcuts

Entering Matrices

Equation Arrays

The Invisibles

Using Left/Right Arrow Keys in Mathematical Text

Math Selection

Subscript and Superscript Bases

Empty Math Zone Place Holders

User Spaces in Math Zones

Automatic arguments

When Formula Autobuildup Occurs

Linear Format Notations for Mathematics

Editing Math using Ribbon, Dialogs, Context Menus

Math Ribbon Entry of Subscripts and Superscripts

Math Context Menus

Formatting

Using Math Italic and Bold in Word 2007

Sans Serif Mathematical Symbols

The Math Paragraph

Paragraphs and Paragraph Formatting

Two Math Typography Niceties

Restricted Math Zone Character Formatting

Breaking Equations into Multiple Lines

Default Document Math Properties

Math Font

Special Capabilities of a Math Font

High Fonts and Math Fonts

STIX Beta Fonts

Equation Numbering

Equation Numbering Prototype

Cool Equation Number Macros for Word 2007

Versions

Mac Word 2011 and Math

Math in Office 2010

Improved MathML support in Word 2007

Demos

Article/Video on Murray Sargent and Math in Office

Equations in Word 2007

Entering Math via the Linear Format

Background

High-Quality Editing and Display of Mathematical Text in Office 2007

Creating Math Web Documents using Word 2007

Directionality in Math Zones

Hidden Math Features in Word 2007

Smart Canvasses

Math Find/Replace and Rich Text Searches

Converting Equations from MathType to Word 2007's Equation Format

How I got into technical WP

Keyboard Operator Shortcuts

MurrayS3 — Fri, 02 Dec 2011 23:02:00 GMT

The previous post introduces Hermann Klinke’s math input notation, which he developed to speed up entry of equations for real-time note taking in OneNote. The post is followed by a very interesting set of comments comparing high-speed, and yet easy-to-remember, input sequences. Some of these involve hot keys and some can be done with math autocorrect. Both approaches are significantly faster than TeX input. In a future post, I’ll write about possible use of hot keys in math zones, which seems like a really powerful feature (MathType has it). The present post deals with a simple, intuitive way of entering 129 Unicode operators.

Over the years I’ve played with simple keyboard sequences for entering operators, such as +- giving ±. Some such sequences work in math zones of Office 2007/2010. This post gives a table of a larger set of 129 sequences that are reasonably unambiguous. Note that ^ and _ are not used since a user may want to superscript or subscript an operator. Even the case +- giving ± could be ambiguous, since one might want to write a + −b. The user can enter this by typing a+-<undo>b, so counting on undo is a possible way to free up some other natural sequences. An interesting example is <-, which has a mathematical meaning as illustrated by the relation a < −b. Accordingly, the sequence <- isn’t used to produce ←. In contrast, -> has no mathematical meaning and therefore produces → unambiguously. Fortuitously → is much more common in mathematics than ←, since → is used in limit expressions. The +- and -> are included in the math autocorrect file that ships with Microsoft Office. You can add the new ones in this post to your math autocorrect file.

The operator-sequence table given below includes keyboard sequences for operators that can be produced using the ASCII operators !+-./:<=>`' and ~. I couldn’t resist adding the somewhat unintuitive characters `, which transforms < and > into ≺ and ≻, respectively, and ', which transforms < and > into ⊂ and ⊃, respectively. These transformations provide access to 44 additional operators. To input the entire Unicode operator repertoire, one needs a notation that uses additional characters or falls back on TeX notation.

In the present scheme, = usually adds a horizontal bar under the preceding operator. For example, >= produces ≥. An additional = converts ≥ into ≧. For cases where Unicode lacks the single-bar character but has the double-bar character, a single = produces the double-bar character directly. For example, ≷ = → ⪒. Amazingly enough ⪒ actually exists in Unicode! Similarly, ~ puts a ~ under the preceding character, as in ~~ → ≈, etc.

Unicode has 18 negated operators defined by the corresponding unnegated characters followed by the slanted-bar combining mark U+0338 as shown in Table 2.8 of Unicode Technical Report #25 Unicode Support for Mathematics. Table 2.8 also has 18 negated operators that have the vertical bar combining mark U+20D2. It would be easy to add the former to the table, but our current fonts don’t display them very well. Using the vertical bar for the corresponding combining mark can be ambiguous and needs further analysis.

In the table the characters in the shaded cells result from typing the characters in the unshaded cells to their left. Note that the Office formula autobuildup facility automatically replaces the ASCII - by U+2212 (−), so technically there are no entries for the ASCII -. In the table, the shaded characters are followed by their Unicode code points without the U+ prefix for simplicity.

char₁

char₂

New char

char₃

New char

char₄

New char

char₅

New char

‼

203C

⩮

2A6E

−

00B1

⩲

2A72

−

∓

2213

−

∹

2239

−

≡

2261

≣

2263

−

→

2192

∸

2238

≐

2250

≑

⩧

2251

2A67

⩪

2A6A

∻

⩭

223B

2A6D

≮

226E

≰

≴

≸

⊄

⊀

2270

2274

2278

2284

2280

⊈

2288

≠

2260

≢

2262

≯

226F

≱

≵

≹

⊅

⊁

2271

2275

2279

2285

2281

⊉

2289

≁

2241

≄

≉

2244

2249

≇

2247

∷

2237

⩴

2A74

≔

2254

⪇

⋦

2A87

22E6

≨

⪉

2268

2A89

≪

226A

⋘

22D8

≤

2264

≦

⋚

2266

22DA

⪋

2A8B

≶

2276

⪑

2A91

≲

2272

⪅

⪏

2A85

2A8F

⊂

2282

⊂/

⊆

⫕

⫓

⫇

2286

2AD5

2AD3

2AC7

⊊

⫅

⫉

228A

2AC5

2AC9

⫋

2ACB

≺

227A

≺/

⪯

⪻

≾

2AAF

2ABB

227E

⪱

⋨

⪳

⪷

2AB1

22E8

2AB3

2AB7

⪵

⪹

2AB5

2AB9

⋜

22DC

⩵

2A75

⩶

⪙

⪚

⩳

2A76

2A99

2A9A

2A73

⋝

22DD

≕

2255

≂

2242

⪈

⋧

2A88

22E7

≩

⪊

2269

2A8A

≥

2265

≧

⋛

2267

22DB

⪌

2A8C

≫

226B

⋙

22D9

≷

2277

⪒

2A92

⊃

2283

⊃/

⊇

⫔

⫖

⫈

2287

2AD4

2AD6

2AC8

⊋

⫆

⫊

228B

2AC6

2ACA

⫌

2ACC

≻

227B

≻/

⪰

⪼

≿

2AB0

2ABC

227F

⪲

⋩

⪴

⪸

2AB2

22E9

2AB4

2AB8

⪶

⪺

2AB6

2ABA

≳

2273

⪆

⪐

2A86

2A90

≆

2246

⪝

2A9D

⪟

2A9F

≃

2243

≅

⩬

2245

2A6C

⪞

2A9E

⪠

2AA0

≈

2248

≊

≋

224A

224B

⩰

2A70

Klinke’s Streamlined Math Input Notation

MurrayS3 — Mon, 21 Nov 2011 04:41:00 GMT

Hermann Klinke has designed and instrumented an input notation on top of the Microsoft Office math facility that you may want to try. It significantly reduces the number of keystrokes needed to input mathematical text. His motivation is to have a way to enter equations in real time while taking lecture notes. He has documentation and an augmented math AutoCorrect list. This blog post includes an abbreviated version of the tutorial given in the documentation. The OneNote format used in the documentation allows easy display of mathematical text, whereas I’ve only been partly able to coax the blog facility to display such text (via images inserted laboriously by hand into HTML). The full version has lots of nice examples of built-up mathematical constructs. For that version, please click on the documentation link.

What is it?

It's an easy to learn and intuitive short hand notation that leverages Office's new powerful Math facility to quickly enter professionally formatted math formulae and technical symbols into Office documents. The short hand notation is ergonomically optimized for the standard U.S. keyboard layout, but also works very well on other standard country-specific keyboard layouts. There is no faster and easier way to enter math on a standard keyboard than this!

What can you do with it?

- Take notes in real-time during mathematical or technical lectures or presentations

- Quickly publish mathematical or technical documents or books

- Do mathematical or technical homework as fast as with pen and paper

Why is it better than the status quo?

TeX is the de-facto standard for publishing mathematical or technical documents or books. Many universities even only accept papers and final theses written in TeX. It's very mature and produces the exact same results on all computers. But it requires special software and has a big learning curve. Learning TeX is like learning a new programming language: There are hundreds of keywords, differenent tools and libraries and the source even looks similar to the source code of a programming language. The source is very hard to read and it takes many months to be proficient in TeX. The commands are in English and not necessarily consistent, so remembering them is not easy, especially for foreign users. It is also very difficult to write fast enough with it to take notes in real-time during lectures or presentations because each commands usually consists of more than 3 characters.

Microsoft Word 2007 introduced the Math Ribbon which is also part of OneNote 2010 and PowerPoint 2010. It allows you to enter math formulae by choosing math formulae and symbols from the Math Ribbon. While this works very well and looks great (just like TeX!), it's very slow if you need to enter lots of math. Naturally, it also cannot include all mathmatical symbols due to space constraints. In addition, it is not very well documented at this point in time.

This notation aims to solve these shortcomings. It is fast, intuitive and does not require any special software. It is as language-agnostic as math itself (unlike TeX), so it should be appealing to international users and it similar to writing math by hand where you create math symbols stroke by stroke. Here you compose math symbols character by character and what you see is what you get (so there is no need to compile your source as in TeX). And best of all, you don't need to remember hundreds of commands or leave familiar tools just because you want to enter a few formulas, because you can write any math formulae or symbol using only 13 different "modifiers" right inside of Office 2010.

The documentation that comes with this notation includes general information on how to use the Math facility in Office and more advanced features that I discovered through trial and error, from reading this blog and technical documents about the "linear format" used internally in Math in Office.

How does it work?

It uses Microsoft Office built-in "Math AutoCorrect" facility to replace a sequence of characters with another character or math symbol when you hit the space key (the space key triggers "Math AutoCorrect"). This works just like the familiar AutoCorrect functionality in Office that corrects mistyped words automatically for you. This short hand notation is basically just a modified Math AutoCorrect file which tells Office which combinations of characters to replace.

What do you need to use it?

- Microsoft Office 2010 (specifically OneNote 2010, Word 2010 or PowerPoint 2010)

- The modified Math AutoCorrect file

How do I install it?

AutoCorrect lists are stored in the local Office directory which is %userprofile%\Application Data\Microsoft\Office on Windows XP and %userprofile%\AppData\Roaming\Microsoft\Office on Windows Vista and Windows 7. You can navigate to these directories by copying the corresponding path to the clipboard, hitting Windows key together with the letter r, pasting the path into the text box that appears and pressing the "OK" button. AutoCorrect lists are files of the form mso*.acl, where * is the language ID. The math language ID is 127, so the math AutoCorrect list is mso0127.acl. You need to replace that one with the AutoCorrect list you can download below. I recommend making a backup of your AutoCorrect list because you will lose the default Math AutoCorrect list and all changes you might have made to it when you overwrite it with the file that you can download below.

How do I use it?

The basic principle is to prepend or append so called "modifiers" (characters that have a special meaning) inside a "Math Zone" to characters you would like to be modified. These will be converted to another character as soon as you press the space key (to prevent accidental conversion) and sometimes Office is smart enough that it converts it automatically for you if you enter certain characters (more on that later). You can always undo a conversion by using the "Undo" button or pressing Ctrl+Z. This allows you to "build up" characters on the fly and does not require a lot of memorization. Once you've understood the basic principle of how it works, you can even extend this notation with your own shortcuts.

Math Zones & Modifiers

Math Zones are special text areas that you need to create inside Office to enter math formulae. Math AutoCorrect is only applied to text you enter inside a Math Zone. You can create a Math Zone by choosing "Insert" and then clicking on "Equation" in the ribbon. This will show the Math Ribbon and the text area will look like this: If you enter something there, your math will have a gray background while you caret is inside it. There is also a shortcut for creating a Math Zone quickly by pressing the Alt key and = key at the same time (note: this shortcut might be different on non-US keyboard layouts). Inside these Math Zones, you can prepend or append modifiers that are part of this notation to other characters to change those characters. To get you started, a short introduction to the modifiers follows. There is also an overview of the modifiers on the "Modifiers" page in the documentation. What you need to enter exactly for a certain formula can be found on the other pages in the documentation (what you see in the "Professional" column is what is produced when you enter what you see in the "ASCII" column).

Modifiers for Greek letters, Script letters, Fraktur Letters, Double Struck symbols and Dotted Symbols

Greek letters are entered by appending a question mark to the corresponding Latin letter. So, if you want to enter the Greek beta, you enter b? and press the space key. This will turn b? into β. If you want to enter a capital Greek letter, then you just append the question mark to a capital Latin letter. For example, G? produces Γ. This works similarly for Script letters, Fraktur letters, double struck symbols and dotted symbols. Append the grave symbol to produce a Script Letter, append the tilde symbol to produce a Fraktur letter, append quotation marks to produce double struck symbols and append a dot to produce dotted symbols.

Examples:

S? produces Σ
R` produces ℛ
R~ produces ℜ
R" produces ℝ
|. producess ⋮

See the documentation for a full list of modified letters and dotted symbols.

Modifiers for Math symbols and Compositions

There are several modifiers that turn letters into math symbols, but they are easy to remember like the others. A semicolon turns a letter that looks similar to a math symbol into that math symbol. For example, v; produces ∨, a logical disjunction or c; produces ⊂, a subset. Similarly, a colon rotates a letter to create a mathematical symbol. v: produces ∧ and c: produces ⊃. These symbols can further be composed to variations of these symbols. Appending = to ⊂ produces ⊆ and appending / to that turns it into ⊊. Another example is e? which produces ϵ, the Greek letter epsilon. Append ; to that and you get ∈, and append another / to negate it to ∉.

Examples of commonly used math symbols:
-; produces ¬
.; produces ·
x; produces ×
o; produces ∘
u; produces ∪
u: produces ∩
A: produces ∀
E: produces ∃
8: produces ∞
O/ produces ∅
+− produces ±
=/ produces ≠
-> produces →
<-> produces ⟷
=> produces ⇒
<=> produces ⇔

See the documentation for a full list of math symbols and how to compose them.

Modifiers for Superscripts, Subscripts and Decoration

Usually superscripts are entered in Math in Office by prepending a circumflex ( ) or prepending an underscore ( ) for subscripts. I noticed that these characters are very hard to hit on most keyboard layouts and that this was slowing me down considerably when taking notes during lectures, so I chose to make the apostrophe turn into ^ for superscripts and make a comma turn into _ for subscripts, which are both much easier to hit. The comma is also used to add decoration below an expression and the apostrophe is also used to add decoration above an expression, so this choice is consistent with the idea of superscripts and subscripts being just something that is attached above or below something else. Now you can think of the comma as a command that sends something down and the apostrophe that sends something up when you append it. To make this easier to remember: The comma is at the bottom of the line and sends something down and the apostrophe is at the top of the line and sends something up. A few examples:

x,1 produces x_1 which is turned into x¹ and x'5 produces x^5 which is turned into x⁵ (make sure to press space after comma or apostrophe to turn them to ^ and _ which the Math linear format uses for subscripts and superscripts).

Similarly, you can add decoration to an expression by appending a comma or apostrophe to a character or symbol. A few examples:

x-' puts a bar above the x

x ~' puts a tilde above the x

x->′ puts an arrow above the x

Modifier to enter punctuation, separate strings and prevent other modifers from being applied

Another modifier which is very useful in various contexts is prepending a dot to an expression. A single dot is turned into a "zero width space". This is a space that is invisible. One use is to prevent other modifiers from being applied. For example, I've just described that a comma is turned into an underscore. If want to enter a comma instead, then you would prepend it with a dot like this: .,. Similarly, to prevent a dot from being turned into a zero width space, you prepend it with another dot. So .. produces .. Another example is that if you wanted to enter A:, you would write A.: to prevent the colon from turning the A: into ∀.

The zero widthspace is also very useful if you want to enter expressions that look like strings but what you really mean is a product of single variables or constants which is common convention in math. For example, the circumference c of a circle can be calculated from its diameter d using the formula c = d⋅ π, which can also be written as c=dπ. But entering dp? does not produce dπ because Math AutoCorrect is always applied to entire strings and the string dπ? is not defined in the Math AutoCorrect file. What you really mean in this case is the variable d followed by the constant π and to treat them as separate letters, you need to prepend dot to π to separate π from d. So to enter dπ you need to type d.p?.

Modifier for equation arrays, (augmented) matrixes, vectors, cases, linear combinations and binomial coefficients

To enter any of the multi-line constructs mentioned in the title, you append to other characters or use it by itself. For example, =# creates the an equation array which produces something that looks like a placeholder , but can be expanded line by line by pressing enter (see "How to"). Another common use is followed by the number of rows and (optionally) number of columns, which produces a matrix with the the specified number of rows and columns. For example, to create a 2×3 Matrix, you would enter #23 and to create a 3×1 matrix you just need to specify the number of rows like this: #3. So if you want to enter a 3-dimensional vector, you just need to enter (#3). Similarly, cases are produced by appending # to { followed by the number of rows. For example, {#3 produces a case expression with three rows. Binomial coefficients are either produced by typing (nk#) to use parentheses or <;nk#>; to use wide angle brackets (bra and ket).

See the documentation for a full list of precomposed matrixes, vectors, cases and linear combinations. You can append rows to precomposed multi-line constructs by entering inside of any cell or append extra columns by entering inside of any cell.

Background

This is not a product or extension by Microsoft, I don't work for Microsoft and I didn't get anything to work on this notation. I only created it because I didn't like the status quo and I wanted to quickly enter math into OneNote so I could take notes in real-time during math and computer science lectures. Other students were also interested in this so I thought it might be a good idea to share it, so I joined Microsoft Student Partners and wrote this tutorial among other documentation for this notation. If you find any inconsistencies or something does not work as expected, or have questions that are not answered in this tutorial or the documentation, then please feel free to post in the comments.

This completes this tutorial and should be enough to get you started with this notation. Please check the documentation to see how to create the other mathematical or technical symbols.

Math Accents

MurrayS3 — Mon, 31 Oct 2011 03:26:00 GMT

Accents are quite common in mathematical text. For example, in physics one uses one- to four-dot accents to designate the first through fourth time derivatives, respectively. Primes are often used on integration variables. Transforms can be designated by tildes and averages by overlines. While accents are usually applied to a single base character, they can in principle be applied to any mathematical expression. This differs considerably from natural language accents, which generally apply to a single character. Accordingly no attempt to handle math accents using fully composed characters was made in Unicode even though most accented characters for natural language have managed to sneak into Unicode as fully composed characters. Instead for math accents, one needs a special accent object that sizes the accent to fit the base.

To enter math accents in Microsoft Office applications, you can use the approach described in the Unicode linear format paper. Since Unicode combining marks follow the associated base characters, the linear format accent operators do so too. For example for ä, one would type a\ddot followed by an operator or, if no operator is needed, by two spaces. You can also enter one of the math accent structures on the math ribbon and then fill in the base and accent. The linear format approach is significantly faster, but not as easily discovered.

One thing the linear format paper doesn’t discuss (at least in the current version) is what happens to the dots on i and j. With Unicode, the dots vanish when a combining mark follows. Similarly in the linear format, the dots vanish when an accent operator follows an i or a j. This is kind of handy and is simpler than the method in TeX, which requires use of \imath and \jmath for dotless i and j, respectively.

The question then arises as to whether the dots should vanish when the base is part of a mathematical expression. Should one have

Generally it should be the latter. In PowerPoint 2010 and OneNote 2010, the dot is only removed if the base consists of i or j alone. In Word 2010, the dots are removed even when the base has more than one character. We need to fix this, but fortunately you can force either choice. In fact, the tilde expressions above were both created in Word 2010 (although their images appear blurred here).

To force a dot to appear, enter i\dot or j\dot. So the second tilde expression above can be entered as (\i\dot+\j\dot)\tilde. This works in all three applications. If you want the first tilde expression, you can also get it in all three applications by using \imath and \jmath to get dotless i and dotless j, respectively as in TeX.

Math accents are also discussed in Unicode Technical Report #25, Unicode Support for Mathematics.

Office Insert Symbol Dialog

MurrayS3 — Fri, 30 Sep 2011 05:22:00 GMT

This blog post describes a cool insert-symbol facility built into Office applications like Word, PowerPoint, Excel, and Outlook. The facility is handy for locating mathematical symbols as well as other characters. And with the developments in Unicode these days, that means a lot of symbols! Recently the Unicode Technical Committee and the ISO WG2 Committee accepted the emoji characters popular on Japanese cell phone networks (DoCoMo, KDDI, and SoftBank) and more symbols will be accepted soon. These all add to the many symbols, mathematical and otherwise, that Unicode 5.0 had already offered. The Office math ribbon has a nice selection of Unicode mathematical symbols, but it doesn’t show other kinds of symbols.

In Microsoft Office 2010, you can see many Unicode symbols using Cambria Math and Segoe UI Symbol with the InsertSymbol dialog. Click on the Insert tab followed by the Symbol icon. For some applications, you need to click once more, namely on “More symbols…”. Then you see something like

This example of the dialog lists the Unicode range “Mathematical Operators”, the Unicode name and code of the character selected, “For All”, as well as the shortcut key 2200 alt+x. (It might also be nice to show the autocorrect entry if one exists, e.g., \forall).

Using this facility you can scroll through the characters in any font, just by changing the “Font:” entry. In particular, check out Segoe UI Symbol, which is a great font for symbol characters unless you’re particularly interested in displaying mathematics. You can also scroll through Chinese and Japanese fonts to see what Han Ideographs they have in Plane 2 (U+2xxxx) and on the Basic Multilingual Plane (BMP, which doesn’t mean bitmap in this context!).

This facility is noticably more powerful than the Windows Accessories CharMap applet. That applet can only display characters on the BMP. In particular, it cannot display the Mathematical Alphanumerics (U+1D400..U+1D7FF) that are so handy for mathematical formulas. In contrast, the InsertSymbol dialog can display the Mathematical Alphanumerics and other Plane-1 characters, although it currently doesn’t give their Unicode character names.

Sans Serif Mathematical Symbols

MurrayS3 — Mon, 29 Aug 2011 18:30:00 GMT

Most mathematical documents and books use fonts with serifs, such as Times Roman. However mathematical expressions can also be displayed with sans-serif letters, such as the font this post uses. In fact, sans-serif letters are used sufficiently often in mathematical typography that six sets of them are included in the Unicode Mathematical Alphanumeric Symbols. Further rationale for these Unicode symbols is given in Section 2.2 of Unicode Technical Report #25, Unicode Support for Mathematics. People have asked how to use sans-serif variables in Microsoft Office math zones. The way to do this isn’t as simple as toggling italic on and off using the italic tool or the ctrl+i hot key. But this posts shows that it can be done.

One way any character can be entered into Word or OneNote (but not into PowerPoint, sigh) is to type the Unicode value of the character followed by the alt+x hot key as described in the post. The 52-character sans-serif upright alphabet starts at Unicode U+1D5A0, which is upper-case A. To enter A, type 1D5A0 alt+x. The lower-case letters follow the upper-case letters, so the lower-case a has the code U+1D5BA. This can be entered by typing 1D5BA alt+x. The 52-character sans-serif bold, italic, and bold-italic sets follow the upright set and start at U+1D5D4, U+1D608, and U+1D63C, respectively. In addition there are bold and bold-italic Greek sets, which start at U+1D756 and U+1D790, respectively.

Entering symbols using alt+x is useful, but if you want to enter lots of symbols, it’s not very convenient. Clearly it would be nice to have a sans-serif button on the math ribbon to toggle between sans serif and serif letters. In this connection, it would also be handy to have bold and italic buttons on the math ribbon, but currently they’re only available on the Home ribbon. Another way to enter sans-serif letters does exist: add the letters you need to math autocorrect.

To add an AutoCorrect entry for any Unicode character, go to the AutoCorrect dialog (the math AutoCorrect dialog for entries into math zones), and in the Replace text box type the AutoCorrect name you want to use and in the With text box type the Unicode hex code of the desired character followed by alt+x. The method works the same way as using alt+x directly in the document, except that you assign a simple string to enter the character instead of entering the character into the document. For example, you could assign the string “\A” to enter U+1D5A0, that is, to enter upper-case sans-serif A. It doesn’t take long to add such strings for all 52 letters in a sans-serif alphabet. (The reason this works for entering math autocorrect symbols is because the text boxes are RichEdit controls, which support alt+x). You can add math autocorrect entries using any Office application that supports math zones and the entries are shared by all Office applications.

If sans-serif italic letters are what you need the most, you might want to use “\A”, etc., for them and use some longer name for the upright characters, such as “\uA”. Note that once you’ve entered a sans-serif letter, you can change its bold and italic properties by selecting the character and using the bold and italic hot keys and buttons.

Rendering MathML in HTML5

MurrayS3 — Sun, 31 Jul 2011 14:53:00 GMT

As you can see in this document, Presentation MathML is part of HTML5. This is very exciting, since HTML5 is becoming the primary new web standard format. You might think that this would automatically make it easy to render MathML in a browser. In fact, FireFox does a decent job of rendering MathML, having incorporated MathML into its HTML renderer quite a few years ago. WebKit used by Safari and some other browsers also has recently added support for MathML. The present post points out some of the things one needs to do to render MathML using the Microsoft Office display engines (LineServices and Page/TableServices). The form needed for these engines is closely represented by OMML in file formats. To convert MathML to this form, more has to be done than simple parsing of a MathML tree.

Many MathML constructs map nicely onto the LineServices model. For example, the elements <mfrac>, <msqrt>, <mroot>, <mfenced>, <menclose>, <msub>, <msup>, <msubsup>, <munder>, and <mover> all map directly to counterparts in the LineServices model. Some others map with minor manipulation, such as <munderover>, <mmultiscripts>, <mphantom>, and <mpadded>. The element <mtable> typically maps well onto the LineServices matrix object, although advanced cases of <mtable> are beyond the scope of the matrix object.

Integrals and n-ary objects have a more complicated relationship and need some processing to convert. MathML doesn’t have a single element for these objects, using various combinations of <msub>, <msup>, <msubsup>, <munder>, <mover> and <munderover> to do the job. In contrast, OMML has the element <nary>, which takes three subelements: the lower limit, upper limit and n-aryand, e.g., integrand or summand. The <nary> element is quite convenient, since you can change the number of limits and the limit placements using element properties instead of having to manipulate the corresponding MathML tree. To convert to <nary> from the various combinations of MathML elements, you need to recognize that an n-ary object is being represented by those combinations. A key part of this recognition is to note that one of the operators in a combination is a Unicode n-ary operator and then to interpret the surrounding subscripts and superscripts (or over/under elements) as limits.

Furthermore, delimited expressions can be represented just using operator <mo> elements surrounding text elements, with no clue that a delimited expression is involved except for the semantics of the delimiter operator characters. For example a parenthesized expression can be written in MathML as <mo>(</mo>content<mo>)</mo>.

Similarly a MathML linear fraction doesn’t use <mfrac> with a “linear”property (as in the LineServices model). Instead the linear fraction is represented by <mrow> numerator <mo>/</mo> denominator </mrow>. To convert this to the <f> object for LineServices, one has to carry out significant parsing.

In some ways the pattern recognition needed to convert Presentation MathML for use with LineServices is akin to that needed to convert the Unicode linear format for math for use with LineServices. In the Microsoft Office implementations of the linear-format and MathML converters, a subset of Version 2 of the TOM interfaces is used. A rich-text string stack is employed for converting infix expressions into the prefix form required by the rendering technology. This is similar to the code one might write to implement a scientific calculator. The human being prefers infix notation like a + b, while the calculator wants the operator first as in +ab, as in the old HP Polish-prefix calculators.

The bottom line is that complex parsing is needed to convert Presentation MathML into a form usable by math display engines such as those in Microsoft Office.

Math Keyboard Shortcuts

MurrayS3 — Tue, 21 Jun 2011 23:04:00 GMT

Nali commented on the post Office 2007 Math Editing/Display that it would be nice to have keyboard hot keys to switch between Professional and Linear format (build up/down), and between Display and Inline mode of equations. This is a great idea especially for those of us who like to use keyboards to speed up math entry. The present post mentions the main alt+= hot key for toggling math zones on and off and then considers other possible hot keys for math.

To insert a math zone at the insertion point, type alt+=. If the selection is nondegenerate (highlights one or more characters), alt+= toggles a math zone on and off. This hot key first shipped with Word 2007 and it also works in Office 2010 applications and Mac Word 2011 (type control+=, since the Mac doesn’t have an alt key). In some locales, the hot key may be different, but since most keyboards have an equal sign, alt+= is pretty general.

To maintain this international generality, we could use ctrl+alt+= to build a (Professional) math zone down to the linear format and shift+ctrl+alt+= to build a math zone up from the linear format. The alt+= hot key typically requires the use of both hands, so including ctrl and shift+ctrl is reasonably natural, especially if you’re a pianistJ.

It seems worthwhile to support Word’s standard subscript and superscript hot keys: ctrl+= and shift+ctrl+=, respectively. These hot keys toggle their respective states. For example, if you type some text, ctrl+=, and some more text, the latter will be subscripted up until you type ctrl+= again to go back on line. If you type one of these hot keys while some text is selected, that text’s script character will be toggled accordingly. In the linear format, subscripts and superscripts are usually entered with the _ and ^ operators as in [La]TeX or via the ribbon. But the standard hot keys can be handy too provided the scripts are not nested.

Word math zones are displayed inside an acetate enclosure that has a drop-down menu with Professional, Linear, Display/Inline, and Justification options. So you might wonder how Word converts from Display to Inline and vice versa. The essential feature is that if a math zone completely fills a hard or soft paragraph, it is shown in Display mode and is a display math zone. If one or more characters appear in the paragraph but not in the math zone, the math zone is displayed in Inline mode and is an inline math zone. To convert a display math zone to an inline math zone, Word inserts a space directly following the math zone. To convert an inline math zone to a display math zone, Word deletes the space for the previous case. More generally, Word inserts a carriage return before and/or after the math zone, depending on how much is needed to obtain a math zone that completely fills its paragraph.

It’s pretty easy to convert between inline and display modes on the keyboard using the space bar and the enter key as necessary. So maybe we don’t need a hot key for it. But if we do, shift+alt+= is currently undefined. Using that along with the others above would define all combinations of ctrl, shift, alt and = that don’t distinguish between left and right control/shift/alt keys. The fact that they all involve the equal sign suggests they are math hot keys and makes them easier to remember.

Other hot keys that are handy in math zones include the home/end and arrow keys. In some applications, the [shift+]tab moves between elements in a matrix. The [shift+]tab key is also used to change the indentation of manual line breaks. In my old PS Technical Word Processor, hot keys were used to enter Greek and math symbols. For example, alt+a inserted α. But TeX’s symbol notation is generally so easy to use, it doesn’t seem necessary to have hot keys for symbols. If you use α a lot, you might want to add the autocorrect entry \a for α, which is certainly faster than typing \alpha. Hopefully at some point, I’ll add autocomplete to the math autocorrect facility and then the difference between typing \a and \alpha will be even smaller.

alt+x is another useful hot key that toggles between a character and its Unicode hexadecimal value. In fact, I entered the α’s here by typing 3b1 alt+x. Admittedly to use this approach, you have to be a bit of a Unicode geek.

NINCH and EMU

MurrayS3 — Sat, 07 May 2011 22:09:00 GMT

People have been asking about a couple of acronyms fairly often these days, so here’s a blog post on them. They are described on the web already if you type the right queries, but a little more motivation might be useful. The acronyms are NINCH for “no input no change” and EMU for “English Metric Unit”, not the large Australian flightness bird so popular in crossword puzzles.

NINCH

Some programming object models, such as RichEdit’s TOM and Word’s Object Model, have formatting objects that you can apply to a range of text. These objects, such as the TOM ITextFont, work in two distinct modes: immediate and acquire. In the immediate mode, a specific property is applied to the associated range of text. For example in Visual Basic notation, r.font.bold = tomTrue sets the text in the range r to bold. In this mode, only a single property is changed; all other properties remain unchanged.

In the acquire mode, the programmer gets a “duplicate” formatting object that isn’t associated with a range or even a text story and sets values for whatever properties need to be changed. Setting the properties is very fast, since they are not yet being applied to text. When all the desired properties are set, the programmer can apply the object to a range of text all in one fell swoop. In effect, the object is a specialized “format painter”, if you’re familiar with the little paint-brush icon on the Word Home ribbon. In this format-painter mode, the properties that should not be altered need to have a special value to convey this fact. The value is the NINCH value, meaning “no input no change”. It’s called tomUndefined in TOM and wdUndefined in Word, and it works with longs, floats, and COLOREFs. For strings, such as the font name, NINCH is represented by the null string.

A related value is needed when properties for a range are retrieved using the formatting object. Specifically if the characters in the range do not all have the same value of a property, the value returned should indicate ambiguity. Such a value is useful for displaying a grayed check box or empty field in property dialogs. The term tomUndefined sort of makes sense, whereas NINCH really doesn’t since no input is involved. Maybe tomAmbiguous would be a reasonable name. In practice, we just use the tomUndefined (or wdUndefined) value and interpret it appropriately on set and get operations. In addition, TOM and Word can toggle simple binary properties by setting them equal to tomToggle and wdToggle, respectively. As such a binary property like bold can be set with four possible values: tomTrue, tomFalse, tomUndefined, and tomToggle (or True, False, wdUndefined, wdToggle for Word). To distinguish such values from ordinary booleans, we call their type “tomBool”. By the way, technically bold is not a binary property: fonts may one or more weights. But for years people have concentrated on two: normal and bold.

EMU

Back in 1959, one of the greatest years for Bordeaux wines, the three nearly equal definitions of the inch became standardized so that the inch equals exactly 2.54 centimeters. The centimeter itself was still defined as one hundredth the length of a special meter long bar until 1983. At that time, the meter was redefined very slightly to be the distance light travels in vacuum in 1/299,792,458 of a second. Advances in physics had allowed people to measure time far more accurately than distance, but I digress. The choice of 2.54 cm/in allows one to define a length unit that is equally at home with both English and metric units: the EMU. There are 914400 EMUs per inch. Note the 1440 in the middle of 914400. You may recognize 1440 as the number of twips/inch, where a twip is 1/20 of a point and a point is 1/72 of an inch. And sure enough there are exactly 914400/1440 = 635 EMUs in a twip and 914400/2.54 = 360000 EMUs in a centimeter. This gives lots of resolution to describe paper sizes around the world accurately and still to be usable with 32-bit integers (4294967296/360000 ≅ 11,930 cm).

It’s nice to have word processing software that lays out a page without depending on the printer or screen resolution and the EMU is handy for that purpose. Another popular unit is the floating-point point, since font heights are usually given in points, single-precision floating-point arithmetic offers reasonably high resolution, and today’s computers are facile with floating point arithmetic. And for what it’s worth an Australian emu may very well be 65,620,800 EMUs in height (6 feet).

Two Math Typography Niceties

MurrayS3 — Sat, 30 Apr 2011 15:05:00 GMT

Roughly eight years ago, some colleagues and I had the good fortune to spend an extraordinary afternoon with Donald Knuth, the primary author of TeX, at his home on the Stanford University campus. Among many things, Donald showed us how he uses TeX to typeset his computer-science papers and books exactly the way he wants them to look. In particular, he applies special tweaks to achieve perfection, such as “smashing the descender” on one radicand to make a sum of square roots line up in a pleasing way, and such as shimming characters to place them more beautifully in a formula.

The present post illustrates a couple typographical niceties that Knuth might add to his documents. At the outset I need to warn the reader that such “tweaking” is a fine art. Knuth mentioned that he could recognize some authors by the way they tweak their TeX documents. Furthermore many TeXies don’t understand the technique that well. Barbara Beeton of the American Mathematical Society (AMS) and a key person in having the AMS adopt TeX told me that the AMS has to delete most user tweaking before publication because it doesn’t meet AMS standards. With that caveat emptor, here are two examples.

A favorite equation of mine is the mode locking equation

I wrote several papers and two book sections showing how this equation describes mode locking phenomena in coupled clocks, coupled oscillators in general, and lasers in particular. Looking at it, you can see that there’s a little too much room between the 2π and the integrand. You can pull the integrand to the left under the π by “smashing” its width. Inside the upper limit, you type \hsmash \pi , and the displays, but has no horizontal width as in

Doesn’t that look better? We thought about automating such refinements, but if we had, we wouldn’t have had enough time to ship Word 2007, so we left it to the user (as did Knuth).

The example Knuth showed us is adding the square root of x to the square root of y. If you just use the default layout in TeX (or Microsoft Office), you get

As you see, the square root of the y is a bigger than that of the x, since the y has a descender. But it would look better if we “smashed” the y’s descender (type \sqrt\dsmash y ) so that both square roots have the same size We also thought about automating such smashing, but the general case doesn’t appear to be described by a simple algorithm. Tweaking is an art! Hopefully you don’t need to tweak that often.

(As you see here, I still haven't been able to make technical documents display in this blog the elegant way they display in Word. Some day, hopefully!)

Equation Arrays

MurrayS3 — Wed, 30 Mar 2011 21:23:00 GMT

One user (Leperkawn) commented "There is basically no documentation on the \eqarray command so I'll post a quick example that I had to figure out from trial and error." Before looking at his interesting example, here's the text in Section 3.19 of the linear format paper describing how to type in equation arrays:

To align one equation relative to another vertically, one can use an equation array, such as

which has the linear format █(10&x+&3&y=2@3&x+&13&y=4), where █ is U+2588. This character can be entered by typing \eqarray. Here the meaning of the ampersands alternate between align and spacer, with an implied spacer at the start of the line. So every odd & is an alignment point and every even & is a place where space may be added to align the equations. This convention is used in AmSTeX.

To make this a little easier to understand, we can highlight the align ampersands red and the spacers green. Then the linear format of equation above looks like

█(10&x+&3&y=2@3&x+&13&y=4

You can also use the equation array to format the "cases" construct, such as

which has the linear format "|x| = {█ (&x" if "x ≥ 0@-&x" if "x < 0)┤" Here the two &'s align the leading x's.

Highlighting the aligns in red and the spacers in green, Leperkawn's example is (note: line breaks after the @'s are included only for readability; they should not be used inside equation arrays)

█(Z-3x_1&-5&x_2&-6&x_3&&&&=&0 @

2x_1&+&x_2&+&x_3&+x_4&&&=&4 @

x_1&+2&x_2&+&x_3&+&x_5&&=&4 @

x_1&+&x_2&+2&x_3&+&&x_6&=&4 @

x_1&+&x_2&+&x_3&+&&&x_7=&3)

This displays as

It's pretty nicely aligned, but note that the first x_3 is a little to the right of the subsequent ones. A choice that aligns them accurately puts an align & immediately before each of the first three variables in each equation and puts the corresponding spacer after, rather than before, the binary operator that follows. This is the pattern used in the first example above. The linear format becomes

█(Z-3&x_1-&5&x_2-&6&x_3&&&=&0 @

2&x_1+&&x_2+&&x_3+x_4&&&=&4 @

&x_1+&2&x_2+&&x_3+&x_5&&=&4 @

&x_1+&&x_2+&2&x_3+&&x_6&=&4 @

&x_1+&&x_2+&&x_3+&&&x_7=&3)

which builds up to

Now all the variables are aligned correctly.

Plain Text Math in Bidirectional Contexts

MurrayS3 — Mon, 28 Feb 2011 21:27:00 GMT

In plain text, bidirectional text (text including some Arabic or Hebrew) is generally displayed according to the Unicode Bidi Algorithm (UBA). Since we’re interested in math, it’s pertinent to study a bit how simple mathematical expressions appear according to the UBA. Ideally math is displayed using higher-order protocols that overrule the UBA appropriately, but in this post let’s consider only very simple overrides that fix balanced parentheses, brackets and braces. An earlier post presents such an algorithm, which makes some mathematical expressions look reasonable in contrast to how they look with the UBA. The present post compares results using that algorithm with one that’s slightly different and yields better results. Mathematical text should be formatted according to rules for math zones. But plain text is still very common, so it’s useful to know how to make it do a better job at displaying simple formulae.

First some background Bidi stuff (skip this and the next paragraph if you already know the UBA). Bidi text runs are assigned a Bidi level, 0, 1, 2, … The even levels are displayed left-to-right (LTR) and the odd levels are displayed right-to-left (RTL). The Arabic and Hebrew scripts are displayed RTL and almost all other scripts are displayed LTR. The one major exception is that numbers are always displayed LTR even if they use Arabic-Indic digits like ١٢٣ (123). A consequence of this exception is that even pure Hebrew text and pure Arabic text are Bidirectional (have both LTR and RTL text runs) if they contain numbers.

The complexity of the UBA enters in the handling of so-called neutral characters of various kinds, e.g., punctuation including parentheses, brackets, and braces, along with the overall placement of numbers. In a pure math zone, all such neutrals (except for period, comma, and space) have the directionality of the math zone itself. But outside math zones, the rules are given by the UBA and are considerably more complicated. The reason this statement applies to pure math zones is that “impure” math zones contain one or more runs of embedded normal text that typically follow the rules of the UBA.

Okay, so here’s the first UBA surprise: an LTR paragraph consisting of “a(b)” displays this text as such, but alone in an RTL paragraph it displays as “(a(b”. This is because in the RTL paragraph (base level 1) the opening parenthesis is between two strong LTR characters and accordingly all three are assigned the level 2 to force them to be display LTR. But the closing parenthesis is between the “b” and the end-of-paragraph mark and the UBA assigns the directionality of the paragraph (1) to that parenthesis and therefore that it be mirrored and placed to the left. Clearly this isn’t what you want.

What does the parentheses algorithm do? It displays the text as “(b)a” when alone in an RTL paragraph. This is actually exactly how it would be displayed in an RTL math zone. But more involved expressions don’t share the same fortune. Consider the LTR “f(x)+g(y)”. In an RTL math zone, this should be displayed as “(y)g+(x)f”, i.e., right to left. The UBA displays it as “(f(x)+g(y” and the parentheses algorithm displays it as “(y)f(x)+g”. Similarly alone in an RTL paragraph the LTR expression “f(x)g(y)” displays as “(f(x)g(y” according to the UBA and “(y)f(x)g” according to the parentheses algorithm. The UBA is clearly suboptimal in all cases, but although the parentheses algorithm does display parentheses as you would expect, it doesn’t succeed in a reasonable ordering of the text units.

To see if we can improve this situation, let’s modify the parentheses algorithm in a way proposed by Windows developer Robert Steen. The original algorithm sets the parentheses pair level equal to the smaller of the two parenthesis levels and then increments that level if the level doesn’t have the same directionality as the paragraph (or more generally, the current embedding). Instead, Robert chooses the larger of the two parenthesis levels for the pair. In both choices, if characters inside the parentheses have a level less than that of the pair, the levels of those characters are incremented by 2 to keep the characters inside the parentheses and to keep their same directionality.

According to this modified algorithm, the LTR “f(x)+g(y)” displays the same way alone in an RTL paragraph. Okay, this isn’t the way it should display in an RTL math zone, but at least it’s readable and understandable. Ditto for “f(x)g(y)”. Let’s check it out using Arabic variables.

Alone in an LTR paragraph the logically ordered “ف(ق)+ك(ل)” displays according to the UBA as “ل)ك+(ق)ف)”. Alone in an RTL paragraph it displays as “(ل)ك+(ق)ف”, which is how it displays in an RTL math zone.

According to the parentheses algorithm alone in an LTR paragraph, “ف(ق)+ك(ل)”displays as “ك+(ق)ف(ل)”, which isn’t what you want. Alone in an RTL paragraph it displays as “(ل)ك+(ق)ف”, which is also the way it displays in an RTL math zone.

According to the modified parentheses algorithm alone in an LTR or RTL paragraph, “ف(ق)+ك(ل)” displays as “(ل)ك+(ق)ف”, the way it displays in an RTL math zone. So with this algorithm, simple math expressions using either all LTR variables or all RTL variables display with the directionality of the variables in paragraphs of either directionality. This seems to be a better plain-text compromise for mathematics.

Check out Live Writer

MurrayS3 — Sat, 01 Jan 2011 19:13:00 GMT

This is a test to see how I can use Live Writer to make blog posts more nicely. In particular, it’s desirable to display equations by copying them from Word. For example, this is the mode locking formula

which you can enter by typing \integral<space> in a math zone. In PowerPoint 2010, it builds up automatically, but in Word 2010, you need to choose the Professional option from the context menu or from the acetate box dropdown.

This is the Pythagorean Theorem displayed inline: . Note that the inline formula is not aligned quite right with the text base line. I used vertical-align: bottom. Does anyone know of a CSS attribute that can align it properly? The image has to have a text baseline spacing.

MathML To-Do List

MurrayS3 — Fri, 31 Dec 2010 22:54:00 GMT

In my MathML 3.0 post, I noted that several things were postponed for future consideration. The present post lists math document properties and equation numbers. Other members of the MathML Working Group can undoubtedly add to the list.

Default Document Math Properties

A number of math display properties have document defaults. They are the ones used if explicit attributes do not appear. The properties generally 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, for example, it is common to see integral limits below and above the integral, while in the United States integral limits are displayed as subscript and superscript. MathML does not formalize document defaults for math, but MathML math zones can inherit them depending on the implementation. Therefore, such defaults are compatible with MathML and currently need to be expressed in some way outside of MathML.

The feeling of the MathML 3.0 working group is that these concepts belong to the document container in which the MathML <math> elements reside. However, presumably the MathML specification should list math document properties along with recommendations for default values, since they’re important and no other W3C group offers such information. An example of a current problem is that one browser currently left aligns equations by default, whereas the common convention is to center equations. An earlier blog post gives a detailed discussion of math document properties.

A possible syntax would be to express default math properties as new attributes in a leading, empty MathML <math> element. In principle, this could work today, since MathML allows undefined attributes to be added with the caveat to ignore them if you do not know what they mean. The following table gives math document properties with default values for the United States listed first and possible attributes for use with the MathML <math> element. The values listed are the same as for the OMML <mathPr> element.

Parameter	Values	Attribute
Math font	Cambria Math, STIX	mathFont
Equation alignment (justification)	Center as a group, left, right, center	defJc
Display n-ary limit placement	Over/under, subscript/superscript	naryLim
Display integral limit placement	Subscript/superscript, over/under	intLim
Break on operator	Before, after, duplicate	brkBin
Break on - duplicate	--, -+, +-	brkBinSub
Reduce nested-fraction size	Current text size, up 1 script level	smallFrac
Use math display spacings	True (false: use para spacings)	dispDef
Display left margin indent	0	lMargin
Display right margin indent	0	rMargin
Display left margin wrapped indent	1"	wrapIndent
Right align wrapped display equations	false	wrapRight
Space before set of equations	0	preSp
Space after set of equations	0	postSp
Intraequation spacing between lines in an equation	0	intraSp
Spacing between equations	0	interSp
Style for differential d and related characters (U+2145..U+2149)	Math italic, upright, open slant	ddStyle
What to display for invisible times (U+2063) if line break occurs at invisible times	× (U+00D7)	visiTimes
Equation number alignment (justification)	right, left	eqnoJc

Equation Numbering

The current number one feature request for Microsoft Office math is native equation numbering. Clearly, equation numbering is a very important part of technical documents and should be part of a math specification like MathML. Hang ups in implementing equation numbers seem to be that people want all the generality of section numbering and want a user interface consistent with other numbering features. Such wants are not trivial to implement.

One approach that handles the vast majority of cases would be to use a <math> element with an “eqno” attribute. The content of the <math> element could include a <semantics> tag that has both what a basic Presentation MathML renderer would display along with an <annotation> element containing what the parent application would display. Attributes could be included to specify that section/chapter numbers should appear as prefixes, etc. CSS could also be useful in such specifications.

By default the equation number would be right aligned relative to the display <math> element that precedes it. Additional attributes could specify other alignments, such as left-aligned and/or vertically centered relative to a consecutive set of equations (display <math> elements). A reference to an equation number could be inline empty <math> element with the same eqno attribute.

This approach to equation numbering is similar to the one described in an earlier post. There an equation (display <math> element) contains a simple unused construct (noop phantom) instead of an eqno attribute, since OMML is not as friendly toward undefined attributes as MathML is.

Mac Word 2011 and Math

MurrayS3 — Mon, 22 Nov 2010 21:31:00 GMT

Office for Mac 2011 has many cool additions. The best of them all (well you know my bias!) is that Mac Word 2011 has the elegant Office math editing and display facility! Although I do not own a Mac, my next-door neighbor Dylan Tom does and we gave the math facility a check out run. Dylan goes to the Lakeside School well known for its famous computer-oriented alumni.

Mac Word 2011 has the math ribbon, which one might expect since the Office for Mac 2011 applications all have their standard ribbons. The math options button is missing, but the options are available in the Preferences dialog (Word menu, Preferences menu item, Math Options button, or Cmd+,). To enter a math zone, type control+=, which plays the role of alt+= on the PC. The "center-as-a-group" default alignment leaves the equations left aligned, but you can use the acetate dropdown at the right side of the math zone to center equations. You can also use that dropdown to align multiple equations in a math paragraph at their equal signs.

The math facility has the formula autobuildup and build-down methods. For these, the Office for Mac team ported over the parts of RichEdit that are responsible for the methods. Accordingly, the methods use the same linear format as on the PC. The facility has the Word math context menus, which you get by typing control+click, which plays the role of the PC's right click. For example, you can use a context menu to insert a manual break on an operator. The tab-key option to shift the manual break over under an operator on the first line of the equation is not yet implemented.

Both summations and integrals are displayed by default with subscript and superscript limits in display mode, whereas on the PC, only integrals are displayed that way by default. You can use a context menu to change the location of the limits for both integrals and n-ary operators as on the PC.

To enter a character using its Unicode value, Mac Word works differently than PC Word. Select the Unicode Hex Input keyboard, hold the Option key down and type in a four-hexadigit code. Releasing the Option key inserts the corresponding Unicode character. This works in general on the Mac, whereas PC Word's alt+x input method currently only works in Word and RichEdit. You can insert a variety of special characters directly using the Option key, including some handy math characters like √, ∫, and ∑, in case you don't want to type \sqrt, \int, and \sum, respectively. PC Word's alt+x Unicode input method is more flexible since it allows you to edit the code, insert higher-plane characters (like math italic and fraktur) and do the inverse: replace a character by its Unicode value.

It would be nice if Apple generalized the Option code entry to allow five hexadigits to be read as a UTF-32 value, since that is the way the characters are referenced in the Unicode Standard. Then if you held down the Option key, typed 1D509 and released the Option key, you would see a math fraktur F. Alternatively, you can type \frakturF. With the Mac Unicode Hex Input keyboard, you can enter this character with its UTF-16 representation as Option+D835DD09.

The great news is that the lion's share of the Office math features are up and running in Mac Word 2011 and make upgrading well worthwhile even if you don't need all the other Mac Word 2010 cool additions.

Posted from 36,000 feet thanks to free GoGo Inflight Internet!

MathML 3.0

MurrayS3 — Thu, 28 Oct 2010 20:23:55 GMT

The W3C announced October 21, 2010 that the MathML 3.0 specification is a W3C Recommendation. This post describes some of the features added to MathML in version 3.0. The specification also includes numerous clarifications that are helpful for people wanting to implement MathML 3.0. The specification’s introductory section “Status of this Document” concludes with a summary of the features.

Improved Unicode Alignment

In February 2001 when the “first edition” of MathML 2.0 became a W3C Recommendation, Unicode/ISO 10646 was still officially missing many math symbols. Unicode 3.1 (May, 2001) added the Unicode math alphanumerics (U+1D400.U+1D7FF) and the differential-d set (U+2145..U+2149). Unicode 3.2 (March, 2002) added the lion’s share of remaining math symbols in the STIX set, including the arrows and math operators in the range U+2900..U+2AFF. The “second and current edition” of MathML 2.0 was released in October 2003 partly to re-align with Unicode and to include math character blocks instead of private use area code points. The operator dictionary did not include Unicode code points.

MathML 3.0 is fully aligned with Unicode 6.0+. In addition to the discussions of the Unicode math character sets in Chapter 15 of The Unicode Standard, Unicode Technical Report #25, and Unicode Technical Note #28, MathML 3.0 adds a thoroughly revamped math operator dictionary featuring Unicode and giving basic operator properties. Complementing this is the new W3C Recommendation XML Entity Definitions for Characters, which incorporates all standard entities used for mathematics. In particular, Section 3 of this document features Unicode blocks of characters that you can mouse over to see relevant math properties. Each character is displayed twice, once with a STIX font and once with a png.

Right-to-Left Math

The earlier posts Tailoring the Unicode Bidi Algorithm and Directionality in Math Zones discuss right-to-left (RtL) math and give useful references for further study, notably Arabic mathematical notation. MathML 3.0 includes full support for RtL math zones, including a directionality attribute, dir, which can appear on most elements. If the dir attribute does not appear, the directionality of the <math> element and children is inherited from the current Bidi embedding. Adil Allawi of Diwan Software Limited notes (in a private communication) that the right-to-left features of MathML 3.0 make “it possible, for the first time, to build standards-based and truly interoperable electronic maths books for students in the Arab countries."

Elementary math

People write long division and multiplication in various ways around the world. Particularly for educational purposes, it is desirable to have an interchangeable format to represent such conventions on the web and in other electronic media. Accordingly, MathML 3.0 defines elements to handle many such conventions. The facility allows special alignments as well as borrow/carry annotations.

Accessibility

MathML is supported by various accessibility tools and has been incorporated into the DAISY Standard. Adding MathML 3.0’s elementary math capabilities widens the range for accessible math.

CSS for math

In a companion specification, a subset of MathML 3.0 is described that can be rendered with CSS. This allows browsers that do not have sophisticated math layout engines to display many mathematical formulas.

Line breaking

MathML 3.0 includes a very rich set of attributes. Office 2010 implements a subset that handles the most common scenarios, including options to display duplicated operator as ++, +-, --, but it is not nearly as general. For example, MathML 3.0 allows breaking at an arbitrary character position with a wealth of possible indents/alignments for the wrapped line(s).

href's everywhere

You can put an href (hyperlink) attribute on most any element in MathML 3.0. This makes it easy, for example, to provide links on a fraction numerator or denominator. Such links can aid the teaching of mathematics as well as to define the meanings of expressions.

Padding

The <mpadded> element has been generalized and clarified. This can be useful for tweaking the positioning of arguments for printing. Caveat emptor: since math layout engines often differ in their spacing choices, tweaking for one engine may spoil the spacing for another engine. The elements <mglyph> and <maction> are also motivated and described more thoroughly.

Content MathML

A substantial effort has gone into improving Content MathML, notably in allowing a rigorous correspondence to OpenMath with its content dictionaries. This work is valuable for symbolic and numerical computations.

Mixing Markup

One reason Microsoft Office went with its own “Office MathML”, that is, OMML, was to be able to combine a math XML with parent namespaces, such as WordProcessingML. MathML 3.0 has generalized the <semantics> element and clarified various scenarios to make such mixing of namespaces more convenient.

What’s not yet done

A number of things were postponed for future consideration. Document math defaults have not been specified. These include the default math font, equation alignment(s), space before/after, breaking conventions, n-ary/integral limit placements, all of which are specified in the OMML <mathPr> element. The power of the OMML math paragraph is also missing, although to some degree it can be emulated by the <mtable> element. Equation numbering is not represented, nor is it in OMML. The feeling of the MathML working group is that these concepts belong to the document container in which the MathML <math> elements reside. However, I think that some discussion should be given to lend a degree of interoperability to these concepts, which are clearly very important for the electronic representation of mathematical text. An example of the problem is that one browser currently left aligns equations by default, whereas the common convention is to center equations.

What becomes of WG?

When the MathML 2.0 Working Group finished the MathML 2.0 specification, the group dissolved. It took some time to put it back together for MathML 3.0. Therefore, the plan for the future is to keep the group active with no specific agenda other than to maintain the spec, answer questions, and dream about the future. Something as complex and important as MathML needs a live pool of expertise.

See also Neil Soiffer’s blog about MathML 3.0.

Nathan Myhrvold

MurrayS3 — Tue, 28 Sep 2010 23:27:00 GMT

This is a post about some of the early days in the life of an amazing person, Nathan Myhrvold. Nathan and his good friend and colleague, Chuck Whitmer, had completed PhD’s in theoretical physics at Princeton. They wanted to investigate advanced behaviors in a field called deterministic chaos. This field deals with how dynamical systems can be extraordinarily dependent on small variations in initial conditions. To pursue these studies, Nathan and Chuck felt they needed a more powerful computer operating system and to this end they started the company Dynamical Systems in 1984. They gathered together a bunch of very smart guys, including some other physicists, and occupied the loft of a building in Oakland, CA. There they had a ring of souped up IBM AT PC’s. The usual speed for the IBM AT at that time was 6 MHz, but Nathan and Chuck found they could run up the clocks to a screaming 8 or even 9 MHz! This is an early example of how Nathan loved and continues to love to push the envelope.

The DS team developed a multitasking operating system on top of DOS called Panorama (later on, Mondrian) that ran 16 processes way faster than IBM’s Top View system could run two processes even though Panorama used only 64 K RAM while Top View used 400 K. Tiny numbers by today’s standards, but you have to remember that there was only 640 K available in DOS.

To develop such a system Nathan needed powerful debugging facilities and noticed me demoing my SST debugger at the computer mecca show, Comdex. Perhaps intrigued that SST could execute backward as well as forward, he bought three copies. Physicists are intrigued by time reversal. Then every week or so he’d call up and ask for a new feature to facilitate debugging. Often the features weren’t too hard, for example, one week he wanted a built-in assembler in addition to the disassembler. So I’d implement the features and send up new copies. Then one day he called and said calmly that 640 K RAM wasn’t enough for running multiple serious applications and wanted me to add protected mode support to SST. This wasn’t nearly so easy, but I got intrigued and implemented his request.

Meanwhile Steve Ballmer got interested with what Nathan & Co were doing and decided to acquire Dynamical Systems, partly as a bargaining chip to use in negotiating with the ever demanding IBM. Soon thereafter Nathan arranged to have me come up to Microsoft to improve the Microsoft CodeView debugger using SST technology. In the process, another Dynamical Systems physicist David Weise and I used SST to get Windows into protected mode, blowing away the 640K DOS RAM barrier and ultimately IBM’s OS/2 operating system as well. So you see Windows dominance was crucially dependent on Nathan dreaming a few of his big dreams.

At Microsoft, Nathan did many things, but probably his proudest achievement was convincing Bill and Steve to support research and then to develop Microsoft Research. He hired many very talented folks, such as the current and long time director of MSR, Rick Rashid. While Nathan ran MSR, he wrote insightful memos every month or so, predicting the course of computing. Many of his predictions have come true over time and even seem to be self-evident now, however controversial at the time. For example during the big debate we had in switching to Unicode, which used 16 bits for characters instead of 8, he pointed out that the size of the text in files was typically negligible compared to the size of associated properties and embedded objects. That observation helped a lot in steering Microsoft to the right approach, years before the competition caught on. Nathan started Windows Mobile and I can’t help but think that if Nathan had stayed interested in the area, especially in view of his stimulating ideas about interactive TV, that Microsoft would have had iPhone pizzazz before Apple. One of his predictions remains to be fulfilled: he wrote that he could not be sure what the form of the most intelligent being on earth would be in the year 2030, but he was quite sure it would not be human.

Linear Format Notations for Mathematics

MurrayS3 — Tue, 31 Aug 2010 01:52:04 GMT

I have been having a great discussion with Christian Lerch about computer-oriented mathematical notations. He has a program that lets you input MathML using a pure ASCII syntax. It is similar to ASCIIMathML. A lightly commented EBNF grammar of his MathEL language as implemented for the time being (still beta and evolving a bit) is given in http://km-works.eu/mathel-interactive/img/MathEL-ebnf.txt. Christian has a more elaborate reference manual in the works. One interesting feature is that he omits the leading backslash in the TeX-like names for symbols. This approach is definitely more readable and is the choice for eqn/troff distributed with Unix. TeX loomed so large in our thinking that we just automatically used the [La]TeX names by default. Office’s autocorrect facility allows users to define any names they want so users can add names without leading backslashes. Perhaps I can add an option that does not require the backslashes in math zones.

Another approach has been discussed, along with many earlier mathematical notations, in the article Stephen Wolfram's Mathematical Notation: Past and Future (2000). Wolfram’s discussion is both edifying and entertaining to read. I think he makes considerable progress with Mathematica’s notation, including introducing the five special characters we ended up adding to Unicode (U+2145..U+2149) for things like differential d (U+2146). However, his thinking is a little constrained by a very desirable goal: whatever math you write should be computable by Mathematica.

Something like Presentation MathML has sufficient flexibility to produce mathematics that cannot be computed without additional context and semantics. Once you allow a notation to have such ambiguity, you can go farther than Wolfram is willing to go. Wolfram calls the linear format “StandardForm” and the presentation format “TraditionalForm”.

I think that a linear format resembles traditional math notation far more closely if one uses Unicode symbols whenever possible. Having an autocorrection facility translate ASCII names for operators and Greek letters into Unicode symbols provides a convenient way to input the desired symbols, but the real format is defined in terms of Unicode symbols, not the ASCII names for these symbols. In addition to looking more mathematical, the notation is then automatically globalized, aside from some Arabic locales. The [La]TeX ASCII symbol names have a minor English-language prejudice. Hopefully this bias isn’t too objectionable to non-English-language speakers. The Unicode symbols are international by their very nature. As such an international linear format for math should use Unicode symbols, rather than ASCII, although it is fine to use the latter for input.

In addition it is nice to have little fix ups that reduce the number of brackets/parens needed to overrule operator precedence. For example, int_-infty^infty should be okay, since it’s clear by context that the – in –infty must be a unary minus. Also it’s nice to have a^b^c mean something (treat it right associatively), unlike in TeX, where it’s an error. OTOH, a^b_c is different, since TeX’s meaning for it is quite handy. Expressions like 1/.2 should create a fraction with .2 in the denominator rather than two sentence fragments. So the ASCII period and comma end up being handled differently when part of a number than in ordinary text. You also need a way to bind in n-aryands, like integrands and summands. So I introduced the glue operator U+2592, which both glues the n-aryand to the n-ary operator and terminates a limit, if one appears. To keep things looking natural, I considered a simple operand to be an alphanumeric span, rather than TeX’s single letter. The expression a_123 is a sub 123 rather than a sub 1 multiplied by 23. A complex operand can include parenthesized expressions so that f(x)/g(x) builds up to the ratio of f(x) to g(x).

Another requirement is to be able to round-trip the presentation (Professional/built-up) format through the linear format and back. This feature is very handy, since it lets us represent essentially arbitrary mathematical expressions/equations in “plain” text. One particular use is for user definable autocorrect entries. For example, you can assign \binomial with the linear format (a+b)^n=∑_(k=0)^n ▒(n¦k)a^k b^(n-k) and presto! When you type \binomial <space> or carriage return, it builds up to the binomial formula. Well not yet in Word 2010 (you need to select Professional Format explicitly), but it does in PowerPoint 2010 and OneNote 2010.

For special edge cases, I needed a couple of somewhat arcane constructs like the lenticular brackets〖〗for round-tripping compound arguments since if parentheses were used, the parentheses would be displayed. The result is that the Unicode linear format is a very general mathematical notation, but it is not a context-free grammar. This would certainly upset Wolfram and it does make it harder to implement and maintain in its full generality, although it is quite efficient in practice. It is the closest to a true mathematical notation that I could define. Let me hasten to add that many, many people, inside and outside Microsoft, have contributed ideas that shaped the version that Microsoft Office 2010 offers.

Bertrand Russell once wrote, “A good notation has a subtlety and suggestiveness which at times make it seem almost like a live teacher…and a perfect notation would be a substitute for thought.” The Unicode linear format certainly isn’t a substitute for thought, but it is a more mathematically natural notation than previously available on computers.

Which Languages a Font Supports

MurrayS3 — Wed, 28 Jul 2010 00:19:00 GMT

A recent post describes how RichEdit chooses default fonts for Unicode characters. The method assigns a character repertoire (CharRep) to each character and queries fonts to find out which CharRep’s they support. If the current font doesn’t support the CharRep for a character, RichEdit chooses a font that does. A variety of heuristics are used to fix up tricky cases.

A simple extension reveals whether a font supports a given language. Although many languages may use the same CharRep, e.g., most Western European languages use the LATIN CharRep, very few languages use more than one CharRep. RichEdit has a table mapping languages to CharRep’s, a table useful for sophisticated clients like OneNote and PowerPoint that typically know or guess the language(s) for text runs, but don’t know the CharRep’s.

A simple language descriptor suffices for font binding purposes, namely the Win32 Local ID (LCID). In fact to get the appropriate CharRep, most cases need only the primary language ID (PLID) given by the low-order 10 bits of the LCID. A few cases need the secondary language ID (SLID—next six bits) to choose among possible CharRep’s, e.g., Simplified vs. Traditional Chinese or Cyrillic vs. Turkish.

CharRep	PLID	Language	Comment
Default	00	Undefined
Arabic	01	Arabic
Cyrillic	02	Bulgarian
Latin	03	Catalan
GB2312	04	Chinese	SLID gives traditional vs. simplified
EastEurope	05	Czech
Latin	06	Danish
Latin	07	German
Greek	08	Greek
Latin	09	English
Latin	0A	Spanish
Latin	0B	Finnish
Latin	0C	French
Hebrew	0D	Hebrew
EastEurope	0E	Hungarian
Latin	0F	Icelandic
Latin	10	Italian
ShiftJis	11	Japan
Hangul	12	Korea
Latin	13	Dutch
Latin	14	Norwegian
EastEurope	15	Polish
Latin	16	Portuguese
Default	17	Rhaeto-Romanic
EastEurope	18	Romanian
Cyrillic	19	CYRILLIC
EastEurope	1A	Croatian
EastEurope	1B	Slovak
EastEurope	1C	Albanian
Latin	1D	Swedish
Thai	1E	Thai
Turkish	1F	Turkish
Arabic	20	Urdu
Latin	21	Indonesian
Cyrillic	22	Ukranian
Cyrillic	23	ByeloCYRILLIC
EastEurope	24	Slovenian
Baltic	25	Estonia
Baltic	26	Latvian
Baltic	27	Lithuanian
Default	28	Tajik	Tajikistan
Arabic	29	Farsi
Viet	2A	Vietnanese
Armenian	2B	Armenian
Turkish	2C	Azeri	SLID gives Latin/Cyrillic
Latin	2D	Basque
Default	2E	Sorbian
Cyrillic	2F	FYROM	Macedonian
Latin	30	Sutu
Latin	31	Tsonga
Latin	32	Tswana
Latin	33	Venda
Latin	34	Xhosa
Latin	35	Zulu
Latin	36	Africaans
Georgian	37	Georgian
Latin	38	Faerose
Devanagari	39	Hindi	Indic
Latin	3A	Maltese
Latin	3B	Sami
Latin	3C	Gaelic
Hebrew	3D	Yiddish
Latin	3E	Malaysian
Cyrillic	3F	Kazakh
Cyrillic	40	Kyrgyz	Cyrillic
Latin	41	Swahili
Latin	42	Turkmen
Turkish	43	Uzbek	SLID gives Latin/Cyrillic
Latin	44	Tatar
Bengali	45	Bengali	Indic
Gurmukhi	46	Punjabi Gurmukhi	Indic
Gujarati	47	Gujarati	Indic
Oriya	48	Oriya	Indic
Tamil	49	Tamil	Indic
Telugu	4A	Telugu	Indic
Kannada	4B	Kannada	Indic
Malayalam	4C	Malayalam	Indic
Bengali	4D	Assamese	Indic
Devanagari	4E	Marathi	Indic
Devanagari	4F	Sanskrit	Indic
Mongolian	50	Mongolian	Mongolia
Tibetan	51	Tibetan	Tibet
Latin	52	Welsh	Wales
Khmer	53	Khmer	Cambodia
Lao	54	Lao	Lao
Myanmar	55	Burmese	Myanmar
Latin	56	Gallego	Portugal
Devanagari	57	Konkani	Indic
Bengali	58	Manipuri	Indic
Gurmukhi	59	Sindhi	Indic
Syriac	5A	Syriac	Syria
Sinhala	5B	Sinhalese	Sri Lanka
Cherokee	5C	Cherokee
Aboriginal	5D	Inuktitut
Ethiopic	5E	Amharic	Ethiopic
Default	5F	Tamazight	Berber/Arabic, also Latin
Default	60	Kashmiri
Devanagari	61	Nepali	Nepal
Latin	62	Frisian	Netherlands
Arabic	63	Pashto	Afghanistan
Latin	64	Filipino
Thaana	65	Maldivian	Divehi
Latin	66	Edo	Nigeria
Latin	67	Fulfulde	Nigeria
Latin	68	Hausa	Nigeria
Latin	69	Ibibio	Nigeria
Latin	6A	Yoruba	Nigeria
Latin	6B	Quechua	Bolivia, Ecuador, Peru
Latin	6C	Sesotho sa Leboa
Cyrillic	6D	Baskir	Cyrillic
Latin	6E	Luxembourgish	Luxembourg
Latin	6F	Greenlandic	Greenland
Latin	70	Igbo	Nigeria
Latin	71	Kanuri	Nigeria
Ethiopic	72	Oromo	Ethiopia
Ethiopic	73	Tigrigna	Ethiopia/Eritrea
Latin	74	Guarani	Paraguay
Latin	75	Hawaiian	United States
Latin	76	Latin
Latin	77	Somali	Somalia
Yi	78	Yi	China
Latin	79	Papiamentu
Latin	7A	Mapudungun	Chile
Latin	7B	-
Latin	7C	Mohawk
Latin	7D	-
Latin	7E	Breton	France
Latin	7F
Arabic	80	Uighur	China Arabic
Latin	81	Maori
Latin	82	Occitan	France
Latin	83	Corsican	France
Latin	84	Alsatian	France
Cyrillic	85	Yakut	Russia
Latin	86	K'iche	Guatemala
Latin	87	Kinyarwanda	Rwanda
Latin	88	Wolof	Senegal
Latin	89	-
Latin	8A	-
Latin	8B	-
Arabic	8C	Dari	Afghanistan
Latin	8D	Malagasy	Madagascar
Latin	8E	-
TaiLe	8F	Tai Le	China
NewTaiLu	90	New Tai Lu	China

In this table, the EastEurope, Baltic and Turkish CharRep’s use the Latin script, but are distinct since they correspond to distinct charset’s. The PLIDs are in hexadecimal.

To tell RichEdit 5.0 or later to format a text run with the CharRep for a given LCID, send the message EM_SETCHARFORMAT with wparam containing the flag SCF_CHARREPFROMLCID (0x0100) and lparam pointing to a CHARFORMAT2 with the LCID.

Article/Video on Murray Sargent and Math in Office

MurrayS3 — Fri, 18 Jun 2010 05:31:51 GMT

The article Professor's Laser Focus Gets Math into Office tells some of the story behind the Math in Office project. It also gives a link to a video that includes a sequence of me showing how easy it is to type in the binomial theorem. Hope you like it J

RichEdit Font Binding

MurrayS3 — Thu, 10 Jun 2010 00:23:00 GMT

Suppose a user pastes some plain text into a document. In principle, that text can contain any Unicode character. That includes virtually all characters used in the current languages of the world along with many from ancient scripts and a plethora of symbols, mathematical and otherwise, that don’t belong to any language in particular. The question arises as to what font(s) to use for the pasted characters. In general the same font cannot be used for all characters, since TrueType glyph indices are 16-bit numbers thereby limiting fonts to 64K characters. Meanwhile Unicode has over 100,000 assigned characters. Furthermore even if a font could contain glyphs for all Unicode characters, it wouldn’t be able to render them all without compromises in quality. East Asian characters, for example, ideally have different baselines from Latin characters. This post describes the way RichEdit chooses fonts for characters not present in the active font. This process is call “font binding”.

The first section describes RichEdit character repertoires. The second section explains how a character is assigned to a character repertoire. The third section describes how to find out what character repertoires are supported by a font. The fourth section shows how these two kinds of information are combined to bind fonts to characters in a context-dependent way.

RichEdit Character Repertoires

RichEdit’s approach to font binding is an extension of the GDI CreateFont() functionality that ensures the created font matches a given charset. If the font named in the call supports the charset, then the font is used, but if not, GDI instantiates a font that does. Before Unicode became popular, charsets defined character encodings for character repertoires typically associated with language systems, like Western European languages and Japanese. As such they were used for two purposes: to define the encodings and to define character repertoires supported by fonts. The GDI CreateFont charset functionality addresses the latter purpose. This facility, which is a kind of “font fallback”, is very handy, since it’s usually easy to choose the charsets for characters that have charsets. In contrast it’s hard to choose the correct languages for characters in general.

Charsets correspond to code pages. The Windows code pages are described here. For reference, the Windows charsets supported by RichEdit are

ANSI_CHARSET	EASTEUROPE_CHARSET	RUSSIAN_CHARSET
GREEK_CHARSET	TURKISH_CHARSET	HEBREW_CHARSET
ARABIC_CHARSET	BALTIC_CHARSET	VIETNAMESE_CHARSET
DEFAULT_CHARSET	SYMBOL_CHARSET	THAI_CHARSET
SHIFTJIS_CHARSET	GB2312_CHARSET	HANGUL_CHARSET
CHINESEBIG5_CHARSET	PC437_CHARSET	OEM_CHARSET
MAC_CHARSET

When Windows 2000 added support for Indic and several other South East Asian scripts, the decision was made not to add charsets for new scripts since it was clear that Unicode was the best way to represent characters on computers. Unfortunately that decision limited GDI’s convenient font “fallback” mechanism to character repertoires that have charsets. RichEdit needed to generalize this usage of charset. Accordingly we defined the charrep, a character repertoire index. There’s a charrep for each Windows charset. In addition, there are charreps for

Armenian	Syriac	Thaana	Devanagari	Bengali
Gurmukhi	Gujarati	Oriya	Tamil	Telugu
Kannada	Malayalam	Sinhala	Lao	Tibetan
Myanmar	Georgian	Jamo	Ethiopic	Cherokee
Aboriginal	Ogham	Runic	Khmer	Mongolian
Braille	Yi	Math General	Math Alphanumeric	Limbu
Taile	Newtailu	Sylotinagr	Kharoshthi

Most of these are described in The Unicode Standard.

Determining a Character’s Charrep

RichEdit does a kind of binary range search to find out which charrep a character nominally belongs to. ASCII is treated specially, since almost all fonts support “low ASCII”, the “neutral” range U+0020..U+003F. High ASCII, the range U+0040..U+007F is supported by most fonts as well. The ANSI_CHARSET includes ASCII and the Western European ANSI set contained in Windows code page 1252. For the range U+00A0..U+00FF, there’s a charrep named “high Latin 1”.

East Asian (CJK—Chinese Japanese Korean) fonts all support ASCII and high Latin 1. Chinese characters are used in Japanese, in both simplified and traditional Chinese, and in Korean. The CJK fonts often have a lot of Unicode symbol characters (not SYMBOL_CHARSET discussed shortly), so a CJK charrep may be returned for those. An exception occurs in math zones, where a math charrep is preferred.

The default charrep is assigned to the Unicode Private Use Area characters, U+E000..U+F8FF, since these characters have no standardized semantics. Special attention is given to SYMBOL_CHARSET fonts, which by definition don’t use Unicode. But characters in the range U+F020..U+F0FF are assigned the SYMBOL_CHARSET charrep, since Microsoft TrueType SYMBOL_CHARSET fonts use those locations as aliases for U+0020..U+00FF. These charrep assignments are similar to some assignment models based on scripts. But note that natural language isn’t used. This is because it’s much easier and more reliable to figure out a reasonable charrep for a character than a natural language for a character.

Determining what Charreps a Font Supports

Windows GDI has a handy structure known as the FONTSIGNATURE, which has bits claiming support for various code pages and Unicode ranges. Some fonts don’t have reliable values, so buyers beware. Nevertheless, it’s fast and useful, so RichEdit uses it to fill in a bit mask for supported character repertoires and has some back-up code to handle errant fonts. Some fonts claim to support a given character repertoire, but only partially support it. For example Japanese fonts claim to support Greek and Cyrillic, but they only have glyphs for basic Greek and Cyrillic characters. RichEdit classifies other characters in these repertoires as “extended”, which means that they need “cmap” verification. The cmap is a TrueType font’s character-to-glyph map. If it returns 0 for a character, the character is missing and will display a missing-character glyph, usually an empty box. The cmap approach is valuable for other cases in which the FONTSIGNATURE may be inadequate. For example, a font may not claim to support Latin 1, but it nevertheless supports low and/or high ASCII. By checking the cmap for ‘0’ and ‘a’, respectively, one can find out the amount of ASCII support available. This approach can also be useful for finding out about new Unicode ranges not yet in the FONTSIGNATURE, e.g., emoji.

Binding Fonts

Given the information in the two preceding sections, we need to ensure appropriate fonts are bound to characters. Let’s start with the basic algorithm and then consider some of many fix-ups.

The simple algorithm is: assign a character flag (bit) to each character repertoire (charrep) and AND the resulting bit mask for a character against the bit mask for the current font. If a nonzero value results, the font claims to support the character’s charrep and the font can continue to be used. If the result is zero, font binding is needed.

In an attempt to keep the current user font choices when font binding, RichEdit scans the text runs backward from the insertion point looking for a font that supports the desired charrep. If one is found, it is used unless it was introduced by font binding. Otherwise the default font for the charrep is used. The RichEdit client can change the default font for a charrep by using the EM_SETCHARFORMAT message with the SCF_ASSOCIATEFONT flag and an LCID (locale ID) that corresponds to the desired charrep.

Special considerations apply to math zones and Chinese characters (among other scenarios). In math zones, a math font is used whenever it can handle the characters. This includes not only Unicode math symbols and math alphanumerics, but also Latin, Greek and Cyrillic text. Many Chinese characters are used in Japanese, but a Chinese font may not look pleasing to a Japanese person. In particular, the simplified Chinese fonts look quite different from the more traditional look of the same characters rendered with a Japanese font. So to bind appropriately, we scan forward and backward around an inserted Chinese character to see if any Hiragana or Katakana characters are present. If so, it’s most likely to be Japanese text and a Japanese font should be used. Similarly if Hangul characters are found, a Korean font should be used. Other heuristics involve noting what the user locale is.

If even with its many heuristics RichEdit still cannot find a reasonable font and a Microsoft Office application is running, RichEdit queries the Office mso.dll for advice. Also various kinds of “font fallback” may kick in at display time to save a character from rendering as a missing-character glyph. Font binding is an area of active research, since new character scripts continue to be added to Windows and Unicode continues to add new characters. In general RichEdit does a good job of it, but it could be better.

Bidi Paragraph with Parenthesized Text

MurrayS3 — Fri, 07 May 2010 00:18:00 GMT

The previous post described four tailorings of the Unicode Bidi Algorithm (UBA) in situations where the UBA display is confusing or even misleading. The present post adds another set of scenarios to this list, namely strange renderings of paragraphs that contain parenthesized or quoted text. An algorithm for displaying such text in a reasonable way is given. This algorithm first shipped in Microsoft Office 2007 and you can see it in action by typing bidi text into Excel 2007/2010 cells. The problem is sort of mathematical in nature, since parenthesized text is like a parenthesized expression. It can be nested and the text should display inside the parentheses.

Nevertheless, according to the UBA, there are cases for which both parentheses of a parenthesized expression have the same glyph. In a rich-text editor like Microsoft Word if you type

(a)b

using an English keyboard and type Ctrl+RightShift to switch to an RtL paragraph you see

(a)b

This is because the parentheses are stamped with LtR directionality by the keyboard language’s directionality, thereby overruling the UBA. In NotePad, which follows the UBA, the LtR paragraph version looks the same as in Word, but the RtL version looks like

a)b)

Here the UBA classifies the opening parenthesis as RtL, thereby appearing first (on the far right) and mirrored instead of to the left of the letter a. Similarly a(b) appears as (a(b in an RtL paragraph.

As a more complicated example, consider the nested case a(bف(فc)dc)d. According to the UBA, this displays in an LtR paragraph as a(bف(فc)dc)d and in an RtL paragraph as

a(bف(فc)dc)d

Neither of these renderings preserves the visual nesting of the characters.

We can fix such parenthesized text displays using a bidi-parenthesis-matching algorithm due to Ayman Aldahleh. A basic idea is to ensure that both parentheses of a matched pair have the same directionality and that what’s inside the parentheses has bidi level(s) greater than or equal to the parenthesis pair level. The algorithm uses an open-parenthesis stack along with a parenthesis-pair information array. The algorithm can be easily generalized to handle brackets, braces, and other character pairs, but for simplicity we stick with ASCII parentheses and assume that Unicode bidi embeddings aren’t present.

1) Run the UBA on a paragraph noting the bidi levels of the characters.

2) Scan the paragraph for parentheses. When an open parenthesis is found (U+0028), record its bidi level and character position in the next information element and push the element index onto the open-parenthesis stack.

3) If a close parenthesis is found (U+0029) and the stack has an entry, a matched pair is found. Use the element index on the top of the stack to find the corresponding pair information element. If both parentheses have the same bidi level, use that for the pair. If they differ, start by setting the pair level equal to the smaller level. If in an RtL/LtR paragraph, the pair level isn’t odd/even, increment the pair level. Set both parenthesis levels equal to the resulting pair level and record the character position ending the pair.

4) If an unpaired or improperly nested parenthesis is found, abandon the matching process.

5) Process the pair information elements from first to last. For each element, if any character inside the pair has a level smaller than the pair level, increment the level by 2. This forces the character to display inside the pair and doesn’t change its directionality.

This last step is recursive, since outer pair elements precede elements for any pairs they contain and increment the latters’ levels. When an inner pair is processed, its level is guaranteed to be greater than or equal to the parent pair, etc.

For the simple paragraph above in an RtL paragraph, the (a)b appears as (a)b, since the opening parenthesis is promoted to level 2. In a case like a(bفc)d in an RtL paragraph, the a(b and c)d all have level 2 and the ف is bumped up to level 3. To see more cases, type various parenthesized expressions into an Excel cell and click on the paragraph direction tool to change the paragraph direction. If you have properly matched parentheses, the results will always look properly nested. It also works with brackets [] and braces {}.

Tailoring the Unicode Bidi Algorithm

MurrayS3 — Tue, 06 Apr 2010 23:37:00 GMT

The Unicode Bidi Algorithm is a very useful, general, and standard approach for displaying text that contains right-to-left scripts, such as Arabic and Hebrew. But there are situations in which it is awkward to use and/or is visually confusing. This post considers three such situations: math zones, International Resource Identifiers (IRIs), and HTML spans with a directionality attribute. In each of these cases, tailoring the Unicode Bidi Algorithm improves the result. The post starts with a summary of the original case of tailoring, namely the popular keyboard “higher-level protocol” used in rich-text applications.

Keyboard-Driven Bidi Algorithm

For the first example of tailoring the Unicode bidi algorithm, consider keyboard input into rich-text editors, such as Word and RichEdit rich-text edit controls. For this kind of input, the directionality of neutral characters, such as space and parentheses, is determined by the keyboard language. Specifically if the keyboard language is Arabic, Hebrew, or some other right-to-left (RTL) language, the neutrals are treated as RTL characters. If the keyboard language is left-to-right (LTR), the neutrals are treated as LTR characters. Spans of digits, possibly including embedded commas and periods, are always displayed LTR even when entered with an RTL keyboard, but the directionality given to the number they comprise has the directionality of the keyboard language.

Users generally like this approach to bidi text, since it’s simple and predictable. If runs of text could always be reliably stamped by the input language, the Unicode Bidi Algorithm would only have to handle some esoteric text embeddings and ensuring that numbers are displayed LTR. But plain text is commonplace and hence there has to be a way to display bidi text correctly without language attributes. Unfortunately in order to handle the wide variety of special character combinations, the resulting algorithm is very complicated, involving the set of special override codes LRM, RLM, LRO, RLO, LRE, RLE, and PDF. In a real sense, these override codes are used to encode a rich-text directionality attribute in plain text. The justification for this is the Unicode principle that “plain text must contain enough information to permit the text to be rendered legibly and nothing more” (see Plain Text subsection of Sec. 2.2 in Chapter 2 of the Unicode Standard).

Note that plain text pasted into a rich-text instance is treated using the Unicode Bidi Algorithm; the keyboard language doesn’t play a role in pastes.

Bidirectional Text in Math Zones

Consider next the directionality of math text in math zones. The guiding principle is that neutrals other than the period and comma are given the directionality of the math zone. This includes math operators and spaces. Alphabetic spans of characters having the same directionality are displayed with that directionality relative to one another, but the span as a whole is treated as object with the directionality of the math zone. As with the Unicode Bidi Algorithm, spans of digits, possibly including embedded commas and periods, are displayed LTR, but analogously to keyboard language tailoring, the number they comprise has the directionality of the math zone.

Normal text embedded in a math zone obeys the directionality rules of normal text. Typically this is given by the Unicode Bidi Algorithm, but the keyboard language algorithm is used if the text is entered by keyboard.

Internationalized Resource Identifiers

Internationalized Resource Identifiers (IRIs) are a generalization of Universal Resource Identifiers (URIs) that can contain many nonASCII characters, such as most alphabetic characters and Chinese characters. Complications occur when bidi characters are used in IRIs especially when displayed in an RTL context. For example according to the Unicode Bidi Algorithm, http://شس.يب.ثق displays in a right-to-left paragraph as

//:httpشس.يب.ثق

Or more confusing yet, http://exchange.شس.ثق displays in an RTL paragraph as

http://exchange.شس.ثق

As the IRI reference discusses, use of the Unicode Bidi Algorithm at least is consistent in the way such IRIs are displayed in plain text, but in some sense the RTL versions are nearly unreadable. The IRI reference does recommend that IRIs always be displayed in LTR display order. But that requires being able to recognize an IRI in the first place.

So assuming an IRI can be recognized, something that RichEdit does on the fly, we can enforce a more readable display order. Namely we force the delimiters '#', '.', '/', ':', '?', '@', '[', ']' to follow the paragraph (or embedding) direction. With this condition, http://exchange.شس.ثق displays in an RTL paragraph as

http://exchange.ثق.شس

i.e., the alphanumeric spans in between the special delimiters appear in the reverse order from the way they appear in an LTR paragraph and the Unicode Bidi Algorithm is not used to resolve the neutrality of the slash and period. The alphanumeric spans themselves (in effect the “leaves” of the structure) are displayed in the order determined by the Unicode Bidi algorithm.

This approach appears to be ideal. The only problem is that it’s not trivial to identify IRIs using heuristics. Both Word and RichEdit can identify IRIs, but ambiguities can occur when spaces appear at the ends. Word allows the user to overrule the IRI recognition, but RichEdit 7.0 and earlier versions do not. The IRI and URI specifications require that spaces be “escaped”, that is, replaced by their ASCII hexadecimal code %20.

Additional Requirements for Bidi in HTML

The paper Additional Requirements for Bidi in HTML describes a number of situations in HTML when application of the Unicode Bidi Algorithm yields bizarre, or at least unwanted, results. These situations don’t cause problems in Word or RichEdit rich-text controls, since every format run (similar to in HTML) is assigned directionality. But in HTML, a with a particular directionality influences the way the text next to it is displayed unless that text also has an assigned directionality.

Even simple things can display in surprising ways. For example,

10 main st.

displays in an RTL context as

.main st 10

This happens because the number at the start of an RTL paragraph is classified as an RTL object in an RTL context (even though the digits are displayed LTR with respect to one another), and hence the number comes first (to the right). It’s followed by the LTR text “main st”, but the period is classified as RTL and appears last, namely to the left of “main st”.

Let’s look at a couple of examples in that paper that can be fixed by adding a new attribute called bdi for “bidirectional isolate”. These examples use the notation that upper-case ASCII letters are strong RTL letters and lower-case ASCII letters are strong LTR. The first example consists of the string “PURPLE PIZZA – 3 reviews”, which is displayed LTR in logical order (RTL characters are displayed LTR). In an LTR context, one would like this string to be displayed as

AZZIP ELPRUP – 3 reviews

But because a number is given the directionality of the (in this case RTL) run preceding it, it displays as

3 – AZZIP ELPRUP reviews

The second example in logical order is

USE css (position:relative).

One wants this to display in an RTL paragraph as

.(position:relative) css ESU

But because the LTR span continues the LTR css, it gets displayed as

.(css (position:relative ESU

The proposed fix is to put the embedded text into a with a bdi attribute, which is then “displayed as if it were surrounded with strong-directional characters of the last explicit embedding level within which it appears” (taken from Sec. 2.1 of the paper referenced above). For the “PURPLE PIZZA” case, the “ - 3” would then be treated as if it were preceded by a strong LTR character. For the “USE css” case, the parentheses would resolve to RTL and get mirrored, giving the desired result above. If you’re interested in these problems, please read the full article.

Implementation for Math Zones and Hyperlinks

RichEdit tailors the Unicode Bidi Algorithm in two main steps: 1) get a string of massaged plain text from a range, and 2) break that string into a set of substrings based on currently assigned directionalities. It’s in step 1) that the math, IRI and some other overrides are made. For math, all operators (not including comma and period) are replaced by the letter ‘a’ for LTR math zones and by alef (U+0627) for RTL math zones. Since only Arabic locales use RTL math zones, alef is a good choice to use as an RTL character. For automatically detected IRIs, the delimiters '#', '.', '/', ':', '?', '@', '[', ']' are similarly replaced by ‘a’ or alef according to the paragraph direction. In Hebrew IRIs, it’s probably a good idea to use the Hebrew alef (U+05D0) instead of the Arabic alef, but I haven’t tested to see if it matters. The IRI overrides are in an experimental stage.

In step 2) Uniscribe’s ScriptItemize() function analyses each substring, returning information that may cause the directionality of some characters to be overruled. When this process is completed, the range is passed to a finite state machine to assign embedding levels for use by the LineServices reverse object handler. This handler is responsible for supplying the relevant glyphs in the appropriate display order for the reverse object nesting level. It’s a little tricky. Actually it’s fair to say that it’s very tricky!

Linear Format Version 3

MurrayS3 — Sat, 13 Mar 2010 16:06:00 GMT

Unicode Nearly Plain-Text Encoding of Mathematics, Version 3 (Unicode Technical Note #28) is now posted. The differences between Version 1 and 2 of that paper are largely cosmetic, but there were enough changes in Version 2 to merit a new number. Version 2 is mostly implemented in Microsoft Word 2007, where it is referred to as the “linear format”. Typing the linear format into a Word 2007 math zone results in “formula autobuildup”, that is, automatic conversion to the built-up format of expressions as their syntax becomes unambiguous.

The new features added in Version 3 are identified as such. They are mostly implemented in the Microsoft Office 2010 applications Word, PowerPoint, Excel, and OneNote. Typically the new features offer convenience over ways defined in Version 2, and the Version 2 syntax remains valid in Version 3. The additions were often inspired by [La]TeX. Examples of simplified input are \choose for binomial coefficients, \cases for alternative definitions, \pmatrix for parenthesized matrices, \middle to define a custom character as a bracket separator, a simpler prescript notation, \root n\of x notation for nth roots, equation alignment, size overrides, and simple negated operator input. The section Version Differences has hyperlinks to where these additions are documented. There are also numerous cosmetic changes along with lots of internal links to facilitate navigation.

If you use Microsoft Office math zones, please read Section 2. It’s a quick read. The knowledge so gained makes it easy to enter simple mathematical expressions into Word 2007/2010, PowerPoint 2010, OneNote 2010 and Excel 2010. Section 3 discusses how to enter more complicated expressions.