MathFlow SDK reference

Localization overview

MathFlow supports the localization of labels, menus, and messages for different languages. It does so via the standard Java mechanism of PropertyBundle files. This consists of defining the translations needed for each string in a file located in the webeq3.resources package of the MathFlow jars. This file name should be derived, following the Java bundle requirements, from the base name of messages.properties. That is, it should be named as follows:

messages_xx.properties

(where xx is the Java code for the desired locale)

For instance, use messages_de.properties for German localization, messages_es.properties for Spanish, messages_fr.properties for French, etc. Once placed in the appropriate location, the messages.properties file will be used when the Java location matches the code in the file name.

messages_xx.properties file

The messages_xx.properties file has the syntax of Java property files. Lines should be shown as follows (except for lines starting with #, which are comments):

key=value

The best way to produce your own localization is to make a copy of the default messages.properties file and translate the value strings, without changing the keys (which are defined by MathFlow and must remain unchanged to work.) Strings that are not translated default to English. In MathFlow's files, the English string is the key, with special characters (=, :, spaces, \) escaped and preceded by the Java package where it is used. For example:

com.dessci.mathflow.sdk.composer.options\ include\:=options include:

(where the string is "options include:", used in the com.dessci.mathflow.sdk.composer package)

Some values have {0} or {0} and {1} in them. These are replaced by MathFlow with words that should not be translated and need to be placed (as {0}, {1}) within your translated string in the appropriate location. For example, the entry

webeq3.editor.Could\ not\ create\ directory\ {0}\:=Could not create directory {0}:

translated into Spanish would appear in a localized file as

webeq3.editor.Could\ not\ create\ directory\ {0}\:=El directorio {0} no se ha podido crear:

Setting the locale

Normally the JVM sets the locale to a default. If you want to use a specific locale, you can do it by calling the following from within your code:

webeq3.resources.Messages.setLocale(Locale new_locale)

Obtaining files

If you would like to localize some or all of MathFlow's strings, you must contact MathFlow Support to obtain a modifiable copy of messages.properties. Once modified, you need to send the file back to MathFlow Support in order to obtain a new, properly-signed jar file with your translated messages in place.

Synth support enhancements

  • Okay/Cancel buttons have been assigned unique names: "mfOKButton" and "mfCancelButton"
  • Okay/Cancel buttons can include an image if a resource with a given name is present on the classpath.
    • "mfOKButton.{png,gif,jpg}"
    • "mfCancelButton.{png,gif,jpg}"

Localization enhancement

ConfigToolbar cues have been extended to allow the use of a Message ID for localization purposes. For example, cue="keyStr" calls Messages.getString(keyStr), which goes in the properties as webeq3.editor.keyStr.

  • MenuConfig objects (SimpleConfigurationInfo, StyleConfigurationInfo, StructureConfigurationInfo) have been extended to reflect the entire menu tree so that any menu item can be disabled or removed.
    • Introduce MenuConfigInfo with the following:
      • boolean getMenuEntryIncluded(itemID)
      • boolean setMenuEntryIncluded(itemID, true|false)
  • To get an instance of MenuConfigInfo, call getDefaultMenuConfigInfo() from top-level editor components.

API Enhancements

  • A method has been introduced to set the default status line: setDefaultStatus(String msg).
  • A method has been introduced to set the default equation background/foreground color to complement font and size: setDefaultEquationStyle(String fontname, int size, String fgcolor, String bgcolor).

Config Toolbar Enhancement

  • Now allows an imagesrc attribute on the btn element.
  • When present, the image indicated will be used for the button face, regardless of the element's content. The action for the button is identical to what it would be without the attribute.
  • The image is rendered, scaled and centered, as is presently the case with image buttons.
  • The value is a path relative to the CLASSPATH. In particular, a fully qualified URL will fetch it.

Overview of font style management

MathFlow allows users to style characters and expressions by requesting particular font faces, weights and slants. While users can specify any font, weight or slant in the underlying MathML markup, what MathFlow actually renders is limited by the availability of fonts on the system. MathFlow uses two rendering engines, a Java-based engine for the Editor, and a Win32-based engine for preview images and PDF composition. The font and style behavior of both engines is similar, but there are some differences in details as described below.

There are three cases that must be distinguished to understand how MathFlow selects fonts:

Default rendering

When no explicit style information is specified, the MathFlow rendering engines apply internal algorithms to select fonts. The Java engine firsts attempts to locate characters in a set of preferred system fonts: Times New Roman for alphanumeric characters, Euclid Symbol for common symbol characters, and Code 2000 for rarer symbol characters. Note that Euclid Symbol is included with MathFlow, but Code 2000 must be obtained separately. The choice of preferred system fonts is configurable. See Configuring preferred fonts.

When characters cannot be located in MathFlow's preferred system fonts, the Java engine also contains built-in fonts containing around 500 symbol characters and will use these fonts instead. Characters that cannot be located either in preferred system fonts or internal fonts render as missing glyphs, generally represented by an empty box. In these cases, explicitly specifying a system font known to contain the character is generally the best solution.

The Win32 rendering engine employs a similar, but more complex model. Characters are first sought in a collection of preferred system fonts, primarily Times New Roman, Symbol and MT Extra. For certain classes of characters, Mathematica fonts, Euclid fonts, and/or Adobe's Mathematical Pi fonts may also be utilized. When characters cannot be located in preferred fonts, the rendering engine searches all available system fonts. At this point, there is no control over the order in which fonts are searched, which can lead to unpredictable results. As in the Java case, explicitly specifying a system font known to contain the character is generally the best solution.

Pre-defined MathML styles

MathML contains twelve pre-defined logical styles, such as "sans-serif" and "script." When one of these styles is selected, both the Java and Win32 engines reformulate these requests in terms of specific fonts. As above, the renderers first look for characters in preferred fonts, and then fall back to either internal fonts or other system fonts, depending on the rendering engine.

User-defined Custom Styles

For user-defined custom styles, both engines will attempt to literally honor the request. If the specified font is not available, an attempt is made to render the character in some font containing the character. If no font can be found, the character is rendered with a missing glyph indicator.

Styles in MathML markup

MathFlow enables the use of user-defined custom styles definitions as described in "Manage Custom Font Styles" in the Structure Editor documentation. Custom styles are represented in the MathML markup by attributes specifying style names. Here we give more details about how the association between the style name and the actual font being used is managed.

All character data in a MathML expression must be contained in a token element (MI, MO, MN, MTEXT, etc.) The font used to render the character data is determined by the values of the "mathvariant", "class", "fontfamily", "fontweight" and "fontslant" attributes. The last three attributes are deprecated by MathML 3.0 and are not generated by MathFlow (though they are still honored by the MathFlow rendering engine.) The values for any of these attributes may either be set explicitly on token elements, or inherited from a parent element, usually an MSTYLE element.

When several of these attributes are used, MathFlow uses the following precedences in determining which of them controls the font:

  1. Explicit "mathvariant" values
  2. Inherited "mathvariant" values
  3. Explicit "class" values
  4. Inherited "class" values
  5. Explicit "fontfamily" "fontweight" and "fontslant" values
  6. Inherited "fontfamily" "fontweight" and "fontslant" values

Both the "mathvariant" and "class" values are interpreted as specifying all three components of the fonts specification -- family, weight and slant. Thus, the "mathvariant" value "bold" actually specifies a serif font face, in bold weight, with normal (upright) slant.

To illustrate the above precedence rules, consider and example. If we define the style "myArial" to have family="Arial", weight="normal" and slant="automatic", then the following will display the x in an Arial, normal, upright font, and the y in serif, bold, upright (since mathvariant="bold" takes precedence over fontstyle="italic"):

‹math›
  <mstyle mathvariant="bold" fontstyle="italic">
    <mi class="myArial">x</mi><mo>+</mo><mi>y</mi>
  </mstyle>
‹/math›

Whereas this will display the x in a serif, bold, upright font, and the y in Arial, normal, italic:

‹math›
  <mstyle class="myArial" fontstyle="italic">
    <mi mathvariant="bold" >x</mi><mo>+</mo><mi>y</mi>
  </mstyle>
‹/math›

Custom font styles

MathFlow stores the custom font styles you have defined in a file, so that it can be reused from session to session. This file can also be edited directly as a more convenient way of defining a large number of styles, to be shared among many users.

The file in question is named .mfstyles and is stored in the same directory as your MathFlow preferences file, usually the following:

C:\Documents and Settings\<username> (Windows) or your user home directory (Unix).

Font style language

The font style definition file has an XML syntax with seven elements:

<styles>

The root element that can contain any number of <style> elements.

<style>

Each <style> element must contain one <label> element and one <fontspec> element. It is an error if either of these is missing or appears more than once.

<label>

The name of the style.

If the inner text of this element matches the value of the class attribute in a MathML element, then that MathML element will be stylized according to the <fontspec> element that is a sibling of this <label>.

<fontspec>

This can contain 0-3 of the following three elements which describe the font characteristics of the style. If any of these elements are omitted, the corresponding font characteristic adopts a default value listed below.

  • <fontfamily> - Accepted values are any legal font family name, or "inherited". Default is "inherited".
  • <fontweight> - Accepted values are "normal", "bold" or "automatic". Default is "automatic".
  • <fontslant> - Accepted values are normal, italic or automatic. Default is "automatic".

For example, the following code defines two font styles named my Arial, myArial2, and myEmphasis:

<styles>
 <style>
  <label>myArial</label>
  <fontspec>
   <fontfamily>Arial</fontfamily>
    <fontweight>normal</fontweight>
    <fontslant>automatic</fontslant>
  </fontspec>
 </style>
 <style>
  <label>myArial2</label>
  <fontspec>
   <fontfamily>Arial</fontfamily>
    <fontweight>bold</fontweight>
   <fontslant>normal</fontslant>
  </fontspec>
 </style>
 <style>
  <label>myEmphasis</label>
  <fontspec>
   <fontfamily>inherited</fontfamily>
    <fontweight>bold</fontweight>
   <fontslant>italic</fontslant>
  </fontspec>
 </style>
</styles>

Java rendering engine

The MathFlow Java rendering engine first attempts to render characters using a collection of four preferred system fonts. The specific system fonts to be used may be identified through the use of a configuration file as described below. Internally, MathFlow considers all characters as belonging in one of the following four broad classes:

  • ALPHA_NUMERIC
  • GREEK
  • SYMBOL
  • EXTRA SYMBOL

The SYMBOL class corresponds to characters found in the standard Adobe Symbol encoding. EXTRA SYMBOL is a catch-all for everything else. MathFlow associates the following numerical values with the following four classes of characters:

ALPHA_NUMERIC = 100
SYMBOL = 101
EXTRA_SYMBOL = 102
GREEK = 103

The default font associations are as follows:

100=Times New Roman
101=Euclid Symbol
102=Code2000
103=Euclid Symbol

To modify the font associations used by MathFlow Editor, create a file named "FontMapping.opt" and place it in this folder:

Windows: C:\Users\<username>
Mac: your user home directory
Unix: your user home directory

Write four lines in the file, one for each character class of the form NNN=<font name>, as shown above. Once you restart MathFlow, these fonts will become the preferred system fonts for character display.

Example

In this example, you need all alphanumeric characters to use the system font "Arial." To do this, you will need to change the ALPHA_NUMERIC value (ID is 100 in the FontMapping.opt file) to Arial, rather than Times New Roman as shown above. To accomplish this, use the following FontMapping.opt file:

100=Arial
101=Euclid Symbol
102=Code2000
103=Euclid Symbol

This mapping will cause every character MathFlow identifies as an alphanumeric character to be displayed in the specified font. Be aware if you use the wrong font name in FontMapping.opt, you will not see the correct font. It will use MathFlow's internal font if it can't find the system font listed in the file. It is possible to pick any system font, but be aware most system fonts do not contain glyphs for non-alphanumeric characters. Euclid Symbol is a high-quality font for common symbol characters, and you will generally not need to change it. However, Code 2000 is a lower-quality, shareware font whose main appeal is exceptionally comprehensive coverage of Unicode, and depending on what symbols you need, you may wish to replace it with a higher quality font. The "GREEK" font defaults to Euclid symbol since it has high-quality Greek characters, but high-quality fonts with Greek characters in other styles are not uncommon. In general, you may need to experiment to make sure the system fonts you pick contain the proper glyph for the Unicode characters you plan to use.

Windows font configuration

Overview of Windows font configuration

The EquationComposer component produces Encapsulated PostScript (EPS) graphics files for each mathematics expression. The use of EPS is often key to producing high-quality output, since it is a vector graphics format that scales nicely to the very high resolutions required for print output. However, a negative of the EPS format is it is an older graphics format designed for use primarily with PostScript fonts. While EPS technology has improved to allow the use of TrueType and more recently OpenType fonts, not all TrueType and OpenType fonts can be used natively within EPS files.

Both the TrueType and OpenType standards provide a number of alternative ways for accessing the characters within fonts and optional mechanisms for discovering what characters a font contains. Thus, there is a wide variation between "TrueType" fonts as to what information is available from the font itself, and how low-level software must access the characters within that font. In particular, only certain types of OpenType and TrueType fonts contain the necessary information in the appropriate format for direct use within EPS files.

Even with PostScript fonts, problems can arise within EPS files. In general, PostScript fonts do not contain enough information within them for external software to automatically, definitively determine what characters are contained within the font. This is a particular problem with mathematical symbols since they are much less standard than alphabetic characters.

Some, though not all, problems with fonts in EPS can be addressed via a complex technique known as "dynamic font subsetting". This technique involves dynamically generating PostScript fonts containing the characters actually appearing in an EPS file from the regular fonts installed on the system, and embedding them within the EPS file. While the EquationComposer component does not yet have this capability, Design Science is working toward this goal for future versions.

Consequently, font management is a significant issue. Care must be taken to ensure the EquationComposer component is configured in such a way characters are taken only from EPS compatible fonts, and the EquationComposer component has access to accurate information about what characters are available to it within EPS compatible fonts. The EquationComposer component uses two font configuration facilities to achieve these goals:

  • A mechanism for configuring the exact list of fonts which the EquationComposer component is allowed to use, in order of preference, and
  • A mechanism for extending the EquationComposer component's knowledge of what characters are available in particular fonts.

Font configuration

Configuration file

To configure the list of fonts Equation Composer/Document Composer is allowed to use, create a font configuration file with file name "FontConfig.txt". Use -fontconfig as a parameter of the Equation or Document Composer method to specify the name and the path to the FontConfig file. Example:

"EquationComposer32" -license "dessci.lic" -mathmlfile "test.mml" -imagename "test" -imagetype "png" –fontconfig "X:/abc/xyz/FontConfig.txt"

If this file is not present when Equation Composer/Document Composer is initialized, Equation Composer/Document Composer will consider all TrueType, OpenType and PostScript fonts installed on the system as eligible for use within EPS files. We don't recommend this, except for compatibility with older versions of MathFlow. See Font Style Management Overview for more information.

The font configuration file should contain a list of font face names, one per line. The '#' character can be used to include comments. Any text on a line following a '#' character will be ignored.

The following example illustrates the format of the font configuration file:

# A sample FontConfig file
#
Times New Roman
Euclid Symbol
MT Extra
Mathematica7

Important: the font face name given in the font configuration file must exactly match the font face name as defined in the font. To determine the font face name under Windows, locate the font in the Fonts control panel and double click it to open the font preview panel. The font face name will be given on the first line. It does not include the parenthesized font technology label which is sometimes present. For example, the title bar of the font preview panel for the Mathematica7 Regular font reads "Mathematica7 (TrueType)" and the font face name is Mathematica7.

See also:

Required entries

Equation Composer/Document Composer requires access to three special fonts to function properly:

  • a main font,
  • a symbol font, and
  • an "extra" font

The main font must contain the ISO Latin 1 alphabetic characters, and is the default font for Latin 1 variables and numbers when no explicit style is given in the MathML markup for an expression. Currently, Equation Composer/Document Composer requires Times New Roman to be available as a default choice of main font, and thus Times New Roman must always be listed in any font configuration file.

The symbol font should be a font with the Adobe symbol encoding, and glyphs for most characters in the encoding. There are two main choices, the standard Adobe Symbol font and the Euclid Symbol font that is installed with MathFlow. Either can be used, but one must be listed in font configuration files. If both are listed, Equation Composer/Document Composer will designate the first one encountered in the listed fonts as the symbol font, and treat the other one as an optional entry.

The 'extra' font is used for pieces of brackets, braces, parentheses, and so on, that are assembled from pieces when required in large sizes. Because the notion of an "extra" font is particular to our products, there are again only two choices, MT Extra and Euclid Extra. Either font is acceptable, but one must be listed in all font configuration files. As with the symbol font, if both fonts are listed, the first one encountered will be designated as the 'extra' font, and the other will be treated as an optional entry.

Optional entries

Apart from the required font entries, the font configuration file may list any number of additional fonts. When Equation Composer/Document Composer encounters a character without a style indicating an explicit font face, it will first try to locate the character in one of the required fonts. Failing that, it will proceed through the list of optional font entries in the order in which they occur, trying to locate a font containing the character. The first font that contains the character will be used. If no font is located containing the character, Equation Composer/Document Composer will render a red question mark in place of the character.

When Equation Composer/Document Composer requires a character that is explicitly styled with a particular font face, it will consult the listed fonts, and if that font face is present, it will check if the font contains the character, and if it does, it will be used. Otherwise, the font face request will be ignored and the procedure used for unstyled characters will be employed, as described in the preceding paragraph.

Good and bad fonts

Equation Composer/Document Composer contains a built-in database of characters useful for math typesetting and fonts that contain them. The fonts and font families are in the database and are known to work well in EPS:

Euclid fonts
Mathematical Pi fonts
Mathematica fonts
Math fonts
Lucida New Math fonts
Lucida Bright Math fonts
Lucida Sans Unicode
WP Math fonts
cm (TeX) fonts
msam and msbm (AMS fonts)
Fences

In addition, all PostScript Type 1 fonts and most OpenType versions of PostScript fonts can be used. For these fonts, however, you may need to provide Equation Composer/Document Composer with detailed information about the encoding and characters available in these fonts in a FontInfo.ini file. See The FontInfo.ini File for more information.

By contrast, TrueType fonts of the variety known as CID fonts will not work with the current version of Equation Composer/Document Composer. These include most large fonts for Asian languages. The most significant example of a CID font that cannot be used is the shareware Code2000 font.

In general, the easiest way to determine whether a TrueType font is compatible with Equation Composer/Document Composer is to simply conduct an experiment. List it in your font configuration file, create an equation with a custom style explicitly setting it as the font, and try it. If it works for any characters, the font is compatible. If Equation Composer/Document Composer doesn't seem to be able to find characters that are known to be present in the font, but it can find some characters, use a FontInfo.ini file to provide detailed information about the encoding and characters available. See The FontInfo.ini file for more information.

This information is on a separate page.

Overview, toolbar configuration language

The MathFlow Editor has a configurable toolbar. A toolbar configuration is described by a toolbar definition string stored in a file, which you reference from the MathFlow Editor's Manage Custom Toolbar dialog. If you'd like to refer to a complete example, you can download the full standard toolbar that ships with MathFlow here. This toolbar has expanded palettes for minor modifications.

If you create a custom toolbar, use the examples and procedures shown in this section. Save the toolbar as an XML file, making note of its location so you can properly reference it in the Manage Custom Palettes Toolbar (or Manage Custom Tabbed Toolbar) dialog:

manage custom palettes toolbar dialog

The toolbar definition string lists what templates, symbols and pull-down palettes should appear on the toolbar, and in what order and sizes. Definitions are written in the MathFlow toolbar definition language, a simple XML vocabulary described on the next page.

A toolbar consists of five kinds of things. First, the toolbar can contain template insertion buttons. These buttons cause an editing template to be inserted at the current cursor location when the button is clicked.

adding a template to a custom palettes toolbar

The toolbar also usually contains some symbol insertion buttons. These buttons can be used to insert any MathML character MathFlow recognizes, including letters and numbers, and symbol characters.

adding symbols to a custom toolbar

A third category of predefined buttons is the toolbox icons category, which includes cut, copy, paste, and magnify for common editing functions. This category is seldom used, since the Mini Toolbar contains these icons.

adding buttons for cut, copy, paste, etc.

The fourth type of toolbar object is the pull-down palette that groups together other symbols and templates. Palettes can be nested within palettes, and palettes, individual symbols and templates can be mixed together on the main toolbar.

adding a complete palette to a custom toolbar

To help visually group together related items on the toolbar, you can insert vertical dividers.

adding separators for readability

The discussion above related to the Palettes Toolbar. A final category of toolbar items relates to a second custom toolbar available — the Tabbed Toolbar.

manage custom tabbed toolbar

The order of the tabs is determined by the order of the tab elements in the toolbar configuration file. The names of the tabs are specified in a name attribute to the tab element.

custom tabbed toolbar

We've placed detailed information about MathFlow's toolbar configuration language on a separate page. Please see that page for details about

  • Language constructs
  • Palettes and templates
  • Advanced toolbar configuration
  • An extended example

Overview, characters

Numeric codes are used by MathFlow when interfacing with other applications, as generally the most robust, interoperable method of representing characters across systems.

MathFlow input accepts any valid Unicode character, but can only display characters located in an available font. The MathFlow Editor flow utilizes two kinds of fonts:

  • System fonts
  • Internal fonts

MathFlow includes internal fonts for approximately 500 math characters. The advantage of using these fonts is that they enable MathFlow to use the most common mathematical symbols, regardless of the fonts available on the system. However, they are low quality and only come in one face, slant and weight; thus, styles are ignored when rendering characters from these fonts.

The sections on the next page document the characters MathFlow Editor has in its internal fonts and the character names MathFlow accepts.

MathFlow named characters

While MathFlow supports all Unicode characters subject to availability of fonts, certain Unicode characters are more relevant to mathematics than others. The MathML Recommendation identifies approximately 2000 such characters in sufficiently common usage to have received names. MathFlow recognizes over 1000 of these names, with support for several hundred additional names specific to MathFlow. To insert a character by name in the MathFlow Editor, you can use the Insert Symbol dialog. For advice about finding fonts containing a specific character, see Font style management.

In addition to named characters, one can insert arbitrary Unicode characters directly by Unicode value using the Insert Symbol dialog or by editing MathML source code. For convenience, tables for most mathematical blocks Unicode characters are included at the end of this section. These tables are merely an aid to looking up character codes and names for obscure characters that you might need to enter. There is no guarantee that MathFlow will be able to locate such characters in an available font.

We've placed detailed information about characters on a separate page. The tables on that page list all named MathFlow characters.

Equation image

MethodDescription
Image getEquationImage(int pointsize, int dpi, String foreground, String background, String halignment, String valignment, int border, int breakwidth, int width, int height) Returns an AWT Image of the current equation rendered with the specified properties.
int getPreferredAscentAt(String ptsize) Returns the preferred ascent above the baseline of the current equation in pixels at the specified point size.
int getPreferredHeightAt(String ptsize) Returns the preferred height of the current equation in pixels at the specified point size.
int getPreferredWidthAt(String ptsize) Returns the preferred width of the current equation in pixels at the specified point size.

Linebreaking and indentation

MathML 3 introduces significant control over line-breaking and indentation functionality. It also leaves some attributes unspecified by stating the behavior should follow renderer-specific rules (thus having an "auto" value). The latest version of MathFlow allows you to control what happens when "auto" is used, along with additional line-breaking/indenting styles. Several of these attributes are based on the notion of an expression tree. In an expression such as y=ax+b, the expression tree is either explicitly written into the MathML (via mrow nesting) or inferred based on the operators present or implicit (e.g., implicit multiplication). For the example above, the expression tree looks like this:

Expression tree

It's easy to see y is at depth 1 in the tree and a is at depth 3. The expression tree is used for automatic linebreaking and indentation.

Linebreaking

MathFlow has two styles of automatic linebreaking, both of which are controlled by the "linebreak" attribute.

linebreak="auto" Lines are filled based on an algorithm that balances filling the line with keeping mathematical sub-expressions such as "ax + b" together on a line.
linebreak="dsi-linebreakop" <mo>s that have dsi:linebreakop="true" have special breaking behavior. Typically, relational symbols (such as "=") should be marked with dsi:linebreakop="true" in the operator dictionary. For the purposes of description, assume all occurrences of "=" are marked as being dsi:linebreakop="true".

The behavior of line-breaking is as follows:

  1. If the expression fits on a line, it is not broken.
  2. The expression is broken on the second and subsequent occurrences of a "=". Typically linebreakstyle="before" so that the "=" starts the next line.
  3. If the part of the expression between "="s is longer than what fits on a line, then "auto" line-breaking is used to break that part of the that expression.
  4. If the first occurrence of "=" is too far to the right (currently 30% of linewidth), then line will be broken before the first "=". If the part of the expression before the first "=" is longer than what fits on a line, then "auto" line-breaking is used to break that part of the expression.
  5. After a linebreak, the next line is indented.

Indenting

MathFlow has two styles of automatic indenting, both of which are controlled by the "indentalign" attribute.

indentalign="auto" The indentation is depth*dsi:indentamount. If this amount exceeds half of the line width, indentation is limited to half of the line width.
indentalign="dsi-linebreakop" Typically used with linebreak="dsi-linebreakop" (refer to description above). For the purposes of description, assume that all occurrences of "=" are marked as being "dsi:linebreakop='true'".

The behavior of indentation is as follows:

  1. If some previous line contained an "=", then indent to the first "=". If this line does not start with an "=", indent an extra level of indentation.
  2. If no previous line contained an "=", then indent one level of indentation (the tree depth is not used). If this line does not start with an "=", indent an extra level of indentation.

Attribute Descriptions and Accepted Values

AttributeDescriptionValues
dsi:linebreakop Legal for <mo>, <mstyle>, and <html><html><html><html><html><html><html><html><math>, but only sensible on <mo>. If true, the operator is used when linebreak="dsi-linebreakop" to control line-breaking behavior and when indentalign="dsi-linebreakop" to control indenting behavior. This attribute is typically set in the operator dictionary. Boolean (default: false)
dsi:linebreakfillpenalty Legal for <mo>, <mstyle>, and <math>. It controls the relative amount of influence that keeping mathematical structure together should have versus how full a line should be. Smaller values favor keeping structure together on a line. Higher values favor filling the line. A value between 0.0 and 1.0 (default: 0.2). To fill as much as possible, use 1.0. To keep math structures together as much as possible, use 0.0.
dsi:indentamount Legal for <mo>, <mstyle>, and <math>. If the attribute indentalign="auto", MathFlow will indent based upon the depth of the expression in the expression tree at the point of the linebreak. The total amount of indentation is depth*dsi:indentamount. If this amount exceeds half of the line width, it is limited to half of the line width. A dimensioned attr (eg, "0.83em"). Default 1.0em

maction

The maction element provides a mechanism for binding actions to expressions, and always has an actiontype attribute applied. These attributes may be used within MathFlow for specific maction capability when displayed with MathPlayer:

AttributeDescriptionValues
dsi:background Fills the expression background with the specified color. rgb | #rrggbb | html-color-name
dsi:color Expression foreground color. rgb | #rrggbb | html-color-name
dsi:backgroundstyle Depending on its value, will highlight the expression either by filling its background with color specified by the dsi:background attribute, or by drawing a dsi:background-colored frame around it. fill | frame
dsi:href Provides capability to load a web page upon clicking an expression covered by maction. URL

Examples:

  • Upon mouseover, colors the expression red and draws a blue frame around it.
    <maction dsi:backgroundstyle='frame' dsi:background='blue' dsi:color='red' actiontype='highlight'>
  • Upon clicking the expression, loads the specified URL in the browser. Note that http:// is required.
    <maction dsi:href='http://google.com' actiontype='link'>

Other Attributes

AttributeDescriptionValues
dsi:ascent The amount in pixels above the baseline. See figure beneath this table. Distance in pixels
dsi:background The background color of the maction element. See MathML spec. MathML 3 allows the use of mathcolor and mathbackground on all presentation elements, so these are less useful now although dsi:background is used with dsi:backgroundstyle
dsi:backgroundstyle The style to use for the background "fill": Fill the background with the dsi:background color "frame": Draw a frame around the maction node using the dsi:background color
dsi:color The foreground color of the maction element. See MathML spec. MathML 3 allows the use of mathcolor and mathbackground on all presentation elements.
dsi:descent The amount in pixels below the baseline. See figure beneath this table. Distance in pixels
dsi:href URL to visit when clicking on an maction element. MathML made href an attribute of all nodes, so this attribute is deprecated. A valid URL
dsi:left The left sidebearing -- this is the "extra" amount on the left side of the chars used for drawing; it is typically added to the bounding box of the characters because you don't want one character to start where the last left off. See figure beneath this table. Distance in pixels
dsi:maxtableshrink Valid for <mstyle>, <math>, and <mtable>. When tables are too wide to fit in the allowed space, their width is shrunk. This causes some or all of their columns to have their width reduced, causing some entries in those columns to linewrap. At the point where the code figures out that the table needs to be narrower, not all information is known about how much it should shrink because information such as indents and allowable break points are not known. This attribute controls the maximum amount the code will shrink the table by. Eg, if length is "4em", the table will shrink by no more than 4 ems. If length is "20%" (the default), the table will shrink by no more than 20% of the linebreaking width. Length (default: "20%"), where length is any valid length value (in, pt, em) and % is interpreted as being a percent of the line-breaking width at that point.
dsi:right The right sidebearing -- this is the "extra" amount on the right side of the chars used for drawing; it is typically added to the bounding box of the characters because you don't want the next character to start before this one leaves off. See figure beneath this table. Distance in pixels
dsi:scriptsatsameheight Valid for <mstyle> and <math>. If true, nested scripts will be positioned at the same height. For example, (x² + y²)² will position all of the 2s at same height. This attribute does not affect script positions when the nest expression ends with a character that is tall-stretched. For example, eh over bee plus y squared quantity squared will not position the 2s at the same height. Boolean value (default: false)
dsi:useprecomposed Valid for <mstyle> and <math>. Unicode defines the number of characters that can "compose" with the character before it. Typical examples are accent marks on letters. Many fonts include nicely composed letters which will be used when the value is "true." However, if the combining character is being used for mathematical markup, then the pre-composed character will not display as intended. For example, the Greek capital letter "alpha" (U+0391) composed with the combining acute accent (U+0301) appears as Ά (U+0386) in the Greek alphabet and in most fonts. To avoid this, use "false." This only affects cases where letters and accents are used instead of markup. Note that MathML suggests using markup (e.g., mover) for these cases. If markup is used, "true" (the default) should be used. Boolean value (default: true)

font metrics

Stretchy characters

AttributeDescriptionValues
dsi:stretchby Legal for <mo>, <mstyle>, and <math>. Controls whether the stretchy character should use segments (connecting pieces of the character) or scaling (stretching a characters). This only applies to characters that have segments that can be put together to make the character. segments | scaling (default: segments)
dsi:scaleratiopct Legal for <mo>, <mstyle>, and <math>. When scaling a stretchy character, this is the percentage of growth in a non-sizing direction. It allows a character to maintain a more natural look when scaled, but still not appear too thick. Integer, typically between 30 and 100 (default: 70%)