ConTeXt in TeX Live 2023

Abstract

Starting with TEX Live 2023 the default ConTEXt distribution is LMTX, a follow up on MkIV, running on top of the LuaMetaTEX engine instead of LuaTEX. Already for a long time the MkII version used with pdfTEX, X E TEX and Aleph has been frozen and most users moved on from MkIV to LMTX (a more distinctive tag for what internally is version MkXL). In principle one can argue that we now have three versions of ConTEXt and there can be the impression that they are very different. However, although MkXL can do more than MkIV which can do more than MkII, the user interface hasn’t changed that much and old functionality is available in newer versions. Of course some old features make no sense in newer variants, like eight-bit font encodings in an OpenType font realm and input encodings when one uses UTF, although we still support input encodings a.k.a. regimes. When we started using the Mk* suffixes the main reason was that we had to distinguish files and the official TEX distribution doesn’t permit duplicate file names. Using a distinctive suffix also makes it possible to treat files differently. Table 1 shows major aspects of the different ConTEXt versions. The ‘template’ files listed in the table are a mix of TEX and Lua and originate in the early days of MkIV; basically, they are a wink to active server pages. With ‘arguments’, we refer to files that accept named macro arguments which means that they need to be preprocessed. That started as a proof of concept but some core files are defined that way. Users will normally just use a .tex file. The Lua files in the code base have the suffix lua, or when meant for LuaMetaTEX that uses a newer Lua engine they can have the suffix lmt. There can also be lfg (font goodies) and llg (language goodies) plus byte-compiled files with various suffixes but these are normally not seen by users. We leave it at that. So, while TEX Live 2022 installed MkII and MkIV, TEX Live 2023 installs MkIV and LMTX. Therefore the most significant upgrade is in the engine that is used by default: LuaMetaTEX instead of LuaTEX. The MkII files are no longer installed so we don’t need pdfTEX. So how did we end up here? Initially the idea was that, because LuaTEX is basically frozen, LuaMetaTEX would be the engine that we conduct experiments with and from which occasionally we could backport code to LuaTEX. However it soon became clear that this would not work out well so backporting is off the table now. Just for the record: the project started years ago so we’re not talking about something experimental here. There have been articles in TUGboat about what we’ve been doing over the years. One of the first decisions I made when starting with LuaMetaTEX was to remove the built-in backend, which then meant also removing the bitmap image inclusion code. That made us get rid of dependencies on external libraries. In fact, a proof-ofconcept experimental variant didn’t use the built-in backend at all. The font loading code could be removed as well because that was not used in MkIV either. In MkIV we also don’t use the kpse library for managing files so that code could be dropped from the engine tool; it can be loaded as so-called optional library if needed but I’ll not discuss that here. If you look at what happens with the LuaTEX code base, you’ll notice that updating libraries happens frequently and that is not a burden that we want to impose on users, especially because it also can involve updating build-related files. Another advantage of not using them is that the code base remains small. A direct consequence of all this was that the build process became much more efficient and less complex. A fast compilation (seconds instead of minutes) meant that more drastic experiments became possible, like most recently an upgrade of the math subsystem. All this, combined with an overhaul of