Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spacing/sizing issues in "cases" environment #485

Closed
pkra opened this issue May 28, 2013 · 12 comments

Comments

Projects
None yet
3 participants
@pkra
Copy link
Member

commented May 28, 2013

The following doesn't seem to render correctly. LaTeX itself shrinks the fraction.

$$ f(x)=
\begin{cases}
\frac{1}{n} & \mbox{if } x>0 \\
0 & \mbox{else}
\end{cases}$$

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

@dpvc

This comment has been minimized.

Copy link
Member

commented May 29, 2013

The issue485 branch of my fork of MathJax includes a fix for this.

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented May 30, 2013

It looks like you've left some debug logging in the source.

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented May 30, 2013

Adding QA unit test wanted, just to remember that I must update LaTeXToMathML tests that rely on the cases construction (around 25).

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2013

=> Ready For Release

IIRC, this changes the reference of a lot of tests that use "cases" directly but also those that use it indirectly (like other environments based on cases). I hope this is what we want. If so, I'll update the references.

@dpvc

This comment has been minimized.

Copy link
Member

commented Jun 12, 2013

None of the other environments currently use cases, so I think it will be OK. This makes cases conform to the TeX usage, so I do think it is what we want. We might want to check the other array environments to see if similar changes are needed there.

Thanks for fixing the debugging call.

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2013

When I executed the LaTeXToMathML tests on 2013-05-30 with that branch, I got failure with subarray, substack, binom due to a change of displaystyle. However, they do not seem to use case so I'm not sure what happened. I'll try to run the tests again.

dpvc pushed a commit that referenced this issue Jul 31, 2013

@dpvc dpvc closed this Aug 2, 2013

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2013

Most failing LaTeXToMathML tests still have a useless explicit displaystyle="false".

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2013

We'll have to analyze more precisely why these explicit displaystyle="false" attribute now show up. But otherwise, I can just update the references.

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2013

So if I understand correctly, we added

     else if (style) {array.arraydef.displaystyle = false}

in the Array function of the input TeX. This is used for all Array environments, not just cases. Then in the native MathML output, NativeMMLattributes does not seem to compare with the default value but just to skip attributes that are "null". This means that displaystyle="false" will be generated.

Is this intended? Should we fix that in MathJax? Or should I update the test references?

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2013

@dpvc any idea?

@dpvc

This comment has been minimized.

Copy link
Member

commented Oct 11, 2013

My recollection is that this is as intended. The environments where inheriting the displaystyle from setting outside the environment, and that is not what it supposed to happen. (The environment is supposed to typeset the same regardless of the style outside.) At the time the macro runs, the MathML is not yet completely available, and you can't tell for sure what displaystyle is in effect, so it seemed best to set it explicitly. I suppose it could be filtered out later, but I don't really see the need.

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2013

OK, thanks. I'll just update the references.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.