I have created a collection “Essai”, and I would like to create a book “discover” with items of this collection (theorems, examples, exercises…). However, it is not possible: the answer is always “no items available” “go to users data to change your profile” (or something like that). Something must missing in the oqmath/omdoc files, but I do not know what… Many thanks for an answer!

The earlier post Breaking Equations into Multiple Lines describes equation line breaking and alignment. In particular, long equations often do not fit on a single line and need to be broken up for display on multiple lines. Word 2007 offers two approaches: automatic and manual line breaking. A related feature is alignment of multiple equations, such as aligning the equal signs in a group of equations, which is described in that post and in More on Math Context Menus. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

The present post describes how these features are implemented in Microsoft Office using the mathematical paragraph, or “math para” for short, and mentions support for some additional properties supported by the underlying layout component (PTS) that aren’t yet implemented in Word or RichEdit, such as elegant equation numbering and customized vertical spacing. The post concludes with some observations about representing the math para in OMML, RTF and MathML. At some time I’ll post more about PTS, Page/Table Services, which is the intimate companion of LineServices, the Microsoft line layout component.

A math para is a group of one or more “equations” attached to a line in a text paragraph. The text paragraph is the ordinary paragraph discussed in the blog post Paragraphs and Paragraph Formatting (it may be helpful to read that post first). If a math para ends the text paragraph, the math para is terminated by the CR (inserted by typing Enter) that terminates the text paragraph. In all other cases, the math para ends with a VT (inserted by typing Shift+Enter) and is followed by a nonempty text line to which it is attached. If the math para contains more than one “equation”,  they are separated by VT’s, and each equation consists of one or more math lines. Here “equation” is quoted because the entity involved is actually a display math zone which might only be a mathematical expression instead of a whole equation. But display math zones usually are equations and hence the name. It’s handy also to refer to text ending with a VT as a “soft paragraph”, as distinguished from text ending with a CR, which is a “hard paragraph”. This terminology is explained further in Paragraphs and Paragraph Formatting.

Okay, what’s a display math zone? First note that a math zone is a text range within which math typography rules usually apply and outside of which math typography rules do not apply. The caveat “usually” appears because math zones can contain specially marked normal text runs for which math typography rules don’t apply. Such text is handy for making equations like rate = distance/time, in which text occurs that should be displayed in normal upright style rather that in the math italic style used for most mathematical variables.

Math zones can be inline or display, corresponding to TeX’s $ and $$ toggle keys, respectively. If a math zone fills an entire soft or hard paragraph, it is a display math zone, i.e., it is displayed on its own line(s). If a math zone is preceded and/or followed by nonmath text other than a CR or VT, the math zone is inline and is rendered in a more compact fashion. Inline math zones usually consist of math expressions or variables, whereas display math zones usually consist of equations or formulas. Inside Microsoft Office, math zones are identified internally by a character-format effect bit like bold. Hence if you delete the ordinary text separating two math zones, you get a single merged math zone. (With hindsight, less overall code would have been required if we had delimited the math zones with special characters, rather than using a character-format effect, but that’s another story).

Note that a text paragraph can contain more than one math para as is often the case in technical documents and books. 

In addition to the underlying plain-text structure of math paras described in the preceding section, there are math para properties representing equation alignment, manual breakpoints, and various horizontal and vertical parameters. The ways you can specify equation alignment and manual breaks are discussed in Breaking Equations into Multiple Lines and More on Math Context Menus. An alignment point is represented internally (and in OMML/RTF) by an operator character format property, not by a character of its own. The operator character so used for alignment can be any kind of operator and can be nested arbitrarily deeply inside a mathematical expression.

An equation break also occurs on an operator character and is represented by a character format property of that operator. But the operators that can be used for equation breaks are restricted in both type and context. First, equation breaks occur only on relational or binary operators. Second, context restricts the break possibilities further. For example, there’s no breaking inside a subscript or superscript object, unless the script or base being broken is bracketed. The reason for this restriction is for readability. The software could break a math expression most anywhere, but for readability, it’s important to know the scope of the expression being broken. Parentheses or brackets reveal such scope, as does the math zone itself if the operator isn’t contained within any math object, like a fraction or superscript object.

The manual break property also specifies to which operator on the first line of the broken equation the break should be aligned. As discussed in Breaking Equations into Multiple Lines, this choice can be made using the Tab key.

A math paragraph has its own alignment and indents, independent from the parent text paragraph. The blog post Default Document Math Properties includes discussion of the default math para alignment and various horizontal and vertical spacing parameters. The math para alignment can be one of: Center as a Group, Left, Right, Center. This kind of alignment is different from aligning a set of equations at various operators. It affects the whole math para as a block. In principle the alignment and positioning parameters could be specified on individual math paras as well, but Word 2007 only implements the math para alignment for individual math paras. The various positioning parameters are math para space before/after, inter/intra equation spacing, left/right indent, and wrap indent. Wrapped lines of an equation can either go to the wrapped indent or be aligned left/right/center. Word 2007 implements the indents on a document default basis, but doesn’t implement the vertical spacings.

Another important feature of the math para is optional equation numbers for one or more equations within the math para. The equation numbers are specified by soft paragraphs of their own and can be placed to the left or right of the equation with a variety of vertical alignment options. Hopefully someday Office will take advantage of this important functionality.

The OMML tag <oMathPara> contains a math para and similarly the RTF group {\*\moMathPara..} contains a math para, which can contain multiple equations consisting of display math zones with the various alignment and breaking options described above. MathML doesn’t have the concept of a math paragraph. It could be modeled using MathML’s <mtable> entity, but it’s simpler to represent it as a sequence of one or more <math display="block"> entities separated by soft paragraph marks and terminated by a soft or hard paragraph mark. These marks are part of the parent document format into which the MathML is embedded. The equation alignment and breaking properties can be represented in MathML 3.0 using the ID attribute. The math para properties can be specified in the parent document format.

Over and over the discussion of JSON vs XML (vs YAML…) appears: they are compared as languages to serialize object graphs. I may be old fashioned but I find there’s no valid reason for anything but XML.

Here’s a set claims in favor of JSON (or YAML it seems):

• JSON is more readable: I am sorry but I don’t find this true, being XML it’s much easier to know where parts start and end since end-tags are named. Most of the times the object graph is not sufficiently indented to recognize any structure hence readability only appears after you’ve tweaked a bit.

read more

What paragraphs are and how they are formatted are questions that continually come up both inside and outside of Microsoft. So this post describes Word/RichEdit paragraphs in general. A subsequent post will describe the “math paragraph”, which is part of a regular paragraph and is used for displayed equations, as distinguished from inline mathematical expressions.

The paragraph is a very important structure in written language. About six years ago, I developed the RichEdit binary format, which shipped with RichEdit 5.0 (Office 2003) as RichEdit’s preferred copy/paste format and was used by OneNote 2003 and 2007. In the design stage I talked with Eliyeser Kohen, of TrueType, OpenType, LineServices, and Page/Table Services fame. I was inclined to have four parallel streams: plain text, character formatting, paragraph formatting, and embedded objects, a format corresponding to the internal RichEdit representation. Eliyezer agreed such parallel streams were important, but insisted that they should be broken up into paragraphs. At the time, this seemed like extra overhead to me and I naturally didn’t want to slow things down. But I followed his advice and it’s right on! First, what’s a paragraph? Then what’s paragraph formatting? Then what’s a “soft” paragraph? And finally, what’s the final EOP?

 From a natural language point of view, a paragraph is one or (preferably) more closely related sentences that naturally belong together without becoming too long. From the Word/RichEdit point of view, a paragraph is a string of text in any combination of scripts and inline objects, including possible “soft” line breaks and “math paragraphs”, with uniform “paragraph formatting” up to and including a carriage return. The carriage return (CR) is given by the Unicode character U+000D, which you insert by typing the Enter key. In plain text on PC’s, the paragraph is usually terminated by a CRLF (U+000D U+000A) combination, but not ordinarily inside a Word document or RichEdit instance. Just the CR is used.

<rant> It’s quite convenient to use a single character. It takes up less space than the CRLF and it’s easier to parse/manipulate, since it’s an atomic entity. In fact, Unix already used a single character, the line feed (LF—U+000A), back in 1972, several  years before the PC operating systems were developed. Unfortunately, the PC with its DEC heritage preferred CRLF, a holdover from the old teletype days, and Word and the Mac shortened it to CR instead of LF. Windows NotePad still isn’t able to display Unix/Linux LF terminated paragraphs correctly after all these years (note that 2008 > 1972). I’m on a mission to fix that, but please don’t hold your breath! Anyhow I like CR better than LF, mostly because of habit. Clearly it would have been better to have a single standard. In this connection, it’s interesting to note that Word and RichEdit can handle CR, LF, and CRLF terminated paragraphs, even though they prefer CR. </ rant>

A key characteristic of a paragraph is its formatting, which is represented by a pretty large set of properties. Most of these properties are settable using a paragraph formatting dialog. In particular, there’s alignment (left, right, center, justify, along with a variety of East Asian options), space before/after, line spacing (single, double, multiple, at least, exactly), left/right margins and wrapped line indent, line/page breaks, tabs (oh, how I wish HTML had tab support!), and bullets/numbering. Internally, paragraphs and their formatting get overloaded with such entities as tables and drop caps, but let’s not get distracted. Using hot keys like Ctrl+E for centering or the paragraph formatting dialog, you can set the formatting for the paragraph(s) in which the current selection occurs. If you just have an insertion point (the blinking caret), only the paragraph containing the insertion point gets the new formatting.

When you create a numbered list, you may want to have an entry with one or more line breaks but no new number or bullet.  To insert a line break without ending the paragraph, type Shift+Enter, which inserts a Vertical Tab (VT—U+000B). Even though you get a line break, you don’t end the current paragraph, so no new line number appears. All the paragraph properties remain the same with the new line and the space-before property doesn’t apply to the new line, since the line is inside the paragraph. Sometimes it’s handy to refer to a sequence of lines terminated by such a line break as a “soft paragraph”. In HTML, these “soft line breaks” are represented by the <BR> tag, whereas “hard” paragraphs are identified by the <P> tag.

Thinking of numbered entities, you might want to change the character formatting of the number or bullet out in front. For example, you might want to use a larger font size or a different font. To do this, change the appropriate character formatting of the CR that ends the paragraph.

To provide a place to attach paragraph formatting for the last paragraph, every Word document and every RichEdit rich-text instance has a “final EOP” (end of paragraph), represented by a CR (CRLF in RichEdit 1.0). You cannot delete the final EOP, nor can you move the insertion point past it. In the Word and RichEdit object models, the ranges can select up through the final EOP, but they cannot collapse to an insertion point that follows the final EOP. The farthest they can go is up to just before the final EOP. Similarly messages like EM_EXSETSEL cannot make the RichEdit selection go beyond the final EOP.

RichEdit also supports plain-text controls, which are characterized by uniform paragraph formatting and don’t need, or have, a final EOP. An empty plain-text control is really empty, whereas a rich-text control always has at least one character, the final EOP.

Translation tools are many… but what good are they? To my surprise, there’s always some folks that find a tool that sounds cute but then it never helps. Let me try to identify the hard questions of translations’ management:

• workflow of updates (by developers) and management of translators’ contributions
• recognizing context when translating phrases
• managing translation duties for documents and phrases

The fancy conclusion? No tool I’ve met really helps any except the management of duties and generally they do so by making completely impossible the others.

read more

You know what?

A content-dictionary as can be found by tons on http://www.openmath.org/cd/ is mostly a social artifact. It’s a set of descriptions of symbols so that one can mean what others means.

read more

An earlier post describes math context menus (right click somewhere in a math zone) for changing the display characteristics of math objects, like fractions and integrals. For example context menus offer options to convert a stacked fraction into a linear fraction and vice versa. Another post describes math context menus for aligning and/or manually breaking equations on binary and relational operators.

In particular, the second post shows how one can align a sequence of equations separated from one another by soft paragraph marks (Shift+Enter, instead of Enter). For this approach, one chooses the “Align at this character” option for the operator to be used for alignment in each equation. This method is quite general in that binary, relational, and punctuation characters can be used as alignment operators, even when inside math objects.

A useful alternative context menu option not described in those posts allows one to align a set of equations with the single menu choice, “Align at =”. This is less general than marking the alignment operators explicitly, since in each equation the first relational operator that’s not inside a math object is used. To access the option, select two or more equations separated from one another by soft paragraph marks. Then right click anywhere on the selected equations and choose the “Align at =” option. Here “=” is the most common choice for aligning multiple equations. But the “=” just stands for the first relational operator, which could be, for example, “≥” instead of “=”. Note that two or more whole equations have to be selected for the “Align at =” option to be offered. If the last equation is only partly selected, the option won’t appear.

The math context menus also include the options “Professional”, “Linear”, and “Save as New Equation…” The “Professional” option converts any linear format text that is selected in the math zone into the corresponding built-up “professional” form. If no text is selected, the whole math zone is build up. Conversely, the “Linear” option converts built-up math objects to the “built-down” linear format. The “Save as New Equation” option saves the selected equation(s) in the Equation drop down list appearing at the left side of the math ribbon. This gives you an easy way to insert them from the math ribbon. Alternatively you can add a Math Autocorrect entry with the linear format for any math expression/equation you’d like to insert via typed entry. To see this last method in action, try typing \quadratic <space> <space> in a math zone. This inserts the solutions to the quadratic equation.

SWiM, the Semantic Wiki for Mathematical Knowledge Management, is now being used for the revision of the OpenMath 3 Content Dictionaries. The wiki at wiki.openmath.org contains the latest draft versions of these content dictionaries. Anybody can browse and discuss. The OpenMath 3 developers can also edit. This paper explains how the system works.

Detailed description of the ongoing case study

read more

A number of math display properties have document defaults. These are the ones used if you don’t explicitly override them, which you can usually do by invoking a math context-menu option. The properties all pertain to “displayed” math zones, that is, math zones that begin either at the start of the document or at a hard/shift Enter (CR/VT) and end at the following hard/shift Enter. The options determine math indents and things such as whether integral limits are positioned below and above the integral or as subscript and superscript. In Russia, it’s common to see the integral limits below and above the integral, while in the United States the limits are displayed as subscript and superscript.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

You can change the default settings to suit your tastes or a publisher’s conventions. In the math ribbon (type Alt+= to insert a math zone and then the math ribbon should appear), click on the Tools button over toward the left side of the ribbon. A dialog will be displayed that shows a variety of math display properties along with buttons to access the math autocorrect and recognized-function dialogs.

The document default math properties in this dialog are described in a somewhat technical way in the math section of the RTF specification. The properties belong to the RTF {\mmathPr…} group. They are also children of the <mathPr> OMML element. In this post, I describe the properties in a less technical way. For easy reference to the RTF specification, the relevant RTF control word is listed in parentheses. The dialog also has some options that are not document default math properties, such as “Copy MathML to the clipboard as plain text” instead of “Copy Linear Format to the clipboard as plain text.” Such options do not affect the layout of a document and hence are stored in the system registry rather than in the document.

Default font for math zones (\mmathFontN) Gives a drop-down list of math fonts that can be used as the default math font to be used in the document. Currently only Cambria Math has thorough math support, but others such as the STIX fonts are coming soon.

Reduce size of nested fractions in display equations (\msmallFracN) Specifies that nested fractions should be displayed such that the numerator and denominator are written in a script or scriptscript size instead of regular-text size. Specifically characters in the outermost fraction’s numerator and denominator are displayed using the full text size, characters in a nested fraction are displayed in the script size (about 70% as large as the text size), and fractions nested inside a nested fraction are displayed in scriptscript size (about 60% as large as the text size). TeX uses this “small fraction” choice by default, but Word 2007 does not, basically because in all the physics books I’ve read I don’t remember seeing reduced sizes used in display math. But if you prefer them, you can change them.

Break lines with binary and relational operators (\mbrkBinN) Document property specifying how binary operators are treated when they coincide with a line break. By default, the line break occurs before the binary operator. That is, the binary operator is the first control word on the wrapped line. But you can change it so that a line break occurs after the operator, or so that the operator is duplicated, that is, it appears at the end of the first line and at the start of the second.

Duplicate operators for subtraction as (\mbrkBinSubN) Document property specifying how the minus operator is treated when it coincides with a line break when break operators are duplicated. By default, the minus appears before and after the break, but you can choose a plus before the break and a minus after the break or vice versa.

Place integral limits to the side/centered above and below (\mintLimN) Document setting for default placement of integral limits when converting from linear format to professional (built-up) format in display mode (not inline). Limits can be either centered above and below the integral, or positioned just to the right of the operator. The default setting is to position to the right of the operator (subscript/superscript).

Place n-ary limits to the side/centered above and below (\mnaryLimN) Document setting for default placement of n-ary limits other than integrals when converted from linear format to Professional (built-up) format in display mode. Limits can be either centered above and below the n-ary operator, or positioned just to the right of the operator.  The default setting is above and below the operator.

Use the following settings for math on its own line (\mdispDefN) Document property to use the default math paragraph settings for equations, i.e., use values given by \mlMarginN, \mrMarginN, \mdefJcN, \mwrapIndentN, \mwrapRightN, etc. Default is to use the default math settings described below, but you can change it to use the text paragraph settings.

Left margin (\mlMarginN) Document property for the left margin for math. Math margins are added to the paragraph settings for margins.

Right margin (\mrMarginN) Right margin for math.

Justification (\mdefJcN) Document property for the default justification of displayed math zones. Individual equations can overrule the default setting. Displayed math zones can be left justified, right justified, centered, or centered as a group. When a displayed math zone is centered as a group, the equation(s) are ordinarily left aligned within a block, and the entire block is centered with respect to column margins. The user can use a context menu to align equations in more general ways, e.g., on the equal signs.

Indent wrapped lines by (\mwrapIndentN) Indent of wrapped line of an equation. The line or lines of a wrapped equation after the line break can either be indented by a specified amount from the left margin, or right-aligned. The default indent is 1”.

Right align wrapped lines (\mwrapRightN) If enabled, right justify wrapped lines of an equation. If disabled, the line or lines of a wrapped equation after the line break are indented by \mwrapIndentN from the left margin.

In addition to the properties above, the math RTF and OMML include four useful displacements for displayed math which unfortunately didn’t make it into Word 2007 (hopefully they will someday J). These properties are

Spacing before math paragraph (\mpreSpN).

Intraequation spacing between lines in an equation (\mintraSpN).

Spacing between equations within a display math paragraph (\minterSpN).

Spacing after math paragraph (\mpostSpN).

In addition two useful, but not yet implemented, document default math properties are 1) math style for differential d and related characters (U+2145..U+2149), and 2) which character to use for invisible times (U+2063) if a line break occurs at the invisible times. Ordinarily one would use the \times (U+00D7) for a visible times character, but a raised dot is another possibility. In the United States, the differential d is almost always displayed as a math italic d, but in Europe, an upright d is fairly standard. The latter choice emphasizes that the differential d is different from regular mathematical variables. Similarly the Naperian logarithm base e (U+2147) and the imaginary unit i (square root of -1, U+2148) are displayed as math italic in the United States and upright in Europe.

The Equations Options dialog also includes buttons to examine math autocorrect entries and recognized functions such as trigonometric functions.

MathML doesn't formalize document defaults for math, but MathML math zones can inherit them depending on the implementation. So such defaults are compatible with MathML and need to be expressed in a way outside of MathML.

It’s not really new that mathematical notation is made there to be abused so as to be most efficient for the current context. But I just met an extreme case:

In the OpenMath3 and MathML3-content efforts, we are polishing the description of symbols’ so that they can be common. Discussion about using linear syntax appears, of course, and an extreme case about the need for context was just posted by James Davenport:

read more

MathDox is a collection of software tools for interactive mathematical
documents on the web.

MathDox supports Mathematics in LaTeX, MathML and OpenMath and uses various
CAS as computational backengines.

MathDox is under development at the Discrete Algebra and Geometry group at the Eindhoven University of Technology.

A Windows installer for the MathDox software can be downloaded from http://www.mathdox.org

Linux users can find the necessary software at the download page of
http://www.mathdox.org