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.
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.
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.)
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.
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.
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.
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.
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.
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.
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 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.
Readit News
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!
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...)
However, it also had index issues.
Deleted Comment
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.
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.
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.
Do you have specific examples?
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.
Apologies if this is a stupid question, I've never used typst.
Jupyter-to-PDF sounds like a perfect match here!
Interesting! Would you share your solution and/or tell us a little more about it? Thanks!
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?
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.
I hope that Typst at least allows you to nest elements without any issues.
Eg. both the article and docs at https://typst.app/docs/reference/model/ref/ use an inline reference that wouldn't work in Serbian.
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.
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.
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.)
So even embedding latest LLM won't solve it so it's better to leave it to the author to do the right thing.
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.
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.
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.
It's a fantastic system, so far as I've seen.
We have that, it's called HTML. The use case is quite different from PDF though.
[0]: https://github.com/pagedjs/pagedjs/tree/main/examples
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)
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.
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.
Can't comment on the AucTeX part, I'm using helix and typst support is not great but good enough.
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
https://codeberg.org/meow_king/typst-ts-mode/wiki/
https://github.com/Myriad-Dreamin/tinymist/tree/main/editors...
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?
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
(Sorry, I can't get the code to display right. goto https://gitlab.com/vslavkin/emacs-config/-/blob/master/emacs... and search for the latex heading)
In my totally anecdotal experience the intersection between proficient LaTeX users and emacs users is pretty large.
So having good emacs support would be a big selling point.
My experience on the other hand is also those people never complain about LaTeX, so they're probably not the target for a new typesetting system.
https://news.ycombinator.com/item?id=41014941
https://news.ycombinator.com/item?id=38354422
https://news.ycombinator.com/item?id=38047224
https://news.ycombinator.com/item?id=35250210
https://news.ycombinator.com/item?id=34423590
Typst: An easy to learn alternative for LaTex - https://news.ycombinator.com/item?id=41014941 - July 2024 (187 comments)
Building the New Hypermedia Systems using Typst - https://news.ycombinator.com/item?id=40986352 - July 2024 (1 comment)
No-Signup Typst Tools - https://news.ycombinator.com/item?id=40905678 - July 2024 (1 comment)
Typst Symbol Classifier - https://news.ycombinator.com/item?id=39878069 - March 2024 (1 comment)
Show HN: A no-frills CV template using Typst and YAML to version control CV data - https://news.ycombinator.com/item?id=38990197 - Jan 2024 (8 comments)
TexText: Re-editable LaTeX/ typst graphics for Inkscape - https://news.ycombinator.com/item?id=38804431 - Dec 2023 (2 comments)
Typst – Compose Papers Faster - https://news.ycombinator.com/item?id=38354422 - Nov 2023 (134 comments)
I rewrote my CV in Typst and I'll never look back - https://news.ycombinator.com/item?id=38047224 - Oct 2023 (25 comments)
typst-conceal.vim: cute UTF-8 conceal for typst - https://news.ycombinator.com/item?id=37862666 - Oct 2023 (1 comment)
Typst 0.7: floating content, improved SVG support and better math layout - https://news.ycombinator.com/item?id=37038708 - Aug 2023 (1 comment)
Typst: Finally a Solid LaTeX Alternative - https://news.ycombinator.com/item?id=35835703 - May 2023 (3 comments)
Typst starts its public beta test and goes open source - https://news.ycombinator.com/item?id=35364822 - March 2023 (1 comment)
Typst, a new markup-based typesetting system, is now open source - https://news.ycombinator.com/item?id=35250210 - March 2023 (146 comments)
Typst: A Programmable Markup Language for Typesetting [pdf] - https://news.ycombinator.com/item?id=34423590 - Jan 2023 (53 comments)
What If LaTeX Had Instant Preview? - https://news.ycombinator.com/item?id=33222356 - Oct 2022 (23 comments)
Typst: Compose Papers Faster - https://news.ycombinator.com/item?id=32209794 - July 2022 (30 comments)
Typst: Compose Papers Faster - https://news.ycombinator.com/item?id=32205005 - July 2022 (1 comment)
Deleted Comment
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.
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.
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.
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.
EDIT: found out where I've read about it: [2]
[0]: https://www.overleaf.com/learn/latex/A_six-part_series%3A_Ho...
[1]: https://en.wikipedia.org/wiki/Church_encoding
[2]: https://news.ycombinator.com/item?id=29713270
The problem is that extending Markdown syntax gets messy.
This is kind of a strange blend of Markdown, CSS, JSON, and HTML. TeX at least has a consistent syntax.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.
As evidenced by the fact that every project which uses it for more than that adds arbitrary extensions.
The minimum viable language for non-mathematical technical documentation is reStructuredText.
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).
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.
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.
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.
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.