Allow change of svg-to-PNG converter [was: Why not use "svg2png" , pure node without JAVA depend]

[everyx]

I hava some trouble in my vps about java environment configuration, and i find the node package "svg2png" and modify some code, i'll submit a pull request about this for a review.

sorry for my poor english.

[pkra]

The reason is that svg2png depends on PhantomJS and one of core requirements of MathJax-node was to get away from PhantomJS.

AFAIK, there is no pure JS svg2png converter out there. In our experience, Batik performance is better and more stable compared to PhantomJS (but that might be worth re-evaluating).

In any case, we should make it easier to switch converters. I'm not sure how the others feel but simply dropping Batik does not seem ideal to me at this point.

[everyx]

@pkra Thanks for you reply, close this issue.

[pkra]

Let me re-open and rename this. I definitely want us to abstract the PNG conversion; it should be as converter independent as possible. Since svg2png is authord by Domenic it would be a good model to follow for an NPM bridge to Batik.

[everyx]

👍

[pkra]

See also #65 (comment)

[SamyPesse]

👍 svgexport works great

[pkra]

@SamyPesse see my earlier comment regarding our original requirements.

[physikerwelt]

I agree that both solutions java and phantomjs are not ideal.
I think one of svgexports advantages is that no file needs to be written on "disk".
A node only solution would be awesome, but I guess it's a very challanging tasks, which can not be done a few after work sessions.
(ping @gwicke)

[pkra]

Some recent observations

• Over on the Wikimedia fork, there's a PR building on rsvg, Use librsvg for PNG rendering wikimedia/mediawiki-services-mathjax-node#16. Biggest immediate question from my end was: is that a bad dependency?
• But I just noticed that jsdom now handles canvas via https://www.npmjs.com/package/canvas. That seem to me to be the most natural approach ("universal JS" etc) despite having similarly bad installation requirements on node.

[pkra]

Note: I haven't actually tested if the canvas solution for jsdom would be sufficient.

[gwicke]

Some quick notes from my end:

• We use (a patched version of) rsvg for SVG thumbnailing in production. It is working okay, but lacks support for some features like HTML-in-SVG. There is some RSVG-related discussion on https://phabricator.wikimedia.org/T40010.
• Latest phantomjs (2.0) is based on relatively recent Blink, so likely has similar SVG support as current Chrome. However, binding support for node is mostly still using phantomjs 1.9. We don't currently use phantomjs in production, but might reconsider it for tasks like HTML-to-PDF in the future.
• I can't vouch for the quality or performance of the jsdom canvas solution. The dependencies are manageable (we have a few services using it).

[d00rman]

My 2 cents here would be to develop an extension point for MathJax so that people can hook up and test whatever suits them better, while still having a sane default. What is that sane default is arguable, ofc, but the way I see it is that it's sane if it doesn't introduce many (especially binary) external dependencies regardless of the performance penalties or feature set. These could be then mitigated on a case-per-case basis with specialised converters.

[pkra]

Thanks for the feedback, @gwicke @d00rman -- much appreciated!

[pkra]

See #174 for a first attempt.

[pkra]

Closed in favor of #205.