diff --git a/src/presentation-markup.html b/src/presentation-markup.html index 1359ffd..dcaf573 100644 --- a/src/presentation-markup.html +++ b/src/presentation-markup.html @@ -483,7 +483,7 @@
Bidirectional Layout in Token Elements
how weakly directional characters are treated and how runs are nested. (The dir attribute is thus allowed on token elements to specify the initial directionality that may be needed in rare cases.) - Any mglyph or malignmark elements appearing within + Any mglyph elements appearing within a token element are effectively neutral and have no effect on ordering.

@@ -1126,12 +1126,9 @@

the content of token elements. Whitespace between elements is ignored. With the exception of the empty mspace element, token elements can contain any sequence of zero or more Unicode characters, - or mglyph or - malignmark elements. + or mglyph elements. The mglyph element is used - to represent non-standard characters or symbols by images; - the malignmark element establishes an alignment point for use within - table constructs, and is otherwise invisible (see ).

+ to represent non-standard characters or symbols by images.

Characters can be either represented directly as Unicode character data, or indirectly via numeric @@ -3370,9 +3367,7 @@

Description
embedded in a mathematical expression should be marked up with mtext, or in some cases mo or mi, but never with ms.

-

Note that the string literals encoded by ms are made up of characters, mglyphs and - malignmarks rather than ASCII - strings. For +

Note that the string literals encoded by ms are made up of characters, mglyphs rather than ASCII strings. For example, <ms>&amp;</ms> represents a string literal containing a single character, &, and <ms>&amp;amp;</ms> represents a string literal @@ -6843,21 +6838,11 @@

Alignment Markers

malignmark and maligngroup are not supported in [[MathML-Core]]. - For most purposes it is recommended that alignment is implemented directly using mtable columns. As noted in the following section these elements may be futher simplified or removed in a future version of MathML. -

-

For existing MathML using malignmark a Javascript polyfill - is provided.

-
- + For most purposes it is recommended that alignment is implemented directly using mtable columns.

+

For existing MathML using malignmark a Javascript polyfill is provided.

- -
-
Removal Notice

- With one significant exception, <maligngroup/> and <malignmark/> - have had minimal adoption and implementation. - The one exception only uses the basics of alignment. Because of this, alignment in MathML is significantly - simplified to align with the current usage and make future implementation simplier. In particular, the following simplifications are made: + The elements <maligngroup/> and <malignmark/> have been simplified compared to earlier release of MathML:

-
+
Description
@@ -6876,54 +6861,6 @@
Description
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.7y=-0
3.14x−50.7y=−1.1
-
-

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

- -
- - - - - - - - - -
8.44x - + - 55.7y - = - 0
3.1x - − - 50.7y - = - −1.1
-

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 @@ -6939,14 +6876,13 @@

Description
between its own alignment elements and the alignment elements inside any nested alignment scopes it might contain.

-

If there is only one alignment point, an alternative is to use linebreaking and indentation attributes - on mo elements as described in .

- +
@@ -6987,7 +6923,7 @@
Specifying alignment groups
third one, for example. This can be seen in the MathML markup for the example given at the end of this section.

-

Although alignment groups need not +

Although alignment groups need not coincide with the nested expression structure of layout schemata, there are nonetheless restrictions on where maligngroup and malignmark @@ -6998,18 +6934,12 @@

Specifying alignment groups

These restrictions are intended to ensure that alignment can be @@ -7036,7 +6963,7 @@

Specifying alignment groups

For the table cells that are divided into alignment groups, every element in their content must be part of exactly one alignment group, - except for the elements from the above list that contain + except for 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 @@ -7052,81 +6979,18 @@

Specifying alignment groups
groups. If they don't, zero-width alignment groups are effectively added on the right side (or left side, in a RTL context) of each table cell that has fewer groups than other table cells in the same column.

-

Do we want to tighten this so that all rows have the same number of maligngroup elements? -

+
Table cells that are not divided into alignment groups
-

Do we still want to allow rows without maligngroup as described in this section? -

-

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. 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.7y=-0     
3.14x−50.7y=−1.1
-
- -

or, with a shorter heading,

- -
- - - - - - - - - - - - - - - - - - -
some equations
8.44x+55.7y=-0
3.14x−50.7y=−1.1
-
+ column as a whole.

@@ -7146,14 +7010,8 @@
Specifying alignment points using malignmark element is provided within an alignment group, it should only occur within the elements allowed for maligngroup (see ). - 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.

+ If there should be at most one malignmark element + in an alignment group.

@@ -7248,90 +7106,15 @@
MathML representation of an alignment example
A simple alignment algorithm
- -

A simple algorithm by which a MathML renderer 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 and the columnalign attribute described - under mtable (). - In an RTL context, switch left and right edges in the algorithm.

-

This algorithm should be verified by an implementation. -

-
    -
  1. 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.
    2. -
  2. For each alignment group, the horizontal positions of the left - edge, alignment point (if specified by malignmark, otherwise the left edge), - 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.
    3. -
  3. Each column of alignment groups 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.
    4. -
  4. 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 - is divided into 2n horizontally 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.
    5. -
  5. Each alignment group is then shifted horizontally as a block - to a unique position that places: in the section called L(i) that part - of the ith group to the left of its alignment point; - in the section called R(i) that part of the ith group - to the right of its alignment point. 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.
    6. -
- - -

- -

- -

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.

+

Alignments marked wth maligngroup + may be converted to an equivalent mtable + that does not use maligngroup, but uses + additional table columns. + A Javascript polyfill is provided + to implement such a transformation which may be useful with [[MathML-Core]] implementations.

+ +

??.