Thank you (author here). I deliberately used the default settings. Typst mentions settings for the line breaking system in the manual (for example you can set the penalties for changing interword spacing between lines), the speedata publisher can switch on margin kerning.
There might be settings to speed up things, so if any of the authors provide me with the settings, I'd be happy to implement those.
I benchmark six different typesetting systems, typst ist by far the fastest. This article describes why the speedata Publisher is still my choice for producing product catalogs.
They probably added text to their link submission. It’s not immediately clear that this text shows up as a comment indistinguishable from anyone else’s.
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 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?
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 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.
> 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.
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.
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).
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.
Thanks. The HB C++17 dependency is already a show-stopper for me. I want to be able to build everything on GCC 4.8, or even better 4.7. I also did some research what actually changed since 1.18.0 and didn't find features my project would depend on.
I have ca. 190 test cases on which I run my software and compare the md5 sums of the resulting PDF. If they are not the same, I create a PNG for every page and compare visually with imagemagick.
The trick is to remove all random stuff from the PDF (like ID generation or such).
This takes about 3 seconds on the M1 Pro laptop. I think this is very much okay.
I have a related feeling about TeX. It has superb output quality but the programming is awful. When LuaTeX finally arrived a few years ago, it was possible to do almost everything you have done before in the TeX language (starting with \backslashes) in Lua.
I have (shameless plug) created a database publishing software using this technique (https://github.com/speedata/publisher/). Once in a while I have to use LaTeX and it feels a bit old school to do the macro programming.
My next project is to rewrite the TeX algorithms in Go - see https://github.com/speedata/boxesandglue. Already usable but not TeX like in any way (this is just a library, not a frontend software like TeX)
I feel the same way! I also feel like the LaTeX crap on top of Plain TeX is crap and it fills me with rage when I try to find info about TeX and always get back something assuming LaTeX.
Various senses that concur.
It has, in addition to the line-breaking algorithm, a global page-breaking algorithm ... and for the rest may I suggest reading (it's brief) section 4.2 of GNU TeXmacs, A free, structured, wysiwyg and technical text editor, J. Van der Hoeven, Cahiers GUTenberg, no. 39-40 (2001), pp. 39-50, that you can find at the official website of the journal at http://www.numdam.org/article/CG_2001___39-40_39_0.pdf
Did you try to enforce the AGPL somehow? In the sense that the user that puts it on a (web)server must provide the end user the source code? (The 'A' in AGPL).
Not really. It's an application you install to your internal network and most probably do not make it accessible publicly. I have no way to know who and where has installed it. I assume that the app is forked in Github and the changes to disable license key check are also committed to that fork, so this would make it valid in terms of AGPL.
> It's an application you install to your internal network and most probably do not make it accessible publicly.
If people don't make it accessible publicly, then the AGPL isn't really imposing any obligations on them, even if they modify the code. It's unclear to me exactly when what you did would lead to someone paying when they otherwise wouldn't.
A lot of people do not care about licenses at all. No matter what you list as the license, they will do so if they can download and run it. Over the years, I have tried this multiple times where I provide the same code under a copyleft (free) license and commercial or permissive license (paid). Not a single time I've had anyone come to me and pay me to make it around the copyleft license. Any time someone has purchased the other option, it has been because of potential support options, etc.
So in EmailEngine, I added a license check. The code is always the same, but if you do not provide the license key (you need to pay to get that key), EmailEngine does not work correctly. Specifically, it stops processing email accounts after 15 minutes of runtime. You have to restart the application to get it functioning again. You would have to modify the source code to overcome this, but EmailEngine is distributed as a binary. To edit that code, you have to download it from Github, modify it and figure out how to run it. It's all straightforward, so it's not an obstacle for anyone with enough dedication. For others, it is easier to pay for the license key than to figure out how to circumvent it.
Did they ever detail what happened, they kept saying nothing has been lost and they were ready to return the site, any minute now, I gave up looking after a few months assuming they'd had some sort of deletion accident they weren't prepared to confess.
IMO contributors deserve to know what happened still. I think there was a lot of agreement that a torrent backup should be made available so the responsibility for the OCAL community's work didn't have to rest with one (?) person who seemingly didn't have time to manage things.
I give away my database publishing software (https://www.speedata.de/) for free and make a living with offering services (helping companies producing high quality product catalogs and datasheets etc. using the software) Its not much, but I live a happy live.
I spend about 1/2 of the time doing services and 1/2 hacking on the software. Quite often, customers are paying for new features in the software so it is paid hacking. Great!
I started with a closed source software but I opened it shortly after. So I didn't start with this in my mind, but since I love open source software, I had the feeling that I should open it and try my luck. I love the idea of the GNU projet.
There might be settings to speed up things, so if any of the authors provide me with the settings, I'd be happy to implement those.