MathML in SVG in MathML #896
Comments
|
It is most likely due to the fact that MathJax doesn't expect the If you can supply an example XHTML file, I'll take a look and see if I can give you any work-arounds. |
|
Here's a real-life example (produced by Maruku(+itex2MML)+SVG-Edit). |
|
{unrelated to mathjax's current implementation really but...) Note the default rendering of a semantics with only annotations is It worked accidentally in native firefox due to the simplistic the mathml3 dtd/RNG clarifies that there should be an expression being annotated The recommended way to embed svg in mathml in html5 is .... metxt allowing arbitrary html+svg as content (which also isn't David |
Well, the current method does work, in both Mozilla and MathJax, provided you don't nest Let's solve one problem at a time.
Can |
|
(Quite accidentally, the MathJax rendering of the above example actually isn't too bad -- despite the nested MathML. I can, however, certainly produce examples where the MathJax rendering is awful.) |
|
On 21 August 2014 22:20, Jacques Distler notifications@github.com wrote:
yes but I think it's relying on non standard rendering which may get fixed.
|
|
Changing itex2MML's output from to is a trivial change which (as you suspect) works just fine in Firefox. But it makes the MathJax rendering even worse. I'm reluctant to make itex2MML's output more spec-compliant if the only visible effect for the end-user is to (further) break MathJax. |
|
On 21 August 2014 23:45, Jacques Distler notifications@github.com wrote:
But if MathJax was going to change anyway, fixing the valid version rather David |
|
I really think these are two separate issues
For the record, the current status (as best as my testing can discern):
If you want to file a bug about SVG in |
Apropos of that, I'll point out that specifying that
is invalid MathML is logically distinct from specifying what sort of error-handling a User-Agent should engage in, when it encounters such a snippet of invalid MathML. The MathML3 Spec doesn't specify what the error-handling should be. And it is arguable that "attempt to render the first child, anyway" is a reasonable choice. Certainly, that's what Firefox and MathJax have done. If you were to go about specifying error-handling in a future version of the MathML Spec, it might not be an unreasonable idea to "pave the cowpaths" and codify that choice in the Spec. |
|
On 22 August 2014 03:24, Jacques Distler notifications@github.com wrote:
That said, a specific renderer can use an annotation to affect (or If you have stripping the semantics produces the invalid 2 some produces some svg2 which is valid So coming back to this mathjax github, what I'd like to see is a mathjax David |
Needless to say, renders nothing, in either Firefox or MathJax. So that's not going to happen. is a hack (valid MathML2, invalid MathML3). But it's a hack that works. Embellishing it, so as to make it valid MathML3 does not make it any less of a hack. The MathML3 Spec does not specify how such a snippet of invalid MathML should be rendered. You have one interpretation; Firefox and MathJax have another (IMHO, equally-valid) interpretation. Changing how they render to match your interpretation would break existing documents. So I don't think that is ever going to happen (nor should it). Changing how they render seems pointless, as no one (or, at least, not itex2MML) is going to produce that, and the MathML3 Spec indicates that the default rendering is blank, which is what they currently do. As I said, I will happily change itex2MML to output instead of if and when MathJax supports SVG-in- P.S.: If you want to discuss itex2MML's (mis)behaviour, then a better place to do that would be here, rather than on MathJax's bug tracker. |
|
There is already an open issue tracker for handling HTML tags in |
|
Getting back to MathML-in-SVG-in-MathML, would it be useful for me to post a testcase where the MathJax rendering is bad? For the one I posted above, the MathJax rendering turns out (accidentally, I think) to be quite good. |
|
I haven't had a chance to look at your current example yet. What would help is an actual complete XHTML page that contains the example (as sometimes the setup of the page is an issue). If you want to do one that renders poorly, that is fine as well. |
|
I just took a quick look at the example, and agree that it looks pretty good. The MathML that is inside the SVG is not being handled by MathJax, however; it is the native MathML renderer of the browser that is handling that. That is probably why it sometimes looks good and sometimes doesn't (as the native MathML renderer might not be able to handle some of the MathML, at least not in the same way that MathJax itself would). |
D'Oh! I should have thought of that. Looking at the same example in Chrome (no native MathML support) reveals that the inner
So then this test-case is perfect, as-is. What I'm requesting is that MathJax take over rendering the inner |
Yes, I understand. This will probably have to wait until the HTML-in- In the meantime, I'm wondering if calling MathJax's Typeset function as second time would pick up the MathML within the SVG? I haven't tried it, but I think it should. |
|
Just tried it, and yes, it does typeset the MathML in the SVG. But the width and height given in the |
Forgive the stupid question, but how do you do that? I thought it would be but that doesn't seem to have any effect.
(Correctly) setting the width and height of the |
Yes, that should work, but leaving off the element should also work. That is, provided you have the mml2jax extension loaded (I initially didn't, and that did cause me some confusion). On the other hand, I tried it in an HTML document, not an XHTML one, and there may be additional problems there. XHTML is more finicky about the namespaces, and it might be that MathJax's getElementsByTagNameNS() calls aren't finding the nested tags. |
|
On 22 August 2014 14:53, Jacques Distler notifications@github.com wrote:
Nothing is the expected default rendering for an empty mrow.
Compatibility concerns may force existing sytsems to support this use
As I say it is far clearer than annotating nothing . Of course if possible,
David |
That's not how the Web works. New renderers need to support existing documents. Existing documents use so new renderers will support this. New documents should (eventually) use to embed SVG in MathML. I am quite confident that they will (at least, those generated by itex2MML). As to how renderers should handle strikes me as an angels-dancing-on-the-head-of-a-pin kind of question. Existing documents don't use that particular construct, and I find it highly unlikely that future documents will either.
|
|
On 22 August 2014 18:58, Jacques Distler notifications@github.com wrote:
many existing renderers will treat that as implied by the spec and render
That's more natural markup if you only target svg capable systems, using
As I say above this is the most natural error recovery for the invalid use
|
Here's what I did (which works in XHTML; I'll worry about HTML later): The MathML-in-SVG-in-MathML does, indeed get rendered. But it also gets displaced relative to the parent
So, right now, this doesn't look like a very satisfactory solution. |
To see what I mean, it's helpful to add a border around the |
MathJax failed to parse the 'inner' MathML, which led to bad rendering. This fixes the problem in Safari and ameliorates it in Chrome. See mathjax/MathJax#896 for a discussion.
MathJax failed to parse the 'inner' MathML, which led to bad rendering. This fixes the problem in Safari and ameliorates it in Chrome. See mathjax/MathJax#896 for a discussion.
|
Wow. This has markedly regressed in MathJax 2.5. |
|
FWIW, the SVG Renderer is much better than the others. |
|
Is there any way to get this test-case to render under MathJax 2.5? It rendered somewhere between acceptably and poorly (depending on the browser) under MathJax 2.4. But it doesn't render at all under 2.5, in any of the browsers I have tested. |
|
PS, there is a way to get it to render with current v2.5.1: set the HTML-CSS |
Update to MathJax 2.5.1. Implement fix per mathjax/MathJax#896 (comment)
|
Cool! Thanks. |
Background:
itex has an
svgenvironment which allows the user to embed SVG figures in equations:$ ... \begin{svg} ... SVG goes here ... \end{svg} ... $
There is an extension for SVG-Edit, which allows the user to embed MathML in an SVG figure.
MathJax seems to work fine if you use one or the other of these mechanisms. That is, it seems to handle SVG-in-MathML and MathML-in-SVG (both inside an (X)HTML host document).
But if you try to use both mechanisms (creating, say, MathML-in-SVG-in-MathML), MathJax craps out, and renders the result poorly, if at all.
Is this an architectural limitation that we should just learn to live with, or is it a bug that could be fixed?
I can assure you that there are good use-cases for MathML-in-SVG-in-MathML. So it would be nice if MathJax supported it.
I can supply a test case, if needed.
The text was updated successfully, but these errors were encountered: