I've moved all of my LaTeX-based content creation to Typst.
It's:
- Fast—Compiling my books would take around 1 minute (I often had to compile twice due to indexing). With Typst, it takes less than 5 seconds.
- Easy to write—I actually don't write it, I wrote a bunch of Pandoc plugins to tweak the output from Pandoc (I write all my books in Jupyter these days, so lots of markdown).
- Easy to read—I've used LaTeX for years (and wrote a bunch of tooling around it) and still couldn't tell you when to use a { or a [. Typst is very readable.
- Easy to script—Okay, I did write some Typst the other day. I migrated my LaTeX-based invoicing system to Typst. I created a list of objects with pricing and count and was able to throw it into a table easily. It has less code than my LaTeX version, which was using a library, and is easier to read. (I did need to write a function to properly format $ because that doesn't exist. A few rounds with AI made that easy.)
- Has great error messages—If you've used LaTeX, you know what I mean.
My needs are different from others, but I'm writing PDFs that need to be printed into a real book that looks professional. This includes front matter, footnotes, callouts, page numbers, page headers and footers, and indexes. I don't do a lot of math-heavy stuff, so I can't comment on that. And the widow/orphan support is a little weak.
This trips people up a lot once they do anything involving cross-referencing or bibliographies. But for some reason some people use latex for a long time and never hear about latexmk, which automates all that, and can even "watch" your files so you can edit and save and see your PDF refresh all in real time. (I've only used latex for papers or blog math, not big books; I can't imagine waiting a minute per change back in college, let alone on modern hardware...)
With your experience of both, have you found that Typst has fewer issues with conflicting/non-commutative plugins than LaTeX does?
Because that's where I lose the most time with LaTeX: packages often mess with the (piles of) global state in ways that sometimes conflict, and the only "solution" seems to be that, if you're very lucky, sometimes conscientious package authors will try to "detect" (through various hacks) whether some other known-conflicting package has already been loaded and adjust accordingly. I didn't see any mention in TFA of any module system or even local variables in Typst to contain this explosion of complexity, so I suspect it will be just as bad in this respect as LaTeX is once there are as many plugins available.
I think compatibility issues in LaTeX often come from packages that redefine the same macros in incompatible ways. This kind of things doesn't happen in typst because all user code is pure: a package can define 1) values or pure functions that can be imported (this makes them available only in the scope where they're imported) and 2) content that can be included in the document.
There's still potential for conflicts, for example content can contain elements that represent a state update such as incrementing a counter. Packages can define their own states for internal use, and the namespace is global, so they can interfere with each other if they don't follow good practice (prefixing state names with __package-name for example). And show rules can replace an element of content with another one, for example one package can replace verbatim code with a figure, and another package can format verbatim code. What happens if you mix them without limiting their scope?
But so far, I think the compatibility problems in typst are more of the "well, what do you expect?" kind. Compare to LaTeX where sensible code is broken when a package makes a small changes somewhere deep in the macro pile of cards.
For example someone here mentioned the example of one package changing "the" to red and another changing "the" to blue. This can be done declaratively in typst, and won't cause an error, but the result will depend on the order of declarations.
>compatibility issues in LaTeX often come from packages that redefine the same macros in incompatible ways
Absolutely. A related but more subtle problem occurs when macro A ordinarily calls a macro B, but a package redefines A not to call B at all (perhaps reimplementing part of B itself), and then, when the user includes a second package that redefines B, this latter package appears to have no effect.
Based on your explanation of Typst having a global namespace, I would expect such conventions (like a function A that by convention calls a function B, both of which can be redefined by any package) to arise in Typst just as they have done in LaTeX. (This risk would be much reduced if Typst didn't have functions as first-class values, but from the TFA, I see that it does.)
>Compare to LaTeX where sensible code is broken when a package makes a small changes somewhere deep in the macro pile of cards.
LaTeX has grown "a macro pile of cards" because (a) the base LaTeX system was not comprehensive/expressive enough to let users express everything they wanted to do "within the system" (i.e., by merely twiddling existing knobs in a composable way) and (b) because it is possible (indeed, relatively straightforward, at least initially) to make them.
Maybe Typst has a much more comprehensive and well-designed set of knobs, in which case the conditions will not arise that encourage the same "macro pile of cards" to form. Otherwise, I don't see any reason to expect that it will wind up any different.
The global namespace in typst is limited to "states", a rather specific feature similar to the global TeX counters for headings and equations. So it's possible for two packages to increment the same counter. Everything else is local. All functions and variable definitions are local, and every function is pure: a function call cannot have any side effect. In particular, a package cannot redefine a function.
(You may wonder how functions can be pure if they can increment counters.... The way it works is that you call the function and put the return value in the stream of content of the document. And this value can be something that says "increase counter X by Y". And when you read the counter, typst applies all such "counter instructions" that are in the document so far, and gives you the result.)
The special knobs that typst provides are the "set" and "show" rules. With "set" rules you can change the default values of elements created later in the same scope. For example "#set text(fill: red)" will make it so that all text created later in the same block of code without a specified color will be red. With "show" rules you can define transformations that will be applied to elements created later in the same scope. For example "#show math.equation: it => figure(it, caption: "An equation")" will wrap every equation in a figure with the given caption.
I think the main reason LaTeX is a pile of cards is because TeX is terrible as a general purpose programming language. Just an example: the fact that a macro called with particular arguments will behave differently depending on the current state of catcodes is a craziness that's hard to imagine when you think in terms of "normal" programming. And the whole ecosystem of amazing packages that make LaTeX so useful, they need to do the kind of things you'd normally do in a normal programming language, so these packages end up working around the oddities of TeX in ways that make the whole thing a pile of cards.
With its design based on pure functions, I'd say typst is at the other end of the spectrum in terms of how easy it is to write code that works reliably without interference from other people's code.
I dpn't remember the details, but IIRC in LaTeX I had a problem bacause babel made the > symbol active in s
Spanish, and xypic used non-active > to draw arrows.
I imagine you're projecting how LaTeX works onto Typst, though despite years of use and a PhD in PL I never really figured out how LaTeX works so I'm not certain.
I don't think Typst has a lot of global state to get corrupted. Like, if one package defines a variable `foo` and another package defines a variable `foo`, and you use both of them (and don't try to import `foo` from both), it's not like those `foo`s are going to conflict with each other. Is that the sort of issue that LaTeX packages run into?
Likewise, you don't modify typesetting in Typst by modifying global state like you do in Latex. You use `set` and `show`, which are locally scoped. You never need to, like, set the font size, then write some stuff, then remember to set it back. You just put `set font(size)` around precisely the stuff you want to be bigger.
In general, with the TeX "engine", you can locally scope most changes by simply wrapping them in braces {}.
However, if you have a need to override something globally (eg. a global heading font, or spacing at the paragraph level), there is really no way to do it other than doing it globally.
How would Typst solve this without having the same problem? Eg. how can I have a package that sets every "the" in red colour, without it interfering with a package that sets every "the" in blue or titlecase?
Perhaps it's structured better (I would hope so, with ~40 years of learnings since TeX was introduced), but the problem seems unavoidable if you allow things like the above.
>how can I have a package that sets every "the" in red colour, without it interfering with a package that sets every "the" in blue or titlecase?
Exactly.
Broadly, the things you might want a package/plugin to do can be categorised as "local" (e.g., add some new type of content in a fixed-size box that the layout engine can then treat the same way as it treats any other such box) or "global" (e.g., change where floats appear). Making local effects play together can be easily handled with standard PL ideas like lexical scoping, but doing the same for global things is much harder: it strongly depends on exactly what knobs (API) the base typesetting engine provides. We now have design patterns like Observer to help make creating such "global" effects simpler, assuming that their effects are genuinely orthogonal, but what if they aren't?
A plugin that sets each "the" to red clearly conflicts with a plugin that sets each "the" to blue: at most one of them can "win", so which is it? Does it depend on which plugin was loaded first? If so, that's no better than LaTeX, and will become an ever-growing headache as the ecosystem grows.
OTOH, a plugin that sets each "the" in italics can sensibly interoperate with a package that sets each "the" in bold -- and can even produce the same results regardless of which was loaded first, because these effects "commute". These effects could be implemented by having the base engine expose an event that can be listened to by any interested plugin.
ETA: The main reason LaTeX is a pain is because it makes no real attempt (that I can see) to manage any of the inevitable complexity of "global" effects. (Admittedly, this is a tough design problem.) I don't yet see signs of anything better from Typst, thus I assume it will become roughly as painful as LaTeX in time.
I disagree with the assumption that the red/blue conflict should produce an error. In real life most of the time you want one style to override the other. So in this simplistic example at least, having the result determined by the order is the correct behavior (and it's what typst does).
More generally, if your system generates errors left and right, you end up making it hard for users to find a combination of packages that work. It's better to make them work error-free as much as possible. And the concept of "overriding" is natural and useful.
I think typst does make a nice attempt at managing global effects. It's nowhere near perfect but works pretty well already. For example it's super easy to implement your example with two packages, one applying bold and the other applying italic:
Template from package A: #show regex("\bthe\b"): set text(style: "italic")
Template from package B: #show regex("\bthe\b"): set text(weight: "bold")
You can use both templates in any order, typst will correctly render "the" in italic bold.
> A plugin that sets each "the" to red clearly conflicts with a plugin that sets each "the" to blue: at most one of them can "win", so which is it? Does it depend on which plugin was loaded first? If so, that's no better than LaTeX, and will become an ever-growing headache as the ecosystem grows.
Just loading a package in Typst won't perform side-effects. Instead what they can do is giving you some function that will apply the styling to any content passed to it. It will be up to you to choose to wrap your whole document in such functions in order have them apply globally, which can be done conveniently with something like `#show: foo_template`, where `foo_template` is the aforementioned function.
This still has a chance of "incompatibility", like in the blue/red example, because you might do this with two functions from two different plugins. However it is up to you to do this, and it will hopefully be clear that you're modifying global styles in two different ways with a specific order between them.
To be fair though I should mention that some packages will expect you to use `#show` with their functions, so sometimes it will be difficult to avoid using it multiple times.
It's been a while, but I vaguely remember that the hyperref LaTeX package for making URLs didn't play nicely with certain other packages -- possibly with one of the citation packages.
Sorry I can't be more specific. I definitely have memories of reordering \usepackage{} statements until "it worked"...
Regarding math stuff and graphics/diagrams, it works well too.
What I enjoy about Typst is the fact that the code is easy to write and read. Even code from some third-party library or template is easy to understand. There is a world of difference between this and LaTeX, which abstracts over TeX, and whose inner workings remain obscure even to experienced developers having used LaTeX over decades for tens of documents.
The compilation of Typst documents is indeed also extremely fast compared to LaTeX.
The runtime and libraries are lightweight and easy to install, compared to LaTeX distributions.
Writing custom logic or even a fully-fledged template with Typst is easy to do from day one.
The only reason I still see to use LaTeX nowadays is writing books and papers whose editor only accepts LaTeX.
I've switched to Typst some months ago and not once have I thought it might have been a mistake. The only thing I regret is that there is no automatic migration of older LaTeX documents to Typst.
Editors still have to be improved, though the Vscode plugin is absolutely usable.
> Easy to script—Okay, I did write some Typst the other day. I migrated my LaTeX-based invoicing system to Typst. I created a list of objects with pricing and count and was able to throw it into a table easily.
Interesting! Would you share your solution and/or tell us a little more about it? Thanks!
Ooh, very interesting! I produce lots of reports using Jupyter and nbconvert. I have a custom nbconvert template (which uses pandoc+jinja+latex under the hood).
I find the whole system to be a bit house-of-cards and I’d love to try alternatives. What’s your workflow for using Typst with Jupyter?
I've always bike shedded my own solutions because none of the existing tools did what I needed for physical books.
Pandoc does a decent job with connecting markdown to Typst. I have a few filters that I run to convert the notebook to markdown and some other filters that I run to change the output from Pandoc.
References in established systems like LaTeX work the way they do for a reason: you don't want to embed words in them (like "Figure" or "Section") automatically because it does not work across languages.
Serbian (and many other languages) have suffix declensions, so while "Figure 4" is "Slika 4", when used like "in Figure 4", you really need "u Slici 4" (and lowercase, really) instead of "u Slika 4" as produced by Typst.
On the plus side, it seems to use OTF locl tables for substitution glyphs for language, though it only partially works for Serbian (might be due to bad locl tables for LinLibertine which seems to be the default font).
I am sure it's not too hard to only get the reference number (eg. @foo.context.something?), but defaults should be good or maybe per-language?
I can see how they wanted to avoid authors having to hard-code the reference type if they change eg. something from an image to a table, but it's hard to make it smart enough for any language.
Hopefully they'll improve the reference system and multilingual support. But if you want a simple number for a reference, you can call "ref(<label>, supplement: none)", or if you want this to be the default for the @label shorthand syntax you can set it globally with "#set ref(supplement: none)".
Also typst knows the type of the referenced element. It's easy to write more elaborate rules that behave differently depending on the type. And the rules can also check the current language to generate localized references.
I played with this briefly, and saw that supplement can also take a function, which presumable how you make @wibble return '(34)' instead of 'Equation 34'? The function is passed the equation itself, so supplement: x => x makes the reference identical to the whole equation (!), but it wasn't obvious to me how to extract just the equation number from an equation x?
This is a really common idiom in mathematical writing: "from (1) we see that..." instead of "from Equation 1 we see that". (Randomly capitalising 'Equation' here is another controversial implication of using a fixed word string as a supplement.)
Agreed it could be improved fairly easily at this early stage, and even documenting 'standard recipes' would help. But I do think as a default, prefacing with a fixed string with fixed capitalisation is probably the wrong choice vs earlier systems which simply insert the reference number/letter itself and allow the user to word things correctly around that. Trying to make it do the right thing in context in a way that generalises across multiple languages is unnecessarily hard.
Embedding words like Figure or Section breaks not only declensions, but capitalization, too. Germans won't notice it because all their nouns are capitalized, and English speakers won't care because they're traditionally forgiving with unmotivated upper-case words in the middle of a sentence (including titles). But formally it shoud be "Figure 4" in the caption and "as we see in figure 4" in the reference.
"as we see in figure 4" is simply incorrect, though; expressions such as "Figure 4" or "3rd Street" are treated as proper names and must be capitalised, as would the non-nominal "third" in "Dritte Straße" if any German-speaking city were to have American-style numbered streets.
Those two cases seem completely distinct: do you have a source for the claim that labeling stuff in documents with type and number makes those labels proper names?
For addresses, that's usually listen in a language grammar as a rule.
That's what ChatGPT sometimes struggles to do correctly for Serbia : the rules are tricky and depend on the surrounding text. Eg. if you want to say "In figures 4 and 5", you are already struggling (even in English).
So even embedding latest LLM won't solve it so it's better to leave it to the author to do the right thing.
If Typst aims for eventually competing with LaTeX, getting outside the bubble of "everyone uses English" is a very good step to take. And it's good to take it early, when your system architecture is still easy to change and not implicitly ossified around englishisms.
Things like "if you ever want to translate your document from English to XXX, you will also need to port it from Typst to LaTeX" tend to be dealbreakers.
Typst authors being germans, one can hardly accuse them in the "everyone uses English" attitude.
Typst `dif` math operator (as in dx/dt) produces upright 'd', quite unexpected to ones used to slanted 'd' tradition.
> I would indeed expect an upright 'd'. It's an operator, not a variable. I don't recognize the tradition you're mentioning.
That's strange. I've never seen a math article in English with upright 'd' differential, only have seen it in German and Spanich articles. It's also
math italic in TeX (you can check Knuth's TeXbook).
In the very limited time I used typst it has been pretty amazing, but imho there is one missing feature that a LaTeX successor, but even more so, templating engine should have.
Come up or adapt a format, that can defer certain styling decisions to the consumer of the document. Stuff like, font, font size, line spacing, citation style, double or single column, numeration style, etc.
On a different note, we got to find a better way to exchange data than pdf reports. In my totally made up estimation about 10% of development time for enterprise software is spend on variations of these pdf templating tools and another 20% on extracting data from such generated pdfs.
You can do that in a couple different ways in Typst. First, if the user passes content into the template, then it's the user's content that ultimately gets to choose its styling. That is, there are three places that a style can be set:
1. In the content passed that the user passes to the template
2. In the template itself
3. By the user, outside the template
They take priority in that order.
OTOH, if the template really wants control, it can take optional styling arguments with defaults, and do as it likes with them. And if it wants content from the user that the user doesn't get to style, it can take that content as a string.
> Come up or adapt a format, that can defer certain styling decisions to the consumer of the document. Stuff like, font, font size, line spacing, citation style, double or single column, numeration style, etc.
We have that, it's called HTML. The use case is quite different from PDF though.
That was exactly my reaction after stumbling upon https://typst.app/universe/package/modern-cv/ I just want a replacement for ModernCV, not downloading MBs of fonts I don't want to use.
You can embed attachments in PDFs. This way you could include CSV or JSON files into your PDF report. For a quick way doing it with CLI see `qpdf --help=add-attachment`
There is no universally correct layouting. I for one absolutely detest epub versions of scientific books. Even if they are the official variant and not a generated one from some other format that understandably sucks, diagrams will be all around and I have to go back and forth and lose context. PDFs for all their shortcomings are a godsend and they do their single job perfectly. I much rather zoom in on my phone to a paragraph than look at a badly placed diagram taking up half a page in an unrelated context.
I've been looking into it.
It's `blazingly fast` (aside from the rust joke, it really is way faster than latex), the syntax is more "modern", consistent, etc.
The main problem is the popularity. It just does not have enough packages, at least for my use case.
I mainly do a lot of equations (simple math), and a loooot of tikz (forest, circuitikz, pgfplots, etc.) [https://gitlab.com/vslavkin/escuela/-/tree/main/5to?ref_type...]
I'm not a fan of tikz, but it's the only way to mantain the graphics homogeneous, clean, easily editable, compiled with the document and with links/references.
Cetz (the typst alternative) is years behind.
I've been thinking of contributing, but tikz is really complex, and I don't have enough time ATM.
Besides the typst packages, it also lacks the editor packages. I am an emacs user insert joke here, and I use AucTeX, which is a really great, and gigant package to edit latex (+cdlatex). AFAIK there's nothing like it for typst, which makes me way slower.
Another thing is that they changed the math syntax. While the latex one wasn't perfect it was insanely popular, because of its use on markdown and a lot of pages (and this was thanks to mathjax iirc).
The good thing is that something like latex or typst will always be needed, so there'll always people that want to have something like it; latex/tex isn't really great, and it has a really low entry bar.
Maybe I'll switch when I have more time to study it and make packages. (It could be as soon as next year or a late as... never)
> Besides the typst packages, it also lacks the editor packages. I am an emacs user…
The typst editor plugin for vscode is pretty great. It gives you a split view of source & pdf, and you can cmd+click on either side to scroll to the corresponding source / rendered output. It also does things like give you autocomplete on fields from externally referenced json data.
Obviously, that might be no help if you’re married to eMacs. But if you’re a little promiscuous with editors like I am, give it a try.
I don't know which of the several typists plugins are you talking about, but they all seem decent, but years from achieving the features auctex has.
Just to say, the most important features:
Well, the feature you mentioned of clicking the PDF and redirecting to the source.
Preview in the same buffer (window) as the code
It uses other regexps to recognize the enabled packages, and then adds the package's macros and environments to its list, so with a command you can open an environment or macro, and it recognizes which packages you are using, if you are in a math environment, etc. and shows only the ones you can use in the context. It's like a super-intelligent set of macros.
AucTex has also great support for bibtex/biblatex, and glossary/glossaries, both for using the macros and for compiling.
Automatic, intelligent, labeling.
And a lot more (altough this is probably the biggest latex package, there are a lot of other smaller packages that are also extremely useful) . Maybe it's not the hardest package to do, but it needs a lot of people and time to replicate, basically what typst is also lacking, for now.
The current actively-developed VSCode extension is Tinymist. Its workflow is great and addresses all your issues (to the extent they are even relevant to Typst):
> Well, the feature you mentioned of clicking the PDF and redirecting to the source.
Tinymist does this. Click on text and it redirects the document buffer to the corresponding source text.
> Preview in the same buffer (window) as the code
Tinymist previews in a separate tab for side-by-side real-time writing with a preview.
> It uses other regexps to recognize the enabled packages, and then adds the package's macros and environments to its list, so with a command you can open an environment or macro, and it recognizes which packages you are using, if you are in a math environment, etc. and shows only the ones you can use in the context. It's like a super-intelligent set of macros.
This sounds like an artifact of Tex. The standard Typst library is very thorough. And for everything else, Typst has automatic retrieval of community packages. Just add an #import and it just works:
#import "@preview/example:0.1.0": add
#add(2, 7)
> AucTex has also great support for bibtex/biblatex, and glossary/glossaries, both for using the macros and for compiling.
This just works with Typst in-the-box for bibliographies, and with the glossarium package for glossaries (just add with: #import "@preview/glossarium:0.4.2": *). But one thing a Typst IDE like Tinymist or the web service adds to the writing environment is an autocomplete for labels and citations. Just start typing the reference and get autocomplete options.
> Automatic, intelligent, labeling.
Not sure what this means, but you can add a label to headings, figures, etc. and quickly reference them with @label, and the current IDEs
It seems good, and there's an emacs version, altough simpler than auctex.
Not having the preview in the code buffer, isn't a dealbreaker, especially when typst is so fast, but it's still a useful feature.
The part of the packages I wasn't talking about a tex feature but an emacs one. When you import a package, it'll usually add environments or macros (in typst i believe they are called commands). Emacs would recognize thay you imported a package and with a shortcut you are able to quickly insert a command without writing it manually (because that's too much time... Like a template) It also recognizes the document type for inserting sections, and whether you are or not inside a math environment.
Albeit, looking a bit more in typst I think it's as mandatory as in latex. Commands tend to be simpler and shorter, especially sections. So maybe it wouldn't impact as hard as I had thought.
For references, using bib files, it would be almost as good as latex.
The auto labeling is useful for align envs or itemizes. AucTeX adds a label to each item or equation automatically. Again, not a dealbreaker, but would be great.
Reading a bit more, it seems that typst is a bit more different that what I had thought. I will not switch till cetz is more mature or I find another alternative.
Maybe I'll remake my Cv in typst just to try it out (+ my cv is horrible)
With typst you can get autocomplete for symbols imported from packages or defined locally. And your bibliography can use the same .bib files as latex if you want to. I’m pretty sure the typst editor plugins also know which mode you’re in and give you different autocomplete suggestions depending on the mode. But yeah, it’s probably still not quite as mature. But it is, in my opinion, much better designed.
What features do you want from cetz that you think are missing?
(And yeah making something with it is a good idea. You’ll get much more of a sense of it by playing around with it.)
I've been using it a bit and it works very well, altough it's hard to get used to its way to define ”environments”. About cetz, I miss mainly circuits. There's a plugin, but's years behind circuitikz or its alternatives. I haven't tried it yet, so I can't tell if the support for mindmaps, trees, etc. is as good.
Yeah I think its fair to say latex has a much more mature ecosystem. And we should expect nothing less from something made in 1985. Its almost 40 years old.
But typst is catching up as fast as it can. I find it very usable already.
Yeah, my guess is that it'll fall on either side of the same go/c vs c++/rust "simple rules with more implicit rules in your head" vs "complex tool with less in your head" divide in people's opinion.
I think it’s more like latex is like c++ and typst is like zig. C++ & latex have been worked on for decades, and has all this design baggage it carries around. An ugly macro system, weird “compile it 3 times” things. But it also has decades of work filling out the 3rd party package ecosystem and decades of stackoverflow questions and answers.
Zig & typst are rewrites from scratch with new ideas. The core is better designed, since they have been able to learn from what came before and have a do over. But they’re missing the decades of incremental work fixing bugs and filling out the ecosystem. So, yeah, I’m sure the eMacs plugin is worse for typst and latex. It’s all just … newer.
I have a similar "user profile" and find typst a much better experience. It's true CeTZ is not as mature, but it's much easier to extend where it's missing functionality (because you have a nice, normal scripting language to work with instead of a macro mess). But math is the reason I smile every morning when I open my .typ files. It's so clean and readable, and a pleasure to write, compared to LaTeX. It's also not as mature so I can imagine some things can be tricky to do in typst depending on your needs. But it does everything I need, and is only getting better (I see that several of the annoyances I found are getting fixed in the next release).
Can't comment on the AucTeX part, I'm using helix and typst support is not great but good enough.
Yeah, that's why I thought of contributing to cetz, the language is definitively way better. Although I think that for basic usage, I like the tikz way a bit better.
The main problem I'd say is circuitikz. It's a really big and versatile project, and I would need years to make it work.
However, thinking about it, it's not like anyone other than me cares about how clean my circuits are. They are high school notes, and the rest of my classmates are doing it on paper, but I haven't found a good alternative. One that probably isn't as clean as circuitikz, but easier, faster and easy to integrate to latex/typst
It looks nice, but it doesn't have as many features, altough I understand that, as typst is easier to write, a lot of things aren't needed.
I'll try it out when I have time
> I use AucTeX, which is a really great, and gigant package to edit latex (+cdlatex)
This is tangential, but have you any quick tips for someone looking to get started with AucTeX? I'm a comfortable Emacser who has started to occasionally think of some document I'd like to do in LaTeX (some maths questions for a student, or an overview of some topic). I've looked at AucTeX once or twice, and ran away thinking, oh, I'll do that some other time.
What is the order of events? Should I make a few really basic LaTeX documents first with a terminal, and then try AucTeX?
I’ve found that the best way to learn a new emacs package is incrementally: for something like Auctex, I initially just enable it for my latex documents and then I configure and learn features as I need them, never learning too much at once. Even with minimal configuration, it gives you some nice things like imenu entries for headings and a menu that surfaces some of the basic latex feature
It's pretty easy, actually.
First, install the plugin, I use this with elpaca:
```
(use-package latex
:ensure nil
:hook
(LaTeX-mode . TeX-fold-mode) ;; I don't use a lot the fold, but it's useful
(LaTeX-mode . turn-on-reftex) ;; For biblatex
(LaTeX-mode . LaTeX-math-mode) ;; For inserting math symbols, altough I think cdlatex is better
(LaTeX-mode . outline-minor-mode) ;; If you use outline to surf throughout the buffer
;; (LaTeX-mode . abbrev-mode) ;; If you use abbrevs
(LaTeX-mode . visual-line-mode) ;; Either this or auto-fill-mode, which will return when you have more than the `fill-column` characters
(LateX-mode . prettify-symbols-mode) ;; Will replace most latex math symbols with unicode
:bind
(:map LaTeX-mode-map
("s-a" . abbrev-mode)
("s-c" . preview-clearout-at-point)
("s-q" . LaTeX-fill-buffer)
)
:custom
(TeX-auto-save t)
(TeX-parse-self t)
(preview-auto-cache-preamble nil) ;; Setting this to t should be faster, but for me it wouldn't work with lualatex
(TeX-command-extra-options "-shell-escape")
;; Use pdf-tools to open PDF files
(TeX-view-program-selection '((output-pdf "PDF Tools"))) ;; I use pdf-tools to read the pdf in emacs
(TeX-save-query nil) ;; Auto save without saving
(TeX-show-compilation nil) ;; Hide the compilation
(TeX-engine 'luatex)
(reftex-plug-into-AUCTeX t) ;; I think this is redundant
(TeX-source-correlate-mode t) ;; To enable synctex (click on the pdf to go to source)
(TeX-source-correlate-start-server t)
:config
(add-to-list 'TeX-command-list '("Make" "make" TeX-run-command nil t))
;; Update PDF buffers after successful LaTeX runs
(add-hook 'TeX-after-compilation-finished-functions #'TeX-revert-document-buffer)
)
(use-package auctex
:ensure (auctex :pre-build (("./autogen.sh")
("./configure" "--without-texmf-dir" "--with-lispdir=.")
("make")))
:demand
:mode (("\\.tex\\'" . LaTeX-mode)
("\\.tex\\.erb\\'" . LaTeX-mode)
("\\.etx\\'" . LaTeX-mode))
:config
(with-eval-after-load 'preview
(dolist (env '("tikzpicture" "circuitikz")) ;; I want to preview tikzpictures and icrcuitikz
(add-to-list 'preview-default-preamble
(concat "\\PreviewEnvironment{" env "}") t))
(add-to-list 'preview-inner-environments "axis") ;; And axis (pgfplots)
(set-face-attribute 'preview-reference-face nil
:foreground "black"
:background "white")))
;; Tikz previews look better with a white background, if you don't use it, it's way cooler to preview latex with a "trasparent" background
```
And then the usage:
Just continue using latex as you are, and then try to incorporate auctex commands.
The most useful being =latex-environment= and =latex-section= + the previews.
So don't write \begin{env}... nor \section{sec}, and instead use C-c C-e and C-c C-s (They seem hard, but they aren't)
For the previews, use C-c C-p ... (there are a lot of options there, using which-key you can see them)
And for compiling use C-c C-c.
I recommend reading https://karthinks.com/software/latex-input-for-impatient-sch... and if you have the time, read bits of the manual
Yeah, I've also seen that in the latex forums, Emacs is strangely popular.
I don't think that there's someone that doesn't have at least one complaint about latex. But probably there are a lot of people that try to understand its flaws and start to love it or something after using it for dozen of years, and don't want to spend the time to switch.
(Stockholm syndrome??)
Judging from the releases page on Github, Typst has been in the public since May 2023. You can hardly expect it to catch up with decades of LaTeX packages in that time.
Typist is a bit older than that, it was born in 2018. Regardless, I don't expect it to have feature parity with latex, but it still lacks several important and simple packages.
Besides, I was just making a point on why people in a similar situation to mine should/shouldn't use it for big documents; what I found good and bad; and what would maintainers need to develop for more people to switch
One of the worst things about LaTeX is its reliance on packages to do anything useful. In fact, LaTeX is itself essentially just a set of packages for Tex. I hope whatever replaces LaTeX finds a solution that covers as many usecases as possible without needing any packages.
This is neat. I've used Latex before, and it definitely suffers from poor ergonomics. Both the language and tooling contribute to this.
The selling point seems to be that this is more similar to Markdown. That makes sense, Markdown is objectively more common and has more users than Latex. I've used both, but Markdown way more often.
Here's something I don't understand: it would be trivial to make Typst even more similar to Markdown, and yet it exists at some strange middle point in the language design space, arbitrarily far from Markdown.
Well maybe it’s good to make it clear that it isn’t markdown to avoid confusion? Also Typst has less syntactic sugar which also has benefits.
More generally, I am really impressed by Typst’s abstractions. I have typset my whole PhD thesis in it without needing any external packages. It was so easy to use the basic building blocks and write a few extra functions for the rest.
The plots were all created with Makie.jl [1] and lots of fiddling and manually writing code to get things right. Although I think Makie is great, I guess it would also be possible with other plotting libraries.
Places I’ve switched from LaTeX to Typst: My resume, research papers. Markdown was never a serious contender for my resume, since I want to control the rendering and the layout.
Places I’ve switched from Markdown to Typst: Slides. There are some okay Markdown-to-HTML solutions, but they have this unfortunate side-effect that you move the slides to some other computer, and something breaks in your rendering. PDFs ftw.
Perhaps you can use pandoc to turn Typst into Latex and then do the little dance of making it compatible with the provided headers?
[ The latter is painful no matter what; once, I had a paper that I simply could not get to compile with the journal's header and had to give it to a wizard for examination. He did some manual TeX shenanigans resulting in a big blob of raw TeX at the preamble and it all worked. ]
the pandoc typst reader is a bit barebones, it doesn’t support packages (understandable) and seems to get confused with functions for me…though it’s been a bit since i tried it
I'm not sure the selling point is similarity with markdown, but rather, to improve, or modernize LaTeX/TeX-the-language/s: TeX is really archaic: if you're curious, there's a series of articles by overleaf[0] detailing some of TeX's inner-working, quite insightful.
I remember reading — but can't find a source at the moment — that TeX originally didn't had counters; people came to rely on Church numerals[1] instead, before Knuth finally implemented them.
It may be similar to Markdown if you squint your eyes real hard, but it's not Markdown.
Furthermore, quoting a random snippet without any elaboration is unhelpful and only serves to confuse people (as it already did for the other comment!)
# means "evaluate". figure(...) is the function being evaluated.
The syntax inside figure(...) is fairly regular, not too different from what you'd see in typical programming languages (but with a document-oriented twist like the %).
<figure> may seem to be related syntatically to #figure(...), but it's not. It's just a label. Like an HTML div tag with id="figure". It can very well be changed to <foo> in your example and it'd still work.
These 6 lines actually put me off. Probably I have to read more about Typst syntax but, same for me, consistent syntax which covers necessary complexity wins over bending a markup language for purposes for which it was never intended.
It’s best not to think of it as a markup language. It’s a programming language designed around the needs of outputting pdfs.
Structurally it’s like a modern, nice version of php, only it’s built for academic articles rather than emitting websites.
The code snippet there packs in about 8 typst concepts all at once. It’s like if someone showed off how “simple” c++ is by showing some template-heavy magic. It’s straightforward once you’ve spent time with the language, but it’s a pretty terrible place to start learning typst. (That example shows expression mode, block mode, function calling, tags, named arguments, and probably more. Whew!)
That is a great analogy.
When I wrote my note/hws in latex, I had the urge to go look for a package more frequently. When I started converting those docs into typst, I was able to hack around more easily, it really did feel like a modern programming language that has great error messages and that I enjoyed writing in.
It did not feel complex, especially with the help of compiler errors messages
It's a little odd at first. I would recommend reading through the tutorial (which is quite good) and you might start to see some of the method to the madness.
It's not a tag, there aren't even HTML/XML tags in Typst. The effect of that <figure> is giving the #figure(...) element the label `figure` (i.e. the name is what's inside the <>). Probably using the label "figure" was not the best choice for an example, something like <my_figure> would have been a bit less confusing showing that it is an arbitrary name/id that you choose.
Edit: and I think you also misinterpreted the other comment about the <div>. It wasn't about using <div> in place of <figure>, but rather that using <figure> in typst does the same thing as id="figure" in HTML.
Personally, I don't really care about it being similar to Markdown. After all if someone wants Markdown they can just use that... For me the selling point is that it provides almost the same features as Latex except with a sane scripting language. This allows me to actually write my own scripts, as opposed to Latex where even understanding how basic stuff worked was a huge pain.
As a side note, TeX engine could support Markdown or HTML or many other syntaxes too: it's easy to redefine control character in TeX to be anything instead or in addition to "\" (I've actually done that with Plain TeX a couple decades earlier to allow two-byte UTF-8 input by making all first-bytes of valid 2-byte UTF-8 sequences into control characters).
So, LaTeX being "unergonomic" is only relative — it's pretty ergonomic compared to things like HTML but especially DocBook or TEI SGML/XML schemas, but less ergonomic than Markdown or even Plain TeX. However, it inherits the most complex part where it is extremely ergonomic from Plain TeX (for the most part): editing math formulae.
But it's also much richer in expressing intent than any of those, and from what I can see, compared to Typst as well — LaTeX is basically semantic markup for excellent printed output (where Plain TeX is excellent printed output with no semantics, DocBook/TEI are pure semantic markup, and HTML/Markdown/Typst are somewhere in the middle too).
Could you give an example of how it could be more similar to Markdown? I recently used Typst for my bachelor's project and never really thought that it needed to be simpler
Typst is a lot of fun and lets you do some really cool stuff. However! In the process of doing that cool stuff, you may need to debug things and that’s when it’s no longer fun. There is no way to print anything out to console and debug anything about what is going on. People have asked for it for over a year now and the authors have refused/ignored their requests. I would be using it a lot more except for this. https://github.com/typst/typst/issues/1669
Hey, I'm one of the Typst devs and author of the issue.
The reason there is no logging yet is because we want to get it _right_ rather than landing a permanent temporary solution. And there were simply more urgent things to do so far.
Also note that if you use an LSP or the web app, you can inspect the live values in your code simply by hovering over them.
The author of this issue is the main developer so I guess they want it done, just had other priorities.
I agree typst needs better debugging tools, but you're a bit harsh. It has things like `repr` that can often be used to inspect objects, and `panic` can be used as a (admittedly crappy) substitute for printing a value to the console.
Would you prefer that I not say exactly why I am not using typst right now as I would like to? The debugging experience is jarring compared to everything else and it put me off. I'd like to be using it but for the things that I want to do, I need to be able to figure out the mistakes I was making faster and easier.
I don't think the debugging experience is worse than in LaTeX (a low bar admittedly): you can print to the console in LaTeX but it's drowned in other messages. Instead of grepping the console in practice I use \show\thing, which is basically the same as doing panic(thing) in typst. What I do is put commented-out "panic(variable)" here and there, and use the comment/uncomment shortcut in the editor to see the value of the variable. With typst's incremental compilation I get immediate feedback, so a better experience than in LaTeX.
I like Typst, but I've had a couple issues so far:
1. The line spacing. It's not defined as baseline to baseline, but as the space inbetween two lines of text. Very difficult for an assignment with a prescribed line height since it usually refers to a baseline-baseline measure.
2. While having multiple columns is really easy, adding floating elements for the text to wrap around seems not possible. There's a reason all these CV templates have the info bar on the right instead of the left.
You can change how the bounding box Typst uses for layout is defined (i.e. set the top and bottom edges both to the baseline), then I would imagine the spacing would be baseline to baseline. Would need to adjust the space before a paragraph to compensate though.
This issue and others like it are dealbreakers for me. There are numerous related issues, but the developers are stubbornly sticking to their interpretation—using the older definition of leading from the days of metal type, rather than the more modern concept of line-spacing. No other software or modern typesetting system I know of uses this approach anymore. This is particularly frustrating since I work with a lot of multilingual text, including Arabic, and it's very difficult to align the baselines when setting text in more than one column.
As one of the core developers, I would say "stubbornly sticking to their interpretation" is not entirely fair. I am open to changing this, but I don't want to do it hastily --- because that means changing things twice. Figuring out all the correct behaviours, in particular with equations and inline objects, is challenging. I tried to constructively present some arguments in favor and against the proposed changes in the linked issue, but I simply did not have time to push things forward beyond that myself so far.
I gotta say though, Typst is powerful enough to implement a custom line spacing. Using the measure command you can get the height of the current font and use that to automatically convert. It's just cumbersome.
Built my resume with typst and know of several other folks using it for serious document typesetting. It is a very nice and modern typesetting system and language that just feels easy to make it do what I want.
It incorporates elements like templates and it is very easy to create reusable content “functions”. It is everything I want out of LaTeX while being super fast and easy to use.
Edit: pandoc can generate typst output if you want to explore :)
First of all, I will commend the Typst community for attempting to rectify the trainwreck that is LaTeX typesetting. It appears that they have succeeded.
So Typst has its own styling system, and its own scripting system, and plugin system via WASM... isn't this just HTML with extra steps? Not to mention that Typst doesn't support HTML export https://github.com/typst/typst/issues/188#issuecomment-14933..., which is a major impediment to vision-impaired accessibility in the academic community.
I think this is all a bit of a shame that there's been no major efforts to reform HTML as the go-to file format for scientific publishing instead. All the elements are there - <cite>, citation.js, KaTex, Web Components, good plotting libraries (Observable Plot), WASM. Was all this extra engineering effort required to get us a Markdown style syntax? I know people hate XML-based markup... but it's not _that_ bad, right?
PDF was designed to look the same on any device/viewer and that's something that HTML/CSS/JS will likely never be able to do (every browser does things slightly different!). HTML also lacks good support for embedding resources in a single file and is much heavier to display (try coding a whole HTML + CSS + JS engine vs a basic PDF/A viewer!). Moreover HTML/CSS lacks all the typesetting features that Latex/Typst support out of the box.
But anyway here's a challenge for you: take some random small document in Latex/Typst and try converting it to HTML/CSS/JS while keeping the same layout and visual feelings. Make it a single file you can share with people and try seeing if all browsers display it the same way.
The key difference between print systems and web tech is responsiveness. Anything print related is primarily designed with dead tree format in mind, so the layout won't change, and you don't have to worry about text reflowing after editing.
It's also why LaTeX/PDF to HTML converters are so difficult to build, because the underlying engine has no semantic information about the structure (this may be changing with LLMs and multimodal setups).
> The key difference between print systems and web tech is responsiveness.
True, but... we were very good at building unresponsive websites in the early 2000s. Can't we just return to tradition and disable a lot of the responsive behaviour that we've layered onto HTML with an off-the-shelf stylesheet? Hardcode some width properties, ya know? (This is not a rhetorical question, genuinely curious).
You can trivially define a CSS stylesheet that eg. hides all the interactive elements like INPUTs and FORMs, or renders <A> tags like plain text.
But "H" in "HTML" is for "Hyper(text)", which really talks about the interactivity. And then you get a really bad language for typesetting that simply lacks a gazillion features of true typesetting systems like TeX or even Typst.
Publishing is heavily dependent on the output media, and multi-format output is still hard for anyone desiring a high quality output.
HTML is specifically designed as a publishing system for our screens and has mostly evolved that way (media CSS tags excluded) and as a web application UI language, along with some push into semantic markup (but TEI or DocBook are much more comprehensive when it comes to semantic markup).
Some of the large problems of typesetting printed documents (page layout, with hyphenation, figure placement, orphans, justification...) are simply unsolved (or badly solved) with HTML+CSS, and they are hard problems even if you focus only on them (TeX systems will sometimes ask you to manually "pick" your poison — if you've ever seen those black bars in the margins).
Some of the beauty of TeX box model could have been transferred to screens though (like tunable and collapsible whitespace), and to an extent they have, but TeX's model remains incompatible with the HTML/CSS box model.
The fact that no language does all 3 (UI for apps, screen rendering of documents, paper rendering of documents) perfectly or even acceptably well — not to mention a fourth class that's a mix between screen and paper: ePub/eBooks — should tell anyone that this is a very hard problem to solve generically.
It's a somewhat difficult issue and I understand being hesitant because of this. Converting to SVG is one possible path around it which isn't too bad but having it natively is of course even better.
The thing is, inserting PDF for just the PDF export would be quite easy. The issue is the other export targets Typst supports (SVG and PNG) as that would require some form of rasterization / a full blown PDF engine written in Rust without C-bindings because of the web app and that simply does not exist yet.
And the developers are hesitant to just add features for one specific export target which I get.
While I appreciate these projects, I can't see any headway for something like this in our academic community. We have a very established ecosystem of LaTeX packages, styles and documents, some of which are more than 25 years old. Everyone knows it. Everyone collaborates with LaTeX. Knowledge is easy to pass on because it is well understood. Everyone knows (or are) the people who write the packages or maintain things behind the scenes. This is all quietly boiling away without a single thing on GitHub.
To move to Typst, we'd have to start again and build all that again, because I guarantee there's stuff you just can't do it in it. I mean I looked at the options for tikz. One publication we have has 520 tikz figures in it for example. And that's dead.
Sure but you have to take into account how easier it is to build these things in typst. It's like one year since the first public typst release and someone already built a very functional "TikZ" equivalent called CeTZ. Far from being as mature as TikZ but easier to extend yourself.
I was hoping that the syntax for equations would be borrowed from LaTeX but it is not the case unfortunately. I would like to switch away from LaTeX, but i think the syntax for equations in LaTeX is pretty sensible actually.
Have you tried with ConTeXt? As LaTeX, it's built atop TeX - though it's not as modular (and popular) it's more powerful.
I'd like to like Typst, but (as mentioned the other day) it follows the same model as LaTeX - great for some predefined styles, but the moment you want or need something different you'd need to get third party plugins, and with that all the perks and cons they may have.
Do give typst's syntax a try! I had the same worry as you but I now find typst's syntax more pleasant to write, and the resulting code is much more readable. Instead of
It took me a few hours to be able to do things I could never do in Latex, which I have had used for a number of documents like thesis, project reports, etc.
In Latex I always relied on googling random packages to fix weird stuff while in Typist I feel like I can do anything I want myself.
The scripting capabilities are powerful and compared to latex insanely easy to use.
This! My first actual project (besides some testing) has been my phd manuscript, and after ~2 days i actually had a tufte-style 1.5 column layout going, written from scratch. And its probably like ~250 lines.
There are some rough edges still, the dom model and advanced programming stuff is not quite there yet (user-defined elements, user-defined settables, advanced layout like chaining blocks for laying text flows). But like the quality of the user interface is several orders of magnitude better than (La)TeX.
The two baseline criteria I have for better-than-LaTeX options are:
1. Maths support equal to or better than amsmath
2. LaTeX-style macros
Both are needed to make writing large amounts of complex equations acceptable.
There should also be something similar to unicode-math, cleveref and biblatex, easy-to-use options to control layout/style/output (including metadata).
I wrote a recent paper in typst. We ended up converting it to latex at the last minute to work with the conference’s submission guidelines, and work around a small bug (now fixed) in typst. But I would 100% use typst again. I wish it output html so I could use it for blogs & documentation.
The maths support was more than good enough for what we needed, and I enjoyed writing it a lot more than latex maths. The macro-equivalent support in typst is fantastic. It’s a standout feature. It has a full, modern-feeling programming language built in, complete with modules, functions, variables, arrays, the whole works. And there’s a growing ecosystem of 3rd party packages you can use with typst. Our benchmark scripts output the results into json files. Then when the typst document compiled, our typst source pulled in the benchmarking data directly from those json files. Then it used that data to populate tables and render charts directly, straight into the pdf. It was a lovely way to work.
(Though that said, I ended up swapping to a more fully featured external charting library because the charts it created looked better).
LaTeX maths or amsmath maths? TeX maths != LaTeX maths != amsmaths maths, and usually what I see described as "LaTeX maths" is TeX maths (or a subset, when someone claiming "LaTeX support" but not actually using LaTeX).
I'm not interested in a programming language (though naturally being able to write plugins would be useful ala luatex), but a textual macro system. I have things like (which is one of the simpler macros):
\newcommand{\dt}[1]{\frac{∂#1}{∂t}}
so I can write things quickly and efficiently. That is the power of (La)TeX, and most examples I've seen of LaTeX alternatives seem to miss that use case, and instead focus on other things (e.g. HTML generation, alternate programming languages).
I'm not a latex expert. I don't know what the difference is between tex math, latex math and amsmath is. (And please don't explain it, I don't care.) Maybe there are some weird expressions out there that don't have a typst equivalent, if we really looked for them. But I haven't run into anything myself, despite writing a pretty math-heavy CS paper. (Or at least, the early drafts were math heavy.)
> I'm not interested in a programming language (though naturally being able to write plugins would be useful ala luatex), but a textual macro system.
Are you sure? Because latex macros like that are really horrible to read & write, and latex gives you notoriously hard to read error messages for your trouble. Here's the equivalent in typst:
#let dt(x) = $(∂#x) / (∂t)$
In my opinion, this is way more readable. That code defines a lambda function (like arrow functions in javascript) that returns a "math mode" block ($this is a math block$). #x escapes the math block to evaluate x - which is just the function parameter we defined earlier.
And you'd use it simply:
The result is $dt(y)$
Its not a macro system. Its just a function that you can call anywhere - including from other functions. And the function returns a block. I personally think its much nicer, and more familiar than the latex macro equivalent.
There are 3 syntactic modes in typst: markup, code and math. In markup, everything is literal, unless you put a `#` sigil like `#expr` in which case `expr` is parsed in code mode. In code mode everything is an identifier, as usual in programming. In math its a bit of an ugly tradeoff but its ok: single-letter things are parsed as literals but multi-letter tokens are parsed as identifiers. Finally, in code you can enclose in `[...]` to parse in markup mode. So typically, your document will be mostly in markup mode and you will encounter stuff like `#something[An argument]`, which is a function call to which you pass one content-typed argument.
So above, `y` is parsed as literal, while `dt` is parsed as an identifier, hence function call.
> In markup, everything is literal, unless you put a `#` sigil
Unless it's a "=", then it begins a new section. And unless it's a "-" or a "+" or a "/", then it's a list item. And unless it's a "<", then it defines a label, or a "@", then it's a reference to one. And unless it's a "_" or "*" or "`", then it changes font or style.
Right. Markup mode supports markup features - including all of that stuff for headings, lists, bold, italics and so on. It’s clearly inspired by markdown and similar languages. Personally I prefer * to \em{xxx} since it’s easier to type and it makes the text easier to read while I’m editing. (Or maybe just more familiar since give written so much markdown at this point).
I think I would have preferred a consistent sigil, but I guess with fast enough feedback you'd get used to the quirks.
I do wonder if this has over-optimised on short equations—to me heavy maths use implies multi-page equations with very specific formatting requirements (something amsmath has no issues with, which isn't surprising given who the authors are).
For me, it's basically a non-starter for academic work because it doesn't support PDF and EPS images (there are currently issues with SVG too). They also have no plans to support PDF graphics (https://github.com/typst/typst/issues/145).
I really want to like this because it seems a lot more accessible to folks than latex but I'm getting that "uncanny valley" feeling like when I look at equations that have been typeset in MS Word. They look almost, but not quite, good.
Like if you look at the equation for Binet's closed form solution for Fibonacci numbers in the link below from their github, it looks to me like there is a bit too much space on either side of the plus sign in the equation for phi on the right hand side. And phi^n on the left-hand side looks too close to the 1/sqrt(5).
I think you're imagining things... This spacing stuff is mostly defined in the font files and typst uses the same math font (or a more recent version, depending on your LaTeX config). I made a small comparison:
https://imgur.com/a/0k6dsok
Note that by default, typst uses the book weight from New Computer Modern. This corresponds to the default settings in LaTeX with the "fontsetup" package.
The only difference I can see is the spacing after the comma. Not sure why typst does it differently. I think typst might be doing the right thing here actually, but it's easy to adjust if you want.
You have a Mac with fractional scaling, your screenshots show the common blurriness render issue more than anything else I believe.
Apart from that there is clearly a size difference but I agree that it's quite close. I think it's good to be detailed oriented but I'm not sure the fetish around Latex rendering is warranted.
I think the size difference was just me being careless with zoom levels in different apps. I thought it was enough to make the point, since you can compare the space sizes to the character sizes. I put another comparison here: https://imgur.com/a/aZRx6fs , this time with same font size and zoom level.
Anyway I agree that looking exactly the same as Latex is not particularly desirable, but it helps for convincing Latex users to switch.
(The screenshots were made on Linux, with scaling but not fractional I think... But I can't check right now)
OK that must have been the screenshot software and zoom producing the blurriness.
In this new screenshot the rendering is perfect and one can't really tell any difference.
As for Latex I think it's a strong desire to belong to a special club that makes people use it and try to stick to the very specific look.
It does render math equation nicely, but the rest isn't anything special, especially compared to modern font/techniques.
I agree with you entirely fwliw. For me it's not a fetish particularly, the spacing just looks too wide in that one case and the comparisons if anything confirm that. "Too wide" is of course entirely a matter of personal opinion but I can't see myself switching to something I don't prefer the output of. I may well change my mind in future and I'm probably going to give typst a go at some point, because looking at the website there's a lot to like imo. Goodness knows for all that latex produces beautiful output it is a system with a lot of quirks and warts.
Sure, Latex gives a nice output but you have to suffer through a lot for that.
Look at the new screenshot, it's so close you can't really tell the difference without superposition.
In any case, Typst seem so much nicer to use that I think it's OK to let go of some minor details...
Could it be an illusion because the "zoom" is a bit different? (I was screenshotting different applications).
Here's a better comparison: 11pt size for both, then importing the LaTeX output in typst (using SVG conversion since typst cannot import PDF): https://imgur.com/a/aZRx6fs
I removed the "comma" that produced different spacing, and added the missing F_n. It seems there's still some different in spacing due to the quad.
If you still think the spacing around '+' is different you'll have to add some highlight/measurements or something to convince me, because they look quite identical to me...
In the near future, I'll have to program the document generation part of an invoicing system.
In the past, I've done generated PDF documents through latex, and didn't really like the process (for one, escaping is just so weird in latex, \ to \textbackslash for example).
I've thought about generating HTML and using a headless browser that can produce PDFs for me, but I don't know how well you can e.g. control page breaks with CSS these days.
Maybe typst is actually a good alternative here? Does anybody have experience with typst and multi-page tables?
I think you're looking for Quarto. Quarto can also compile to Typst for typesetting, but you can get simultaneous HTML/PDF/Word outputs from a single markdown input.
I'm doing PDF document generation in typst, the format I'm generating is similar to invoices (specific to how the law in my country is, but that's a longer story).
Typst code generation was easy to automate with trivial python templates (jinja2). The core part of my document are multi-page tables, and typst splits them nicely.
I had to google around a bit, as there are multiple settings on how large tables are handled, I suggest that you give Typst a try, you can build a working prototype in no time
I have been building tools for document generation out of templates using Typst for a few months. It works great!
So far, I haven't found any bigger issues with multi-page tables in Typst. For example, it was no big deal, to get subtotals in an invoice for every page break.
Typst is a huge improvement over LaTeX, but makes the rather anachronistic decision to target paper-based media instead of screens. Unless you're planning to print out all your papers onto physical paper, and you have stacks of different sized paper lying around (A4, US Letter, US Legal, etc.), PDFs are kind of old-fashioned. Why constrain your document's width to eight and half twelfths of the length of some medieval king's foot, when we have cutting-edge 1980s technology like HTML which can adapt to your screen width?
Incidentally, there's an open issue with Typst for making HTML output, but I don't understand why that wasn't the project's first priority. Even if scientific journals require PDF uploads, you can still get those from printing HTML. The opposite isn't true at all.
I've tried typsit and Ive really been enjoying it. It's very easy to learn and easy to use. It's a new project so it can't as of yet replace the functionality of LaTeX's many packages. However it is good for quick and easy texts, it's replaced markdown and office for me for writing simple documents on a computer.
FWIW, as a long time user of tectonic I just started a project using typst yesterday,
I'm really curious if typst will be able to do parallel downloading of packages than tectonic.
This is something which I have found can affect initial first time document builds since it can cause sequential downloading of a lot of small files sequentially.
The reason why it is difficult to parallelize or fix in tectonic itself is the way latex itself is parsed in a turing complete fashion. Importing a package can affect subsequent parsing. This makes it basically impossible to build a map of package dependencies without interpreting the entire document.
Yup. I use both LaTeX and Typst (although I prefer Typst when possible) and I haven't used anything other than tectonic for the past few years. It simply has everything you need included, and is pretty darn fast too.
If I understand correctly the fees are only for an overleaf-type web collaborative editing experience. The typst program itself, the one you install on your computer, is free to use and open-source.
That's right. The whole thing is open source -- just, since it's hard to make any money from open source, they made the online editor (which is pretty good BTW)
What is the story with the fonts Typst uses?
Does it come with a standard library of fonts?
I am not a fan of LaTex myself, but I admire it to some extent.
Other systems come along that are less verbose and easier to write,
and faster.
Yay.
And then people use it, and then someone thinks "oh we should have this
function", "We need to add a feature for it to work well" etc etc
and slowly the system either bloats, and at some point, a person will
look back at LaTeX and go
"Oh that is why this existed, and ah that
is why this is slow"
Or one can choose to keep the new system simple and simply use LateX
when something more is required.
Adding a font is just `#set text(font: "besley")` or you can use a list for fallback like `#set text(font: ("jost", "noto sans")`. Then you can select weight, italic/bold, opentype features, ligatures, etc. as options on `text` with the same syntax.
The command line comes with a few defaults such as the open source Libertinus for text or New CMM for math, but may fall back to your System fonts for characters like emoji (and there are flags to disable system fonts). You can also set a specific path to look up font files.
And then the web app has plenty of fonts in an extensive dropdown, and supports dropping in custom font files that will be automatically recognized.
I believe one current limitation is bitmap fonts not working properly, but that is being actively developed by a contributor.
I'm optimistic that Typst won't run into the issues you mention. I see it as doing well at incorporating the knowledge of the past into simpler, better interfaces.
Oh, that great! My major point of friction with LaTeX is that using unicode is not straightforward. You sort of can, by including the right packages and using the right interpreters, but it imposes strange constraints involving the fonts that you can use and whatnot.
Regarding the usage, it's probably my fault. I tried to compile it locally and it didn't work at first (requires newer rustc version).
No. I'm talking about modern LaTeX. You can easily write é outside of math mode, but not inside. By default, you cannot write α either inside nor outside of math. By using the right packages, you can do both, but other things break.
Yes, that is the problem, precisely. Lualatex and xelatex do not support all the features of plain latex (mostly "hacky" things, like pdf controls, js animations in beamer, etc). So, you have to chose between using these features and being able to type unicode letters directly.
Probably there is a magic combination of engines and packages that allows to do everything at the same time, but I haven't found it.
If this works natively in typst, it's a great selling point for me (although I dislike the markdown-like syntax).
Uh, pdftex, xetex and luatex should support everything of the original tex engine, but each has extended tex, so some things will work on pdftex (which I think is what you're thinking of as plain latex), others on xetex and then others on luatex (or pairs of engines, I know microtype works on pdftex and luatex, but not xetex). I don't think this is an tex specific problem, more a natural result when there's multiple implementations.
I suspect as typst only has a single implementation (I believe), it won't have the problem of different engines ;)
First of all, today I almost exclusively write all my LateX in overleaf, so a lot of pain of LateX distros is taken away. But the main thing was always good templates, so I found a collection of ML conference templates [0], that shows also that typst still has some issues with acutely reproducing existing styles. Also when having to submit sources, I guess cross compile to latex would be the only possibility (typically they accept Latex or sometimes MS Word)
I'm using Markdown/LaTex to PDF/HTML converter for preparing various legal/rules documents. While this approach works for very simple documents, whenever I needed simple change (i.e. specific list numbering or break the page for chapters) the path to find the solution was long and painful.
Typst was a breath of fresh air, and I'm moving all my document generators to it and don't look back.
The only thing I miss at the moment is generation of HTML (in addition to PDF). It's possible to achieve via Typst+Pandoc I guess, but would be great to have it as an output target natively.
I have a love-hate relationship with LaTeX... in 2016, I wrote my PhD with it, for wich I defined lots of helpers and commands.I used xetex for some obscure reasons I don't remember.The final result was beautiful but I dread opening any of those files. And it doesnt compile anymore.
Among all the systems (tools, languages, devices...) I exploited professinaly, LaTeX is the one that remains the most obscure and frustrating to me. I'm not sure why.
Latex already has massive amounts of libraries. Simple things like chemistry or physics typesetting for example. That's hard to just switch away from.
can it do freetype fonts? I use XeLatex to change the fonts since the default gets boring. I've been doing all my math in latex for so long I feel like I can't just switch to something else.
There is overlap, with creating whole documents, but I can imagine at some point one could use Typst inside Quatro. (Like using Typst inside Obsidian.)
I'd rather see effort go into improving LaTeX performance instead of creating some new incompatible thing in a trendy language. One could also imagine an Elixer-style "resyntaxing" of LaTeX that would preserve compatibility with decades of packages. I don't think a long-developed ecosystem should be given up lightly.
Speed and nice error messages in (La)TeX, and to some extent ease of programming, are entirely doomed because of fundamental design choices. Being based on unhygienic macro expansion means that there is only one way to evaluate (the slow way), there will never be incremental compilation (everything can possibly be stateful in horrible ways), there will never be good error messages because there's basically no AST information anywhere (begin/end is a joke).
Regarding ecosystem: tons of undecipherable LaTeX packages are basically one-liners (ok, 10 liners) in typst. I know it from experience: I've written my PhD manuscript in typst. So perhaps one reason why there are so many (basically frozen) packages in LaTeX is because they are so hard to write and maintain.
edit: of course, being only a few years old, typst is nowhere near as solid as TeX, but you can already use it for a lot of things and its a breeze to use.
It's a Java-based implementation of TeX, forked from NTS, that was optimized to render 500 to 1,000 equations in real-time on commodity hardware. My text editor, KeenWrite, uses the KeenType library to preview the document. The final output is passed to ConTeXt for typesetting, by way of first converting Markdown to an XHTML file. (This means that KeenWrite can export as both HTML and PDF.)
AST information, hygienic macros, and a ton of other things can be added without starting over. What do you think of LuaTeX? I think we as an industry habitually overestimate the difficulty of evolving older platforms and underestimate the value of doing so.
TeX has three actively-maintained engines, and there are a lot of folk putting work into improving LaTeX and its ecosystem. So effort is going into LaTeX, including performance, right now. Probably someone committed a perf improvement today, or in the last week.
There are problems with TeX which can't be fixed, problems which Typst is directly addressing. I wish them all success. I will never understand the attitude which holds that because some established system exists, nothing in the same category of program should ever be written. Let people cook.
I do understand Rust fatigue but the swipe here is uncalled for. This isn't a "rewrite it in Rust", it's a new language which happens to be implemented in Rust, and y'know what? Good choice frankly. There are tasks where "fast enough" isn't a meaningful concept, and compiling raw documents into a finished form is one of those tasks.
TeX and LaTeX aren't going anywhere, and Typst has years of work ahead of it to ever offer a comparable richness of capability. If it incrementally replaces the use of LaTeX over time, that will be because it earned it.
Have you used troff lately? Probably not. Things change. And yet man pages are written in nroff to this day. Dr. Knuth wrote TeX because what existed at the time wasn't working for him. Typst likewise.
The user interface / language design. See talk "LaTeX: It's Not You, It's Me" by Martin Haug (cofounder). TeX's language design is at the level of Basic's. Which is in fact not surprising given the timeframe.
Ah I see, so not exactly the kind of thing you'd notice making a document but you would if trying to extend the actual language. I mean TeX is basically an overpowered lambda calculus with a focus on text markup and generation.
I suppose the fact that LaTeX works at all is a testament to TeX's power, but yes I can imagine a better base language could be relevant for something like Typst.
> so not exactly the kind of thing you'd notice making a document
By "user interface" I mean (like Martin, in the linked video) the surface language, the way you interact with TeX, its syntax and how it presents itself to the user, the programming model. So definitely the kind of thing you'd notice making a document. Leaky abstractions and footguns are basically everywhere when you write a big LaTeX document.
> I mean TeX is basically an overpowered lambda calculus with a focus on text markup and generation.
No, lambda calculus has capture-avoiding substitution, aka hygienic macro expansion if you will. TeX has naive substitution. By the way, macro expansion is typically CBN, which is very much a rare and weird evaluation order (yes, Haskell, i know). TeX is much closer to some kind of assembly language for a virtual machine.
I use typst to generate PDFs on the fly in my sass-platform. The only other reliable ways I could find to do that was by using LaTeX (slow) or various WebKit-based tools (also slow, and in carious states of unmaintained/deprecated). It works like a charm.
If the author is reading, there’s a bug with dark mode, the `aside` (for the TOC) gets a background color of #d3d3d3 which results in very bad contrast as the font and heading are adjusted for dark mode.
I tried typst several months (or was it already a year?) ago, and I found it really great. I was even able to easily modify a simple plugin after barely playing 1 hr with it, where in latex that I used for years, I never even tried (to be fair the amount of plugins meant I didn't need to).
I just wish I had a good reason to use it... maybe when the implement the html output ?
I'd like to throw my two cents into the "my experience is limited but I like it better than LaTeX" ring. Because, in my limited experience, Typst is easier and faster than LaTeX by a lot.
I'd like to emphasize how important it is that Typst is a collaborative web-app like Overleaf-- 100% of the LaTeX use I saw in academia was on Overleaf.
Both have been “on the roadmap” from day 1, with little progress.
Many open source projects put “we should make our system accessible to disabled vision issues” on the roadmap, depressingly few projects then actually do it.
Even latex, which in academic circles is famous for not having html output, nowadays produces more accessible output than typist.
You are right that it's been on the roadmap for a while, however, it's definitely very high on their priority list. The recent update (v0.12) contained a lot of necessary internal refactorings of the layout engine, and they've mentioned on the Discord that after v0.12, they will start work on HTML output.
PDFs can be translated to EPUB using existing programs. I'm going to go out on a limb and guess that Typst emits "good" PDF (I worked on a PDF program for years and I know it when I see it) so that conversion should be fairly high fidelity.
Clearly this is not as good as offering a second backend, but the latter is also a huge amount of work. I'm sure if you showed Typst cases where their PDF output doesn't translate to EPUB cleanly using available converters, they would at least investigate and see if they can improve that.
But without demonstrating that translation isn't working, I'm not going to accept the claim that there's an accessibility problem here.
The central issue for new typesetting methods, unlike most software projects, is that to represent a solution, not a new problem, they must seamlessly communicate with other similar environments. So I have to ask:
* Can Typist seamlessly export Latex?
* Can Typist seamlessly import Latex?
And I must link to the definitive XKCD cartoon on this topic: "Standards" https://xkcd.com/927/ .
It's:
- Fast—Compiling my books would take around 1 minute (I often had to compile twice due to indexing). With Typst, it takes less than 5 seconds.
- Easy to write—I actually don't write it, I wrote a bunch of Pandoc plugins to tweak the output from Pandoc (I write all my books in Jupyter these days, so lots of markdown).
- Easy to read—I've used LaTeX for years (and wrote a bunch of tooling around it) and still couldn't tell you when to use a { or a [. Typst is very readable.
- Easy to script—Okay, I did write some Typst the other day. I migrated my LaTeX-based invoicing system to Typst. I created a list of objects with pricing and count and was able to throw it into a table easily. It has less code than my LaTeX version, which was using a library, and is easier to read. (I did need to write a function to properly format $ because that doesn't exist. A few rounds with AI made that easy.)
- Has great error messages—If you've used LaTeX, you know what I mean.
My needs are different from others, but I'm writing PDFs that need to be printed into a real book that looks professional. This includes front matter, footnotes, callouts, page numbers, page headers and footers, and indexes. I don't do a lot of math-heavy stuff, so I can't comment on that. And the widow/orphan support is a little weak.
Otherwise, I'm happy to never use LaTeX again!