Acetaminophen’s diary

化学に関すること,TeXに関すること,ゆきだるまに関すること。

TeX Live をホンキで語る ― 「TeX Live ってなんだろう?」

これは TeX & LaTeX Advent Calendar 2016 の 5 日目の記事です。昨日は tex-ut-tex さんでした。明日は doraTeX さんです。今年はあと一回、7 日目にも参加しました。

最近では、TeX Live のインストール手順のわかりやすい解説がたくさん世に出ています。内容も「最近はデフォルトの設定で簡単にインストールできますよ!」という事例紹介が多く、昔に比べると日本語の TeX 環境を整えるのが楽になったことの表れで好ましく思います。しかし同時に、TeX Live が成長し大きくなるにつれて、全体を俯瞰することがほとんど不可能になってしまったように思います。

f:id:acetaminophen:20161204224308p:plain

たとえばこんな疑問を持ったことはないでしょうか。

  • なんでパッケージは頻繁に新しくなるのに、LuaTeX は(既に v1.0 がリリースされているはずなのに)まだ 0.95.0 なの?
  • パッケージを作ったんだけど、TeX Live に入れてもらうにはどうしたらいいの?
  • プログラムのバグを見つけたんだけど、ソースコードはどこにあるのかな?

今回は、成長を続ける TeX Live の裏側、特に「TeX Live の開発者たちの行動」や「(pLaTeX やなんとかパッケージのような)一般の開発者と TeX Live の中央の開発者との関係性」に焦点を当てて、普段は意識しない TeX Live そのものに注目して「ホンキの解説」を試みます。開発活動について知りたい人にとっても、ちょっとカスタマイズしたい一般のユーザの方にとっても知って損はしない情報だと思います。

 

そもそも TeX Live とは

公式サイトによると、1996 年から世界中の TeX ユーザの集まりである TeX Users Group によって開発が始まりました。1970 年前後に Knuth さんが TeX の開発を始めて以降、世界中で開発者がバラバラに TeX 周辺ツールやその拡張を開発し、各々ソースやプログラムを(ネットワークのみならずテープなどの形態でも!)配布していました*1。これではインストールするのが一苦労なので、TeX Users Group がそれらのソースやパッケージを一箇所に集め、一気にインストールできるようにすることを目指したわけです。このような考え方による配布物の集合体を「TeX ディストリビューション」と呼ぶわけです。2016 年現在はこの TeX Live と、もうひとつ MiKTeX*2が二強とみてよいでしょう*3

この TeX Live は非常に多くの環境で利用できるため評判が高く、Mac 環境でよく知られている MacTeX / BasicTeX(Richard (Dick) Koch さんによる)のような派生版 TeX ディストリビューションのベースとなっていたり、Windows 環境で良く知られている W32TeX角藤亮さんによる)も 2010 年以降は TeX Live のカスタマイズ版といえるような形態になっています。このあたりの関係性については別の機会に説明するかもしれません。

 

TeX Live の開発者

さまざまなツールを集積した TeX Live ですが、個別ツールのメンテナが作ったものをそのまま取り込むだけではうまくいきません。集めるだけでなく幅広い環境でビルドできるようにサポートしたり、インストールを簡略化するためのスクリプトを開発したりする必要があります。このようなインフラ部分の整備や、個別ツールのアップデートや新規収録なども、もちろん TeX Live の開発者の方々が常に行ってくださっています。

TeX Live の初期から中心となって活動していらっしゃるのが、Karl Berry さんという方です。2016 年現在、日本人(または日本在住・日本語話者)の TeX Live 開発者*4としては、角藤亮さんWindows 環境に TeX を移植した開発者で、W32TeX のメンテナでもある)、田中琢爾さん(pTeX の内部処理を Unicode 化した upTeX の開発者)、Norbert Preining さんDebian 向けの TeX Live パッケージのメンテナ;ブログあり)がいらっしゃいます。

 

TeX Live の全貌(中央での管理体制)

既に述べたとおり、TeX Live はさまざまなプログラムやパッケージを収録したものです。実はみなさんのお手元にインストールされる「TeX Live」は、中央で管理されているもののごく一部といっても過言ではありません。

TeX Live の「真の全貌」が見える場所は、すべてを収録した subversion (svn) リポジトリを訪れるのがよいでしょう:

ここに、各種パッケージやドキュメント、さらにはプログラムのソースコードまで、TeX Live に関係するあらゆるものが管理されています。少しずつ見ていきましょう。

 

subversion の探検:パッケージやドキュメントなど

まずは svn リポジトリの Master ディレクトリ以下を覗いてみましょう。

texmf-dist というディレクトリや bin というディレクトリが見えますね。TeX Live をインストールしている方は、お手元のコンピュータにある texlive/20xx ディレクトリのなかを見てみてください。構成が非常に似ていることがわかります。そう、みなさんのお手元に届いているファイルはすべてこの Master 以下に収録されているのです。

一般ユーザがインストールする TeX Live は、svn の Master ディレクトリ以下の“一部”です。“一部”とは具体的には以下のとおりです。

  • bin/[該当するプラットフォーム]
  • readme-*
  • texmf-dist
  • tlpkg
  • その他ドキュメントなど

texmf-dist を見ると、お手元の TeX Live と全く同じ状態になっているはずです。\usepackage に書くようなパッケージたち、LaTeXpLaTeX といったフォーマットのコード、さらにそれらを説明したドキュメント類や関連する TeX ソースファイルなどが入っています。tlpkg には収録パッケージのデータベースや少数の補助スクリプトなどです。

svn の Master 以下のうち一般ユーザ向けには省略されているモノは以下のようなものです。
  • bin/ 以下をみると、svn では各種プラットフォーム向けのバイナリが収録されています。一人のユーザが一つの環境にインストールすべきバイナリは一種類ないし二種類*5(bin/win32 や bin/x86_64-linux など)ですから、該当するもの以外はインストールせずに済みます。
  • source/ には大まかに「TeX Live チームが一切関与していないが、TeX Live に収録するプログラム」あるいは「TeX Live と非常につながりの深い“派生ディストリビューション”」のソースコードです。たとえば TeX Live では Windows だけ、Ghostscript を同梱しています。この Ghostscript は外部で開発されていますから、TeX Live がそれに手を加えることはなく、ただ取ってきているだけという様子です。

この subversion リポジトリで変更が加えられる(この手順については後述)と、世界中の TeX Live ミラーサイトに反映され、すると一般ユーザの元にアップデートとして届けられるわけです。subversion でのアップデートからお手元に届くまでが約一日~二日かかります。

 

subversion リポジトリの探検:バイナリのソースコードプログラム

先ほどの Master/bin/ 以下にはバイナリが収録されていて、それがそのままユーザの元に届きます。Knuth さんによるオリジナルの TeX も、拡張された各種エンジン pdfTeX, XeTeX, LuaTeX、日本語化された pTeX, upTeX、それに DVI ドライバ(または DVIware)とよばれる dvips, dvipdfmx、さらには文献を扱う bibtex, pbibtex, upbibtex、索引を扱う makeindex, mendex, upmendex、…とあらゆる実行用プログラムが bin/ 以下に収録されていますよね。

ではバイナリの元となっているソースコードはどこに…? という疑問がわいてくるでしょう。TeX Live では、これらのプログラムのソースコードsvn リポジトリの Build ディレクトリ以下で管理しています。こちらも覗いてみましょう。

Build → soure → texk とたどっていくと、ここに見覚えのあるプログラムの名前がいくつも出てきます。dvipdfm-x というのは dvipdfmx(と、XeTeX の TeX 組版処理のあとに PDF 出力を担う xdvipdfmx)のソースです。dvipsk というのは dvips ですし、mendexk は mendex ですね(k という接尾辞が付いているのは、大昔に存在した kpathsea 非対応な dvips と区別していた名残と思われます)。

【脱線】…えっと、kpathsea については補足が必要かもしれません。TeX 関連のファイルはすべて TEXMF ツリー(texmf-dist とか texmf-local とか)の下に入れて管理することになっていますが、ここから目的のファイルを探し出すシステムのことです(“K”arl さんによる “path” “sea”rch システムだと思います)。コマンドライン
$ kpsewhich jsarticle.cls
/usr/local/texlive/2016/texmf-dist/tex/platex/jsclasses/jsarticle.cls
のようにファイルの場所が返ってくるのはこの kpathsea のおかげですし、このシステムがないと膨大な TeX Live のファイルをディレクトリ別に整理してうまく呼び出してやることなど不可能です。

では「ナントカ TeX」はどこにあるかというと、この一つ下の web2c というディレクトリの中です。このなかに ptexdir や uptexdir や eptexdir や euptexdir が見えますが、それぞれ pTeX / upTeX / e-pTeX / e-upTeX に対応します。また、pdftexdir や xetexdir や luatexdir も然りです。

【また脱線】web2c とはなんでしょうか? TeX というプログラムは、Knuth さんによって創始された「文藝的プログラミング (literate programming)」という概念に由来します。これは、プログラムのソースコードとその説明を同じファイルに記述し、あたかも読み物のようにソースコードを理解できるという理想です。この具体的な方法が、TeX というプログラムのソースコードPascal 言語で記述するときにまわりにコメントを埋め込んだ「WEB」という新たな言語体系でした。しかし、Pascalコンパイラは所有する人がそう多くないので、より一般的な C 言語のコンパイラTeXコンパイルできるようにするのが WEB2C (WEB to C) という翻訳プログラムです。ナントカ TeX のソースは(LuaTeX のようなモダンTeX エンジン*6を除いて)Pascal WEB で書かれていますので、そこから C 言語に翻訳する必要がある…というわけで web2c ディレクトリの下に管理されています*7

一般のユーザが TeX Live をインストールするときには、この Build ディレクトリ以下は全く手元に届きません。既に述べたとおり、Master/bin/ 以下の「ビルド済みのバイナリ」が届くので、各自が TeX 関連プログラムをビルドする必要がないためです。

これはどういうことかというと、もうお分かりのとおり、どこかの誰かが Build 以下にあるソースをコンパイルして、バイナリ形式にしたものを Master/bin/ 以下に作ってくださっているのです。皆さんはそれがネットワークから落ちてくるのをそのまま使えばよい、簡単ですね!

では、このコンパイルは誰が行っているのでしょうか。これはすべてボランティアで成り立っていますコンパイルしてくださっている方の一覧は、公式サイトの Building TeX Live の Volunteer builders の項目にリストアップされています。2016 年現在、Norbert Preining さんと Akira Kakuto さんの名前もあります。この方々が年に一回ビルドして下さっているので、みなさんは「ソースを取ってきて、コンパイルして…エラーが出たよ(泣)」のような手間を取らなくて済むわけです。

 

TeX Live による成果物のインポート

TeX Live の svn の構造を大まかに見たところで、その中に収録されているいろいろな成果物が「どこからやってきたのか」を考えてみましょう。これは「バイナリのソースコード(Build 以下)」と「パッケージ類(Master 以下)」では少々異なりますので、個別に説明します。

Master 以下のもの:CTAN からのインポート

TeX Live でみなさんが利用している各種パッケージやフォントなどは texmf-dist に入っているわけですが、元はといえば世界中のパッケージ開発者が作ったものです。では、世界中のパッケージをどうやって TeX Live は集めることができるのでしょうか。

パッケージ収録に際し、TeX Live が頼っている巨大なアーカイブの枠組が、CTAN です。

世界中の TeX ユーザは、自分で作成した便利パッケージを他人にもぜひ使ってほしい場合、すべて CTAN に登録することになっていますTeX Live は CTAN をほぼ毎日チェックし、更新分があれば取り込みますし、まだ収録していない新しいものが見つかれば(そのライセンスが自由な再配布を許していれば)これも TeX Live に取り込みます。

逆にいえば、CTAN に登録していないパッケージを TeX Live が収録することは最近ではほぼありえません。TeX Live で自分のスゴイパッケージを使えるようにしたいと考えた場合は、すみやかに CTAN に登録しましょう

ちなみに私自身も pLaTeX や upLaTeX などをアップデートする際に CTAN に登録していますし、platex-tools バンドルなどいくつかのパッケージを CTAN に公開し、無事 TeX Live に収録していただいています。

この CTAN から TeX Live への取り込みは、ほとんど自動化されているといってよいでしょう*8。とはいえ、ときどきファイルの収録場所に間違いが生じることもあり、その場合は TeX Live のメーリングリストに流せば対処してくださいます。

Build 以下のもの:上流からのインポート or 直接コミット

TeX Live が収録しているプログラムも、元はといえば世界中の開発者によって書かれたものです。しかし、ソースコードの収録については texmf-dist のパッケージとは少し事情が異なります。もちろん TeX 関連の成果物ですので CTAN に登録することができますが、それだけでは TeX Live に収録されるとは限りませんし、既に TeX Live に収録されているもののアップデートを CTAN に登録しても反映されるとは限りません。新しいプログラムが公開されても、TeX Live がサポートしているすべてのプラットフォームでコンパイルが難なく通るということは少ないでしょうから、自動的にというわけにはいかないのでしょう。

では TeX Live がどのようにソースコードを維持管理しているかというと、これはプログラムに依ります。TeX Live が取り込んだ後に本家開発元が活動終了してしまった場合は、もはやメンテナンスする人がいません。この場合、TeX Live の svn で不具合修正などが直接行われます。2016 年現在、pTeX 系や dvipdfmx などはその類で、たとえば pTeXアスキーによる最後のリリース (pTeX 3.1.11) 以降、北川弘典さん(e-pTeX の開発者;LuaTeX-ja の開発者)などが修正パッチを書いてくださり、それが TeX Live に送られて反映されています。

【ごく最近の話】2016 年 12 月から、“上流”が存在せずに TeX Live svn の Build 以下で直接コミットされていた「日本語関連のプログラム」のソースコードが、日本語 TeX 開発コミュニティの GitHub 上に minimal TeX Live tree という形で置かれるようになりました。 現在準備中ですが、今後ここが日本の TeX 環境の開発拠点となる可能性も秘めています。

一方、本家が活発に開発活動を行っている場合は、TeX Live が独自に svn で変更を加えることはありません。主なものは LuaTeX で、本家 svn リポジトリの変更に定期的に追随するだけ開発がすすめられます(svn変更履歴を見てみると、sync with the upstream と書かれていますね!)。

新しいプログラムの収録については、TeX Live に収録してほしい」と直接 TeX Live のメーリングリストに要望を出すのが確実でしょう。実際に私は行った経験はありませんが、たとえば TeX Live 2016 で新たに収録された upmendex はこの方法をとったようです。

 

TeX Live の一年周期の開発サイクル

先ほど「この方々が年に一回ビルドして下さっている」と書きましたので、いったん大まかな TeX Live の開発サイクルをみておきます。これは以前の記事にも書きましたが、おさらいしておきます(引用一部改変)。

TeX Live の開発は、TeX Live 2015 や TeX Live 2016 と名のつくとおり一年周期です。TeX Live 2016 を例にすると
  • 2016 年 4 月頭 : TeX Live 2015 frozen
    • 一般向けのパッケージ類の更新停止
  • 2016 年 4 月 -- 5 月 : TeX Live 2016 pretest
    • ボランティアがバイナリを新しくなったソースからビルド
    • 有志が新しいバイナリとパッケージをテスト
  • 2016 年 6 月 : TeX Live 2016 正式リリース
    • 一般向けに新しいバイナリ配布(むこう 1 年間は critical なバグ以外直さない)
    • 一般向けに新しいパッケージが 2 ヶ月ぶりに届く
  • 2017 年 4 月頭 : TeX Live 2016 frozen
    • 一般向けのパッケージ類の更新停止
    例年、このような周期になっています。

4 月 -- 5 月の「ソースからビルド」というのが「Build 以下にあるソースコードをビルドして Master/bin に置く」という作業を指します。4 月から 5 月にかけては TeX Live 開発陣の“繁忙期”で、次にリリースする TeX Live 20xx を確定させるために活発にコミットが行われます。例年 5 月上旬に作業が一段落し、「これで TeX Live 20xx のソースコードは完成だ!」と判断されると、しばらく svn の Build へのコミットは停止し、ボランティアの方々が各 OS 向けに全く同じ revision のソースコードから一斉にコンパイルを行います。すべてのプラットフォームのバイナリが出そろってしばらくテストされた後、6 月頃に「TeX Live 20xx リリース!」になるわけです。

このコンパイルは OS によっては結構大変らしく、毎年いくつかの OS ではエラーが出たりビルドが通らなかったりするようです。それでもなんとかビルドを成功させ、同じソースコードからバイナリを完成させるのは「TeX Live 2016 ならばどのプラットフォームで動作させても同じ結果になる」ということを保証するためでしょう。win32 は新しく linux はちょっと古い…というようなことが起きるとややこしくなってしまいますから、一斉に同じソースからコンパイルすることに意味があります。このことを考えると、「年に何度もボランティアがコンパイルする」のは極めて困難であると思われます。LuaTeX v1.0 が 2016 年 9 月にリリースされても、TeX Live 2016 の期間中は 0.95.0 に固定されているのもうなずけます。

 

TeX Live Manager (tlmgr) によるパッケージ管理とアップデート

TeX Live 20xx をインストールしたあと、ユーザの皆さんは (sudo) tlmgr update --self --all を実行して手元の TeX Live をアップデートしていると思います。この tlmgr について、しばしば誤解されている点についても触れておきましょう。

その1:tlmgr の“パッケージ”と LaTeX の“パッケージ”は違う

TeX Live をフルインストールする場合には「全部」入るので問題になることはほぼありませんが、「最低限の LaTeX 関連ツール (scheme-small) と日本語関係 (collection-langjapanese) だけインストールして、必要なパッケージは個別に tlmgr でインストールする」という運用をしている方もいらっしゃるようです。このとき、tlmgr でインストールしたいパッケージをなぜか見つけられないという声を時々ききます(直近では TeX.SX の質問 にもありました)。この原因は多くの場合「LaTeX パッケージの名前がそのまま tlmgr でインストールされるパッケージの名前になっているとは限らない」からです。“パッケージ”には二通りの意味があるというのです。

分かりやすい例として、LaTeX パッケージである color (color.sty) を考えます。

$ tlmgr install color
tlmgr: package repository ftp://ftp.kddilabs.jp/CTAN/systems/texlive/tlnet (verified)
tlmgr install: package color not present in repository.

このように見つからないと怒られます。でも確かに TeX Live には color.sty が収録されています。ではどこにあるのでしょうか。

答えは「graphics パッケージ」です。ほかにも、plext.sty は「platex パッケージ」に含まれますし、jsarticle.cls などは「jsclasses パッケージ」に含まれます。一般化すると、以下のようになります。

  • tlmgr の引数に与えるべきは「TeX Live に何という名前で収録されているか(=これが“tlmgr のパッケージ”)」である
  • 多くの場合、原著者がひとまとめ(バンドル)にして CTAN にアップロードしたものは、丸ごと単一の“tlmgr のパッケージ”として登録される
  • したがって、\usepackage に書き込む LaTeX パッケージ(.sty ファイル)の名前が“tlmgr のパッケージ”と一致することもあれば、一致しないこともある

tlmgr にとってのパッケージは非常に広い意味を持ち、LaTeX パッケージ (.sty) やクラスファイル (.cls) を集めたパッケージのほかにも、フォントファイル (.otf/.ttf) を集めたパッケージ、解説本のようなドキュメント (.tex, pdf) だけのパッケージなど多種多様です。考えてみれば、一つの成果物に複数のファイルが含まれる(例:jsarticle.cls と jsbook.cls とか)ことは往々にしてありますから、仮にそれを個別にひとつずつ tlmgr で呼ぼうとすると不便で仕方ありません。上の仕組みをとることで、CTAN からのインポートもローカル環境でのインストールも合理的に行うことができるのです。

「解説本のようなドキュメント (.tex, pdf) だけのパッケージ」の例として、LaTeXTeX のリファレンスといえる文書も TeX Live には多数含まれています。これらを紹介した良質なまとめが、wtsnjp さんにより執筆されています。(追記:2016-12-26)

問題は、たとえば LaTeX 文書のタイプセット中に Package 'hoge' not found というエラーが出た場合、どうやってそれに対応する“tlmgr のパッケージ名”を知るかでしょう。名前が異なるとなると、どうやって tlmgr install すればよいかわからなくなってしまいます。

ここで便利な方法が一つあります。tlmgr に教えてもらいましょう

$ tlmgr search --global --file ifpdf.sty
tlmgr: package repositories
	main = http://mirror.ctan.org/systems/texlive/tlnet (verified)
	tltexjp = http://texlive.texjp.org/current/tltexjp (verified)
oberdiek:
	texmf-dist/tex/generic/oberdiek/ifpdf.sty

このように、LaTeX パッケージなどのファイル名で検索するとそれを含んでいる“tlmgr パッケージ”が表示されます。oberdiek というパッケージに含まれていることがわかりますね! この oberdiek パッケージってなんだろうと思ったら、その説明も見てみましょう。

$ tlmgr info oberdiek
package:     oberdiek
category:    Package
shortdesc:   A bundle of packages submitted by Heiko Oberdiek
longdesc:    The bundle comprises packages to provide …(略)…
installed:   Yes
revision:    41346
sizes:       src: 5181k, doc: 19021k, run: 2809k
relocatable: No
cat-date:    2016-07-05 18:29:32 +0200
cat-license: lppl
cat-topics:  collection
collection:  collection-latex

私の環境では既にインストール済みでしたので、installed: Yes と表示されています。

【少し高度な話】tlmgr info を紹介しましたが、これは、お手元にインストールされた TeX Live に付属している巨大なデータベースファイルをパースして情報を見せてくれています。データベースの実体は texlive/20xx/tlpkg ディレクトリの中にある texlive.tlpdb ファイルで、すべての“パッケージ”のファイル情報を保管した巨大なテキストファイルです。読んでみると name の行にあるのが “tlmgr のパッケージ” で、その下にファイル名や短い説明が書かれていることがわかります。

他の方法としては、CTAN の search を使う方法もあります。たとえば color を検索してみると…

f:id:acetaminophen:20161204223934p:plain

Package color と出てきたところをクリックしてみると

f:id:acetaminophen:20161204224356p:plain

Contained in TeX Live as graphics

と書かれているのが分かります。要するに、いわゆる LaTeX の「color パッケージ」は TeX Live には graphics という“tlmgr のパッケージ”として収録されているということです。ほかにも、ifpdf を検索してみると TeX Live as oberdiek と出てきますから、oberdiek という“tlmgr のパッケージ”をインストールすれば LaTeX の「ifpdf パッケージ」が付いてくることがわかります。

その2:tlmgr は依存関係を完全には解決できない

Unix 系のプラットフォームでよく知られているように、世の中には apt や pacman や port や brew といったパッケージマネージャがあります。これらは、たとえば sudo port install hoge とすると、hoge 単独ではなくその動作に必須な外部パッケージたちも一緒に引っ張ってきてインストールすることが多いでしょう。

ところが、これは tlmgr については成り立ちません。つまり、tlmgr は「パッケージをインストールすると必要なパッケージがすべて自動で入ってくれる」という代物ではありません

これには困難な事情があります。tlmgr に登録されているパッケージは既に 3,000 を超えていますが、それはすべて CTAN にアップロードした大勢の開発者によるものです。開発者によっては「必須パッケージ」をドキュメントに明記している場合もありますが、そうでない場合も(特に昔ながらの古いパッケージに)非常に多いのが実際です。明記されていない場合も含めて tlmgr を完璧にしようとすると… TeX Live のメンテナが大昔のパッケージも含めて逐一チェックして、どのパッケージがどのパッケージを必要としているか調べなければなりません。更新のたびに依存関係が変わる可能性もありますし、膨大な数のパッケージをチェックするのは現実的ではありません。昔と違ってネットワーク環境も強化されて高速にダウンロード可能となったいま、そもそも「フルインストールしてしまえば万事解決」なのですから、苦労する割に得るものが少ない=モチベーションが上がらないのもうなずけます。ですから、tlmgr はそういうものだと割り切って理解するのがよいと私も考えています(もし納得いかないということであれば、ぜひ画期的な案を提案しましょう!)。

この事実を逆説的にとらえて、「自分で CTAN にパッケージをアップロードするときは、ドキュメント(PDF ファイルの中でなく、できればテキスト形式の README)に依存パッケージや動作条件を明記する」ということを心掛けるのもよいでしょう。

 

まとめ

巨大な TeX Live がどのように管理されているのか、その片鱗が見えてきたのではないでしょうか。公式ドキュメントは TUG のウェブサイトにありますが、日本語でこの TeX Live の仕組みを説明した文書はほぼ見当たらないように思います。この記事が少しでも参考になれば幸いですし、裏方として日々メンテンナンスにあたってくださっている方々(そしてこれまでさまざまなかたちで貢献してくださったすべての方々)に感謝しつつ、TeX Live で快適な TeX ライフを送りたいですね!

Happy TeXing!

*1:アスキーにより日本語化された pTeX もそうした関連ツールのひとつですし、dvips や dvipdfm の日本語化パッチ、dviout のようなビューアもまた関連ツールのひとつです。

*2:Windows でよく知られており、Christian Schenk さんによります。日本語の pTeX や upTeX などは収録していません。

*3:TeX Live や MiKTeX と並んで、かつて広く用いられていた大きな TeX ディストリビューションとしては、Thomas Esser さんという方による teTeX(2006 年で開発終了)というものもありました。

*4:このような呼称はないとおもいますが、本記事では「TeX Live のソースリポジトリにコミットする権限を持っていて、活発に活動されている方」と定義します。

*5:たとえば Mac 環境では x86_64-darwin と universal-darwin の二種類がインストールされることが多いようです。

*6:LuaTeX は元の TeX ベースでなく、その“時代遅れなところ”を積極的に改変していろいろな拡張が施されています。そのソースは WEB から C に翻訳した状態で開発されており、文藝的プログラミングとの掛け合わせで CWEB と呼ばれます。

*7:個人的には WEB が Pascal ベースで、さらに Knuth さんの「TeXソースコードKnuth 以外改変してはいけない」という特殊なライセンスに起因する change file という独特のパッチ方式のために、私には読みこなすのが難しい代物です。

*8:ctan2tds というスクリプトが書かれていて、必要に応じて継ぎ足しながら使われています。CTAN に登録されたファイルのうち sty は TEXMFDIST/tex 以下に、pdf は TEXMFDIST/doc に…というように、ファイル形式に応じて TEXMF ツリーの下に自動的に分類されているようです。