![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
Hi, 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 context). - 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 ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------