Could MathTeXEngine hook up into LaTeX?

[Gregstrq]

This topic might be quite irritating, so sorry for that in advance.

Currently, Makie.jl uses MathTeXEngine.jl to process LaTeX. I have looked at MathTeXEngine.jl, and what I understood is that it returns information about a set of boxes: coordinates and scalings for the boxes plus the symbols to go inside the boxes.

As it is written in the Readme, MathTeXEngine parses the LaTeXString and then produces the approximation for the LaTeX output using the unicode characters. As far as I understand, this approximation needs to be hardcoded manually, which is a time-consuming process.

So, I have two question:

• Why was the design choice made to do everything manually: parsing, approximating with unicode, etc. Would it not be easier just to use LaTeX directly like matplotlib does?

• May it be a good idea to provide an alternative which actually hooks up into LaTeX and uses the same syntax as MathTeXEngine? I looked into matplotlib source code: they process LaTeX code with LaTeX, and then parse the .dvi output. Also, it looks like dvi contains precisely the kind of information that we need: font, boxes with coordinates and scalings, symbols. Also, it may be much easier to parse dvi instead of the source tex code.

[sdanisch]

https://github.com/JuliaPlots/MakieTeX.jl does that… But without the DVI parsing part, since that’s pretty complicated…
The simple answer is: It’s super hard to ship latex with a package, and then make it spit out the correct text layout information… Certainly not impossible, but for the LaTeX support we ship natively with Makie, an approach like MathTeXEngine is much preferred.

Anyways, feel free to implement the dvi parsing, i’d be very happy to have that

[Gregstrq]

@sdanisch

But without the DVI parsing part, since that’s pretty complicated…

Actually, I have looked through matplotlib source code, and this DVI parsing part is rather straightforward. DVI file contains simple commands, like “go down one line”, or “put a character from some font and move right by its width”. The result of the parsing gives you the coordinates of the symbols with the indices of the symbols inside the used fonts.

The hard part is linking with the font files (like ttf or otf) to get the actual glyphs for rendering. TeX predates the vector fonts. As a result, working with the modern fonts is a bit tricky, but not impossible (it seems pdfTeX ships with a file “pdftex.map” containing mapping from internal TeX fonts to more modern fonts).

@sdanisch

It’s super hard to ship latex with a package

Hooking up with LaTeX is really needed only if you need to produce publish quality plots. However, if you are trying to write a paper, you will have LaTeX already installed in the first place to do the writing.

[jules]

I’d also be glad to have that feature. If you could come up with a prototype that shows a path forward with real Latex, that would be great.

[jzr]

It may be interesting to look at implementations of MathML Core, the markup language for math under development for a W3C standard.

[sdanisch]

@Gregstrq

Actually, I have looked through matplotlib source code, and this DVI parsing part is rather straightforward.

That’s good news, let us know whenever you have a PR ready

[Gregstrq]

@sdanisch

let us know whenever you have a PR ready

It is straightforward, but it may take some time. (I have other commitments as well.)

@sdanisch I could use some expertise from MathTeXEngine. If I have questions about its internals, should I ask you, @Kolaru, or someone else? Also, do you guys have a dedicated workspace on Slack? (Or should I simply write in Julia#makie channel?)

[sdanisch]

Yeah @Kolaru is the person to ask Not sure where on slack would be best, makie channel seems fine…
If you write anything, I think it should ultimately go into MakieTex.jl, but I’d write a simple prototype outside of it first, since MakieTex.jl is not in a really good state I can help integrate it once DVI → makie plot is working.

[Kolaru]

@Gregstrq

Why was the design choice made to do everything manually: parsing, approximating with unicode, etc. Would it not be easier just to use LaTeX directly like matplotlib does?

First I love writing parsers

But more seriously there were two main reasons:

• I needed the feature and I don’t understand latex internal process. Comparatively, parsing latex and placing characters seemed rather straightforward (still a lot of work, but no need to learn several other programming languages to go through).
• Implementing it felt unavoidable. At some point for speed or ease of use, a native solution would be needed. This idea was reinforced by the fact that matplotlib also ships its own simple latex engine.

[Gregstrq]

@Kolaru

This idea was reinforced by the fact that matplotlib also ships its own simple latex engine.

After more roaming through matplotlib internals I gathered the following:
matplotlib has simple latex engine as well as the means to hook up into latex. Simple latex engine is used with interactive backends like ‘Agg’, for example. Hooking up into LaTeX is used with static backends, like pdf or svg.

Here goes the tricky part. Let’s say you use a interactive backend. Say, ‘Agg’, which is used by default. If you try to save figure to a pdf file, matplotlib actually switches backend to pdf and then uses this backend to save a file.

To summarize: matplotlib uses simple latex engine for interactive plotting and raster outputs. In the case of vector graphics output, matplotlib hooks into LaTeX.

[Gregstrq]

I would say that we need both MathTeXEngine and the means to hook up directly into LaTeX: one can be used for interactive plotting, another — for publication quality output.