A good name is OfficeMath. “Office” alludes to Microsoft Office but needn’t be exclusive. “Office” suggests a highquality level (okay, maybe I’m biased ). OfficeMath might suggest calculations rather than math text, but documentation can resolve that ambiguity, which also exists for the linear formats AsciiMath and UnicodeMath. The heart of OfficeMath is its inmemory model, named “Professional” in the OfficeMath UI. This model is mirrored in the OMML file format. It features Nary structures such as integrals with limits and integrands, subscripts, superscripts and accents with welldefined bases, and math functions with function names and arguments. This level of detail is ordinarily reserved for content math formats such as Content MathML and OpenMath. OfficeMath incorporated these structures to support highquality math typography, with the nice side effect of facilitating symbolic manipulations and graphing (OneNote Math Assistant). This post summarizes OfficeMath’s history, model, file format support, interoperability, math font, and math formatting, and includes links to further information in OfficeMathoriented posts in Math in Office. OfficeMath UI will be discussed in a separate post.
A fun place to learn about the origins of OfficeMath is the post LineServices, which tells how the LineServices linelayout component came to be and how it evolved to yield TeXquality math typography. OfficeMath depends on other technologies as well, including the creation of the mathfont OpenType standard described in HighQuality Editing and Display of Mathematical Text in Office 2007 and OpenType Math Tables. For older history, the post How I got into technical WP describes the first math display program (Scroll, 1970) and predecessors of UnicodeMath.
OfficeMath was based on Unicode from the start. Unicode 3.2 (March, 2002) already had most of the current Unicode math character set. The Unicode Technical Committee is committed to including all attested math symbols in the Unicode Standard, so Unicode makes an ideal foundation on which to build math functionality. It also streamlines incorporation into Microsoft Office applications, since they are based on Unicode.
As with [La]TeX, MathML, MathType, and other math presentation programs, OfficeMath puts all math expressions and equations into math zones. Mathzone typography differs from the typography of ordinary text (see the section on Formatting below).
In the OfficeMath inmemory "Professional" format, mathematical objects like fraction and subscript are represented by a start delimiter, the first argument, an argument separator if the object has more than one argument, the second argument, etc., with the final argument terminated by an end delimiter. For example, the fraction 𝑎/𝑏 is represented in builtup format by {_{frac} 𝑎𝑏} where {_{frac} is the start delimiter,  is the argument separator, and } is the end delimiter. Similarly, the subscript object 𝑎_{𝑏} is represented by {_{sub} 𝑎𝑏}. The start delimiter is the same character for all math objects as are the separator and end delimiters. In RichEdit, these delimiters are given by the Unicode characters U+FDD0, U+FDEE, and U+FDEF, respectively. In OMML, the start delimiter is represented by an container element, such as <f> for fraction and arguments appear within argument element containers, such as <num>…</num> for a numerator.
The type of object is specified by a characterformat property associated with the start delimiter. In plain text, the builtup forms of the fraction and subscript are identical if the fraction arguments are the same as their subscript counterparts. In the example here, a plaintext search for {_{frac} 𝑎𝑏} matches {_{sub} 𝑎𝑏} as well as {_{frac} 𝑎𝑏}. Searching for OfficeMath equations involves plaintext searches like this together with comparison of the object types as discussed in Math Find/Replace and Rich Text Searches. The OfficeMath math objects are listed in the table in the next section along with their OMML and Presentation MathML representations. The objects are represented by prefix notation: the character formatting of the object start delimiter contains the object properties (see ITextRange2::GetInlineObject()). This differs from infix notation like 𝑎/𝑏, which needs to be parsed. The OfficeMath inmemory format is a “builtup” format as distinguished from linear formats like UnicodeMath and LaTeX.
The OMML format is the XML format that encapsulates the OfficeMath inmemory “Professional” format. When OfficeMath was designed, Presentation MathML 3.0 was nearing publication. But Presentation MathML is missing two important elements which therefore require <mrow> emulations to represent OfficeMath. Specifically, Presentation MathML doesn’t have an explicit Nary element, nor does it have an explicit mathfunction element. Furthermore, OfficeMath needs to embed client (Word, PowerPoint, Excel, …) XML easily into the math XML. The MathML <semantics> element can embed such information, but it’s awkward. Accordingly, OMML was created to describe the OfficeMath inmemory format naturally. With best practices, MathML without the <semantics> element can be used to roundtrip OfficeMath equations apart from nonmath formatting like revision markings and embedded objects.
Here is a listing from MathML and Ecma Math (OMML) of the OMML elements and exact or approximate MathML counterparts
Builtup Office Math Object...  OMML tag...  MathMl 
Accent  acc  mover/munder 
Bar  bar  mover/munder 
Box  box  menclose (approx) 
Boxed Formula  borderBox  menclose 
Delimiters  d  mfenced 
Equation Array  eqArr  mtable (with alignment groups) 
Fraction  f  mfrac 
Math Function  func  mrow with FunctionApply (2061) mo 
Left SubSup  sPre  mmultiscripts (special case of) 
Lower Limit  limLow  munder 
Matrix  m  mtable 
Nary  nary  mrow msubsup/moverunder with Nary mo 
Phantom  phant  mphantom and/or mpadded 
Radical  rad  msqrt/mroot 
Group Char  groupChr  mover/munder 
Subscript  sSub  msub 
SubSup  sSubSup  msubsup 
Superscript  sSup  msup 
Upper Limit  limUpp  mover 
Other OMML references are Extracting OMML from Word 2003 Math Zone Images and OMML Specification, Version 2.
More MathML discussion is given in MathML 3.0, Improved MathML support in Word 2007, Rendering MathML in HTML5, and MathML on the Windows Clipboard.
Mathematical RTF is essentially OMML in RTF syntax. See also Office Math RTF and OMML Documentation and Updated RTF Specification.
Linear Format Notations for Mathematics include UnicodeMath and LaTeX Math in Office. See also Recognizing LaTeX Input in UnicodeMath Input Model.
Major interoperability is afforded via Presentation MathML and [La]TeX math. In addition, the Design Science MEE and MathType equations can be converted to OfficeMath as described in Converting Microsoft Equation Editor Objects to OfficeMath. MathType can convert OfficeMath to MathType equations. These equation facilities are compared in EquationEditor OfficeMath Feature Comparison and Other Office Math Editing Facilities. The latter also compares them to the Microsoft Word EQ Field.
With a bit of effort, equations can be imported into Office applications from Wikipedia articles as described in Copying Equations from Wikipedia into Office Applications. You can create HTML documents with equations in them as described in Creating Math Web Documents using Word 2007.
A basic part of OfficeMath is the Unicode OpenType math font. The first such font, Cambria Math, and the OpenType math tables were developed together with the Office 2007 math software, each influencing the other to obtain high quality results. Some history is given in the post HighQuality Editing and Display of Mathematical Text in Office 2007. The font contains extensive math tables, glyph variants and glyphs for most of the Unicode math character set. The tables were incorporated into the OpenType standard as noted in OpenType Math Tables. Posts elaborating on the math font are Special Capabilities of a Math Font and High Fonts and Math Fonts.
Cambria Math and Cambria are serifed fonts designed to look good on digital displays. As such, the stem widths never get skinny, in contrast to Times Roman fonts. If you prefer, the STIX math font is a Times Roman font that includes the OpenType math table support and works with OfficeMath. This font is discussed further in Math STIX Fonts 2.0 and UTR #25 Updates.
This section discusses how OfficeMath handles math formatting involving math spacing, math styles, and alignments, and gives links to posts with further information. A math zone is defined by the mathzone characterformat effect, an effect like bold or italic. As such, this is a nonnestable property, unlike math objects like fractions, which can be nested arbitrarily deeply. Adjacent math zones automatically merge into a single math zone.
An essential part of good math typography is math spacing. Within a math zone, OfficeMath follows the math spacing rules given in Appendix G of The TeXbook plus some enhancements that weren’t added to TeX for reasons of archivability. Section 3.16 of UnicodeMath summarizes the rules for the most common situations. Also see User Spaces in Math Zones for ways that OfficeMath autocorrects typical user input spacing errors. Two Math Typography Niceties shows how phantom objects can improve math spacing beyond the standard spacing rules.
Math bold and math italic define different math variables in math zones (𝐚 ≠ 𝑎 ≠ a ≠ 𝒂), while in ordinary text, bold and italic are used for emphasis. In math zones, math bold and math italic characters are different Unicode alphanumeric characters, while in ordinary text, bold and italic are character format attributes with no change in character codes. For example, 𝐚 is U+1D41A, 𝑎 is U+1D44E, a is U+0061, and 𝒂 is U+1D482. Even though the math and ordinarytext uses of bold/italic are unrelated semantically, the user can control these math styles using the usual bold and italic UI as described in Using Math Italic and Bold in Word 2007. There are other math styles that yield still different mathematical variables, such as openface, script, Fractur, and sans serif (see Section 2.2 of Unicode Technical Report #25). In general, character formatting is controlled in math zones as described in Restricted Math Zone Character Formatting. In informal documents, people may want to use sansserif characters instead of serif characters for aesthetic reasons rather than for defining different variables. Currently OfficeMath doesn’t support this choice, but maybe it should.
Occasionally one needs to embed ordinary text, such as words, into math zones. OfficeMath defines a character format attribute “ordinary text” for this purpose. Text with this attribute uses standard character formatting for italic, bold, etc. Unless the “ordinary text” attribute is active, the bold and italic settings only affect math alphanumerics; ASCII digits, punctuation, operators, and nonmath characters are all rendered nonbold and upright.
In addition, OfficeMath has a “nobuildup” attribute to treat operator characters literally rather than use them in buildup translations. For example, if ‘\’ is marked with this attribute, build up in UnicodeMath mode leaves it as the character ‘\’ rather than converting it with the arguments around it into a builtup “stacked” fraction.
Since math zones are one level deep, you can embed ordinary text into a math zone, but you can’t nest a math zone within that ordinary text or elsewhere within the math zone. This hasn’t proven to be a limitation, although TeX can embed ordinary text inside math zones and nested math zones inside the ordinary text. It always seems to be possible to unwrap such nested mathzone scenarios into unnested math zones.
It’s useful to be able to define math properties for an entire document, rather than specify them for each math zone. This is described in Default Document Math Properties. A new property could be defined to use sansserif math characters instead of serif characters.
There are two kinds of math zones: inline and display. For example, an inline math zone in TeX has the form $...$ and a display math zone has the form $$...$$. Inline math zones use reduced spacing and character sizes to make expressions fit better in line with normal text. In OfficeMath a display math zone starts at the start of a document or follows a hard or soft paragraph end (U+000D or U+000B, respectively) and ends with a hard or soft paragraph end. In some cases, it would be useful to apply display mathzone formatting to inline math zones, but this isn’t currently available.
Interequation alignment and line breaking involve multiple lines. To handle these cases and equation numbering, OfficeMath has the Math Paragraph, while MathML uses tables and MathType uses PILEs. A math paragraph is a sequence of one or more display math zones separated by soft paragraph ends (U+000B). Line breaking can be automatic or manual as described in Breaking Equations into Multiple Lines. Background on paragraph formatting is given in Paragraphs and Paragraph Formatting.
In a document with more than a few equations, it’s useful to number equations referred to from elsewhere in the document. The math paragraph has elegant equationnumber support, but it hasn’t been exposed beyond prototyping. The earliest way to handle equation numbering is described in Cool Equation Number Macros for Word 2007. Later ideas are in More on Equation Numbering and equation numbering using equation arrays is described in Equation Numbering in Office 2016. This last approach isn’t quite as convenient as the ideal mathparagraph equation numbering, but it can handle virtually all cases.
]]>Conversion to OfficeMath is only enabled for program modes that support the OMML (Office Math Markup Language) file format. If a file is opened in “Compatibility Mode”, equation objects in the file may not be directly convertible to OfficeMath. Word added OMML support in Word 2007 and PowerPoint and Excel added it in Office 2010. The old doc, ppt, and xls file formats do not support OMML. To convert equation objects in such files, first save them as the corresponding docx, pptx, and xlsx files using the Save As menu option. Then you can click on an equation object and get a menu/dialog that offers “Convert Equation to Office Math” and an option to “Apply to all equations”.
PowerPoint displays OLE objects on a slide wherever you put them. The objects are not embedded in the text of text boxes and hence don’t flow with text. For example, if you line up an equation object with text in a text box and change the text size, the text moves, but the equation object doesn’t move since it’s not part of the text. This differs from Word, for which OLE objects are embedded in the text and therefore flow with text changes.
The equationeditor converter converts OLE objects to native math (OfficeMath) text. To put the OfficeMath for a converted object onto a PowerPoint slide, the OfficeMath is stored in its own OfficeArt text box, which has the same dimensions as the original OLE object. People often position a set of equation objects to lay out equations nicely. Ideally all these objects would end up properly aligned in a single text box. But that’s a tricky recognition task and it isn’t handled by the converter. Users may want to do some cutting and pasting to get optimal results. The same approach is used for converting MEE objects in Excel.
In Word, equation objects are embedded in the text and the corresponding OfficeMath text replaces the objects in that text. So, equation conversion in Word doesn’t have object/text alignment problems, although line and page breaks may change due to the use of different fonts. OfficeMath requires a math font for characters supported by a math font, while MEE and MathType use a collection of nonmath fonts that can be customized by the user.
The MEE object EquationNative binary data (described in later sections) includes relative font sizes but doesn’t provide an overall default font size. For example, if you resize an equation object in PowerPoint, the EquationNative binary data doesn’t change nor do the text sizes in the Windows metafile used to display the object. If the converted math text is too large for its text box, PowerPoint decreases the font size to fit. In any event, the converted math text typically has a different size from that in the original OLE object.
There are two kinds of fixups performed by the converter: 1) those handling differences in the math models as described in Integrands, Summands, and Math Function Arguments and Subscript and Superscript Bases, and 2) those dealing with equation object errors that don’t affect the object display significantly but change the display of the converted math text. For example, in OfficeMath, empty numerators, denominators, subscripts, superscripts, etc., display the placeholder character ⬚. Since the OLE objects don’t display such a character, the converter fixes up equations by removing empty subscripts and converting left subscripts with no bases into normal (right) subscripts. Similarly, if a math function name like “min” doesn’t have an argument, the converter treats the function name as ordinary text, rather than as a functionapply object with an empty base. In testing PowerPoint presentations, we found many such errors including an extreme case of an MEE subscript object with a subscript consisting of a “pile” of four empty lines. The converted math text shows a column (equation array) of four ⬚’s although the original object shows nothing. It seems reasonable to have the user delete errors that are that complicated. MEE and MathType use the deprecated codes U+2329 and U+232A for the wideangle brackets ⟨ (U+27E8) and ⟩ (U+27E9), respectively. The converter replaces the former pair by the latter pair. It also changes the upper limit construction for ≝ into the single character (U+225D).
Now things get more technical. The converter is implemented as part of RichEdit and uses the same TOM interfaces as the UnicodeMath/LaTeX/speech/braille build up/down facilities. The Office RichEdit dll (riched20.dll) exports three conversion functions: ConvertEquationFromStorage() converts the object given by an IStorage interface, ConvertEquationFromOleStream() converts the object given by the OLESTREAM Get() method (prototype defined in ole2.h), and ConvertEquationFromStdVector() converts the equation binary data in the “Equation Native” stream. These functions don’t call operatingsystem OLE functions; hence they can be used on all major platforms. The prototypes for the functions are
HRESULT ConvertEquationFromOleStream( ITextRange2 * prg, ITextStrings2 * pstrs, OLESTREAM * poleStream, // OLE stream to read from BYTE bVersion) // Design Science MathType version # HRESULT ConvertEquationFromStorage( ITextRange2 * prg, // Range for inserting result ITextStrings2 * pstrs, // Richtext string stack IStorage * pstg) // IStorage for OLE math object HRESULT ConvertEquationFromStdVector( ITextRange2 * prg, ITextStrings2 * pstrs, std::vector<BYTE> & EquationNative, // "Equation Native" binary stream BYTE bVersion) // Design Science version # (3EE3, 5MathType)
The interface ITextStrings2 is defined in the Office tom.h (eventually it’ll be in the Windows tom.h) and derives from ITextStrings. It adds the method
ITextStrings2::Rotate(LONG iString)
ITextStrings2::Rotate(2) reorders the Design Science Nary arguments to put the naryand (integrand, summand, …) third instead of first. ITextStrings2::Rotate(1) is the same as ITextStrings::Swap() and swaps the top two strings. If the Type argument of ITextStrings::EncodeFunction() has the tomTeXStyleIsTextColor flag set, the TeXStyle argument has the text color instead of the TeXStyle. The TeXStyle isn't used by the converter since it’s implied by context (although it is stored in the OLE object binary data).
ConvertEquationFromStorage() calls IStorage::OpenStream(L”Equation Native”, …) to retrieve the Design Science OLE object’s “Equation Native” stream and then calls the converter to create the corresponding native math zones.
ConvertEquationFromOleStream() reads a Design Science object's compound file format, defragments it, retrieves the “Equation Native” stream, and calls the converter to create the corresponding math zones.
ConvertEquationFromStdVector() converts the "Equation Native" binary stream to a builtup Office math zone. This function is handy for unit tests. Enter with the EquationNative std::vector<BYTE> starting with the byte following the two "Equation Native" stream headers. The “Equation Native” binary format is illustrated in the next section.
The Design Science OLE object "Equation Native" stream contains the MTEF binary data for a MathType or MEE object. The MTEF data consists of a 28byte equationOLE header, a version header (5 bytes for MEE and 12 bytes for MathType) followed by the records for the equation. Container records (rcdLINE, rcdTMPL, rcdPILE, rcdMATRIX) can contain other records including themselves and are terminated by the end record rcdEND. For full documentation, see MathType's Equation Format (MTEF) in the MathType SDK (http://www.dessci.com/en/reference/sdk/).
The following table illustrates the Equation Editor 3.0 binary records for the equation
The two headers in the EquationNative stream are omitted. Putting the binary into a std::vector<BYTE> and passing it to ConvertEquationFromStdVector(), you insert this equation into the text. Be sure to convert the ASCII hex characters to binary, two per byte with no intervening spaces. Note that the integrand precedes the integral limits. In OfficeMath, the integrand follows the limits, hence the need for ITextStrings2::Rotate().
binary  meaning 
0a 01 030e0000 01 02883100 00 01 02883200 0284c003 00 00 03150200 01 030e0000 01 12836400 0284b803 00 01 12836100 02862b00 12836200 12827300 12826900 12826e00 0284b803 00 00 00 0b 01 02883000 00 01 02883200 0284c003 00 0d 02862b22 00 0a 02863d00 030e0000 01 02883100 00 01 030d0000 01 12836100 030f0000 0b 11 01 02883200 00 00 0a 02861222 12836200 030f0000 0b 11 01 02883200 00 00 00 11 00 00 00 00 
<normal size/> <line> <fraction> <line> (numerator) 1 </line> <line> (denominator) 2𝜋 </line> </fraction> <integral> <line> (integrand) <fraction> <line>𝑑𝜃</line> <line> 𝑎 + 𝑏 sin 𝜃 </line> </fraction> </line> <script size/> <line>0</line> (lower limit) <line>2𝜋</line> (upper limit) <symbol size/> ∫ (character) </integral> <normal size/> = <fraction> <line>1</line> (numerator) <line> (denominator) <root> <line> 𝑎 <sup> <sup size/> <line/> (null subscript) <line>2</line> </sup> <normal size/> − 𝑏 <sup><sup size/><line/><line>2</line></sup> </line> (end radicand) <line/> (no degree, i.e., square root) </root> </line> </fraction> </line> 
]]>
Format  Naryand  Math function arg  Sub/sup base 
OMML  explicit  explicit  explicit 
Presentation MathML  no  no  explicit 
Content MathML  explicit  explicit  explicit 
[La]TeX  no  no  no 
UnicodeMath  explicit or implied  explicit or implied  explicit or implied 
MathType/Equation Editor  explicit  no  no 
Nemeth math braille  no  no  no 
It’s clear that a math function argument or an Naryand should include the first entity that follows the base object. For example, for sin 𝑥, 𝑥 is the argument. Or for the summation (in Nemeth math braille ⠐⠨⠠⠎⠩⠝⠀⠨⠅⠀⠴⠣⠠⠝⠻⠁⠰⠝⠐)
𝑎_{𝑛 }is the summand. But what about the integral (⠮⠰⠴⠘⠠⠿⠐⠑⠘⠤⠭⠘⠘⠆⠐⠙⠭)
If you only include the exponential (⠑⠘⠤⠭⠘⠘⠆⠐), you omit the 𝑑𝑥.
Ideally the Naryand is delimited explicitly. Presentation MathML has the <mrow> entity which can contain multiple MathML entities. A natural way to represent a math function argument or an Naryand is to put them inside <mrow>…</mrow> as in (omitting mml: prefix and xmlns field)
<math> <msubsup> <mo stretchy="false">∫</mo> <mn>0</mn> <mo>∞</mo> </msubsup> <mrow> <msup> <mi>e</mi> <mrow> <mo>−</mo> <msup> <mi>x</mi> <mn>2</mn> </msup> </mrow> </msup> <mi>d</mi> <mi>x</mi> </mrow> </math>
In [La]TeX, enclose the Naryand in {…} as in \int_0^\infty{e^{x^2}dx}. Notice how much more concise [La]TeX is. Delimiting Naryands in these ways constitutes best practice. It’s also best practice to delimit math function arguments these ways in MathML and LaTeX.
When the Naryand isn’t delimited explicitly by notation such as <mrow>…</mrow>, the first math object following the Nary operator (with limits) should be part of the integrand. If this object is a delimiter object, such as {…} (\{…\} in TeX), a compound Naryand is well defined. But if it’s a concatenation of math objects as in the integral (⠮⠰⠴⠘⠠⠿⠐⠑⠘⠤⠭⠘⠘⠆⠐⠙⠭)it’s more than just the first object. It’s tempting to choose the concatenation of objects up to a binary operator of precedence of addition or to the end of the expression, whichever comes first. Such concatenation gives the correct result in this case. UnicodeMath has the concept of an argument that consists of such concatenations. This would also work for Nemeth math braille, which has no way of delimiting Naryands or function arguments explicitly.
UnicodeMath attempts to look like a math notation as closely as a linear format can. But when an expression becomes too ambiguous, UnicodeMath encloses the expression in lenticular brackets 〖…〗(see Sec. 3.4 of that reference). As such, the integral above is written as ∫_0^∞▒〖e^(x^2 ) dx〗in UnicodeMath. Here ▒ is the “glue” operator that connects the Naryand to its large Nary operator. But clearly UnicodeMath could use its definition of an argument to get the correct integrand in this case. I didn't code this refinement up for Office applications because the input method automatically puts the insertion point into the integrand as soon as a space builds up the integral operator. The same approach is used for entering function arguments. This makes it easy to type sin x+y, where x+y is the argument of the sine. To get out of the Naryand or function argument, the user types an arrow key or clicks a mouse button. In the absence of the glue operator, it does seem like a good idea for UnicodeMath to capture a concatenation of objects for a Naryand as it does for arguments of fractions, subscripts, etc.
]]>To get the alt text for an equation image, type F12 in your browser (I use Edge for this). This turns on a window with source browsing capabilities. At the top left side is the inspect tool, a little arrow with a rectangle. Click on the inspect tool and then on an equation. Let’s illustrate using the timedependent Schrödinger equation, which is described nicely in Wikipedia. We see the figure
Copy the text highlighted in blue. This gives the HTML for the equation image
<img class="mwemathfallbackimageinline" ariahidden="true" style="verticalalign: 2.505ex; width:41.97ex; height:6.343ex;" alt="i\hbar {\frac {\partial }{\partial t}}\Psi (\mathbf {r} ,t)=\left[{\frac {\hbar ^{2}}{2\mu }}\nabla ^{2}+V(\mathbf {r} ,t)\right]\Psi (\mathbf {r} ,t)" src="https://wikimedia.org/api/rest_v1/media/math/render/svg/f2ae69999ed8b8551b217b9fbdcd8bf73490c82f">
The image alt text is given by the alt="…" field. The LaTeX for the equation is inside the "…". Copy the LaTeX into a Word math zone and build it up in LaTeX mode (type Ctrl+=). You then see
which looks the same as in the browser aside from a change in font.
Back in 2009 I gave a lecture featuring highlights of my PhD advisor Willis Lamb’s life work. I knew his laser theory contributions quite well having written papers and a book with him on laser theory. But I didn’t know his Nobelprize work on the Lamb shift or his theory of the Mössbauer effect very well. So, I read up on these phenomena in Wikipedia, copied the LaTeX for some equations into an alpha version of PowerPoint 2010, and built them up using an early version of the LaTeX converter code. I gave the lecture at a memorial symposium for Lamb at the University of Arizona’s Optical Sciences Department, wondering if anyone would ask how I prepared the equations in the slides. It was more than a year before Office Math shipped in PowerPoint. Fortunately, no one asked. Perhaps people assumed I had used images from Word or LaTeX. (But how then could the background match the slide pattern so well? )
]]>The information in this post is useful if you’re considering whether to convert MathType and/or Equation Editor OLE objects to native Office math zones, particularly if it becomes easy to convert them. If the conversions are faithful to the original semantics, you gain [La]TeX quality typography, inline editing and search and support across all platforms including iOS and Android. But if you use features only available with the original OLE objects, you’ll want to stick with MathType or MathType Lite. You can download MathType for free. It downgrades to MathType Lite in 30 days if you don’t pay for it, but that downgrade is a significant upgrade from the Equation Editor. Note that if your computer doesn’t have the MT Extra font needed for some Equation Editor symbols, you can download it from here.
This post doesn’t compare the user interfaces (UI) between the products, although that would make for interesting blog post(s). The UI varies considerably and if you’re used to MathType and its hot keys, you may find it harder to enter math into native Office math zones. But it’s mostly a question of what you’re used to. The Office math autocorrect facility is handy, and you can define your own control sequences. MathType and Office apps support [La]TeX, in case you prefer [La]TeX, and they support math pen input (Windows Math Input Panel).
Here’s the summary comparison table
Format  Long division...  Matrix lines...  User spacing  Symbols  Templates 
MathType  1 or 2 lines  Row/column  Nudges  Unicode 2.1++  Yes 
Equation Editor...  1 or 2 lines  Row/column  Nudges  Unicode 2.1+  Yes 
Office Math  No  No  Unicode, phantom...  Unicode 11  Yes 
Both MathType and the Equation Editor support one and twoline long division expressions such as Multiline long division expressions that have intermediate divisions shown below the baseline can be handled by multiple lines with enough nudges. With lots of effort using a flushright tab and nudges, I managed to produce the multiline longdivision expression
But since this takes a lot of effort, there probably aren’t many multiline longdivision expressions in EquationEditor objects (unless there’s an easier way to create them). Office Math has no provision for long division.
MathType and the Equation Editor support lines above and below any row in a matrix and left and right of any column. The lines are defined by the values: 0 for none, 1 for solid, 2 for dashed, and 3 for dotted. For example, you can put lines before and after every row and column as in the 2×2 matrixOffice Math doesn’t support such lines.
Math typography has welldefined rules for horizontal and vertical spacing of symbols and structures as described in the post User Spaces in Math Zones. In most cases, added user spacing detracts from the quality of math typography and is discouraged. Nevertheless, there are occasions where users may want to change the spacing. All three formats have ways to do this, but they are not necessarily interchangeable. In Office Math you can insert any Unicode space to increase spacing and you can remove or add precise spacing via smashes and other phantoms (see Section 3.17 of UnicodeMath). MathType and the Equation Editor don’t have phantoms, but they do have nudges. To nudge text and objects, select what you want to nudge and move it using the arrow keys while holding the Ctrl key down. The nudge offset can vary between −32768 and 32767. For rarely used mathematical special purposes, such flexibility could be useful, and Office Math has no counterpart. I used nudges in simulating the multiline long division above. It can also be useful in nonmathematical contexts. Note that the nudge values do not scale with the font height.
MathType lets users change the math spacing for math quantities, while Office Math gets those values from the math font’s OpenType MATH table. Math fonts such as Cambria Math use values compatible with [La]TeX, the publishing industry’s math standard. MathType lets you define intraline spacing in multiline equations. Office Math does too, but it’s not currently exposed in the Office apps.
MathType also has a ruler for defining tab settings. In apps like Word, such settings don’t apply in math zones, so this might be a consideration in deciding whether to convert Design Science OLE objects to native math zones. The Equation Editor 3.0 menu doesn’t have a ruler, so it’s not clear how a user could define the tab settings. But the Equation Editor file format includes the tabs and their settings.
MathType and the Equation Editor are based on Unicode 2.0 (1996), while Office Math uses the current Unicode Standard. The math alphanumerics were added in Unicode 3.1 (2002) and many math operators were added in Unicode 3.2 (2002) (see DerivedAge.txt). A few more mathematical symbols have been added since then, notably the long division symbol ⟌... in Unicode 5.1. 364 characters have the math property in Unicode 2.0, while the current Unicode Standard has 2310 math characters. Because of the importance of many of these symbols, particularly the math alphanumerics, MathType has some nonUnicode ways of accessing symbols that weren’t defined in Unicode 2.0. There are also some symbols that MathType supports, e.g., the Apple logo (see character code 0xE7 of MT Extra 4.30), that Office Math doesn’t support natively, although you can insert normal text in a math zone formatted with any font. Office Math supports almost all math symbols in the Unicode math symbol set, which has many symbols not available in MathType. Office Math supports ISO standard math fonts, while MathType does not.
In Office Math if you don’t want to use a math font for symbols that appear in a math font (almost all mathematical symbols), then you have to mark the symbols with the “Text” attribute and you lose automatic mathematical spacing. When the “Text” attribute is used, any characters from any font can be inserted into a math zone.
For a complete listing of MathType symbols, see MTCode Encoding Table and Font Encoding Tables. For descriptions of the Unicode math symbol set see Unicode Technical Report #25 and UnicodeMath. If you’re converting from the Equation Editor or MathType to Office Math, it’s unlikely that you’ll lose any symbols. MathType can’t handle math alphanumerics in the U+1D400..1D7FF block since it can only handle Unicode characters with codes < 0x10000. It simulates common math alphanumerics using font styles with ASCII and Greek characters. The Unicode math alphanumerics are summarized along with MathType support in the following table adapted from Section 2.2 of UTR #25
Math Style  Characters from Basic Set...  Location...  MathType  
plain (upright, serifed)  Latin, Greek and digits  BMP  Yes  
bold  Latin, Greek and digits  Plane 1  Yes  
italic  Latin and Greek  Plane 1*  Yes  
bold italic  Latin and Greek  Plane 1  Yes  
script (calligraphic)  Latin  Plane 1*  Yes  
bold script (calligraphic)...  Latin  Plane 1  No  
Fraktur  Latin  Plane 1*  Yes  
bold Fraktur  Latin  Plane 1  No  
doublestruck  Latin and digits  Plane 1*  Yes  
sansserif  Latin and digits  Plane 1  No  
sansserif bold  Latin, Greek and digits  Plane 1  No  
sansserif italic  Latin  Plane 1  No  
sansserif bold italic  Latin and Greek  Plane 1  No  
monospace  Latin and digits  Plane 1  No 
Here * means that some of the characters are in the Letterlike block U+2100..U+214F.
The following symbols are in MathType’s MTCode Encoding Table, but not in Unicode (although usually there are Unicode symbols with the same semantics). The codes given are in the Unicode Private Use Area and, as such, depend on the font used.
E949  Lazy S (Unicode considers this to be a glyph variant of reversed tilde U+223D ∽) 
E94E  Alias delimiter, E954 Round implies 
E955  Smile under bar, E956 Frown over bar 
E959  Greaterthan almost equal to or lessthan 
E95A  Lessthan almost equal or greaterthan 
E966  Equals with dotted top line 
E967  Precedes with colon, E968 Succeeds with colon 
E97A  Paired quadruple vertical dots 
E986..E989...  Dashed solidus, dashed backslash, dashed midline, dashed vertical bar 
E98E  Vertical bar with double hook 
E98F  Medium dot operator (free radical) 
E996  Vertical bar over circle 
E997  Vertical proportional to 
E998  Black last quarter moon 
E999  Black first quarter moon 
E99A  Negative sine wave 
E9E0  Precedes equivalent to or succeeds 
E9E1  Succeeds equivalent to or precedes 
E9E2  Precedes almost equal to or succeeds 
E9E3  Succeeds almost equal to or precedes 
EB00..EB6F  Has quite a few missing arrows and negations 
The Equation Editor 3.0, MathType and Office Math all have template menus for various kinds of fractions, integrals, matrices, accents, subscripts, superscripts, etc. MathType and Word’s Office Math let users save templates and equations for quick recall. In addition, Office Math has the math autocorrect facility, which allows users to assign templates and equations to mathautocorrect control words. For example, “\integral” is predefined to insert the equation
You can add others using the math ribbon Equation Tools/Equations Option dialog.
One cool way to enter an n×m matrix template is to type alt+= to enter a math zone, then \matrix(&…&@...@) where &…& consists of m − 1 &’s and @...@ consists of n − 1 @’s. So a 3×3 matrix template is given by \matrix(&&@@), which you can type pretty quickly.The \matrix() construct is designed to produce a rectangular matrix, so you only have to enter &’s for the first row.
]]>If you select a pair of equations like
2𝑥 + 3𝑦 = 5
3𝑥 − 4𝑦 = 7
you can ask the math assistant to solve for 𝑥 and 𝑦 getting 𝑥 = 41/17, 𝑦 = 1/17. You can also ask it to show the steps in the derivation by three methods: substitution, matrices, and elimination. It’s like a live teacher! In these simultaneous equations, options don’t appear if you use letters as coefficients.
Two formulas that appear in laser theory as well as other areas of physics are the Gaussian and the Lorentzian
These are normalized so that their integrals from −∞ to ∞ equal 1. Entering these into OneNote and clicking on the Math icon, we can graph them as
Notice how the Gaussian (brown curve) approaches 0 for large 𝑥 much faster than the Lorentzian (blue curve). In the math panel below the graph, there’s an entry window for changing the value of the coefficient 𝑎
For a cool demo showing how you can enter equations with a pen and graph them, check out Mina Spasic’s post on the OneNote math assistant.
Universal OneNote doesn’t have the math ribbon that OneNote 2016 has, but OneNote 2016 doesn’t have the builtin math assistant. If you want to enter equations into either version with a keyboard, type alt+= to insert a math zone and start typing UnicodeMath. The equations build up in front of your eyes! You can switch to LaTeX input by typing 24c9 alt+x to enter Ⓣ or add it to your math autocorrect as \TeX and type that to switch. You can switch back to UnicodeMath by typing 24c1 alt+x to enter Ⓛ. My favorite way to enter math is with a keyboard using UnicodeMath, but admittedly I’m a bit biased . Alternatively, draw in the equations with a pen. At some point people will stop insisting that math is hard!
]]>As noted in Section 3.10 Accent Operators of the UnicodeMath specification, the most common math accents are (along with their TeX names)
These and more accents are described in Section 2.6 Accented Characters and 3.2.7 Combining Marks in Unicode Technical Report #25, Unicode Support For Mathematics. More generally, the Unicode ranges U+0300..U+036F and U+20D0..U+20EF have these and other accents that can be used for math.
The Windows Character Map program shows that the Cambria Math font has all combining marks in the range 0300..036F as well as 20D0..20DF, 20E1, 20E5, 20E6, 20E8..20EA. The range 0300..036F used as math accents in Word looks like
Except for the horizontal overstrikes and the doublecharacter accents shown in red, all these work as math accents in Microsoft Office apps, although many aren’t used in math. In keeping with the Unicode Standard, UnicodeMath represents an accent by its Unicode character, placing the accent immediately after the base character. There’s no need for doublecharacter accents in Microsoft Office math since the corresponding “single” character accents expand to fit their bases as in
In UnicodeMath, this is given by (a+b)~, where ~ can be entered using the TeX control word \tilde. This is simpler than TeX, which uses \widetilde{a+b} for automatically sized tildes rather than \tilde{a+b}.
The combining mark in the range 20D0..20EF that work as accent objects in Office math zones areYou can test accents that don’t have TeX control words by inserting a math zone (type alt+=), type a nonhex letter followed by the Unicode value, alt+x, space. For example, alt+=, z, 36F, alt+x, space gives
MathML 1 was released as a W3C recommendation in April 1998 as the first XML language to be recommended by the W3C. At that time, Unicode was just starting to take hold as Microsoft Word 97 and Excel 97 had switched to Unicode. [La]TeX was developed before Unicode 1.0, so it relied on control words. Accordingly, it was common practice in 1998 to use control words or common spacing accents to represent accents instead of the Unicode combining marks even though many accents didn’t have a unified standardized representation. Unicode standardized virtually all math accents by using combining marks. One problem with using the combining marks in file formats is that they, well, combine! So, it may be difficult to see them as separate entities unless you insert a nobreak space (U+00A0) or space (U+0020) in front of them. UnicodeMath allows a nobreak space to appear between the base and accent since UnicodeMath is used as an input format as well as in files. Only programmers need to look at most file formats (HTML, MathML, OMML, RTF), so a reliable standard is more important for file formats than userfriendly presentation.
MathML 3’s operator dictionary defines most horizontal arrows with the “accent” property. In addition, it defines the following accents
02C6 ˆ modifier letter circumflex accent
02C7 ˇ caron
02C9 ˉ modifier letter macron
02CA ˊ modifier letter acute accent
02CB ˋ modifier letter grave accent
02CD ˍ modifier letter low macron
02D8 ˘ breve
02D9 ˙ dot above
02DA ˚ ring above
02DC ˜ small tilde
02DD ˝ double acute accent
02F7 ˷ modifier letter low tilde
0302 ̂ combining circumflex accent
0311 ̑ combining inverted breve
Presumably the operator dictionary should be extended to include more math combining marks and their equivalents, if they exist, with the spacing diacritics in the range U+02C6..U+02DD.
Here’s the MathML for the math object 𝑎̂.
<mml:mover accent="true">
mm<mml:mi>a</mml:mi>
mm<mml:mo>^</mml:mo>
</mml:mover>
“Office MathML” OMML is the XML used in Microsoft Office file formats to represent most math. It’s an XML version of the inmemory math object model which differs from MathML. The math accent object 𝑎̂ has the following OMML
<m:acc>
mm<m:accPr>
mmmm<m:chr m:val=" ̂"/>
mmmm<m:ctrlPr/>
mm</m:accPr>
mm<m:e>
mmmm<m:r>
mmmmmm<m:t>𝑎</m:t>
mmmm</m:r>
mm</m:e>
</m:acc>
The Rich Text Format (RTF) represents math zones essentially as OMML written in RTF syntax. Regular RTF uses the \uN notation for Unicode characters not in the current code page. The math accent object 𝑎̂ has the RTF
{\macc{\maccPr{\mctrlPr\i\f0\fs20 }{\mchr \u770? }}{\me\i\u10187?\u9138?}}
Unicode RTF is easier to read since characters are written in Unicode
{\macc{\maccPr{\mctrlPr\i\f0\fs20 }{\mchr ̂}}{\me\i 𝑎}}
But none of these is as simple as the UnicodeMath 𝑎 ̂ .
]]>
The RTF specification doesn’t have a control word for GIF images, although it has \jpegblib for jpeg’s and \pngblip for png’s. One way to persist GIFs would be to define a \gifblip. But this approach has the disadvantages that RTF readers that don’t recognize \gifblip would either discard the image altogether or fall back to an alternate format if one is included in the RTF stream. RichEdit’s earlier choice of converting the GIF to a png saves only the initial frame. A simple observation reveals how to solve both problems: the RTF reader isn’t, and furthermore shouldn’t be, responsible for the image format. Instead the program that interprets the image binary data should recognize the image format and validate the data. This is essential for security reasons. Accordingly, RichEdit just uses the \pngblip control word for a GIF even though the binary data defines a GIF! This interoperates with Word, older RichEdit clients, etc. Human readers of RTF can know the difference if they want to by looking at the image data, which starts with “PNG” for a real png and “GIF” for a GIF. The decoding of the images on Microsoft and Android operating systems is performed by the Windows Imaging Component (WIC), which also validates the images. Currently the RichEdit image facility isn’t supported on Apple platforms, but that may change.
When reading a GIF from RTF or via one of the APIs, RichEdit calls WIC to convert the image to a WIC bitmap. RichEdit saves memory space by not storing the original image data, since that data can be faithfully recovered from the WIC bitmap including all metadata.
Animated GIFs vary appreciably in size, ranging from 50 kilobytes for simple cartoon animation like
to several megabytes, such as this 1megabyte GIF from the movie Singin’ in the Rain
When exported in RTF files, the size doubles since each binary byte is represented by two hexadecimal bytes. So, it’s wise not to insert animated GIFs excessively.
The GIF format is described very well on the web, but here are a few quick thoughts before explaining how GIF animation works in RichEdit. First, GIF metadata is essential for animation. It controls the frame rate on a perframe basis, the color palette(s) and how the current full image is used in composing the next image. In fact, several partial frames along with the current full image may be combined to create the next displayed frame. Such intermediate frames have “0delay”, that is, they are included in the composition without being displayed. Some programs display them anyway (see the Windows photo viewer and the animated GIF sample), but I, at least , think that’s misunderstanding the purpose of 0delay intermediate frames. In fact as discussed further below, some multiframe GIFs use the extra frames purely for refining the image colors, since a single frame is limited to 8bit color and one color palette.
Each animated GIF gets its own timer in this model since use of a shared timer ends up slowing down the animations. The time delays between frames may be the same or they can vary substantially, such as in the GIF
Animation is enabled/disabled via calling ITextDocument2::SetProperty(tomAnimateImages, Value), where tomAnimateImages is given by 0x95 and Value = tomTrue/tomFalse, respectively. A client that enables animation guarantees that the ID2D1RenderTarget supplied in the call to ITextServices2::TxDrawD2D() remain valid between calls. By default, animations are disabled since previous clients don’t know about this requirement.
Animations only work in Direct2D/DirectWrite mode. Initial attempts to get them running in GDI/Uniscribe mode display the animated images correctly except with a black background. This could be fixed if there is a need for animations in GDI mode.
Animations are disabled for selected images. This allows the user to recognize when images are selected. They are also disabled when the RichEdit control loses the focus. If a GIF has a maximum loop count, the animation stops after reaching that count.
Clients can get an image IStream by calling ITextRange::GetEmbeddedObject() to get the image’s IUnknown interface, then calling IUnknown::QueryInterface for an IServiceProvider interface and finally calling IServiceProvider::QueryService() to get the image IStream. This works for all kinds of images, not just GIFs.
GIFs with frames that all have zero frame delays display only the composite final frame. The multiple frames are typically used to get a composite image that has higherresolution color than possible with a single 8bit color palette. The Windows photo viewer nevertheless tries to animate such GIFs so the user sees fluctuating colors. PowerPoint presentation mode displays the correct composite image after one animation sequence, but Word only shows the first frame. See HighColor GIF Images for a detailed discussion of the following stationary multiframe GIF with highresolution color.
]]>Word’s current help facility does not document the EQ field, although it works as designed. In case you need to know more about the EQ field, this post gives documentation adapted from earlier Word help files.
Up until this month, a user could convert an EQ field into an Equation Editor OLE object. But starting this month, that is not possible since the Equation Editor is no longer available due to security concerns. See Error when editing an equation in Office for further information. One work around is that MathType can convert an EQ field into a MathType object. If you’ve been using the Equation Editor, it’s very worthwhile to install MathType. You can download MathType for free with the full features for 30 days and after that it still has more features than the Equation Editor, as well as being uptodate security wise. Alternatively, you might want to check out https://0patch.blogspot.com/2018/01/bringingabandonedequationeditorback.html. Even with that approach, it’s not easy to restore the Equation Editor since you have to reinstall the original eqnedt files and edit the registry.
Word help does document most fields such as SaveDate. To insert a field using Word’s ribbon, click on Insert/Quick Parts/Field…, which brings up a dialog. Scrolling down to Eq and clicking on Field Codes and then on Options, you can see
The options dialog lists the switches along with a brief description. It doesn’t give any switch options, at least some of which are needed for all but the most basic arithmetic. Once an EQ field is inserted, you can use the Toggle Field Codes contextmenu option to toggle back and forth between displaying the builtup equation and the linear {EQ…} text. In the latter, you can insert Unicode math alphanumerics and add spacing to improve the typography (see examples in Other Office Math Editing Facilities). The EQ field examples in this post don’t have these enhancements.
The EQ field produces mathematical expressions given by the switches. The switches specify how to build the equation with the elements, which are enclosed in parentheses. You can modify the behavior of a switch by following it with one or more switch options. A switch consists of a backslash (\) followed by a single letter. An option consists of a backslash followed by two letters and sometimes a number. Either EQ or eq can be used.
Some switches take a list of elements separated by commas or semicolons. Use commas as the separators if the decimal symbol for your system is a period. If the decimal symbol for your system is a comma, use semicolons.
To use a comma, open parenthesis, or backslash character in a resulting equation, precede the symbol with a backslash: \, \( \\.
Switch  Action 
array: \a()  Draw a twodimensional array 
bracket: \b()  Bracket a single element 
displace: \d()  Move next character to left or right a specified number of points 
fraction: \f(,)  Create a fraction 
integral: \i(,,)  Create an integral, summation or product using the specified symbol or default symbol and three elements 
list: \l()  Group values in a list, which can then be used as a single element 
overstrike: \o()  Display each successive element on top of the previous one 
radical: \r(,)  Draw a radical sign, using one or two elements 
superscript or subscript: \s()  Position elements as superscripts or subscripts 
box: \x()  Draw a border around an element 
The following sections describe each of these switches along with their options. The spaces shown in the tables between the options and the numeric value n are present only for readability; they can be omitted. In the switch examples, the linear native math zones are given in UnicodeMath. Typing the UnicodeMath text into a math zone (type alt+= to insert a math zone) and then ctrl+= converts it to the builtup (Professional) display to the right of the UnicodeMath.
Display an array (matrix) of elements in multiple columns. The elements appear in order by rows. The following options modify the \a switch
Option..  Action 
\al  Align left within columns 
\ac  Align center within columns 
\ar  Align right within columns 
\co n  Array elements in n columns (default is 1) 
\vs n  Add n points of vertical spacing between lines 
\hs n  Add n points of horizontal spacing between columns 
Example
{ EQ \a \ac \co2 \vs3 \hs3(Axy,Bxy,A,B) }  
\matrix(Axy&Bxy@A&B) 
Enclose an element with bracket(s) sized to fit the element. The default brackets are parentheses. The options listed in the following table can modify the \b switch.
Option..  Action 
\lc\c  Draw left bracket using the character c. 
\rc\c  Draw right bracket using the character c. 
\bc\c

Draw both bracket characters using the character specified for c. If the character you specify is {, [, (, or <, Word uses the corresponding closing character as the right bracket. If you specify any other character, Word uses that character for both brackets. 
Example
{ EQ \b \bc\{ (\r(3,x)) }  
{\sqrt(3&x)} 
Displace the next character according to the option(s) for the \d switch. The empty parentheses follow the last option. This switch doesn’t have a counterpart in native math zones, but Unicode spaces can be entered as desired in native math zones.
Option..  Action 
\fo n ()  Displace n points to the right 
\ba n ()  Displace n points to the left 
\li ()  Underline the space up to the next character 
Example
"Before { EQ \d \fo10 \li() } after" displays Before __ after
Create a fraction with the numerator centered over the denominator. If your system uses a comma as the decimal symbol, separate the two elements with a semicolon.
Example
{ EQ \f(2,RateChange) }  
2/"RateChange" 
Create an integral, summation or product using the specified symbol or default symbol and three elements. The first element is the lower limit, the second is the upper limit, and the third is the integrand, sum or product. The options listed in the following table modify the \i switch. By default the nary symbol is ∫.
Option..  Action 
\su  Change nary symbol to Σ and create a summation 
\pr  Change nary symbol to Π and create a product 
\in  Use inline formatting (display limits to right of the nary symbol instead of above and below) 
\fc\c  Substitute a fixedheight character specified by c for the nary symbol 
\vc\c  Substitute a variableheight character specified by c for the nary symbol. The symbol matches the height of the third element. 
Example
{ EQ \i \su(n=1,5,n) }  
\sum_(n=1)^5 n 
Create a list of elements separated by commas or semicolons, so that multiple elements act as a single element. Native math zones don’t need this construct.
Example
{ EQ \l(A,B,C,D,E) } displays A,B,C,D,E
Place each successive element on top of the previous one. Any number of elements is allowed. Separate multiple elements with commas. Each character is printed within an invisible character box. Options align the boxes on top of one another. This functionality can be obtained using the phantom operators (see Section 3.17 of the UnicodeMath specification) in native math zones. The following options modify the \o switch
Option..  Align character boxes 
\al  At left edge 
\ac  In the center (default) 
\ar  At right edge 
Example
{EQ \o(J,w) }  
\hsmash(J)w 
Draw a radical using one or two elements.
{ EQ \r(n,x) }  
\sqrt(n&x) 
Place an element or elements as superscript or subscript characters. Each \s code can have one or more elements; separate the elements with commas. If more than one element is specified, the elements are stacked and leftaligned. The following options place single elements after the \s switch
Option..  Action 
\ai n ()  Add n points of space above a line in a paragraph 
\up n ()  Move a single element above the baseline by n points. The default is 2 points 
\di n ()  Add n points of space below a line in a paragraph 
\do n ()  Move a single element below the baseline by n points. The default is 2 points 
Example
a{eq \s\do4(b{eq \s\do3(c)})}  
a_b_c 
Create a border for an element. When used without options, this switch draws a box around the element. The following options modify the \x switch
Switch..  Draws a border 
\to  above element 
\bo  below element 
\le  left of element 
\ri  right of element 
Example (Word currently ignores the 12& in the UnicodeMath, but its context menu lets you hide borders)
{ EQ \x \to \bo(5) }  
\rect(12&5) 
The arrangement of these examples is the {eq…} field on a line followed by a line with the corresponding UnicodeMath followed, in turn, by the builtup displays of the eq field and UnicodeMath. The symbol [boxed fn] can be entered by \funcapply (there are easier ways to type it and the integrals if one can use the → key)
{ eq \a\ac\vs1\co1(lim,n→∞) \b(\f(n,n^{2} + 1^{2}) + \f(n,n^{2} + 2^{2}) + ... + \f(n,n^{2} + n^{2}))}
lim_(n→∞) (n/(n^2+1^2 )+n/(n^2+2^2 )+…+n/(n^2+n^2 ))
..... 
{ eq \I(,, \b(\f(x,x^{2} + 3x + 2)))\s\up10(2)}
∫ (x/(x^2+3x+2))^2 dx
..... 
{ eq \i\in( tan x, \s\up2(sec x), \b(\r(3) )\s\up4(t)\s\up7(2) dt)}
\int_(tan x)^(sec x) (\sqrt 3)^𝑡^2
..... 
{ eq \b\bc\(\i\in( 0, 1,f(t) dt)  \i\su(k=0,n1,\f(1,2n) \b\bc\[(f\b(\f(k+1,n)) + f\b(\f(k,n))))) ≤ \f(M,12n²)}
\int_0^1\of f(t)dt\sum_(k=0)^(n1)\of\begin 1/2n [f(k+1/n)+f(k/n)]\end\leq M/12n^2
..... 
{ eq \b(\a\ac\vs2\hs2\col3(cos θ,sin θ, 0, sin θ, cos θ, 0, 0, 0, 1))\s\up20(n)}
(\matrix(cos θ&sin θ&0@sin θ&cos θ&0@0&0&1))^n
..... 
{ eq f(x) =\b\lc\{(\a\al\vs3\hs14\col2(x,if x>0,0,if x=0,x,if x<0)) }
f(x)=\cases(x &"if" x>0@0 &"if" x=0@x &"if" x<0)
..... 
{eq eq \o(\o(x,\s\do6(~)),\s\up5(^))}
x\hat\below~
..... 
]]>
Acetate selection is discussed in RichEdit Colors. The principle is that the background color of the selected text is blended with the selection background color and the text is then painted on top with the regular text color. This differs from other selection methods, such as inverting the colors of the selected text, using different selection text and background colors, or enclosing selected text in rectangles. Office applications typically use acetate selection, whereas Windows apps such as Notepad use selection text and background colors. One advantage of acetate selection for RichEdit is that partial ligature selection doesn’t get clipped by the rectangular selection background. This is illustrated in the following image where the f of an fi ligature is selected
Since the f’s text color doesn’t change when selected, the f’s underhang and overhang aren’t clipped. In contrast without acetate selection, RichEdit appears to select the whole fi ligature and clips the f’s underhang since RichEdit doesn’t have the code to render the ligature glyph three times with appropriate text colors. You can try out acetate selection with an Arabic ligature too, e.g., type a lam aleph (لا – gh with an Arabic keyboard) and then shift+→ to select the lam alone. You’ll see the acetate highlight go half way thru the لا. Acetate selection in RichEdit works the same way as in Word.
Without acetate selection as in Notepad, RichEdit can clip overhangs and underhangs. For example, with selection text and background colors and no ligatures, selecting the f alone renders as
Notepad displays this text without clipping. Acetate selection is used by default in RichEdit. To disable acetate selection, send EM_SETEDITSTYLEEX with wparam = lparam = SES_EX_NOACETATESELECTION.
Nevertheless, even with acetate selection, RichEdit will clip in some scenarios. If the character format of adjacent space differs from that of a character with an underhang, the selection can clip it. For example, selecting “f” in RichEdit where the f is in Times New Roman and the leading space is in Segoe UI looks like
The f overhang is also clipped if the character following the f is selected but not the f. For some scripts, RichEdit automatically formats spaces with the same font as the character that precedes it. But ideally the code should display such scenarios enough times to paint all parts of a glyph with the appropriate background. This problem doesn’t occur in Word or Notepad.
The source of the problem is that RichEdit handles one characterformat run at a time, first painting the background and then the text. When the format background changes, the new background gets painted over any overhang from the preceding run. A fix would be to paint all the background colors for a line first and then paint the text on top. Alternatively, one could paint a glyph as many times as necessary to display the various parts of the glyph unclipped (as in Notepad).
In wellformed typography, the baselines between different fonts coincide. This increases the line height when fonts with different ascents and descents appear on the same line. This is particularly true when Latin and Japanese scripts appear together. No one font can cover all of Unicode; Version 10 has 136,755 characters and TrueType fonts are limited to a maximum of 65535 glyphs (16bit glyph indices). So multiple fonts must be used in general. Notepad, too, uses multiple fonts to display such text. As such virtually any editor has to have some degree of richtext capability as discussed more in RichEdit PlainText Controls.
To illustrate how the line height increases when an East Asian font is used on the same line as a Latin font, we select text with a single font and then with a combination. The selection background color reveals the resulting line height
A way to avoid baseline alignment is to send the message EM_SETEDITSTYLEEX with wparam = lparam = SES_EX_DONTALIGNBASELINE (0x00000800). This flag isn’t currently defined in MSDN, but should be. For the example above, this choice produces
which fits in the same vertical space as the Latin text alone.
Some Southeast Asian scripts can have glyph size or shaping that results in a large ascent and/or descent. This can make it hard to mix with other scripts and maintain the line height. Accordingly, font designers may leave little or no vertical padding for glyph clusters that push the limits. In singleline controls or when paragraph linespacingexactly is active, this may result in clipping. For example, consider the Thai character SARA AI MAIMUAN ใ (U+0E43). Enlarging it and showing the top and bottom glyph boundaries compared to the Latin letter A, we see that there’s no room for roundoff on the top
RichEdit clips the top of this letter unless there’s some paragraph spacebefore or linespacing exactly with enough extra vertical space. While space before/after can eliminate such clipping for a single line, inside a multiline paragraph, one has to use a large enough linespacingexactly value. One could argue that the font designers made a mistake by eliminating all vertical padding for these large glyphs, but text renderers now need to deal with it. This font nopadding “feature” differs from the high fonts used in mathematics and in fancy fonts, which can have ascents and descents appreciably larger than those for standard glyphs.
While RichEdit provides a way to disable baseline alignment and to specify a larger line height to avoid Southeast Asian large glyph clipping, it doesn’t handle all kinds of selection clipping. It would be desirable to fix the remaining selection clipping scenarios and to offer a mode where the line height is automatically increased to avoid clipping of large Southeast Asian glyphs in fonts that provide inadequate vertical padding.
]]>