11 ポイント 投稿者 GN⁺ 2025-09-28 | 3件のコメント | WhatsAppで共有
  • TypstはRustで開発された文書組版プログラムで、数式・表・図の挿入など技術資料の作成に最適化されたLaTeXの代替として語られている
  • LaTeXの複雑な文法・遅いコンパイル・わかりにくいエラーメッセージの問題を解決し、Markdownに似た文法と統合された関数ベースの言語を提供する
  • 高速なインクリメンタルコンパイルと明確なエラー表示、簡潔な文法により、大規模な文書でもリアルタイムプレビューが可能で、プログラミング機能がシステムに自然に組み込まれている
  • 欠点としては、専門パッケージのエコシステム不足、ジャーナルテンプレート対応の不十分さ、ドキュメントの難しさや一部機能不足が指摘されるが、パッケージは急速に増えており、Pandocによる変換も可能
  • Typstはまだ初期段階だが、一部学術誌での採用、800個以上のパッケージ、活発なコミュニティにより、LaTeXを置き換えうる有力候補として浮上している

Typstの紹介と重要性

  • Typstは文書組版プログラムであり、数式、表、図などの技術文書に適した構造を備えている
  • LaTeXに匹敵する高品質な成果物を、より簡単なマークアップと高速なコンパイルで提供する
  • TypstはRustで開発されたオープンソースソフトウェアで、Apache-2.0ライセンスに従う
  • 大規模文書の処理速度、文法の単純化、容易なカスタマイズが大きな強み

LaTeXの限界と代替の必要性

  • LaTeXはTeXベースで数学・計算機科学分野における学術論文の標準ツールとして定着したシステム
  • しかしインストール容量が大きく、コンパイル速度の低下難解なエラーメッセージマクロ言語ベースで難しいカスタマイズの問題が継続的に指摘されてきた
  • 何十年もの間代替の議論はあったが、膨大なパッケージエコシステムと既存ユーザーへの依存により現実的な代替がなかった

Typstの登場と開発背景

  • 2019年にドイツの開発者Laurenz MädjeMartin Haugが個人プロジェクトとして始め、その後修士論文とベータリリースを経て発展した
  • 2023年のv0.1.0公開以降、現在はv0.13.1まで成長しており、GitHubでは365人以上のコントリビューターが参加している
  • 一部の学術誌がTypst原稿を投稿形式として受け入れ始めたことで、実運用の可能性が広がっている

Typstの機能と利点

  • TypstはRustソースおよびコンパイル済みバイナリとして提供され、Linux、macOS、Windowsをサポートする
  • 単一実行ファイル(typst)で動作し、LaTeXのように複数のエンジンを使い分ける必要がない
    • typst fontsコマンドで利用可能なフォントの確認と追加が可能
    • typst compileでPDF/SVG/PNG出力、typst watchモードでリアルタイムプレビューに対応し、ソース変更時にPDFを自動更新できる
    • 高速なインクリメンタルコンパイルにより、大規模文書でもリアルタイムプレビューが非常に速い
  • 文法はMarkdown風のスタイルと数式専用文法を組み合わせており、LaTeXより簡潔で直感的
  • 明確なエラーメッセージインクリメンタルコンパイルRustに似た関数型言語のサポートにより、ユーザー体験が改善されている
  • 数式表現はLaTeXとほぼ同等の品質を提供し、Unicode記号入力を直接活用できる

LaTeXに対するTypstの改善点

  • LaTeXより短く読みやすいソース文法を提供
  • TypstはLaTeXと同じ改行アルゴリズムと類似の数式組版方式を用いて品質を維持する
  • 複雑なマクロの代わりに関数呼び出しベースのカスタマイズで安定性と単純さを確保
  • TypstにはRustスタイルの組み込みプログラミング言語が内蔵されている
    • 関数の大半は純粋関数で、予測可能な結果とデバッグのしやすさを提供
    • プログラミング言語と文書組版完全に統合されており、簡潔なコードを書ける
    • 文書のカスタマイズ、たとえばフォント変更やセクションスタイルなども関数呼び出し方式
    • LaTeXのLua拡張より一貫性があり単純なプログラミング構造をサポートする
  • LaTeXで問題になりがちなフロート処理、表の分割なども改善されたレイアウトモデルで解決可能

マークアップ例と構造

  • 見出し: =記号、自動番号付きリスト: +、箇条書きリスト: -で簡単に記述
  • Bold、Italicなどのテキスト装飾も直感的に入力できる
  • 一部機能は関数呼び出しで処理: 例) #underline[Good] gin
  • テキスト、コード、数式の3種類の入力モードが存在
  • 数式モードは$で囲んで入力し、Unicode記号やギリシャ文字をそのまま入力できる

Typstの欠点と限界

  • LaTeXに比べてページレイアウトの精密さが不足(widow/orphan制御など)
  • まだ専門パッケージ数が少ないが、現在は800個以上へと急速に拡大中
  • 学術誌テンプレート対応が不足しており、Pandoc変換が必要
  • 公式ドキュメントが不十分で、急速なアップデートに追いつけていない問題がある
  • PDF挿入不可、parshape未対応など一部の高度な機能が欠けている
  • プロジェクト初期段階の特性上、**互換性破壊(breaking changes)**のリスクがある

結論と展望

  • 著者は実際に物理学論文の執筆にTypstを使用しており、LaTeX変換にはPandocを活用している
  • Neovim + Tree-sitterと組み合わせて効率的な執筆環境を構築しており、Typstの速度とエラー表示の体験に満足している
  • 高速で直感的な数式入力、エディタ/ビジュアルツール対応、高速なコンパイルフィードバックなど、実務上の作業効率を提供する
  • TypstはLaTeXの代替可能性を持つ有力候補であり、現時点でも十分実用的で、今後さらに拡張されると評価されている

LWNの主なコメント

  • 互換性と長期安定性
    • TeX/LaTeXが成功できた理由の一つは、将来バージョンとの互換性維持にあった(spacefrogg)
    • しかし実体験では、古い文書が新しい環境で壊れたり、パッケージ変更で書き直しが必要になったりする問題が多かったという不満もある(wtarreau, warrax)
    • 一部ユーザーは、数十年前の論文や学位論文が今でも問題なくビルドできた経験を共有し、使っていたパッケージの安定性の違いが核心だと指摘する(dskoll, anton)
  • 出版社テンプレートとパッケージの問題
    • 学術誌出版時に提供されるLaTeXテンプレートと旧式パッケージの使用が強制され、実際には互換性の利点が弱まるという指摘がある(NYKevin, aragilar)
    • 結局重要なのは文書形式を長く保つことではなく、本文テキストを新しいテンプレートへ容易に移植できるかだという現実的な意見もある(anton)
  • Typstの言語設計と利点
    • TypstはLaTeXと異なり、コード文法と組版文法が明確に分離されているためマクロの副作用が減り、現代的な言語機能を備えている(spacefrogg)
    • 簡単な文書を素早く書けて、エラーメッセージの読みやすさインクリメンタルコンパイルが大きな利点(spacefrogg, notriddle)
    • ただしTypstもチューリング完全性を持つ以上、長期的には互換性問題が繰り返される可能性を懸念する意見もある(epa, smoogen, taladar)
  • エコシステムとコミュニティ
    • Typstではパッケージ開発が活発で、要望に応じて機能がすばやく追加された事例がある(leephillips, adnl)
    • 公式ドキュメント不足という指摘とは別に、コミュニティフォーラムが親切で活発だという前向きな経験も共有されている(al4711)
    • 他の代替プロジェクトとしてSILEや過去のLoutも言及されたが、ネットワーク効果の不足で普及に失敗した歴史も振り返られている(rogerwhittaker, ceplm, anton)
  • LaTeXの継続的な進化との比較
    • LaTeXも最近は**Tagged PDF(アクセシビリティ強化)**のような現代的機能を導入しており、今も研究者や開発者が積極的に改善している(jschrod)
    • Overleaf、LyXなどさまざまなツールがLaTeXの使い勝手を改善しており、共同作業や初心者学習に有用だという意見もある(smitty_one_each, paulj, callegar)
    • TypstにはLaTeXより単純で現代的という利点がある一方、数十年かけて蓄積されたエコシステムと専門機能にはまだ追いつきにくいという懐疑的な見方もある(norbusan, callegar)
  • その他の議論
    • TypstのPDF取り込み機能は最近追加され、parshape類似機能もパッケージとして登場した(Delio, yashi)
    • Typstも数十年後には結局LaTeXと同じ互換性・複雑性の問題を繰り返すだろうという批判もある(norbusan)
    • 一部ではTypstのイタリック補正不足のような細かな問題が指摘され、LaTeXの細密で伝統的な機能と比べると不十分だと強調されている(callegar)

3件のコメント

 
shakespeares 2025-10-01

エコシステムが整うまでもう少し待つ必要がありそうですね..

 
secret3056 2025-09-29

Typoraは多くの面でLaTeXを圧倒していると思います。
ただ、まだ細かなバグが残っていて、新しいバージョンが出るまでに時間がかかりすぎるのが残念ですね。
コミュニティを独自に運営し、エディタ+クラウドの有料化を試みたもののうまくいかず、開発速度が以前ほどではなくなったように思います。

 
GN⁺ 2025-09-28
Hacker News の意見
  • Typst がますます注目されるようになってうれしい。私の組織 Zerodha では、2年前に実務を Typst に移行した。毎日 150 万件を超える PDF を生成してメール送信する業務だった。以前は LaTeX(最初は pdflatex、その後は lualatex)ベースのパイプラインを使っていたが、大規模文書で原因不明のメモリエラーが出ることと、Docker イメージが大きすぎて ephemeral ワーカーの起動が遅いことが常に問題だった。Typst に切り替えてからは、単一の静的バイナリで非常に軽量なイメージを使えるようになり、起動速度が目に見えて速くなった。性能向上も非常に大きかった。全体のコンパイル時間は LaTeX 比で 3〜4 倍高速で、2000 ページを超える大規模文書では Typst は 1 分で終わるのに対し、lualatex は 18 分もかかった。開発者体験も向上し、エラーメッセージもずっと親切なので満足している。全体アーキテクチャと Typst への移行経験について詳しく書いたので、興味があれば こちら を参照してほしい

    • 私は LaTeX パイプラインで、テキスト、請求書、フォームなどさまざまな文書を、データベース内のスニペットをもとに生成している。セットアップはかなり複雑だったが、結果にはとても満足している。もっと簡単なマークアップ言語を使いたい気持ちはあるが、時間を無駄にした挙げ句、限界に突き当たるのではないかと心配でもある。私が必須だと思う条件は、複数カラムで意味のあるカラム分割・ページ分割を指定できること(新しいカラム/ページで最低行数を指定するなど)、複数言語(英語/ドイツ語、将来的にはフランス語/イタリア語/スペイン語)で信頼性の高い自動ハイフネーションが効くこと、カラム内での画像の自動配置、複雑な表やフォームの自動ページ分割、背景画像、そして minipage のように扱える異なる領域などだ。Typst でこれらが全部できるのか気になる

    • どんな文書を作っているのか、サンプルや例を共有してもらえたら本当に面白そう

    • 私が働いていた会社では、統計資料、小規模レポート、その他さまざまなビジネス文書の PDF を定期的に送っていた。多くは MJML、自作 HTML、Puppeteer などで PDF を生成していた。こういう用途でも Typst が向いているのか気になる

    • そのユースケースで、なぜ最初に LaTeX を使ったのか気になる。LaTeX を置き換えるということより、出発点として LaTeX を選んだことの方がむしろ驚きだ

  • Typst と LaTeX を比べると本当に雲泥の差だ。私は博士論文を Typst で書いているが、実質的にはかなり冒険に近い選択だ。まだ大きなユーザー層があるわけでもなく、完全に安定しているわけでもないからだ。それでも一度使ってみたら、もう後戻りできなかった。大学が要求する LaTeX テンプレートにピクセル単位で合わせる作業はまだ残っているが、それでも Typst の方が明らかに適していると確信した。LaTeX を 10 年以上使っていても、TeX を本当に理解しているとは言えなかった。ところが Typst は、数日でかなり効率よく使えるようになった。必要なパッケージがなければ自分で素早く作れるし、その多くはすでに優れたパッケージで提供されている。LaTeX では想像もできなかった作業が Typst では簡単にできる。生産性を大きく落としていた要因の一つが、TeX でのパッケージ競合、互換性、バージョン問題だったが、Typst ではそうしたことがまったくない。本物のプログラミング言語とモジュール体系があるからだ。コンパイルも速く、全体としての使用体験が本当に優れている。ただし 100% 完璧ではない。いくつか惜しい設計もあるし、たとえば PDF を画像のように埋め込む機能のように、まだ開発中の部分もある。組版品質も TeX 比で 95% くらいに近づいている感覚だ(TeX は常に完璧だ)。カーニングを時々手で調整しないといけないこともある。それでも今後さらに改善されると期待している

    • 大学の LaTeX テンプレートにピクセル単位で合わせる必要があるのは、むしろ幸運かもしれない。たいていの人は大学の MS Word テンプレートをそのまま LaTeX で再現しなければならなかったのだから

    • Typst も進化し続けると思う。ただ、ときどき互換性を壊す大きな変更があった。直すのは難しくなかったが、デバッグは直感的ではなかった。多くの人が Typst をうまく使えるよう願っているように見える。TeX と LaTeX はあまりに巨大で複雑なので、何かすっきりした LaTeX の「ディストリビューション」のようなものが必要だと感じる。コンテナでアトミックな単位としてうまく作れたらいいのにと思う。テンプレートを受け取ってビルドしようとすると、いつも何かが足りないことがあるし。こういう分野で革新が続いているのは良いことだ

    • LaTeX を 10 年以上使っていたのに、Typst は数日で使いこなせるようになったというのは興味深い。なぜだろう? もしかして CS(コンピュータサイエンス)のバックグラウンドがあるから?

    • ピクセル単位での再現というのが本当に文字通りなのか、それとも誇張なのか気になる。LaTeX にはほぼピクセル単位で再現不可能なパッケージも多いし、とくに microtype のようなものは科学論文でよく使われる

    • Typst で論文を書いた経験を扱った ブログ記事 も参考になるかもしれない

  • Typst と LaTeX を使い比べて感じたことをまとめると

    1. LaTeX はコンパイルするたびに妙なファイルが 5 つくらい増えるが、Typst にはそれがない
    2. コンパイル速度が即時的
    3. 診断メッセージが本当にわかりやすい(Rust コンパイラのように具体的)
    4. リスト項目を -[item] などいろいろな書き方で書けるが、角括弧方式を使うと vim で % による対応ペア移動がしやすく、長いリストでも簡単にナビゲーションできる
    5. LaTeX は \document{} の冒頭にマクロ宣言を全部集めておかなければならないが、Typst では必要な場所の近くにそのまま置ける
    6. semantic line break 方式を使うと、バージョン管理や diff がやりやすくなる
    7. ページレイアウト、余白、間隔、フッターなどもずっと簡単に変更できる
      1. プログラミング環境も素晴らしい。独自のインタプリタ言語が組み込まれているので、json("some_file.json") のような関数で結果表をそのまま読み込んで使える。論文を書くとき、ベンチマークスクリプトが作った JSON データを Typst で直接読み込み、PDF にコンパイルして利用している
    • マクロ宣言は冒頭に置く必要はなく、どこでも宣言できる。LaTeX でもパッケージは preamble でしか読み込めないが、マクロはどこでも宣言可能だ。semantic line break も LaTeX で特に問題ない。コンパイル速度と診断メッセージについての意見には同意する。この点こそが LaTeX 最大の弱点だ

    • 実際、5 番の内容のようにマクロはどこでも宣言できる。慣習的に preamble に置いているだけだ

    • Typst で実際に記事のようなものを書いてみた人がいるのか気になる。私はごく限定的にしかうまくいかず、まだ利用者が多くないので自力で問題を解決しなければならない状況だ

    • Typst は単なるマクロではなく、本物のプログラミング言語なので、関数、型、モジュール(名前空間もある)などさまざまな機能がある。そのおかげで、TeX で作業していたときより苦痛が 80% は減る(特に単純な学生実験レポート以外では)。完璧ではないが、本当に大きな違いになる利点だ

  • LaTeX 自体は、そのものとして見れば LaTeX よりはるかに単純で直接的だ。むしろ制御権が多すぎて戸惑うほどだ。たとえば、これは有効な plain TeX 文書だ: $$\aleph_0$$ \bye。begin/end を使う必要すらない。extended plain のようなマクロ集を使えば機能を拡張できる。私も論文全体を extended plain で書いたが、図書館提出時に LaTeX スタイルファイルへ書き直すよう求められ、結局 LaTeX に直した

    • LaTeX しか使ったことがないなら、plain TeX に触れると驚くはずだ。LaTeX マクロだと思っているものの多くは、実際には TeX 自身が直接提供している機能だ
  • Typst が本当に LaTeX の競合になるには、学術論文やカンファレンスで Typst テンプレートが公式採用される必要がある。大学での普及も最終的には出版社側の採用に左右される。まだ研究者コミュニティでは Typst のサポートがほとんどない。論文、スライド、レポートはすでに皆 LaTeX テンプレートで書いており、まずはどこかの教授や研究室で Typst テンプレートが承認され、それが大学全体に広がり、さらに学会やジャーナルへ波及していく必要がある。このプロセスは非常に長く退屈で、まだ進行中だ。しかし不可欠な段階でもある

    • ジャーナル投稿のような、より専門的な組版でどんな問題があるのかよく知らないせいかもしれないが、研究論文で組版がそこまで重要なのかはよくわからない。実際には、もっとシンプルで内容中心のフォーマットがあれば十分だと思う。論文や書籍の出版社側が、提出された原稿を自分たちのスタイルに合わせて組版すればよい。研究者としては、シンプルで内容中心のフォーマットだけを気にすればよい方が望ましい。実際、LaTeX や Typst よりも、何らかの研究向け markdown フォーマットが標準になってほしいと思う

    • 研究者の立場では、LaTeX がすでに問題を十分うまく解決しているので、わざわざ変える大きな理由がない

  • 私は LaTeX で複数の講義ノートと数学の修士論文を書いた。他人が作ったテンプレートに文章を流し込むだけなら、LaTeX も十分に良い。しかしパッケージを自作したり内部構造を理解しようとすると、本当に黒魔術のように感じられた。各パッケージが互いに衝突しないよう細心の注意を払う必要があり、特殊な回避策も多く、常に複雑だった。Typst がレイアウトやデザインを直接かつ簡単に扱える LaTeX 代替になってくれるなら、本当に素晴らしいと思う。Typst は試験的にしか使っていないが、言語そのものは気に入った。正直、文章を書くときは文法そのものはそれほど重要ではないとも思う。ちなみに実際の修士論文では、最初は reStructuredText で書き、Pandoc で LaTeX と PDF を作り、全体構成が固まってから LaTeX 部分を手直しして必要な書式や図を描き直して仕上げた。長い preamble なしですぐ書き始められるのが利点だった。今でも、問題は文法ではなく、初期設計の段階で気にしすぎると本文そのものが書けなくなることだと思っている

    • Typst はまだあまり使い込んでいないが、私の感触では、テンプレート作成では LaTeX よりも黒魔術的な要素がかなり少ない。すでに LaTeX より自由に構造を作れるように感じる

    • 文書デザインやレイアウトをもっと直接的に制御したいなら、LaTeX や Typst ではなく ConTeXt を勧める。私はグラフィックデザイナーとして ConTeXt が大好きで、他のツールで置き換えるつもりはない。ただ、文章だけを書いてデザインを気にしないなら、LaTeX や Typst も依然として優れている

    • 私も reStructuredText で論文を書き、Pandoc と latexmk で PDF を作り、matplotlib と Python で生成した PDF グラフを無損失で埋め込んだことがある。reStructuredText ではできなかったことが何かあったのか気になる。LaTeX テンプレートも使えるし、reStructuredText 自体が Markdown など他のマークダウン系より強力なので、そのまま reStructuredText を使い続けても問題ないと思っている

    • あなたの脚注は、実質的に LaTeX がそれほど良い選択ではないことを示している。私も最近 Typst で論文を書き、それ以前は LaTeX を使っていた。LaTeX では Markdown で書いてあとから LaTeX に変換していたが、Typst ではその必要がなかった。今後 Typst がサービス品質を落とさずに進化し続けるなら、そのまま使い続けるつもりだ

  • 最近は Typst で Pandoc + LaTeX を置き換えて本を書いている(GitHub リンク)。Typst の文法は Markdown のように簡単で、LaTeX よりはるかにプログラムしやすい(とはいえ、まだ荒削りな部分もある)。LaTeX では常にパッケージに依存し、それぞれの奇妙な相互作用も避けなければならず、手間が多かった。Typst は必要な部分を自分で実装するのも簡単だ。非常に高速で、ファイルシステムに不要なファイルを大量に残すこともない。PDF 中心の技術文書なら本当におすすめできる

  • 代替組版システムとしては SILE もある。XML ベースと TeX スタイルの両方をサポートし、lua でスクリプトも書ける。(La)TeX や Typst と違って、公式ドキュメントに準ずる仕様もある。数式は MathML をそのまま使うこともできる。ただし Typst も SILE も実際には使ったことはなく、ドキュメントを読んだだけだ。HTML + MathML も悪くないし、XML ソース + XSLT でテンプレートを書いて OpenStax の教科書のように制作する事例もある(CNXML ベース)。troff(plus eqn)、Texinfo、org-mode、LaTeX 埋め込み、Markdown + HTML/MathML など、さまざまな組み合わせがある

    • HTML は手で書く分には悪くないが、MathML は本当にタグが多すぎて手書きするにはつらい。 を見ると、簡単な式でも大量のタグが付くのがわかる
  • 長年 LaTeX を使ってきた立場としては、LaTeX ではすでに数多くの特殊ケースを経験し、解決策も把握しているので、新しいシステムへ移るのは負担が大きい。Typst がどれほど良くても、その過程をまた一から繰り返すのかと思うと不安になるし、Typst のコミュニティがまだ大きくない中で、自分と同じ問題に遭遇して解決策を共有している人がいるのかも心配だ。公式の例だけを見ると非常に良さそうだが、LaTeX の強みは細かなカスタマイズ(字下げ、マーカー記号、間隔など)を精密に制御できることにあるので、Typst でも同じレベルの制御が可能なのか気になる

    • まったく同じ懸念がある。確かに非常に優れたレイアウト言語で、制作物の品質もずっと高い。しかし、新しい特異ケースや限界にまたぶつかるのは避けられない。Typst のユーザー基盤もまだ十分に大きくない。加えて、Claude Code のような AI が Typst をよく理解しているのか昨年試してみたが、そうではなかった

    • Typst は今でも、画像を本文中で自然にフロートさせる(テキストが回り込むなどの)機能を提供していない。画像をページ上部や下部に置くことはできるが、本文中の「浮動画像」はネイティブではサポートされていない

    • (字下げ、間隔、記号などの)リストのカスタマイズ制御については、公式ドキュメントで確認できる: Typst のリストモデル文書

    • もし別の機関(図書館、学会など)があなたの論文やペーパーを LaTeX でしか受け付けないなら、そのときどうするかも考えておく必要がある

  • Typst は本当にすごい。最近では、数学科の学生が論文を書かずに Typst パッケージ作成に寄り道している、なんて冗談まである。あと 10 年でどこまで進化するのか興味深い。長所: コンパイルが即時なので、.typ ファイルを保存するだけですぐ PDF が生成される。Markdown の代替として使うことも多く、特別な準備なしで美しい PDF をすぐ出力できる。短所: エラーメッセージが簡潔を通り越して圧縮されすぎていることがあり、デバッグしにくい。また、文法エラーが 1 つあるだけで PDF がまったく生成されないため、LaTeX の一部のデバッグ手法が使いにくい。外部パッケージで問題が起きることもあるが、LaTeX を長く使ってきた人にとっては驚くほどのことではない

    • Typst パッケージで起きる問題は、LaTeX のパッケージ問題とは性質が違う。Typst では関数説明が不十分だったり一般的なバグだったりと、より「プログラミングらしい」問題だが、LaTeX ではパッケージを読み込むだけで文書全体に予測不能な影響が及び、原因究明がほぼ不可能なことが多い。2 つのパッケージが単に「非互換」なこともよくあり、こういうことはまともなプログラミング言語では本来あってはならないものだ