This booklet showcases the advancements made in enhancing SILE’s math engine up to version 0.15.7+, along with a critical assessment of its current capabilities and the challenges it faces.
Edit: I initially said none of the upstream maintainers call it a rewrite, but I was wrong because the original author did in fact use that turn of phrase on several occasions including in the manual and in a talk.
I agree though it's not an ideal way to describe it because it has some many differences too. It's not a port of TeX to a different language. As you suggest TeX-inspired is much nearer the mark. It's a from-scratch effort at addressing roughly the same problem space. It does re-implement some of the same algorithms. One of it's input syntaxs resembles TeX (although the resemblance is not even skin deep). But no it is not a rewrite, just a new take.
SILE can also read XML or Markdown. I use it for publishing books from Markdown via Pandoc (there are several paths from Markdown→SILE).
And for the record the native SIL syntax resembles TeX at first blush but is actually vastly simpler because it is regular and uses a smaller set of possible syntax variations. If you don't like the look or feel of the syntax you can use something else for your source format and provide your own reader that generates a document AST.
Actually it just takes XML as an input format, but depending on your XML you need to provide a class that defines how to typeset each tag. For Docbook SILE has an example class with about 40% of the possible tags defined to something sensible. If you want to typeset Docbook you'd need to round that out to cover your use case. To date it is only supplied as an example of how to process XML.
On a scale of LaTeX=0 (absolutely inscrutable) to Rust=10 (holds your hand through the fix) I would say SILE is about a 5. Caveat, I speak as one of the authors. It helpfully traces the location of any problem to an exact location in your document, mostly clarifying what it was trying to do, has a trace stack with code locations for everything it was trying to do leading up to the problem, and in many common cases has sensible descriptive errors. That being said if even as a contributing author I only give it a 5 it clearly has room to improve!
Yes it comes with its own context-free syntax that (despite some surface resemblance to TeX) is quite easy to parse. It can also ingest XML and some other formats.
The whole point is you shouldn't have to manually balance columns in a spread. Obviously a round trip from source to output to fiddle with balancing every spread would be tedious. But if you can say "For this content I want to use spread X defined as this shape and balanced in this way" and then be able to fiddle with your content and have your spread always work, then where is the tedium? That's what SILE is supposed to do.
Many publisher's workflows involve a round of content editing bouncing a word file back and forth, then a period where a typesetter uses InDesign or similar to lay it all out, then it goes to press. You can't keep copy-editing after the designer takes over. With a workflow using source documents in Markdown and typesetting handled by SILE I am able to allow copy-edits to book manuscripts up until minutes before going to press.
GPU's are good at massively parallel tasks. Compression is, almost by definition, not a parallel problem. If you want speed you can break it up into chunks and if you are optimizing from throughput there are gains to be made there. But if you are optimizing for compression, the more chunks you break the task up into the less opportunity you have to find ways to compress it. For example a fast compression tool creating an archive of files might split up each file into a different thread which gets the job done fast, but it will loose out on huge gains in compression if there are common parts to files that could have been compressed if there were processed as a single blob. GPUs are designed to do lots of small chunks of work in parallel, CPUs are better at doing bigger jobs faster.