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.
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
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.
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.
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
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 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.
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).
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.
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.)
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 :)
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
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.
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)
> 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
> 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.
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 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.
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.
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
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??)
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
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
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.
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`
> 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.
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 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.
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.
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.
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.
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.
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.
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"...
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.
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 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.
>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.
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...)
> 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.
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.
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?
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.
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.
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.
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).
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
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.
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.
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.
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).
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.
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 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.
242 comments
[ 2.7 ms ] story [ 262 ms ] threadThe 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.
What did you use to generate the attractive and clear svgs?
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.
[1]: https://docs.makie.org/stable/
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.
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
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.
[ 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 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.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!)
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.
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.
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).
Exceptions: you’ll need extensions for slides, some layouts. No books support, yet.
[I work on this.]
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 :)
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.
Have you taken a look at my text editor, KeenWrite?
https://keenwrite.com/screenshots.html
The text processing chain for KeenWrite is:
The look and feel of the final PDF document is controlled by a theme, which allows complete customization.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)
https://github.com/typst/typst/issues/188#issuecomment-14933...
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.
However, it’s also been a “top priority” since basically the first release.
Feel free to step up and close it. Complaining about it isn't going to add velocity to a new project.
I work on accessibility on the open source programs I already contribute to.
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.
https://github.com/Leedehai/typst-physics/blob/master/physic...
And fed it through the top pdf2epub on google:
https://cloudconvert.com/pdf-to-epub
Plain text is fine, but all maths is mangled, and tables and matrices are completely destroyed.
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)
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....
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.
But typst is catching up as fast as it can. I find it very usable already.
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.
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.
> 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:
> 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
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)
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.)
https://codeberg.org/meow_king/typst-ts-mode/wiki/
https://github.com/Myriad-Dreamin/tinymist/tree/main/editors...
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.
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
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
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.
[1]: https://github.com/typst/typst/issues/145
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.
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!
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.
Do you have specific examples?
Sorry I can't be more specific. I definitely have memories of reordering \usepackage{} statements until "it worked"...
See also <https://latex.org/forum/viewtopic.php?t=25156>.
1)pstcol has to be loaded before graphicx (I forget the reason but it just does)
2) if I use pdftricks I have to unset the "clipbox" command because it conflicts with the one in adjustbox.
As you say in another comment, given how latex reports errors debugging these can be a Fun time.
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.
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.
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.
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:
You can use both templates in any order, typst will correctly render "the" in italic bold.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.
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.
(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.
Jupyter-to-PDF sounds like a perfect match here!
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.
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.
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.
I hope that Typst at least allows you to nest elements without any issues.
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?
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).
You could simply use a static layout for your html, and then add borders or zoom (just like in a pdf viewer).
Then you'd have the editability, accessibility and performance of html, with the same responsiveness as a pdf (none).
I've never really given this much thought, but html could reallly become the standard file format for documents.
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).
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.
It is much trickier if you are using tikz heavily, but it still doable.
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.
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.
But of course.
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.
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.
Have you checked out KeenType?
https://gitlab.com/DaveJarvis/KeenType
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.)
https://keenwrite.com/screenshots.html
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.
I ask because most issues I got using LaTeX tend to be the result of LaTeX additions, very rarely are they issues from TeX itself.
Heck I even took to using TeX macros at some point because while they can be an amazing footgun they're also a lot simpler.
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.
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.
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).
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).
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):
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 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:
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:
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.So above, `y` is parsed as literal, while `dt` is parsed as an identifier, hence function call.
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.
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).
TL;DR - Profile-Guided Optimization (PGO) can improve Typst's performance for 10%+
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.
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.
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.
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.
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 the other hand, one can easily understand why, bein German, they assume Figure, Equation, etc. will always be capitalized.
> 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).
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.)
You can probably do that with a function given as supplement but it looks a bit involved, I think you'd have to do something like in this example: https://typst.app/docs/reference/model/ref/#customization
(I think the reference system is an area where things can be improved to main some common use cases simpler.)
For addresses, that's usually listen in a language grammar as a rule.
So even embedding latest LLM won't solve it so it's better to leave it to the author to do the right thing.
[0] https://github.com/daskol/typst-templates