Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.w3.org/TR/MathML2/chapter3.html below:

Presentation Markup

Matrices, arrays and other table-like mathematical notation are marked up using mtable, mtr, mlabeledtr and mtd elements. These elements are similar to the table, tr and td elements of HTML, except that they provide specialized attributes for the fine layout control necessary for commutative diagrams, block matrices and so on.

The mlabeledtr element represents a labeled row of a table and can be used for numbered equations. The first child of mlabeledtr is the label. A label is somewhat special in that it is not considered an expression in the matrix and is not counted when determining the number of columns in that row.

A matrix or table is specified using the mtable element. Inside of the mtable element, only mtr or mlabeledtr elements may appear.

In MathML 1.x, the mtable element could infer mtr elements around its arguments, and the mtr element could infer mtd elements. In other words, if some argument to an mtable was not an mtr element, a MathML application was to assume a row with a single column (i.e. the argument was effectively wrapped with an inferred mtr). Similarly, if some argument to a (possibly inferred) mtr element was not an mtd element, that argument was to be treated as a table entry by wrapping it with an inferred mtd element. MathML 2.0 deprecates the inference of mtr and mtd elements; mtr and mtd elements must be used inside of mtable and mtr respectively.

Table rows that have fewer columns than other rows of the same table (whether the other rows precede or follow them) are effectively padded on the right with empty mtd elements so that the number of columns in each row equals the maximum number of columns in any row of the table. Note that the use of mtd elements with non-default values of the rowspan or columnspan attributes may affect the number of mtd elements that should be given in subsequent mtr elements to cover a given number of columns. Note also that the label in an mlabeledtr element is not considered a column in the table.

In addition to the attributes listed below, this element permits id, xref, class and style attributes, as described in Section 2.4.5 Attributes Shared by all MathML Elements.

Note that the default value for each of rowlines, columnlines and frame is the literal string "none", meaning that the default is to render no lines, rather than that there is no default.

As described in Section 2.4.4 MathML Attribute Values, the notation (x | y)+ means one or more occurrences of either x or y, separated by whitespace. For example, possible values for columnalign are "left", "left left", and "left right center center". If there are more entries than are necessary (e.g. more entries than columns for columnalign), then only the first entries will be used. If there are fewer entries, then the last entry is repeated as often as necessary. For example, if columnalign="right center" and the table has three columns, the first column will be right aligned and the second and third columns will be centered. The label in a mlabeledtr is not considered as a column in the table and the attribute values that apply to columns do not apply to labels.

The align attribute specifies where to align the table with respect to its environment. "axis" means to align the center of the table on the environment's axis. (The axis of an equation is an alignment line used by typesetters. It is the line on which a minus sign typically lies. The center of the table is the midpoint of the table's vertical extent.) "center" and "baseline" both mean to align the center of the table on the environment's baseline. "top" or "bottom" aligns the top or bottom of the table on the environment's baseline.

If the align attribute value ends with a "rownumber" between 1 and n (for a table with n rows), the specified row is aligned in the way described above, rather than the table as a whole; the top (first) row is numbered 1, and the bottom (last) row is numbered n. The same is true if the row number is negative, between -1 and -n, except that the bottom row is referred to as -1 and the top row as -n. Other values of "rownumber" are illegal.

The rowalign attribute specifies how the entries in each row should be aligned. For example, "top" means that the tops of each entry in each row should be aligned with the tops of the other entries in that row. The columnalign attribute specifies how the entries in each column should be aligned.

The groupalign and alignmentscope attributes are described with the alignment elements, maligngroup and malignmark, in Section 3.5.5 Alignment Markers.

The columnwidth attribute specifies how wide a column should be. The "auto" value means that the column should be as wide as needed, which is the default. If an explicit value is given, then the column is exactly that wide and the contents of that column are made to fit in that width. The contents are linewrapped or clipped at the discretion of the renderer. If "fit" is given as a value, the remaining page width after subtracting the widths for columns specified as "auto" and/or specific widths is divided equally among the "fit" columns and this value is used for the column width. If insufficient room remains to hold the contents of the "fit" columns, renderers may linewrap or clip the contents of the "fit" columns. When the columnwidth is specified as a percentage, the value is relative to the width of the table. That is, a renderer should try to adjust the width of the column so that it covers the specified percentage of the entire table width.

The width attribute specifies the desired width of the entire table and is intended for visual user agents. When the value is a percentage value, the value is relative to the horizontal space a MathML renderer has available for the math element. When the value is "auto", the MathML renderer should calculate the table width from its contents using whatever layout algorithm it chooses.

MathML 2.0 does not specify a table layout algorithm. In particular, it is the responsibility of a MathML renderer to resolve conflicts between the width attribute and other constraints on the width of a table, such as explicit values for columnwidth attributes, and minimum sizes for table cell contents. For a discussion of table layout algorithms, see Cascading Style Sheets, level 2.

The rowspacing and columnspacing attributes specify how much space should be added between each row and column. However, spacing before the first row and after the last row (i.e. at the top and bottom of the table) is given by the second number in the value of the framespacing attribute, and spacing before the first column and after the last column (i.e. on the left and on the right of the table) is given by the first number in the value of the framespacing attribute.

In those attributes' syntaxes, h-unit or v-unit represents a unit of horizontal or vertical length, respectively (see Section 2.4.4.2 Attributes with units). The units shown in the attributes' default values (em or ex) are typically used.

The rowlines and columnlines attributes specify whether and what kind of lines should be added between each row and column. Lines before the first row or column and after the last row or column are given using the frame attribute.

If a frame is desired around the table, the frame attribute is used. If the attribute value is not "none", then framespacing is used to add spacing between the lines of the frame and the first and last rows and columns of the table. If frame="none", then the framespacing attribute is ignored. The frame and framespacing attributes are not part of the rowlines/columnlines, rowspacing/columnspacing options because having them be so would often require that rowlines and columnlines would need to be fully specified instead of just giving a single value. For example, if a table had five columns and it was desired to have no frame around the table but to have lines between the columns, then columnlines="none solid solid solid solid none" would be necessary. If the frame is separated from the internal lines, only columnlines="solid" is needed.

The equalrows attribute forces the rows all to be the same total height when set to "true". The equalcolumns attribute forces the columns all to be the same width when set to "true".

The displaystyle attribute specifies the value of displaystyle (described under mstyle in Section 3.3.4 Style Change (mstyle)) within each cell (mtd element) of the table. Setting displaystyle="true" can be useful for tables whose elements are whole mathematical expressions; the default value of "false" is appropriate when the table is part of an expression, for example, when it represents a matrix. In either case, scriptlevel (Section 3.3.4 Style Change (mstyle)) is not changed for the table cells.

The side attribute specifies what side of a table a label for a table row should should be placed. This attribute is intended to be used for labeled expressions. If "left" or "right" is specified, the label is placed on the left or right side of the table row respectively. The other two attribute values are variations on "left" and "right": if the labeled row fits within the width allowed for the table without the label, but does not fit within the width if the label is included, then the label overlaps the row and is displayed above the row if rowalign for that row is "top"; otherwise the label is displayed below the row.

If there are multiple labels in a table, the alignment of the labels within the virtual column that they form is left-aligned for labels on the left side of the table, and right-aligned for labels on the right side of the table. The alignment can be overridden by specifying columnalignment for a mlabeledtr element.

The minlabelspacing attribute specifies the minimum space allowed between a label and the adjacent entry in the row.

A 3 by 3 identity matrix could be represented as follows:

<mrow>
  <mo> ( </mo>
  <mtable>
    <mtr>
      <mtd> <mn>1</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
    </mtr>
    <mtr>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>1</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
    </mtr>
    <mtr>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>1</mn> </mtd>
    </mtr>
  </mtable>
  <mo> ) </mo>
</mrow>

This might be rendered as:

Note that the parentheses must be represented explicitly; they are not part of the mtable element's rendering. This allows use of other surrounding fences, such as brackets, or none at all.

An mtr element represents one row in a table or matrix. An mtr element is only allowed as a direct sub-expression of an mtable element, and specifies that its contents should form one row of the table. Each argument of mtr is placed in a different column of the table, starting at the leftmost column.

As described in Section 3.5.1 Table or Matrix (mtable), mtr elements are effectively padded on the right with mtd elements when they are shorter than other rows in a table.

In addition to the attributes listed below, this element permits id, xref, class and style attributes, as described in Section 2.4.5 Attributes Shared by all MathML Elements.

The rowalign and columnalign attributes allow a specific row to override the alignment specified by the same attributes in the surrounding mtable element.

As with mtable, if there are more entries than necessary in the value of columnalign (i.e. more entries than columns in the row), then the extra entries will be ignored. If there are fewer entries than columns, then the last entry will be repeated as many times as needed.

The groupalign attribute is described with the alignment elements, maligngroup and malignmark, in Section 3.5.5 Alignment Markers.

An mlabeledtr element represents one row in a table that has a label on either the left or right side, as determined by the side attribute. The label is the first child of mlabeledtr. The rest of the children represent the contents of the row and are identical to those used for mtr; all of the children except the first must be mtd elements.

An mlabeledtr element is only allowed as a direct sub-expression of an mtable element. Each argument of mlabeledtr except for the first argument (the label) is placed in a different column of the table, starting at the leftmost column.

Note that the label element is not considered to be a cell in the table row. In particular, the label element is not taken into consideration in the table layout for purposes of width and alignment calculations. For example, in the case of an mlabeledtr with a label and a single centered mtd child, the child is first centered in the enclosing mtable, and then the label is placed. Specifically, the child is not centered in the space that remains in the table after placing the label.

While MathML 2.0 does not specify an algorithm for placing labels, implementors of visual renderers may find the following formatting model useful. To place a label, an implementor might think in terms of creating a larger table, with an extra column on both ends. The columnwidth attributes of both these border columns would be set to "fit" so that they expand to fill whatever space remains after the inner columns have been laid out. Finally, depending on the values of side and minlabelspacing, the label is placed in whatever border column is appropriate, possibly shifted down if necessary.

The attributes for mlabeledtr are the same as for mtr. Unlike the attributes for the mtable element, attributes of mlabeledtr that apply to column elements also apply to the label. For example, in a one column table,

<mlabeledtr rowalign='top'>

means that the label and other entries in the row are vertically aligned along their top. To force a particular alignment on the label, the appropriate attribute would normally be set on the mtd start tag that surrounds the label content.

One of the important uses of mlabeledtr is for numbered equations. In a mlabeledtr, the label represents the equation number and the elements in the row are the equation being numbered. The side and minlabelspacing attributes of mtable determine the placement of the equation number.

In larger documents with many numbered equations, automatic numbering becomes important. While automatic equation numbering and automatically resolving references to equation numbers is outside the scope of MathML, these problems can be addressed by the use of style sheets or other means. The mlabeledtr construction provides support for both of these functions in a way that is intended to facilitate XSLT processing. The mlabeledtr element can be used to indicate the presence of a numbered equation, and the first child can be changed to the current equation number, along with incrementing the global equation number. For cross references, an id on either the mlabeledtr element or on the first element itself could be used as a target of any link.

<mtable>
  <mlabeledtr id='e-is-m-c-square'>
    <mtd>
      <mtext> (2.1) </mtext>
    </mtd>
    <mtd>
     <mrow>
       <mi>E</mi>
       <mo>=</mo>
       <mrow>
        <mi>m</mi>
        <mo>&it;</mo>
        <msup>
         <mi>c</mi>
         <mn>2</mn>
        </msup>
       </mrow>
     </mrow>
    </mtd>
  </mlabeledtr>
</mtable>

This should be rendered as:

An mtd element represents one entry, or cell, in a table or matrix. An mtd element is only allowed as a direct sub-expression of an mtr or an mlabeledtr element.

The mtd element accepts any number of arguments; if this number is not 1, its contents are treated as a single "inferred mrow" formed from all its arguments, as described in Section 3.1.3 Required Arguments.

The rowspan and columnspan attributes allow a specific matrix element to be treated as if it occupied the number of rows or columns specified. The interpretation of how this larger element affects specifying subsequent rows and columns is meant to correspond with the similar attributes for HTML 4.01 tables.

The rowspan and columnspan attributes can be used around an mtd element that represents the label in a mlabeledtr element. Also, the label of a mlabeledtr element is not considered to be part of a previous rowspan and columnspan.

The rowalign and columnalign attributes allow a specific matrix element to override the alignment specified by a surrounding mtable or mtr element.

The groupalign attribute is described with the alignment elements, maligngroup and malignmark, in Section 3.5.5 Alignment Markers.

Alignment markers are space-like elements (see Section 3.2.7 Space (mspace)) that can be used to vertically align specified points within a column of MathML expressions by the automatic insertion of the necessary amount of horizontal space between specified sub-expressions.

The discussion that follows will use the example of a set of simultaneous equations that should be rendered with vertical alignment of the coefficients and variables of each term, by inserting spacing somewhat like that shown here:

    8.44x + 55  y =  0
    3.1 x -  0.7y = -1.1

If the example expressions shown above were arranged in a column but not aligned, they would appear as:

    8.44x + 55y = 0
    3.1x - 0.7y = -1.1

For audio renderers, it is suggested that the alignment elements produce the analogous behavior of altering the rhythm of pronunciation so that it is the same for several sub-expressions in a column, by the insertion of the appropriate time delays in place of the extra horizontal spacing described here.

The expressions whose parts are to be aligned (each equation, in the example above) must be given as the table elements (i.e. as the mtd elements) of one column of an mtable. To avoid confusion, the term "table cell" rather than "table element" will be used in the remainder of this section.

All interactions between alignment elements are limited to the mtable column they arise in. That is, every column of a table specified by an mtable element acts as an "alignment scope" that contains within it all alignment effects arising from its contents. It also excludes any interaction between its own alignment elements and the alignment elements inside any nested alignment scopes it might contain.

The reason mtable columns are used as alignment scopes is that they are the only general way in MathML to arrange expressions into vertical columns. Future versions of MathML may provide an malignscope element that allows an alignment scope to be created around any MathML element, but even then, table columns would still sometimes need to act as alignment scopes, and since they are not elements themselves, but rather are made from corresponding parts of the content of several mtr elements, they could not individually be the content of an alignment scope element.

An mtable element can be given the attribute alignmentscope="false" to cause its columns not to act as alignment scopes. This is discussed further at the end of this section. Otherwise, the discussion in this section assumes that this attribute has its default value of "true".

To cause alignment, it is necessary to specify, within each expression to be aligned, the points to be aligned with corresponding points in other expressions, and the beginning of each alignment group of sub-expressions that can be horizontally shifted as a unit to effect the alignment. Each alignment group must contain one alignment point. It is also necessary to specify which expressions in the column have no alignment groups at all, but are affected only by the ordinary column alignment for that column of the table, i.e. by the columnalign attribute, described elsewhere.

The alignment groups start at the locations of invisible maligngroup elements, which are rendered with zero width when they occur outside of an alignment scope, but within an alignment scope are rendered with just enough horizontal space to cause the desired alignment of the alignment group that follows them. A simple algorithm by which a MathML application can achieve this is given later. In the example above, each equation would have one maligngroup element before each coefficient, variable, and operator on the left-hand side, one before the = sign, and one before the constant on the right-hand side.

In general, a table cell containing n maligngroup elements contains n alignment groups, with the ith group consisting of the elements entirely after the ith maligngroup element and before the (i+1)-th; no element within the table cell's content should occur entirely before its first maligngroup element.

Note that the division into alignment groups does not necessarily fit the nested expression structure of the MathML expression containing the groups - that is, it is permissible for one alignment group to consist of the end of one mrow, all of another one, and the beginning of a third one, for example. This can be seen in the MathML markup for the present example, given at the end of this section.

The nested expression structure formed by mrows and other layout schemata should reflect the mathematical structure of the expression, not the alignment-group structure, to make possible optimal renderings and better automatic interpretations; see the discussion of proper grouping in section Section 3.3.1 Horizontally Group Sub-Expressions (mrow). Insertion of alignment elements (or other space-like elements) should not alter the correspondence between the structure of a MathML expression and the structure of the mathematical expression it represents.

Although alignment groups need not coincide with the nested expression structure of layout schemata, there are nonetheless restrictions on where an maligngroup element is allowed within a table cell. The maligngroup element may only be contained within elements (directly or indirectly) of the following types (which are themselves contained in the table cell):

• an mrow element, including an inferred mrow such as the one formed by a multi-argument mtd element;

• an mstyle element;

• an mphantom element;

• an mfenced element;

• an maction element, though only its selected sub-expression is checked;

• a semantics element.

These restrictions are intended to ensure that alignment can be unambiguously specified, while avoiding complexities involving things like overscripts, radical signs and fraction bars. They also ensure that a simple algorithm suffices to accomplish the desired alignment.

Note that some positions for an maligngroup element, although legal, are not useful, such as for an maligngroup element to be an argument of an mfenced element. When inserting an maligngroup element before a given element in pre-existing MathML, it will often be necessary, and always acceptable, to form a new mrow element to contain just the maligngroup element and the element it is inserted before. In general, this will be necessary except when the maligngroup element is inserted directly into an mrow or into an element that can form an inferred mrow from its contents. See the warning about the legal grouping of "space-like elements" in Section 3.2.7 Space (mspace).

For the table cells that are divided into alignment groups, every element in their content must be part of exactly one alignment group, except the elements from the above list that contain maligngroup elements inside them, and the maligngroup elements themselves. This means that, within any table cell containing alignment groups, the first complete element must be an maligngroup element, though this may be preceded by the start tags of other elements.

This requirement removes a potential confusion about how to align elements before the first maligngroup element, and makes it easy to identify table cells that are left out of their column's alignment process entirely.

Note that it is not required that the table cells in a column that are divided into alignment groups each contain the same number of groups. If they don't, zero-width alignment groups are effectively added on the right side of each table cell that has fewer groups than other table cells in the same column.

Expressions in a column that are to have no alignment groups should contain no maligngroup elements. Expressions with no alignment groups are aligned using only the columnalign attribute that applies to the table column as a whole, and are not affected by the groupalign attribute described below. If such an expression is wider than the column width needed for the table cells containing alignment groups, all the table cells containing alignment groups will be shifted as a unit within the column as described by the columnalign attribute for that column. For example, a column heading with no internal alignment could be added to the column of two equations given above by preceding them with another table row containing an mtext element for the heading, and using the default columnalign="center" for the table, to produce:

equations with aligned variables
      8.44x + 55  y =  0
      3.1 x -  0.7y = -1.1

or, with a shorter heading,

   some equations
8.44x + 55  y =  0
3.1 x -  0.7y = -1.1

Each alignment group's alignment point can either be specified by an malignmark element anywhere within the alignment group (except within another alignment scope wholly contained inside it), or it is determined automatically from the groupalign attribute. The groupalign attribute can be specified on the group's preceding maligngroup element or on its surrounding mtd, mtr, or mtable elements. In typical cases, using the groupalign attribute is sufficient to describe the desired alignment points, so no malignmark elements need to be provided.

The malignmark element indicates that the alignment point should occur on the right edge of the preceding element, or the left edge of the following element or character, depending on the edge attribute of malignmark. Note that it may be necessary to introduce an mrow to group an malignmark element with a neighboring element, in order not to alter the argument count of the containing element. (See the warning about the legal grouping of "space-like elements" in Section 3.2.7 Space (mspace)).

When an malignmark element is provided within an alignment group, it can occur in an arbitrarily deeply nested element within the group, as long as it is not within a nested alignment scope. It is not subject to the same restrictions on location as maligngroup elements. However, its immediate surroundings need to be such that the element to its immediate right or left (depending on its edge attribute) can be unambiguously identified. If no such element is present, renderers should behave as if a zero-width element had been inserted there.

For the purposes of alignment, an element X is considered to be to the immediate left of an element Y, and Y to the immediate right of X, whenever X and Y are successive arguments of one (possibly inferred) mrow element, with X coming before Y. In the case of mfenced elements, MathML applications should evaluate this relation as if the mfenced element had been replaced by the equivalent expanded form involving mrow. Similarly, an maction element should be treated as if it were replaced by its currently selected sub-expression. In all other cases, no relation of "to the immediate left or right" is defined for two elements X and Y. However, in the case of content elements interspersed in presentation markup, MathML applications should attempt to evaluate this relation in a sensible way. For example, if a renderer maintains an internal presentation structure for rendering content elements, the relation could be evaluated with respect to that. (See Chapter 4 Content Markup and Chapter 5 Combining Presentation and Content Markup for further details about mixing presentation and content markup.)

malignmark elements are allowed to occur within the content of token elements, such as mn, mi, or mtext. When this occurs, the character immediately before or after the malignmark element will carry the alignment point; in all other cases, the element to its immediate left or right will carry the alignment point. The rationale for this is that it is sometimes desirable to align on the edges of specific characters within multi-character token elements.

If there is more than one malignmark element in an alignment group, all but the first one will be ignored. MathML applications may wish to provide a mode in which they will warn about this situation, but it is not an error, and should trigger no warnings by default. The rationale for this is that it would be inconvenient to have to remove all unnecessary malignmark elements from automatically generated data, in certain cases, such as when they are used to specify alignment on "decimal points" other than the '.' character.

In addition to the attributes listed below, the malignmark element permits id, xref, class and style attributes, as described in Section 2.4.5 Attributes Shared by all MathML Elements.

malignmark has one attribute, edge, which specifies whether the alignment point will be found on the left or right edge of some element or character. The precise location meant by "left edge" or "right edge" is discussed below. If edge="right", the alignment point is the right edge of the element or character to the immediate left of the malignmark element. If edge="left", the alignment point is the left edge of the element or character to the immediate right of the malignmark element. Note that the attribute refers to the choice of edge rather than to the direction in which to look for the element whose edge will be used.

For malignmark elements that occur within the content of MathML token elements, the preceding or following character in the token element's content is used; if there is no such character, a zero-width character is effectively inserted for the purpose of carrying the alignment point on its edge. For all other malignmark elements, the preceding or following element is used; if there is no such element, a zero-width element is effectively inserted to carry the alignment point.

The precise definition of the "left edge" or "right edge" of a character or glyph (e.g. whether it should coincide with an edge of the character's bounding box) is not specified by MathML, but is at the discretion of the renderer; the renderer is allowed to let the edge position depend on the character's context as well as on the character itself.

For proper alignment of columns of numbers (using groupalign values of "left", "right", or "decimalpoint"), it is likely to be desirable for the effective width (i.e. the distance between the left and right edges) of decimal digits to be constant, even if their bounding box widths are not constant (e.g. if "1" is narrower than other digits). For other characters, such as letters and operators, it may be desirable for the aligned edges to coincide with the bounding box.

The "left edge" of a MathML element or alignment group refers to the left edge of the leftmost glyph drawn to render the element or group, except that explicit space represented by mspace or mtext elements should also count as "glyphs" in this context, as should glyphs that would be drawn if not for mphantom elements around them. The "right edge" of an element or alignment group is defined similarly.

In addition to the attributes listed below, the maligngroup element permits id, xref, class and style attributes, as described in Section 2.4.5 Attributes Shared by all MathML Elements.

maligngroup has one attribute, groupalign, which is used to determine the position of its group's alignment point when no malignmark element is present. The following discussion assumes that no malignmark element is found within a group.

In the example given at the beginning of this section, there is one column of 2 table cells, with 7 alignment groups in each table cell; thus there are 7 columns of alignment groups, with 2 groups, one above the other, in each column. These columns of alignment groups should be given the 7 groupalign values "decimalpoint left left decimalpoint left left decimalpoint", in that order. How to specify this list of values for a table cell or table column as a whole, using attributes on elements surrounding the maligngroup element is described later.

If groupalign is "left", "right", or "center", the alignment point is defined to be at the group's left edge, at its right edge, or halfway between these edges, respectively. The meanings of "left edge" and "right edge" are as discussed above in relation to malignmark.

If groupalign is "decimalpoint", the alignment point is the right edge of the last character before the decimal point. The decimal point is the first "." character (ASCII 0x2e) in the first mn element found along the alignment group's baseline. More precisely, the alignment group is scanned recursively, depth-first, for the first mn element, descending into all arguments of each element of the types mrow (including inferred mrows), mstyle, mpadded, mphantom, menclose, mfenced, or msqrt, descending into only the first argument of each "scripting" element (msub, msup, msubsup, munder, mover, munderover, mmultiscripts) or of each mroot or semantics element, descending into only the selected sub-expression of each maction element, and skipping the content of all other elements. The first mn so found always contains the alignment point, which is the right edge of the last character before the first decimal point in the content of the mn element. If there is no decimal point in the mn element, the alignment point is the right edge of the last character in the content. If the decimal point is the first character of the mn element's content, the right edge of a zero-width character inserted before the decimal point is used. If no mn element is found, the right edge of the entire alignment group is used (as for groupalign="right").

In order to permit alignment on decimal points in cn elements, a MathML application can convert a content expression into a presentation expression that renders the same way before searching for decimal points as described above.

If characters other than "." should be used as "decimal points" for alignment, they should be preceded by malignmark elements within the mn token's content itself.

For any of the groupalign values, if an explicit malignmark element is present anywhere within the group, the position it specifies (described earlier) overrides the automatic determination of alignment point from the groupalign value.

It is not usually necessary to put a groupalign attribute on every maligngroup element. Since this attribute is usually the same for every group in a column of alignment groups to be aligned, it can be inherited from an attribute on the mtable that was used to set up the alignment scope as a whole, or from the mtr or mtd elements surrounding the alignment group. It is inherited via an "inheritance path" that proceeds from mtable through successively contained mtr, mtd, and maligngroup elements. There is exactly one element of each of these kinds in this path from an mtable to any alignment group inside it. In general, the value of groupalign will be inherited by any given alignment group from the innermost element that surrounds the alignment group and provides an explicit setting for this attribute. For example, if an mtable element specifies values for groupalign and a maligngroup element within the table also specifies an explicit groupalign value, then then the value from the maligngroup takes priority.

Note, however, that each mtd element needs, in general, a list of groupalign values, one for each maligngroup element inside it, rather than just a single value. Furthermore, an mtr or mtable element needs, in general, a list of lists of groupalign values, since it spans multiple mtable columns, each potentially acting as an alignment scope. Such lists of group-alignment values are specified using the following syntax rules:

group-alignment            := left | right | center | decimalpoint
group-alignment-list       := group-alignment +
group-alignment-list-list := ( '{' group-alignment-list '}' ) +

As described in Section 2.4.4 MathML Attribute Values, | separates alternatives; + represents optional repetition (i.e. 1 or more copies of what precedes it), with extra values ignored and the last value repeated if necessary to cover additional table columns or alignment group columns; '{' and '}' represent literal braces; and ( and ) are used for grouping, but do not literally appear in the attribute value.

The permissible values of the groupalign attribute of the elements that have this attribute are specified using the above syntax definitions as follows:

In the example near the beginning of this section, the group alignment values could be specified on every mtd element using groupalign = "decimalpoint left left decimalpoint left left decimalpoint", or on every mtr element using groupalign = "{decimalpoint left left decimalpoint left left decimalpoint}", or (most conveniently) on the mtable as a whole using groupalign = "{decimalpoint left left decimalpoint left left decimalpoint}", which provides a single braced list of group-alignment values for the single column of expressions to be aligned.

The above rules are sufficient to explain the MathML representation of the example given near the start of this section. To repeat the example, the desired rendering is:

    8.44x + 55  y =  0
    3.1 x -  0.7y = -1.1

One way to represent that in MathML is:

<mtable groupalign="{decimalpoint left left decimalpoint left left decimalpoint}">
  <mtr>
    <mtd>
      <mrow>
        <mrow>
          <mrow>
            <maligngroup/>
            <mn> 8.44 </mn>
            <mo> &InvisibleTimes; </mo>
            <maligngroup/>
            <mi> x </mi>
          </mrow>
          <maligngroup/>
          <mo> + </mo>
          <mrow>
            <maligngroup/>
            <mn> 55 </mn>
            <mo> &InvisibleTimes; </mo>
            <maligngroup/>
            <mi> y </mi>
          </mrow>
        </mrow>
      <maligngroup/>
      <mo> = </mo>
      <maligngroup/>
      <mn> 0 </mn>
    </mrow>
    </mtd>
  </mtr>
  <mtr>
    <mtd>
      <mrow>
        <mrow>
          <mrow>
            <maligngroup/>
            <mn> 3.1 </mn>
            <mo> &InvisibleTimes; </mo>
            <maligngroup/>
            <mi> x </mi>
          </mrow>
          <maligngroup/>
          <mo> - </mo>
          <mrow>
            <maligngroup/>
            <mn> 0.7 </mn>
            <mo> &InvisibleTimes; </mo>
            <maligngroup/>
            <mi> y </mi>
          </mrow>
        </mrow>
        <maligngroup/>
        <mo> = </mo>
        <maligngroup/>
        <mrow>
          <mo> - </mo>
          <mn> 1.1 </mn>
        </mrow>
      </mrow>
    </mtd>
  </mtr>
</mtable>

The alignment elements maligngroup and malignmark can occur outside of alignment scopes, where they are ignored. The rationale behind this is that in situations in which MathML is generated, or copied from another document, without knowing whether it will be placed inside an alignment scope, it would be inconvenient for this to be an error.

An mtable element can be given the attribute alignmentscope="false" to cause its columns not to act as alignment scopes. In general, this attribute has the syntax (true | false) +; if its value is a list of boolean values, each boolean value applies to one column, with the last value repeated if necessary to cover additional columns, or with extra values ignored. Columns that are not alignment scopes are part of the alignment scope surrounding the mtable element, if there is one. Use of alignmentscope="false" allows nested tables to contain malignmark elements for aligning the inner table in the surrounding alignment scope.

As discussed above, processing of alignment for content elements is not well-defined, since MathML does not specify how content elements should be rendered. However, many MathML applications are likely to find it convenient to internally convert content elements to presentation elements that render the same way. Thus, as a general rule, even if a renderer does not perform such conversions internally, it is recommended that the alignment elements should be processed as if it did perform them.

A particularly important case for renderers to handle gracefully is the interaction of alignment elements with the matrix content element, since this element may or may not be internally converted to an expression containing an mtable element for rendering. To partially resolve this ambiguity, it is suggested, but not required, that if the matrix element is converted to an expression involving an mtable element, that the mtable element be given the attribute alignmentscope="false", which will make the interaction of the matrix element with the alignment elements no different than that of a generic presentation element (in particular, it will allow it to contain malignmark elements that operate within the alignment scopes created by the columns of an mtable that contains the matrix element in one of its table cells).

The effect of alignment elements within table cells that have non-default values of the columnspan or rowspan attributes is not specified, except that such use of alignment elements is not an error. Future versions of MathML may specify the behavior of alignment elements in such table cells.

The effect of possible linebreaking of an mtable element on the alignment elements is not specified.

A simple algorithm by which a MathML application can perform the alignment specified in this section is given here. Since the alignment specification is deterministic (except for the definition of the left and right edges of a character), any correct MathML alignment algorithm will have the same behavior as this one. Each mtable column (alignment scope) can be treated independently; the algorithm given here applies to one mtable column, and takes into account the alignment elements, the groupalign attribute described in this section, and the columnalign attribute described under mtable (Section 3.5.1 Table or Matrix (mtable)).

First, a rendering is computed for the contents of each table cell in the column, using zero width for all maligngroup and malignmark elements. The final rendering will be identical except for horizontal shifts applied to each alignment group and/or table cell. The positions of alignment points specified by any malignmark elements are noted, and the remaining alignment points are determined using groupalign values.

For each alignment group, the horizontal positions of the left edge, alignment point, and right edge are noted, allowing the width of the group on each side of the alignment point (left and right) to be determined. The sum of these two "side-widths", i.e. the sum of the widths to the left and right of the alignment point, will equal the width of the alignment group.

Second, each column of alignment groups, from left to right, is scanned. The ith scan covers the ith alignment group in each table cell containing any alignment groups. Table cells with no alignment groups, or with fewer than i alignment groups, are ignored. Each scan computes two maximums over the alignment groups scanned: the maximum width to the left of the alignment point, and the maximum width to the right of the alignment point, of any alignment group scanned.

The sum of all the maximum widths computed (two for each column of alignment groups) gives one total width, which will be the width of each table cell containing alignment groups. Call the maximum number of alignment groups in one cell n; each such cell's width is divided into 2n adjacent sections, called L(i) and R(i) for i from 1 to n, using the 2n maximum side-widths computed above; for each i, the width of all sections called L(i) is the maximum width of any cell's ith alignment group to the left of its alignment point, and the width of all sections called R(i) is the maximum width of any cell's ith alignment group to the right of its alignment point.

The alignment groups are then positioned in the unique way that places the part of each ith group to the left of its alignment point in a section called L(i), and places the part of each ith group to the right of its alignment point in a section called R(i). This results in the alignment point of each ith group being on the boundary between adjacent sections L(i) and R(i), so that all alignment points of ith groups have the same horizontal position.

The widths of the table cells that contain no alignment groups were computed as part of the initial rendering, and may be different for each cell, and different from the single width used for cells containing alignment groups. The maximum of all the cell widths (for both kinds of cells) gives the width of the table column as a whole.

The position of each cell in the column is determined by the applicable part of the value of the columnalign attribute of the innermost surrounding mtable, mtr, or mtd element that has an explicit value for it, as described in the sections on those elements. This may mean that the cells containing alignment groups will be shifted within their column, in addition to their alignment groups having been shifted within the cells as described above, but since each such cell has the same width, it will be shifted the same amount within the column, thus maintaining the vertical alignment of the alignment points of the corresponding alignment groups in each cell.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4