embedded equation component manifesto (long)

[Paul Topping <PaulT mathtype com>]

Hi,

So, IMHO, here are the features needed for a container/embedded object
system to support equation editing well. BTW, none of these things is really
specific to math but, instead, revolve around the embedded object being
perceived by the user as containing text that is really part of the
document. I have put these items somewhat in order of importance because, as
it is sort of a wish list and it looks like Gnome already has specified a
container-to-embedded object interface, I only expect some, if any, of these
items to actually get implemented.

Before I get into my list, I'd like to set the record straight with respect
to my company's relationship to Microsoft. I am the president of the company
so this IS Design Science's official opinion ;-). Microsoft Word is a
powerful program incorporating many features but it doesn't do a great job
on technical documents. Many, but not all, of its failings in this area are
mentioned in my list below. I'd love for Microsoft to fix some of these
things (and have begged them to do so) and if Gnome can do a better job, it
might eventually force them to do it.

Although MS Word can definitely be improved upon, it won't be done using the
Gnome interfaces that I've seen so far. There seems to be a tendency among
the "open software" community to dismiss Microsoft apps and operating
systems as "brain dead". This is terribly naive. They have a lot of really
sharp people working for them and, while there goals don't always match
those of users and customers and their software is by no means perfect,
there is a lot of really powerful stuff there.

I intend the above to be taken as a challenge to do better than Microsoft
and to also say that it won't be easy. It won't be enough to simply be an
enlightened open source programmer that hasn't yet sold his/her soul to the
devil.

Paul

----------------------------------------------------------------
Paul Topping                          http://www.mathtype.com
Design Science, Inc.                  email: pault@mathtype.com
                                      phone: 562-433-0685
----------------------------------------------------------------

Finally, the list:

1. Baseline Alignment

Many equations must flow with the text in which they occur. A simple
expression like the square root of ax + b, where the root is expressed using
the usual radical sign, requires the formatting capability of an equation
editor (i.e. it can't just be typed in the word processor), but it is too
small to place in its own paragraph. In the lingo, the two kinds of equation
are "inline" and "display".

Inline equations have a natural baseline, the baseline of "ax + b" in the
above example. If the embedded object's boundary is a rectangle, the
location of the baseline can be expressed as a distance from the bottom edge
to the baseline. This information should be passed to the container along
with the bounding rectangle (and the side bearings, see below.). See
http://www.mathtype.com/support/tech/misc/baseline.gif for a pretty picture.

The container must position the embedded object vertically to align the
baseline of the equation with that of the surrounding text.

Although baseline alignment is normally thought of in the context of inline
equations, it actually applies to display equations as well as an equation
number is usually placed at the right margin on the equation's baseline.

2. Side Bearings

In general, an inline equation (or an inline anything, for that matter)
should have a similar relationship with the surrounding text as does an
individual character glyph. A character glyph has a baseline, an origin on
that baseline, an advance width, and a rectangle surrounding the glyph image
(non-left-to-right writing systems are ignored here). See
http://www.mathtype.com/support/tech/misc/glyph.gif for another pretty
picture.

Although an inline equation may contain many glyphs, for formatting
consideration, it can be treated as a single glyph. In particular, its side
bearings must be considered during line layout. To give an example of the
kind of problem that can occur if side bearings are ignored, imagine an
inline equation that ends on the right with an italic "f" (like the one in
the image linked in the preceding paragraph), followed by a comma in the
document. This is a very common case in technical docs. If line layout
ignores side bearings and just uses the equation's image rectangle, there
will be extra space between the "f" and the comma.

MS Word does not respect side bearings. Those users with any typographic
sophistication at all learn to ignore these glitches. It is my hope that a
Gnome word processor (and any other for that matter) could do better.

3. "Auto" Line Spacing

This item doesn't really have anything to do with the interfaces, but has
been a problem with several word processors. Word processors often try to do
some kind of automatic line spacing where, if something "unusual" is
embedded in a line (an equation object or a stretch of text in a different
font), they will change from the normal line spacing to allow extra space
between lines. This sounds ok, but in practice they are ultra-conservative
in performing this adjustment. With inline equations, the preferred behavior
is for the word processor to detect that a too-tall equation overlaps the
text in an adjacent line and let the user decide either to reformat the
equation to be less tall (by changing a fraction from one with a horizontal
bar to a diagonal one, for instance) or to make it into a display equation.
No way does the user want the line spacing changed in a paragraph for a
single line --- this is just bad formatting. This is a big problem in MS
Word.

4. Ambient Font, Size, and Style

Although equations use math fonts that may not be used elsewhere in the
containing document, they also contain characters whose font and size must
track that of the document. If the document's body text is in 10-point
Times, the equation's variables will be also. Subscript and superscript
sizes will be specified as percentages of the body text size. Functions,
like "sin" and "cos" will be in Times plain, whereas variables, like "x" and
"y", should be in 10-point Times italic.

So, it is important that the embedded object have access to the "ambient"
style information. This can be done by having the container pass this
information into the embedded object but a better way is to pass it a
pointer to a "embedded document object site" interface that allows the
embedded object access to all kinds of document information.

5. Cross-Page and Column Embedded Objects

It is quite common to have a block containing several equations stacked
vertically. It is desirable to handle this as a single object so that
equation-specific alignments (e.g. by equal signs) can be maintained. It is
often desirable to handle page and column breaks within the object.

Very long equations are often broken into a stack of expressions, but in a
math-specific way where a plus or minus sign at the line-break point will be
duplicated at the right end of the upper line and the left end of the lower
line.

Both of these require quite complicated size negotiation between the
container and the embedded equation object.

6. Spell-checking, Search & Replace, Global Font and Size Changes

Because equation objects are a special kind of text, users expect them to
participate in document editing operations such as spell-checking, search &
replace, and font and size changes. For example, if someone selects a
paragraph in a word processor and changes its font from Times to Helvetica,
the equation would most likely change its "primary font" accordingly. Its
functions (e.g. sin, cos) would change from Times, plain to Helvetica, plain
and its variables would change from Times, italic to Helvetica, italic.
Greek letters, mathematical operators would remain unchanged.

7. Cross-Equation Alignment

Although most alignments are intra-equation (except for baseline alignment,
of course), it is often desirable to align things between equations. For
example, it is quite common to have two display equations with an
intervening paragraph or two. Professional quality typesetters want such
equations to align at their equal signs (or other relational operator). This
is particular example of what I describe in general in the next section.

8. Many Equations per Document

Due to the nature of math, it is common for a document to have many
equations per document. When programmers think of embedded objects in a
document, I think the example that comes to their minds is that of embedding
a spreadsheet or two. This mindset causes several potential problems:

a. Performance. If all the objects on a page are "active" in some way and
this is not expected by the implementors of the object system and/or the
word processor, this may cause severe memory and speed issues.

b. Document-wide preferences for the embedded object. Because there can be
so many equations in a document, it is necessary that there be some sort of
document-wide context for preferences. It would be quite tedious if the user
had to specify which fonts and point sizes are to be used for each and every
equation individually.

The solution that our Equation Editor uses is to make these choices global.
This helps but creates a problem when the user wants one set of font & size
choices for one set of documents (say for submission to a particular
journal) and another for for documents for use within the company or
university. MathType's solution to this is to allow the user to associate a
preference file with a document or a document template. This helps but it is
a problem if the user sends the document to a colleague but doesn't include
the preference file.

The solution that is needed here is to allow each embedded object editor to
store a "bag" of preferences in the document and to have interfaces
available to access them. The word processor simply carries this around as
baggage data, perhaps in XML form.

9. Accessibility Issues

Because of equation object's dual nature as both text and graphics, dealing
with accessibility by the visually impaired can be problematic. Some such
users choose a user interface color scheme that allows them to type white
text on a black background. This is allowed by modern word processors.
However, when we print such a document, the word processor must be smart
enough to print the text using black, not white. This is also supported by
modern word processors. However, if the embedded object is treated solely as
a picture, this can be hard to pull of for reasons I hope are obvious.

I believe the solution to this problem is to allow the equation "picture" (a
vector graphic, not a bitmap) to draw and display text in a virtual "current
text" color. In the "white text" scenario, the current text color is white
when the equation is rendered to the screen but black when printed. This
virtual color idea can also be described as late binding in graphics
metafiles. Such a facility may have many other uses.

10. Generating HTML/XML

In today's web-centric world, it is likely that many word processing
documents will eventual be targeted for delivery as a web page. I believe
that Gnome's philosophy is that the word processor's native document format
be XML and, therefore, it might be directly displayable in a web browser
with an appropriate style sheet. However, MathML and other specialized
XML-based languages that might be the archival format used by embedded
object are not currently understood by browsers. Current CSS and XSL styles
are not powerful enough to format math, so this will have to be handled by
various browser plug-in mechanisms. (Yes, I know that Mozilla handles MathML
directly but it doesn't handle ChemML and name_your_favorite_ML, so the
browser plug-in facilities are still required.)

It is important that the embedded object be able to support interfaces that
allow it to participate in the HTML/XML generation process, both for
archiving the container document and for conversion to web document form.

11. Math Fonts and Unicode

This issue is a bit tangential to the implementation of embedded objects,
but it seems to be a common misconception so I thought I'd throw it in.

As you might imagine, math often involves symbolic fonts. A common
misconception is that Unicode contains all the characters needed by math
and, therefore, all software that claims Unicode compatibility will
automatically support math characters. Whereas Unicode does contain some
math characters, it is not even close to enough. Although one day Unicode
probably will contain enough math characters, the submission that proposes
them has not yet been accepted by the Unicode Consortium and, even if it is
accepted, it will be many years before browsers deal with them. It may be a
surprise to some that current browsers do not even handle Unicode 1.0's math
characters and this standard was published 10 years ago!

It would be more realistic for browsers to allow access to fonts as an array
of glyphs without Unicode assignments for all characters. It is impractical
for all uses of a new character to wait until someone submits it to the
Unicode Consortium, they approve it, and all the browsers support it.