In looking at the CUBIC revision XML, I discovered that the SVG created by mathjax isn't perfectly suited to use in an RFC.
For the most part, this is down to the use of <use> elements, which are allocated id attributes that collide. Because SVG is inlined in the final HTML, the resulting HTML has a bunch of duplicate ID elements.
It seems like this tex2svg uses svgo to optimize the SVG it produces, but this doesn't extend to configuring it very much. We would probably benefit from using the prefixIds plugin, with the prefix being set based on a simple counter or something like that. The cleanupIDs might then reduce the image size.
Note that I was initially confused by the existence of this tex2svg project, which integrates svgo and provides options to control ID generation. But it doesn't provide a command-line utility, where mathjax-node-cli does.
Not all SVG images need this sort of optimization, but it seems like many could benefit.
In looking at the CUBIC revision XML, I discovered that the SVG created by mathjax isn't perfectly suited to use in an RFC.
For the most part, this is down to the use of
<use>
elements, which are allocatedid
attributes that collide. Because SVG is inlined in the final HTML, the resulting HTML has a bunch of duplicate ID elements.It seems like this
tex2svg
uses svgo to optimize the SVG it produces, but this doesn't extend to configuring it very much. We would probably benefit from using the prefixIds plugin, with the prefix being set based on a simple counter or something like that. The cleanupIDs might then reduce the image size.Note that I was initially confused by the existence of this
tex2svg
project, which integrates svgo and provides options to control ID generation. But it doesn't provide a command-line utility, where mathjax-node-cli does.Not all SVG images need this sort of optimization, but it seems like many could benefit.