Looking to integrate TeX equations in a TeX-agnostic fashion, suitable for either ConTeXt or LaTeX, into a Java-based desktop Markdown editor. The possibilities are numerous, but I'm not sure what approach to take.

JMathTex outputs to MathML, which must be transformed. JEuclid can transform MathML to BufferedImages (not 100% sure). Neither are JDK 14-friendly and may be too slow to render in real-time. I haven't looked because I read that they didn't work with Java 9 (without porting effort), much less 14. Also, the licensing isn't LGPL, which probably won't work with the MIT licensing.

The NTS library is reported to compile gentle.tex in about 3 seconds. The spin-off project, εχTEX improves upon NTS, but I don't know to what extent.

Java LaTeX Report requires a TeX engine.

Yet another possibility is to try JavaTex or rework the project using web2java to transpile WEB files into Java files.

JLaTeXMath does an exceptional job at rendering, though investigation would be required to see if it can perform real-time renders, output as SVG, or otherwise determine if it can integrate with FlyingSaucer.

The HTML preview panel uses FlyingSaucer. The SVG documents are rendered using SVG Salamander. If it was possible to go from TeX to SVG, that could work quite handily, architecturally. Some documentation stated FlyingSaucer can also render MathML, but I suspect the doc is wrong. FlyingSaucer doesn't integrate with JavaScript. For that I'd have to add a JavaScript Engine.

If a JavaScript Engine is necessary, then using KaTeX may be an option.

Still another possibility is the TeX to MathML service. This is written in Java, but the source code is not available anywhere. I've reached out to some people involved in the project.

For native speeds, there may be a (cross-platform?) C-based TeX engine that can generate MathML or SVG from a TeX input. If so, it may be possible to integrate with the JNI.

Here's a demo video of the app, to give you an idea of what is needed:

The goal is to produce real-time rendering of math, ideally in pure Java (no JavaScript).

What approach would you take and what do you see as its benefits and drawbacks?

  • 1
    It is good that you showed the effort you already have invested. However, here on SE.SE, we do not recommend tools or libraries (and that is probably what you need here). I think your question qualifies for softwarerecs.stackexchange.com
    – Doc Brown
    Commented Aug 14, 2020 at 19:00
  • 1
    I was seeing the question not so much about a library (I've already listed most of them), but rather how to go about integrating a particular option to get real-time performance and any problems that may appear. Such as JavaScript vs. JNI vs. pure TeX in Java. Commented Aug 14, 2020 at 22:43
  • I guess what could help you here is not really a software engineering expert, but someone who has experience with those very specific libraries (maybe you find tex.stackexchange.com, but do not crosspost). In the end, this is going to become an evaluation process we cannot do for you - this depends too much on details like the specific TeX subset you want/need to support, your performance requirements and the "integratibility" of the solution into your system. This is hard work, I know, but don't expect anyone else here to do it for you. ...
    – Doc Brown
    Commented Aug 15, 2020 at 6:09
  • ... said that, I think I can write an answer how to approach such an evaluation process (from the POV of a software engineer who knows TeX, but has no experience with those specific libs)
    – Doc Brown
    Commented Aug 15, 2020 at 6:11
  • 1
    Check out AucTeX with it's preview mode. Commented Aug 16, 2020 at 14:08

1 Answer 1


I have no experience with those specific libraries and tools, but since you asked this here on SE.SE, let me give you an answer on how to approach such an evaluation process as a software engineer.

It seems you have identified already a list of potential candidate components. That is a really good start. You also know several of your requirements and expectations for these components, that is even better. Now the next step is to make a table where

  • the rows are the candidates
  • the columns are the requirements to fulfill

For the requirements: try to list all which are important for you. I guess this is not just "rendering performance", but also

  • the supported TeX subset
  • how well it integrates with your current system (Java, Flying Saucer)
  • supported Java version
  • supported Operating Systems (not every Java component is OS independent)
  • license / pricing
  • maturity
  • how well is it documented
  • expected maintenance effort (by yourself, or does the author actively maintains the component)

Then go systematically through that table and try to fill it out. Maybe you have to dive deeper into some components, read their docs or try them out. Maybe you can already rule out some of the solutions (for what you are trying, I would probably avoid anything which requires the installation of a full TeX engine, especially when the program shall work not just in one specific Linux environment).

In the end, you have to look into the table and pick the row which suits your requirements best. One could try to give each column a weight, and calculate a "score" for each candidate. IMHO making the comparison by "common sense" instead will usually work better. But whatever approach you pick, expect this to become a trade-off!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.