The LaTeX team have recently taken steps to extend the LaTeX2e kernel to
provide some low-level support for post-TeX90 engines. This has included
integrating parts of the functionality of the etex package and various
ad hoc additions to the format-building process. These changes were
released in time for TeX Live 2015 and have largely gone smoothly (the
team are working to deal with outstanding issues/grey areas and expect
those to be sorted shortly).
For LuaTeX there are other new register types that need allocation but
that has not to date been covered at all by any pre-built formats. As
well as registers, there is also a need to manage some functionality at
the Lua level, principally addition to callbacks, which shares certain
key characteristics with register allocation. Most notably, all of these
require *exactly one* implementation is active.
To date, support for this area has been left to package authors, with
both the "luatex" and "luatexbase" packages available. This situation
has led to some issues and also means that many basic uses of LuaTeX
with LaTeX have to pull in quite a bit of material.
Following on from the introduction of 'engine awareness' in the
2015/01/01 kernel release, the team are now examining how this LuaTeX
situation can be better addressed. Following some initial consultation
with the authors of luatex and luatebase, we have therefore drafted an
approach to the area as the basis for discussion.
The code we have at present is available from
This consists of two parts: code to be added to the kernel (in
ltluatex.dtx) and code to be made available as a separate package (in
lualatexsupport.dtx). Between the two parts we cover the majority of the
functionality of luatexbase.
We are looking for feedback in two areas. Firstly, does the
functionality provided cover the needs of package authors using LuaTeX?
Secondly, we would like input on how a transition to new support code
can be managed. We are reluctant to suggest a complex compatibility
layer for either our code or the existing packages, and suspect at this
stage that a clean 'step change' may be needed for packages working with
LuaTeX. However, this is a complex area and needs careful consideration.
All input most welcome.