\bfや\it等のサポート

[yuw]

\DeclareOldFontCommandで定義されている次の九つは削除してよいのではと思います．

• \mc
• \gt
• \rm
• \sf
• \tt
• \bf
• \it
• \sl
• \sc

これらは長いこと非推奨とされてきましたが，未だに使われています．その理由の一端に，使えてしまっているからということがあるかと思います． 影響はそれなりにあるかもしれませんが，舵をきってもよいかと思います．

[okumuralab]

さすがにそれは鬼

[zr-tex8r]

「二文字フォント命令」を使うのをチョットは躊躇させるようなナニカは欲しいですね……。 例えば：

• 警告を出す
• 特定のオプションを付けないと使えない
• etc.

[zr-tex8r]

（余談）

BXJS クラスを最初に設計しているときに、「二文字コマンド」の廃止は検討したことがある。そのときは 「二文字コマンド」を使用した（古い）文献スタイル（.bst）を使用しているユーザが困ってしまう という懸念があって断念した。

※「二文字コマンド」は“クラスによっては定義されない”ものであるため、 “LaTeX2e用の”パッケージや文献スタイルがこれに依存することはあり得ない。 しかし自分の認識では、文献スタイルは“思い切り古い”ものが使い続けられている、 と思っている。

[abenori]

（スタイルではなくてデータベースの方ですが）MathSciNetからとれるBibTeX用のデータでは\rmとかたまにみる気がします．

[okumuralab]

元のLaTeX2e classesでも\bf等を捨てられていません。 もし消すのなら，新しい名前で出せばいいので，従来のものが突然動かなくなることは絶対に避けるべきです。

[kmaed]

最近，TeX Live の ML でもそんな話が流れていましたね．

[tex-live] Class scrartcl Error: undefined old font command '\it' and '\rm'

KOMA-Script で二文字フォント命令が使えないという話です．実際，

\documentclass{scrartcl}
\begin{document}
\bf a
\end{document}

を試すと，

! Class scrartcl Error: undefined old font command `\bf'.

See the scrartcl class documentation for explanation.
Type  H <return>  for immediate help.
 ...

l.3 \bf
      a
? H
You should note that since 1994 LaTeX2e provides a new font selection scheme
called NFSS2 with several new, combinable font commands. New KOMA-Script
classes have defined the old font commands like `\bf' only for compatibility
with old LaTeX 2.09 document styles of Script 2.0. Nevertheless, these
commands are deprecated and undocumented at least since 2003. Since 2013
KOMA-Script classes warn abouts soon removement of these deprecated commands.
Now, after two decades of LaTeX2e and NFSS2, these commands will not work any
more. If loading a package results in this error message, you should contact
the author of that package and ask him to replace the deprecated font command
`\bf', e.g., by `\normalfont \bfseries `. Otherwise you should reconfigure
or replace the package. If you have used the old font command `\bf' yourself,
you should replace it, e.g., by `\normalfont \bfseries '.
To make it work for now, you can use the already also deprecated class option
`enabledeprecatedfontcommands'.

と出ます．そこで，

\documentclass[enabledeprecatedfontcommands]{scrartcl}
\begin{document}
\bf a
\end{document}

とすると，通りますが Warning が出ます：

Class scrartcl Warning: deprecated old font command `\bf' used.
(scrartcl)              You should note, that since 1994 LaTeX2e provides a
(scrartcl)              new font selection scheme called NFSS2 with several
(scrartcl)              new, combinable font commands. New KOMA-Script classes
(scrartcl)              have defined the old font commands like `\bf' only for
(scrartcl)              compatibility with LaTeX 2.09 document styles of
(scrartcl)              Script 2.0. These commands are deprecated and
(scrartcl)              undocumented at least since 2003. Since 2013,
(scrartcl)              KOMA-Script classes warn about soon removement of
(scrartcl)              these deprecated commands. Now, after two decades of
(scrartcl)              LaTeX2e, NFSS2, and KOMA-Script these commands will
(scrartcl)              not work any longer. If loading a package results in
(scrartcl)              this message you should contact the author of that
(scrartcl)              package and ask him to replace the depracted font
(scrartcl)              command `\bf', e.g., by `\normalfont \bfseries '.
(scrartcl)              Otherwise you should reconfigure or replace the
(scrartcl)              package. If you have used the old font command
(scrartcl)              `\bf' yourself you should replace it, e.g., by
(scrartcl)              `\normalfont \bfseries ' on input line 3.

参考までに．

[h-kitagawa]

ちょうど同じことを考えていて，h-kitagawa/jsclasses の warn_209cmd ブランチを作ったところです．

（言葉が足りなかったので追記）エラーにはせずに，

Class jsbook Warning: deprecated old font command `\sf' used.
(jsbook)              You should note, that since 1994 LaTeX2e provides a
(jsbook)              new font selection scheme called NFSS2 with several
(jsbook)              new, combinable font commands. This jsbook class
(jsbook)              has defined the old font commands like `\sf'
(jsbook)              only for compatibility on input line 3.

と警告を出すようにしています．

[okumuralab]

しがらみがないものはいいですね。

[yuw]

特定のオプションを付けないと使えない

というのであれば個人的にですが許容できます．

19 の議論で\if@compatibilityを完全に排除することに合意できた場合，2.09の記法とは完全に決別するわけですが，\bf等の記法は事実上2.09式の記述ですので，無条件で使え続けらる場合はダブルスタンダードになるおそれがあると考えています．

[okumuralab]

特定のオプションをつけないと使えないでは，今まで動くコードが動かなくなります。 そういう場合は，名前を変えたクラスファイルを作るべきです（きっぱり）。

[okumuralab]

というわけで，理想を追求するjcclasses（Japanese Community/Clean Classes，仮称）を，互換性を重んじるjsclassesからフォークするというのはどうでしょうか？

[aminophen]

jsclasses からいま新しいのをフォークしたところで、使う人はいないと思うのでやるきがおきないです。作っても使われなければ意味ないので。

いま jsclasses が批判を受けながらもスタンダードたる所以のひとつは、奥村氏のクラスだという点が大きいと思います。いまのモチベーション（互換モード撤去＝エラーが増えるだけ）で新しいクラスを作った場合、どちらのクラスを使おうか選ぶ人にとっては「どうみても面倒なことが増えるだけ」にしかみえず、誰も選ばないでしょう。「正しい書き方とはこういうものだ」という教育を受けたい物好きにしか選ばれないようだと、結局何の解決にもなりません。仮にフォークを提案するならもっと前向きなモチベーションが欲しいです。（ここで私はフォークに賛成とは一言も言っていないことに注意。）

「前に作ったものがエラーになる」は、#11 の「どのエンジンでもコンパイルが通るけれどある一つだけが正しい」にも通ずるものを感じます。仮にエラーを採用した場合でも、古いソースは古い TeX 環境でコンパイルすれば済む話です。それができるように、古い TeX のインストール法なりエミュレート法なりを提供または解説するのが筋ではないかと思います。警告ならまだマシでしょう。

[okumuralab]

いやそうじゃなく連中は\documentclassを使って\includegraphicsもちゃんと使っていて，その上で\bfを使っているんです（慣れてるし，短いし）。そういうコードがいっぱい動いているのが現状です。

[aminophen]

慣れてるし、短いし、な人が出てくるのは、20 年も前に deprecated になったにもかかわらず今の今までエラーも警告も出さなかったから、だと思います。どこかで舵をきらないといつまでもそういう連中が後を絶たないので、いまの issue になっていると推測します。

最新の pLaTeX は「起動時に platex.cfg を読み込む」という機能を持っているので、これにゴニョゴニョ書けば 2.09 コマンドが通る、というのが可能だと思います。

[okumuralab]

ごにょごにょ書けば古いコードも使えるようになる，でなくて，そのまま動く，というのが互換性の維持です。 本家のLaTeX2e classesで\bf等を許している間は日本語でも許さざるをえません。

[aminophen]

本家の LaTeX2e classes に対応するのは、pLaTeX2e の jclasses です。仮にそちらを凍結しても、jsclasses は別問題だと思います。（きえださんが pLaTeX にではなく jsclasses に issue を出しているのは、そこがポイントなんじゃないかと勝手に推測）

[okumuralab]

すでに動いているのだから，動かなくするのはダメです（キッパリ）。

[aminophen]

北川さんが検討されているような Warning なら「動く」からいいんですか？

[kmaed]

LaTeX2e 標準の article クラスすら \bf に警告を出さない現状では，jsclasses だけが頑張ってもしょうがないだろう，というのは一理ある感じが私はします．

前に挙げた TeX Live の ML では，そもそも LaTeX2e kernel では \bf などは定義していないので deprecated でもなんでもない．各クラスファイルで定義しているだけなので除去するのは作者の自由なのだけれども，本当に除去するとはちょっと勇気ある選択だね，という感想が出てきます．ZRさんやあべのりさんも書かれている通り，現実問題として入力される可能性のあるあらゆるものから二文字フォントコマンドが消えない限り，使いづらいだけになってしまいます．

警告を出すだけにしても，なんだかんだで BibTeX だのなんだの使うと警告だらけになったりしませんかね．

[aminophen]

警告だらけになったりしませんかね．

「一回だけ警告を出す」が仮に実装できたとしてもダメですか？

[kmaed]

「一回だけ警告を出す」はたぶんできるのだろうとは思うのですが，一回だけとしても自分の書いたソースには二文字フォントコマンドがなくても警告が出たりするとちょっと気持ち悪そうです．何も試していないので，実際に導入したときに各々の利用者の環境でどうなるかは何も予測できない状態で書いています．

KOMA-Script の警告は「もしこのメッセージが出たら原因の作者に連絡しろ」と書いてあるので，えらく強気だなあ，と思います．これに従う人はどれぐらいいるのだろう．もちろん，パッケージ製作者は問題があれば連絡してほしいと思っているわけですが，現実は……．

[abenori]

すでに動いているのだから，動かなくするのはダメです（キッパリ）。

その通りだと思います．なので以下蛇足ですが……．フォーラムにも書いたようなことですが，よくわからないままLaTeXを使っているけど，無いと死ぬ，という人は割といると思います．そういう人にとって「挙動が変わってしまう」というのは結構辛いものがあると思います．特に何かの締め切り直前にぶち当たったりすると……．というわけでそういう人がたくさんいることもご理解いただけるとありがたいかと……．

大事なのは出力結果なので，警告がでるのはそこまでまずくないとは思います．やはり大変困るのはコンパイルが通らないとか，明らかに出力がおかしい（何か文字が出ない）とかでしょうか．出力自身が微妙に変わってしまうのもまずいケースもありそうですが，「とりあえず何か出す」だけのことが多いので，やばさとしては少し小さいかと．

とはいえ，警告が出るとなると個人的には

一回だけとしても自分の書いたソースには二文字フォントコマンドがなくても警告が出たりするとちょっと気持ち悪そうです

ですが……．（と北川君のを何も見ていないのですが．）

[aminophen]

一回だけとしても自分の書いたソースには二文字フォントコマンドがなくても警告が出たりするとちょっと気持ち悪そうです

具体的な例が出ないとどうも掴めなそうなので、とりあえず：

texlive 2016 の texmf-dist/bibtex/bst 以下で、「二文字コマンド \bf が登場する .bst」が含まれるディレクトリの一覧（ファイル名にすると「あー」と見覚えのあるのが私もいくつかありました）：

./beebe/
./besjournals/
./chem-journal/
./computational-complexity/
./ieeepes/
./kluwer/
./nar/
./pnas2009/
./seuthesis/
./spie/
./texsis/
./tugboat/
./uestcthesis/

[kmaed]

KOMA-Script の警告に従うと，これらは全て改訂すべきなのかな．

ltugbib.bst なんかは更新日が2010年になっているわけですが，未だに \bf が残っているとは……．

[aminophen]

まあ「bst 対策」だけなら、ちょっと汚いですが thebibliography 環境の中だけフックする、という手がなきにしもあらずだと思います。一般のパッケージが使っている例こそが、真に不愉快な「自分は 2.09 命令使っていないのに警告される例」をつくりうると思います。

[kmaed]

一般のパッケージが使っている例

そう書かれると探してしまうのですが……．

xymtex/chemist/chemist.sty

が引っかかりました．LaTeX 2.09 対応なのでしょうか．

[aminophen]

で、ちなみに \bf を使っている有名（？）なパッケージとしては、fancyvrb や fancybox が引っかかりました。ほかにもイロイロあることはわかったので、こういう場合をどうとらえるか、でしょう。

というわけで、いちばん簡単な例を挙げておきます。h-kitagawa/warn_209cmd ブランチの jsarticle.cls を使うと警告が出てくることを確認済み（この場合だと 2 回出る）。

\documentclass{jsarticle}
\usepackage{fancybox}
\begin{document}
\begin{Bdescription}
\item[ゆきだるま] かわいい。
\item[\TeX] アレ。
\end{Bdescription}
\end{document}

というわけで、「エラーを出す」はやりすぎということで同意します。警告を出すかどうか、については、まだ私は意見保留としておきます。

追記：kmaed さんの chemist.sty は 2010 年出版の作者の著書「LaTeX2e 論文作法」（ピアソン）にも登場するので、どう考えても 2e で使うことを想定しているパッケージです。

[kmaed]

fancyvrb や fancybox

ありがとうございます．grep のやり方が下手で関係ないのがたくさん出てきたので，一番最後の結果に注目してしまいました．失礼いたしました．

[tattsan]

そんなにムキになって purge しなくてはいけない事柄なんでしょうか。 放置すると困る事って、何がありますか?

[aminophen]

放置すると困る事

私がこの issue にコメントしたのは ”なんかやけに参加人数が多い＝関心事らしい” からでした。さしあたり私が困っているわけではないですが、いつかほんとうに \bf とかが使えなくなったとき（「LuaTeX 専用クラス」とかだと今後起きても私は驚きません）に大問題が起きないように、なるべく早くというのは一理あるのではないでしょうか。ZR さんの言葉を借りれば

「二文字フォント命令」を使うのをチョットは躊躇させるようなナニカは欲しいですね……。

というようなことができれば、と漠然と思っていました。私の中でずっと疑問に思ってきた分が一気に噴出した分が見苦しかったのは謝ります。

[kuroky49]

@abenori さんが述べていますが，BibTeX の bst に文字数制限があって，短い記法を使っているような例があるはずです（\bf とか普通に吐きます．\it でなくて \em にしてくれたりはしていますが）．なので，警告ならまだしも，エラーにされるのは困ります．

[aminophen]

aminophen/warn_209cmd ブランチで北川さんの warn_209cmd をフォークして

• 警告は最初の一回だけ
• thebibliography 環境の中は例外扱いして警告を出さない

としてみました。これで「bst に \bf が使われていようが警告は出ない」になったはずですが、相変わらず先に挙げた fancybox.sty の Bdescription 環境などでは警告が一回だけ出ます。この「一回きり」がどのくらい不愉快か、という問題にまで落とせたと思います。 ← 追記：ここでいう「不愉快」は、「自分は一度も \bf など書いていないのに、使っている sty や bst のせいで警告がでる」というケースを想定しているつもり。

追記：natbib.sty などは \renewenvironment{thebibliography} するので、上記の「例外扱い」を jsclasses に入れたところで結局ムダになる（やはり bst の \bf 由来の警告が一回だけ出る）ケースが存在することも、加味する必要があるかもしれない。

[yuw]

議論が進んでしまっていて何ですが，\bf等を気にせず使い続けている方々はおそらく警告は無視すると思いますので，毎回であろうが一回であろうが回数による不快感は気にしなくてもよいでしょう．

（クラスファイル側で何もしないよりは使用の抑制にむかって前進したと思います．）

[aminophen]

膠着してしまったので書きます。

この issue の本質は「\bf をエラーにして動かなくなる方向に進みたい」のではなく、「\bf の使用を抑制する方向に進みたい」だと思います。動かなくするのはダメです、はよくわかりました。でも編集者側の実務の立場として「\bf があると編集の手間がかかる」という不満があって、それが具体的な提案として「エラーにしてはどうか」という形になってでてきたのでしょう。ほかでもなく「js クラスに対して」issue が立っているという意味をもう少し考えてみたいと思っています。

「要望が来ない」からといって「要望が無い」とは限りません。「スタートボタンをなくせという要望がないのに」はその通りだと思いますが、この issue は「無い要望を勝手に作っている」のではなく現場の悲鳴そのものでしょう。#11 の「理解不能なエラーの改善」も、要望が来たことはありませんがそれは「なんだこのエラーは」で終わってしまっているからでしょう。その不満を的確に拾った素晴らしい要求だと私は思います。

というわけで、#16 や #21 のプルリクのマージをお願いできませんか？

[okumuralab]

すみません，#21はマージできたのですが，#16はconflictが起こってしまったようです。どなたかgitに詳しい方，マージお願いします。

[okumuralab]

\bfなどの件はひとまず置いておいて，残りの便利な改善をとりあえずCTANに入れて，十分テストしてもらった上で，3年間固定する美文書バージョンとして秋に焼くのでどうでしょうか。

[aminophen]

16 を merge しました。conflict の原因は \CheckSum だけでした。

[aminophen]

「\bf をエラーにして動かなくする」ことが主目的でないことをまだ理解していない方がいらっしゃるのは残念ですね。議論が平行線になるのは何の得もしないので、早く決めた方がよいと思います。

「\bf などの使用で職業編集者・組版者が困っている」ことへの対処として「jsclasses は今のまま（警告なし）、新しく作る pLaTeX 用クラスでは警告を出す」が有効なのであれば、もうフォークした方がよいのでしょう。有効でないのであれば、新しく作る意味はないのでしょうから、フォーク以外の手段をとるべき（あるいは困っているという意見は一切無視して現状維持？）でしょう。

• https://twitter.com/munepixyz/status/754563506364559360
• https://twitter.com/p_typo/status/754457758007566336

どう思われますか？

[kmaed]

既に似たようなことを書いたのですが，jsclasses だけが \bf などに警告を出したとして，入稿される原稿に \bf などが使われてしまう問題がどれぐらい解決するのでしょうかね．入稿原稿のほとんどが jsclasses で書かれているならば多少は意味があると思いますが，もし jclasses とか LaTeX2e classes とか amscls なんかで入稿されるものも多いならば効果は限定的ですよね．あと，きえださんも書かれている通り，警告止まりだと結局 \bf を使う人は気にせず使い続けるんでしょうね．

Perl や JavaScript だと use strict というのがありますが，似たようなパッケージを作って入稿原稿にはこれを読み込むことを義務づける，みたいなことはできないのかな．できたとしても，クライアントにそういう要求を出すのは難しいでしょうか．

[okumuralab]

\usepackage{lint} とかすれば，欄外に赤で「ここは \bf でなく何々と書いてください」のような注意が入るパッケージはどうですか？

[kmaed]

文法チェッカ的なものとしては，プログラムですが lacheck とか chktex というのが TeX Live にはついているようです．例えば lacheck で \bf{a} が含まれるファイルを入力すると

"test.tex", line 4: Fontspecifiers don't take arguments. "
\bf"

というのが検出されます．\bf だけで引数をとらないと特に警告が出ないので，どれぐらい役立つのかは不明です．

[okumuralab]

ですね。それに多分コマンドラインからlacheckを実行する方法がわからない人が大多数でしょうから，パッケージ（*.sty）にして，弊社に入稿する場合はこれを付けてくれとする。

[yuw]

入稿原稿のほとんどが jsclasses で書かれているならば

和文に関してはほとんどがjsclassesかそれを元に版面等をカスタマイズしたもので入稿される現状があります．もちろん私の観測範囲に限ったことですが．

jsclassesが“標準”とみなされている雰囲気がありますので，そこで警告を出すのは一定のアピールになると思います．

入稿原稿にはこれを読み込むことを義務づける，みたいなことはできないのかな．できたとしても，クライアントにそういう要求を出すのは難しいでしょうか．

ほとんど不可能だと思います．しかし一方でパッケージ読み込みの推奨はできると思います．

ところで警告を出す方向で収束しつつあるという認識でよいでしょうか．私はそれに反対するつもりはありません．

[aminophen]

みなさま、ありがとうございます。

私が「jsclasses が何かしら対処する」ことに意味があると思ったのは、「新しく学び始める人に \bf を使わない習慣を自然に身につけてもらう程度の効果は期待できそうだ」だからです。実際に入稿されるものにも jsclasses かその派生物が多いというきえださんの見解も大変参考になります。「js だけ頑張っても意味がない」には、やっぱり個人的には同意しかねます。

「パッケージ作成」という案が出たことはすごくいいです。パッケージ自体がどれくらい効果のあるものに実装できるかと、その利用推奨とやらをどうやってアナウンスするか、は課題でしょう。

「警告」に関しては、北川さんが実装してくださったもの＋私のパッチ入りが h-kitagawa/warn_209cmd ブランチにあるのですが、これはどのくらい見ていただけたのでしょうか？

[okumuralab]

せっかくですが，jsclassesでは将来にわたって\bfなどをサポートするという意思表示の意味も込めて，警告もやめましょう。

[aminophen]

jsclassesでは将来にわたって\bfなどをサポートするという意思表示の意味も込めて

現状維持する（警告も出さない）こととその理由づけがようやく一貫して明言された印象を受けました（「迷惑だからダメです」という主観的・恣意的な主張ではなくなったことが大きな要因）。クラスファイルの実装は意思表示そのものだと私は思いますので、「警告もやめる」という案について納得しました。ほかの方々はどのようにお考えでしょうか。

合意に達する場合、「パッケージ実装」について具体化する方向で進めるため、texjporg に新たなリポジトリを作って議論を始めましょう。名前は何がいいですか？パッケージ名は lint.sty という名前で、texjporg/lint でよいのでしょうか。（lint というリポジトリ名はなんだか判りにくそう＆混同されそうな予感がするけれど、理由は不明）

kmaed さんが例示されたスクリプトについては TeX.SX のココを参考なさったのかな。

• http://tex.stackexchange.com/questions/163/is-there-a-program-equivalent-to-lint-for-latex

[e-kwsm]

盛り上がっているところ申し訳ありません．

個人的には何十年も非推奨のものを使い続けている人のために互換性を維持する必要はないと思います． 2007年に出た l2tabu にも「\bf　(や \eqnarray) は使うな」と書いてあります． 古い情報がいくらでもある中，そもそもそういう非推奨のものをどれだけの人が把握しているかという話ですが．

非推奨を検出するのには nag というパッケージが既にあります． 例えば \bf の場合以下のように "Warning" を出します．

Package nag Warning: Command \bf is an old LaTeX 2.09 command.
(nag)                Use \bfseries or \textbf instead on input line 4.

私は必要がないので使っていませんが．

デフォルトで警告を出すのすらダメなのであれば，nag を読み込む (あるいは警告でなくエラーを出す) オプション (例えば checkcanonical) を追加するのはどうでしょうか．

[kmaed]

きえださん，ありがとうございます．jclasses や（そもそも和文用でない）classes などでの入稿も多いのではという勝手なイメージがあったのですが，jsclasses がかなり普及しているのですね．

アセトアミノフェンさん，

私が「jsclasses が何かしら対処する」ことに意味があると思ったのは、「新しく学び始める人に \bf を使わない習慣を自然に身につけてもらう程度の効果は期待できそうだ」だからです。

この観点が抜けていました．確かに日本国内だけでもそういう効果は期待できそうですね．

（TeX.SX についてはその通りです．で，下に続く．）

かわしまさん，実は既にそういうパッケージがあるのではないかと思って探していたのですが，辿り着けていませんでした．情報提供ありがとうございます．昔バズった「使ってはいけない……」にもよく見たら書いてありましたね．

個人的には何十年も非推奨のものを使い続けている人のために互換性を維持する必要はないと思います．

私も新たに書くものについてはそう思いますが，奥村先生が懸念されているのは過去に書かれたものの再利用に関してだと思われます．警告・エラーを出すにしてもオプションで無効化できれば過去のものについても問題ないのではというのが私の感覚ですが，現実にはそれですら対処できずに騒ぐ人もいるのでしょう（世の中，色々な人がいます）．あとは，上で出てきた BibTeX や他のパッケージに埋め込まれている \bf に関する問題がありますが，これは瑣末なことかもしれません．

さて，結局どうするのがよいのでしょうか．私としては，作者が「警告も出してはならない」という明確な意思表示をされていますので，それに従うべきかと考えます．ちなみに，かわしまさんが書かれているようにオプションで警告・エラーを出すのもだめということでしょうか．また，nag で不十分なようでしたらどんな仕様のパッケージが必要でしょうか（日本語でメッセージを出す，PDF 内で赤字で出力をする，etc.）．

de-macro の情報も拾ったりしたので，「入稿時に読むべきページ」のようなものがどこかにあるといいかもしれないです．

[aminophen]

私の主張が180度変わったかのように見られてしまったので弁明しますと、原作者が『jsclassesでは将来にわたって〜警告もやめましょう』と初めて（意思と手段を揃った形で）明確に表明されたことは尊重しようというのが私の立場です。ちょうど前田さんの

作者が「警告も出してはならない」という明確な意思表示をされていますので，それに従うべきかと考えます．

に近いです。「将来にわたって\bfなどをサポートする」という判断が正しいか否か、また「原作者の意思に従う」のが正しいか否かはわかりません。そもそも正解なんてないのでしょう。

---

さて、かわしまさんが教えてくださるまで nag というパッケージを完全に忘れていました。中身を改めて見ましたが、前提として「l2tabu の内容が妥当なのか」が要検討です。\bf とかだけでなくほかの obsolete なパッケージも挙げていますが、信じていいのでしょうか。

nag には警告かエラーかを選べる機能があるようです。警告だけだと \bf を平気で使う人に効果がないでしょうし、エラーはチェック導入の推進にとって逆効果でしょうから、PDF 内で赤字で知らせる等の機能が欲しいですね。…と考えていると、クラスファイルの draft オプションの Overfull 警告なんかと連動させてもよいのでは思いついてしまって

オプションで警告・エラーを出すのもだめということでしょうか．

この前田さんの質問を、奥村先生宛に私からもさせてください。

[e-kwsm]

弁明しておくと nag である必要はなく，「nag ライクに \bf 等の使用に警告/エラーを出す，あるいは PDF に赤字で注釈を付けるオプション (ないしパッケージ)」であれば構いません． 面倒かもしれませんが checkcanonical = warning | error | markpdf のようにユーザがレベルを選べるように実装するのもいいでしょう．

前提として「l2tabu の内容が妥当なのか」が要検討です。

l2tabu 全てを網羅するか \DeclareOldFontCommand のみに対処する (追記: h-kitagawa/jsclasses:warn_209cmd や aminophen/jsclasses:warn_209cmd のように) かはお任せします．

ただ，この issue の採否とは別に非推奨コマンド・パッケージについて周知する必要はあると思います (仮に採択されても　\bf ユーザが使用しなければ意味がありません)．