MathBus

[ Term Structure | Algebra | Geometry | Logic | Drawing ]
[ Language Bindings | C++ | Java | Lisp | ML ]


Mathbus Drawing Structure

Overview

There are more intuitive presentations for many mathematical expressions than the MathBus parenthesized syntax. The Java implementation of the MathBus substrate provides tools for displaying algebraic structures in a natural two dimensional fashion, similar to the output of formatting programs like TeX. The approach used is fairly general, and can be extended so that operators with which the Java code is not familiar with can also be displayed in a natural fashion. The JavaDoc documentation for the Java implementation can be found here.

The Java implementation displays these expressions in three steps. First, the MathBus mathematical expression is transformed into a linked structure of boxes and glue (flexible space) that represents the natural two dimensional relationship. The leaves of this structure are TextBox's that contain a string of characters. More complicated structures consist of vertical and horizontal lists of TextBox's, glue, and lists themselves. Second, in the noad sizing phase, the primitive TextBox's are sized according to the current font and scale factor currently being used. This information is then propagated through the horizontal and vertical lists, so the size and relative position of every box in the structure is known. Finally, the boxes are painted on the screen.

The result of the first step in the Java implementation is called a Noad structure and a version provided by the user can override that computed by the MathBus tools. The Noad structure is represented using the standard MathBus Node structure using a few standardized node types. This allows the user to overide the default formatting used for mathematical expressions. The purpose of this section is to document the Noad structure.

A Note on Measurements

To gain more precise control of the positioning and size of objects, especially when they are scaled, all measurements used in a Noad are represented using a unit called the SMU. An SMU is defined in terms of the width of the current, level zero font. The width of an em-dash in this font is 6*18 = 108 SMU. Thus a there are 6 SMU's to each TeX mu (mathematics unit). This scaled mu eliminates the need to use fractional values. It is fine enough for good, but not publication quality, formatting of mathematical expressions. Distances specified in SMU's are thus independent of the font and scale factor used to display the expression.

Noad Structures

There are six primary Noad primitives: TextBox, SpecialBox, RuleBox, GlueBox, HList and VList.. The display of most mathematical expressions can be represented using by combining these six primitives. The first three of these primitves describe bits of graphics: strings, stretchable characters and rules. The last two are used to combine the elements into horizontal and vertical lists (a la TeX). The remaining element, GlueBox's, are used to provide space between marking elements in the lists.

In addition, there are a few additional Noad labels that provide guidance while the noads are sized. For example, the width of a rule in a fraction cannot be specified before the fraction itself is sized. It is a bit greater than the maximum of the width of the numerator and denominator of the fraction. Fraction nodes are special vertical lists that know the rule in the fraction must be sized specially. Additional variants of vertical lists are provided to deal with super- and sub-scripts, both before and after the element they are modifying.

The first subterm of all Noads is a 32-bit integer that encodes the desired alignment of the Noad inside an enclosing list. Currently, all Noads are aligned along their baseline in horizontal lists, so this information is only used when the Noad is embedded in a vertical list. within vertical lists, Noads can be either centered, aligned agains the left edge of the list, or aligned against the right edge of the list.


TextBox alignment level font StringNode

Represents a string in a single font family, face, color and size. The string itself is encoded as a standard MathBus Node using the full Unicode character set. This Noad stores text and any other symbols that need to be rendered to the screen. The text is stored with a relative font size (1, 2, or 3) that indicates its size relative to other members. In addition, a string representation of the object that needs to be displayed is stored here. Along with the type of font to use (Plain or Italic) this can describe most objects.


SpecialBox alignment charIdentifier refOffset

This node is used to identify special glyphs, whose size is depends upon other Noads in a list. These special characters include stretchable parentheses, brackets and braces and integral signs. The refOffset field identifies the element in the surrounding list that controls the size of the special character. Precisely how the character is sized depends upon the nature of the character.


RuleBox alignment width height depth

A rule is rectangular black area that needs to be displayed. The three 32-bit integer parameters width, height, and depth specify the dimensions of the box in SMU's. However, they may be overridden if the rule is placed in a FractionBox.


GlueBox alignment width height depth

This Noad is the "whitespace" equivalent of the RuleBox.

List Noads

Noads of these types act as containers. There are several different types of list noads but they are all variants of two basic types: a horizontal list and vertical list. Both of these types of Noads consist of an arbitrary number of Noads, which are displayed one after another either horizontally or vertically.

There are two different NoadListBox types: Horizontal and Vertical. Since the structure for each is the same, they are differentiated by a boolean flag which is set upon instantiation.With the combination of both horizontal and vertical NoadListBoxes, it is possible to outline the format of many different structures.


HList alignment noad1 noad2 . . . noadn

Displays the sub-noads one after another, advancing the position to the right by the width of the previous noad. All of the noads are vertically aligned so that their base lines have the same vertical position.


VList alignment noad1 noad2 . . . noadn

Displays the sub-noads one after another, advancing the position downward by the sum of the height and depth of the previous noad. The alignment field of the sub-noads is used to determine how they horizontally aligned.


FractionList alignment leftPad ruleHeight rightPad numNoad glue1 rule glue2 denNoad

ment field of the sub-noads is used This noad is a vertical list, but is used to represent a fraction. The last five subterms of this noad describe the content of the fraction itself. The first four control the size and shape of the horizontal rule between the numerator and denominator. As usual, alignment is used to control the alignment of the noad when it is contained in lists. leftPad and rightPad indicate how far beyond the maximum width the numerator and denomintor the rule extends. ruleHeight indicates the thickness of the rule. The values of the entries in the rule noad are ignored and overridden by the FractionList logic. The glue fields can be omitted.


PreScriptList alignment superscript glue subscript

This type of vertical list is used to represent the superscripts and subscripts that preceed the character that is scripted. Superscript and subscript are arbitrary noads, but are most often HLists. The fields in the glue noad are overridden by the logic of this noad, which computes the size of the glue from the following noad.


PostScriptList alignment superscript glue subscript

This type of vertical list is used to represent the superscripts and subscripts that follow the character that is scripted. Superscript and subscript are arbitrary noads, but are most often HLists.The fields in the glue noad are overridden by the logic of this noad, which computes the size of the glue from the preceeding noad.


What follows is incorrect and needs to be revised.

The expressions x2 + 1 would be represented in MathBus prefix form by

(HList 0 (HList 0 (TextBox 0 0 "x")
                  (PostScriptList 0 (HList 0 (TextBox 2 1 "2")) (GlueBox 65536))) 
         (GlueBox 65536) (TextBox 0 1 "+") (GlueBox 65536) (TextBox 0 1 "1"))

Putting It Together

Here is how a sample expression using the Noad primitives would be represented:

Mathbus Node Representation: (Quotient (Application (AlgFuncCode 'Sine') (Plus (AlgVariable 'x') [2])) (Exponentiate (AlgVariable 'x') (AlgVariable 'x') ))

The actual representation (taken as a screenshot) is as follows:

The processing begins with the breakdown of the node tree structure. At the root is a quotient node. This sets up a "template" with a vertical NoadListBox having three sub-boxes: the numerator, rulebox, and denominator. The numerator and denominator are themselves processed as trees, yielding two horizontal boxes. Thus, each node can embedd a large number of subterms (limted by computational resources) whic can create large structures that can be easily represented.

It should be noted that we have a NoadListBox enclosing the text boxes 'x' '+' '2' in the numerator. This may seem to be redundant, but it actually facilitates the internal operations. By enclosing the entire expression in one large box, we are able to refer to the height and width of the expression that are the arguments for the sin function. Thus, the argument for the sin function can be a simple 'x' or a more complex expression such as 'x+2'. Both are handled equally by the graphics drawer since the operations are always performed on boxes.

As can be seen, a fairly complex expression can easily be represented with a combination of the four primitive box type. These structures can be embedded inside one another to create increasingly large objects. The embedding of NoadListBoxes affords a large degree of flexibility in page layout.