Closed Bug 508120 Opened 10 years ago Closed 8 years ago
Bad line breaks within a mathematical expression
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/2009070811 Ubuntu/9.04 (jaunty) Firefox/3.0.12 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/2009070811 Ubuntu/9.04 (jaunty) Firefox/3.0.12 Firefox has nonstandard rules for choosing line breaks within a mathematical expression. For example, in the expression <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline" ><mi >K</mi><mo class="MathClass-open">(</mo><mo class="MathClass-open">(</mo><msub><mrow ><mi >X</mi></mrow><mrow ><mn>1</mn></mrow></msub ><mo class="MathClass-punc">,</mo><mo class="MathClass-op">…</mo><mo class="MathClass-punc">,</mo><msub><mrow ><mi >X</mi></mrow><mrow ><mi >n</mi></mrow></msub ><mo class="MathClass-close">)</mo><mo class="MathClass-close">)</mo></math> it will allow a line break before the two closing parentheses. This looks terrible and is contrary to (say) TeX's rules for breaking inline math. (Screenshot available on request.) Reproducible: Always
Component: General → MathML
Product: Firefox → Core
QA Contact: general → mathml
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
Summary: firefox mathml renderer chooses line breaks poorly → Bad line breaks within a mathematical expression
Version: unspecified → Trunk
> I would emphasize that the desired solution to this is _not_ to > add additional tags in the mathml such as nobreak. Mathml is supposed > to describe the math content, not how it is laid out. It is the > browser's job to render it correctly. I assume this is possible in > the cases above, because TeX is perfectly capable of choosing the > correct breaks in (say) $(x+y)+z=x+(y+z)$ (with much less verbosity). I haven't really studied this yet, but here is what has been introduced in MathML3: http://www.w3.org/TR/MathML3/chapter3.html#presm.linebreaking
Thanks for clarifying the difference between these two bug reports. Let me say a few things based on my experience typesetting papers in TeX for PJM. The vast majority of the time, TeX makes the correct call: it allows line breaks just after binary operators like + and \times, and after relational operators like "=". It doesn't allow breaks after commas or open parentheses. All of this information is encoded in mathml (mathopen, mathbin etc), so it should be fully possible to replicate TeX's algorthm. That is, unless, as mentioned elsewhere, inline mathml and surrounding text is dealt with in completely separate parts of the code. There are cases when one wishes explicitly disallow a line break, by using \nobreak after (say) +, usually because we'd prefer to break after something higher in the expression's hierarchy. For example a(x+y)=(x+y)a, should break, if at all, after the =, not the pluses. But enforcing additional constraints is a secondary problem: Just like TeX, a good mathml renderer should aim to get the line breaks mostly right the first time. One shouldn't have to manually specify nobreak where there should never be breaks in the first place.
The solution to the problem here is essentially to implement MathML 3 linebreaking. So I resolve this bug as duplicate.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: mathml-linebreaking
You need to log in before you can comment on or make changes to this bug.