How do the developers of XeTeX and LuaTeX ensure that their engines don't significantly deviate from the output produced by earlier TeX engines? (I've read that the developers of LuaTeX tend to care less about this, so this question is geared more toward XeTeX, the documentation of which says specifically that certain features/options cause documents to compile differently or with different line breaks than they would under older TeX engines.) Is there a program that does this automatically?

  • 2
    One of the primary advantages of the Unicode-aware engines (Lua- and Xe-) is that they use fontspec and are capable of responding to properties of fonts that post-date the old PostScript Type 1 era. I can see that improved font handling could possibly cause lines to break differently, On a possibly related note, I see that recent versions of LibreOffice Writer can now handle some Open Type features that hitherto were ignored. Some of them can be used automatically. Thus, I would expect that some of their documents would produce different layout when the version changed.
    – user139954
    Commented Jan 23, 2018 at 5:40
  • 2
    @RobtAll I'm not sure that the extra font formats supported really affects this question. When comparing compatibility you are asking whether you get the same output from the same input, so in particular using classic tex fonts (both xetex and luatex can use) Commented Jan 23, 2018 at 7:48
  • @DavidCarlisle Ah. I supposed that when switching engines, the user would also switch from PostScript to TrueType or Open Type equivalent fonts, which might not be exactly identical in terms of layout calculations.
    – user139954
    Commented Jan 23, 2018 at 15:25
  • 2
    @RobtAll unless you change the document the font format does not make any difference (as tex does not look at it, only the font metrics) the pdf may be constructed using truetype type1 or even a type3 bitmap font which may affect how it renders but won't affect line or page breaks. If you change to a font with different metrics then of course anything can change whether or not you change engine, just switching between two times roman clones with pdftex for example. Commented Jan 23, 2018 at 16:59

2 Answers 2


I suspect that in practice the best test (especially in the case of luatex) is that the LaTeX maintainers regularly run the LaTeX2e and expl3 test suites using all three engines (and also ptex variants in the case of expl3). The l3build test format normalises the log output to some extend to remove known differences and (allows engine-specific versions of the base log files to be stored).

So while we are not directly involved in the development of either luatex or xetex we can (and do:-) report any issues to the engine developers, often using test releases of texlive, so things get fixed before the full texlive release.

Not all differences are bugs (and especially luatex is explicitly not designed to be fully compatible) but having the test suite means that it is easier to document expected differences and ensure that the latex macros work in all three cases, the format itself and several packages have variant definitions depending on the engine being used. Notably \showhyphens and the allocation macros like \newcount plus the initialisation of character properties such as \lccode lowercase settings are all engine dependent.


Quoting the excellent TeX FAQ

TeX (and MetaFont and MetaPost) are written in a ‘literate’ programming language called Web which is designed to be portable across a wide range of computer systems. How, then, is a new version of TeX checked?

Of course, any sensible software implementor will have his own suite of tests to check that his software runs: those who port TeX and its friends to other platforms do indeed perform such tests.

Knuth, however, provides a ‘conformance test’ for both TeX (trip) and MetaFont (trap). He characterises these as ‘torture tests’: they are designed not to check the obvious things that ordinary typeset documents, or font designs, will exercise, but rather to explore small alleyways off the main path through the code of TeX. They are, to the casual reader, pretty incomprehensible!

Once an implementation of TeX has passed its trip test, or an implementation of MetaFont has passed its trap test, then it may in principle be distributed as a working version. (In practice, any distributor would test new versions against “real” documents or fonts, too; while trip and trap test bits of pathways within the program, they don’t actually test for any real world problem.)

Here is a link to the documentation for the trip test

  • 1
    I think LuaTeX, at least, does not aim to pass the trip test. Does it?Possibly the same is true of XeTeX. Commented Jan 23, 2018 at 6:19

You must log in to answer this question.

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