Tectonic is forked from the XeTeX TeX engine. However, the build process for XeTeX (and all other mainstream TeX engines) is extremely baroque:
1. The original Knuth sources are written in a language called WEB (which is basically used by nobody else)
2. Those sources are then patched with a series of “change files” due to restrictions on distributing modified sources
3. These patched files are then converted to the Pascal language using some custom processing scripts
4. That Pascal code is then converted to C code using additional custom tools
5. Those C files are then compiled against a set of extension files and libraries written natively in C and C++
One of the big motivators for the launch of the Tectonic project was to break out of this ridiculously unwelcoming development process. Tectonic is based on the C/C++ files that emerge from the XeTeX build process, and is gradually translating that code to modern Rust.
While the core TeX architecture and XeTeX are largely stable, they do, however, evolve with time. This repository recreates the final XeTeX C/C++ files from their source, so that modifications can be ported into the main Tectonic codebase.
https://github.com/tectonic-typesetting/tectonic-staging/blo...
Tectonic is a cool project, but hasn't seen any significant changes in a few years---and likely won't anytime soon. It seems we maintainers don't have the time and motivation to put serious work into Tectonic.
I haven't looked at the code in years (and thus may be wrong), but here's a quick overview:
Tectonic's code consists of thin bindings to /harfbuzz/graphite/etc and a vendored XeTeX (in C, with some tweaks to make the build easier), driven by Rust that tries to keep the TeX environment predictable and sane. A few components have been fully ported to Rust (bibtex, spx2html), but the project is very unfinished.
I've looked into the dark corners of TeX when I worked on Tectonic, and it is not pretty. TeX relies on a stack of evil hacks and esoteric behavior that is very hard to replicate, and very difficult to expose in an ergonomic way. This is true of the core system, and of many packages on CTAN.
A quick example: code highlighting does not work in Tectonic. The canonical solution is https://ctan.org/pkg/minted, which spawns a python process to style your code. Reproducibility is one of Tectonic's selling points, so we cannot replicate this behavior.
With https://typst.app/ as good as it is, there's little motivation to modernize TeX---especially considering the effort required. Typst _is_ modern TeX, and I'd rather spend my time there.
It is so snappy and with great error messages. I encourage people to try it out. The typst tutorial is very approachable.
Nowadays, with Typst existing, it's vital for TeX ecosystem to solve these issues, since none of them are present in Typst. Projects like Tectonic would solve this for TeX, but they lack enough hands and (maybe) financial support.
Otherwise, using TeX only makes sense nowadays only if 1) you already have some templates 2) some features are still missing in Typst 3) you are just forced to use TeX/LaTeX for whatever reason.
I'm writing two books, both in LaTeX.
I really don't get what the problem is.
It reminds me of that very embarrassing dance we used to do around 2008 :)
The pdftex engine is pretty much a dead end these days and I would only recommend its use for compiling legacy documents.
That said, the biggest problem is nothing to do with the source code of TeX. The change file mechanism is pretty straightforward and there have been tools for decades to allow application of more than one change file against the source, although with the standardization on web2c in the build process as well as better cross-platform C compilation in 2026 vs 1982, there isn’t the proliferation of platform-dependent change files that there were in the 80s when people were compiling on Pascal compilers that supported different subsets of the language.
But as I was saying before I got into that digression, the source language isn’t the issue with TeX so much as the basic architecture which is highly coupled to the limitations of computers in the late 70s/early 80s when even 7-bit ASCII couldn’t be assumed to be consistent between systems¹. As much as I enjoy writing TeX macros and can do wonderful things with them that most people would consider dark magic, it’s a cursed way to do programming and has no parallel in any other programming paradigm.
⸻
1. The SAIL platform at Stanford where Knuth did the initial work, for example, had ↑ in the code space ASCII designates as ^, and IBM mainframes all used EBCDIC which has the complication of having | and ¦ as two separate characters both of which were typically mapped to | in EBCDIC to ASCII conversions with the reverse conversions arbitrarily choosing one of the two characters so that there was no guarantee that you’d get the expected character in your text file conversion² or your ASCII terminal controller.
2. Which is yet another reason why non-Unix operating systems would have distinct text and binary modes for opening files.
Thank you for fully fixing LaTeX for me.