Exploring Typst, a new typesetting system similar to LaTeX

386 pointsposted 18 hours ago
by judell
(blog.jreyesr.com)

138 Comments

necovek

6 hours ago

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.

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.

cbolton

5 hours ago

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.

darrensharm

5 hours ago

Use `\usepackage{cleveref}` and then `\cref` in LaTeX. Also works with babel.

bboygravity

5 hours ago

Why would a user who types only in English prefer a system that was optimized for all languages?

phoe-krk

36 minutes ago

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.

superb_dev

5 hours ago

It’s better for all of us if we can collaborate with a common system. This tool will have to deal with other languages if it’s gets popular enough

__mharrison__

13 hours ago

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.

Otherwise, I'm happy to never use LaTeX again!

Jach

8 hours ago

> (I often had to compile twice due to indexing)

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...)

__mharrison__

7 hours ago

I use rubber. For some reason it worked better than latexmk for me. (Don't remember now.)

However, it also had index issues.

laurmaedje

2 hours ago

If you're talking about weak widow/orphan support for headings in particular, that will finally be fixed in Typst 0.12.

vestingz

6 hours ago

> 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!

heisenzombie

5 hours ago

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?

akoboldfrying

12 hours ago

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.

cbolton

4 hours ago

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.

justinpombrio

9 hours ago

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.

necovek

7 hours ago

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.

akoboldfrying

7 hours ago

>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.

SkiFire13

36 minutes ago

> 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.

cbolton

4 hours ago

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.

mr_mitm

5 hours ago

Typst uses pure functions, so they cannot mutate globale state

__mharrison__

10 hours ago

To be honest, I don't know if I've seen conflicting packages.

Do you have specific examples?

seanhunter

an hour ago

There are quite a few examples, but here's two that have affected me

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.

akoboldfrying

9 hours ago

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"...

andrepd

2 hours ago

LaTeX-based invoicing system? Okay, you got me curious.

YmiYugy

14 hours ago

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.

justinpombrio

9 hours ago

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.

It's a fantastic system, so far as I've seen.

Klasiaster

29 minutes ago

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`

mixmastamyk

10 hours ago

That’s what html was supposed to be; probably still could. Epub uses it as well, though readers are not equivalent.

seanhunter

an hour ago

I really want to like this because it seems a lot more accessible to folks than latex but I'm getting that "uncanny valley" feeling like when I look at equations that have been typeset in MS Word. They look almost, but not quite, good.

Like if you look at the equation for Binet's closed form solution for Fibonacci numbers in the link below from their github, it looks to me like there is a bit too much space on either side of the plus sign in the equation for phi on the right hand side. And phi^n on the left-hand side looks too close to the 1/sqrt(5).

https://user-images.githubusercontent.com/17899797/228031796...

vslavkin

14 hours ago

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)

aulin

7 hours ago

> I am an emacs user insert joke here

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.

josephg

10 hours ago

> 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.

porridgeraisin

6 hours ago

Latex workshop gives an identical experience with latex

josephg

4 hours ago

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.

cbolton

5 hours ago

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.

sourcepluck

13 hours ago

> 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?

fiddlerwoaroof

11 hours ago

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

andrepd

2 hours ago

Well that's going to remain an issue for a long time: TeX has close to half a century head start :)

Vt71fcAqt7

9 hours ago

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.

elashri

15 hours ago

Previous discussions about Typst.

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

dang

14 hours ago

Thanks! Macroexpanded:

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)

knuckleheads

8 hours ago

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

cbolton

5 hours ago

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.

knuckleheads

4 hours ago

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.

cbolton

3 hours ago

Maybe I was a bit harsh too :)

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.

laurmaedje

2 hours ago

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.

alphazard

16 hours ago

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.

huijzer

15 hours ago

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.

sshine

15 hours ago

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.

gumbojuice

8 hours ago

Are there journals/conferences that accept typst for typesetting yet? It is probably my main reason for staying in LaTeX.

ykonstant

2 hours ago

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. ]

prettymuchnoone

2 hours ago

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

auggierose

3 hours ago

How do you submit your research papers written in Typst?

josephg

10 hours ago

I really wish typst had a good way to emit html. Id love to use it for blogging & technical writing and documentation.

laurmaedje

2 hours ago

(Typst dev here.) That's one of the next big things we plan to work on once Typst 0.12 has shipped. :)

mbivert

15 hours ago

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.

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

necovek

6 hours ago

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).

Animats

15 hours ago

> The selling point seems to be that this is more similar to Markdown.

The problem is that extending Markdown syntax gets messy.

    #figure(
      image("image.jpg", width: 70%),
      caption: [
        Observe the image in the picture
      ],
    ) <figure>
This is kind of a strange blend of Markdown, CSS, JSON, and HTML. TeX at least has a consistent syntax.

orangeboats

14 hours ago

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.

smartmic

14 hours ago

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.

josephg

10 hours ago

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!)

gauge_field

7 hours ago

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

__mharrison__

10 hours ago

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.

airstrike

15 hours ago

Strange to the untrained eye, perhaps. To me that just looks like a function. In a long document I recently wrote, I defined a custom function

    #let img(filepath, inset: 0.5em, caption: none) = {
      figure(
        box(inset: inset, stroke: 0.5pt + gray, image(filepath)),
        caption: caption
      );
    }
and just used it like:

    #img("images/excel-5.0.png", caption: "Microsoft Excel 5.0 was released in 1993.")
edit: fixed unused inset param

padjo

14 hours ago

Looks like it has a bug, the inset parameter is unused

airstrike

14 hours ago

Whoops, thanks. Wrote this one-off and never needed to change the inset so didn't catch that. Fixed!

SkiFire13

13 hours ago

Was do you find inconsistent here? It seems pretty consistent to me, except maybe the <figure>

chrisweekly

10 hours ago

and that <figure> tag is kind of moot -- as another commenter mentioned, it could have been some other html tag like a div

SkiFire13

4 hours ago

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.

llm_trw

15 hours ago

Markdown is a very poor language to try and use for anything other than single column typewriter like text.

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.

SkiFire13

13 hours ago

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.

__mharrison__

12 hours ago

I write markdown and use Pandoc (plus some filters) to create Typst. Happy to never touch LaTeX again.

prettymuchnoone

15 hours ago

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

mbo

12 hours ago

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?

SkiFire13

4 hours ago

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.

necovek

6 hours ago

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.

Onavo

12 hours ago

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).

aniviacat

12 hours ago

One could ask if responsiveness is relevant for documents.

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.

mbo

11 hours ago

> 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).

necovek

5 hours ago

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.

Onavo

10 hours ago

Then you might as well just use PDF.js and render the PDF in its entirety.

viralsink

14 hours ago

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.

Aaron2222

11 hours ago

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.

bitexploder

15 hours ago

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 :)

sega_sai

15 hours ago

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.

Gualdrapo

14 hours ago

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.

thangalin

10 hours ago

> Have you tried with ConTeXt?

Have you taken a look at my text editor, KeenWrite?

https://keenwrite.com/screenshots.html

The text processing chain for KeenWrite is:

    Markdown (input) -> XHTML (export) -> ConTeXt (import) -> PDF (output)
The look and feel of the final PDF document is controlled by a theme, which allows complete customization.

cbolton

3 hours ago

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

    \frac{1}{\alpha - 1}\ \mathrm{for}\ n\in\{1, \ldots, N\}
you get to write

    1/(alpha - 1) "for" n in {1, ..., N}

aragilar

10 hours ago

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).

josephg

10 hours ago

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).

aragilar

5 hours ago

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).

josephg

5 hours ago

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.

aragilar

an hour ago

I'm curious, how does typst work out that I want the function expanded or I want the literal string if there's no marker.

HerrmannM

3 hours ago

I have a love-hate relationship with LaTeX... in 2016, I wrote my PhD with it, for wich I defined lots of helpers and commands.I used xetex for some obscure reasons I don't remember.The final result was beautiful but I dread opening any of those files. And it doesnt compile anymore.

Among all the systems (tools, languages, devices...) I exploited professinaly, LaTeX is the one that remains the most obscure and frustrating to me. I'm not sure why.

tcfhgj

3 hours ago

It took me a few hours to be able to do things I could never do in Latex, which I have had used for a number of documents like thesis, project reports, etc.

In Latex I always relied on googling random packages to fix weird stuff while in Typist I feel like I can do anything I want myself. The scripting capabilities are powerful and compared to latex insanely easy to use.

enriquto

5 hours ago

It's cute that you can write greek letters by spelling them, without any escape:

    pi, alpha
What I'd really want to type is however

    π, α
Will this work in typst? I had some trouble installing it.

cbolton

4 hours ago

Yes that works.

What trouble did you have installing it? (It's literally a single binary with zero dependencies)

enriquto

4 hours ago

> Yes that works.

Oh, that great! My major point of friction with LaTeX is that using unicode is not straightforward. You sort of can, by including the right packages and using the right interpreters, but it imposes strange constraints involving the fonts that you can use and whatnot.

Regarding the usage, it's probably my fault. I tried to compile it locally and it didn't work at first (requires newer rustc version).

jimhefferon

2 hours ago

> My major point of friction with LaTeX is that using unicode is not straightforward.

Possibly you are describing how it used to be before the input encoding standard for LaTeX switched to UTF-8?

enriquto

an hour ago

No. I'm talking about modern LaTeX. You can easily write é outside of math mode, but not inside. By default, you cannot write α either inside nor outside of math. By using the right packages, you can do both, but other things break.

aragilar

an hour ago

Which engine? I believe XeTeX and LuaTeX support it natively?

enriquto

40 minutes ago

Yes, that is the problem, precisely. Lualatex and xelatex do not support all the features of plain latex (mostly "hacky" things, like pdf controls, js animations in beamer, etc). So, you have to chose between using these features and being able to type unicode letters directly.

Probably there is a magic combination of engines and packages that allows to do everything at the same time, but I haven't found it.

If this works natively in typst, it's a great selling point for me (although I dislike the markdown-like syntax).

aragilar

6 minutes ago

Uh, pdftex, xetex and luatex should support everything of the original tex engine, but each has extended tex, so some things will work on pdftex (which I think is what you're thinking of as plain latex), others on xetex and then others on luatex (or pairs of engines, I know microtype works on pdftex and luatex, but not xetex). I don't think this is an tex specific problem, more a natural result when there's multiple implementations.

I suspect as typst only has a single implementation (I believe), it won't have the problem of different engines ;)

divan

5 hours ago

I'm using Markdown/LaTex to PDF/HTML converter for preparing various legal/rules documents. While this approach works for very simple documents, whenever I needed simple change (i.e. specific list numbering or break the page for chapters) the path to find the solution was long and painful.

Typst was a breath of fresh air, and I'm moving all my document generators to it and don't look back.

The only thing I miss at the moment is generation of HTML (in addition to PDF). It's possible to achieve via Typst+Pandoc I guess, but would be great to have it as an output target natively.

riedel

6 hours ago

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)

[0] https://github.com/daskol/typst-templates

Semaphor

4 hours ago

If the author is reading, there’s a bug with dark mode, the `aside` (for the TOC) gets a background color of #d3d3d3 which results in very bad contrast as the font and heading are adjusted for dark mode.

rsrsrs86

3 hours ago

Typst is simply amazing. I wrote a thesis using latex and boy would I love if I had found about typst sooner.

Munksgaard

5 hours ago

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.

cozzyd

11 hours ago

Until the arxiv gets typst support, I imagine this will get relatively little traction.

darkteflon

15 hours ago

Love to hear some informed opinions on typst versus quarto.

ternaryoperator

15 hours ago

Search in HN for Typst and you'll see this link is routinely posted and as little as three months ago got nearly 200 comments.

timeon

15 hours ago

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.)

fourthark

14 hours ago

Yes, Typst is fully supported as an output language of Quarto.

Exceptions: you’ll need extensions for slides, some layouts. No books support, yet.

[I work on this.]

vivekd

15 hours ago

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.

quotemstr

12 hours ago

C-f r u s t RET

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.

hggigg

4 hours ago

While I appreciate these projects, I can't see any headway for something like this in our academic community. We have a very established ecosystem of LaTeX packages, styles and documents, some of which are more than 25 years old. Everyone knows it. Everyone collaborates with LaTeX. Knowledge is easy to pass on because it is well understood. Everyone knows (or are) the people who write the packages or maintain things behind the scenes. This is all quietly boiling away without a single thing on GitHub.

To move to Typst, we'd have to start again and build all that again, because I guarantee there's stuff you just can't do it in it. I mean I looked at the options for tikz. One publication we have has 520 tikz figures in it for example. And that's dead.

cbolton

3 hours ago

Sure but you have to take into account how easier it is to build these things in typst. It's like one year since the first public typst release and someone already built a very functional "TikZ" equivalent called CeTZ. Far from being as mature as TikZ but easier to extend yourself.

beezle

11 hours ago

Real men use TeX or troff!

volemo

2 hours ago

Real men write formulae by hand in their typewriter typed papers.

pseingatl

15 hours ago

Does Typst have epub or html export?

njkleiner

14 hours ago

Both are on the roadmap, apparently.

https://github.com/typst/typst/issues/188#issuecomment-14933...

CJefferson

13 hours ago

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.

Vallaaaris

5 hours ago

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.

dsrtslnd23

6 hours ago

is this comparable to asciidoc?

bitwize

10 hours ago

Ah, Typst -- the Wayland of formatting systems.

hyperbrainer

5 hours ago

Wayland is far more feature-complete than Typst is. Typst is Wayland 5-6 years ago maybe.

mixmastamyk

10 hours ago

Does this allow a book to be split into parts? One problem I had with Sphinx.