124

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:

enter image description here

LuaLaTeX:

enter image description here

\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.

9
  • 11
    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. Jul 31, 2013 at 15:10
  • 4
    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, 2014 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, 2014 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, 2014 at 18:58
  • @Thérèse I've opened a new question about this: tex.stackexchange.com/questions/184758/…
    – Sverre
    Jun 13, 2014 at 19:07

6 Answers 6

59

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.
7
  • 3
    Official successor? What about LaTeX 3; different discussion?
    – Raphael
    Jul 31, 2013 at 15:13
  • 12
    @Raphael I believe you are mistaking engines for formats
    – cgnieder
    Jul 31, 2013 at 15:15
  • 11
    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. Jul 31, 2013 at 16:08
  • 5
    On my computer Lua takes much more time to compile than Xe May 4, 2014 at 14:07
  • 3
    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. Mar 23, 2018 at 17:43
23

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.

7
  • Can you give an example of a PGF feature that does not work under XeTeX? Feb 22, 2015 at 19:03
  • 2
    @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. Feb 23, 2015 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, 2015 at 14:45
  • 5
    @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 Nov 2, 2015 at 15:29
  • 1
    Which one compiles the document faster?
    – skan
    Nov 13, 2016 at 19:29
23

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 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).

3
  • 1
    @Mico You're right, I forgot about the command line options.
    – TeXnician
    Aug 8, 2017 at 9:32
  • 2
    @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, 2017 at 9:33
  • 4
    Also, xelatex can use PSTricks, but lualatex cannot.
    – Sverre
    Aug 8, 2017 at 10:21
11

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.

1
  • 11
    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, 2015 at 10:19
8

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 ...

11
  • 6
    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. Sep 6, 2013 at 14:33
  • 8
    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. Sep 6, 2013 at 16:45
  • 4
    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). Sep 6, 2013 at 17:21
  • 2
    Ok, I'm beginning to understand. When I look at the Junicode ligature fft in BabelMap, it says that Code points is 0000, whereas the Code point for the Sample Glyph is EECE. If I use \char"EECE in XeTeX, I get the fft ligature, but is garbled when I copy from the pdf. If I just type fft, on the other hand, I get the same ligature, but I can copy it out as fft. In Linux Libertine, the same ligature has Code points 0020, and has Sample Glyph Code point E035. This ligature is garbled out of the pdf no matter if I use \char"E035 or just type fft.
    – Sverre
    Sep 6, 2013 at 17:56
  • 5
    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. Sep 7, 2013 at 0:38
5

Adding in a comment on write streams, since they matter a lot for larger projects. In short, write streams are the amount of concurrent open files for writing (XXX)TeX can have, and varies a bit between different implementations. If you have used all your write slots, there are packages such as morewrites which uses one of the files as cache for opening more files, therefore slowing down matters since a lot of files of opened and closed.

In large works, such as books or theses, the limited amount of writes in Xe(La)TeX (16 write streams) requires the use of libraries such as morewrites to function properly (multiple glossaries, indices etc have a tendency to eat write streams). Lua(La)Tex has 256 write streams and therefore does not require extra overhead such as morewrites to handle large projects.

The largest issue with morewrites (i.e. under XeLaTeX) is the performance of your drive, since you have to open and close files constantly you get a large performance penalty (i.e. waiting for IO). If you are using a machine controlled by the department's IT division you might also have anti-virus and similar scanning all the file reads (!).

As an example my PhD-thesis (~400 pages with figures, tables, glossaries, and auto-generated content by external scripts) compiles from clean checkout in ~8 minutes with LuaLaTeX and ~24 minutes with XeLaTeX on my department laptop, all due to morewrites opening and closing files constantly and additional overhead from "forced" anti-virus programs. On my workstation at home the numbers are 90 seconds for LuaLaTeX vs 220 seconds for XeLaTeX with RAM-disk and scanning disabled for project directories.

As such, for me the implicit differences, such as write streams, are more important than the actual implementation differences between XeLaTeX and LuaLaTeX.

2
  • Would it be possible to add a line or two at the beginning explaining what "write streams" are?
    – Sverre
    Sep 17, 2019 at 7:29
  • @Sverre Added a bit more, enough?
    – flindeberg
    Sep 17, 2019 at 8:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .