Force specific position of the limits for sum, product, integral, etc.

[anermina]

ISO 80000-2 demonstrates different versions of the same entry for some math expressions, e.g.:

The limits are currently automatically generated by Metanorma as follows:
HTML:

DOC:

Could we enable forcing a specific position for the limits?

[opoudjis]

For limits and similar underscripts and overscripts in MathML (HTML), the global attribute displaystyle=true forces the limits to appear as expected, under and over the symbol. If displaystyle=false, the height of math expressions is minimised ("compact"), and they appear as subscripts and superscripts instead.

So we have a suite of problems:

1. The displaystyle default of Word (OOXML) is not the same as the displaystyle default of HTML (MathML)
2. The displaystyle default for both does not appear to conform to desired behaviour in MathML: that inline math expressions have compact style, displaystyle=false (so that prose does not look crap), and standalone formulas use normal style, displaystyle=true.
3. We have no way of telling AsciiMath to set the style to one or the other.

To start with (3): no. We will not introduce style commands to AsciiMath, they are utterly out of scope for it. The correct markup for the "are also used" line is to use MathML, not AsciiMath, to differentiate the two rendering styles. There are things that AsciiMath cannot and should not do, and this is one of them. So not:

stem:[nnn_{i in I}^n], stem:[nnn_{i in I}] and stem:[nnn_{i in I}] 

but

stem:[<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle displaystyle="false"><munderover><mo>⋂</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mi>n</mi></munderover></mstyle></math>], stem:[<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle displaystyle="true"><munder><mo>⋂</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder></mstyle></math>] and stem:[<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle displaystyle="false"><munder><mo>⋂</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder></mstyle></math>] 

(You get the MathML by converting a doc with the AsciiMath, and looking at the Semantic XML.)

[opoudjis]

There is also a bug in Plurimath. The munderover operands, sum prod ^^^ vvv nnn uuu, are being rendered with msubsup, which means they can never be rendered with limits above and below. This is a bug: they should be rendered with munderover (or munder or mover, if an operand is missing). Whether munderover is rendered in normal or compact style is determined by the displaystyle operand.

[opoudjis]

There remains the issue that DOC and HTML defaults are inconsistent. That is the result of two separate bugs:

• The conversion to OOXML is ignoring the displaystyle attribute in MathML, and is deciding whether to do compact or normal rendering based on other criteria that I haven't worked out yet. Debugging this will involve debugging the XSLT provided by Microsoft. (@suleman-uzair you are converting Plurimath to OMML; is that code ready for use? If so, please confirm that it respects the displaystyle attribute, or allows me to invoke it, as requested in Do not set displaystyle=true universally plurimath/plurimath#168 for MathML. I will then switch to using your converter in Metanorma.

• Plurimath is defaulting to displaystyle="true" universally in its output. Not too concerned about that, I can switch the displaystyle value locally after conversion, based on context.

• ... That said, I don't think Plurimath should be setting displaystyle without rendering hints from the consumer.

[suleman-uzair]

@opoudjis

you are converting Plurimath to OMML; is that code ready for use?

I am currently testing it, will let you know once it is finalized.

please confirm that it respects the displaystyle attribute, or allows me to invoke it

Plurimath currently sets the displaystyle attribute by default to true. I will make the necessary code updates in a new pull request to provide an option for users to invoke the displaystyle attribute as needed.

[opoudjis]

Changing Metanorma XML model to pass in mandatory block attribute, about whether element should be rendered as if a block or as if an inline element. (Currently it is contextually determined, but we cannot rule out user override.)

[opoudjis]

As part of refactor, I need to know when Asciimath is to be converted to MathML whether it is displaystyle or not. I have allowed a text-based asciimath conversion in Html2Doc for Word docs, because the Word XML is not necessarily clean XML, and shouldn't go into Nokogiri. But Html2Doc has not received raw AsciiMath in years, all maths is converted to MathML in Semantic Metanorma XML. So that code needs to move into metanorma-standoc, and should not be triggered within html2doc.

[opoudjis]

Input:

stem:[nnn_{i in I}^n]

[stem]
++++
nnn_{i in I}^n
++++

HTML is ok:

PDF is ok:

DOC is very far from OK:

and that is pending plurimath/plurimath#173 (among other tickets, some of which may not yet have been authored.)

Putting this ticket on hold, pending DOC resolution.

[opoudjis]

No, will use ticket #796 instead to cover the failure of DOC to pay attention to displaystyle.