Item — HN Reader

> I hate this language with the intensity of a thousand suns

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/)

1 comments

> 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

https://github.com/speedata/publisher

https://github.com/contextgarden/luametatex

Thanks for the hints. The projects have different goals. My goal is to use a stand-alone luatex engine and integrate it with my new typesetting language, completely replacing TeX. MMTeX still uses TeX, but make an easier to install package using the OpTeX format; that's a very good approach for people who want to use OpTeX and don't care about the whole TexLive machinery. Speedata is closest to what I intend, but their language is XML based and optimized for catalogues, and they depend on a pre-existing luatex installation (so they could use mine instead). LuaMetaTeX is the successor of LuaTeX which essentially moves more implementation to Lua. To my surprise, I actually didn't find a pre-existing project so far which shares my goals.

Have you considered using ConTeXt's CLD [0]? It's still uses TeX underneath, but that's pretty well insulated from the end user. Here are some random examples that I've written [1] [2] [3].

[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/...

[3]: https://tex.stackexchange.com/a/715598/270600

I'm successfully using ConTeXt in a radar data evaluation and reporting project for more than ten years where a C++ based generator reads data from binary Matlab files and combines/formats them into perfectly layouted reports automatically. It's an impressive technology and if the users don't mind to have an extra ConTeXt installation on their system (which grows pretty large), the solution is perfect.

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.

> I'm successfully using ConTeXt […]

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.

[0]: https://tug.org/TUGboat/

Concerning Lua: there are approaches for years to add static typing to Lua, but from my point of view (as a language developer) none was really good when compatibility with Lua on language level (such as TypeScript vs. JavaScript) is a goal. With my own languages I only reused the engine without Lua compatibility, and the resulting language is much better suited for large-scale software engineering. But the approach based on LuaJIT turned out to be too brittle, so I switched to the CLI Mono engine, which is much faster (factor two) and much more stable.

> 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).

(Author of speedata Publisher here)

Just a small note: the speedata Publisher ships with a LuaTeX, so you don't need it pre-installed.

Cool, good to know. But I assume you use a standard version, part of TexLive or a subset thereof? What libraries in addition to the luatex executable to you need? I'm currently integrating the fontloader into the executable binary so that I don't have to deploy a directory structure.

> so that I don't have to deploy a directory structure

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.

Thanks, I've seen that. So far kpathsea didn't get into my way and caused less trouble than the Lua code I had to use to (hopefully) achieve optimal typsetting quality. But kpathsea is indeed on my list of disposable parts.

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).

I use the standard binary from TeX-live and use the integrated harfbuzz loader, which works like a charm.

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. )

I now have migrated LuaTex 1.10 and also 1.18 (with HarfBuzz) to my BUSY build system assuming that at least with the latter I could get rid of any TexLive dependency (especially the luaotfloader). I even implemented my own OTF loader in C (with Lua bindings for additional 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.

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?

Thanks for the info. I now have a pretty lean stand-alone build of luatex 1.10.0 without all the autotools fuzz. Currently I'm testing on Linux.

> stand-alone build of luatex 1.10.0

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.