I used it a bit recently and it is brilliant. Instead of lugging a huge TeX installation around you have a single reasonably sized binary. When you run ’tectonic file.tex’ it will download everything it needs on the fly. If you want to run it without internet access you can sort of freeze the downloaded files and run tectonic with your *.tex plus the frozen bundle.
It also claims reasonable error messages but I only ran it on error-free files, so I cannot tell.
One small downside is that in my direct comparison with lualatex it was always marginally slower.
Another one is that it is not a rewrite but still based on the old TeX code.
I think tectonic is a great project but generally speaking I find it quite disappointing that we do not have 100% compatible LaTeX with a modern codebase. And that is not even because the old code is bad - not at all. It's just that a pure Rust or Java implementation would make it so much easier to integrate into other projects. An audited TeX core we could run on untrusted input would be another benefit.
Which brings me to my last point: When researching tectonic I found a fork that attempted a pure Rust port and it nearly worked with examples. There is hope...*
Why rewrite TeX? To me TeX is one of the example of what a software project should aim to be, arrive to a stable version where it does what it should do and it work reasonably well. That was the initial idea of Knuth (in fact the version is a number that approaches PI one decimal at a time).
This is the contrary of the "modern" philosophy that says that we need to constantly modify, update or rewrite a software in "modern" languages even if it's a huge effort and risks introducing bugs that were not present in the original version.
Well, at least if we want to rewrite it let's just have to wait 10 years, then we can fed all the codebase to ChatGPT and ask for a new fancy Rust version!
Regarding of integration, TeX follows the (to me still relevant) UNIX philosophy that a software can be called by another software and the input/output communicates in a pipe. Nowadays we have even containers that let us distribute the software as a single unit so we don't have to worry about installing multiple files on a system. Not a big deal, in the end.
1. Most people aren't compiling with tex->dvips->ps2pdf anymore, most people with basic requirements compile with pdftex for more robust hyperlink and navigation pane, etc. features
2. People who want Unicode support and support for modern font files are using xetex or luatex
3. What has been proposed isn't a new tex compiler but more like a package manager for 3rd-party tex packages, using the already established xetex compiler to compile. Whereas historically you would download the whole distribution (or a predefined subset thereof) onto your system versioned by year (e.g. TexLive 2020) eating up GiBs of space, this allows you to download just what you need for your document.
not tex based, but uses CM fonts. I really think that trying to update the programming parts of TeX is necessary. sadly I'm struggling with fonts in svg figures.
but to suddenly see applying effort in this area and getting real traction is treat. so many thanks for the luminaries that put up the last one, but maybe its time for some rework after 40 years.
A new typesetting system will be very hard to get people to adopt. There are a million packages and existing documents that would have to be ported over. At this point, compatibility with TeX is a critical feature, not just a nice-to-have.
New typesetting systems are a dime a dozen and none of them is getting anywhere. Also in almost all cases HTML/CSS is what you want to use anyway. TeX is pretty niche but it fills that niche perfectly. A 100% compatible LaTeX that plays nicely in today's infrastructure is all I want.
Isolation is a good second line of defense. It's not going to prevent malicious input to produce malicious output. At least not until you go as far as Qubes OS and you squeeze everything through a rasterized bitmap.
Not really what you asked for -- but there is an interactive modern typesetter that is programmable and works on trees. It's called TeXmacs - you may want to check out what it can do -- https://www.youtube.com/watch?v=H46ON2FB30U
It's a TeX distro that only supports the XeTeX engine. A far cry from "modern", as XeTeX is an abandoned engine that always had quirky compatibility problems.
And it's not "self-contained" either if it downloads packages from the Internet.
XeTeX allows me to use the system’s Truetype/Opentype fonts and Unicode without any of pdfTeX/Metafont voodoo necessary in previous times, and it did this flawlessly for more than ten years for me. LuaTeX took ages to finally get a 1.0 version, so there was at least a period of 8 to 10 years where XeTeX was simply the best and only solution.
Isn't it nice to get your software directly from the people who wrote it? At least I'm confident any malicious edits were made intentionally. If I add a distro middleman who knows what they messed up mucking around for no good reason.
Let’s say, for example, that I invite a friend over and offer them a glass of water. Would you be similarly upset to find that I don’t recommend that they first send a sample of the water to be tested for purity before consuming said glass of water? I mean, don’t get me wrong, I would be fine with my friend being cautious and wanting to get the water tested (though I doubt that would ever happen in practice)… but if he trusts me to give him clean water, I doubt you’d raise any fuss over him just downing a glass.
Why/how is this any different? Anyone that wants to inspect the shell script can amend that line to first save and view the script. Are you thinking it’s never appropriate to trust such a script implicitly? If that’s the case, I’d love to hear about your workflow for checking the packages you install (e.g. debs can run arbitrary post install scripts, and do you know that a malicious actor with signing keys didn’t taint the binaries therein?), how you inspect all JavaScript for sandbox escaping exploits before viewing anything on the web, how you’ve ensured your hardware itself isn’t backdoored, etc.
The complaints of piping directly into shell from an HTTPS server strikes me as nothing more than a “no real technologists does $THING!” sort of elitism, though I’m open to being shown otherwise. A non-answer would be to propose that one first fetch a package signing key and install from your package manager of choice — if the script we’re complaining about can’t be trusted, there’s no reason to trust that the key file is any better with it being hosted in exactly the same way… unless you’re going to propose that you use something along the lines of web-of-trust to inspire further confidence that the signing key is authentic; at that point, though, your problem is with how 99.9% of third-party software packages (with respect to your distro of choice) are distributed - every PPA I’ve ever seen (docker, mongodb, whatever) at best tells you to fetch a key from some HTTPS server, and that’s all. It would then strike me as suspect to single out curl|bash (while additionally implying something about Rust users).
I’m well aware of that. I didn’t make it explicit (as I thought it logically followed) that one would execute the local copy after review. Even putting aside the security aspect, downloading something twice makes little sense, so I thought the fact you would execute the saved file (again, after review) was pretty obvious.
In other words, you are saying that an HTTP server can detect distinguish between when the client is doing `curl $url | sh`, and when the client is doing `curl $url | sh -c 'cat > /tmp/file'`.
I'd love to hear the mechanism that the server would use to do that, if you have the time!
I'm sorry I just saw this, but the idea is that sh will read as it executes so you can detect it passively. If you make it `sleep 1` you can detect on the server side that your call to send() hangs until sh proceeds, for the same duration as the sleep. You need to put enough content to make the TCP buffers fill up, but that can be done with all those function definitions that you tend to see in those scripts anyway.
Or the script could also signal through an active mechanism, a different innocuous-looking HTTP request that makes the server switch the content to a malicious payload if it happens at the same time.
It also claims reasonable error messages but I only ran it on error-free files, so I cannot tell.
One small downside is that in my direct comparison with lualatex it was always marginally slower.
Another one is that it is not a rewrite but still based on the old TeX code.
I think tectonic is a great project but generally speaking I find it quite disappointing that we do not have 100% compatible LaTeX with a modern codebase. And that is not even because the old code is bad - not at all. It's just that a pure Rust or Java implementation would make it so much easier to integrate into other projects. An audited TeX core we could run on untrusted input would be another benefit.
Which brings me to my last point: When researching tectonic I found a fork that attempted a pure Rust port and it nearly worked with examples. There is hope...*