Exploring Typst, a new typesetting system similar to LaTeX(blog.jreyesr.com) |
Exploring Typst, a new typesetting system similar to LaTeX(blog.jreyesr.com) |
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.
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.
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.
I tried typst several months (or was it already a year?) ago, and I found it really great. I was even able to easily modify a simple plugin after barely playing 1 hr with it, where in latex that I used for years, I never even tried (to be fair the amount of plugins meant I didn't need to).
I just wish I had a good reason to use it... maybe when the implement the html output ?
I'd like to emphasize how important it is that Typst is a collaborative web-app like Overleaf-- 100% of the LaTeX use I saw in academia was on Overleaf.
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.
* Can Typist seamlessly export Latex?
* Can Typist seamlessly import Latex?
TL;DR - Profile-Guided Optimization (PGO) can improve Typst's performance for 10%+
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.)
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.
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.
It's:
- Fast—Compiling my books would take around 1 minute (I often had to compile twice due to indexing). With Typst, it takes less than 5 seconds.
- Easy to write—I actually don't write it, I wrote a bunch of Pandoc plugins to tweak the output from Pandoc (I write all my books in Jupyter these days, so lots of markdown).
- Easy to read—I've used LaTeX for years (and wrote a bunch of tooling around it) and still couldn't tell you when to use a { or a [. Typst is very readable.
- Easy to script—Okay, I did write some Typst the other day. I migrated my LaTeX-based invoicing system to Typst. I created a list of objects with pricing and count and was able to throw it into a table easily. It has less code than my LaTeX version, which was using a library, and is easier to read. (I did need to write a function to properly format $ because that doesn't exist. A few rounds with AI made that easy.)
- Has great error messages—If you've used LaTeX, you know what I mean.
My needs are different from others, but I'm writing PDFs that need to be printed into a real book that looks professional. This includes front matter, footnotes, callouts, page numbers, page headers and footers, and indexes. I don't do a lot of math-heavy stuff, so I can't comment on that. And the widow/orphan support is a little weak.
Otherwise, I'm happy to never use LaTeX again!
This trips people up a lot once they do anything involving cross-referencing or bibliographies. But for some reason some people use latex for a long time and never hear about latexmk, which automates all that, and can even "watch" your files so you can edit and save and see your PDF refresh all in real time. (I've only used latex for papers or blog math, not big books; I can't imagine waiting a minute per change back in college, let alone on modern hardware...)
However, it also had index issues.
Because that's where I lose the most time with LaTeX: packages often mess with the (piles of) global state in ways that sometimes conflict, and the only "solution" seems to be that, if you're very lucky, sometimes conscientious package authors will try to "detect" (through various hacks) whether some other known-conflicting package has already been loaded and adjust accordingly. I didn't see any mention in TFA of any module system or even local variables in Typst to contain this explosion of complexity, so I suspect it will be just as bad in this respect as LaTeX is once there are as many plugins available.
There's still potential for conflicts, for example content can contain elements that represent a state update such as incrementing a counter. Packages can define their own states for internal use, and the namespace is global, so they can interfere with each other if they don't follow good practice (prefixing state names with __package-name for example). And show rules can replace an element of content with another one, for example one package can replace verbatim code with a figure, and another package can format verbatim code. What happens if you mix them without limiting their scope?
But so far, I think the compatibility problems in typst are more of the "well, what do you expect?" kind. Compare to LaTeX where sensible code is broken when a package makes a small changes somewhere deep in the macro pile of cards.
For example someone here mentioned the example of one package changing "the" to red and another changing "the" to blue. This can be done declaratively in typst, and won't cause an error, but the result will depend on the order of declarations.
I don't think Typst has a lot of global state to get corrupted. Like, if one package defines a variable `foo` and another package defines a variable `foo`, and you use both of them (and don't try to import `foo` from both), it's not like those `foo`s are going to conflict with each other. Is that the sort of issue that LaTeX packages run into?
Likewise, you don't modify typesetting in Typst by modifying global state like you do in Latex. You use `set` and `show`, which are locally scoped. You never need to, like, set the font size, then write some stuff, then remember to set it back. You just put `set font(size)` around precisely the stuff you want to be bigger.
Do you have specific examples?
What I enjoy about Typst is the fact that the code is easy to write and read. Even code from some third-party library or template is easy to understand. There is a world of difference between this and LaTeX, which abstracts over TeX, and whose inner workings remain obscure even to experienced developers having used LaTeX over decades for tens of documents.
The compilation of Typst documents is indeed also extremely fast compared to LaTeX.
The runtime and libraries are lightweight and easy to install, compared to LaTeX distributions.
Writing custom logic or even a fully-fledged template with Typst is easy to do from day one.
The only reason I still see to use LaTeX nowadays is writing books and papers whose editor only accepts LaTeX.
I've switched to Typst some months ago and not once have I thought it might have been a mistake. The only thing I regret is that there is no automatic migration of older LaTeX documents to Typst.
Editors still have to be improved, though the Vscode plugin is absolutely usable.
Apologies if this is a stupid question, I've never used typst.
Jupyter-to-PDF sounds like a perfect match here!
Interesting! Would you share your solution and/or tell us a little more about it? Thanks!
I find the whole system to be a bit house-of-cards and I’d love to try alternatives. What’s your workflow for using Typst with Jupyter?
Pandoc does a decent job with connecting markdown to Typst. I have a few filters that I run to convert the notebook to markdown and some other filters that I run to change the output from Pandoc.
I hope that Typst at least allows you to nest elements without any issues.
Eg. both the article and docs at https://typst.app/docs/reference/model/ref/ use an inline reference that wouldn't work in Serbian.
Serbian (and many other languages) have suffix declensions, so while "Figure 4" is "Slika 4", when used like "in Figure 4", you really need "u Slici 4" (and lowercase, really) instead of "u Slika 4" as produced by Typst.
On the plus side, it seems to use OTF locl tables for substitution glyphs for language, though it only partially works for Serbian (might be due to bad locl tables for LinLibertine which seems to be the default font).
I am sure it's not too hard to only get the reference number (eg. @foo.context.something?), but defaults should be good or maybe per-language?
I can see how they wanted to avoid authors having to hard-code the reference type if they change eg. something from an image to a table, but it's hard to make it smart enough for any language.
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.
The main problem is the popularity. It just does not have enough packages, at least for my use case.
I mainly do a lot of equations (simple math), and a loooot of tikz (forest, circuitikz, pgfplots, etc.) [https://gitlab.com/vslavkin/escuela/-/tree/main/5to?ref_type...] I'm not a fan of tikz, but it's the only way to mantain the graphics homogeneous, clean, easily editable, compiled with the document and with links/references. Cetz (the typst alternative) is years behind. I've been thinking of contributing, but tikz is really complex, and I don't have enough time ATM.
Besides the typst packages, it also lacks the editor packages. I am an emacs user insert joke here, and I use AucTeX, which is a really great, and gigant package to edit latex (+cdlatex). AFAIK there's nothing like it for typst, which makes me way slower.
Another thing is that they changed the math syntax. While the latex one wasn't perfect it was insanely popular, because of its use on markdown and a lot of pages (and this was thanks to mathjax iirc).
The good thing is that something like latex or typst will always be needed, so there'll always people that want to have something like it; latex/tex isn't really great, and it has a really low entry bar.
Maybe I'll switch when I have more time to study it and make packages. (It could be as soon as next year or a late as... never)
The 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.
The reason there is no logging yet is because we want to get it _right_ rather than landing a permanent temporary solution. And there were simply more urgent things to do so far.
Also note that if you use an LSP or the web app, you can inspect the live values in your code simply by hovering over them.
I agree typst needs better debugging tools, but you're a bit harsh. It has things like `repr` that can often be used to inspect objects, and `panic` can be used as a (admittedly crappy) substitute for printing a value to the console.
1. The line spacing. It's not defined as baseline to baseline, but as the space inbetween two lines of text. Very difficult for an assignment with a prescribed line height since it usually refers to a baseline-baseline measure. 2. While having multiple columns is really easy, adding floating elements for the text to wrap around seems not possible. There's a reason all these CV templates have the info bar on the right instead of the left.
This issue and others like it are dealbreakers for me. There are numerous related issues, but the developers are stubbornly sticking to their interpretation—using the older definition of leading from the days of metal type, rather than the more modern concept of line-spacing. No other software or modern typesetting system I know of uses this approach anymore. This is particularly frustrating since I work with a lot of multilingual text, including Arabic, and it's very difficult to align the baselines when setting text in more than one column.
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 :)
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 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.
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.
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:
Markdown (input) -> XHTML (export) -> ConTeXt (import) -> PDF (output)
\frac{1}{\alpha - 1}\ \mathrm{for}\ n\in\{1, \ldots, N\}
1/(alpha - 1) "for" n in {1, ..., N}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.
There are some rough edges still, the dom model and advanced programming stuff is not quite there yet (user-defined elements, user-defined settables, advanced layout like chaining blocks for laying text flows). But like the quality of the user interface is several orders of magnitude better than (La)TeX.
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):
\newcommand{\dt}[1]{\frac{∂#1}{∂t}}
For me, it's basically a non-starter for academic work because it doesn't support PDF and EPS images (there are currently issues with SVG too). They also have no plans to support PDF graphics (https://github.com/typst/typst/issues/145).
https://www.reddit.com/r/typst/comments/1ej07al/comment/lq9u...
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...
Note that by default, typst uses the book weight from New Computer Modern. This corresponds to the default settings in LaTeX with the "fontsetup" package.
The only difference I can see is the spacing after the comma. Not sure why typst does it differently. I think typst might be doing the right thing here actually, but it's easy to adjust if you want.
My typst code:
$ round(1 / sqrt(5) phi.alt^n), quad phi.alt = (1 + sqrt(5)) / 2 $
\[ \left\lfloor\frac{1}{\sqrt{5}} \phi^n\right\rceil,\quad \phi = \frac{1+\sqrt{5}}{2} \]Apart from that there is clearly a size difference but I agree that it's quite close. I think it's good to be detailed oriented but I'm not sure the fetish around Latex rendering is warranted.
In the past, I've done generated PDF documents through latex, and didn't really like the process (for one, escaping is just so weird in latex, \ to \textbackslash for example).
I've thought about generating HTML and using a headless browser that can produce PDFs for me, but I don't know how well you can e.g. control page breaks with CSS these days.
Maybe typst is actually a good alternative here? Does anybody have experience with typst and multi-page tables?
Typst code generation was easy to automate with trivial python templates (jinja2). The core part of my document are multi-page tables, and typst splits them nicely.
I had to google around a bit, as there are multiple settings on how large tables are handled, I suggest that you give Typst a try, you can build a working prototype in no time
So far, I haven't found any bigger issues with multi-page tables in Typst. For example, it was no big deal, to get subtotals in an invoice for every page break.
Incidentally, there's an open issue with Typst for making HTML output, but I don't understand why that wasn't the project's first priority. Even if scientific journals require PDF uploads, you can still get those from printing HTML. The opposite isn't true at all.
This is something which I have found can affect initial first time document builds since it can cause sequential downloading of a lot of small files sequentially.
The reason why it is difficult to parallelize or fix in tectonic itself is the way latex itself is parsed in a turing complete fashion. Importing a package can affect subsequent parsing. This makes it basically impossible to build a map of package dependencies without interpreting the entire document.
I'm curious to see how typst handles such things.
Last thing you want to do is use a platform that goes defunct.
I am not a fan of LaTex myself, but I admire it to some extent.
Other systems come along that are less verbose and easier to write, and faster. Yay.
And then people use it, and then someone thinks "oh we should have this function", "We need to add a feature for it to work well" etc etc and slowly the system either bloats, and at some point, a person will look back at LaTeX and go
"Oh that is why this existed, and ah that is why this is slow"
Or one can choose to keep the new system simple and simply use LateX when something more is required.
You can see all the options for `text` here: https://typst.app/docs/reference/text/text It will likely need some reorganization in time, but is quite functional.
The command line comes with a few defaults such as the open source Libertinus for text or New CMM for math, but may fall back to your System fonts for characters like emoji (and there are flags to disable system fonts). You can also set a specific path to look up font files.
And then the web app has plenty of fonts in an extensive dropdown, and supports dropping in custom font files that will be automatically recognized.
I believe one current limitation is bitmap fonts not working properly, but that is being actively developed by a contributor.
I'm optimistic that Typst won't run into the issues you mention. I see it as doing well at incorporating the knowledge of the past into simpler, better interfaces.
pi, alpha
π, α
What trouble did you have installing it? (It's literally a single binary with zero dependencies)
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).
Also typst knows the type of the referenced element. It's easy to write more elaborate rules that behave differently depending on the type. And the rules can also check the current language to generate localized references.
This is a really common idiom in mathematical writing: "from (1) we see that..." instead of "from Equation 1 we see that". (Randomly capitalising 'Equation' here is another controversial implication of using a fixed word string as a supplement.)
So even embedding latest LLM won't solve it so it's better to leave it to the author to do the right thing.
Things like "if you ever want to translate your document from English to XXX, you will also need to port it from Typst to LaTeX" tend to be dealbreakers.
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.
The typst editor plugin for vscode is pretty great. It gives you a split view of source & pdf, and you can cmd+click on either side to scroll to the corresponding source / rendered output. It also does things like give you autocomplete on fields from externally referenced json data.
Obviously, that might be no help if you’re married to eMacs. But if you’re a little promiscuous with editors like I am, give it a try.
Just to say, the most important features:
Well, the feature you mentioned of clicking the PDF and redirecting to the source.
Preview in the same buffer (window) as the code
It uses other regexps to recognize the enabled packages, and then adds the package's macros and environments to its list, so with a command you can open an environment or macro, and it recognizes which packages you are using, if you are in a math environment, etc. and shows only the ones you can use in the context. It's like a super-intelligent set of macros.
AucTex has also great support for bibtex/biblatex, and glossary/glossaries, both for using the macros and for compiling.
Automatic, intelligent, labeling.
And a lot more (altough this is probably the biggest latex package, there are a lot of other smaller packages that are also extremely useful) . Maybe it's not the hardest package to do, but it needs a lot of people and time to replicate, basically what typst is also lacking, for now.
Can't comment on the AucTeX part, I'm using helix and typst support is not great but good enough.
However, thinking about it, it's not like anyone other than me cares about how clean my circuits are. They are high school notes, and the rest of my classmates are doing it on paper, but I haven't found a good alternative. One that probably isn't as clean as circuitikz, but easier, faster and easy to integrate to latex/typst
https://codeberg.org/meow_king/typst-ts-mode/wiki/
https://github.com/Myriad-Dreamin/tinymist/tree/main/editors...
This is tangential, but have you any quick tips for someone looking to get started with AucTeX? I'm a comfortable Emacser who has started to occasionally think of some document I'd like to do in LaTeX (some maths questions for a student, or an overview of some topic). I've looked at AucTeX once or twice, and ran away thinking, oh, I'll do that some other time.
What is the order of events? Should I make a few really basic LaTeX documents first with a terminal, and then try AucTeX?
(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" backgroundAnd then the usage:
Just continue using latex as you are, and then try to incorporate auctex commands. The most useful being =latex-environment= and =latex-section= + the previews. So don't write \begin{env}... nor \section{sec}, and instead use C-c C-e and C-c C-s (They seem hard, but they aren't) For the previews, use C-c C-p ... (there are a lot of options there, using which-key you can see them) And for compiling use C-c C-c. I recommend reading https://karthinks.com/software/latex-input-for-impatient-sch... and if you have the time, read bits of the manual
(Sorry, I can't get the code to display right. goto https://gitlab.com/vslavkin/emacs-config/-/blob/master/emacs... and search for the latex heading)
In my totally anecdotal experience the intersection between proficient LaTeX users and emacs users is pretty large.
So having good emacs support would be a big selling point.
My experience on the other hand is also those people never complain about LaTeX, so they're probably not the target for a new typesetting system.
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)
More generally, I am really impressed by Typst’s abstractions. I have typset my whole PhD thesis in it without needing any external packages. It was so easy to use the basic building blocks and write a few extra functions for the rest.
Places I’ve switched from Markdown to Typst: Slides. There are some okay Markdown-to-HTML solutions, but they have this unfortunate side-effect that you move the slides to some other computer, and something breaks in your rendering. PDFs ftw.
I remember reading — but can't find a source at the moment — that TeX originally didn't had counters; people came to rely on Church numerals[1] instead, before Knuth finally implemented them.
EDIT: found out where I've read about it: [2]
[0]: https://www.overleaf.com/learn/latex/A_six-part_series%3A_Ho...
The problem is that extending Markdown syntax gets messy.
#figure(
image("image.jpg", width: 70%),
caption: [
Observe the image in the picture
],
) <figure>
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.
#let img(filepath, inset: 0.5em, caption: none) = {
figure(
box(inset: inset, stroke: 0.5pt + gray, image(filepath)),
caption: caption
);
}
#img("images/excel-5.0.png", caption: "Microsoft Excel 5.0 was released in 1993.")
As evidenced by the fact that every project which uses it for more than that adds arbitrary extensions.
The minimum viable language for non-mathematical technical documentation is reStructuredText.
So, LaTeX being "unergonomic" is only relative — it's pretty ergonomic compared to things like HTML but especially DocBook or TEI SGML/XML schemas, but less ergonomic than Markdown or even Plain TeX. However, it inherits the most complex part where it is extremely ergonomic from Plain TeX (for the most part): editing math formulae.
But it's also much richer in expressing intent than any of those, and from what I can see, compared to Typst as well — LaTeX is basically semantic markup for excellent printed output (where Plain TeX is excellent printed output with no semantics, DocBook/TEI are pure semantic markup, and HTML/Markdown/Typst are somewhere in the middle too).
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.
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).
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.
Here's a better comparison: 11pt size for both, then importing the LaTeX output in typst (using SVG conversion since typst cannot import PDF): https://imgur.com/a/aZRx6fs
I removed the "comma" that produced different spacing, and added the missing F_n. It seems there's still some different in spacing due to the quad.
If you still think the spacing around '+' is different you'll have to add some highlight/measurements or something to convince me, because they look quite identical to me...
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.
For addresses, that's usually listen in a language grammar as a rule.
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.
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.
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>.
>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.
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!)
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.)
[ 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. ]
> 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)$
And you'd use it simply:
The result is $dt(y)$
So above, `y` is parsed as literal, while `dt` is parsed as an identifier, hence function call.
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.
Anyway I agree that looking exactly the same as Latex is not particularly desirable, but it helps for convincing Latex users to switch.
(The screenshots were made on Linux, with scaling but not fractional I think... But I can't check right now)
In this new screenshot the rendering is perfect and one can't really tell any difference.
As for Latex I think it's a strong desire to belong to a special club that makes people use it and try to stick to the very specific look. It does render math equation nicely, but the rest isn't anything special, especially compared to modern font/techniques.
In any case, Typst seem so much nicer to use that I think it's OK to let go of some minor details...
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).
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.
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.
Possibly you are describing how it used to be before the input encoding standard for LaTeX switched to UTF-8?
> 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)
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.)
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:
Template from package A: #show regex("\bthe\b"): set text(style: "italic")
Template from package B: #show regex("\bthe\b"): set text(weight: "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.
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).
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).
I suspect as typst only has a single implementation (I believe), it won't have the problem of different engines ;)