3 ms·

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

Rochus 9mo ago
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.
- patrickg 9mo ago
  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. )
  - Rochus 9mo ago
    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.
    - gucci-on-fleek 9mo ago
      > 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.
      - Rochus 9mo ago
        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. My focus is on stability. The idea was to go with a minimal system and even integrate luatex-fonts-merged.lua as part of the binary, so there are no external dependencies. 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.
        patrickg 9mo ago
        LuaHBTeX support has improved in the current version (next year's TeX-live), for example support for subsetting fonts.
        Rochus 9mo ago
        But this requires C23 and C++17 now, isn't it?
        gucci-on-fleek 9mo ago
        The dependencies might have a minimum C++ version, but I'd be pretty surprised if the core LuaTeX files couldn't be compiled with C99/C11. The recent C23 commits are just about adding support for compiling in C23 mode, so the main change is no longer using the implicit "everything is an int" function prototypes.
  - Rochus 9mo ago
    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?
- gucci-on-fleek 9mo ago
  > 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.
  - Rochus 9mo ago
    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).

Rochus 9mo ago

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.

patrickg 9mo ago
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. )
- Rochus 9mo ago
  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.
  - gucci-on-fleek 9mo ago
    > 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.
    - Rochus 9mo ago
      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. My focus is on stability. The idea was to go with a minimal system and even integrate luatex-fonts-merged.lua as part of the binary, so there are no external dependencies. 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.
      - patrickg 9mo ago
        LuaHBTeX support has improved in the current version (next year's TeX-live), for example support for subsetting fonts.
        Rochus 9mo ago
        But this requires C23 and C++17 now, isn't it?
        gucci-on-fleek 9mo ago
        The dependencies might have a minimum C++ version, but I'd be pretty surprised if the core LuaTeX files couldn't be compiled with C99/C11. The recent C23 commits are just about adding support for compiling in C23 mode, so the main change is no longer using the implicit "everything is an int" function prototypes.
- Rochus 9mo ago
  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?
gucci-on-fleek 9mo ago
> 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.
- Rochus 9mo ago
  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).