Last Comment Bug 236963 - (stretch-mtd-math) Stretchy characters don't stretch in mtd/math elements
(stretch-mtd-math)
: Stretchy characters don't stretch in mtd/math elements
Status: NEW
:
Product: Core
Classification: Components
Component: MathML (show other bugs)
: Trunk
: All All
: P4 normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Mentors:
: 428906 585347 (view as bug list)
Depends on: mathml-linebreaking
Blocks: mathml-2 557086 mathml-in-mathjax 958947
  Show dependency treegraph
 
Reported: 2004-03-09 18:13 PST by Gérard Milmeister
Modified: 2015-01-07 02:31 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
style attributes not respected (1.25 KB, image/png)
2004-03-10 09:11 PST, Gérard Milmeister
no flags Details
screenshot with a stock mozilla buidl (4.89 KB, image/gif)
2004-03-10 17:00 PST, rbs
no flags Details
testcase for stretching characters in math tags (6.21 KB, text/xml)
2004-08-04 15:56 PDT, steve.swanson
no flags Details
Testcase for mtd (1.30 KB, text/html)
2012-11-30 05:04 PST, Frédéric Wang (:fredw)
no flags Details
Testcase (1.56 KB, text/html)
2014-10-04 02:05 PDT, Frédéric Wang (:fredw)
no flags Details
Testcase (2.17 KB, text/html)
2014-10-04 02:07 PDT, Frédéric Wang (:fredw)
no flags Details

Description Gérard Milmeister 2004-03-09 18:13:29 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 Galeon/1.3.13
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 Galeon/1.3.13

Style attributes like fontfamily, fontweight or color are not respected.
On the other fontstyle="normal" is respected, but
mathvariant="normal" is not, neither is mathvariant="fraktur" and
mathvariant="script", see 

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/mimathvariant13.xml

Stretchy arrows don't work in:
http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtableBsize2.xml



Reproducible: Always
Steps to Reproduce:
Comment 1 rbs 2004-03-09 18:43:39 PST
>Style attributes like fontfamily, fontweight or color are not respected.

These attributes are supported. It is only the mathvariant attribute that
doesn't work yet -- and that's bug 114365.

> Stretchy arrows don't stretch in table cells.
That's a separate issue. The usual practice is to report one issue per bug.

I am mutating this bug because there is nothing yet in bugzilla about strecthy
characters in math table cells. 

This bug is now meant for the problem that "stretchy characters don't stretch in
mtable cells".
Comment 2 Gérard Milmeister 2004-03-10 09:10:45 PST
Sorry about mixing issues.
However I beg to disagree about the style attributes.
The attached image shows the rendering of the following:

      <math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
	<mi fontfamily="Courier">A</mi>
	<mi fontstyle="normal">A</mi>
	<mi mathstyle="normal">A</mi>
	<mi color="blue">A</mi>
	<mi mathcolor="blue">A</mi>
	<mi fontweight="bold">A</mi>
	<mi mathvariant="bold">A</mi>
      </math>
Comment 3 Gérard Milmeister 2004-03-10 09:11:31 PST
Created attachment 143511 [details]
style attributes not respected
Comment 4 rbs 2004-03-10 17:00:28 PST
Created attachment 143558 [details]
screenshot with a stock mozilla buidl

Works for me on Win2K. Not sure why there should be any difference with the
Galeon build. Note: |mathstyle| is an invalid attribute and is ignored. Also
note that mathvariant="bold" resets everything except the font-size, i.e., in
the terminlogy of CSS, mathvariant="bold" is equivalent to style="font: medium
serif bold; font-size: inherit;" That's why there is a difference between
<mi fontweight="bold">A</mi> and <mi mathvariant="bold">A</mi>.
Comment 5 steve.swanson 2004-08-04 15:56:07 PDT
Created attachment 155215 [details]
testcase for stretching characters in math tags

Also, stretching doesn't happen in a <math> tag if there's no enclosing mrow. 
This is contrary to the MathML spec since a math tag acts as an implied mrow.

(I've known about this problem for a few years, but it was recently brought to
my attention again.  Kind of a pain for automatic generation of MathML:  is
<math> an implied mrow or not?

My guess is that the <math> tag generates a frame which is not a
nsMathMLContainerFrame, hence doesn't participate in the stretchy computation.

If this testcase/bug is cluttering up this bug, I'd be happy to make a new bug.
But this bug seemed a bit confused anyway.)
Comment 6 steve.swanson 2004-08-05 14:54:02 PDT
On further thought, it may be that the problem mentioned in Comment #5 is the 
same as bug 219873.  (math tag doesn't know its height)
Comment 7 David Harvey 2005-12-17 15:27:47 PST
Getting the discussion back to the original title "Stretchy characters don't stretch in mtable cells".

I have observed this also. For example, the following two blocks should look the same:

<mtable>
    <mtr>
        <mtd>
            <mrow>
                <mo stretchy="true">(</mo>
                <mfrac><mi>x</mi><mi>y</mi></mfrac>
                <mo stretchy="true">)</mo>
            </mrow>
        </mtd>
    </mtr>
</mtable>

and

<mtable>
    <mtr>
        <mtd>
             <mo stretchy="true">(</mo>
             <mfrac><mi>x</mi><mi>y</mi></mfrac>
             <mo stretchy="true">)</mo>
        </mtd>
    </mtr>
</mtable>

because the <mtd> should contain an implied <mrow>. However, they render differently (Firefox 1.5); the parentheses stretch in the first one but not in the second.
Comment 8 rbs 2006-09-01 16:02:09 PDT
Stretching in the case of table cells is complicated by the fact that it has to be resolved based on the height of the whole row (or the width of the whole column). For example, if you have:

<mtable>
    <mtr>
        <mtd>
             <mo>(</mo>
             <mfrac><mn>1</mn><mn>2</mn></mfrac>
        </mtd>
        <mtd>
             <mfrac>
                 <mfrac><mn>1</mn><mn>2</mn></mfrac>
                 <mfrac><mn>3</mn><mn>4</mn></mfrac>
             </mfrac>
             <mo>)</mo>
        </mtd>
    </mtr>
</mtable>

Then, the left paranthesis and the right parenthesis should stretch to the same height.

Picture the left/right/up/downarrows of a commutative diagram for example. They should stretch automatically if at least the minsizes of one vertical arrow and one horizontal are given. That is, the stretching will be passed on to the other arrows to make the whole thing look uniform.  That's why this bug is quite involved.
Comment 9 distler 2008-02-06 15:12:03 PST
I don't see why this bug, narrowly construed, is so "involved." If the Spec says: <math> (or <mtd> or whatever) has an implied <mrow>, then the behaviour should be the same whether one places an explicit <mrow> or one doesn't.

But the behaviour is not the same.

Which is a bug.
Comment 10 Karl Tomlinson (:karlt) 2008-02-12 18:29:08 PST
Details on stretching operators within tables are here:

http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.8.2
Comment 11 Karl Tomlinson (:karlt) 2009-07-16 19:23:10 PDT
The special rules for operator stretching in tables seem to only apply when the operator is the "sole direct sub-expression of an mtd element".

http://www.w3.org/TR/MathML3/chapter3.html#presm.inferredmrow implies that

<mtd>
  <mo>&stretchyoperator;</mo>
</mtd>

"is treated as if it were"

<mtd>
  <mrow>
    <mo>&stretchyoperator;</mo>
  </mrow>
</mtd>

which seems contradictory as the operator would no longer be a direct sub-expression.

I guess the intention is that we should read the inferred mrow statement backwards and treat the form with the explicit mrow in the same manner as is specified for the form with and inferred mrow.

The operators for parentheses in comment 8 are not sole direct sub-expressions, so they should only stretch to the height of the implied mrow within their individual mtd.
Comment 12 Frédéric Wang (:fredw) 2009-08-06 14:33:55 PDT
(In reply to comment #11)
> The special rules for operator stretching in tables seem to only apply when the
> operator is the "sole direct sub-expression of an mtd element".
> 
> http://www.w3.org/TR/MathML3/chapter3.html#presm.inferredmrow implies that
> 
> <mtd>
>   <mo>&stretchyoperator;</mo>
> </mtd>
> 
> "is treated as if it were"
> 
> <mtd>
>   <mrow>
>     <mo>&stretchyoperator;</mo>
>   </mrow>
> </mtd>
> 
> which seems contradictory as the operator would no longer be a direct
> sub-expression.
> 
> I guess the intention is that we should read the inferred mrow statement
> backwards and treat the form with the explicit mrow in the same manner as is
> specified for the form with and inferred mrow.
> 

	Actually, according to the section "inferred <mrow>s" the children are treated as a single mrow only "if the number of children is 0, or is more than 1". Hence the rule of the "sole direct sub-expression" still applies. Moreover it is also the case with the explicit mrow, according to the rule of the "<mrow> of one argument":

http://www.w3.org/TR/MathML3/chapter3.html#id.3.3.1.3.1
Comment 13 Frédéric Wang (:fredw) 2012-11-30 04:46:47 PST
*** Bug 428906 has been marked as a duplicate of this bug. ***
Comment 14 Frédéric Wang (:fredw) 2012-11-30 05:04:08 PST
Created attachment 687059 [details]
Testcase for mtd

Here is a testcase for mtd. It seems that MathJax uses mfenced.
Comment 15 Frédéric Wang (:fredw) 2012-11-30 05:11:01 PST
*** Bug 585347 has been marked as a duplicate of this bug. ***
Comment 16 Frédéric Wang (:fredw) 2012-12-02 11:28:35 PST
Making this blocking MathJax as I suggested the team to use <mrow>+<mo> instead of <mfenced>.
Comment 17 Frédéric Wang (:fredw) 2014-10-04 02:05:46 PDT
Created attachment 8499983 [details]
Testcase
Comment 18 Frédéric Wang (:fredw) 2014-10-04 02:07:26 PDT
Created attachment 8499985 [details]
Testcase

Note You need to log in before you can comment on or make changes to this bug.