Would you consider Luatex to be ready for a production environment

Question

I'm setting up a number of document with dynamic texts. Basically LaTeX is view mechanism to dynamically present the results of ongoing statistical analysis on a database. So I have numerous \ifnums and \newifs that are fed by Sweave with the values calculated in the R chunks of and Rnw file.

And although the LaTeX if else constructs work, the LuaTex examples posted here on tex.se look so much more elegant and easier to debug that I would much prefer to go that route. Especially when I have multiple nesting I sometimes struggle to pinpoint why errors occur.

I certainly do ask about advantages and disadvantages of LuaTeX and LuaLaTex itself. There are some excellent posts here discussing that already. What I do need is some arguments to propose the switch to LuaTex for some or all reports to my team. The immediate response is "LuaTex is still in beta, and will be for a while". However the authors suggest that it is stable enough:

major releases (x.x0 versions) are stable enough to be used for production work

Can you validate this with experience? Are there risks other than the possibility of having to refactor when a new version of LuaTex/LuaLaTex comes out? The documents I'm working on are relatively simple from a type setting perspective, and I'm only using standard document classes. Also, once prepared the templates are not likely to change much.

I realize that there are some things I take entirely for granted with pdflatex, and my question could narrow down to whether this already applies (in your experience) to lualatex:

• Starting many pdflatex processes concurrently has never lead to any trouble.
• Once an a (Rnw --> Sweave --> tex) template works (has been tested, debugged and brought into production) I have never had too look at it again (except for some updates in R packages but that is definitely off topic here).

topskip already gives me one pointer: learn the limitations of the current beta, work around it if necessary and be careful when updating. I interpret this as follows: looking at cost vs benefits it will be easier to program now and possibly (but most likely not) more costly to maintain later.

Do you have more experiences you could share along that train of thought?

UPDATE - moved my notes on making the switch from pdflatex to lualatex to an answer below. It was getting too long to remain in the question

Answer 1

Yes. I have two projects with customers where we switched from XeTeX to LuaTeX (because of problems with image inclusion which are now fixed in XeTeX) and which now run for more than a year without problems (still using TL2012). Of course you need to consider how to get professional support if your business depends on LuaTeX.

It's definitely production ready; I switched from pdfTeX to luaTeX for personal use years ago. But then I can fix bugs in LuaTeX myself if need be. :-)

Answer 2

I make my living for a few years using LuaTeX, so I do consider LuaTeX to be ready for a production environment. This doesn't mean its bug free or you can use it without any thoughts.

I am still using a rather old version of LuaTeX and I never change my environment, so I have a very stable setting. (At least) one annoying bug is in my current binary (0.71.0) and I have a bit of trouble working around it, but it's ok.

If you update regularly, you might be in trouble. LuaTeX changes, Lua changes and the userland changes even more. If you have documents that don't rely on the most secret features of any of those, you have good chances that you won't notice any differences throughout the years.

So the answer is "it depends on your very personal needs" and thus I consider this question off-topic ;)

Answer 3

Yes, it seems perfectly ready for production but it comes at a steep performance cost.

After working with LuaLatex in a test environment for a while, there is much to like, and I have yet to encounter a bug, so I finally choose for Martin's resounding yes. However, I would like to qualify some aspects of my personal needs. It may help if you are deciding about including LuaLaTex in your work flow.

1. Migration

Migrating to LuaTex is a easy and well documented and requires only minor changes for documents with a layout as (relatively) simple as mine.

It takes little time to become productive in Lua, and once you have figured out how the different Lua environments you are pretty much set. This means that rewriting documents is pretty fast. The very few peculiarities of tex.print are all well documented so it does not take long to figure it out.

Another one of those peculiarities is the way you can to pass R values with Sweave to a Luacode environment. It turns out that it is perfectly possible to evaluate \Sexpr{} inside a lua environment. The trick is to make sure that you use luacode and that you use the tostring and tonumber functions in lua.

 \begin{luacode}
    local mystring = tostring(\Sexpr{df[3,c("TextColumn")]})
    local myinteger = tonumber(\Sexpr{df[3,c("NumberColumn")]})
    end
 \end{luacode}

Expressions like tostring and tonumber are among the few things that require an effort to find in de documentation. The rest is pretty standard syntax.

Because migration involves the removal of the inputenc package Sweave needs to be called with the utf8 encoding option, otherwise it will not recognize the encoding:

R CMD Sweave --encoding='utf8' testluatex.Rnw

2. Performance

This is where the costs really lie. My test document with a number of nested if-then blocks takes 0.28 seconds to convert to pdf with pdflatex and a full 1.45 seconds with lualatex. Changing the fonts back to using the pdffonts (uarial instead of Arial through fontspec) speeds it up a little bit (1.32 seconds) but not much.

That performance is still behind LuaTex's cousins is also well documented. I just did not know how much performance loss could be expected.

3. Coding and Maintainability

It is really a breath of fresh air to work in luacode instead of tex when you are working on reports with dynamic content. And it is definitely much easier and faster to read and debug in comparison to tex.

Performance happens to weigh heavily in our decision, and unfortunately the coding benefits do not yet outweigh the cost to performance. But performance may not be relevant to you, and in that case there is the benefits are substantial.