LaTeX Newsを斜め読みしていきます。完全な翻訳を目指す類のものではなく、私が興味を持った項目だけを、ざっくり説明しようと思います。網羅性と正確性には期待しないでください。
最近はAIツールを援用することで、単純な翻訳作業については作業効率がかなり上がっているので——もちろん、技術的・文化的な背景を見落とした誤訳・微妙な訳が出力されることはあるので、ヒューマンチェックは重要ですが——網羅性については、「斜め読み」シリーズを始めた頃よりも顕著に上がってきています。もっとも、LaTeX Newsの後半部はしばしばLaTeX本体ではなく、LaTeXチームが管理するパッケージに関する変更内容が列挙され、こうしたパッケージ(多くが和文組版を考慮していない)は私を含め日本語TeXユーザの関心は低い傾向にあるため、依然として意図的に除外している場合があります。
また、正確性に関しても、LaTeX News本文を逐語訳するよりも訳者の独自解釈や補足を含めていることが少なくありません。訳者の補足に関しては、可能な限り「ブログ記事の脚注はいずれも訳注」「LaTeX News原文の脚注は必要なものは本文に展開、そうでなければ除外」「本文中に訳者が補足したい場合は飾り枠もしくは〔甲カッコ〕で導入」などの区別を行うようにしていますが、あまりにプレゼンテーションが煩雑化するのを避けるため、形式上は曖昧に混ぜてしまう場合もあります。例えば訳者が補足したコード例は本文にそのまま含めてしまっています。内容を見れば一目瞭然だとは思いますが。
いずれにせよ、本家LaTeX Newsの内容を完全に把握したい方は、少なくとも原文を合わせて確認することを想定しており、この「斜め読み」シリーズは一種のコンメンタールとして機能することを意図しています。
それでは今回はLaTeX News Issue 42, November 2025 (LaTeX release 2025-11-01)を“斜め”の角度から読んでいきます。
イントロダクション
ダグラス・アダムズのファンなら、今回のLaTeX Newsが特別な号であると気付くだろう1。残念ながら今回はまだ「生命、宇宙、そして万物の究極の問いの答え」を示すには至っていない——そこに到達するまでには、もう少し取り組むべき課題が残っている。
しかし、このリリースでは、LaTeXからタグ付きでアクセシブルなPDFドキュメントを生成するための取り組みがさらに進展した。この進歩を示すために、もはやこれを「プロトタイプ的な解決策」と呼ぶ段階を過ぎ、すでに実運用のワークフローで使用可能なレベルに達したといえる(対応済みパッケージに制限されるが)。これは、タグ付け機能を含むlatex-labのコード開発が完了したことを意味するわけではない。しかし、ユーザが直接利用する側の部分は、すでにかなり安定し、実用に耐える段階にある。
タグ付けプロジェクト以外にも、フォント選択機能の拡張、新たなコード改善、そして複数箇所への機能追加が行われた。たとえば、テンプレートインスタンスなどを指定する際に便利な「キー値の宣言時における値の展開」がサポートされている。
例によって、いくつかのバグ修正も行われた(今回はとりわけ奇妙なものも含まれていた)。さらに、この機会にtoolsコレクション2に含まれていたいくつかのパッケージを正式に引退させることにした。より優れた代替手段がすでに存在するため、これらのパッケージは新しい文書では使用しないことを推奨する。
今回から実運用段階に入ったとされるタグ付けPDF機能について、その使用法の要点を伝えるクイックガイドも用意されている。「まずはとりあえず使ってみたい」という方はこのガイドから始めるとよいだろう。
https://latex3.github.io/tagging-project/documentation/usage-instructions
タグ付きPDFプロジェクトからのニュース
\DocumentMetadataコマンドの拡張
2022年に導入された\DocumentMetadataには、2つの効用があった。一つは、文書全体に関わる設定やメタデータを記述する専用の場所を提供する〈宣言コマンド〉としての効用、もう一つは、LaTeXの新しいコードを読み込むか否かを指定する〈ローダーコマンド〉としての効用である。この後者の役割により、タグ付けプロジェクトに不可欠な新しい拡張インターフェースを使用できるようになるが、このことは仮にタグ付けを行わない場合にも有用である。
当初、引数を空にした\DocumentMetadataの使用は、PDF管理に関わるコードのみを読み込み、新しいhyperrefドライバを利用するものだった。2024年11月以降は、このコマンドを使用した場合のデフォルトのエンコーディングがOT1からT1に変更され、さらに2025年6月以降は、デフォルトのPDFバージョンも1.7から2.0に変更されている。
タグ付けプロジェクトなどで必要となる追加コード(latex-labから提供されるもの)は、これまでtestphaseまたは最近導入されたtaggingキーを\DocumentMetadataの引数に指定して明示的に読み込む必要があった。この仕組みは、新しいコードの選択的な読み込みやテストには便利だったが、クラスやパッケージがタグ付けプロジェクト対応のためにコードを調整する際に、どの部分のlatex-labコードが有効になっているかを判断しづらいという問題も生じていた。
このリリースでは、\DocumentMetadataをさらに拡張し、tagging=offやtestphase=latestキーを使用した場合と同じコードを自動的に直接読み込むようにした。
これにより、testphaseキーの値phase-I、phase-II、phase-IIIは、もはや異なるコードバリエーションを読み込むのではなく、タグ付け機能の有効化のみを行うようになる。まだlatestモジュール群に統合されていない追加モジュールを読み込みたい場合は、引き続きtestphaseキーを利用できる。
PDF管理に関わるコードのみを読み込み、タグ付けをサポートするコードを不要とする文書向けには、専用のパッケージが新たに提供されている。
これまで
\DocumentMetadata{pdfversion=1.7, pdfstandard=a-3b}
と記述していた文書は、今後は以下のように書き換える必要がある。
\RequirePackage{pdfmanagement}
\SetKeys[document/metadata]{pdfversion=1.7, pdfstandard=a-3b}
タグ付けサポートコードとの互換性確認
さまざまな文書クラスやパッケージがタグ付けサポートとどの程度互換性を持つかを示すデータベースが作成されており、オンラインで閲覧可能である。今回のリリースでは、その一部を抽出して小規模なパッケージlatex-tagging-statusにまとめ、さらに\DocumentMetadataにcheck-tagging-statusというキーを追加した。このキーを利用すると、使用中のパッケージおよび文書クラスの互換性ステータスがログファイルの末尾に表示される。
このステータスはあくまで簡易的なものであり、最終的な互換性を報告するためではなく、デバッグを補助するためのものである。「非互換(incompatible)」あるいは「部分的に非互換(partially incompatible)」と分類されているパッケージを使用しても、必ずしもタグ付けが壊れるわけではない。たとえばhyperrefは部分的に非互換とされているが、これはフォームフィールドが正しくタグ付けされない(この問題にはl3pdffieldパッケージの利用が必要)ためであり、フォームフィールドを含まない文書では問題なく動作する。「部分的に非互換」または「非互換」なパッケージを使用する場合は、何が未対応なのかを説明していることが多いので、完全な互換性表を確認するべきである。
latex-tagging-statusパッケージは、パッケージ群や互換性データベースの更新を反映するために定期的にアップデートされる予定である。誤ったメッセージを見つけた場合は、タグ付けプロジェクトのGitHubリポジトリに報告して欲しい。また、データの更新や修正のためにプルリクエストを送ることも可能である。
タグ付けサポートコードの要求と判定
\DocumentMetadataによって読み込まれる新しいコード専用に設計されたクラスやパッケージでは、ファイルの冒頭で新コマンド\NeedsDocumentMetadataを使用できる。これにより、タグ付けサポートコードが読み込まれていない場合に適切なエラーメッセージを出力する。
一方、従来形式の文書と\DocumentMetadataを使用する新しい形式の文書の両方に対応したいクラスやパッケージでは、新しいコードが読み込まれているかどうかを判定するために\IfDocumentMetadataTFを利用できる。この判定は、場合によってはLaTeXフォーマットの日付テストと組み合わせて使うこともできる。また、PDF管理コードが読み込まれているかを確認するためのテストとして、\IfPDFManagementActiveTFが提供されている。
パラグラフタグ付けのソケット化
LaTeXではパラグラフを入れ子にすることができる。たとえば、引用環境を含むパラグラフがあり、その引用部分が複数の(サブ)パラグラフから構成されており、その後に同じ外側のパラグラフに属する本文が続くといった構造を持つことがある。
例:
日本語TeXコミュニティの一部においては、ゆきだるまは〈本質的な存在〉として扱われている。
%
\begin{quote}
ゆきだるまはかわいい。
ゆきだるまは素敵。
本質以外のコンテンツは不要!
\end{quote}
%
この一派の成果物としてSC-ripts\footnote{\url{https://github.com/zr-tex8r/SC-ripts}}や
SC-tools\footnote{\url{https://github.com/zr-tex8r/SC-tools}}が挙げられる。
このような「意味的パラグラフ(semantic paragraphs)」をモデル化するために、LaTeXはtext-unitという構造を用い、パラグラフテキストの一部または全体に対してのみtext(役割マッピングはP)を使用している。なお、text-unitという名称は暫定的で、将来的に変更される可能性がある。
この設計は意味的に明確であり、〔タグ付きPDFの〕処理者が完全なパラグラフを識別する際にはtext-unitタグを手がかりにできる。しかし、「意味的パラグラフ」のタグ付けを無効化するオプションを求める要望が寄せられたため、今回のリリースでは関連するタグ付けコードをソケットへ移動した3。これにより、以下のようにnoopプラグを割り当てることで「意味的パラグラフ」のタグ付けを無効化できるようになった。
\AssignTaggingSocketPlug{para/semantic/begin}{noop}
\AssignTaggingSocketPlug{para/semantic/end}{noop}
\includegraphicsキーのためのフック
\includegraphicsで使用されるキーalt、actualtext、artifactの3つの定義に、Gin/alt、Gin/actualtext、Gin/artifactという名前のフックが追加された(Ginはgraphicxパッケージにおけるkeyvalのファミリ名を指す)。
最初の2つのフックは2つの引数を取り、1つ目の引数にはPDF内でも使用される精製済みの値(\text_purify:nで処理された値4)、2つ目の引数には元の生の値が渡される。これらのフックは、タグ付けが有効化されていない場合でも処理される。
この仕組みにより、例えばaltテキストをコマンドに保存することが可能になる。
\AddToHookWithArguments{Gin/alt}{\gdef\myalttext{#2}}
\includegraphics[alt=Hello World]{example-image}
The alt text of the graphic was \myalttext.
シンボリック構造名
構造要素タグの名前は、Sect、H1、FigureのようなPDFの標準的な名前空間から取ることもできるが、こうした標準名に役割がマップされるかぎり、別の名前を使用することもできる。後者の方法には次の3つの利点がある。
- たとえば聖書のような文書では、
SectではなくTestament、Book、Chapterといった構造タグ名を使う方が見た目が自然である。 - スキーマ内でこうした構造に対して追加の制約を定義できるため、たとえば
Bookの中にTestamentが現れないよう保証できる。これはすべての構造にSectを使っている場合には不可能である。 - LaTeXとして統一的な構造タグ名集合を提供できる。
現在のところ、文書作成者が構造タグ名を変更するのは難しい。これは、タグ付けサポートコードがハードコードされた名前またはアドホックな内部変数を使用しているためである。そこで今回、新たに3つのコマンドを追加し、シンボリック構造名(symbolic structure name)5を宣言、使用、役割割り当てするためのインターフェースを提供した。
\NewStructureNameは引数を1つ取り、シンボリック構造名を宣言する。展開可能なコマンド\UseStructureNameも引数を1つ取り、\tagstructbeginコマンド内でその名前を使用できるようにする。\AssignStructureRoleは、シンボリック構造名に役割を割り当てるためのコマンドである。
今後数か月のうちに、タグ付けコード内のさまざまな構造タグ名はこのようなシンボリック構造名へ置き換えられていく予定である。この移行が完了すれば、文書やクラスの作成者は自分の文書に合わせて構造タグ名を柔軟に設定できるようになる。
ブロック環境のキー名の標準化
itemize、center、verbatimなどのディスプレイブロック環境は、少し前にすべてタグ付け対応として再実装された。このとき初めて、テンプレート/インスタンス機構を用いてレイアウト設定を一貫して行えるようにした(次は見出しコマンドがこの方式を採用する予定である)。この再設計の過程では、どの設定が最適かを見極めるためにさまざまな構成を試行した。しかしその副作用として、複数のテンプレート間でキー名がかなり不統一になってしまった。この試行錯誤が落ち着いたので、全体を見直して可能な限りキー名を標準化することにした。この作業はほぼ完了しているものの、他の領域をカバーするテンプレートの開発を進める中で若干の変更が続く可能性がある。
これらの変更は、単にタグ付きでアクセシブルな文書をそのまま生成したいだけのユーザにとっては基本的に透明である〔影響がない〕。しかし、\EditInstanceなどを用いて環境のレイアウトをカスタマイズしているユーザの場合は、キー名の変更に応じて設定を修正する必要がある。
組版におけるコンテキスト
文書の要素は、その使用箇所によってレイアウトを変える必要がある場合がある。たとえば、脚注やフロート内で使用されるリストは、通常よりも縦方向の余白を少なくした方がよいことがある。このような設計を一貫して簡潔に実現するために、「名前付きコンテキスト(named context)」という概念が導入された。文書を組版する際、LaTeXは現在の「プライマリコンテキスト」と「セカンダリコンテキスト」を追跡しており、これらは\footnoteなどのコマンドやフロートなどの環境を組版する際に自動的に切り替わる。
プライマリコンテキストについては、LaTeXは既定で本文組版(コンテキスト名は空)と、footnote、marginal、float、caption、header、footerを区別している。
セカンダリコンテキストは既定では異なる文字サイズの組版を識別するために用いられ、tiny、scriptsize、footnotesize、small、large、Large、LARGE、huge、Huge、および空(\normalsizeの組版を意味する)が認識されている。
理論上は、コマンドや環境が現在のコンテキストを参照して挙動を変えることも可能だが、それには比較的複雑なコードが必要となる。そこで主な用途は、レイアウトを定義するテンプレートインスタンスとの組み合わせに置かれている。\UseInstance{〈タイプ〉}{〈インスタンス名〉}が使用されると、通常は〈タイプ〉型の〈インスタンス名〉という名前のインスタンスが呼び出される(これらのインスタンスは\DeclareInstanceまたは\DeclareInstanceCopy宣言で定義される。詳しくはlttemplates-doc.pdfを参照)。
ただし、プライマリコンテキストやセカンダリコンテキストが空でない場合、\UseInstanceは現在のコンテキストに特化したインスタンスを検索する。この動作は次のようになる。
:〈プライマリコンテキスト〉:〈セカンダリコンテキスト〉という文字列が〈インスタンス名〉に付加され、その名前のインスタンスが存在すればそれが使用される(プライマリコンテキストが空の場合は実質的に::〈セカンダリコンテキスト〉が付加される)。- 存在しない場合は、
〈インスタンス名〉:〈プライマリコンテキスト〉が試される。 - それも存在しない場合は、通常どおり
〈インスタンス名〉が使用される。
これにより、特定の組版コンテキスト内でインスタンスの挙動を変更することが容易になった。たとえば、第1階層の箇条書きリストのインスタンス名がitemize-1である場合、脚注内専用のレイアウトを定義するためにitemize-1:footnoteという別のインスタンスを定義できる。詳細はlatex-lab-context.pdf、またはコマンドラインでtexdoc latex-lab-contextを実行することで確認できる。
現時点ではこの仕組みはまだ実験的な段階にあり、latex-lab内で実際に提供・使用しながら実験を重ねている。開発者が試用してフィードバックを寄せることも推奨されるが、実装の詳細は今後変更される可能性がある。
MathMLのintent属性
\MathMLintentと\MathMLargという2つの新しいコマンドが追加された。これらはフォーマット中では何もしない(no-op)として定義されており、パッケージ内のコマンド定義に自由に追加できるようになっている。luammlを有効にしてMathMLを生成する場合、これらのコマンドを使うことでMathMLのintent属性およびarg属性を指定できるようになる。
例えば、
\newcommand\abs[1]{%
\MathMLintent
{absolute-value($x)}%
{{\lvert\MathMLarg{x}{#1}\rvert}}%
}
という定義は、\abs{y}を使用した際に、次のようなMathML出力を生成する。
<mrow intent="absolute-value($x)">
<mo>|</mo><mi arg="x">y</mi><mo>|</mo>
</mrow>
これにより、読み上げ技術(Assistive Technology;AT)は曖昧な記号|y|を、選択された言語に応じて「yの絶対値」などの正しい読みとして認識できるようになる。
tabularセル内の数式のタグ付けを正しく処理
LuaTeXによるMathML自動生成が有効な場合、tabularセル内の数式内容が正しくタグ付けされないという問題があった。また、\verb=>{$}c<{$}=, \verb=>{\(}c<{\)}=のような前置・後置を含むtabular前文の記述も機能しなかった。これらの問題は修正された。
スクリプト用フォントに別ファミリを割り当てるためのサポート
TeXの数式処理では、テキストサイズ・スクリプトサイズ・スクリプトスクリプトサイズで別々のフォントを選択できる。一方、LaTeXのNFSSは伝統的に、サイズが違っても同じフォントファミリを用い、スクリプト位置6で見栄えが良くなるようにオプティカルサイズによって調整してきた。この方式は従来型のTeXフォントではうまく機能するが、OpenTypeフォントでは問題が生じる。OpenType数式フォントは、スクリプト位置のフォントに別の機能セットがあることを前提としており、そのため固有の調整が施されるからである。
これを、単なるフォントサイズに基づくヒューリスティックに依存せずに正しく扱うため、新しいコマンド\DeclareMathScriptfontMappingが追加された。このコマンドは3組のエンコーディング・ファミリのペアを取り、最初のペアが数式のメインフォントとして使われている場合に、2つ目と3つ目のペアをそれぞれスクリプト用フォントとスクリプトスクリプト用フォントとして使用すべきであることを指定する。
LaTeXのフォントメタファミリに関するプログラミングサポート
LaTeXには主に3つの文書用フォントファミリがある。文書のセリフ体フォントファミリに対応する\rmfamily、サンセリフ体フォントファミリに対応する\sffamily、等幅フォントファミリに対応する\ttfamilyである。これに加えて、ユーザや文書クラス、パッケージは\fontfamily{〈ファミリ名〉}\selectfontを用いて他のフォントファミリを明示的に読み込んで使用することもできる。
場合によっては、現在の組版でこれら3つのメタファミリのどれが使用されているかを取得できると有益である。この情報がプログラマ向けに\@currentmetafamilyとして提供されるようになった。この値はrm、sf、ttのいずれか、または(いずれのメタファミリにも属さない場合)??を返す。
この機能の小さな応用として、LaTeXカーネルには\@restoremetafamilyも追加された。現在のメタファミリが〈ファミリ名〉である場合、このコマンドは\〈ファミリ名〉family(例:\sffamily)を実行し、さらに再初期化処理のほかに〈ファミリ名〉familyという名前のフックを実行する。フックに条件付きコードが含まれており、その条件が変化したために再初期化が必要となる場面でこの仕組みが有用となる。
文書コマンドの引数指定子を復元する機能
LaTeX News 38では、\GetDocumentCommandArgSpecはデバッグ目的でしか必要とされないと判断し、この機能を削除したことを説明した。しかし、引数指定子へのアクセスが有用となる特殊な用途があることも事実である(例として、プルリクエスト #1799を参照7)。そのため、この件を再検討し、引数指定子へアクセスするためのコードレベルのインターフェースとして\cmd_arg_spec:Nを追加した。
ここでデザインレベル〔パスカルケースのコマンド〕ではなくコードレベルの名称〔expl3関数〕を採用しているのは、この機能がかなり特殊な用途向けであり、主にパッケージ作者にとってのみ関心がある性質のものだからである。
引数を取らないコマンドが\longにならないようにする
元々の実装では、\newcommandや\renewcommandは、コマンドが引数を持たない場合であっても常に\long\defによって定義していた。つまり、本来\longという概念がまったく意味を持たない状況でも、無条件に\longが付与されていたことになる8。
この挙動の問題点は、引数が存在しないため\longの意味が適用されないにもかかわらず、\longの有無だけが異なる2つのコマンドは\ifx比較において異なるものとして扱われるという点にある。たとえば、
\renewcommand\rmdefault{lmr}
\def\test{lmr}
と定義した場合、\ifx\test\rmdefault は偽となる。しかし、\rmdefaultが\defで定義されていた場合(多くの文書クラスが実際にこの方法を用いている)、比較は真になる。このため、本来シンプルであるはずの「引数を持たないコマンドの比較」が難しくなっていた。
そこで今回、\newcommandや関連コマンドの実装を変更し、引数を持たないコマンドは不要な\longを付けずに定義するようにした。
今後は、パッケージやカーネル側のコードにおいても、引数を取らないコマンドが\renewcommandで定義されたか\defで定義されたかに依存することなく、常に「非\longである」と仮定できるようになるため、コードの取り扱いが簡単になる。
わずかな可能性として、この変更が一部のパッケージの実装を破壊するケースがあるかもしれない(ただし現時点ではそのような事例は知られていない)。たとえば、もしコードが意図的に「\long\defであるかどうか」をテストしている場合、このテストは今後、非\longの定義に対して行うか、あるいは両方を許容するように見直す必要がある(過去のNFSS実装では実際に両方を許容していた)。
フォント置換に関する奇妙な警告を避ける
sbcのようなフォントシリーズ値には、太さ(sb=semibold)と幅(c=condensed)が両方含まれている。これらのうち片方だけを“medium”に戻し、もう片方はそのまま保持したい場合、\fontseries{m?}や\fontseries{?m}を使用できる。前者はsbcをcに、後者はsbcをsbに変える。
しかし、変換後のシリーズが存在しない場合、従来は次のような奇妙で分かりにくい警告が出ていた。
LaTeX Font Warning:
Font shape `OT1/cmss/c/n' undefined
using `OT1/cmss/m?/n' instead on input line 7.
LaTeX Font Warning:
Font shape `OT1/cmss/m?/n' undefined
using `OT1/cmss/m/n' instead on input line 7.
今回の改善によって、警告はより意味の明確な1つだけになった。
LaTeX Font Warning:
Font shape `OT1/cmss/c/n' undefined
using `OT1/cmss/m/n' instead on input line 7.
なお、mシリーズ自体が存在しない場合には依然として奇妙な警告が出るが、このような状況に該当するフォントはほとんど存在しない。また、この機会に関連する実装の整理も行われた。
無限縮小エラーの扱いの改良
2024年6月のリリース〔ltnews39とその斜め読みを参照〕では、改良されたマーク機構と、TeXの「無限縮小エラー」を回避する際に生じていた問題について説明した。その後、各エンジンに新しいプリミティブ\ignoreprimitiveerrorが追加され、このエラーを警告へと変換できるようになった。たとえば、ボックスの分割を試行的に行うだけの場合などに使用できる。この改善により、.logファイルに出力される内容が次のような長い警告から
! Infinite glue shrinkage found in box being split.
<argument> Infinite shrink error above ignored !
l. ... }
The box you are \vsplitting contains some
infinitely shrinkable glue, e.g., `\vss' or
`\vskip 0pt minus 1fil'. Such glue doesn't belong
there; but you can safely proceed, since the
offensive shrinkability has been made finite.
次のような単純で明確なメッセージへと改善された。
ignored error: Infinite glue shrinkage found in
box being split
さらに重要なのは、(本当のエラーがないかぎり)TeX実行時のリターンコードが常に0のままになる点である。つまり、TeXの実行結果にエラーがなかったかどうかをワークフローで判定する場合、これまでは「無視されたエラー」によって不適切にエラー扱いになる可能性があったが、今後はそのような誤判定が起こらなくなる。
\ProcessKeyOptionsで複数のファミリ名を使用可能にする
keyvalオプションの処理機能は、2022年6月のリリース〔ltnews35参照〕でカーネルに統合された。このとき追加された\ProcessKeyOptionsは、与えられたオプションを割り当てる役割を担い、元の仕様ではオプションとして1つのキーファミリ(名前空間)を選択できるだけだった。今回の拡張により、この引数にはカンマ区切りの複数ファミリ名を指定できるようになった。
keyvalにおける値の展開制御
通常、キーと値の入力は“そのまま”扱われ、キー・値ともに展開されない。しかし、一部の値については展開が必要になる場面もある。今回、テンプレート用のキー(\DeclareInstanceなど)と、L3プログラミング層で作られたキーに対して、指定した値のみ展開する機能が追加された。
どちらの場合も、末尾のコロンと指定子によって展開形式を設定する。この指定子は\ExpandArgsやL3プログラミング層で使用されている引数指定子と同じである。たとえば、LaTeX2eの変数\@itemdepthの値を利用したい場合、次のように記述できる。
key-a:c = @itemdepth ,
key-b:v = @itemdepth
この機能は、L3プログラミング層を用いて実装された設定コマンドを持つパッケージ(例:siunitx)では自動的に利用可能となる。
ケース変換で除外語を指定できるサポート
過去のリリースにわたって、自動的なケース変換(大文字・小文字変換)の改善が続けられてきた。今回、新たに「ケース変換から除外する語」を登録できる機能が追加された。利用できるコマンドは次の3つである。
\DeclareLowercaseExclusions\DeclareTitlecaseExclusions\DeclareUppercaseExclusions
これにより、小文字化・タイトルケース化・大文字化されては困る語〔固有名詞など〕を柔軟に指定できるようになった。
\parトークンの自動挿入
2022年以降、主要なTeXエンジンには\partokencontextというパラメタが追加され、\vboxの終端など、類似の場面でTeXが水平モードにあるときに\parトークンを追加するかどうかを制御できるようになった。従来のように、内部の「段落終端」処理が明示的なトークン追加なしに呼び出される方式よりも細かい制御が可能になる。
これにより、段落フックは\vboxの終端のような場面でも段落の終了を検知できるようになる。従来は、こうした状況で段落終端を検知させるため、パッケージ側のコードに明示的な\parを追加する修正が必要だった。今回の仕組みにより、既存パッケージのタグ付けコードとの互換性が向上すると期待される。
LaTeXはこのパラメタを既定で2に設定し、これらの場面での\par自動挿入を有効にした。
汎用フックへのアクセス改善
次のような汎用フックを追加するコード
\AddToHook{cmd/somecmd/before}{...}
が、expl3構文(\ExplSyntaxOn)で定義されたコマンドに対してより確実に成功するよう改善された。以前は、元の定義が\ExplSyntaxOnの状態で~を使用していた場合、フックの追加に失敗していた9。
バグ修正
\DeclareRobustCommandがアクティブ文字を正しく扱えるようにする
\DeclareRobustCommandの仕組みでは、文書用コマンド\fooに対応する内部コマンドとして、名前にスペースを付加した\foo␣が作られる。しかし、この方式をアクティブ文字に適用すると問題が生じる。通常のコマンドと異なり、アクティブ文字は必ず1文字でなければならないからである。
実装上の理由から、これまではアクティブ文字に対して\DeclareRobustCommandを用いると、内部的に毎回\␣を再定義するという誤った挙動になっていた。今回の修正によってこの問題は解消された。すなわち堅牢なアクティブ文字は\protected機構を用いて作成され、内部補助用のコマンドを使わなくなった。これにより、ファイル名やラベル内でアクティブ文字がその文字自身として扱われるという挙動も従来どおり維持される。
“Corrupted NFSS tables”エラーの回避
アクセント付き文字(例:ä、é)を組版する際、その文字がフォント内に存在せず、基底文字と単独アクセント記号の組み合わせで構成しなければならない場合がある。さらに、そのアクセント記号までフォントに存在しない場合、LaTeXは別のフォント(通常はOT1など別のエンコーディングのもの)からアクセントを探そうとする。
しかし、ここでフォント置換を伴うと、処理がループに入り“Corrupted NFSS tables”のエラーを引き起こす場合があった。今回、必要な\DeclareFontSubstitutionを追加することでこの問題が修正された。
toolsカテゴリとfirstaidカテゴリのパッケージ
いくつかのパッケージのステータス更新
toolsバンドルには、多様な用途をもつ複数のパッケージが含まれている。いくつかはLaTeX 2.09からLaTeX2eへの移行期に必要だったものであり、また別のもの(例:array)は現在も広く使われている。今回、このtoolsに含まれる少数のパッケージを「歴史的・安定性維持のためにのみ残されている」ものとしてマークし、必要に応じてより新しい代替パッケージへの誘導を〔パッケージ文書に〕追加した。対象のtoolsパッケージは以下のとおり。
- enumerate: 代わりにenumitemを推奨
- rawfonts: LaTeX 2.09サポートの一部として維持
- somedefs: LaTeX 2.09サポートの一部として維持
- theorem: 代わりにamsthmを推奨
- verbatim: 代わりにfancyvrbを推奨
longtableにおけるページマーク処理の更新
新しいLaTeXのマーク構造にあわせて、ページが出力される際の調整が正しく行われるようになった。
bmの更新
\chardefで定義されたコマンド(例:\#)を受け付けられるようになった。
AMS文書クラス群への応急手当
AMSクラス群は依然として旧来のマーク機構を使用しており(これは2024年に新方式へ置き換えられ、2025年6月リリースで完全に引退した)、その過程でカーネルコードの一部を上書きしている。このため、現在いくつかの問題が発生していた。今回のリリースではこの問題への応急手当が追加された。
-
今回のIssue番号が42であることにかけた洒落。 ↩︎
-
LaTeXの「必須ツール」の一部となっている、LaTeXチームが管理する小パッケージ群。https://ctan.org/pkg/latex-tools ↩︎
-
この決定の経緯は必ずしもGitHub Issue等に整理された形でまとまってはいないが、そもそもパラグラフの入れ子を許容するLaTeXのパラグラフモデルは、一般的なアクセシブルPDF標準(PDF/UA等)が採用する単純な
Pモデルよりも顕著に複雑である。そのため、特にtitlesecや標準外の文書クラスを用いた際に、複雑なLaTeXのパラグラフモデルによるタグ付けが破綻してしまうケースが多発したものと思われる。cf. TeX.SXでの報告例。 ↩︎ -
簡単にいえば、LaTeXのコマンドをすべて展開した後、残ったコマンドを除去したプレーンテキスト。例えば
\textgt{テスト、\LaTeX 、$x + y$}というLaTeX入力を精製するとテスト、、$x + y$という文字列になる。詳細はinterface3を参照。 ↩︎ -
ここでの「シンボリック(symbolic)」は「象徴的/記号的」というよりも「記号名として抽象化された/シンボルとして扱える」という意味だと考えられる。これはLispやUnixの文化の継承で、例えばUnixにおける「シンボリックリンク(symbolic link)」の「シンボリック」と同類と捉えるとよいだろう。 ↩︎
-
上付き/下付き文字(super-/sub-script)のこと。 ↩︎
-
ここで参照されているプルリクエスト(#1799)ではMemoizeパッケージの利用例が登場している。要するに
\cmd_arg_spec:Nが提供する文書コマンドの引数指定子復元機能は、コマンドのラップなどのメタプログラミング的場面で役立つ場合がある、という話がされている。ちなみに、MemoizeパッケージというのはTikZやForestなどTeXでの処理が重い要素の処理結果を外部にダンプしておき、毎回の処理時間を削減するためのパッケージ。TikZ標準にもexternalizationライブラリがあるが、それよりも初期化時の効率がよいという特徴があると謳われている。 ↩︎ -
\longは引数中で複数の段落(つまり\parの出現)を許可する接頭辞。接頭辞とマクロ等価性に関する話題はZR氏の『徹底解説! マクロの等価性を理解する』に詳しい。 ↩︎ -
元ネタとなっているIssue(#1099)を辿ると、マクロの定義が行われた後かつフックの設定が完了する前のタイミングで、そのマクロの定義が含む文字のカテゴリーコードが変更されるとフックが期待通り動作しないという不具合があったようだ。イントロダクションで「とりわけ奇妙なもの」と予告されていたのはこのバグではないかと思われる。かなり込み入った議論になっているので、TeX言語愛好家の方は読んでみると面白いだろう。 ↩︎