[NTG-context] context lmtx

Hans Hagen j.hagen at xs4all.nl
Mon Apr 8 11:53:39 CEST 2019


As some (and hopefully more) users are testing lmtx, here is some more 
information about what to watch for.

- There are no changes at the macro level that would not have occurred 
at some point when using luatex. For instance, if \pagewidth doesn't 
work, that is because it is now simply gone, while before it was a 
temporary compatibility hack. It is some backend related measure that 
did more good than bad and was never meant for users.

- In MkIV most of the backend code is done in Lua, and ConTeXt never 
used much of the engine. We now simply do all backend stuff in Lua. That 
also means that the pdf.* namespace is no longer supposed to be used at 
the user level. It might get hidden completely at some point, or maybe 
emulated to some extend but again, that was never meant to be a user 
level interface (in context).

- The same is true for images. I might decide to keep the img namespace 
but we have different mechanisms so again, img was never meant for user 
level usage (in context). In lmtx the engine is no longer really 
involved in image inclusion at all (so we went from 'some' to 'none' in 

- Directions (there was some message about that) have a high level 
interface that should be used because there can be interferences 
otherwise (read: therefore no support for low level hacking). The 
directional model in luametatex has been overhauled and to what extent i 
will backport that to luatex is undecided (think of compatibility 
issues; it also depends on further experiments; and after all, it works 
ok in luatex) but that should not affect mkiv (and using luatex).

- Font handling was already under Lua control in context so nothing 
changed there apart from that also tfm loading is now delegated (but i 
suppose that not many users use tfm fonts). The new setup will provide 
some interesting new options that will be explored in the future but 
there we're talking of non-typical usage (for those wondering about 
generic usage of the font loader: we could always do some more in 
context so the generic usage is not affected.)

- Performance is in hit by all this because a lua backend is of course 
slower than native c but we gain a back in other areas, so overall 
performance is not touched (and actually a lot can be gained due to 
other side effects; the same is true for the memory footprint; now that 
luatex 1.10 is out I can also use some of its features.).

- Some problems reported (like clash in cache) are easy to solve. As are 
some more tricky things like the page injection mechanism, which just 
happens to depend on alternative low level backend code. I suppose more 
issues like those will show up in the coming weeks.

- Let me stress that deep down there is still the normal TeX engine, 
token handler, memory management, macro machinery at work and it will 
stay as such because nothing can beat the core tex performance. At the 
macro level context is rather optimized for using it and just in case 
one wonders if we could benefit from further luafication, the answer is 
'no' because as said, tex parsing (and expansion) is very fast, as is 
the grouping model (which is fundamental to tex). So, we have (and keep) 
the same hybrid lua, tex, mp model as we already have for over a decade. 
We use each language for what it is best.

- When all users have moved to luametatex i might clean up some code 
that now is kept around for compatibility (just because, the less code 
the better, and we can always make a frozen snapshot). But that is 
something that will go mostly unnoticed.

So, thanks for testing, and please keep testing,


                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl

More information about the ntg-context mailing list