Learn LaTeX in 30 Minutes
overleaf.com
overleaf.com
Interesting. What's the main reason? Do you already have representative experience with Typst? Does it really solve the issues you perceived with Latex? Are you satisfied with the typographic quality of Typst? (why I'm interested: https://github.com/rochus-keller/typos/)
The following projects have somewhat similar goals, so they might be worth looking into:
https://github.com/vlasakm/mmtex
Just a small note: the speedata Publisher ships with a LuaTeX, so you don't need it pre-installed.
The downloadable ZIP is ready to run and does not need any additional libraries. (That said, I include some helpers, for example for https access. )
Why such an old version? The latest version is 1.24.0, which should have lots of new features and fixes relative to v1.10. And if you're starting from scratch and not planning on using any of the TeX stuff, I'd really recommend using LuaMetaTeX since it cleans lots of stuff up, and doesn't use autotools at all.
The problem seems rather to be, that luatex-fonts-merged.lua is not really usable outside of the ConTeXt or TexLive tree, because it makes a lot of assumptions which are not met in my environment, and finding such dependencies in ~40kLOC of a dynamic language is nearly impossible. There was e.g. the assumption that the global utf variable pointed to unicode.utf8 (at least that's what I assume). So I had to set that before loading luatex-fonts-merged.lua. I assume there are many more such "tricks". After two days of experimenting, not even a "Hello World" is properly typeset. First the two words were apart half a page, and now they are set on two lines and I don't find out why.
These experiments brought me to the conclusion, that implementing so fundamental and complex logic in Lua is a very bad idea. So I'm currently evaluating LuaHBTex in the stable version 1.18.0. I like that it is still in C99 and C++ <= 11 (at least that's what I understood so far). I also had an intense look at LuaMetaTeX but don't like the architectural decision to do even more stuff in Lua. I'm using and integrating this language since 25 years and think it is good for a bit of glue code (max. 1-2 kLOC), but larger code bases pass the limit of practicability of a dynamic language. I even implemented a few statically typed languages which generate Lua source and bytecode to reuse the technology without this disadvantage.
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/
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).
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.
What is your experience? Have you managed to use the LuaTeX engine stand-alone with decent results, or do you use additional TeX and Lua scripts?
LuaTeX itself doesn't depend on any particular directory structure. kpathsea does expect a certain directory structure, but you don't need to use kpathsea—LuaTeX was primarily developed for ConTeXt, which doesn't use kpathsea at all. Without kpathsea, you'll need to supply the appropriate callbacks in a Lua initialization script, but this is fairly simple.
And for a system like speedata at least the Lua implemented luaotfload machinery had to be accessible somewhere in a known directory. When they now switched to LuaHBTex (as I likely will as well) this dependency can be avoided without losing typesetting quality (as far as I've understood so far).
[0]: https://www.pragma-ade.nl/general/manuals/cld-mkiv.pdf
[1]: https://github.com/gucci-on-fleek/unnamed-emoji/blob/master/...
[2]: https://github.com/TikZlings/Extravaganza2025/blob/main/max/...
For my present project, I would like to start "from first principles" and not just add layers on top of things I don't fully understand. Thanks for the CLD document. I have read it when I started the mentioned project. I have no doubt from my own experience that the typesetting quality is excellent. But I consider using Lua for such large-scale achievements a mistake for architectural, maintainability und eventually performance reasons. The "flexibility" of this approach is payed with a high price.
Ah, nice! ConTeXt certainly isn't the solution to every problem, but it solves lots of the common complaints about LaTeX, and most people have never heard about it, so I always try and advertise it when I see a problem that seems like a good fit.
> if the users don't mind to have an extra ConTeXt installation on their system (which grows pretty large)
> For my present project, I would like to start "from first principles"
> But I consider using Lua for such large-scale achievements a mistake for architectural, maintainability und eventually performance reasons.
Well I personally disagree regarding Lua :), but all your points are very fair. Most people who say "I'm going to write my own typesetting system" severely underestimate the difficulty, but it sounds like you have a pretty good handle on the situation, so I'm rather hopeful that you'll accomplish your goal.
Once you're able to typeset something, we'd gladly accept a progress report at TUGboat [0], since this is a topic that lots of people are interested in but very few have accomplished.
> Once you're able to typeset something, we'd gladly accept a progress report at TUGboat
Currently I try to find out whether a Pascal based typesetting language with static typing would be worthwhile or not. Otherwise I will likely implement something like Typst (the latter is actually the reason I started this journey because it is for one part a much better language than TeX, but for the other part the typesetting quality is much worse, and this doesn't seem to change for years when looking at the roadmap).