Selection of text in a math zone obeys some special rules concerning built-up math objects, such as fractions and integrals. First some background on how these objects are stored helps to clarify the rules.

In memory, math objects start with a special 16-bit character and end with a different 16-bit character. In RichEdit, the start character is U+FDD0 and the end character is U+FDEF. An argument of an object ends with a special separator character (U+FDEE for RichEdit) when followed by another argument and it ends with the end-of-object character if the argument is the last one of the object. This math object structure is also discussed in my post on math find/replace. The math object delimiter characters belong to the special Unicode range U+FDD0..U+FDEF, which is defined for internal use only. That is, these characters can be used in memory, but should not be used in files.

Selection of text in a math zone works the same way it does in normal text as long as one of these three math-object delimiter characters isn’t selected. As soon as one is selected, the whole object is automatically selected. For example, if you type Shift+→ at the end of the numerator of a fraction, you attempt to select the numerator’s delimiter. This causes the whole fraction to be selected. Similarly if you type Shift+→ at the start of a math object or Shift+← at the end of a math object, the whole object is selected. The math object is also selected if you type Delete at the start of the object or Backspace at the end the object. A second Delete or Backspace then deletes the object. This behavior exists so that you don’t delete things by mistake. If you do so anyway, you can always undo your deletion by typing Ctrl+z.

You can select from outside a math zone part way into a math zone unless the math zone consists of a single math object. So if normal text precedes *E *= *mc*^{2}, you can select that text along with, for example, *E*. As such the math zone isn’t treated as a single math object. This is possible because math zones are identified by a character format effect like bold rather than by start and end delimiter characters.

Glad to see you are back from your vacation! 🙂

It would be good it you could explain in more detail in a future post why OOXML could not use MathML. I read your earlier post, but did not find it convincing. What we need are some examples from real-life docs which clearly demonstrate the need for OOXML to use a variant of MathML. Bare assertion is simply not enough if you want OOXML to become an ISO/IEC standard.

This policy sounds all very nice and natural, and your answer at the MathUI workshop was just as much, but I am under the thought that there must be something more tricky somewhere.

Have you been comparing this to other tools?

Do you have experiment results that make it work ?

thanks!

paul

It is nice to learn how RichEdit handles text selection internally. In my own math tool I used basically the same algorithm. Hopefully I’m not violating any Microsoft patents now… The memory representation is slightly different: I used U+000F..U+001E for start of object, U+000E for end of object, and U+000A (new line) as argument separator. The argument separator can be selected or even deleted without selecting the entire object.

Re John’s question on why OOXML can’t use MathML, the basic reason is that Word allows the user to insert things into math zones that cannot be expressed as MathML. Such things include revision marks, footnotes, comments, and images. In the current MathML Working Group we have been attempting to figure out reasonable ways to generalize MathML to handle these things and might come up with appropriate modifications for MathML 3.0. When we created the new math facility, we were limited to MathML 2.0. Nevertheless, using an XSLT to translate OMML to MathML is fine for most purposes, since revision marks, footnotes, comments, images, etc., can either be discarded or can be avoided.

For examples of real life documents, note that revision marks are a standard way of recording changes made by various coauthors. They are heavily used in the preparation of legal documents. But it doesn’t seem reasonable to include them in MathML. Instead I think they could be included in a property entity that belongs to a different namespace. For this to work, MathML needs to allow some kind of embedded namespaces. There are other needs for embedded namespaces in MathML and it’s a hot topic in the MathML WG.