The “\rect(a+b)” is the UnicodeMath representation of this boxed formula.

The post Rounded Rectangles and Ellipses appeared first on Math in Office.

]]>Mobile versions of Excel needed custom rounded boxes with background color for cell tokens in the formula bar. Accordingly, the RichEdit boxed-formula implementation was enhanced to offer that feature along with the ellipse. The Direct2D line styles are supported, and the line and background colors can be specified by COLORREFs. This post describes the user interfaces (UI) and APIs for creating such objects in a RichEdit control. Examples include

In Excel, it turned out that having a math zone in the formula bar complicated font binding. So RichEdit offers the same functionality in an Enclose object, which works in ordinary text.

Let’s start with the UI entry in a math zone. To insert an empty rectangle object, you can use UnicodeMath. For this note that each math object is associated with its own Unicode character. The character for the square rectangle is U+25AD, ▭. In a math zone, the text \rect autocorrects to ▭. The characters for the rounded box and ellipse are U+25A2 (▢) and U+2B2D (⬭), respectively. In the RichEdit math autocorrect, you can type \rrect for ▢ and \ellipse for ⬭. But you can also just type the hex character code followed by alt+x to insert the character. Then put the text you want inside the parentheses and hit the Space bar to build it up into the object as illustrated above. The colors for the border and background are taken from the text and background colors in the character format for the opening character of the rectangle object. Currently the Enclose object can only be inserted via copy/paste or the ITextRange2::SetInlineObject() function described below.

To understand the APIs for inserting and manipulating a math object, here’s a quick summary of how such objects are represented in the RichEdit backing store. In OfficeMath built-up format, as distinguished from a linear format like UnicodeMath or LaTeX, mathematical objects like fraction and boxed formula 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 the end delimiter. For example, the fraction 𝑎 over 𝑏 is represented in built-up 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} 𝑎|𝑏}. Here the start delimiter is the same character for all math objects and is the Unicode character U+FDD0 in RichEdit (Word uses a different character). The kind of object is specified by a rich-text object-name property associated with the start delimiter. So in plain text, the built-up forms of the fraction and subscript are identical if the fraction arguments are the same as their subscript counterparts. In the example here, a plain-text search for {_{frac} 𝑎|𝑏} matches {_{sub} 𝑎|𝑏} as well {_{frac} 𝑎|𝑏}. A rich-text search can distinguish between the two.

To insert an empty math object into a RichEdit control, call ITextRange2::SetInlineObject(Type, Align, Char, Char1, Char2, Count, TeXStyle, cCol). In particular, to insert one of the enclosures in a math zone, call

ITextRange2::SetInlineObject(tomBoxedFormula, Align, Char, Char1, 0, 0, 0, 0),

where Char = ▭, ▢, or ⬭ produce a square rectangle, a rounded rectangle, or an ellipse, respectively. To insert such an enclosure in ordinary text, call

ITextRange2::SetInlineObject(tomEnclose, Align, Char, Char1, 0, 0, 0, 0)

To change the border and/or background colors, select the object start character and apply the formatting via EM_SETCHARFORMAT, EM_SETRANGEFORMAT, or ITextFont::SetForeColor() and SetBackColor().

The various border styles are determined by the Align argument. For the rectangle, the Align values are defined by any combination of OR’ing bits given by

tomBoxHideTop | 1 |

tomBoxHideBottom | 2 |

tomBoxHideLeft | 4 |

tomBoxHideRight | 8 |

tomBoxStrikeH | 16 |

tomBoxStrikeV | 32 |

tomBoxStrikeTLBR | 64 |

tomBoxStrikeBLTR | 128 |

Here the low eight bits of Align control which sides are hidden (if any) along with whether four possible strike-throughs are drawn. Since all eight bits were defined for these purposes before, they are persisted in most existing file formats along with the Char code. The UnicodeMath notation that defines the Align value 𝑛 for a string 𝑥 is ▭ (𝑛&𝑥).

For the rounded rectangle, the Align values are defined by

tomRoundedBoxDashStyleMask | 0x07 | D2D1_DASH_STYLE |

tomRoundedBoxHideBorder | 0x08 | |

tomRoundedBoxCapStyleMask | 0x30 | D2D1_CAP_STYLE * 16 |

tomRoundedBoxNullRadius | 0x40 | |

tomRoundedBoxCompact | 0x80 |

Here bits 0..2 of Align give the Direct2D D2D1_DASH_STYLE, and bits 4..5 give the D2D1_CAP_STYLE. For example, Align = D2D1_DASH_STYLE_CUSTOM (5) gives the “input 1” example above. The radius (in twips) of the rounded corners of a rounded rectangle is given by Char1. The Office MathML converters don’t support the rounded rectangle and ellipse yet, even though MathML does.

The post Rounded Rectangles and Ellipses appeared first on Math in Office.

]]>The post OfficeMath appeared first on Math in Office.

]]>So, we call it *OfficeMath*. “Office” alludes to Microsoft Office but needn’t be exclusive. “Office” suggests a high-quality 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 in-memory model, named “Professional” in the OfficeMath UI. This model is mirrored in the OMML file format. It features *N*-ary structures such as integrals with limits *and* integrands, subscripts, superscripts and accents with well-defined 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 high-quality 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, math formatting, user interfaces, and includes links to further information in OfficeMath-oriented posts in Math in Office.

Editing Math using Ribbon, Dialogs, Context Menus

A good place to learn about the origins of OfficeMath is the post LineServices, which tells how the LineServices line-layout component came to be and how it evolved to yield TeX-quality math typography. OfficeMath depends on other technologies as well, including the creation of the math-font OpenType standard described in High-Quality 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*. Math-zone typography differs from the typography of ordinary text (see the section on Formatting below). The user creates a math zone with the Alt+= hot key or inserts one from the ribbon Insert tab.

In the OfficeMath in-memory 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 𝑎/2 is represented in built-up format by {_{frac} 𝑎|2} where {_{frac} is the start delimiter, | is the argument separator, and } is the end delimiter. Similarly, the subscript object 𝑎₂ is represented by {_{sub} 𝑎|2}. 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 a 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 character-format property associated with the start delimiter. In plain text, the built-up forms of the fraction and subscript are identical if the fraction arguments are the same as their subscript counterparts. In the example here, a plain-text search for {_{frac} 𝑎|2} matches {_{sub} 𝑎|2} as well as {_{frac} 𝑎|2}. Searching for OfficeMath equations involves plain-text searches like this together with comparison of the object types. 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 a/b, which needs to be parsed. The OfficeMath in-memory format is a “built-up” format as distinguished from linear formats like UnicodeMath and LaTeX.

The OMML format is the XML format that encapsulates the OfficeMath in-memory “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 *N*-ary element, nor does it have an explicit math-function 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 in-memory format naturally. With best practices, MathML without the <semantics> element can be used to round-trip OfficeMath equations apart from non-math 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

Built-up 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 or corresponding <mrow>… |

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 |

N-ary |
nary | mrow msubsup/moverunder with N-ary 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 Equation-Editor Office-Math 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. You can also create HTML documents with equations in them.

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 High-Quality 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. It might be good to add a variable-font weight axis to math fonts for this purpose.

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 math-zone character-format effect, an effect like bold or italic. As such, this is a non-nestable 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 ordinary-text 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 open-face, 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 sans-serif 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 non-math characters are all rendered nonbold and upright.

In addition, OfficeMath has a “no-build-up” attribute to treat operator characters literally rather than use them in build-up 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 built-up “stacked” fraction. This attribute can be entered in UnicodeMath by “quoting” the operator, namely preceding the operator by a backslash.

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 math-zone 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 sans-serif 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 math-zone formatting to inline math zones, but this isn’t currently available.

Inter-equation 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 equation-number 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 math-paragraph equation numbering, but it can handle virtually all cases.

OfficeMath UI can be grouped into keyboard, menu/ribbon, ink, and accessibility categories. Let’s consider each of these in turn. The keyboard, menu/ribbon, and ink categories are discussed in Chapter 6 of the book *Creating Research and Scientific Documents with Microsoft Word*.

A succinct summary of entering and editing math with a keyboard is given in the original blog’s first post, Formula Autobuildup in Word 2007. Basically, type the hot key Alt+= to insert a math zone and then type math using TeX control words for symbols. For example, in UnicodeMath mode, typing a/b=c inserts

The UnicodeMath syntax resembles that used in programming languages except that it uses many Unicode operators. Naturally there’s much more to math than symbols and fractions, and the keyboard input methods are described in UnicodeMath for the Unicode input method and in LaTeX/TeX input method for the LaTeX/TeX input method.

In UnicodeMath mode, build up to the “Professional” format is automatic as described in When Formula Autobuildup Occurs. In Word’s LaTeX mode, you must request build up. Enter Ctrl+= to build up a math zone into “Professional” format and Shift+Ctrl+= to build the math zone down into the current linear format (UnicodeMath or LaTeX). Or you can click on the corresponding options of the math-zone acetate rectangle.

In addition to the LaTeX/TeX control words, there are operator shortcuts described in Math Keyboard Shortcuts, Negated Operators, Keyboard Operator Shortcuts, Entering Unicode Characters, and Klinke’s Streamlined Math Input Notation. For example, /= autocorrects to ≠ and <= to ≤. Subscripts and superscripts are entered using _ and ^, respectively as discussed in Section 2.2 of UnicodeMath and in Keyboard Entry of Subscripts and Superscripts. Nice things to add include making the leading backslash optional and having an autocomplete drop-down menu of possible control words once you’ve entered the first few characters. For example, many control words start with \left and it would be nice to be able to select the desired one rather than type in the whole word like \leftrightarrow for .

In LaTeX mode, the subscript, superscript, numerator, and other math arguments are single entities. An entity can be a character or control word for a character like \alpha for α, or it can be an expression in curly braces like {a+b}. In UnicodeMath mode, the argument can be a sequence of alphanumeric characters. You can see such a difference by comparing what a^12 becomes: in LaTeX you get 𝑎¹2 and in UnicodeMath you get 𝑎¹². To get the latter in LaTeX input mode, enter a^{12}.

Unicode has many math characters (see Section 2 of Unicode Technical Report #25, Unicode Support for Mathematics). The post Math Symbol Hierarchy divides the math operator symbols into basic, intermediate, and full Unicode math categories. Most technical papers use the symbols in the basic and intermediate categories. The remaining characters are very specialized, e.g., ⪑, so you’ll probably never need them.

Built-up math zones convert alphabetic characters to math alphabetic characters, e.g., ‘a’ becomes ‘𝑎’, which is given by the Unicode character U+1D44E. Conversion to math alphabetic is overruled for special situations like trigonometric function names and can be overruled for arbitrary text. Also, it doesn’t occur for Greek upper-case letters as noted in Math Greek Letters. Math spacing is important and User Spaces in Math Zones explains how UnicodeMath build up may remove a space that’s automatically inserted by math spacing rules. In LaTeX mode, spaces are ignored except to terminate control words.

You can navigate through a math zone Using Left/Right Arrow Keys in Mathematical Text or you can use a mouse. Math Selection is like selection of ordinary text, but if you select a math object start/end/separator delimiter, the whole object is selected. Up and down-arrow keys try to go to the logical target, e.g., up arrow in the denominator of a fraction goes to the numerator. In navigating and selecting text, it’s useful to understand the concept of the Text Insertion Point. The insertion point is *in between* characters, not on top of a character.

You can enter accented characters as discussed in Math Accents and in Representation of Math Accents. You can enter matrices as discussed in Entering Matrices. If you want to line up two or more equations just right, see Equation Arrays.

In OfficeMath, empty numerators, denominators, subscripts, superscripts, and other essential arguments, etc., display the place-holder character ⬚. If you want to hide the ⬚, insert a “zero-width space” given by the Unicode character U+200B as discussed in The Invisibles. In OneNote you can edit optional arguments. These arguments are normally not shown, but you can move inside them by using the left/right arrow keys. When the IP is inside an optional argument, the ⬚ is displayed and you can enter characters. For example, you can convert a square root into an *n*^{th} root by navigating into the root’s index argument and typing n. To make such changes in Word or PowerPoint, you need to use a context-menu option.

If you become familiar with keyboard entry, you’ll probably find that the fastest way to enter math (see also the Ink section next). But admittedly, it’s not obvious how to enter many things. The math ribbon displays lots of math objects in readily clickable form. As such it provides easily discoverable ways to enter common mathematical expressions. For a comparison of keyboard and ribbon, see Math Ribbon Entry of Subscripts and Superscripts.

Math Context Menus provide context-sensitive ways to modify math objects, such as changing a stacked fraction into a slashed fraction, or aligning a set of equations at their equal signs. See also More on Math Context Menus. You can use the Office Insert Symbol Dialog to insert any Unicode character including all Unicode math symbols. The more common math symbols can be inserted using the symbol galleries on the math ribbon. You can also insert many math symbols using the Windows+. hot key.

Smart phones running OfficeMath don’t sport a math ribbon, but a math on-screen keyboard could let you enter lots of math entities easily. Think of exposing math symbols instead of emoji and using surround menus. Also, smart phones can work with ink…

You can enter equations with a pen as described in OneNote Math Assistant and the links therein. Microsoft’s math ink recognition first shipped in Windows 7 with the applet called the Math Input Panel. This applet lets you enter mathematical text using a pen or a mouse. It recognizes what you enter and displays the result using a private version of RichEdit. It also lets you copy the results to Word, Mathematica, or any other application that reads Presentation MathML.

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

Math accessibility falls into two categories: speech and braille. Microsoft Office Math Speech shipped in over 18 languages in January 2017. As described in Speaking of math…, math speech has two granularities: coarse-grained for fluent speech and fine-grained for editing. Together with touch typing on a keyboard, this combination enables a blind, nondeaf person to consume and edit math, both elementary and advanced.

The OfficeMath speech capability could be extended in useful ways such as offering alternate speech as discussed in Speaking Subscripts, Superscripts, and Fractions. Also, the facility “spoon feeds” the math speech to UI Automation. Some Assisted Technologies (ATs) such as NVDA and JAWS would like to get MathML for math zones and generate the math speech (and braille) themselves. Ways to do this will be the subject of a future post. Interestingly MathML can, in principle, be used both for generating math speech *and* for editing math as discussed in Editing Math using MathML for Speech.

Key infrastructure for math braille shipped in August 2017, namely the RichEdit build up/down machinery used by OfficeMath applications added support for entering and editing math using Nemeth Braille—the first math linear format. More work is needed for applications to expose math braille to end users. The main reason for using Nemeth math braille is given in Braille for Math Zones, which points out that the usual braille digit code ambiguities don’t exist in math zones, which is where the math is. Specifically, braille contractions aren’t used in math zones, so digits can be represented unambiguously using computer braille codes; no numerical indicator is needed for digits in Nemeth math zones (aside from an obscure case). Nemeth braille in math zones works with all languages (is globalized), whereas braille in ordinary text is localized to the language being used.

Other posts describing work on math braille include Unicode – Nemeth Character Mappings, which discusses extending the Nemeth specification to include many Unicode math symbols not in the current Nemeth specification and Nemeth Braille Alphanumerics and Unicode Math Alphanumerics, which relates how the Unicode math alphanumerics can be represented using Nemeth braille. The post Math Braille UI describes ways to reveal the math insertion point (IP) using a refreshable braille display. The braille IP location is complicated relative to that for ordinary text in that math structure characters described in OfficeMath aren’t always represented by a Nemeth code. For fractions, they are, but the start delimiter of a subscript object, for example, isn’t present in the Nemeth code.

Math dictation would be another math input method for blind and sighted users alike. Imagine, you can say 𝑎² + 𝑏² = 𝑐² faster than you can write or type it! Math dictation would work with all devices, computers, tablets, and phones. Hopefully someday…

The post OfficeMath appeared first on Math in Office.

]]>The post Two Phonetic Scripts: Vietnamese and Korean appeared first on Math in Office.

]]>In Vietnam in the 1500’s and 1600’s, Portuguese and French missionaries wanted to be able to read and write Vietnamese and to communicate with the Vietnamese people in writing as well as verbally. To this end, they chose a Latin alphabetic script with the letters a..z, đ, â, ă, ê, ô, ơ, ư plus the corresponding upper-case letters and five tone marks ̀ ́ ̃ ̉ ̣ (acute, grave, tilde, hook, and dot below, defined in the Unicode U+0300 block) for a total of 134 characters. This alphabetic script represented the Vietnamese language phonetically. The traditional Chinese orthography continued to be dominant until the early 1900’s, when the alphabetic script took over. In Vietnam today you still see Chinese characters, but mostly on old buildings and manuscripts. The vast majority of Vietnamese text uses the alphabetic script. All 134 characters were encoded in Unicode 1.1 (June 1993). Initially people used 8-bit code pages such as 1258 to encode the Vietnamese characters. But since Unicode has all the characters, it’s much more efficient to use them.

The default Windows 11 Vietnamese keyboard encodes the tone marks as combining marks in the U+0300 block instead of using the fully composed characters. This requires complex-script shaping, which slows down the display. Admittedly shaping engines can perform other useful tasks such as kerning and ligature formation, yielding finer typography. And a Vietnamese tone mark applies to a whole syllable, so it doesn’t have to be placed where a fully composed vowel has it. But web sites such as Wikipedia use fully composed Unicode characters. In Windows 11 you can install the Telex and/or the VNI keyboards, which have slicker ways to enter Vietnamese characters and insert fully composed characters. VNI’s option of automagically inserting the accents is particularly intriguing. To use one of these methods, press Windows > Settings > Time & Language > Language & region > Add a keyboard and add Vietnamese. Click on the Vietnamese keyboard Options “…” and you can choose a more advanced Vietnamese keyboard from the drop-down menu

While foreign missionaries were responsible for the Vietnamese script, King Sejong of Korea was responsible for the Korean script. His motivation was essentially the same as the European missionaries’: make it easy for all Koreans to read and write their language. His original script published in 1446 had only 24 characters, called jamo, as shown in the following picture taken of an interactive display in the National Palace Museum of Korea in Seoul.

Modern Korean requires more: 19 initial consonants (C), 21 vowels (V) and 27 final consonants (T). The final consonants include most of the initial consonants and add some others. The jamo are displayed in boxes called Hangul syllables. There are 19×21 CV combinations and 19×21×27 CVT combinations for a total of 11172 possible Hangul syllables in modern Korean. The jamo are encoded in the Unicode U+1100 block (C—U+1100..U+1112, V—U+1161..U+1175, T—U+11A8..U+11C2) and the 11172 Hangul syllables are encoded from U+AC00..U+D7A3 in CVT sort order (T varies fastest, C varies slowest).

If you look at the Unicode U+1100 block, you’ll notice it’s full: 256 jamo! That’s more than 19 + 21 + 27. The major difference is the inclusion of many old Hangul jamo that are not used in Modern Korean. Modern Korean can be handled as a simple script: just use the Hangul symbols for which no glyph shaping is needed. In contrast, Old Hangul has many more combinations and needs to have a shaping engine to place the jamo correctly. The Unicode Standard explains how to do this in Chapter 3, Section 3.12 Conjoining Jamo Behavior.

Some interesting Unicode Hangul history. Non-combining jamo (U+3130..U+318F) and 2350 Hangul syllables (U+3400..U+3D2D) were part of Unicode 1.0 (October, 1991). Unicode 1.1 (June 1993) added the modern combining jamo (U+1100 block) and 4306 more Hangul syllables. The Korean government wanted the remaining 11172 – 4306 – 2350 = 4516 syllables of Modern Korean to be added as well and preferably to collect all the syllables in a single block. I had just joined the Unicode Technical Committee (over 26 years ago!) and it seemed to us to be a shame to have the Hangul syllables split up into three blocks. Furthermore, Unicode wasn’t yet used for Korean anywhere as far as we could tell. Windows NT had support for Unicode, but nothing special for Hangul. Other operating systems didn’t even support Unicode at that time. Word processing programs that supported Korean used a Korean code page, not Unicode. S.G. Hong of the Microsoft Korean subsidiary pleaded for us to use a single block and after considerable deliberation the UTC and WG2 (the ISO 10646 working group on character sets) elected to do so. Hence in Unicode 2.0 (July 1996) the two earlier Hangul blocks were deprecated and the Hangul syllables were assigned U+AC00..U+D7A3 in the ideal alphabetic order. To this day, no one has come up with a Korean document that was compromised by these changes. But you should have heard the outcries of folks that were upset that the old codes were deprecated.

Ever since then, Unicode code points have been completely stable and such stability is a basic requirement. Shortly after the release of Unicode 2.0, Word 1997 was released. Based on Unicode, it supported the modern Hangul syllables. At that point it would have been unthinkable to change the code points since documents actually existed that used the code points. Fortunately, we were able to make the changes early enough in Unicode’s history that Korea enjoys excellent Unicode support. I couldn’t help but think of that a bit while walking through the streets and palaces of beautiful downtown Seoul.

The post Two Phonetic Scripts: Vietnamese and Korean appeared first on Math in Office.

]]>The post Windows 11 Notepad appeared first on Math in Office.

]]>The classic Notepad has two handy features that weren’t implemented in RichEdit: line-ending detection (CR, LF, CRLF) and the “Show Unicode control characters” mode (discussed next). For years Notepad didn’t break Unix-convention lines that terminated with a LF (U+000A) instead of a CRLF (U+000D U+000A). I used to open the Unicode Character Data files, which contain LF-terminated lines, with WordPad and save them to convert the LF’s to CRLF’s so that Notepad would display them correctly. To fix this problem, Notepad went one better: it checked to see which line ending came first and then made that line ending the default for the file. So, a file with LF- terminated lines remains LF terminated *and* displayed correctly. Internally RichEdit follows the lead of Word and the Mac in terminating paragraphs with a CR and converting LF’s and CRLF’s to CR when reading in a file or storing text via an API like WM_SETTEXT or ITextRange2::SetText2. This is still the case, but you can tell RichEdit to recognize the kind of line termination in a file and use that choice for saving/copying the file by sending the EM_SETENDOFLINE message with wparam = EC_ENDOFLINE_DETECTFROMCONTENT.

Notepad has had a “Show Unicode control characters” option in its context menu for many years. This mode displays Bidi zero-width control characters using distinctive “zero-width” glyphs. This is very valuable, for example, in revealing the Bidi RLO (U+202E) and LRO (U+202D) codes that override the usual character directionalities and are sometimes used to spoof files for nefarious purposes. It also displays the zero-width joiner (ZWJ—U+200D) with a “zero-width” vertical line topped by an x. But inside emoji ZWJ sequences, such as family emojis, the mode doesn’t break the sequence apart at the ZWJ’s and doesn’t reveal the ZWJ’s by the zero-width ZWJ glyph. And classic Notepad doesn’t display ZWJ sequences and emoji in general in color.

In the new Notepad “Show Unicode control characters” mode, ZWJ sequences are broken apart at the ZWJ’s and the ZWJ’s are displayed by the ZWJ zero-width glyph. You can navigate inside the ZWJ sequence using the ← and → keys and type Alt+x to see the codes of the characters comprising the ZWJ sequence. This lets you figure out how a ZWJ sequence is constructed. For example, the new mode displays the family emoji ZWJ sequencegiven by the codes U+1F468 ZWJ U+2764 U+FE0F ZWJ U+1F469 as

Visual Studio Code has a nifty Find/Replace dialog that drops down into the upper right of the text area. In case the dialog overlaps the starting text, the user can drag the text down just under the bottom of the dialog. The new Notepad mimics this behavior. It was a bit tricky to get RichEdit to provide the associated functionality. In rich-text formatting, the paragraph space-before and space-after properties are used to add spacing between paragraphs. Since RichEdit is a rich-text editor, it supports these properties, and it was natural to implement the drop-down space as “document space before”. The space-before value is included in the ascent of the first line in the document. The tricks came in dealing with deleting or replacing the first line and in scrolling the display correctly with a nonzero document-space-before value.

We decided to match the Visual-Studio UI for selecting and not selecting the EOP character at the end of a line. This differs from Word’s UI, which tends to auto select the EOP character if you navigate next to it. Specifically, in plain-text controls, we don’t let the mouse extend the selection to include the EOP on a line or let Shift+End select the EOP. This corresponds to what gets deleted if you hit the Delete key after selecting the text. You can still select the EOP character by using Shift+→ and by extending the selection to the next line. Also, if word wrap is turned off, the insertion-point caret now follows any spaces you enter instead of ignoring the spaces.

The Windows 11 Notepad uses a window for its editing canvas and windows generally use GDI for displaying text and images. GDI doesn’t have functions to display color fonts in color, whereas DirectWrite does. To be able to use DirectWrite for color emoji and other enhancements, the new Notepad therefore creates a RichEDitD2DPT window, which uses DirectWrite for text and GDI for OLE objects (Notepad doesn’t insert OLE objects).

The RichEdit build used in Notepad comes from the same sources as the RichEdit that’s loaded with Microsoft 365 applications like Word, PowerPoint, Excel, and OneNote. It’s not the Windows RichEdit in msftedit.dll. Consequently, Notepad has the latest RichEdit improvements.

We’ve fixed bugs that didn’t show up for RichEdit plain-text controls over the years partly because before Notepad, the plain-text instances have been small.

Notepad uses RichEdit classic font binding instead of the IProvideFontInfo font binding used in XAML text controls and in RichEdit controls appearing in Microsoft 365 applications. Notepad doesn’t want to load the mso libraries used in the latter since these libraries are quite large. The classic font binding has been improved but needs to add support for more scripts.

We improved RichEdit’s performance for large ASCII files such as those for core dumps. One feature that can slow down reading in a large file is autoURL detection. While reading in plain text, LF and CRLF are translated to CR for internal use and in the process the text is checked for the combination “:/”. If that combination isn’t found and only AURL_ENABLEURL is enabled, autoURL detection is bypassed.

Imagine things that can be added given the power of RichEdit. RichEdit plain-text controls have only one paragraph format, but they can have considerable character formatting. The latter is needed because 1) Unicode has over 144,000 characters and a single font is limited to 65535 glyphs, and 2) input method editors (IMEs) and spell checkers require underlines and/or text coloring. So, although the user interface only exposes one character format, the TOM object model gives access to many more properties (see ITextFont2). Accordingly, it would be possible to offer program code syntax highlighting used, for example, in Visual Studio and Visual Studio Code. But probably that should be the domain of compiler interactive development environments. Another option could be to display HTML, XML, JSON, and RTF files with indentation and toggle between XML/HTML start and end tags like Ctrl+} does for bracketed expressions, e.g., in JSON and RTF files. Large file performance needs more improvement. Please feel free to comment about bugs and wishes!

The post Windows 11 Notepad appeared first on Math in Office.

]]>The post Function to get Unicode Fractions appeared first on Math in Office.

]]>wchar_t GetUnicodeFraction( wchar_t chNum, // Numerator character wchar_t chDenom) noexcept // Denominator character { static const wchar_t rgchNum1[] = L"½⅓¼⅕⅙⅐⅛⅑⅒"; switch (chNum) { case '0': return chDenom == '3' ? L'↉' : 0; // Used in baseball scoring case '1': // ':' (0x003A) is used for '10' return IN_RANGE('2', chDenom, ':') ? rgchNum1[chDenom - '2'] : 0; case '2': return chDenom == '3' ? L'⅔' : chDenom == '5' ? L'⅖' : 0; case '3': return chDenom == '4' ? L'¾' : chDenom == '5' ? L'⅗' : chDenom == '8' ? L'⅜' : 0; case '4': return chDenom == '5' ? L'⅘' : 0; case '5': return chDenom == '6' ? L'⅚' : chDenom == '8' ? L'⅝' : 0; case '7': return chDenom == '8' ? L'⅞' : 0; } return 0; }

Here the IN_RANGE(‘2’, chDenom, ‘:’) macro is true for all characters in the range ‘2’ through ‘:’, that is 23456789:, and the ‘:’ is used for the 10 in ⅒.

Occasionally, people recommend limiting programs to the ASCII characters in Unicode since some programming tools can’t handle other Unicode characters. But ASCII was invented in 1963 and contemporary programming tools should be able to handle Unicode, which has been the de facto character standard for many years. I use Unicode math and braille characters extensively in the RichEdit math editing and display code, and the code is much easier to read and maintain than when ASCII numeric references are used.

Inside math zones, you can enter arbitrary built-up fractions, but it can be handy to have the Unicode fractions in ordinary text. As you might guess, the GetUnicodeFraction() function is used in the new RichEdit “Autoformat as you type” option, an option that will be discussed in a future post.

The post Function to get Unicode Fractions appeared first on Math in Office.

]]>The post UnicodeMath Color appeared first on Math in Office.

]]>Inputting math using UnicodeMath into Word and other applications typically doesn’t require special text and background color syntax since these applications have user interfaces (UI) to color text. But UnicodeMath is a useful format for persisting math in files and in plain-text scenarios that don’t have rich UI. I use UnicodeMath to represent math in many math tests because it’s so much easier to input and read than MathML, LaTeX, RTF, and OMML. So, it’s valuable to be able to include text coloring in UnicodeMath.

Following the UnicodeMath tradition of using non-math UnicodeMath symbols to represent operations, Noah chose ✎ (U+270E) as the text color operator and (U+2601) for background color. The syntax is like that for *n*^{th} root \root(n&x). For example, “a+✎(red&q^2)+(lime&r^2)” converts to OfficeMath in RichEdit as

You can specify a color using the #RRGGBB or #RGB syntax or by the name of a standard HTML color (aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, yellow). We still need to implement the ITextFont::SetForeColor() and SetBackColor() methods in Word and OfficeArt to get the UnicodeMath color operators to work in Word, PowerPoint and Excel. The color operators work now in OneNote since OneNote uses RichEdit’s TOM implementation.

The TeX-like names for foreground and background color operators are \color and \backcolor, respectively. The latter is easier to enter with math autocomplete.

Noah also added the delimiters ⫷ and ⫸ to hide text appearing inside the delimiters, and the monospace operator ￗ to use monospace characters within ￗ(…). I haven’t added these to the RichEdit implementation yet. Also, we need an operator for the forthcoming MathML “intent” attribute, since UnicodeMath should be interoperable with Presentation MathML.

The post UnicodeMath Color appeared first on Math in Office.

]]>The post RichEdit Stories appeared first on Math in Office.

]]>Microsoft Word uses multiple stories in a document, such as a main story, a footnote story, a header story, a footer story, etc. A RichEdit client could do something similar in supporting a full-fledged document program. For example, OneNote instantiates a RichEdit control for editing and displaying a paragraph. Since a OneNote document can have many sections, each with many paragraphs, OneNote has a pool of RichEdit controls to be used as needed. A large OneNote document has many more paragraphs than RichEdit controls. An alternate approach would be to house each paragraph of a OneNote section in its own story all within a single control for the whole section. This approach might be more performant than using multiple relatively large controls since the stories package rich text efficiently, and paragraphs would only have to be loaded once.

Place-holder controls are used for user entry and need place-holder text to instruct the user what to do. As soon as the user types something, the place-holder text disappears, and what the user types is displayed instead. If the user deletes all the text, the place-holder text reappears. This behavior is accomplished by storing the place-holder text in its own story. The story that is currently active is displayed on screen.

The first use of stories in RichEdit was in RichEdit 6.0 (Office 2007) for converting UnicodeMath input into the internal OfficeMath format. In fact, the TOM2 ITextStrings interface handles a collection of rich-text strings useful for manipulating rich text, such as converting infix math expressions into the prefix OfficeMath form and vice versa. The ITextStrings strings collection is implemented by concatenating the strings together in a scratch story and maintaining an array of the string counts that delimit the strings. RichEdit also uses an ITextStrings scratch story in converting MathML and OMML into OfficeMath.

Stories can be programmed using the messages EM_SELECTSTORY, EM_GETSTORYTYPE, and EM_SETSTORYTYPE and by the methods in ITextStory, which is part of TOM Version 2. Stories can be “edited” simultaneously using ITextRange2’s and displayed independently of one another. A given ITextRange2 accesses one and only one story. In addition, only one story can be user active at a time, that is, only one story receives the keyboard and mouse input and is displayed. The EM_SELECTSTORY message isn’t documented elsewhere on the web, so here’s how it’s used. The message is defined by

#define EM_SELECTSTORY (WM_USER + 263)

The message selects the story with ID given by the wparam. It returns the active story ID. The lparam has the flag SSS_DONTDISPLAYSTORY defined by

#define SSS_DONTDISPLAYSTORY 1

The ITextDocument2 interface has methods to get the active story, to get a new story, and to get an existing story by story ID. The story facility needs a stories collection, since among other things before the parent ITextServices instance is deleted, it needs to zombie any unreleased ITextStory pointers and delete the story data. The stories collection is accessed externally via methods in ITextDocument2. RichEdit 6.0 (Office 2007) and later versions have a multistory facility (see ITextStoryRanges), but it is not sufficiently lightweight and convenient for clients, so we added the ITextStory approach in RichEdit 8 (in 2012). The ITextStoryRanges facility implements the original TOM version of stories as ranges and is oriented towards stories as used in Word. The current emphasis on a multitude of lightweight instances leads to a different model. A range adds extra instance size, so it saves space to instantiate ranges only when they are needed to manipulate stories.

To minimize the size of the story, it only contains rich-text structures that are used. For example, if a control only has default formatting, it has no character or paragraph format run arrays. Some languages like Thai need cluster and word breaking, but if a story doesn’t contain text of such languages, the cluster and word breaking structures are omitted. Similarly, if there are no embedded objects or images, there’s no object array.

The current RichEdit control has a single display that’s used by the active story. A more advanced model would offer multiple displays and an enhanced ITextHost interface with methods that specify the ITextStory to be displayed.

The post RichEdit Stories appeared first on Math in Office.

]]>The post RichEdit Place Holder appeared first on Math in Office.

]]>Send two messages to set up a place-holder control: 1) EM_SETTEXTEX to set the place-holder text, and 2) EM_SETEDITSTYLEEX to enable the place-holder functionality. For setting the text, write something like

const WCHAR wszPlaceholder [] = L"Start a conversation"; SETTEXTEX settext = {ST_PLACEHOLDERTEXT, 1200}; SendMessage (hwndRE, EM_SETTEXTEX, (WPARAM)&settext, (LPARAM)wszPlaceholder);

To enable the place-holder functionality, send EM_SETEDITSTYLEEX to an empty control by

SendMessage (hwndRE, EM_SETEDITSTYLEEX, SES_EX_SHOWPLACEHOLDERONFOCUS, SES_EX_SHOWPLACEHOLDERONFOCUS);

At this point, the place-holder text “Start a conversation” is displayed. The constants ST_PLACEHOLDERTEXT and SES_EX_SHOWPLACEHOLDERONFOCUS aren’t documented on the web, so here they are

#define SES_EX_SHOWPLACEHOLDERONFOCUS 0x80000000 #define ST_PLACEHOLDERTEXT 0x0010

Internally, the place-holder functionality is implemented using two stories, one for the main text and one for the place-holder text. A story is a programming object that *stores* rich text. More about this kind of story in another post. Whenever the main text is empty, the place-holder story is displayed on screen. As soon as the user types something, the main story is displayed. The initial place-holder facility was added in 2005, but SES_EX_SHOWPLACEHOLDERONFOCUS functionality was added in 2018 and isn’t in the Windows msftedit.dll. The XAML TextBox uses RichEdit and supports place-holders.

The post RichEdit Place Holder appeared first on Math in Office.

]]>The post LineServices appeared first on Math in Office.

]]>This post is an update of an earlier post that tells some of how LineServices came to be and developed over time. It all started in 1994 with one of Microsoft’s most talented engineers, Eliyezer Kohen, a Turkish computer scientist who obtained his PhD at the Technische Hochshule in Zürich with Nicolas Wirth (author of Pascal, among other things). Eliyezer had led the two-man teams (the other person was Dean Ballard) that developed the Microsoft TrueType rasterizer as well as the original OpenType specification. Peter Pathe was heading Word at the time and wanted to improve Word’s line layout. He figured that Eliyezer could get a team going to do this in time for Word 97.

Eliyezer was convinced he could factor out Word’s line layout, but because of Word’s mind-boggling backward compatibility requirements, he refused to agree to the Office 97 time frame. I was working on RichEdit 2.0 next door to Eliyezer back then and you should have heard the prolonged arguments between Eliyezer and Peter! In that time frame, Eliyezer had a native American working with him named Lennox Brassel. Then he hired his first St. Petersburg mathematician, Sergey Genkin. Sergey’s first job after arriving in the USA in 1990 was back East working on a TeX compatible system. The team developed LineServices 1.0, which shipped first with a little program call Greeting Cards.

Eliyezer needed more developer cycles, so he asked Sergey if knew any more smart software engineers back in St. Petersburg. Sure enough Igor Zverev could come and RichEdit was fortunate enough to have Igor’s services for a while in developing RichEdit 2.0. (RichEdit also had another St. Petersburg mathematician Andrei Burago for some of that time; more about Andrei in a bit…). Not long after, yet another St. Petersburg mathematician Victor Kozyrev joined the team.

LineServices 2.0 was developed and shipped with Word 2000, Internet Explorer 4.0, RichEdit 3.0, PowerPoint 2000, and Publisher 2000. In addition to Western text, LineServices supported several special layout objects: the reverse object for BiDi text, the ruby object for East Asian phonetic annotations, Tatenakayoko (Japanese for “horizontal in vertical”, but sounds better than HIV), and warichu (two lines in one). From my point of view ruby was just a fraction in disguise, so naturally I was very excited to see that LineServices could do such a beautiful job displaying ruby. The initial ruby handler was developed by Rick Sailor.

LineServices handles lots of tricky problems with text layout and calls the client back for all the information it needs. LineServices never makes any operating system calls directly and it can run on any operating system that has a C++ compiler. The team had the strange habit of seriously designing a product before ever writing one line of code. What’s even stranger is that when they finally wrote the code, it had very few bugs in it. My own approach is to design partially and then dive into writing code using the well-known physicist approach to evaluating things called successive approximations. I can’t figure out everything in advance, so I try something and then gradually improve on it. Those guys figured out most of the design without writing any code.

After Office 2000, Eliyezer & Co. embarked on Page/TableServices, which was natural. He had started with characters in implementing TrueType, then progressed to lines with LineServices, and so pages and table were the next items on the layout hierarchy. To pull that off he needed the help of another St. Petersburg mathematician, Anton Sukanov, who had been a whiz kid in Russia winning various computer-science puzzle competitions. So, the team developed PTS as it’s called and revised LineServices to work well with it.

About that time, I simply couldn’t stand not having some native math layout in our products, so in February 2001 I wrote a math handler for LineServices patterned after the ruby handler. While I was at it, I installed the ruby object in a recursive way, so that you could have ruby objects nested like continued fractions. This upset the authors of the HTML ruby specification, since they said ruby was not supposed to be nested. Nevertheless, the easiest way to display complex ruby is using one level of nesting. My simple math handler showed that LineServices could do mathematics, although my spacing was mediocre. More precisely, spacing was delegated to the user, who unfortunately seldom knows what correct math spacing is.

A valuable thing about my old LineServices math handler was that it convinced people that we had the infrastructure to layout math. Fortunately, I didn’t appreciate at the time how hard laying out TeX-quality math would prove to be. Else I might not have been able to persuade people to work on it. It seems that most things that are worthwhile are way harder than you think they’ll be when you start working on them.

Of course, Eliyezer didn’t need any convincing; he and his team had designed LineServices so that it could be used to layout math. They just didn’t tell anyone! So after Office 2003 shipped, Eliyezer convinced Bill Gates and Steven Sinofsky that we should handle math layout and he started studying mathematical typography in earnest. He got his hands on every math typography book he could find, but by far the most influential and useful was Donald Knuth’s *The TeXbook*. After a few months Eliyezer enlisted the help of Victor and Andrei to design a math handler. Andrei had been working in the Windows font group, a background that would prove to be incredibly helpful on the math project.

They’d often come into my office announcing they were planning to do this and that and I would sometimes protest that what they had in mind wasn’t workable from a client’s, e.g., RichEdit’s, point of view. So they’d revise the plan and eventually they had a math handler design that was compatible with my general approach and offered really high quality mathematical typography. While this was going on, I was developing the formula autobuildup input method (see OfficeMath UI) using my old math handler, since they didn’t have any code written.

Since TeX was so valuable in the design process, Eliyezer wanted to talk with Donald Knuth, who happened to be an old friend of Eliyezer’s PhD advisor, Nicolas Wirth. A visit was arranged in November 2003 and the four of us had the good fortune to spend an extraordinary afternoon with Knuth at his home on the Stanford University campus. Among many things, Donald showed us how he uses TeX to typeset his papers and books exactly the way he wants them to look. 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 shimming characters to place them more beautifully in a formula. This interaction inspired us to think that we could automate some of Donald’s tweaks using what evolved into the OpenType math tables and associated code, such as “cut-ins” to kern superscripts and subscripts with their bases.

Eliyezer’s health gradually declined, and he decided to retire after the initial math-handler design. Sergey Genkin took over leadership of the math project. One day in the summer of 2004 they came into my office all excited and announced that they had been able to display the mathematical expression 𝑎 + 𝑏! It was a real achievement, since the spacing around the + was the desired 4/18^{th} em and a lot of code had checked out correctly. One of the things they soon discovered was that LineServices alone was not adequate to layout high quality mathematics: you need PTS too!

The problem is that on computer screens, unlike the printed page, the layout width varies substantially from one invocation to another. Hence you must be able to break equations to accommodate different window widths. TeX delegates most equation breaking to the user, but that’s not a good option for browsers, slide shows and other screen usages. Also, you need PTS to handle placement of equation numbers. Yet another brilliant St. Petersburg mathematician had joined the PTS team, namely Alexander Vaschillo. So, he and Anton implemented equation breaking and numbering.

At this point one can understand better how we came to use OMML (Office MathML) as a file format for mathematics rather than MathML. OMML is a close representation of the LineServices/PTS math objects. These math objects were created after extensive study of mathematical typography, rather than by study of MathML. It’s natural to have a file format that mirrors the internal format. In addition, we needed to be able to put any inline text and objects inside math zones. MathML cannot embed other XML namespaces except indirectly via parallel markup of some kind.

The post LineServices appeared first on Math in Office.

]]>The post Unicode Math Braille Sequences appeared first on Math in Office.

]]>Section 2.2 of Unicode Technical Report #25 discusses the math alphanumerics and why they’re important for math. OfficeMath uses math alphabetics for most variables and supports the math digit sets as well. Accordingly, we need mappings between Unicode and Nemeth braille math alphanumerics. No attempt is made to give UEB sequences for the Unicode math alphanumerics.

For the most part, the mappings are straightforward as illustrated in the table below. But due to its generative use of type-form and alphabetic indicators, Nemeth braille encodes some math alphabets not in Unicode, e.g., Greek Script and Russian Script. Meanwhile, Unicode has math double-struck and monospace English alphanumerics, which don’t exist in Nemeth braille. Unicode also has six alphabets that aren’t mentioned in the Nemeth specification but that can be defined unambiguously with Nemeth indicators, namely bold Fraktur (Nemeth calls Fraktur “German”), bold Script, and Sans Serif bold and/or italic. The table below includes unambiguous prefixes for these alphabets chosen such that the Nemeth bold indicator precedes the italic or script indicators, and the Sans Serif indicator precedes the bold indicator. These choices correspond to the orders in which the Unicode math alphabets are named. Changes in this ordering result in alternative prefixes that are also unambiguous, but it seems simpler for implementations and users to standardize on the Unicode name ordering. Note that for simplicity English letters in math expressions often aren’t preceded by the braille italic indicator even though they are understood to be math-italic characters. Both LaTeX and MathML also use this convention.

Letter/style |
Nemeth |
E.g. |
Unicode |
Nemeth |

English letter | ⠰ | A | U+0041 | ⠰⠠⠁ |

Fraktur letter | ⠸ | 𝔄 | U+1D504 | ⠸⠠⠁ |

Greek letter | ⠨ | Γ | U+0393 | ⠨⠠⠛ |

Greek letter alternatives | ⠨⠈ | 𝜀 | U+03B5 | ⠨⠈⠑ |

Russian letter | ⠈⠈ | Д | U+0414 | ⠈⠈⠠⠙ |

Hebrew letter | ⠠⠠ | ℵ | U+2135 | ⠠⠠⠁ |

Bold | ⠸ | 𝐀 | U+1D400 | ⠸⠰⠠⠁ |

Bold Fraktur | ⠸⠸ | 𝕬 | U+1D56C | ⠸⠸⠠⠁ |

Bold Italic | ⠸⠨ | 𝑨 | U+1D468 | ⠸⠨⠰⠠⠁ |

Bold Script | ⠸⠈ | 𝓐 | U+1D4D0 | ⠸⠈⠰⠠⠁ |

Italic | ⠨ | 𝐴 | U+1D434 | ⠨⠰⠠⠁ |

Italic Greek | ⠨⠨ | 𝛾 | U+1D6FE | ⠨⠨⠛ |

Script | ⠈ | 𝒜 | U+1D49C | ⠈⠰⠠⠁ |

Sans Serif | ⠠⠨ | 𝖠 | U+1D5A0 | ⠠⠨⠰⠠⠁ |

Sans Serif Bold | ⠠⠨⠸ | 𝗔 | U+1D5D4 | ⠠⠨⠸⠰⠠⠁ |

Sans Serif Bold Italic | ⠠⠨⠸⠨ | 𝘼 | U+1D63C | ⠠⠨⠸⠨⠰⠠⠁ |

Sans Serif Italic | ⠠⠨⠨ | 𝘈 | U+1D608 | ⠠⠨⠨⠰⠠⠁ |

Upper case | ⠠ | A | U+0041 | ⠠⠁ |

The Nemeth specification has Script Greek (in §22) as well as “alternative” Greek letters (in §23). Some of the latter may be referred to as “script”. Specifically, the Unicode math Greek italic letters 𝜃𝜙𝜖𝜌𝜋𝜅 have the alternative counterparts 𝜗𝜑𝜀𝜚𝜛𝜘, respectively. The symbol 𝜗 can be called “script theta”. Since Unicode doesn’t have a math script Greek alphabet, it makes sense to map Nemeth math script Greek letters to the alternative Greek letters, if they exist, on input and to use the Nemeth alternative notation on output. In addition, in Unicode the upper-case Θ has the alternative ϴ. In TeX and OfficeMath, the alternative letters are identified by control words with a “var” prefix, as in \varepsilon for 𝜀, while ϵ is given by \epsilon. Interestingly, modern Greek uses 𝜑 and 𝜀 instead of 𝜙 and 𝜖, but math notation considers the script versions to be the alternatives. The table below lists the Greek symbols explicitly.

Nemeth braille has several Russian alphabets (see §22 of the Nemeth spec). These alphabets map to characters in the Cyrillic range U+0410..U+044F. Unicode has no math Russian alphabets, but italic and bold Russian alphabets can be emulated using the appropriate Cyrillic characters along with the desired italic and bold formatting. The Unicode Technical Committee, which is responsible for the Unicode Standard, has not received any proposals for adding Russian math alphabets. At least in my experience, technical papers in Russian use English and Greek letters in math zones. In Russian technical documents, this has the nice advantage of easily distinguishing mathematical variables from normal text. Accordingly the OfficeMath math braille facility uses the Russian letter notation for Unicode math double-struck letters.

Unicode has four predefined Hebrew characters in the Letterlike Symbols range U+2135..U+2138: ℵ, ℶ, ℷ, ℸ, respectively. In math contexts, it makes sense to map those Hebrew letters in Nemeth braille to the Letterlike Symbols and to map the other Nemeth Hebrew letters to characters in the Unicode Hebrew range U+05D0..U+05EA. The Unicode Technical Committee has not received any proposals for adding more Hebrew math letters so they probably won’t appear in math zones, except, perhaps, as embedded normal text.

Most Unicode math digits can be represented by the appropriate type-form indicator sequences in the table above followed by the numeric indicator ⠼ (if necessary) and the corresponding ASCII digits. For example, a math bold 2 (𝟐—U+1D7D0) can be represented by ⠸⠼⠆or “_#2”. This works for the bold and/or sans-serif digits, but not for the double-struck and monospace digits, which have no Nemeth counterparts. Meanwhile Nemeth notation supports italic and bold italic digits, which aren’t in Unicode.

Digits in most math contexts don’t need a numeric indicator in Nemeth notation, e.g., most digits in fractions, subscripts, or superscripts. To optimize common numeric subscript expressions like a_{1}, the numeric indicator *and* the subscript indicator are omitted. In Nemeth ASCII braille, a_{1} is “A1” and in Nemeth braille it’s ⠁⠂. The ASCII braille representation is tantalizing since variables like A1, B2, etc., are used to index spreadsheets and it would be more natural if spreadsheet indices were a_{1}, b_{2}, etc., at least for people with a mathematical background.

Code |
Char |
Unicode Name |
Nemeth |
UEB |

0021 | ! | Exclamation mark | ⠸⠖ | ⠖ |

0021 | ! | Factorial | ⠯ | ⠖ |

0022 | “ | Quotation mark | ⠠⠶ | |

0023 | # | Number sign | ⠨⠼ | ⠸⠹ |

0024 | $ | Dollar sign | ⠈⠎ | ⠈⠎ |

0025 | % | Percent sign | ⠈⠴ | ⠨⠴ |

0026 | & | Ampersand | ⠸⠯ | ⠈⠯ |

0027 | ‘ | Apostrophe | ⠄ | ⠄ |

0028 | ( | Left parenthesis | ⠷ | ⠐⠣ |

0029 | ) | Right parenthesis | ⠾ | ⠐⠜ |

002A | * | Asterisk | ⠈⠼ | ⠐⠔ |

002B | + | Plus sign | ⠬ | ⠐⠖ |

002C | , | Comma | ⠠ | ⠂ |

002D | – | Hyphen | ⠸⠤ | ⠤ |

002E | . | Full stop | ⠸⠲ | ⠼⠲ |

002F | / | Solidus | ⠸⠌ | ⠸⠌ |

003A | : | Colon | ⠸⠒ | ⠒ |

003B | ; | Semicolon | ⠸⠆ | ⠆ |

003C | < | Less-than sign | ⠀⠐⠅⠀ | ⠈⠣ |

003D | = | Equals sign | ⠀⠨⠅⠀ | ⠐⠶ |

003E | > | Greater-than sign | ⠀⠨⠂⠀ | ⠈⠜ |

003F | ? | Question mark | ⠸⠦ | ⠦ |

0040 | @ | Commercial at | ⠈⠁ | ⠈⠁ |

005B | [ | Left square bracket | ⠈⠷ | ⠨⠣ |

005C | \ | Reverse solidus | ⠸⠡ | ⠸⠡ |

005D | ] | Right square bracket | ⠈⠾ | ⠨⠜ |

005E | ^ | Circumflex accent | ⠸⠣ | ⠈⠢ |

005F | _ | Low line | ⠨⠤ | |

007B | { | Left curly bracket | ⠨⠷ | ⠸⠣ |

007C | | | Vertical line | ⠡ | ⠸⠳ |

007D | } | Right curly bracket | ⠨⠾ | ⠸⠜ |

007E | ~ | Tilde | ⠈⠱ | ⠈⠔ |

00A2 | ¢ | Cent sign | ⠈⠉ | ⠈⠉ |

00A3 | £ | Pound sterling | ⠈⠇ | ⠈⠇ |

00A7 | § | Section sign | ⠈⠠⠎ | ⠘⠎ |

00A9 | © | Copyright sign | ⠷⠠⠉⠾ | ⠘⠉ |

00AC | ¬ | Not sign | ⠈⠹ | |

00AE | ® | Registered sign | ⠷⠠r⠾ | ⠘⠗ |

00B0 | ° | Degree sign | ⠘⠨⠡ | ⠘⠚ |

00B1 | ± | Plus-minus sign | ⠬⠤ | ⠸⠖ |

00B6 | ¶ | Pilcrow sign | ⠈⠠⠏ | ⠘⠏ |

00B7 | · | Middle dot | ⠡ | |

00D7 | × | Multiplication sign | ⠈⠡ | ⠐⠦ |

00F7 | ÷ | Division sign | ⠨⠌ | ⠐⠌ |

0391 | Α | Greek capital letter alpha | ⠨⠠⠁ | ⠠⠨⠁ |

0392 | Β | Greek capital letter beta | ⠨⠠⠃ | ⠠⠨⠃ |

0393 | Γ | Greek capital letter gamma | ⠨⠠⠛ | ⠠⠨⠛ |

0394 | Δ | Greek capital letter delta | ⠨⠠⠙ | ⠠⠨⠙ |

0395 | Ε | Greek capital letter epsilon | ⠨⠠⠑ | ⠠⠨⠑ |

0396 | Ζ | Greek capital letter zeta | ⠨⠠⠵ | ⠠⠨⠵ |

0397 | Η | Greek capital letter eta | ⠨⠠⠱ | ⠠⠨⠱ |

0398 | Θ | Greek capital letter theta | ⠨⠠⠹ | ⠠⠨⠹ |

0399 | Ι | Greek capital letter iota | ⠨⠠⠊ | ⠠⠨⠊ |

039A | Κ | Greek capital letter kappa | ⠨⠠⠅ | ⠠⠨⠅ |

039B | Λ | Greek capital letter lambda | ⠨⠠⠇ | ⠠⠨⠇ |

039C | Μ | Greek capital letter mu | ⠨⠠⠍ | ⠠⠨⠍ |

039D | Ν | Greek capital letter nu | ⠨⠠⠝ | ⠠⠨⠝ |

039E | Ξ | Greek capital letter xi | ⠨⠠⠭ | ⠠⠨⠭ |

039F | Ο | Greek capital letter omicron | ⠨⠠⠕ | ⠠⠨⠕ |

03A0 | Π | Greek capital letter pi | ⠨⠠⠏ | ⠠⠨⠏ |

03A1 | Ρ | Greek capital letter rho | ⠨⠠⠗ | ⠠⠨⠗ |

03A3 | Σ | Greek capital letter sigma | ⠨⠠⠎ | ⠠⠨⠎ |

03A4 | Τ | Greek capital letter tau | ⠨⠠⠞ | ⠠⠨⠞ |

03A5 | Υ | Greek capital letter upsilon | ⠨⠠⠥ | ⠠⠨⠥ |

03A6 | Φ | Greek capital letter phi | ⠨⠠⠋ | ⠠⠨⠋ |

03A7 | Χ | Greek capital letter chi | ⠨⠠⠯ | ⠠⠨⠯ |

03A8 | Ψ | Greek capital letter psi | ⠨⠠⠽ | ⠠⠨⠽ |

03A9 | Ω | Greek capital letter omega | ⠨⠠⠺ | ⠠⠨⠺ |

03B1 | α | Greek small letter alpha | ⠨⠁ | ⠨⠁ |

03B2 | β | Greek small letter beta | ⠨⠃ | ⠨⠃ |

03B3 | γ | Greek small letter gamma | ⠨⠛ | ⠨⠛ |

03B4 | δ | Greek small letter delta | ⠨⠙ | ⠨⠙ |

03B5 | ε | Greek small letter epsilon
(alternative epsilon) |
⠨⠈⠑ | ⠨⠑ |

03B6 | ζ | Greek small letter zeta | ⠨⠵ | ⠨⠵ |

03B7 | η | Greek small letter eta | ⠨⠱ | ⠨⠱ |

03B8 | θ | Greek small letter theta | ⠨⠹ | ⠨⠹ |

03B9 | ι | Greek small letter iota | ⠨⠊ | ⠨⠊ |

03BA | κ | Greek small letter kappa | ⠨⠅ | ⠨⠅ |

03BB | λ | Greek small letter lambda | ⠨⠇ | ⠨⠇ |

03BC | μ | Greek small letter mu | ⠨⠍ | ⠨⠍ |

03BD | ν | Greek small letter nu | ⠨⠝ | ⠨⠝ |

03BE | ξ | Greek small letter xi | ⠨⠭ | ⠨⠭ |

03BF | ο | Greek small letter omicron | ⠨⠕ | ⠨⠕ |

03C0 | π | Greek small letter pi | ⠨⠏ | ⠨⠏ |

03C1 | ρ | Greek small letter rho | ⠨⠗ | ⠨⠗ |

03C2 | ς | Greek small letter final sigma | ⠨⠒ | ⠨⠎ |

03C3 | σ | Greek small letter sigma | ⠨⠎ | ⠨⠎ |

03C4 | τ | Greek small letter tau | ⠨⠞ | ⠨⠞ |

03C5 | υ | Greek small letter upsilon | ⠨⠥ | ⠨⠥ |

03C6 | φ | Greek small letter phi
(alternative phi) |
⠨⠈⠋ | ⠨⠋ |

03C7 | χ | Greek small letter chi | ⠨⠯ | ⠨⠯ |

03C8 | ψ | Greek small letter psi | ⠨⠽ | ⠨⠽ |

03C9 | ω | Greek small letter omega | ⠨⠺ | ⠨⠺ |

03D1 | ϑ | Greek theta symbol | ⠨⠈⠹ | |

03D5 | ϕ | Greek phi symbol | ⠨⠋ | |

03D6 | ϖ | Greek pi symbol | ⠨⠈⠏ | |

03F0 | ϰ | Greek kappa symbol | ⠨⠈⠅ | |

03F5 | ϵ | Greek lunate epsilon symbol | ⠨⠑ | |

2014 | — | Em dash | ⠤⠤ | ⠠⠤ |

2015 | ― | Horizontal bar | ⠤⠤⠤⠤ | ⠐⠠⠤ |

2018 | ‘ | Left single quotation mark | ⠠⠦ | ⠠⠦ |

2019 | ’ | Right single quotation mark | ⠴⠠ | ⠠⠴ |

201C | “ | Left double quotation mark | ⠦ | ⠘⠦ |

201D | ” | Right double quotation mark | ⠴ | ⠘⠴ |

2020 | † | Dagger | ⠸⠻ | ⠈⠠⠹ |

2021 | ‡ | Double dagger | ⠸⠸⠻ | ⠈⠠⠻ |

2022 | • | Bullet | ⠔⠔ | ⠸⠲ |

2026 | … | Ellipsis | ⠄⠄⠄ | |

2030 | ‰ | Per mille sign | ⠈⠴⠴ | |

2031 | ‱ | Per ten thousand sign | ⠈⠴⠴⠴ | |

2032 | ′ | Prime | ⠄ | ⠶ |

2033 | ″ | Double prime | ⠄⠄ | ⠶⠶ |

210F | ℏ | Planck constant over two pi | ⠈⠓ | |

2113 | ℓ | Script small l
(differs from 1d4c1: 4-56-123) |
⠈⠇ | |

211D | ℝ | Double-struck capital R
(no nemeth double struck) |
||

212B | Å | Angstrom sign | ⠈⠠⠁ | |

2146 | ⅆ | Double-struck italic small d | ||

2147 | ⅇ | Double-struck italic small e | ||

2190 | ← | Leftwards arrow | ⠀⠫⠪⠒⠒⠀ | ⠳⠪ |

2191 | ↑ | Upwards arrow | ⠀⠫⠣⠒⠒⠕⠀ | ⠳⠬ |

2192 | → | Rightwards arrow | ⠀⠫⠕⠀ | ⠳⠕ |

2192 | → | Rightwards arrow | ⠀⠫⠒⠒⠕⠀ | |

2193 | ↓ | Downwards arrow | ⠀⠫⠩⠒⠒⠕⠀ | ⠳⠩ |

2194 | Left right arrow | ⠀⠫⠪⠒⠒⠕⠀ | ⠰⠳⠺⠗⠕ | |

2195 | Up down arrow | ⠀⠫⠣⠪⠒⠒⠕⠀ | ||

2196 | North west arrow | ⠀⠫⠘⠪⠒⠒⠀ | ⠳⠱ | |

2197 | North east arrow | ⠀⠫⠘⠒⠒⠕⠀ | ⠳⠎ | |

2198 | South east arrow | ⠀⠫⠰⠒⠒⠕⠀ | ⠳⠣ | |

2199 | South west arrow | ⠀⠫⠰⠪⠒⠒⠀ | ⠳⠜ | |

219A | ↚ | Leftwards arrow w stroke | ⠀⠳⠈⠫⠪⠒⠒⠻⠀ | |

219B | ↛ | Rightwards arrow w stroke | ⠀⠳⠈⠫⠒⠒⠕⠻⠀ | |

219C | ↜ | Leftwards wave arrow | ⠀⠫⠪⠔⠒⠢⠀ | |

219D | ↝ | Rightwards wave arrow | ⠀⠫⠔⠒⠢⠕⠀ | |

219E | ↞ | Leftwards two headed arrow | ⠀⠫⠪⠪⠒⠒⠀ | |

219F | ↟ | Upwards two headed arrow | ⠀⠫⠣⠒⠒⠕⠕⠀ | |

21A0 | ↠ | Rightwards two headed arrow | ⠀⠫⠒⠒⠕⠕⠀ | |

21A1 | ↡ | Downwards two headed arrow | ⠀⠫⠩⠒⠒⠕⠕⠀ | |

21A2 | ↢ | Leftwards arrow w tail | ⠀⠫⠪⠒⠒⠠⠽⠀ | |

21A3 | ↣ | Rightwards arrow w tail | ⠀⠫⠠⠯⠒⠒⠕⠀ | |

21A4 | ↤ | Leftwards arrow from bar | ⠀⠫⠪⠒⠒⠳⠀ | |

21A5 | ↥ | Upwards arrow from bar | ⠀⠫⠣⠳⠒⠒⠕⠀ | |

21A6 | ↦ | Rightwards arrow from bar | ⠀⠫⠳⠒⠒⠕⠀ | |

21A7 | ↧ | Downwards arrow from bar | ⠀⠫⠩⠳⠒⠒⠕⠀ | |

21A8 | ↨ | Up down arrow w base | ⠀⠫⠣⠪⠒⠒⠕⠳⠀ | |

21A9 | Leftwards arrow w hook | ⠀⠫⠪⠒⠒⠈⠽⠀ | ||

21AA | Rightwards arrow w hook | ⠀⠫⠈⠯⠒⠒⠕⠀ | ||

21AB | ↫ | Leftwards arrow w loop | ||

21AC | ↬ | Rightwards arrow w loop | ||

21AD | ↭ | Left right wave arrow | ⠀⠫⠪⠔⠒⠢⠕⠀ | |

21AE | ↮ | Left right arrow w stroke | ⠀⠳⠈⠫⠪⠒⠒⠕⠻⠀ | |

21AF | ↯ | Downwards zigzag arrow | ⠀⠫⠩⠔⠢⠔⠕⠀ | |

21B4 | ↴ | Rightwards arrow w corner downwards | ⠀⠫⠩⠠⠳⠒⠕⠀ | |

21B5 | ↵ | Downwards arrow w corner leftwards | ⠀⠫⠪⠒⠈⠳⠀ | |

21B6 | ↶ | Anticlockwise top semicircle arrow | ||

21B7 | ↷ | Clockwise top semicircle arrow | ||

21BA | ↺ | Anticlockwise open circle arrow | ⠀⠫⠢⠔⠕⠀ | |

21BB | ↻ | Clockwise open circle arrow | ⠀⠫⠪⠢⠔⠀ | |

21BC | ↼ | Leftwards harpoon w barb upwards | ⠀⠫⠈⠪⠒⠒⠀ | |

21BD | ↽ | Leftwards harpoon w barb downwards | ⠀⠫⠠⠪⠒⠒⠀ | |

21BE | ↾ | Upwards harpoon w barb rightwards | ⠀⠫⠣⠒⠒⠠⠕⠀ | |

21BF | ↿ | Upwards harpoon w barb leftwards | ⠀⠫⠣⠒⠒⠈⠕⠀ | |

21C0 | ⇀ | Rightwards harpoon w barb upwards | ⠀⠫⠒⠒⠈⠕⠀ | |

21C1 | ⇁ | Rightwards harpoon w barb downwards | ⠀⠫⠒⠒⠠⠕⠀ | |

21C2 | ⇂ | Downwards harpoon w barb rightwards | ⠀⠫⠩⠒⠒⠈⠕⠀ | |

21C3 | ⇃ | Downwards harpoon w barb leftwards | ⠀⠫⠩⠒⠒⠠⠕⠀ | |

21C4 | ⇄ | Rightwards arrow over leftwards arrow | ⠀⠫⠒⠒⠕⠫⠪⠒⠒⠀ | |

21C5 | ⇅ | Upwards arrow leftwards
of downwards arrow |
⠀⠫⠣⠒⠒⠕⠐⠫⠩⠒⠒⠕⠀ | |

21C6 | ⇆ | Leftwards arrow over rightwards arrow | ⠀⠫⠪⠒⠒⠫⠒⠒⠕⠀ | |

21C7 | ⇇ | Leftwards paired arrows | ⠀⠫⠪⠒⠒⠫⠪⠒⠒⠀ | |

21C8 | ⇈ | Upwards paired arrows | ⠀⠫⠣⠒⠒⠕⠐⠫⠣⠒⠒⠕⠀ | |

21C9 | ⇉ | Rightwards paired arrows | ⠀⠫⠒⠒⠕⠫⠒⠒⠕⠀ | |

21CA | ⇊ | Downwards paired arrows | ⠀⠫⠩⠒⠒⠕⠐⠫⠩⠒⠒⠕⠀ | |

21CB | ⇋ | Leftwards harpoon over rightwards
harpoon |
⠀⠫⠈⠪⠒⠒⠫⠒⠒⠠⠕⠀ | |

21CC | ⇌ | Rightwards harpoon over leftwards
harpoon |
⠀⠫⠒⠒⠈⠕⠫⠠⠪⠒⠒⠀ | |

21CD | ⇍ | Leftwards double arrow w stroke | ⠀⠳⠈⠫⠪⠶⠶⠻⠀ | |

21CE | ⇎ | Left right double arrow w stroke | ⠀⠳⠈⠫⠪⠶⠶⠕⠻⠀ | |

21CF | ⇏ | Rightwards double arrow w stroke | ⠀⠳⠈⠫⠶⠶⠕⠻⠀ | |

21D0 | ⇐ | Leftwards double arrow | ⠀⠫⠪⠶⠶⠀ | ⠰⠳⠶⠶⠪ |

21D1 | ⇑ | Upwards double arrow | ⠀⠫⠣⠶⠶⠕⠀ | ⠰⠳⠶⠶⠬ |

21D2 | ⇒ | Rightwards double arrow | ⠀⠫⠶⠶⠕⠀ | ⠰⠳⠶⠶⠕ |

21D3 | ⇓ | Downwards double arrow | ⠀⠫⠩⠶⠶⠕⠀ | ⠰⠳⠶⠶⠩ |

21D4 | ⇔ | Left right double arrow | ⠀⠫⠪⠶⠶⠕⠀ | |

21D5 | ⇕ | Up down double arrow | ⠀⠫⠣⠪⠶⠶⠕⠀ | |

21D6 | ⇖ | North west double arrow | ⠀⠫⠘⠪⠶⠶⠀ | |

21D7 | ⇗ | North east double arrow | ⠀⠫⠘⠶⠶⠕⠀ | |

21D8 | ⇘ | South east double arrow | ⠀⠫⠰⠶⠶⠕⠀ | |

21D9 | ⇙ | South west double arrow | ⠀⠫⠰⠪⠶⠶⠀ | |

21DA | ⇚ | Leftwards triple arrow | ⠀⠫⠪⠸⠸⠀ | |

21DB | ⇛ | Rightwards triple arrow | ⠀⠫⠸⠸⠕⠀ | |

21DC | ⇜ | Leftwards squiggle arrow | ⠀⠫⠪⠢⠤⠔⠒⠢⠀ | |

21DD | ⇝ | Rightwards squiggle arrow | ⠀⠫⠢⠤⠔⠒⠢⠕⠀ | |

21DE | ⇞ | Upwards arrow w double stroke | ⠀⠳⠳⠈⠫⠣⠒⠒⠕⠻⠀ | |

21DF | ⇟ | Downwards arrow w double stroke | ⠀⠳⠳⠈⠫⠩⠒⠒⠕⠻⠀ | |

21E0 | ⇠ | Leftwards dashed arrow | ⠀⠫⠪⠒⠀⠒⠀ | |

21E1 | ⇡ | Upwards dashed arrow | ⠀⠫⠣⠒⠀⠒⠕⠀ | |

21E2 | ⇢ | Rightwards dashed arrow | ⠀⠫⠒⠀⠒⠕⠀ | |

21E3 | ⇣ | Downwards dashed arrow | ⠀⠫⠩⠒⠀⠒⠕⠀ | |

21E4 | ⇤ | Leftwards arrow to bar | ⠀⠳⠫⠪⠒⠒⠀ | |

21E5 | ⇥ | Rightwards arrow to bar | ⠀⠫⠒⠒⠕⠳⠀ | |

21E6 | ⇦ | Leftwards white arrow | ||

21E7 | ⇧ | Upwards white arrow | ||

21E8 | ⇨ | Rightwards white arrow | ||

21E9 | ⇩ | Downwards white arrow | ||

21F3 | ⇳ | Up down white arrow | ||

21F4 | ⇴ | Right arrow w small circle | ⠀⠨⠡⠈⠫⠒⠒⠕⠻⠀ | |

21F5 | ⇵ | Downwards arrow leftwards
of upwards arrow |
⠀⠫⠩⠒⠒⠕⠐⠫⠣⠒⠒⠕⠀ | |

21F6 | ⇶ | Three rightwards arrows | ⠀⠫⠒⠒⠕⠫⠒⠒⠕⠫⠒⠒⠕⠀ | |

21F7 | ⇷ | Leftwards arrow w vertical stroke | ⠀⠳⠈⠫⠪⠒⠒⠻⠀ | |

21F8 | ⇸ | Rightwards arrow w vertical stroke | ⠀⠳⠈⠫⠒⠒⠕⠻⠀ | |

21F9 | ⇹ | Left right arrow w vertical stroke | ⠀⠳⠈⠫⠪⠒⠒⠕⠻⠀ | |

21FA | ⇺ | Leftwards arrow w double vertical stroke | ⠀⠳⠳⠈⠫⠪⠒⠒⠻⠀ | |

21FB | ⇻ | Rightwards arrow w double vertical stroke | ⠀⠳⠳⠈⠫⠒⠒⠕⠻⠀ | |

21FC | ⇼ | Left right arrow w double vertical stroke | ⠀⠳⠳⠈⠫⠪⠒⠒⠕⠻⠀ | |

21FD | ⇽ | Leftwards open-headed arrow | ||

21FE | ⇾ | Rightwards open-headed arrow | ||

21FF | ⇿ | Left right open-headed arrow | ||

2200 | ∀ | For all | ⠈⠯ | ⠘⠁ |

2202 | ∂ | Partial differential | ⠈⠙ | ⠈⠙ |

2203 | ∃ | There exists | ⠈⠿ | ⠘⠢ |

2204 | ∄ | There does not exist | ⠌⠈⠿ | |

2205 | ∅ | Empty set | ⠸⠴ | ⠈⠚ |

2207 | ∇ | Nabla | ⠨⠫ | ⠘⠙ |

2208 | ∈ | Element of | ⠀⠈⠑⠀ | ⠘⠑ |

2209 | ∉ | Not an element of | ⠀⠌⠈⠑⠀ | |

220B | ∋ | Contains as member | ⠀⠈⠢⠀ | ⠈⠘⠑ |

220C | ∌ | Does not contain as member | ⠀⠌⠈⠢⠀ | |

220E | ∎ | End of proof | ⠸⠳ | |

2211 | ∑ | N-ary summation | ⠨⠠⠎ | |

2212 | − | Minus sign | ⠤ | ⠐⠤ |

2213 | ∓ | Minus-or-plus sign | ⠤⠬ | ⠸⠤ |

2214 | ∔ | Dot plus | ⠐⠬⠣⠡⠻ | |

2215 | ∕ | Division slash | ⠸⠌ | |

2217 | ∗ | Asterisk operator | ⠈⠼ | |

2218 | ∘ | Ring operator | ⠨⠡ | ⠐⠴ |

221A | √ | Square root | ⠜ | ⠐⠩ |

221B | ∛ | Cube root | ⠣⠒⠜ | |

221C | ∜ | Fourth root | ⠣⠲⠜ | |

221D | ∝ | Proportional to | ⠀⠸⠿⠀ | ⠸⠐⠶ |

221E | ∞ | Infinity | ⠠⠿ | ⠼⠿ |

221F | ∟ | Right angle | ⠫⠪⠨⠗⠻ | |

2220 | ∠ | Angle | ⠫⠪ | ⠸⠪ |

2221 | ∡ | Measured angle | ⠫⠪⠈⠫⠁⠻ | ⠨⠸⠪ |

2223 | ∣ | Divides | ⠀⠳⠀ | |

2224 | ∤ | Does not divide | ⠀⠌⠳⠀ | |

2225 | ∥ | Parallel to | ⠀⠫⠇⠀ | ⠼⠇ |

2226 | ∦ | Not parallel to | ⠀⠌⠫⠇⠀ | |

2227 | ∧ | Logical AND | ⠈⠩ | ⠈⠦ |

2228 | ∨ | Logical OR | ⠈⠬ | ⠈⠖ |

2229 | ∩ | Intersection | ⠨⠩ | ⠨⠦ |

222A | ∪ | Union | ⠨⠬ | ⠨⠖ |

222B | ∫ | Integral | ⠮ | ⠮ |

222C | ∬ | Double integral | ⠮⠮ | ⠮⠮ |

222D | ∭ | Triple integral | ⠮⠮⠮ | ⠮⠮⠮ |

222E | ∮ | Contour integral | ⠮⠈⠫⠉⠻ | ⠈⠮ |

2232 | ∲ | Clockwise contour integral ???
§156 has half arcs |
⠮⠈⠫⠪⠢⠔⠻ | |

2233 | ∳ | Anticlockwise contour integral ??? | ⠮⠈⠫⠢⠔⠕⠻ | |

2234 | ∴ | Therefore | ⠀⠠⠡⠀ | ⠠⠡ |

2235 | ∵ | Because | ⠀⠈⠌⠀ | ⠈⠌ |

2236 | ∶ | Ratio | ⠀⠐⠂⠀ | ⠒ |

2237 | ∷ | Proportion | ⠀⠰⠆⠀ | ⠒⠒ |

2238 | ∸ | Dot minus | ⠨⠤ | |

2239 | ∹ | Excess | ⠀⠤⠐⠂⠀ | |

223A | ∺ | Geometric proportion | ⠀⠐⠤⠩⠡⠡⠣⠡⠡⠻⠀ | |

223B | ∻ | Homothetic | ⠀⠐⠈⠱⠩⠡⠣⠡⠻⠀ | |

223C | ∼ | Tilde operator | ⠀⠈⠱⠀ | |

223D | ∽ | Reversed tilde | ⠀⠠⠱⠀ | |

2242 | ≂ | Minus tilde | ⠀⠱⠈⠱⠀ | |

2243 | ≃ | Asymptotically equal to | ⠀⠈⠱⠱⠀ | ⠸⠔ |

2245 | ≅ | Approximately equal to | ⠀⠈⠱⠨⠅⠀ | ⠐⠸⠔ |

2248 | ≈ | Almost equal to | ⠀⠈⠱⠈⠱⠀ | ⠘⠔ |

224A | ≊ | Almost equal or equal to | ⠀⠈⠱⠈⠱⠱⠀ | |

224B | ≋ | Triple tilde | ⠀⠈⠱⠈⠱⠈⠱⠀ | |

224C | ≌ | All equal to | ⠀⠠⠱⠨⠅⠀ | |

224D | ≍ | Equivalent to | ⠀⠫⠠⠫⠈⠀ | |

224E | ≎ | Geometrically equivalent to | ⠀⠈⠣⠠⠣⠀ | |

224F | ≏ | Difference between | ⠀⠈⠣⠱⠀ | ⠘⠐⠶ |

2250 | ≐ | Approaches the limit | ⠀⠐⠨⠅⠣⠡⠻⠀ | |

2251 | ≑ | Geometrically equal to | ⠀⠐⠨⠅⠩⠡⠣⠡⠻⠀ | ⠨⠐⠶ |

2254 | ≔ | Colon equals | ⠀⠐⠂⠨⠅⠀ | |

2255 | ≕ | Equals colon | ⠀⠨⠅⠐⠂⠀ | |

2256 | ≖ | Ring in equal to | ⠀⠨⠡⠈⠨⠅⠻⠀ | |

2257 | ≗ | Ring equal to | ⠀⠐⠨⠅⠣⠨⠡⠻⠀ | |

2258 | ≘ | Corresponds to | ⠀⠐⠨⠅⠣⠫⠁⠻⠀ | |

2259 | ≙ | Estimates | ⠀⠐⠨⠅⠣⠸⠣⠻⠀ | |

225A | ≚ | Equiangular to | ⠀⠐⠨⠅⠣⠸⠩⠻⠀ | |

225B | ≛ | Star equals | ⠀⠐⠨⠅⠣⠫⠎⠻⠀ | |

225C | ≜ | Delta equal to | ⠀⠐⠨⠅⠣⠫⠞⠻⠀ | |

225D | ≝ | Equal to by definition | ⠀⠐⠨⠅⠣⠙⠑⠋⠻⠀ | |

225E | ≞ | Measured by | ⠀⠐⠨⠅⠣⠍⠻⠀ | |

225F | ≟ | Questioned equal to | ⠀⠐⠨⠅⠣⠸⠢⠻⠀ | |

2260 | ≠ | Not equal to | ⠀⠌⠨⠅⠀ | ⠐⠶⠈⠱ |

2261 | ≡ | Identical to | ⠀⠸⠇⠀ | ⠸⠿ |

2262 | ≢ | Not identical to | ⠀⠌⠸⠇⠀ | |

2264 | ≤ | Less-than or equal to | ⠀⠐⠅⠱⠀ | ⠸⠈⠣ |

2265 | ≥ | Greater-than or equal to | ⠀⠨⠂⠱⠀ | ⠸⠈⠜ |

2266 | ≦ | Less-than over equal to | ⠀⠐⠅⠨⠅⠀ | |

2267 | ≧ | Greater-than over equal to | ⠀⠨⠂⠨⠅⠀ | |

2268 | ≨ | Less-than but not equal to | ⠀⠐⠅⠌⠨⠅⠀ | |

2269 | ≩ | Greater-than but not equal to | ⠀⠨⠂⠌⠨⠅⠀ | |

226A | ≪ | Much less-than | ⠀⠐⠅⠈⠐⠅⠻⠀ | ⠨⠈⠣ |

226B | ≫ | Much greater-than | ⠀⠨⠂⠈⠨⠂⠻⠀ | ⠨⠈⠜ |

226D | ≭ | Not equivalent to | ⠀⠌⠈⠣⠠⠣⠀ | |

226E | ≮ | Not less-than | ⠀⠌⠐⠅⠀ | |

226F | ≯ | Not greater-than | ⠀⠌⠨⠂⠀ | |

2270 | ≰ | Neither less-than nor equal to | ⠀⠌⠐⠅⠱⠀ | |

2271 | ≱ | Neither greater-than nor equal to | ⠀⠌⠨⠂⠱⠀ | |

2272 | ≲ | Less-than or equivalent to | ⠀⠐⠅⠈⠱⠀ | |

2273 | ≳ | Greater-than or equivalent to | ⠀⠨⠂⠈⠱⠀ | |

2274 | ≴ | Neither less-than nor equivalent to | ⠀⠌⠐⠅⠈⠱⠀ | |

2275 | ≵ | Neither greater-than nor equivalent to | ⠀⠌⠨⠂⠈⠱⠀ | |

2276 | ≶ | Less-than or greater-than | ⠀⠐⠅⠨⠂⠀ | |

2277 | ≷ | Greater-than or less-than | ⠀⠨⠂⠐⠅⠀ | |

2278 | ≸ | Neither less-than nor greater-than | ⠀⠌⠐⠅⠨⠂⠀ | |

2279 | ≹ | Neither greater-than nor less-than | ⠀⠌⠨⠂⠐⠅⠀ | |

227A | ≺ | Precedes | ⠀⠨⠐⠅⠀ | |

227B | ≻ | Succeeds | ⠀⠨⠨⠂⠀ | |

227E | ≾ | Precedes or equivalent to | ⠀⠨⠐⠅⠈⠱⠀ | |

227F | ≿ | Succeeds or equivalent to | ⠀⠨⠨⠂⠈⠱⠀ | |

2282 | ⊂ | Subset of | ⠀⠸⠐⠅⠀ | ⠘⠣ |

2283 | ⊃ | Superset of | ⠀⠸⠨⠂⠀ | ⠘⠜ |

2284 | ⊄ | Not a subset of | ⠀⠌⠸⠐⠅⠀ | |

2285 | ⊅ | Not a superset of | ⠀⠌⠸⠨⠂⠀ | |

2286 | ⊆ | Subset of or equal to | ⠀⠸⠐⠅⠱⠀ | ⠸⠘⠣ |

2287 | ⊇ | Superset of or equal to | ⠀⠸⠨⠂⠱⠀ | ⠸⠘⠜ |

2288 | ⊈ | Neither a subset of nor equal to | ⠀⠌⠸⠐⠅⠱⠀ | |

2289 | ⊉ | Neither a superset of nor equal to | ⠀⠌⠸⠨⠂⠱⠀ | |

228A | ⊊ | Subset of w not equal to | ⠀⠸⠐⠅⠌⠱⠀ | ⠨⠘⠣ |

228B | ⊋ | Superset of w not equal to | ⠀⠸⠨⠂⠌⠱⠀ | ⠨⠘⠜ |

228C | ⊌ | Multiset | ⠨⠬⠈⠫⠪⠒⠻ | |

228D | ⊍ | Multiset multiplication | ⠡⠈⠨⠬⠻ | |

228E | ⊎ | Multiset union | ⠬⠈⠨⠬⠻ | |

2295 | ⊕ | Circled plus | ⠫⠉⠸⠫⠬⠻ | ⠰⠫⠿⠪⠐⠖⠱ |

2296 | ⊖ | Circled minus | ⠫⠉⠸⠫⠤⠻ | |

2297 | ⊗ | Circled times | ⠫⠉⠸⠫⠈⠡⠻ | |

2298 | ⊘ | Circled division slash | ⠫⠉⠸⠫⠸⠌⠻ | |

2299 | ⊙ | Circled dot operator | ⠫⠉⠸⠫⠡⠻ | |

229B | ⊛ | Circled asterisk operator | ⠫⠉⠸⠫⠈⠼⠻ | |

229C | ⊜ | Circled equals | ⠫⠉⠸⠫⠨⠅⠻ | |

229D | ⊝ | Circled dash | ⠫⠉⠸⠫⠤⠤⠻ | |

229E | ⊞ | Squared plus | ⠫⠲⠸⠫⠬⠻ | |

229F | ⊟ | Squared minus | ⠫⠲⠸⠫⠤⠻ | |

22A0 | ⊠ | Squared times | ⠫⠲⠸⠫⠈⠡⠻ | |

22A1 | ⊡ | Squared dot operator | ⠫⠲⠸⠫⠡⠻ | |

22A2 | ⊢ | Right tack | ⠀⠫⠳⠒⠀ | |

22A3 | ⊣ | Left tack | ⠀⠫⠒⠳⠀ | ⠈⠸⠒ |

22A4 | ⊤ | Down tack | ⠀⠫⠩⠳⠒⠀ | |

22A5 | ⊥ | Up tack (See also 27C2) | ⠀⠫⠏⠀ or ⠀⠫⠣⠳⠒⠀ | ⠼⠤ |

22A6 | ⊦ | Assertion | ⠸⠒ | |

22A8 | ⊨ | True | ⠘⠸⠒ | |

22B2 | ⊲ | Normal subgroup of | ⠈⠸⠣ | |

22B3 | ⊳ | Contains as normal subgroup | ⠈⠸⠜ | |

22B4 | ⊴ | Normal subgroup of or equal to | ⠸⠸⠣ | |

22B5 | ⊵ | Contains as normal subgroup or equal to | ⠸⠸⠜ | |

22B6 | ⊶ | Original of | ⠀⠫⠨⠡⠒⠡⠀ | |

22B7 | ⊷ | Image of | ⠀⠫⠡⠒⠨⠡⠀ | |

22B8 | ⊸ | Multimap | ⠀⠫⠒⠨⠡⠀ | |

22BE | ⊾ | Right angle w arc | ⠼⠸⠪ | |

22BF | ⊿ | Right triangle | ⠫⠞⠨⠗⠻ | |

22C5 | ⋅ | Dot operator | ⠡ | ⠐⠲ |

22C6 | ⋆ | Star operator | ⠫⠎ | |

22CD | ⋍ | Reversed tilde equals | ⠀⠠⠱⠱⠀ | |

22D6 | ⋖ | Less-than w dot | ⠀⠡⠈⠐⠅⠻⠀ | |

22D7 | ⋗ | Greater-than w dot | ⠀⠡⠈⠨⠂⠻⠀ | |

22D8 | ⋘ | Much less-than | ⠀⠐⠅⠈⠐⠅⠈⠐⠅⠻⠀ | |

22D9 | ⋙ | Much greater-than | ⠀⠨⠂⠈⠨⠂⠈⠨⠂⠻⠀ | |

22DC | ⋜ | Equal to or less-than | ⠀⠱⠐⠅⠀ | |

22DD | ⋝ | Equal to or greater-than | ⠀⠱⠨⠂⠀ | |

22EE | ⋮ | Vertical ellipsis | ⠀⠩⠒⠒⠒⠀ | |

22EF | ⋯ | Midline horizontal ellipsis | ⠀⠒⠒⠒ | |

22F0 | ⋰ | Up right diagonal ellipsis | ⠀⠘⠒⠒⠒⠀ | |

22F1 | ⋱ | Down right diagonal ellipsis | ⠀⠰⠒⠒⠒⠀ | |

22F2 | ⋲ | Element of w long horizontal stroke | ⠀⠱⠈⠈⠑⠻⠀ | |

22F5 | ⋵ | Element of w dot above | ⠀⠐⠈⠑⠣⠡⠻⠀ | |

22F6 | ⋶ | Element of w overbar | ⠀⠱⠈⠑⠀ | |

22FA | ⋺ | Contains w long horizontal stroke | ⠀⠱⠈⠈⠢⠻⠀ | |

22FD | ⋽ | Contains w overbar | ⠀⠱⠈⠢⠀ | |

2308 | ⌈ | Left ceiling | ⠈⠘⠷ | |

2309 | ⌉ | Right ceiling | ⠈⠘⠾ | |

230A | ⌊ | Left floor | ⠈⠰⠷ | |

230B | ⌋ | Right floor | ⠈⠰⠾ | |

2322 | ⌢ | Frown | ⠀⠫⠁⠀ | |

2323 | ⌣ | Smile | ⠀⠫⠄⠀ | |

25A0 | ■ | Filled square | ⠫⠸⠲ | |

25A1 | □ | Square | ⠫⠲ | |

25AC | ▬ | Filled rectangle | ⠫⠸⠗ | |

25AD | ▭ | Rectangle | ⠫⠗ | |

25B2 | ▲ | Black up-pointing triangle | ⠫⠸⠞ | |

25B3 | △ | White up-pointing triangle | ⠫⠞ | |

25BC | ▼ | Black down-pointing triangle | ⠸⠨⠫ | |

25CB | ○ | White circle | ⠫⠉ | ⠿ |

25CF | ● | Black circle | ⠫⠸⠉ | |

25EB | ◫ | White square w vertical bisecting line | ⠫⠲⠸⠫⠳⠻ | |

27C2 | ⊥ | Perpendicular | ⠀⠫⠏⠀ | |

27C3 | ⟃ | Open subset | ⠀⠨⠡⠈⠸⠐⠅⠻⠀ | |

27C4 | ⟄ | Open superset | ⠀⠨⠡⠈⠸⠨⠂⠻⠀ | |

27DC | ⟜ | Left multimap | ⠀⠫⠨⠡⠒⠒⠀ | |

27DD | ⟝ | Long right tack | ⠀⠫⠳⠒⠒⠀ | |

27DE | ⟞ | Long left tack | ⠀⠫⠒⠒⠳⠀ | |

27DF | ⟟ | Up tack w circle above | ⠫⠣⠳⠒⠒⠨⠡ | |

27E6 | ⟦ | Mathematical left white square bracket | ⠈⠸⠷ | |

27E7 | ⟧ | Mathematical right white square bracket | ⠈⠸⠾ | |

27E8 | ⟨ | Mathematical left angle bracket | ⠨⠨⠷ | |

27E9 | ⟩ | Mathematical right angle bracket | ⠨⠨⠾ | |

27F5 | ⟵ | Long leftwards arrow | ⠀⠫⠪⠒⠒⠒⠀ | |

27F6 | ⟶ | Long rightwards arrow | ⠀⠫⠒⠒⠒⠕⠀ | |

27F7 | ⟷ | Long left right arrow | ⠀⠫⠪⠒⠒⠒⠕⠀ | |

27F8 | ⟸ | Long leftwards arrow | ⠀⠫⠪⠶⠶⠶⠀ | |

27F9 | ⟹ | Long rightwards arrow | ⠀⠫⠶⠶⠶⠕⠀ | |

27FA | ⟺ | Long left right arrow | ⠀⠫⠪⠶⠶⠶⠕⠀ | |

27FB | ⟻ | Long leftwards arrow from bar | ⠀⠫⠪⠒⠒⠒⠳⠀ | |

27FC | ⟼ | Long rightwards arrow from bar | ⠀⠫⠳⠒⠒⠒⠕⠀ | |

27FD | ⟽ | Long leftwards double arrow from bar | ⠀⠫⠪⠶⠶⠶⠳⠀ | |

27FE | ⟾ | Long rightwards double arrow from bar | ⠀⠫⠳⠶⠶⠶⠕⠀ | |

27FF | ⟿ | Long rightwards squiggle arrow | ⠀⠫⠢⠤⠔⠒⠢⠤⠔⠒⠢⠕⠀ | |

2921 | ⤡ | North west and south east arrow | ⠀⠫⠘⠪⠒⠒⠕⠀ | |

2922 | ⤢ | North east and south west arrow | ⠀⠫⠰⠪⠒⠒⠕⠀ | |

2983 | ⦃ | Left white curly bracket | ⠨⠸⠷ | |

2984 | ⦄ | Right white curly bracket | ⠨⠸⠾ | |

2991 | ⦑ | Left angle bracket w dot | ⠡⠈⠨⠨⠷⠻ | |

2992 | ⦒ | Right angle bracket w dot | ⠡⠈⠨⠨⠾⠻ | |

29C4 | ⧄ | Square rising diagonal slash | ⠫⠲⠸⠫⠔⠻ | |

29C5 | ⧅ | Square falling diagonal slash | ⠫⠲⠸⠫⠢⠻ | |

29C6 | ⧆ | Squared asterisk | ⠫⠲⠸⠫⠈⠼⠻ | |

29CA | ⧊ | Triangle w dot above | ⠐⠫⠞⠣⠡⠻ | |

29CB | ⧋ | Triangle w underbar | ⠫⠞⠱ | |

29CC | ⧌ | s in triangle §114 | ⠫⠞⠎ | |

29E6 | ⧦ | Gleich stark | ⠫⠳⠶⠶⠳ | |

2A0C | ⨌ | Quadruple integral operator | ⠮⠮⠮⠮ | ⠮⠮⠮⠮ |

2A0D | ⨍ | Finite part integral | ⠮⠈⠱⠻ | |

2A0E | ⨎ | Integral w double stroke | ⠮⠈⠱⠱⠻ | |

2A16 | ⨖ | Quaternion integral operator | ⠮⠈⠫⠲⠻ | |

2A18 | ⨘ | Integral w times sign | ⠮⠈⠈⠡⠻ | |

2A19 | ⨙ | Integral w intersection | ⠮⠈⠨⠩⠻ | |

2A1A | ⨚ | Integral w union | ⠮⠈⠨⠬⠻ | |

2A1B | ⨛ | Integral w overbar (upper) | ⠣⠮ | |

2A1C | ⨜ | Integral w underbar (lower) | ⠩⠮ | |

2A22 | ⨢ | Plus sign w small circle above | ⠐⠬⠣⠨⠡⠻ | |

2A23 | ⨣ | Plus sign w circumflex accent above | ⠐⠬⠣⠸⠣⠻ | |

2A24 | ⨤ | Plus sign w tilde above | ⠐⠬⠣⠈⠱⠻ | |

2A25 | ⨥ | Plus sign w dot below | ⠐⠬⠩⠡⠻ | |

2A2A | ⨪ | Minus sign w dot below | ⠐⠱⠩⠡⠻ | |

2A30 | ⨰ | Multiplication sign w dot above | ⠐⠈⠡⠣⠡⠻ | |

2A31 | ⨱ | Multiplication sign w underbar | ⠈⠡⠱ | |

2A38 | ⨸ | Circled division sign | ⠫⠉⠸⠫⠨⠌⠻ | |

2A39 | ⨹ | Plus sign in triangle | ⠫⠞⠸⠫⠬⠻ | |

2A3A | ⨺ | Minus sign in triangle | ⠫⠞⠸⠫⠤⠻ | |

2A3B | ⨻ | Multiplication sign in triangle | ⠫⠞⠸⠫⠈⠡⠻ | |

2A40 | ⩀ | Intersection w dot | ⠡⠈⠨⠩⠻ | |

2A41 | ⩁ | Union w minus sign | ⠤⠈⠨⠬⠻ | |

2A42 | ⩂ | Union w overbar | ⠱⠨⠬ | |

2A43 | ⩃ | Intersection w overbar | ⠱⠨⠩ | |

2A51 | ⩑ | Logical AND w dot above | ⠐⠈⠩⠣⠡⠻ | |

2A52 | ⩒ | Logical OR w dot above | ⠐⠈⠬⠣⠡⠻ | |

2A5C | ⩜ | Logical AND with horizontal dash | ⠱⠈⠈⠩⠻ | |

2A5D | ⩝ | Logical OR with horizontal dash | ⠱⠈⠈⠬⠻ | |

2A5E | ⩞ | Logical AND w double overbar | ⠱⠱⠈⠩ | |

2A5F | ⩟ | Logical AND w underbar | ⠈⠩⠱ | |

2A60 | ⩠ | Logical AND w double underbar | ⠈⠩⠱⠱ | |

2A62 | ⩢ | Logical OR w double overbar | ⠱⠱⠈⠬ | |

2A63 | ⩣ | Logical OR w double underbar | ⠈⠬⠱⠱ | |

2A66 | ⩦ | Equals sign w dot below | ⠀⠐⠨⠅⠩⠡⠻⠀ | |

2A67 | ⩧ | Identical w dot above | ⠀⠐⠸⠇⠣⠡⠻⠀ | |

2A6A | ⩪ | Tilde operator w dot above | ⠀⠐⠈⠱⠣⠡⠻⠀ | |

2A6C | ⩬ | Similar minus similar | ⠀⠈⠱⠱⠈⠱⠀ | |

2A6D | ⩭ | Congruent w dot above | ⠀⠐⠈⠱⠨⠅⠣⠡⠻⠀ | |

2A6E | ⩮ | Equals w asterisk | ⠀⠐⠨⠅⠣⠈⠼⠻⠀ | |

2A6F | ⩯ | Almost equal to w circumflex | ⠀⠐⠈⠱⠈⠱⠣⠸⠣⠻⠀ | |

2A70 | ⩰ | Approximately equal or equal to | ⠀⠈⠱⠈⠱⠨⠅⠀ | |

2A71 | ⩱ | Equals sign above plus sign | ⠀⠨⠅⠬⠀ | |

2A72 | ⩲ | Plus sign above equals sign | ⠀⠬⠨⠅⠀ | |

2A73 | ⩳ | Equals sign above tilde operator | ⠀⠨⠅⠈⠱⠀ | |

2A74 | ⩴ | Double colon equal | ⠀⠐⠂⠐⠂⠨⠅⠀ | |

2A75 | ⩵ | Two consecutive equals signs | ⠀⠨⠅⠨⠅⠀ | |

2A76 | ⩶ | Three consecutive equals signs | ⠀⠨⠅⠨⠅⠨⠅⠀ | |

2A77 | ⩷ | Equals sign w two dots above and two dots below | ⠀⠐⠨⠅⠩⠡⠡⠣⠡⠡⠻⠀ | |

2A78 | ⩸ | Equivalent w four dots above | ⠀⠐⠸⠇⠣⠡⠡⠡⠡⠻⠀ | |

2A79 | ⩹ | Less than w circle inside | ⠀⠐⠅⠈⠨⠡⠻⠀ | |

2A7A | ⩺ | Greater than w circle inside | ⠀⠨⠂⠈⠨⠡⠻⠀ | |

2A7B | ⩻ | Less-than w question mark above | ⠀⠐⠐⠅⠣⠸⠦⠻⠀ | |

2A7C | ⩼ | Greater-than w question mark above | ⠀⠐⠨⠂⠣⠸⠦⠻⠀ | |

2A85 | ⪅ | Less-than or approximate | ⠀⠐⠅⠈⠱⠈⠱⠀ | |

2A86 | ⪆ | Greater-than or approximate | ⠀⠨⠂⠈⠱⠈⠱⠀ | |

2A8B | ⪋ | Less-than above double-line equal above greater-than | ⠀⠐⠅⠨⠅⠨⠂⠀ | |

2A8C | ⪌ | Greater-than above double-line equal above less-than | ⠀⠨⠂⠨⠅⠐⠅⠀ | |

2A8D | ⪍ | Less-than above similar or equal to | ⠀⠐⠅⠈⠱⠱⠀ | |

2A8E | ⪎ | Greater-than above similar or equal to | ⠀⠨⠂⠈⠱⠱⠀ | |

2A8F | ⪏ | Less-than above similar above greater-than | ⠀⠐⠅⠈⠱⠨⠂⠀ | |

2A90 | ⪐ | Greater-than above similar above less-than | ⠀⠨⠂⠈⠱⠐⠅⠀ | |

2A91 | ⪑ | Less-than above greater-than above double-line equal | ⠀⠐⠅⠨⠂⠨⠅⠀ | |

2A92 | ⪒ | Greater-than above less-than above double-line equal | ⠀⠨⠂⠐⠅⠨⠅⠀ | |

2A99 | ⪙ | Double-line equal to or less-than | ⠀⠨⠅⠐⠅⠀ | |

2A9A | ⪚ | Double-line equal to or greater-than | ⠀⠨⠅⠨⠂⠀ | |

2A9D | ⪝ | Similar or less-than | ⠀⠈⠱⠐⠅⠀ | |

2A9E | ⪞ | Similar or greater-than | ⠀⠈⠱⠨⠂⠀ | |

2A9F | ⪟ | Similar above less-than above equals sign | ⠀⠈⠱⠐⠅⠨⠅⠀ | |

2AA0 | ⪠ | Similar above greater-than above equals sign | ⠀⠈⠱⠨⠂⠨⠅⠀ | |

2AAE | ⪮ | Equals sign with bumpy above | ⠀⠈⠣⠨⠅⠀ | |

2AAF | ⪯ | Precedes above single-line equals sign | ⠀⠨⠐⠅⠱⠀ | |

2AB0 | ⪰ | Succeeds above single-line equals sign | ⠀⠨⠨⠂⠱⠀ | |

2AB1 | ⪱ | Precedes above single-line not equal to | ⠀⠨⠐⠅⠌⠱⠀ | |

2AB2 | ⪲ | Succeeds above single-line not equal to | ⠀⠨⠨⠂⠌⠱⠀ | |

2AB3 | ⪳ | Precedes above equals sign | ⠀⠨⠐⠅⠨⠅⠀ | |

2AB4 | ⪴ | Succeeds above equals sign | ⠀⠨⠨⠂⠨⠅⠀ | |

2AB5 | ⪵ | Precedes above not equal to | ⠀⠨⠐⠅⠌⠨⠅⠀ | |

2AB6 | ⪶ | Succeeds above not equal to | ⠀⠨⠨⠂⠌⠨⠅⠀ | |

2AB7 | ⪷ | Precedes above almost equals to | ⠀⠨⠐⠅⠈⠱⠈⠱⠀ | |

2AB8 | ⪸ | Succeeds above almost equals to | ⠀⠨⠨⠂⠈⠱⠈⠱⠀ | |

2AB9 | ⪹ | Precedes above not almost equals to | ⠀⠨⠐⠅⠌⠈⠱⠈⠱⠀ | |

2ABA | ⪺ | Succeeds above not almost equals to | ⠀⠨⠨⠂⠌⠈⠱⠈⠱⠀ | |

2ABB | ⪻ | Double precedes | ⠀⠨⠐⠅⠈⠨⠐⠅⠻⠀ | |

2ABC | ⪼ | Double succeeds | ⠀⠨⠨⠂⠈⠨⠨⠂⠻⠀ | |

2ABD | ⪽ | Subset w dot | ⠀⠡⠈⠸⠐⠅⠻⠀ | |

2ABE | ⪾ | Superset w dot | ⠀⠡⠈⠸⠨⠂⠻⠀ | |

2ABF | ⪿ | Subset with plus sign below | ⠀⠐⠸⠐⠅⠩⠬⠻⠀ | |

2AC0 | ⫀ | Superset with plus sign below | ⠀⠐⠸⠨⠂⠩⠬⠻⠀ | |

2AC1 | ⫁ | Subset with multiplication sign below | ⠀⠐⠸⠐⠅⠩⠈⠡⠻⠀ | |

2AC2 | ⫂ | Superset with multiplication sign below | ⠀⠐⠸⠨⠂⠩⠈⠡⠻⠀ | |

2AC5 | ⫅ | Subset of above equals sign | ⠀⠸⠐⠅⠨⠅⠀ | |

2AC6 | ⫆ | Superset of above equals sign | ⠀⠸⠨⠂⠨⠅⠀ | |

2AC7 | ⫇ | Subset of above tilde operator | ⠀⠸⠐⠅⠈⠱⠀ | |

2AC8 | ⫈ | Superset of above tilde operator | ⠀⠸⠨⠂⠈⠱⠀ | |

2AC9 | ⫉ | Subset of above almost equal to | ⠀⠸⠐⠅⠈⠱⠈⠱⠀ | |

2ACA | ⫊ | Superset of above almost equal to | ⠀⠸⠨⠂⠈⠱⠈⠱⠀ | |

2ACB | ⫋ | Subset of above not equals sign | ⠀⠸⠐⠅⠌⠨⠅⠀ | |

2ACC | ⫌ | Superset of above not equals sign | ⠀⠸⠨⠂⠌⠨⠅⠀ | |

2AD3 | ⫓ | Subset above superset | ⠀⠸⠐⠅⠸⠨⠂⠀ | |

2AD4 | ⫔ | Superset above subset | ⠀⠸⠨⠂⠸⠐⠅⠀ | |

2AD5 | ⫕ | Subset above subset | ⠀⠸⠐⠅⠸⠐⠅⠀ | |

2AD6 | ⫖ | Superset above superset | ⠀⠸⠨⠂⠸⠨⠂⠀ | |

2AD7 | ⫗ | Superset beside subset | ⠀⠸⠨⠂⠐⠸⠐⠅⠀ | |

2AEF | ⫯ | Vertical line w circle above | ⠀⠫⠩⠨⠡⠒⠒⠀ | |

2AF0 | ⫰ | Vertical line w circle below | ⠀⠫⠣⠨⠡⠒⠒⠀ | |

2AF1 | ⫱ | Down tack w circle below | ⠀⠫⠣⠨⠡⠒⠒⠳⠀ | |

2AF2 | ⫲ | Parallel w horizontal stroke | ⠀⠱⠈⠫⠇⠻⠀ | |

2AF3 | ⫳ | Parallel w tilde operator | ⠀⠈⠱⠈⠫⠇⠻⠀ | |

2AF4 | ⫴ | Triple vertical bar binary relation | ⠀⠳⠳⠳⠀ | |

2B1F | ⬟ | Black pentagon | ⠫⠸⠢ | |

2B20 | ⬠ | White pentagon | ⠫⠢ | |

2B21 | ⬡ | White hexagon | ⠫⠖ | |

2B22 | ⬢ | Black hexagon | ⠫⠸⠖ | |

2B2C | ⬬ | Black ellipse | ⠫⠸⠑ | |

2B2D | ⬭ | White ellipse | ⠫⠑ | |

2B30 | ⬰ | Left arrow w small circle | ⠀⠨⠡⠈⠫⠪⠒⠒⠻⠀ | |

2B31 | ⬱ | Three leftwards arrows | ⠀⠫⠪⠒⠒⠫⠪⠒⠒⠫⠪⠒⠒⠀ | |

2B32 | ⬲ | Left arrow w circled plus | ⠀⠫⠪⠒⠒⠈⠫⠉⠸⠫⠬⠻⠀ | |

2BC3 | ⯃ | Horizontal black octagon | ⠫⠸⠦ |

In general, Unicode’s math characters are simpler to work with than the braille sequences since they are assigned separate character codes instead of being composed as sequences of 64 braille codes. Unicode has about 2310 math characters (see Math property in DerivedCoreProperties.txt) and to distinguish all of those without indicators would require 12-dot braille! Such a system would be hard to learn. LaTeX describes characters using control words consisting of a backslash followed by combinations of the 64 ASCII letters. That approach has mnemonic value, but it’s not as concise as the Nemeth braille character code sequences. When you get a feel for the Nemeth approach, a character’s Nemeth sequence gives a good idea of what a character is even if you haven’t encountered it before. UnicodeMath and Nemeth braille are intended to be read by human beings, whereas LaTeX and MathML are intended to be read by computer programs, notwithstanding that some TeXies can read LaTeX fluently! Nemeth math alphabets not in Unicode probably don’t have to be considered unless they show up in published documents.

The post Unicode Math Braille Sequences appeared first on Math in Office.

]]>