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
If your question is of interest to others as well, please add an entry to the
maillist : firstname.lastname@example.org / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net