# The double-bar delimiter does not stretch in MathJax v2.2 #475

Closed
opened this issue May 20, 2013 · 18 comments

Projects
None yet
4 participants

### robjohn commented May 20, 2013

 This does not appear in MathJax v2.1. In the following code, the \left|...\right| delimiters do not stretch as the \left{...\right} do $$\begin{array}{cc} | \frac{a}{b} | & \left| \frac{a}{b} \right| \ { \frac{a}{b} } & \left{ \frac{a}{b} \right} \end{array}$$ This bug was noted on math.stackexchange: http://meta.math.stackexchange.com/q/9647 This problem also appears with \lVert \rVert \lvert and \rvert delimiters.
Member

### dpvc commented May 20, 2013

 This is due to a change in how \left...\right is handled in v2.2. The mfrenced() method of the TeX input jax need to force stretchy to true (as was done in the original mfenced implementation). I thought I had done that, but apparently missed it.
Member

### dpvc commented May 21, 2013

 @pkra, do you think this should be a hot-fix on the v2.2-latest branch? That would get it out quickly. It is a regression due to changes in v2.2, so I think that would be justified. It is a simple fix.

### dpvc pushed a commit to dpvc/MathJax that referenced this issue May 21, 2013

 Make sure mfenced delimiters are stretchy. Resolves issue mathjax#475. 
 a147a9a 
Member

### dpvc commented May 21, 2013

 The issue475 branch of my fork of MathJax includes the fix.
Contributor

### fred-wang commented May 22, 2013

 The MathML spec says that mfenced is equivalent to using  and , so the mfenced function was correct. For operators like the double bars, I would expect that they are marked stretchy="true" in the MathML operator dictionary and so MathJax should know they should stretch. I'm not sure what \left...\right previously did, but it seems that what we want for these commands is to force stretchy="true", so it's not really equivalent as the mfenced element. I guess that's the same for other commands using the mfenced function. So perhaps the name mfenced is not quite correct.
Contributor

### fred-wang commented May 22, 2013

 So that seems specific to the double bar which is U+2225 "parallel to" (neither stretchy nor fence in the operator dictionary ; infix). I don't see the bug that was reported on the mailing list (using either TeX or MathML input modes). U+2016 "double vertical line" (fence and stretchy, prefix/postfix) seems more appropriate in the current context. I think there was a similar discussion in Gecko and the idea was to have prefix/postfix forms for "parallel to" and these forms would be fence and stretchy. Then the heuristics rules to determine the operator form should solve the problem (not sure it works very well in Gecko atm) Anyway, I think what we want for \left...\right (and other similar TeX constructions using the mfence function) is to force stretchy="true" and so mfenced or its equivalent is not appropriate. So we can take Davide's fix but a different name/description for the function seems necessary to avoid confusions.
Contributor

### fred-wang commented May 22, 2013

 So if we agree, I'll write a tree== reftest ensuring that \left| \frac x y \right| is equivalent to the mrow construction with stretchy="true" attributes. Or perhaps a visual reftest ensuring that that the | bars stretch.

Closed

Member

### dpvc commented May 22, 2013

 I'm fine with changing the name of the routine. How about just fenced()? You are also right that a change from U+2225 to U+2016 would probably be a good idea. (The original mappings were taken from a latex-to-unicode list that I found; this was early on before I knew as much about unicode as I do now.) We may also want to look at when U+2223 is used and use U+007C instead in some cases. But I think those changes belong in the next version, not in a hot-fix, so I'm going to leave them off for now and open a new issue for them.
Contributor

### fred-wang commented May 22, 2013

 Yes I think fenced is fine + removing the comment about the fact that it generates an mrow equivalent to mfenced (and/or explain the difference). I agree that the mapping or dictionary should be considered later (perhaps some people use | to mean "parallel to", so that may need more care?).

### dpvc pushed a commit to dpvc/MathJax that referenced this issue May 22, 2013

 Rename mfenced() to fenced() since the mrow is not really equivalent … 
…(the mo's are forced to have stretchy=true). Resolves Fred's concerns for issue mathjax#475 for now.
 4e01303 
Member

### dpvc commented May 22, 2013

 OK, I've renamed the routine as discussed above. See the differences for details.
Member

### dpvc commented May 22, 2013

 I think the tree reftest should be sufficient. Though I suppose a test for whether specific delimiters do stretch might be useful. Something that checks if the stretched version is hidden behind a red square that is too short to cover the stretched one but big enough to cover the unstretched one.
Contributor

### dpvc pushed a commit that referenced this issue May 22, 2013

 Merge remote-tracking branch 'dpvc/issue475' into v2.2-latest 
Resolves issue #475
 b9863ce 
Member

### dpvc commented May 22, 2013

 => Merged
Contributor

### fred-wang commented May 24, 2013

 LaTeXToMathML/issue475.html => In testsuite
Member

### pkra commented May 24, 2013

 Can be closed now?
Member

### dpvc commented May 24, 2013

 I left it open because Fred had it marked for needing a reftest, but now that that is ready, we can close it.

Contributor

### fred-wang commented May 30, 2013

 I'm marking this Unit test wanted since it seems that some LaTeXToMathML references must be updated after this change.
Contributor

Contributor

### fred-wang commented Jun 13, 2013

 Tests updated.