# Why choose LuaLaTeX over XeLaTeX?

There are questions on TeX.sX already about what the differences between LuaLaTeX and XeLaTeX are (Differences between LuaTeX, ConTeXt and XeTeX), what one should be keep in mind when going from XeLaTeX to LuaLaTeX (Considerations when migrating from XeTeX to LuaTeX?), and how they typically differ in their preambles (Frequently loaded packages: Differences between XeLaTeX and LuaLaTeX).

From the perspective of an end user, however, I've yet to see any reason for why one should switch from XeLaTeX to LuaLaTeX. That is, I have read facts like LuaLaTeX using the Lua scripting engine, but that is not relevant to an end user like me who has no idea what that entails.

Yet I've noticed that most of the cool kids here on TeX.sX seem to prefer LuaLaTeX over XeLaTex, and I'm curious what those reasons are, and more specifically, if they apply to "normal" end users like myself.

To give LuaLaTeX a try, I recompiled an old short handout of mine in LuaLaTex, and they mostly looked exactly the same. Where they differed, however, XeLaTeX clearly gave the better results. Below are some examples I found in my handout:

XeLaTeX:

LuaLaTeX:

\documentclass{article}
\usepackage{fontspec}
\setmainfont
[
Path = C:/Windows/Fonts/,
Extension = .otf,
UprightFont = LinLibertine_R,
BoldFont = LinLibertine_RZ,
ItalicFont = LinLibertine_RI,
BoldItalicFont = LinLibertine_RZI
]{libertine}

\begin{document}
mak\textbf{\underline{a}}t
\textit{wund\textbf{\underline{V\char"0306}}de}
\textit{*wund\textbf{\underline{\char"014D}}d\char"0113}
\end{document}


In the second and third word, LuaLaTeX adds more white space before the underlined italicized boldfaced characters. In my view, it adds too much. Notice, however, that it does not add any extra white space in the first word, where the character is not italicized.

In the second word, XeLaTeX handles the placement of the combining breve character well, but LuaLaTeX does not. This is potentially a worry, since I normally use a lot of combining characters in my documents (this being the only example in my handout).

If anything, I only see reasons to stick to XeLaTeX for the moment, but I am still curious if there are advantages to LuaLaTeX over XeLaTeX that could potentially override the disadvantages I've identified above.

• I am aware of the fact that lualatex uses dynamic memory management. As author of a memory-intensive package, I believe that this is quite interesting and simplifies things considerably. I suppose the xelatex has the typical cumbersome memory limit restrictions. – Christian Feuersänger Jul 31 '13 at 15:10
• To some extent, the problem you note has to do with the font: your example gives perfect results in lualatex with Brill, DejaVu, Heuristica, and Source Sans Pro, all of which have the mkmk feature (Junicode also has it, but the output is ugly). – Thérèse Jun 13 '14 at 17:40
• @Thérèse I think you mean mark (mkmk is for aligning diacritics to other diacritics)? So the question is why \textit{\textbf{V\char"0306}} gives a good result with XeLaTeX, but not with LuaLaTeX. – Sverre Jun 13 '14 at 18:40
• The four fonts with which your example gave good results in lualatex have both the mark and the mkmk feature. I don’t know which is responsible for the good result (I’ve also seen some fonts with an abvm feature, and I’ve never tried to work out how font designers interpret each of these). But at least it’s clear that the differences between xetex and luatex aren’t the only factor; the font also plays a role. – Thérèse Jun 13 '14 at 18:58
• @Thérèse I've opened a new question about this: tex.stackexchange.com/questions/184758/… – Sverre Jun 13 '14 at 19:07

In my personal opinion (i.e. from anecdotal situations I've encountered), lua(la)tex looks indeed a little less stable than xe(la)tex, in particular when it comes to some advanced font features (fontspec was after all developed for xe(la)tex first). It's somehow to be expected: xe(la)tex itself is older than lua(la)tex and can therefore expected to be a more mature in terms of bugs, etc.

The advantages I see of lua(la)tex though are:

• lua(la)tex has been choosen as the official successor of pdf(la)tex, so you can expect more development effort to go towards it now and in the future. For example, microtype supports much more features under lua(la)tex than it does under xe(la)tex,
• lua(la)tex opens up the internals of TeX to the Lua programming language. This might sound like some irrelevant technicality to the end user, but in reality it is not when you consider that this might enable advanced packages / features that are just not possible to implement otherwise, such as rivers detection and most other features of impnattypo.
• lua(la)tex doesn't rely on system-specific libraries, so in theory you're less prone to encounter platform-specific issues or differences in output.
• Official successor? What about LaTeX 3; different discussion? – Raphael Jul 31 '13 at 15:13
• @Raphael I believe you are mistaking engines for formats – clemens Jul 31 '13 at 15:15
• XeTeX relies on system specefic libraries for system specific features (like locating system fonts, which is always system specific, if you want to do it reliably), so it is hardly an issue in practice. – Khaled Hosny Jul 31 '13 at 16:08
• On my computer Lua takes much more time to compile than Xe – Nicholas Hamilton May 4 '14 at 14:07
• I realize this is a very late comment, but for others who may come here in search of diffs between xe and lua: XeTeX correctly renders Indic scripts, whereas afaict, LuaTeX does not (even as of the 2017 TeXLive distro). There's a post here with more details: tex.stackexchange.com/questions/285527/… (and a comment from me at the end). This may also affect other complex scripts, like Burmese. – Mike Maxwell Mar 23 '18 at 17:43

I agree with Xavier on the first two points.

Another advantage of LuaTeX over XeTeX is that LuaTeX uses the PDF engine of pdfTeX, while XeTeX uses its own one. One consequence of this is, that all features of the PGF graphics package (on which TikZ builds) should be available also under LuaTeX, while some features are definitely not available under XeTeX.

• Can you give an example of a PGF feature that does not work under XeTeX? – Faheem Mitha Feb 22 '15 at 19:03
• @FaheemMitha Shading is the most common example I think, try for example \documentclass[tikz]{standalone} \begin{document} \begin{tikzpicture} \shade (0,0) rectangle (2,1); \end{tikzpicture} \end{document} with pdflatex and then with xelatex. – Torbjørn T. Feb 23 '15 at 10:07
• @TorbjørnT. I see no difference between the outputs produced by pdflatex and xelatex. I otherwise agree with Faheem, and it's hard to evaluate the validity of Wolfang's claim without at least one example. – Sverre Nov 2 '15 at 14:45
• @Sverre You're right that there is no difference now, but there have definitely been problems earlier, see e.g. TikZ 3.0.0 (release) produces strange shadings if used with XeLaTeX and standalone I think there were problems prior to pgf 3.0 as well, but cannot say for sure. There have also been other problems, e.g. TikZ example involving Spies won't typeset properly using XeLaTeX I'd say Wolfgang's claim was perfectly valid at the time, but most of these problems may have been fixed since, though I don't know – Torbjørn T. Nov 2 '15 at 15:29
• Which one compiles the document faster? – skan Nov 13 '16 at 19:29

Since I am a heavy user of tikz/pgf, here are some key points why I always prefer lualatex.

• pgfplots works best with lualatex. On a moderate size csv file, both pdflatex and xelatex wet their pants (run out of memory).
• TikZ graphdrawing library works only with lualatex. The layout algorithms are implemented in Lua; they are too complicated to be implemented in TeX.
• Access to Lua (though I wish it was python) means a lot if you are doing very non-standard things e.g. read only n lines from a csv before plotting it; replace 'X' with 'Y', write to file etc. These are non-standard use cases but they are better handled in Lua than using some latex package.

Probably it is safe to say that whatever you can do in XeLatex, you can do with lualatex but not the other way round (See comments below).

• @Mico You're right, I forgot about the command line options. – TeXnician Aug 8 '17 at 9:32
• @Dilawar - I agree with all of your statements except the last one, viz., that "whatever one can do in XeLaTeX, one can do with LuaLaTeX". See, e.g., the posting Can one set a specific font variant in xelatex for uppercase letters only? While it may be true, in a very narrow sense, that it should be possible to replicate the functionality of the \XeTeXcharclass/ \XeTeXinterchartoks machinery in LuaTeX, this replication still has to be performed. For sure, I'm not aware of any LuaLaTeX packages that provide this type of functionality. – Mico Aug 8 '17 at 9:33
• Also, xelatex can use PSTricks, but lualatex cannot. – Sverre Aug 8 '17 at 10:21

LuaTeX including METAPOST as mplib is a huge advantage (this allows one to directly use MP code w/o the overhead and need to pause typesetting, run a separate process and then load the created file) --- looking forward to LuaTeX maturing past the difficulties noted in the question (you did report those as bugs to the appropriate people, right?)

• No I didn't ... :-/ I'll search and see if there's a place for LuaTeX bug reports. – Sverre Sep 6 '13 at 13:54
• It would be more helpful if you elaborated on how it is a "huge advantage" that luatex includes "METAPOST as mplib". I have no idea what this means. – Sverre Nov 2 '15 at 10:19

One good reason to switch to LuaTeX is the fact that XeTeX can't use the glyph names for glyphs in the Private Use Area of fonts. As a result, any glyph from the PUA will end up as garbled text if you try to copy it from the pdf output. This issue has been raised in Small-caps, old-style numbers, and some ligatures produce odd symbols in PDF copy text? and \pdfglyphtounicode with XeTeX. I don't know if this is likely to be resolved, since the XeTeX maintainers apparently insist that fonts shouldn't use the PUA at all. But as long as there are many characters that haven't been included in Unicode yet, fonts need to add those extra characters in the PUA.

LuaTeX doesn't have this problem, it seems. LuaTeX does not, however, as seen in the OP's question, deal very well with many other aspects of font outputs ...

• Using PUA for glyphs that should be accessed with font features is not the same as using PUA for unencoded characters, the later works as intended; PUA in → PUA out. – Khaled Hosny Sep 6 '13 at 14:33
• The recommended way is to not give the alternate glyphs any Unicode points at all, that is what all the new fonts does. And if the font designer does this and give them proper glyph names, everything works as expected. – Khaled Hosny Sep 6 '13 at 16:45
• PUA are Unicode code points, Unicode just does not assign any characters to them. Check latest version of JUnicode font of how variant glyphs should be handled (or my Amiri font, it has 5000+ variant glyphs, non is assigned any code point). – Khaled Hosny Sep 6 '13 at 17:21
• I don’t know BabelMap, so I don’t understand its terminology. Junicode used to use PUA for its ligatures and alternate glyphs, but last version(s) does not do that any more. The PUA glyphs are still left for backward compatibility e.g. for people who were typing the PUA codes directly (which is one if the reason why PUA should not be used for this; it encourages bad practices). Libertine is still using PUA, though I discussed this with its author and hopefully it will be fixed in later releases. – Khaled Hosny Sep 7 '13 at 0:38
• Yes, unless you are using a font viewer (or glyph palette, in applications that has such a thing). – Khaled Hosny Sep 7 '13 at 13:00