[gucci-on-fleek]

> The idea was to use the version which was officially declared as "complete" and also the last before the development of the HB integration started.

HB is implemented as just another library, and it's pretty easy to exclude with the build script (ConTeXt does this).

> The problem seems rather to be, that luatex-fonts-merged.lua is not really usable outside of the ConTeXt or TexLive tree

So option 1 is to base things off of `luatex-plain` [0], which I believe is fully self-contained, but mostly undocumented. Option 2 is to base things off of luaotfload, which only depends on lualibs and luatexbase.

> There was e.g. the assumption that the global utf variable pointed to unicode.utf8 (at least that's what I assume).

It needs to be in the environment where you load the file, but that doesn't necessarily need to be the global environment. This is the fourth argument of the Lua "load" function.

> First the two words were apart half a page

I would randomly guess that your issue is that \parfillskip is initialized to 0pt from iniTeX, so the problem might go away if you typeset the text in an \hbox or node.hpack, or if you set \parfillskip/tex.parfillskip to "0pt plus 1fil".

> I like that it is still in C99 and C++ <= 11

I think that the latest versions of LuaTeX still only use C99 features, but they're also C23 compatible. The only thing that should use newer versions of C++ is HB I think.

> I also had an intense look at LuaMetaTeX but don't like the architectural decision to do even more stuff in Lua.

Fair enough :). The main thing that was moved from C to Lua was the PDF backend, because it's seriously unfun to write a PDF parser/writer in C.

[0]: $TEXMFDIST/tex/generic/context/luatex/

[Rochus]

Just wanted to say that I skipped LuaTex 1.10 because not even a bare Hello World worked. So I switched to LuaTex 1.18 including the HarfBuzz library. I even implemented my own OTF loader in C (with Lua bindings for additional required HarfBuzz functions) and added it to the LuaHBTex executable. The font loading works, and also the layout in principle, but the result is ugly. So I came to the conclusion that there is still a lot of Lua and TeX code required to get the famous LuaTeX typographic quality, and there is little chance to get it with only the LuaHBTeX engine itself.

For that reason I now left LuaTeX altogether and re-start with my own implementation of the Knuth algorithms based on HarfBuzz, FreeType, MicroTeX and Cairo. For the time being I limit the typesetting to western languages (LTR-only), which I hope allows me to get a working MVP version in a few months.

[Rochus]

> base things off of `luatex-plain`

I have that on the radar indeed, but as far as I understand it still depends on plain.tex which again depends on tons of 1986 stuff (like old fonts) which I want to avoid. But due to my present experiments with the 40kLOC Lua machinery I'm scared of integrating this thing and would rather opt for avoiding it.

> that \parfillskip is initialized to 0pt from iniTeX

I did a lot of instrumented runs where values were printed and looked "unsuspicious". My best guess at the moment is that the Lua based machinery has an issue with the space in DejaVuSans.ttf, but that's just an assumption. I already stopped this path due to its apparent fragility and my reluctance of the architectural approach (I initially thought that everything required to do high-quality typesetting was already part of the luatex executable, but only realized this fragile dependency when doing larger test cases on my downsized engine version).