User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/416.12 (KHTML, like Gecko) Safari/416.13 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 When I try to explicitly horizontally stretch an arrow like this: <mo stretchy="true" minsize="5em" maxsize="5em">→</mo> the arrow doesn't stretch. However, if I make this <mo> element a sub-element of something like <mfrac> or <mover>, e.g. <mover> <mi>x</mi> <mo stretchy="true" minsize="5em" maxsize="5em">→</mo> </mover> then the arrow stretches correctly. Similar behaviour for &DoubleRightArrow, etc. Reproducible: Always Steps to Reproduce: 1. View a MathML object containing only the operator <mo stretchy="true" minsize="5em" maxsize="5em">→</mo> as above. 2. 3. Actual Results: The arrow doesn't stretch. Expected Results: The arrow should stretch. I wonder if this is related to bug 236963.
Created attachment 235688 [details] testcase showing problem Testcase attached. It appears that displaystyle=false is necessary to trigger the bug. Apologies for not noting this before.
Created attachment 236379 [details] [diff] [review] patch It is not really related to displaystyle. It has more to do with the directionality of the stretching. If you say <mstyle> <mrow> <!-- something really big here --> </mrow> <mo>→</mo> <mo>↑</mo> </mstyle> Even though both arrows are intrinsically stretchy, the surrounding <mstyle> will only make the ↑ to stretch. There is not enough context to stretch the → unambiguously. Stretching it (by default) would be inappropriate/unexpected by users. And the situtation is reverse if you have <munderover> instead of <mstyle>. The → will stretch while the ↑ will stay put... However, this bug shows a case where the minsize attribute should override the directionality coming from the parent to allow any char to stretch in its natural direction to span the requested minsize. That's what the patch does.
Comment on attachment 236379 [details] [diff] [review] patch I need to iterate a bit to be more careful with the stretched size. When the direction is different from what was requested, we have to take: max(min(CHARSIZE,maxsize),minsize) instead of: max(min(CONTAINERSIZE,maxsize),minsize) (i.e., the container ceases to play a role since the direction that it asked isn't been honored.) I will get back to this later.
Created attachment 236627 [details] [diff] [review] iteration per above comment