Typst とは、新しい組版ソフトウェアです。数式を多用する科学技術系の記事を書くのに向いています。
ローカル環境で PDF にコンパイルすることもできますし、 Overleaf のようなオンラインの執筆環境も提供されています。
この分野では LaTeX が歴史的にも非常に強く、なかなか代替のソフトウェアが出現しなかったのですが、ようやく注目にも値する品質のものが登場してきたという感じです。
そもそも Qiita や Zenn でも数式を埋め込むことができるこの時代、ドキュメントを書くための専用の言語を使う理由は何でしょうか。 LaTeX はオワコンではないのでしょうか。
組版システムというのは簡単には無くなりません。これは、ブログや Wiki などの Web の記事とは性質が異なるからです。
組版システムは紙に印刷することを最終的な目的にしたシステムです。このためレイアウトは厳密に制御することができます。これに対し、ブログなどの web ページは表示デバイスに応じてレイアウトが変わりますので、著者が厳密に制御するメリットがあまりありません。
経験のある人ならわかると思いますが、 Web 向けの記事を PDF に変換するといまいちきれいな文書になりません。
図や数式が大きすぎたり小さすぎたりはみ出たりして読みやすい文書にならないのです。数式は MathJax や KaTeX といった JavaScript ライブラリでレンダリングされているケースが多いので、そもそも変換できないケースすらあります。
印刷向けの文書と web 向けの文書を統一的に扱おうという試みは長い間多くの人が挑戦してきたと思いますが、未だに上手くいっていません。これは「見た目は本質の一部」だからではないかと思います。
さて、では組版システムには存在意義があるとして、なぜ今ある LaTeX の代替を考える必要があるのでしょうか。
正直に言って、 LaTeX は優れたソフトウェアです。40年が経とうとしている今でも、古臭さは目立つものの、科学技術系文書においては右に出るもののいない組版システムです。 WYSIWYG が流行った時の逆風にも耐え、拡張と進化を続けてきました。
しかし、一つだけ重みを増しつつあるデメリットがあります。それはコンパイル時間です。日本語を含む文書を PDF にコンパイルするには、 LuaLaTeX が最も便利ですが、これは LaTeX の拡張の中でも特に遅い部類で、コンパイルに分単位の時間がかかります。[1]
WYSIWYG ではない組版システムでは、結果をプレビューするにはコンパイルしなくてはいけません。一文字直すたびにコンパイルしないとレイアウトが確認できないのでは、微調整に著しい時間がかかります。
そこで typst に注目する理由が出てきます。 typst はほぼリアルタイムのコンパイル時間を売りにしており、複数の著者による同時更新すらもできるようです。
何より Rust で書かれているということなので注目せざるを得ません。
typst の際立った特徴は、新たな専用のマークアップ言語を定義していることです。これは LaTeX がこれほど浸透している世の中では勇気ある決断だと思います。
特に面白いのが数式のマークアップです。 MathJax や KaTeX では LaTeX と互換性のある構文でしたが、 typst の構文は全く互換性がありません。
次のような数式を例にとりましょう。
LaTeX では次のように書きます。
$$\frac{\partial\mathcal{L}}{\partial q_i} -\frac{d}{dt}\frac{\partial\mathcal{L}}{\partial\dot{q_i}} = 0$$typst では次のようになります。
$ (diff cal(L)) / (diff q_i) - d / (d t) (diff cal(L)) / (diff dot(q_i)) = 0 $詳しい構文はリファレンスを見ていただくとして、ぱっと見たところ少し短くなっていることと、バックスラッシュを使わないところが見て取れます。総合的にはやや読みやすくなっていると言えるのではないでしょうか。
インストール方法には複数あります。
まず、ブラウザ上でオンラインエディタを使うなら何もインストールする必要はありません。ただし、ドキュメントが大きくなってきたら、バージョン管理もしたくなってくると思います。また、オンラインエディタは正直なところまだ動きが怪しいので、ローカル環境を使いたくなってくるかもしれません。
インストール方法はGitHub に OS ごとの方法が書かれていますし、 docker を使うこともできるようですが、私のお勧めは Rust でソースからインストールする方法です。
cargo install --git https://github.com/typst/typstもちろん Rust および cargo がインストールされている前提ですが、これが最もクロスプラットフォームなインストール方法だと思います。
やはり本当に使い物になるのかを確かめるには、ある程度の規模のプロジェクトで実際に使ってみるしかありません。とは言え、 LaTeX とは互換性がないので、既存の LaTeX ドキュメントをそのまま使うことはできず、移植作業が必要になります。
少し昔に書いたドキュメントを移植してみました。日本語のコンパイルが少々怪しかったので英語にしてあります。

もう少し別の例です。

図も入れてみます。

文書の美しさは LaTeX と遜色ないレベルだと思います。
構文は新たに学習する必要がありますが、慣れれば LaTeX よりもスムーズに書けるような気がします。ただしこれは主観的な感覚で、時間を測ったりはしていません。
そして何よりコンパイルの速さは本物です。 10 ページほどの文書(これが現時点で移植できた最長の文書です)でもコンパイルに一秒もかかりません。それもレイアウトや相互参照全て含めてです。
こちらのドキュメントのソースは以下のリポジトリに置いてあります。
https://github.com/msakuta/typst-test
やむを得ないことではありますが、日本語のサポートはいまいちです。オンラインエディタで日本語を入れると、句読点が中国語仕様になります。

これは pLaTeX などと異なり documentclass などを指定しないので言語が選択されていないのと、フォントの問題だと思いますが、解決策はよくわかりません。ローカルでコンパイルすると上手くいきます。システムのフォントを使っている気配がします。
[[2023/6/15 追記]]
Typst 0.5.0 が先週リリースされ、そこから直っているようです。

でもこれは逆に中国語圏の人にはコレジャナイことにならないんでしょうか。フォントは指定していないので入力内容を元に言語を判定している…? そんな高度なことをしているでしょうか。中国語話者の人の意見を聞いてみたいところです。
どちらにしても、きれいな文書を作るためにはフォントを指定するほうが良いと思います。それも、システムにデフォルトで備わっているものではなく、フォントファイルを指定するほうが移植性に優れます。例えばIPA明朝を使うと次のようになります。

少し細かいですが、image 関数は PDF ファイルを図として埋め込めません。
私が LuaLaTeX でよくやるのは、 matplotlib などでベクターグラフィックスのプロットなどを pdf に出力し、 LaTeX 文書に図として埋め込む方法です。これだとラスタライズせずに出力デバイスの最高解像度で出力できるのが大きなメリットです。
しかし、 typst は同じ方法は使えません。 SVG に出力すると同じようなことができるようです。
cases 関数のレイアウトが変これも少し細かいのですが、数式のレイアウトでここだけ気になりました。場合分けを式で表現するcases という関数があるのですが、値と条件部のスペースが少ないです。これだと値と条件の境目がちょっとわかりにくいかもしれません。

LaTeX の場合は、値と条件の間に& を挟むとある程度スペースを入れてくれます。
pLaTeX で dvi ファイルに出力してから dvipdfmx を使って PDF 化するのが伝統的な方法で、これは LuaLaTeX に比べるとそこまで遅くはないですが、複数のコマンドを組み合わせたり文字コードや図の問題があまりにも煩雑なので初心者向けではなく、時代にも合わなくなりつつあります。↩︎
C, C++, JavaScript, TypeScript, Python を主に使います。最近はほぼ Rust 信者です。「Rustで作るプログラミング言語」発売中です!amazon.co.jp/dp/4297141922
手元 (MacOS) では、
#set text(font: "Hiragino Kaku Gothic Pro")のような指定をした上で
typst --font-path /System/Library/Fonts watch hoge.typと、フォントパスを指定して実行すると「直角電話。」 のような文字列も日本語らしいフォントでレンダリングされました。
C, C++, JavaScript, TypeScript, Python を主に使います。最近はほぼ Rust 信者です。「Rustで作るプログラミング言語」発売中です!amazon.co.jp/dp/4297141922