move PNG generation out of mathjax-node

[pkra]

As per F2F, the PNG generation will be moved out of mathjax-node; there will be alternative modules to use.

Cf. the discussion in #174; see also #191.

[pkra]

From F2F: we will be adding width and height to the returned data (not just as an option).

[pkra]

While working on this, I've been wondering about structure of mj-single and the SVG modifications.

• SVG modifications in mj-single
  • add svg namespace https://github.com/mathjax/MathJax-node/blob/master/lib/mj-single.js#L570
  • prettify and add xlink https://github.com/mathjax/MathJax-node/blob/master/lib/mj-single.js#L588-L593
  • make a file version https://github.com/mathjax/MathJax-node/blob/master/lib/mj-single.js#L594-L601
  • create an img tag https://github.com/mathjax/MathJax-node/blob/master/lib/mj-single.js#L608-L618

The last two seem like they should be dropped alongside the PNG (since they only come into play there). Any thoughts?

I'm also wondering if we should expose both the "HTML5" svg data alongside the namespaced version. Would anyone benefit from having the "HTML5" svg data?

[pkra]

I'm also wondering if we should expose both the "HTML5" svg data alongside the namespaced version. Would anyone benefit from having the "HTML5" svg data?

Or perhaps we should have a more general "standalone (prefixed?)" option affecting both MathML and SVG (and perhaps even CommonHTML?) output. Or maybe I'm just overthinking this 😉

[dpvc]

The <img> tag is actually for an SVG file, not a PNG file, so the file version of the SVG is used for that as well as the PNG file. But perhaps you don't want to produce the SVG <img> tag any longer and want to push that to the surrounding tool.

One of the difficulties of pushing this off to the application is the copying of the style attributes from the <svg> to the <img> tag. If we are returning just a string for the svg (as we do now), then it is harder to get the style using string manipulation rather than DOM element's methods, and that is less reliable. But if we return the DOM element rather than a string, then that means the application is now responsible for prettying it up as we currently do.

One solution might be to provide service routines to do some of this so that the application can call them as needed.

[dpvc]

I'm also wondering if we should expose both the "HTML5" svg data alongside the namespaced version. Would anyone benefit from having the "HTML5" svg data?

I'm not sure I understand what you are suggesting. Can you be more clear about the difference you have in mind?

Or perhaps we should have a more general "standalone (prefixed?)" option affecting both MathML and SVG (and perhaps even CommonHTML?) output.

Again, I'm not clear on what you are suggesting. Can you give more details about what is included (and not included) in each form?

[pkra]

The tag is actually for an SVG file, not a PNG file, so the file version of the SVG is used for that as well as the PNG file.

Right.

But perhaps you don't want to produce the SVG <img> tag any longer and want to push that to the surrounding tool.

I think creating an image tag is something that's better done outside mathjax-node. As a developer, I would frequently want to modify the img tag (add e.g., classes, data-attributes, wrapping elements).

One of the difficulties of pushing this off to the application is the copying of the style attributes from the to the

Right. Which is why I add the dimensions and styles alongside the SVG in the result.

One solution might be to provide service routines to do some of this so that the application can call them as needed.

Right. As we discussed on the last F2F, maybe exposing the SVG as an (htmlparser2?) object is useful more generally.

I'm not sure I understand what you are suggesting. Can you be more clear about the difference you have in mind?

The SVG data before/after adding namespaces and xlink prefixes (and prettying).

Again, I'm not clear on what you are suggesting. Can you give more details about what is included (and not included) in each form?

I don't really want any of this as part of mathjax-node but for completeness: just like the current code makes the SVG usable as a standalone document, it could do the same for MathML and HTML.

[dpvc]

I think creating an image tag is something that's better done outside mathjax-node. As a developer, I would frequently want to modify the img tag (add e.g., classes, data-attributes, wrapping elements).

If course, if we returned a DOM element (like we are considering for the SVG element itself), it would be easy to do those things.

Which is why I add the dimensions and styles alongside the SVG in the result.

I had forgotten that you included the CSS text. Of course, if we return the SVG DOM element, then it is easy to get those values from the node itself, and so they may not need to be added to the result in that case.

The SVG data before/after adding namespaces and xlink prefixes (and prettying).

I'm more and inclined to think that the DOM node is the thing that should be returned. Then the outer application can serialize it as they want, and we can provide functions to call that do the prettifying and xlink adjustments if we want.

just like the current code makes the SVG usable as a standalone document, it could do the same for MathML and HTML.

Do you mean adding the <?xml version="1.0" standalone="no"?> and <!DOCTYPE ...> to the top of the file? And for the HTML output, adding an <html>, <head>, and <body> tags (with the CSS in a <style> element in the head)?

Again, it seems like service routines to do this given a result object might be the way, rather than returning two forms based on more flags.

[pkra]

I'm more and inclined to think that the DOM node is the thing that should be returned.

Me too but I don't know what would count as a good DOM object in nodejs land. Of course for now we're stuck with jsdom (which I think means parse5).

We should research a few libraries, I guess (also for MathJax v3). Good starting points might be parse5 (jsdom) but also htmlparser2 (e.g., used by cheerio).

The only downside I can see is that an application using mathjax-node would need a minimal amount of understanding over the relevant structure (e.g., so as to serialize it).

Do you mean adding [...]

Pretty much.

[...] it seems like service routines to do this given a result object might be the wa

I second that.