Typstで博士論文を書きました

• 筆者は Typst を使って博士論文を執筆しており、従来の LaTeX とは異なる新しい挑戦だった
• 高速なコンパイル、整合性があり強力なスクリプト言語、容易なレイアウトのカスタマイズ、優れたコードハイライト により、文書の修正やテンプレート調整が非常に効率的だった
• 参考文献管理の不便さ、LaTeX 変換の限界、若いエコシステムゆえのテンプレート不足、エラーメッセージの限界 など、不便さと限界は明確に存在する
• LaTeX との互換性、共同作業、論文投稿時に求められる書式対応にはまだ不十分な点があり、論文の共同執筆や学会投稿では LaTeX が事実上の標準 であることを実感した
• Typst は プログラミング的な自由度と最新機能 が必要な場合に特に有利だが、初心者や標準的な要件には勧めにくい

---

博士論文を Typst で書いた理由

• 筆者は最近、博士論文を Typst で執筆し、伝統的によく使われる LaTeX の代わりに新しいタイポグラフィ言語を試した
• Typst は Markdown と動的型付けの Rust を組み合わせたような形で、文書作成が LaTeX より自然で、スクリプト言語としての拡張性にも優れている
• 構文が直感的で、コードと文書の切り替えがしやすい点が特徴だ

Typst の長所

コンパイル速度

• Typst コンパイラは 非常に高速 で、文書が大きくなってもリアルタイムの PDF プレビューが可能
• フルビルドも 15 秒前後で完了し、内容を変更した際にはほぼ即座に結果を確認できる
• レイアウトやスタイルの修正作業を効率よく繰り返せるため、最終成果物の品質向上につながる

言語設計とスクリプト活用

• Typst 言語は一貫性が高く、Rust ベースの設計 により学習コストが低い
• LaTeX で各パッケージごとに構文の一貫性が乏しいという不便さが、Typst では解消されている
• TOML ファイルを直接パースして、データを文書内で自動可視化できるなど、プログラミング的な応用 が豊富
• モダンなツール（コンパイラ、依存関係管理、LSP など）との統合も強みだ

テンプレートとレイアウト修正

• Typst のテンプレート構造は明快で、望む形に簡単に修正・拡張できる
• LaTeX の複雑なテンプレート修正に比べ、はるかに直感的で素早い設定体験を提供する

コードハイライト

• 組み込みの syntax highlighting 対応により、論文中のコードの可読性が高い
• Textmate grammar を活用でき、regex ベースのカスタム定義も容易に実装できる
• スクリプトで直接パーサーを書き、特定の構文ハイライトも試している

エラーメッセージ

• LaTeX に比べてエラー位置と原因を明確に案内してくれるため、問題解決にかかる時間が大幅に減る
• 不要なターミナル出力がなく、エラー情報が実用的に役立つ

Typst の短所

参考文献（bibliography）管理

• 論文全体で単一の bibliography しかサポートされず、章ごとや論文を取り込む場合に別々の参考文献ファイルを使えない
• Bibtex 変数などの高度な機能への対応が不足しており、Makefile による手動統合が必要
• パッケージ（Alexandria）で部分的な解決は可能だが、使い勝手や自動化の水準は低い
• 引用スタイル変換やフィールドマッピングなどの細かな調整が不完全で、手作業が避けられない
• 参考文献フィールドが Bibtex 標準と異なるため、結果に差が出る

エラーメッセージの限界

• 複雑なケース（例: Alexandria 使用時）では、具体的なエラー説明なしに単純な失敗メッセージだけが表示される
• 状態ベースの show rule などはエラー位置の追跡が難しく、デバッグの難易度が高い
• 一部のレイアウト関連警告は、原因の特定が容易ではない

複雑な現実: 互換性とエコシステム

LaTeX との互換性と共同作業

• 既存論文や投稿論文では LaTeX 形式が必要なため、Typst で書いたものを Pandoc などで変換して利用している
• 新しい論文も Typst で下書きした後、最終投稿用に変換作業が必要になる
• Typst から LaTeX への自動変換は完全ではないため、別途ツールを開発して作業を進めた
• 変換結果の一部（例: コード）は LaTeX の \includepdf を使う必要があり、出版社の要件に合わない可能性がある
• LaTeX が標準であるため、共同執筆者が Typst を新たに学ばなければならない煩わしさも生じる

Typst エコシステムの現状

• Typst はまだ 初期段階のエコシステム にあり、公式テンプレートや投稿フォーマットは限定的
• ユーザーが自分でカスタムテンプレートを作らなければならないことが多い
• 主要学会・ジャーナル向けの Typst テンプレートは、対応範囲や品質がまだ万全ではない

結論とおすすめ

• プログラミングを楽しめて、ツールの細かなカスタマイズに魅力を感じるなら、Typst で論文を書くことは十分おすすめできる
• 試行錯誤を高い頻度で繰り返せることと、カスタマイズの自由度の高さによって、成果物をより美しく仕上げられる利点がある
• 一方で、特別な追加設定なしですぐ使いたいのであれば、現時点の Typst は博士論文のような大規模文書には適していない
• 小規模な文書作成や個人的な実験には、Typst を試してみる価値がある

[GN⁺]

Hacker Newsの意見

• 30年後でもLaTeXはオープンソースのまま維持・管理されている可能性が高い一方で、Typstはオープンソースとクローズドソースが混在する構造なので、会社が消えたらプロジェクトも維持されなくなる可能性が高いのではないかという懸念
  • Typstプロジェクト自体はオープンソースとクローズドソースの混合と見るのは難しく、CLIとWebアプリが同じように動作するようにすることが中核目標だと開発者自身が述べている。関連するissueコメントを参照。LSP実装のtinymistなど、コミュニティが作ったオープンソースもある。また、Typstifyのような有料エディタも会社とは無関係に存在する
  • TypstのWebエディタはクローズドソースだが、編集に必要な要素の大半はオープンソースなので、ローカル環境でも同等かそれ以上の体験が得られる。TypstコンパイラやLSPなどはすべてオープンソース。OverleafでLaTeXプロジェクトを作る事例と似ており、Typst社が消えた場合でもパッケージのダウンロードはオープンソースのgitリポジトリベースなので、代替リポジトリを作れば大きな問題はないだろうという考え
  • オープンソース部分が放置されるというのは、実際には完全にオープンソースで配布されている大半のプロジェクトと変わらないという話でもある
  • クローズドソースに入っている「中核機能」とは、具体的に何なのか気になる
• 計算機科学の博士課程の学生たちが、なぜあれほど組版に執着するのか気になる。LaTeXに強い関心を示した末にマクロ作業へ数か月を注ぎ込むのを見ると、また一人LaTeX沼に落ちたと思ってしまう。LaTeXは先延ばし癖のある学生にとっての罠のように感じられる
  • 数学専攻として言えば、何もかも手書きで済ませるのはあまりに面倒で、数式の多い文書をタイピングで作るのも簡単ではない。実際、物理のほうが入力はさらに大変。論文や課題に集中する人生では、アイデアをどれだけ簡単に記録できるかが本当に重要になる。だからこそエンジンの品質に敏感になるし、マクロの小技も互いによく共有する。周囲から得た助言や基本ヘッダの共有が自然な文化になっている
  • LaTeXを使うと、ある種の「公式な感じ」が出る。数式もLaTeX文書で書くと非常に真面目に見えるが、Wordでやるとそうはならない。Aldus PageMakerで最初のニュースレターを作ってレーザープリンタで出力したときのように、プロになった気分になる
  • 大きな文書（たとえば論文）をセクションごとに別々のtexファイルで管理し、あとでまとめてコンパイルする構成が使える。gitのようなVCSとも相性がよい。スクリプトで図などを生成すると、LaTeXが新しいファイルを自動検知して再コンパイルしてくれる。Wordではそれぞれの図を自分で探して差し替えなければならず非効率。文書規模が大きくなるほどWordは不便になるが、LaTeXは最初だけ設定すれば、その後はむしろ効率的になる
  • 2000年代には、数式が少し入るだけでもWordで作業するのは相当つらかった。数十ページを超える数式と相互参照が必要になると、LaTeXでなければほぼ不可能だった。章ごとのファイル分割や、まともなエディタとの連携も重要な利点
  • 10年間にわたって論文やレポートを書いていれば、細かなsnippetを集めるのは執着ではなく自然な結果
• Typstが非常に有望に見える理由は、IEEEのような代表的テンプレートを標準で提供し、その出力結果がLaTeXとほぼ同一だから。LaTeXのツールチェーンには不便さが多く、makefileもときどき不安定。何度も回さないと正しい結果にならないことが多く、時には git clean -xdf までしないと解決しない。なぜそうなるのかいまだによく分からず、makefile自体も複雑すぎる
  • 「同じことを二度やって違う結果を期待するのは狂気だ」と言うが、LaTeXのコンパイルはまさにその通り
  • 完全な解決策ではないが、latexビルドの苦労を自動化してくれるLatexmkを勧めたい。使い方リンクを参照。加えて -outdir オプションで中間ファイルを分離管理できる
  • 自分もかつては、なぜ複数回回す必要があるのか理解していたが、今では思い出せない。昔使っていた個人用buildスクリプトにも、bibtexを使うときは3回、そうでなければ2回回せという条件分岐があった。今見ると、あの時代が終わってせいせいする
  • 最近はTectonicを使えば、こうした反復コンパイルの問題は自動的に解決される
• AIこそが文章作成の主な相手であり、マークアップ形式を選ぶ主な理由でもある。意味的圧縮という観点では、Typst、markdown、asciidocはLaTeXよりはるかに簡潔。個人的にはこの6か月で、AIを使った数学研究やコード作業が大きく変わったが、この領域には確かな正解や助言が見つかりにくい。実際、AIはSVGの数学ダイアグラムも人間よりうまく読み、LaTeXソースを読むのは好まない。ジャーナル側のフォーマット規定は理解できるが、時代遅れな2段組出力を強制するジャーナル編集者も多い。紙での出力に大きな意味がない時代なので、あまり気にせず、今後は研究成果をアニメーションやTypst文書として残すつもり
  • 実際に論文を印刷して読む専門的な科学コミュニティでは、紙はいまだに効率的
• ジャーナルやカンファレンスがまだtypstを受け入れていないので、自分はわざとLaTeXに固執しているのではなく、現実的にLaTeXにとどまらざるを得ない。導入するかどうかは、彼らにツールチェーンへ統合する意思があるかにかかっている
• だんだん自分の作業をTypstへ移しているが、動作が速く快適。ただし、数式記法を新たに覚えるのが最大のハードルだった。Typst独自のルールがあり、新しく習得する必要がある
  • Typstもよさそうだが、Claude CodeとVS Codeの組み合わせによって再びLaTeXを使うようになった。LaTeXからしばらく離れていたものの（博士号取得後10年あまり）、昔はTikZや数式、preambleマクロを暗記するほど使っていた。Claude Codeは、望むものを入力すると1、2回でほぼ欲しい結果を出してくれる。LaTeXのエラーメッセージの解釈もClaudeが95%は解決してくれるので、以前ほど大きな問題ではない
  • mitexも一つの選択肢。mitexパッケージを参照。自分はもう別の記法を新たに覚える気力がない
• typstのソースと出力結果が気になるなら、自作したいくつかの文書を共有する:
  • Latex Resume Template参考版
  • Enduring Power of Attorneyの例
  • 遺言書テンプレート
• Typstは数年以内に消えるか会社に買収される可能性が高く、LaTeXは今後数十年残るだろうという見方
• TypstはLaTeXより縦方向レイアウト制御などで魅力的なので移行しようとしたが、最近のChatGPT系LLMのコード生成能力が向上したことで、新しいマークアップエンジン、特にtypstではかなり力不足に見える。AIはlatexについてはひどいながらもtypstよりははるかにましで、typstでは本当に結果が出ない。6か月か1年もすれば多少は改善するかもしれない
  • LLMを使うと思考量が減って楽ではあるが、LLMに依存しすぎて新しい道具自体を使えない人が多いのはもどかしい。昔も、コピペできないとかコードsnippetを探しにくいといった理由で新しい言語を避ける人がいたが、それと似た現象
  • markdownやrustではAIはかなり実用的。Typst文書のアウトラインをLLMのプロンプトに入れれば、少しは役に立つかもしれない
• Typstで気に入らないのは、今やLaTeXの数式文法がほぼ標準として定着しており、すでに広く使われているため、新しい数学文法を覚えにくいこと
  • 実際、Typstでも $x^2=1$ のような表記はそのまま動く