enrichment of subnumcases changes visual rendering
pkra opened this issue · 12 comments
Using MathJax's cases extension, the stretchy brace in, e.g., \begin{subnumcases}{x} \tag{a} b \\ \tag{a} b \end{subnumcases} no longer stretches after enrichment.
I realize how hacky cases / empheq is but if you replace {x} with {\quad}, it's ok, so perhaps there's a way to salvage this.
Just fyi, I recently ran into this issue again, this time with numcases.
\begin{numcases}{\theta _{ij}(\rho )=} \tag{2.9}\cssId{upwind}{} \theta _{ij}^{U}(\rho )=\rho _{i}, \; \text{if}\; S_{j}>S_{i},&\\\tag{2.10}\cssId{Average}{} \theta _{ij}^{A}(\rho )=\frac{\rho _{i}+\rho _{j}}{2} &\\\tag{2.11}\cssId{Logrithm}{} \theta _{ij}^{L}(\rho )=\frac{\rho _{i}-\rho _{j}}{\log (\rho _{i})-\log (\rho _{j})}. &\\\end{numcases}
Looking at this a bit more closely, the problem is that the mstyle and mphantom content are outside the row that contains the brace. Maybe SRE could move such "non-semantic" elements following flat content inside the mrow it creates?
It's actually a problem with handling expressions coming out of empheq in general. And the real problem is that the LaTeX can not be expressed due to the limiting expressiveness in MathML. So it can only be hacked with bizarre table manipulations. (Did I already mention that one of my greatest regrets is the design decision to base SRE on MathML and not LaTeX???)
The issues_634 should contain a solution, which tries to capture the proper semantic of these types of expressions. It still needs cleanup, but if you find the time to do some testing with a range of expressions, that would be great.
Alternatively, if you can just send me a set of LaTeX sample expressions, I can easily turn them into semantic tree visualisations we can browse for correctness.
It's actually a problem with handling expressions coming out of empheq in general.
Right, I was trying to find a point that wasn't directly tied to it.
And the real problem is that the LaTeX can not be expressed due to the limiting expressiveness in MathML.
As much as I agree in general, it wouldn't be as bad if MathJax could do row and column spanning.
And the real problem is that the LaTeX can not be expressed due to the limiting expressiveness in MathML.
As much as I agree in general, it wouldn't be as bad if MathJax could do row and column spanning.
I should probably agree. But it would still leave a considerably "semantic reconstruction problem".
Can you send me those examples?
Can you send me those examples?
The first two comments have the examples I have.
Can you send me those examples?
The first two comments have the examples I have.
You don't have more in your dataset?
You don't have more in your dataset?
I do have more (though thankfully not many). But those don't cause any issues.
To follow up on the samples I sent, I looked at the results I was getting. The analysis / exploration works pretty well, I think. It just seems like the mphantom needs to be kept close to the content it's supposed to influence.
FYI: using 4.1.0-beta.2 (and mathjax v4-alpha) all of our examples appear fixed. Thank you!
This was fixed.