I'd like to announce the release of version 0.1.5 of Tectonic, a complete, modernized, self-contained TeX/LaTeX engine. TeX is a language for precision typography of technical documents.
I've been working on this under the radar for a while, but I think it's progressed far enough where it's time to start advertising it a bit more widely.
Right now, Tectonic primarily delivers a command-line client that replaces standard TeX engines. Unlike other TeX engines, Tectonic:
Downloads resource files from the internet on-the-fly, preventing the need for a massive install tree of TeX files
Automatically and intelligently loops TeX and BibTeX to produce finished documents repeatably
Has a command-line program that is quiet and never stops to ask for input
Supports modern OpenType fonts and Unicode
It is delivered as a Rust crate that can be embedded in a variety of other contexts; the Rust API wraps ~120,000 lines of C/C++ code. Tectonic is derived from the XeTeX extension of the standard WEB2C TeX engines. The pre-built bundles of support files are from TeXLive and hosted by JFrog Bintray.
Current areas of work are:
Reducing the dependence on system libraries to make the code easier to install and more portable
Gradual refactoring of the backing code to not be such a mess (seriously, you don't even want to know)
Adding support for modern HTML output
This last item is something I've been working towards for several years. When the pieces come together, I believe that Tectonic will be able to reproducibly typeset technical documents with best-in-the-world output to both PDF and web-browser formats. It will take some time to get there, though.
Here's the GitHub repo:
Questions and contributions are welcome! I'd love to recruit folks who might be able to contribute to the project in any of a variety of ways. The GitHub issues page is the place to start.
It's "using" XeTeX in the sense of embedding all of the code, so I think it's fair to call it self-contained. It has no runtime dependencies besides system font and image libraries.
@G2P No I hadn't ... I guess I don't have a great sense of what the uptake of Flatpak has been like. In general, I'm having trouble deciding what distribution method(s) to favor, since there are so many options and I only have so much time. Even anecdotal evidence about which methods give the most bang for the buck (from you or anyone) would be very helpful!
Would really appreciate a simpler way to install. cargo install fails on some dependency. Would it be feasible to host prebuilt binaries for some common arch/os on Github releases?
Or better instructions for how to install the dependencies on various systems.
@ramn Yeah, still trying to figure out what to do here — I've gotten some interesting suggestions, though. Please see the GitHub issue, and, in case you haven't seen them, the developer notes which include some build instructions for those who can't or won't use the Anaconda method.
One of my biggest complaints about LaTeX (I'm using LuaTeX) is how errors are handled. Very often it's impossible to track down the exact line that caused an error and error messages are meaningless. I understand it's because TeX is a command processor and many (most?) syntax constructions used in LaTeX are implemented by packages, but anyway, is tectonic better in that regard?
I would say that the answer is: currently, it's somewhat better; in the future, I hope it will be much better.
For instance, Tectonic automatically turns on the file-line-error option that some TeX engines have to actually report where errors came from. That's nice. We also have the engine give up on the first serious error, which IMO usually leads to a better UX. And TeX's chatter is hidden by default, so that it's easier to locate the messages for certain errors. (For others, the error message is mixed in with the chatter so we have to show it all.)
And overall, Tectonic is happy to change the UX of the command-line engine to make it more human-friendly, so the goal is to improve its behavior in all of these regards relative to the previous engines. Better messages, more traceability, etc.
A really interesting project!
What would really be great if you could use HTML with CSS instead of this terrible LaTeX to create PDF files of the same print quality!
I think the "of the same print quality" part would be hard.
HTML/CSS was never designed for printed documents, and it shows in many places. Things like title pages, page breaks, labeled figures + references, bibliography or tables of figures/contents are unduly hard to do in web tech because the underlying infrastructure is heavily biased towards infinitely scrollable screens with no notion of page or clearly defined internal organisation. And then let us not forget that LaTeX is mostly about easy mathematical formulas, which are a bit of a mess on the web (What do you prefer ? An unreadable XML dialect which never managed to reach cross-browser support ? Or a bloated Javascript library perhaps ?).
A cleaner replacement to LaTeX which leverages lessons learned (e.g. by using a saner programming and compilation model) would be useful, but I do not think that HTML has what it takes to be this replacement.
As much as I hate the language of TeX/LaTeX (from the need to throw % all over the place to suppress paragraph breaks, to the completely psychotic rules of command expansion, to the fact that all the names I'd like to use for my commands are taken by things I'd never use (but my packages use them and I don't want to break my packages!), to how align enviroments choke whenever you have a blank line in them, to good god how are you supposed to escape characters in a filepath
[big breath]
...as much as I hate the language of TeX/LaTeX, any attempt to replace it is going to be faced with the impossible task of adoption by basically half of the entire scientific community.
So I'll gladly settle for something that just fixes all the problems with pdflatexthe program.
(Like all the auxiliary files it dumps directly next to the files I actually care about, or the tiny error messages that it always hides somewhere between 15 pages of debug output and the complete and unabridged works of William Shakespeare, or the interactive prompt that keeps somehow managing to come back from the grave no matter how many CLI args I add to kill it, or the whole pdflatex-bibtex-pdflatex-pdflatex-bibtex-bibtex-p̀dflate҉x͞-c̴̀͞t̸͘h́u͜lh͏́̕u͘-̡̨f̡h̕t̸̨͟a̡̧g͜n̵-͝
That is not completly correct; since HTML 5 there are things like Figures and Captions, just like in LaTeX.
In fact, mathematical formulas are a problem, because this MathML is even uglier than LaTeX, and it already has its reasons why XHTML is dead.
But already the tables in HTML, especially in interaction with CSS, are a lot more powerful; while in LaTeX you have to constantly search for any packages to get more than just a bad result. That's why I add smaller tables in LaTeX as PDF (designed and created with LibreOffice).
In LaTeX I miss massively the clean separation between distinction and design. In addition, you can easily invent your own tags in HTML, and design them with CSS, the browser displays everything. :)))
A HTMLtoPDF compiler could translate the markup of the text in HTML5 – plus supplements and specified by CSS templates – into nice printable PDF's, under adopting and using the algorithms of TeX.
Why don't you just write markdown and sprinkle latex for math formulas in the same file, than use pandoc to get a fancy latex document...? basically latex is great until you don't have to manually write it.
I just wanted to comment that literally every single one of these issues is something that I have done my best to fix in Tectonic (The buried error messages are still a problem, but at least Tectonic hides the output if nothing fatal happens.)
(The buried error messages are still a problem, but at least Tectonic hides the output if nothing fatal happens.)