Math Selection

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², 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.

Comments

• Anonymous
  June 30, 2007
  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.

• Anonymous
  July 01, 2007
  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

• Anonymous
  July 02, 2007
  The comment has been removed

• Anonymous
  July 02, 2007
  The comment has been removed