Hello, Prince works nicely with KaTeX, but the spacing is still not perfect. For example, $A \in a$ renders too tight as compared to Chrome's result, as if the KaTeX-generated "mspace" spans are discarded.
Forum › Feature requests
Further improve support for KaTeX
mspace does render in Prince in at least one example I checked. Could you please post the xml that KaTeX generates for the above example?
When running simply ‘prince demo/katex.html’, I get the attached, spaced, rendering, which matches what I get from Firefox, and differs from both the prince.pdf and chrome.pdf from your demo.zip. Could you please give the full input and command line for reproducing, just so we're looking at the same thing?
Hi, the provided snippet is what you asked for, not an original HTML snippet. You should link to the KaTeX package in the HTML and enable JavaScript when processing it. Otherwise the math expression will be rendered twice, and the KaTeX-specific font won't be used, as shown in your katex.pdf. I'll upload a full example shortly after.
Hi, I come up with a self-contained minimal demo for you to try again. Just execute run.bat (on Windows) or run.sh (on Linux), and compare with Chrome's Save as PDF result. The provided KaTeX package is patched just a little from v0.16.4 to be compatible with Prince.
Thanks, and I'm sorry I wasn't clear in asking for "the xml that KaTeX generates for the above example". However, it looks as if what you sent at first might be helpful in diagnosing the problem: the first version renders with a spaced ‘∈’, while the second version (which has very different HTML: e.g. no mathml at all, and just a TeX expression to be processed by javascript) renders without spacing the ‘∈’. This suggests that the problem could be with the client-side javascript that converts the TeX.
The fact that the first version you posted did render well spaced also suggests a workaround of generating the MathML version in advance, and feeding Prince just the MathML without the javascript. This will also be quicker to render (assuming the initial generation of MathML can be put in a makefile or script).
For anyone wanting to look at non-minimized versions of demo2.html, try doing git clone 'https://github.com/KaTeX/KaTeX'
The fact that the first version you posted did render well spaced also suggests a workaround of generating the MathML version in advance, and feeding Prince just the MathML without the javascript. This will also be quicker to render (assuming the initial generation of MathML can be put in a makefile or script).
For anyone wanting to look at non-minimized versions of demo2.html, try doing git clone 'https://github.com/KaTeX/KaTeX'
Hi, thanks for your investigation! But the first version was a snippet of the DOM tree (e.g. from the Element panel of Chrome DevTools), not part of the original HTML tree. The DOM is what Prince sees after JavaScript is executed. Please try again and you'll get exactly the same result as mine. (To be sure, I downloaded both versions and performed a byte-for-byte comparison just now.)
Update: Here is a screenshot of the DOM tree for the second version, rendered in the Guest mode of Chrome 111.0.5563.147.
Update: Here is a screenshot of the DOM tree for the second version, rendered in the Guest mode of Chrome 111.0.5563.147.
Edited by yyang
Until someone looks into what part of the javascript isn't supported, here's a hack based on the workaround I mentioned, using wkhtmltopdf instead of interactive use of DevTools:
It should work for many other js libraries too. No doubt others have written more refined versions of the above.
If demo.html and its dependencies were available on a web server, then the --enable-local-file-access flag could be dropped. I don't see a way of suppressing pdf output; using a dedicated javascript interpreter instead of wkhtmltopdf might be better. Use of mktemp --suffix=.pdf in place of deleteme.pdf (and/or mktemp --suffix=.html in place of outer.html) might also be beneficial.
wkhtmltopdf --run-script 'console.log("\n<!DOCTYPE html>\n" + document.body.parentNode.outerHTML);' --log-level warn --debug-javascript --enable-javascript --enable-local-file-access demo.html deleteme.pdf 2>&1 | sed 1d > outer.html
prince -j outer.html
rm deleteme.pdf
It should work for many other js libraries too. No doubt others have written more refined versions of the above.
If demo.html and its dependencies were available on a web server, then the --enable-local-file-access flag could be dropped. I don't see a way of suppressing pdf output; using a dedicated javascript interpreter instead of wkhtmltopdf might be better. Use of mktemp --suffix=.pdf in place of deleteme.pdf (and/or mktemp --suffix=.html in place of outer.html) might also be beneficial.
Edited by pjrm