SVG output, as offered by MathJax, would be great to have. Applications include formulas in diagrams, for example.
@jbaayen there's been some work to render to canvas, see https://github.com/Khan/KaTeX/pull/251. Rendering to other targets is not a huge priority. We have discussed providing some sort of intermediate representation to make this easier.
@jbaayen: I'm developing SVG graphs, and the approach I'm using when including formulas is to overlay the SVG with HTML elements. There are some examples on this page:
http://www.intmath.com/exponential-logarithmic-functions/calculating-e.php
It suits my purposes.
@kevinbarabash @mbourne, these sound like steps in the right direction!
We're looking at an out-of-browser application though, where SVG is the graphics format. Given an intermediate representation, we may be able to develop the SVG output ourselves.
I'd just like to add that foreignObject is horrendously broken in WebKit and blink. Positioning is completely off.
If anyone decides to implement SVG output, it would be nice to do it with <text> tags instead of outlined glyphs. This way it would be much faster to load. MathJax uses outlined glyphs.
@pnsaevik: If one were to use <text>, one would have to make sure that the fonts used are the ones shipped with KaTeX. In a browser, it might suffice to use the same CSS file as for KaTeX. For stand-alone SVG, one might have to link to external resources or embed the fonts as data: URIs. And one would have to choose between WebFonts and SVG fonts. The latter don't support various features like hinting, but on the other hand SVG fonts are the only font the SVG 1.1 spec requires viewers to support. Not that it were actually supported in the wild, though.
@gagern Thanks for your comments. It would definitely have to rely on webfonts, just as regular KaTeX. And it would be for the use within browsers, coupled with the KaTeX CSS file. But then, one may argue that CSS is sufficient, and that SVG provides no extra advantage.
But then, one may argue that CSS is sufficient, and that SVG provides no extra advantage.
I realize this is probably not currently high on any priority list, but just by way of documenting use-cases: Bokeh just added an SVG output option for plots (a long requested feature). Users can also render KaTeX labels on plots with an extension, but since these are separate DOM elements, they are missing from the SVG export. We use canvas2svg to convert the plot canvas to SVG, and presumably if KaTeX could generate SVG as well, we could find a way to merge things together. This would make users wanting to export Bokeh plots for inclusion in scientific publications very extremely happy.
@mbourne Are you using foreignObject? how are you referring the position and element in SVG?
@jpatel3 No, I'm not using foreignObject. For the particular example I linked to above, I'm using a PHP -> SVG library.
My text creating function has the following parameters:
function text($pt,$str,$pos,$class,$attrs,$brdParams) {...}
where $pt is something like [1, 3] and $str is either plain text (which creates an ordinary SVG
$htmlTxt = "<div class=\"$class svgHtml\" style=\"top:".round($height - $pt[1]*$yunitlength-$oy-$padding)."px;left:".round($pt[0]*$xunitlength+$ox)."px\">$str</div>";
As the whole thing is being created server-side, any KaTeX sitting on top of the SVG is processed along with the rest of the page on page load.
Most helpful comment
I realize this is probably not currently high on any priority list, but just by way of documenting use-cases: Bokeh just added an SVG output option for plots (a long requested feature). Users can also render KaTeX labels on plots with an extension, but since these are separate DOM elements, they are missing from the SVG export. We use
canvas2svgto convert the plot canvas to SVG, and presumably if KaTeX could generate SVG as well, we could find a way to merge things together. This would make users wanting to export Bokeh plots for inclusion in scientific publications very extremely happy.