This is an exciting project, and one that I think has an immense amount of potential. I read through sections 3, 4 and 5, and will take a look at the rest at some point, but overall the language and compiler seem feature-full given how new this is! It already supports a good portion of what many people use Latex for (text, alignment, equations and code).
I haven’t played around with it yet, but the language looks well designed and you can definitely see the Rust influence. I think the biggest hurdle to replacing Latex is going to be library support, and the emphasis on making a real language vs. macros will hopefully help jumpstart things. I haven’t seen what the errors look like, but can’t get worse than latex.
I hope this project takes off, a user-friendly alternative to Latex with the same power is needed. It will definitely take a long time to get to feature-parity with Latex, but this seems like a fantastic start!
Hear, hear! My only concern is this wording in the about page:
We will publish Typst’s compiler source code as soon as our beta phase starts. From then on, it will form the Open Core of Typst, and we will develop and maintain it in cooperation with the community.
I sure hope they plan to publish something
at least as usable as latex (i.e. all the parts needed to compile a paper to common output formats are there)
under a license that allows inclusion in mainstream distributions
People who write papers, articles and books care a lot about not losing their work (e.g. if the startup goes under). I don’t write papers any more but I’m sure I wouldn’t have considered typst before those conditions were met.
That is the plan! The open source part will cover the whole compiler and CLI and the license will probably be a permissive one (e.g. MIT/Apache-2). We’re only keeping the web app proprietary, but don’t want to lock anybody into it, so you will always be able to download your projects and compile them locally.
The text editor I’ve been working on for several years is able to convert Markdown to PDF. The engine transforms Markdown into XHTML then uses ConTeXt to typeset the XHTML document against a “theme”. One reason I wrote KeenWrite was to give me the ability to use variables while writing:
Hey, I’m the author of the thesis. As already pointed out in another comment, it is completely typeset with Typst. Typst also doesn’t use (La)TeX in the backend, I just used a LaTeX-like font as to fit the typical thesis style. Luckily there was no requirement from the instituation.
I only had a chance to skim the thesis, so sorry if I missed something, but it looks as if this reproduces the LaTeX mistake of combining markup and formatting instructions. Do you have conventions for separating them? When I write LaTeX (I’ve written four books in LaTeX, among other things), I have to be very careful to not actually write LaTeX, but instead to write LaTeX-syntax semantic markup and then a separate preamble that defines how to translate this into formatted output. If I don’t do that, then exporting to something like HTML is very hard. I didn’t do this for my first book and the ePub version was a complete mess. I did for later ones and was able to write a different tool that just converted most of my semantic markup into class= attributes on HTML elements or, in a few cases, used them as input for some processing (e.g. headings got added to a ToC, references to code files got parsed with libclang and pretty-printed).
This is one of my favourite things about SILE: your input is in some text markup language to describe the text and a programming language (Lua) to describe transforms on the text.
You can combine markup and formatting instructions, but you can also write semantic markup in Typst. Typst’s styling system works with the document’s structure: A show rule for an element defines the transformation from structure into output (or other structure that is transformed recursively). Since the show rule can execute arbitrary code, you have lots of flexibility here. You can even apply other rules to the content that shall be transformed, so e.g. your transformation for figures could redefine how emphasized text is transformed within them.
At the moment, you can only use show rules with built-in structural elements, so user-defined functions don’t work with it, but this is something we will support in the future. And since PDF is the only supported format for now, in the end your show rules will transform the document to a fixed layout. However, more export formats (primarily HTML) are on our radar and we could then provide different sets of primitives for these other formats. This way, you could have a second set of show rules that define how to export the structure to XML.
Thanks. I’ll look forward to seeing what it looks like with HTML output. It’s a very different problem, but a language that can generate both TeX-quality PDFs and clean semantic HTML would be very attractive.
I was wondering the same, and then wondered why there aren’t more of these sorts of systems that just output TeX as a backend language. I suppose part of the goal is not just the language, but to reinvent the ickier parts of the TeX ecosystem.
Looks like they’re building an app out of this. I like some of the ideas here.
I have worked in academic publishing and had to learn more than I strictly wanted about TeX’s internals. This looks fantastic. Nice work @laurmaedje!
This is an exciting project, and one that I think has an immense amount of potential. I read through sections 3, 4 and 5, and will take a look at the rest at some point, but overall the language and compiler seem feature-full given how new this is! It already supports a good portion of what many people use Latex for (text, alignment, equations and code).
I haven’t played around with it yet, but the language looks well designed and you can definitely see the Rust influence. I think the biggest hurdle to replacing Latex is going to be library support, and the emphasis on making a real language vs. macros will hopefully help jumpstart things. I haven’t seen what the errors look like, but can’t get worse than latex.
I hope this project takes off, a user-friendly alternative to Latex with the same power is needed. It will definitely take a long time to get to feature-parity with Latex, but this seems like a fantastic start!
Hear, hear! My only concern is this wording in the about page:
I sure hope they plan to publish something
People who write papers, articles and books care a lot about not losing their work (e.g. if the startup goes under). I don’t write papers any more but I’m sure I wouldn’t have considered typst before those conditions were met.
Thanks for taking this on!
That is the plan! The open source part will cover the whole compiler and CLI and the license will probably be a permissive one (e.g. MIT/Apache-2). We’re only keeping the web app proprietary, but don’t want to lock anybody into it, so you will always be able to download your projects and compile them locally.
How simple is the compiler to re-implement? What’s the ETD (estimated development time)?
Wow, this is really well designed.
The text editor I’ve been working on for several years is able to convert Markdown to PDF. The engine transforms Markdown into XHTML then uses ConTeXt to typeset the XHTML document against a “theme”. One reason I wrote KeenWrite was to give me the ability to use variables while writing:
https://github.com/DaveJarvis/keenwrite/blob/main/docs/screenshots.md
I have a series of videos coming out soon that demonstrates how it works.
This is very interesting, did a summary read and it looks rather good in concept.
I wonder if the thesis itself is typeset in the language?
It does look like standard (La)TeX, but that could be a requirement from the institution.
Hey, I’m the author of the thesis. As already pointed out in another comment, it is completely typeset with Typst. Typst also doesn’t use (La)TeX in the backend, I just used a LaTeX-like font as to fit the typical thesis style. Luckily there was no requirement from the instituation.
Well, you fooled me. :)
I hate that font, but it certainly makes it look authentically LaTeX.
I only had a chance to skim the thesis, so sorry if I missed something, but it looks as if this reproduces the LaTeX mistake of combining markup and formatting instructions. Do you have conventions for separating them? When I write LaTeX (I’ve written four books in LaTeX, among other things), I have to be very careful to not actually write LaTeX, but instead to write LaTeX-syntax semantic markup and then a separate preamble that defines how to translate this into formatted output. If I don’t do that, then exporting to something like HTML is very hard. I didn’t do this for my first book and the ePub version was a complete mess. I did for later ones and was able to write a different tool that just converted most of my semantic markup into
class=attributes on HTML elements or, in a few cases, used them as input for some processing (e.g. headings got added to a ToC, references to code files got parsed with libclang and pretty-printed).This is one of my favourite things about SILE: your input is in some text markup language to describe the text and a programming language (Lua) to describe transforms on the text.
You can combine markup and formatting instructions, but you can also write semantic markup in Typst. Typst’s styling system works with the document’s structure: A show rule for an element defines the transformation from structure into output (or other structure that is transformed recursively). Since the show rule can execute arbitrary code, you have lots of flexibility here. You can even apply other rules to the content that shall be transformed, so e.g. your transformation for figures could redefine how emphasized text is transformed within them.
At the moment, you can only use show rules with built-in structural elements, so user-defined functions don’t work with it, but this is something we will support in the future. And since PDF is the only supported format for now, in the end your show rules will transform the document to a fixed layout. However, more export formats (primarily HTML) are on our radar and we could then provide different sets of primitives for these other formats. This way, you could have a second set of show rules that define how to export the structure to XML.
Thanks. I’ll look forward to seeing what it looks like with HTML output. It’s a very different problem, but a language that can generate both TeX-quality PDFs and clean semantic HTML would be very attractive.
Page 8:
Got me fooled too, tho. So this is a testament to the output quality already. (It doesn’t do ligatures there tho.)
I was wondering the same, and then wondered why there aren’t more of these sorts of systems that just output TeX as a backend language. I suppose part of the goal is not just the language, but to reinvent the ickier parts of the TeX ecosystem.