Page MenuHomePhabricator

Closing bracket size too small
Closed, ResolvedPublic

Description

From https://de.wikipedia.org/wiki/Portal_Diskussion:Mathematik#c-Christian1985-20231122184800-Physikerwelt-20231122183800 in a discussion about T350787.
On the reference page,

image.png (456×670 px, 47 KB)

(screenshot taken from https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Intbar&oldid=32121#Normale_Integrale)
the test expression is rendered incorrectly in the lower native section. The upper MathML section is the intended result.

Event Timeline

latexml sets maxsize and minsize to 120% for the brakets`<mo maxsize="120%" minsize="120%" >]</mo>` MathJax does a similar thing. I am wondering if this is a workaround for a bug, or how this is supposed to work.

Aklapper renamed this task from Closing breaket size too small to Closing bracket size too small.Nov 30 2023, 10:51 AM
<math forcemathmode=native>\gamma \,x + \ln\bigl[\Gamma(x + 1)\bigr]= \sum_{n=1}^{\infty}\biggl[ \frac{x}{n} - \ln\biggl(1 + \frac{x}{n}\biggr) \biggr]</math>

related macro: "\bigr] "

Change 979078 had a related patch set uploaded (by Stegmujo; author: Stegmujo):

[mediawiki/extensions/Math@master] Fix closing bracket size too big

https://gerrit.wikimedia.org/r/979078

Change 979078 merged by jenkins-bot:

[mediawiki/extensions/Math@master] Fix closing bracket size too big

https://gerrit.wikimedia.org/r/979078

Hello @Stegmujo ,
hello @Physikerwelt ,

in Chrome the brakets are still rendered incorrectly, see

image.png (858×582 px, 64 KB)

Formula 1 in section Klammern is wrong and also formula 5 in section "Weiteres".

@Physikerwelt ,

no it looks the same as in the picture

image.png (858×582 px, 64 KB)

Before the fix was made the closing bracket in formula 5 was too big now it is too small.

Screenshot 2023-12-02 at 13.52.40.png (364×588 px, 42 KB)
Investigating this. The upper part is mathoid rendering rendered in Chrome with MathML, and the lower part is native rendering.

The closing element has the same properties in both versions; however, the mrow structure differs. If one puts the opening and closing brackets in an additional mrow, it looks ok.

Note that the first formula is in displaystyle and the second in inline style. I wonder how this did happen.

Change 979688 had a related patch set uploaded (by Stegmujo; author: Stegmujo):

[mediawiki/extensions/Math@master] Fix bracket sizes

https://gerrit.wikimedia.org/r/979688

As a reference or comparison, here a correctly displayed simplified example of formula nr 5:

<math id="p2.1.m1.1" class="ltx_Math" alttext="\biggl{(}A_{n}^{\mathsf{c}}\biggr{)}^{\!\!\mathsf{c}}" display="inline">
	<msup>
		<mrow>
			<mo>(</mo>
			<msubsup>
				<mi> A </mi>
				<mi>n</mi>
				<mi>𝖼</mi>
			</msubsup>
			<mo maxsize="210%" minsize="210%">)</mo>
		</mrow>
		<mi>𝖼</mi>
	</msup>	
 </math>

MathJax as reference, this is also not displayed correctly:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <mrow data-mjx-texclass="OPEN">
    <mo minsize="2.047em" maxsize="2.047em">(</mo>
  </mrow>
  <msubsup>
    <mi>A</mi>
    <mi>n</mi>
    <mrow data-mjx-texclass="ORD">
      <mrow data-mjx-texclass="ORD">
        <mi mathvariant="sans-serif">c</mi>
      </mrow>
    </mrow>
  </msubsup>
  <msup>
    <mrow data-mjx-texclass="CLOSE">
      <mo minsize="2.047em" maxsize="2.047em">)</mo>
    </mrow>
    <mrow data-mjx-texclass="ORD">
      <mstyle scriptlevel="0">
        <mspace width="-0.167em"></mspace>
      </mstyle>
      <mstyle scriptlevel="0">
        <mspace width="-0.167em"></mspace>
      </mstyle>
      <mrow data-mjx-texclass="ORD">
        <mi mathvariant="sans-serif">c</mi>
      </mrow>
    </mrow>
  </msup>
</math>

The major difference is the usage of a wrapping msup element

This would be a "corrected" variant of MathJax, which displays correctly in Chrome:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
    <msup>
        <mrow data-mjx-texclass="OPEN">
            <mo minsize="2.047em" maxsize="2.047em">(</mo>

            <msubsup>
                <mi>A</mi>
                <mi>n</mi>
                <mrow data-mjx-texclass="ORD">
                    <mrow data-mjx-texclass="ORD">
                        <mi mathvariant="sans-serif">c</mi>
                    </mrow>
                </mrow>
            </msubsup>
            <mrow data-mjx-texclass="CLOSE">
                <mo minsize="2.047em" maxsize="2.047em">)</mo>
            </mrow>
        </mrow>

        <mrow data-mjx-texclass="ORD">
            <mstyle scriptlevel="0">
                <mspace width="-0.167em"></mspace>
            </mstyle>
            <mstyle scriptlevel="0">
                <mspace width="-0.167em"></mspace>
            </mstyle>
            <mrow data-mjx-texclass="ORD">
                <mi mathvariant="sans-serif">c</mi>
            </mrow>
        </mrow>
    </msup>
</math>

The major difference is the usage of a wrapping msup element

Screenshot from 2023-12-04 14-54-47.png (537×604 px, 81 KB)

Solving this problem for Chrome in the Way LaTeXML does, requires an adaption of the grammar. The encapsulating brackets including the superscript have to be recognized with one item.

I guess it is a grammar bug, I'll investigate and create new ticket, as this is a whole new can of worms. At is first glance I t seems that the grammar only nows left as left left function but not bigl.

It's a grammar error, indeed.

physikerwelt@a1 texvcjs % ./bin/texvcjs '\bigl( a'
+{\bigl (}a
physikerwelt@a1 texvcjs % ./bin/texvcjs '\big( a' 
+{\big (}a
physikerwelt@a1 texvcjs % ./bin/texvcjs '\left( a'
S

Wow https://gerrit.wikimedia.org/r/c/mediawiki/services/texvcjs/+/980006 suggests that there are cases in Wikipedia where there exists \bigl without corresponding right element. I suggest we only change it in wikitexvc, otherwise we will see pages with syntax errors immediately.

Physikerwelt lowered the priority of this task from High to Medium.Dec 5 2023, 5:36 AM

After careful investigation, there are high chances that this is a chrome bug. It is displayed correctly in Firefox and the overall mrow structure can not be changed without applying guessing and heuristics.

The original bug was fixed. The new problem will be investigated in T352946.