Hi, With luametatex becoming more mature, it's time to get rid of some old code. For instance, we have lmt files that assume 5.4, but regular lua files should work for luajittex (5.2) and luatex (5.3). Most noticable are the lack of bitwise operators and integer devision in luajittex, but there are more details. Till now, part of this problem is deals with by using functions that can actually be seen as macros that can are optimized when the format is made (kind of c-ish). It's not pretty, but works and probably no one ever noticed it. That mechanism will probably stay (for the fun of it) but the less it's used for creating the format the better. Another complication is that we use mtxrun for both running luatex and luametatex so there we need to be friendly to all three engines. But ... eventually luametatex will be the stub for also luatex and then mtxrun can become 5.4+ (the --luatex flag already works that way). An alternative is that we have mtxrun.lmt as well as mtxrun.lua but why bother. I also need to keep in mind that there are users of the font code that expect it to work with luajittex but that can be dealt with by splitting files. By splitting modules in lua and lmt variants we can tune for luametatex so that will happen anyway (less code, no engine specific sections, again a smaller format file, etc). All these adaptations have no functional consequences but of course there can be temporary hickups because of some oversight. At the engine level there is also some occasional cleanup, like replacing some left-over low level 5.2/5.3 lua api things by 5.4 but that's kind of ongoing (as lua progresses). In principle users should not notice such changes, just like probably no one noticed that we now use a different zip library (in the beginning some high speed variants were tested too but it's not that critical and I just don't want architecture dependencies that complicate a build and can influence stability). I still try to minimize the code base and dependencies, although I admit that sometimes stuff gets added (like the more efficient memory allocator). But my target max binary size of 3MB (less with link time optimization and related stripping) and fast compilation goals are still met. 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 -----------------------------------------------------------------