コミュニティ

LaTeX で行き詰まったとき、答えを持っている人はたいてい tex.stackexchange.com にいます。ただしこのコミュニティには入場料があり、それは礼儀正しさではなく 最小の再現例（minimal working example、略して MWE） です。どれくらい本気かというと、TeX Live には MWE を作りやすくするためだけの mwe というパッケージが同梱され、texdoc minexample と打てば「MWE の作り方」だけを論じた 21 ページの小冊子が開きます。このページでは、LaTeX の質問をどこへ持っていくか——TeX Stack Exchange、Usenet の comp.text.tex が残したもの、TUG と各国のユーザ会、パッケージの issue tracker——と、答えが返ってくる聞き方、すなわち 300 ページの文書を 20 行まで削る手つきを扱います。

まず tex.stackexchange.com を検索する

LaTeX の質問の大半は、すでに誰かが同じ言葉で聞いています。 TeX Stack Exchange（tex.stackexchange.com）が作られたのは 2010 年 8 月。この日付は伝聞ではなく、LaTeX チーム自身の会報に残っています——TeX Live に同梱される『LaTeX3 News』第 5 号（2011 年 1 月）が「TeX Stack Exchange の Q&A サイトが作られ、急速に成長した。執筆時点で約 2,800 人が 2,600 の質問を投げ、回答は合わせて 5,600、1 日あたり 2,200 人が訪れている」と書き留めています。手元で texdoc l3news と打てば同じページが開きます。十数年を経て桁が二つほど変わりましたが、増えたのは何より過去問の在庫です。検索するときのコツは一つ——自然文で説明せず、エラーメッセージを原文のまま貼ること。! Undefined control sequence や ! Missing $ inserted のような一行は、そのまま検索キーとして最良です。

その前の三十年、TeX の議論の重心は Usenet のニュースグループ comp.text.tex にありました（ドイツ語圏には de.comp.text.tex がありました）。どれくらい中心だったかは、当時の本の謝辞を見ればわかります。Victor Eijkhout は『TeX by Topic』（1991 年、Addison-Wesley）の謝辞で、メーリングリストの TeXhax、オランダの TeX-nl、そして comp.text.tex の参加者に礼を述べ、彼らの質問と回答が考える材料をくれたと書いています。この本は TeX Live に同梱されていて texdoc texbytopic で読めます——謝辞ごと読めるので、コミュニティの重心が移動したことを目で確かめられます。newsgroup は今も生きていますが、いま LaTeX の質問をするなら第一選択は TeX Stack Exchange です。古い記事を検索して当たることは今もあるので、見つけたときは「何年のものか」を必ず確認してください。

最小の再現例（MWE）とは何か

MWE とは、問題を再現できる、いちばん短い「完結した」文書です。この定義は厳しめに読んでください。Nicola L C Talbot の『Creating a LaTeX Minimal Example』（2014 年、TeX Live 同梱、texdoc minexample）は冒頭で、最小例には問題に寄与しないパッケージやコードを一切入れてはならないが、文書クラスと document 環境は必ず含めなければならない、と釘を刺しています。つまり断片ではありません。相手がそのまま保存して pdflatex を通せる形——これが「working」の意味です。逆に言えば、\begin{document} の無い 3 行のコード片を貼ると、回答者はまず「完全な例を出してください」と返すことになり、往復が一回増えます。

% A minimal working example: complete, compilable, and as short as it can be.
% Nothing here that does not bear on the problem being reported.
\documentclass{article}
\usepackage{booktabs}
\begin{document}
\begin{tabular}{ll}
  \toprule
  left & right \\
  \bottomrule
\end{tabular}
\end{document}

例に図が要るときは詰まります。手元の写真は送れませんし、送られても相手の環境には無いからです。ここで効くのが mwe パッケージで、\usepackage{mwe} と書くと graphicx を読み込み、さらに example-image、example-image-a、example-image-16x9、example-grid-100x100bp といった標準の画像ファイル群を TeX ツリーから使えるようにします。これらは TeX Live を入れた全員の手元にあるので、\includegraphics{example-image} と書いた例はそのまま誰の環境でも通ります。同じ理屈で、長いダミー本文が要るときは lipsum の \lipsum[1-3] や blindtext の \blindtext を使います（mwe は lipsum があれば自動で読み込みます）。添付ファイルを必要としない例は、それだけで答えが早くなります。

300 ページを 20 行に削る——building up と hacking down

道は二本しかありません。Talbot はそれを building up（積み上げ）と hacking down（削り落とし）と呼んでいます。積み上げは、\documentclass{article} と空の document 環境だけから始めて、問題が出るまで一つずつ足していく方法。削り落としは、実際の文書の複製から、問題が消えるまで削っていく方法です。原稿が短いなら積み上げ、300 ページあるなら削り落としが速いのですが、削り落としを一行ずつやってはいけません。半分ずつ消すのです。プリアンブルの前半をコメントアウトして問題が残れば、前半は無実だと一度に判明します。残った半分をまた半分に——十数回で数百行が数行になります。これは二分探索そのもので、\include された章にも同じ手が使えます。

• 複製を作る。 元の .tex は絶対に触らない。削り作業は必ずコピーの上で行います。
• 本文を先に捨てる。 \include された章、図、表、参考文献を落とし、\begin{document} の直後に問題の一行だけを残します。
• プリアンブルを半分ずつ消す。 問題が残れば消した側は無実。残れば残ったほうを疑い、また半分に割ります。
• 自作マクロを展開する。 \newcommand の定義を中身で置き換えると、問題が自分のマクロにあるのか本体にあるのかが分かれます。
• クラスを article に置き換えてみる。 それで再現しなくなったらクラスが原因で、それも立派な発見です。ただし報告するときはその事実ごと書きます。
• 削るたびにコンパイルする。 消しすぎて問題が消えたことに気づかないまま進むのが、いちばんよくある失敗です。

削り終えたら、最後にバージョン情報を添えます。手で書き出す必要はありません。\documentclass の前に \listfiles の一行を置いてコンパイルすると、.log の末尾に *File List* という節ができて、読み込まれたファイルの日付とバージョンが全部並びます。エンジン（pdflatex / xelatex / lualatex）とディストリビューション（TeX Live 2024、MiKTeX、Overleaf）を書き添えれば、これで回答者はあなたの環境をほぼ再現できます。エラーは要約せず、! から始まる行と続く数行をそのまま貼ってください。 「なんとかエラーが出ます」という説明は、原文の一行より必ず情報が少なくなります。

% \listfiles before \documentclass, then look at the end of the .log:
 *File List*
 article.cls    2023/05/17 v1.4n Standard LaTeX document class
  size10.clo    2023/05/17 v1.4n Standard LaTeX file (size option)
booktabs.sty    2020/01/12 v1.61803398 Publication quality tables
 ***********

Stack Exchange 以外の窓口——TUG、各国のユーザ会、issue tracker

TUG（TeX Users Group） は 1980 年に発足した国際的な非営利の会員組織で、TeX Live を含む開発を支え、機関誌 TUGboat を発行し、年次会議を開いています。TUGboat が単なる読み物ではないことは手元で確かめられます——投稿用のクラスファイル ltugboat.cls が TeX Live に同梱されていて（著作権表示は「Copyright 1994-2023 TeX Users Group」、保守者は TUG そのもの）、texdoc tugboat と打てば投稿者向けの手引き ltubguid.pdf が開きます。つまり、TeX の使い方を書いて発表したくなったら、その組版の道具はもう入っているわけです。

TeX の世界は国ごとのユーザ会でも支えられています。TeX Live の公式ガイドは謝辞で TUG、ドイツ語圏の DANTE e.V.、オランダの NTG、ポーランドの GUST に技術と運営の基盤を提供してもらったと書き、「近くのユーザ会に入ってください」と添えて tug.org/usergroups.html を案内しています。スペイン語圏の CervanTeX も TeX Live に FAQ を寄せており、tlmgr info es-tex-faq で確認できます。日本語圏では 日本語 TeX 開発コミュニティ（texjporg） が pLaTeX／upLaTeX、jsclasses（元は奥村晴彦氏）、dvipdfmx の日本語対応、gentombow、ptex2pdf などを保守し、TeX Wiki（texwiki.texjp.org）を運営しています。日本語の質問なら 奥村先生の TeX フォーラム（okumuralab.org/tex/）が事実上の窓口です。ほかに latex.org フォーラム、メーリングリストの [email protected]、Reddit の r/LaTeX があります。

それが質問ではなくバグだと確信できたら、行き先が変わります。パッケージ固有の不具合は作者の issue tracker へ——住所は探さなくても手元にあります。tlmgr info <パッケージ名> の出力に cat-contact-bugs や cat-contact-repository の行があれば、それが公式の報告先です（たとえば tlmgr info mwe は GitHub の issue ページを返します）。一方、LaTeX 本体（カーネル）の不具合は LaTeX Project（latex-project.org）へ送りますが、その際は latexbug パッケージを使います。これはバグの切り分けを助けるためのもので、LaTeX チームは、バグ報告に添えるテストファイルにこれを読み込むよう求めています。読み込むと、そのバグが本当にカーネルのものか、それとも第三者パッケージのものかを判定してくれます。宛先を間違えた報告は、どこにも届かないのと同じです。

答えが返ってくる質問の書き方

必要なのは四つだけです——短い症状の説明、MWE、エラーの原文、試したこと。 Talbot は先の小冊子で、症状の説明は簡潔にし、原因を追うために何を試したかを並べ、プロジェクト全体の長い説明には入り込まないよう勧めています。情報が多すぎると読む気を削ぐからです。そしてもう一つ、忘れられがちな前提を明記しています——誰も報酬を受け取っておらず、答える義務も負っていない、だから要求や非難のように聞こえる書き方は避けること。この助言が 2014 年の文書に書かれ、いまも同じ形で TeX Live に同梱されている事実そのものが、コミュニティの気風を語っています。付け加えるなら「やりたいこと」を書くのを忘れないでください。うまくいかない方法だけを説明されると、回答者はもっと簡単な別解を提案できません。