Acetaminophen’s diary

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

TeX Live 2018 注目ポイントまとめ (1)

TeX

今年 2018 年も、TeX Live 最新版のリリースが近づいてきました。注目の変更点をまとめてみましょう。特にユーザに影響しそうな項目については、以下の目次に太字で示しています。

 

1. LaTeX の入力エンコーディング (inputenc) が UTF-8 既定に                            

最近は XeTeX や LuaTeX のように「既定で任意の Unicode 文字入力が可能なエンジン」がありますが、それ以外（“クラシックな TeX エンジン”）では ASCII 以外の文字がきちんと解釈されませんでした。pLaTeX / upLaTeX もそれに含まれ、「和文扱いされる文字」は勿論入力できますが、「欧文扱いされる文字」については ASCII の範囲内しか扱えませんでした。そして、欧文扱いされる Unicode 文字を入力したい場合は \usepackage[utf8]{inputenc} が必須でした。inputenc パッケージについてはこの記事が詳しいです。

長年の制約がついに 2018 年リリースの LaTeX2e 2018-04-01 で解消し、既定で UTF-8 入力が有効になりました。つまり、\usepackage[utf8]{inputenc} を明示的に書かなくても、生で UTF-8 の欧文文字を書くことができるようになります。

互換性が少し心配になるところだと思いますので、箇条書きで説明します。

  • 従来 \usepackage[utf8]{inputenc} していたソースはそのまま通ります*1。同様に、utf8 と少し違う文字集合を利用できる \usepackage[utf8x]{inputenc} も、エラーなく通ります。
  • ただし、従来の「ASCII 文字以外は解釈されず素通りする」という挙動を利用した「ソースファイルを UTF-8 以外のエンコーディングにして、そのエンコーディング特有の文字を書く」という使い方は封じられます。具体例としては、ZR さんのコメントにあるような「ファイルを Windows-1252 (winansi) で保存し、フォントのエンコーディングを LY1 にする」という使い方はサポートされません*2。
  • 現時点では \input{tèst.tex} のように ASCII 以外の欧文文字を含むファイル名を読み込もうとすると失敗します。これは LaTeX team も承知の上で、後々対処される模様です。対処としては、例えばこの David さんのコメントにあるように、\detokenize を噛ませるとうまくいきます*3。
  • 直感に反するかもしれませんが「日本語の LaTeX ソースを UTF-8 以外のエンコーディングで用意して、pLaTeX でコンパイルする」という使い方は、従来通り可能です*4。例えば、今後も Shift_JIS でソースを保存して platex -kanji=sjis test.tex のようにコンパイルすることは可能です（Windows の場合は下記の自動推定機能により -kanji=sjis も不要）。これは、pTeX 系では和文文字と欧文文字が字句解析の時点で区別されるので、欧文の inputenc がどうなろうが関係ないからです。
  • この件に影響を受けてか、Windows 上の TeX Live 2018 で pTeX / e-pTeX / pLaTeX の日本語入力エンコーディングの既定値が Shift_JIS から UTF-8 に変わりました（他の Unix 系 OS との統一が図られました）。ただし従来と変わらず「文字コードの自動推定」という機能が存在するため、影響は無いはずです。 (→ forum:2396)

なお、(u)pLaTeX 側では、新しい LaTeX における \DeclareFontEncoding の定義変更に追随しています。 (→ texjporg/platex#68)

 

2. pLaTeX などの更新                            

番外：texjporg 管理の成果物のパッケージ再構成                            

日本語 TeX 開発コミュニティ (Japanese TeX Development Community) が始動して 3 年目に入ります。GitHub で管理を始めたさまざまなプロジェクトを、「メンテナンスのしやすさ」という観点から再構成し、CTAN にアップロードし直しました（参考：texjporg/tex-jp-build#51）。

  • (1) pLaTeX
    • フォーマット作成時の .ltx ファイルの読込順序を変えた。目的は後述 upLaTeX (2) のため。
    • ascmac.sty は (4) へ移動。
    • nidanfloat.sty は (5) へ移動。
  • (2) upLaTeX
  • (3) ptex-fonts
    • ascmac 用フォントを (4) へ移動。
    • morisawa 用フォントを (7) へ移動。
  • (4) ascmac ← pLaTeX (1) と ptex-fonts (3) から新規作成。
    • コミュニティ版であれば pLaTeX/upLaTeX 専用でなく pdfLaTeX などでも動く。
    • ascmac だけ更新したい場合に都合が良い。
  • (5) nidanfloat ← pLaTeX (1) から新規作成。
    • 元々 pdfLaTeX などでも動くため。
    • nidanfloat だけ更新したい場合に都合が良い。
  • (6) jsclasses
    • morisawa.sty は (7) へ移動。
  • (7) morisawa ← jsclasses (6) と ptex-fonts (3) から新規作成。
    • TeX Live に入っていた morisawa.map は上流がなかったので取り込み。
  • (8) ptex-fontmaps
    • hiragino-{elcapitan,highsierra} など macOS 専用は ptex-fontmaps-macos に分離；後述
  • (9) cjk-gs-integrate
    • macOS 専用のデータベースを cjk-gs-integrate-macos に分離；後述
  • (10) ptex-base
    • 古いアスキーのドキュメント類 (jtex.pdf, jtexdoc.pdf, ptexdoc.pdf, ptexskip.pdf) は obsolete 扱い。既に現在の pTeX と合わない部分もあるため，歴史的な資料ということにする。
    • 最新の pTeX のマニュアルは別途 ptex-manual として鋭意作成中。

2.1 JFM グルーを消す \removejfmglue 命令の追加                            

pTeX には \inhibitglue というプリミティブが存在します。

\inhibitglue: 和文フォントのメトリック情報から、自動的に挿入されるグルーの挿入を禁止します。このプリミティブを挿入した箇所にのみ有効です。

もう少し詳細に書くと

  • JFM（和文メトリック）には、「括弧類などの文字（例えば 」）はあたかも半角幅であるかのように扱い、空白に見える部分（例だと右半分）は半角幅のグルーとして扱う」という定義がある。
  • pTeX はこれを解釈し、組版時に自動的にこのグルーを挿入する。
  • ただし、\inhibitglue という命令を発行した箇所では、この自動挿入を抑制する。

というわけです。例えば 」あ では間に半角アキが挿入されますが、」\inhibitglue あ とするとくっつきます。

ところが、例えば 」\relax\inhibitglue あ のように書いても 」 と あ の間には半角分のアキが入ってしまいます。なぜかというと、」\relax の時点でグルー挿入が起こり、その後で \inhibitglue で抑制しようと思っても「時既に遅し」だからです。あくまで inhibit ＝ 抑制であって、削除ではないのです。

では、「既に挿入されてしまった JFM グルーを削除する」ことはできないのか、という疑問が起こります。これは従来の pTeX では不可能でしたが、2018 年 2 月 26 日の e-pTeX の更新で \lastnodesubtype という新しいプリミティブが追加されたことにより、マクロで実装可能になりました。

この新しい \removejfmglue は、次に挙げる表組のマクロ改善に寄与しています。

2.2 表 (tabular) の JFM グルー対策の改良                            

コミュニティ版 pLaTeX では、表（tabular 環境）のセル内が括弧類で始まる場合・終わる場合を考慮し、JFM グルーを消したいという要望を反映した修正を 2017 年に導入しました（参考：texjporg/platex#43）。ところが、この影響で「LaTeX と pLaTeX で組版結果が違う」という事例が発生してしまいました。

細かい事例ではありますが、対処しようにも従来の pTeX では不可能…というところを、\removejfmglue マクロを活用することで解消することができました。

2.3 新規約：和文クラスファイルで「和文スケール値」規定へ                            

和文クラスファイルをデザインするとき、和文文字と欧文文字のサイズバランスを考える必要があります。そして、多くのクラスファイルは、和文文字のメトリックをスケールすることで欧文とバランスを取るという方法が採られています。

例えば \documentclass[10pt]{…} のように 10pt が指定されたとき、全角幅 1zw はどんなサイズにするのが良いでしょうか？ これはクラスファイルの設計者に委ねられるので、例えば (u)jarticle 系は 0.962216 倍、jsclasses 系は 0.924690 倍という設計になっています。

世の中には、フォントを変更する・多書体化するパッケージが存在します（例えば OTF パッケージ）。ここで「フォントは変えるけど、クラスファイルが意図するスケール値を極力踏襲したい」と考えると…。クラスファイル毎の設計値を知る必要がありますが、アドホックに「jarticle というクラスでは 0.962216 倍、jsarticle というクラスでは 0.924690 倍、…」のように一つ一つ登録する必要が出てきます。実際、新たなクラスファイルについてはその都度スケール値を調べないと、クラスファイルのデザインと合わなくなってしまうのです。

それでは不便なので、新たに pLaTeX / upLaTeX 系列では規約を策定しよう、という方向で進めています*5。なお、この方向性は LuaTeX-ja にも踏襲されています。

  • 和文クラスファイルは、和文スケール値（1zw ÷ 要求サイズ）を \Cjascale という名前のマクロで定義する。
  • フォント関係のパッケージは、必要なら \Cjascale を参照する。

この新規約に従って実装されているクラスファイルであれば、例えば OTF パッケージ（2018-02-01 v1.7b 以降）はそのクラスファイルの和文スケール値を踏襲してくれます。2018 年 4 月 7 日現在、以下がその規約に従っています。

  • クラスファイル
    • pLaTeX 付属の標準クラス (jarticle, jbook, jreport, tarticle, tbook, treport)
    • upLaTeX 付属の標準クラス (ujarticle, ujbook, ujreport, utarticle, utbook, utreport)
    • jsclasses (jsarticle, jsbook, jsreport, jspf, kiyou)
    • BXjscls (bxjsarticle, bxjsbook, bxjsreport, bxjsslide)
    • LuaTeX-ja 付属のクラス (ltjsarticle, ltjsbook, ltjsreport, ltjspf, ltjskiyou)
  • パッケージ
    • OTF パッケージ (otf)
    • ZR さん作の各種パッケージ (BXbase, BXcjkjatype, PXchfon, PXgtfont, ZXjafont, ZXjatype, ZXotf)

この記事を書いている時点では、JLReq クラス (jlreq.cls) は従っていません。現時点では \Cjascale を解釈するパッケージが（ほぼ OTF パッケージのみと）限られること、またその OTF パッケージのメトリックが日本語組版処理の要件と必ずしも合致していないことが理由と思われます。

2.4 ascmac パッケージを縦組でも pict2e と互換に                            

LaTeX の picture 環境系の命令は、TeX 本来の機能「線や文字を置くだけ」で描ける精一杯の描画をします。しかし、それだけでは描ける線の方向や円の大きさに制限があるため、pict2e パッケージが開発されました。これは「描画はドライバ（DVI → PS/PDF に変換するツール）に任せる前提で、picture 系の命令を \special を駆使したものに再定義し、綺麗な描画をする」というものです。通常の横組の範囲では、この pict2e パッケージはうまく機能し、LaTeX 標準のインターフェースはそのままに、幅広い描画が可能になります。しかし、pLaTeX や upLaTeX の縦組では一般に pict2e の結果が崩壊します。pTeX が思っている縦組の字送り・行送り方向と \special で描かれる線の方向が 90 度ずれてしまうためです。

ascmac パッケージは screen 環境などで「角の丸」を描画します。そのために使われる \oval も pict2e による再定義を受けるため、縦組で pict2e を読み込んだだけで screen 環境の「角の丸」が変な方向を向きます。…が、ascmac にとって必要なのは \oval だけなので、案外簡単に対処できます。

というわけで対処した新しいバージョンが、TeX Live 2018 からは利用可能です。

2.5 morisawa パッケージの \textmg 命令を robust に                            

pLaTeX の \textmc（明朝体にする）や \textgt（ゴシック体にする）は robust な命令として定義されています。長年 morisawa パッケージの \textmg（丸ゴシック体にする）はなぜか robust でなく展開されるという挙動でしたが、今回の更新で robust にしました。

 

3. pTeX の修正・e-pTeX の修正と新機能                            

この点については、北川さんによる詳しいまとめがあります。

上記では (e-)pTeX エンジンの挙動に注目してまとめられているので、私の記事では目次の引用とともに「pLaTeX / upLaTeX ユーザに影響しそうなポイント」まで落とし込んだ補足を付けておきます。

pTeX
  1. 組方向変更が可能な条件を厳格化
    • 「ボックスが空でない時は組方向変更できない」を徹底しつつ、「ボックスが空かどうか」の判定は少し緩んでいます。この厳格化で、例えば過去にあった「biblatex が縦組でエラー (forum:1508)」のような「かなり“微妙な”問題」は起きなくなります。
  2. \hbox{・} の処理
    • 例えば okumacro の \kenten 命令の実装には、\hbox{・} が使われています。今回の pTeX の修正に伴い、従来の実装のままでは圏点がずれる（参考：forum:2272）という問題が起きました。現在の okumacro は texjporg/jsclasses#60 を経て修正されています。
  3. 和文のコントロールシンボル
  4. エラーメッセージのヘルプ
  5. \ptexversion プリミティブなどの追加
  6. disp_node の処理
    • forum:2388 のような現象が起きなくなります。ただし 
      \documentclass{tarticle}
\begin{document}
\noindent 「こんにちは！」

と元気に挨拶した。
\end{document}
      のようなソースの組版結果が変わります（TL2017 では最初の 「 が二分下がり、TL2018 では天付き）。
  7. 禁則用ペナルティや \inhibitxspcode でデフォルト値を設定した場合
    • 北川さんの記事にも書かれていますが、texjporg/tex-jp-build#57 のバグが TeX Live 2018 の初版の (e)(u)ptex に混入してしまいました。この状況では「既に禁則ペナルティや \inhibitxspcode が設定されている文字に対して、デフォルト値を設定してキャンセルしようとする」行為は避ける必要があったのですが、TeX Live 2018 でバグが多発したため、例年にはなく異例の「バイナリのリビルド」が行われました。このとき r47477 の修正が反映されましたので、5月下旬以降に tlmgr でアップデートした場合は解消しています。
e-pTeX
  1. \epTeXversion プリミティブの追加
  2. \epTeXinputencoding プリミティブの動作修正
  3. \pdfprimitive, \ifpdfprimitive の動作修正
    • pdfTeX / XeTeX の同様の問題も修正されました。
  4. ! File ended ... エラーの修正
    • pdfTeX / XeTeX の同様の問題も修正されました。
  5. \lastnodesubtype プリミティブの追加
    • これが pLaTeX の \removejfmglue に寄与します。
JFM の改善・拡張
  1. 0x10000 以上の文字コードをサポート
    • この新仕様の JFM をサポートすべく、各種 DVI ドライバも改修が入っています。具体的には、dvips, dvipdfmx, dvisvgm, dvipos, (u)pdvitype が対応完了しています。(u)pmpost, dviout, (p)xdvi は未対応となっています。
  2. glue/kern テーブルの制限緩和
    • ここで「JFM グルー・カーンの指定（glue/kern テーブルのエントリ数）も 32510 個まで」に制限緩和されたことが、upLaTeX で OTF パッケージの \propshape を使う場合（※ japanese-otf-uptex-nonfree のインストールが必要）に効いてきます。実際、ヒラギノプロポーショナル用の JFM は 256 個が上限では足りず、たくさんの glue/kern エントリが定義されています。
なお「検討中の事項：\inhibitglue の有効範囲」は TeX Live 2018 には適用されませんでした。今後も要検討となります。

 

4. upTeX の仕様変更：和文扱い・欧文扱いする文字範囲の変更                            

従来の upTeX 1.22 では、ASCII 以外のすべての Unicode 文字（U+0080 以上）を和文扱い*6していました。おそらく、pTeX が ASCII 以外の「JIS X 0208 で扱える文字全て」を和文扱いしていることに合わせたのでしょう。

upTeX 1.23 では、（非英語）欧文との親和性向上のため、デフォルトでラテン文字をなるべく欧文扱いするよう変更されました。

この影響で、例えば \kcatcode`À=15 (À: U+C0) のような書き方はうまくいかなくなります（この文字は今回「デフォルトで欧文扱い」に変更された内に含まれるので）。pxcjkcat パッケージを使っている場合は（pxcjkcat も対応完了しているため）問題ありません。

 

5. makejvf の大規模拡張                            

makejvf とは、pTeX が組版に使う JFM メトリックから、実際のフォントへの“橋渡し”を担う Virtual Font (VF) を作成するためのツールです。従来の makejvf ではできなかった機能が追加され、使い方次第で VF のカスタマイズが可能になりました。（TeX におけるフォントの扱いに詳しい方向けの難しめの内容を含みますが、極力簡単な記述を心がけます。）

5.1 Enhanced mode の追加                            

JFM では約物を半角幅のように扱い（その不足分を伸縮可能な JFM グルーで補い）ますが、実際の和文フォントでは約物も固定全角幅でデザインされています。この齟齬を解消するため、VF は「JFM グルーの分だけ文字を左にシフトする」という処理を担います。

この「シフト量」は、一般的な日本語フォントのデザインを前提として、makejvf のソース中にハードコードされていました。これでは日本語用 JFM に対してはうまくいきますが、例えば繁体中国語フォント（句読点類が仮装ボディの左下でなく、中央にデザインされているケースが殆ど）では失敗し、アンバランスになります。

このようにハードコードされたシフト量を使うのではなく、JFM に即した VF を作ることができればいいのに…という希望を叶えるのが、Enhanced mode です。-e オプションをつけて起動すると Enhanced mode に入ります。

-e           Enhanced mode; the horizontal shift amount is determined
             from the glue/kern table of <TFMfile> input

この Enhanced mode は、JFM に格納された glue/kern テーブルをうまく読み出し、その文字ごとに「pTeX が左に挿入してくるグルー量の分だけ、実際のフォントでは文字を左にシフトする」としてやれば良いという発想に基づきます。

例えば uptex-fonts に収録されている uptch〜 という繁体中国語用 VF はこの -e を利用して作成されています。

5.2 カスタマイズ用 Configuration file の読込機能                            

それでも少し特殊な JFM を作ると、シフト量が期待通りにならない場合がありえます。そこで使えるのが設定ファイルを読み込む -t オプションです。

-t  Use <CNFfile> as a configuration file

この設定ファイルでは「シフト量 (MOVE) の他にも「文字の置換」(REPLACE) と「VF に含める文字集合」(CHARSET) も指定可能です。使い方は以下の GitHub の議論中に日本語で書かれているのと、texdoc makejvf で表示されるマニュアル（英語）を参照してください。

既に、2018-02-11 にリリースされた uptex-fonts ではこの設定ファイルを利用し、upTeX / upLaTeX 用のデフォルト日本語 JFM（upjis 系）で Adobe-Japan1-6 の全文字を出力できるようにしてあります。ZR さんの「アレなデフォルト」の「その4：upLaTeXでBMP外の字を使うとアレ」が解消したのも、この makejvf の新機能あってのものです。

5.3 makejvf のその他の修正                            

細かい修正も入りました。(texjporg/tex-jp-build#16, texjporg/tex-jp-build#17)

 

6. Knuth の TeX / PLtoTF と TeX Live 版のそれらとの差異解消                            

ちょっと驚きの発見が相次ぎました。少しだけ嚙み砕いた表現にすると、「TeX Live に 20 年以上収録されている TeX は、実は作者 Knuth が作った TeX とは動作が違った」といった事件が発生したのです。それを修正した結果、TeX Live 2017 以前と比べると TeX の字句解析の挙動まで変わってきます（といっても、かなり特殊なケースですが）。

6.1 TeX で行末のタブ文字が消えなくなります                            

Knuth の TeX は、Pascal WEB というプログラミング言語で書かれていて、Pascal コンパイラでコンパイルします*7。しかし、Pascal コンパイラを持っている人は少ないので、TeX Live では WEB から C 言語に変換し、C コンパイラでコンパイルしています。このような TeX の実装をよく「Web2C 版の TeX」と呼びます。

TeX Live の TeX は「Web2C 版」なのですが、元の Pascal WEB から C に変換してコンパイルするために、入出力部分を書き直すことになります。その際に、「行末にタブ文字があった場合」の処理方法がまずく、Knuth が作った TeX と Web2C 版の TeX の間に違いがあることが 2017 年に見出されました。

これがついに修正され、TeX Live 2018 に反映されています。なお、この修正により、昨年の TeX ＆ LaTeX Advent Calendar 2017 の 20 日目の記事

にある記述

行の最後のコマが空欄の場合は，Tabと改行の間に{}（ブレースの組）を入れてTabと改行を仕切ってください。そうしないと，TeXの字句解析器の段階で改行が食われてしまい，うまくいきません。

の問題が自動的に解消します。

6.2 PLtoTF が不正な TFM を作らなくなります                            

TFM を作成するツールである PLtoTF が「TeX に Bad metric (TFM) file. と怒られる不正な TFM」を作ってしまうという問題です（発見者は私）。

TFM には、全体のファイルサイズの上限が存在します。TeX Live 2017 までの PLtoTF には、TFM 生成時にサイズ上限を超えてもエラーを出さずにオーバーフローしてしまうという挙動がありました。その結果、大きすぎて読み込めない TFM ができてしまい、TeX や TFtoPL（逆変換ツール）に怒られてしまうわけです。このオーバーフローは、Pascal WEB ソースの PLtoTF にある整数値のレンジ 0〜32767 を C で書き直すときに、(signed) int のレンジ -32768〜32767 に拡張されてしまうことが原因でした。

この問題は日本語の JFM を作る (u)pPLtoTF も引き継いてしまっており、特に (u)pTFtoPL はこの不正な JFM を食わせるとメモリ不足のエラー（場合によっては落ちる）ケースがありました。TeX Live 2018 ではこうした問題に対処しています。

 

まだまだ続きます。

*1:従来は「\usepackage[utf8]{inputenc} した時点で utf8.def というファイルが読まれる」という仕組みでした。新しい LaTeX では最初から utf8.def が読込済の状態になっていて、敢えて二回目は読まれないように対処されています。newunicodechar パッケージも 2018-04-08 付けで LaTeX の新仕様をサポートしています。

*2:これと同じ理由で、ZR さんのブログにある例のように「Shift_JIS の半角カタカナを直接書く」という使い方はサポートされません。これらの使い方は“バッドノウハウ”にすぎず、正統な使い方ではありません。

*3:なお、2018-04-08 時点でリリースされていた LaTeX2e 2018-04-01 patch level 1 には「ターミナルから pdflatex tèst.tex と打っただけでもエラーになる (issue 32)」という問題が存在したので、patch level 2 で修正されています。このエラーの理由は「ファイル名のつもりの引数も、実は TeX 言語コードの一部である」という TeX のアレな仕様に由来します。参考：ZR さんのブログ

*4:上述の「半角カタカナの“バッドノウハウ”」は除く。

*5:現時点では、pLaTeX の「公式マニュアル」と呼べるものが存在しないので、「規約化しました」と宣言するには不十分な状態になっています。今後、ドキュメントを整備しながら、これを規約として成立させられるよう善処する予定です。

*6:upTeX の仕様によると、厳密な表現は「CJK 扱い（漢字、仮名、その他記号、ハングルのうちのいずれか）」とすべきですが、簡単のため和文と呼ぶことにします。

*7:WEB とは「文芸的プログラミング」で、ソースコード本体とその解説文書を一緒に書くという、Knuth が提案した手法です。TeX のソースコード tex.web は実際に Pascal WEB で書かれています。tex.web をコンパイルして TeX のバイナリを生成するためには、tangle というプログラムで Pascal WEB から素の Pascal ソースを抽出し、Pascal コンパイラでコンパイルします。また、解説文書を処理するためには、weave というプログラムで TeX ソースを抽出します。

TeX Live 2017 注目ポイントまとめ

TeX
これは TeX ＆ LaTeX Advent Calendar 2017 の 10 日目の記事です。昨日は hak7a3 さんでした。明日は isaribi_saitoh さんです。

2017 年も残りわずかとなりました。TeX Live 2017 がリリースされてから早くも半年が経ったことになります。遅くなりましたが、ここで

TeX Live 2016 やそれ以前から TeX Live 2017 へ移行する場合のメリット・注意点

をまとめてみます。TeX Live のメンテナのお一人であるノルベルトさんの記事もありますが、遅ればせながらここで紹介させていただきます。

ここで詳細な説明をすると長くなってしまうので、この記事ではあくまで変更点を俯瞰するにとどめ、それぞれの詳しい説明への導線を可能な限りで張ることにします。

一般の LaTeX ユーザ☃が使う上で注意が必要なのは

もう少し進んだ使い方（欧文フォントの TFM/VF の追加など）をするユーザの方は

新しいコトをもっともっとしてみたいユーザにとっては

に注目です。TeXnician の方々🍣は

をどうぞ。

宣伝：昨年と一昨年も似たような記事を書いていますので、よろしければどうぞ。

 

☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃ ☃

続きを読む

コミュニティ版 pLaTeX / upLaTeX 2017/05/05 版の解説 (2)

TeX

前回の続きです。

 

3. LaTeX2e 2017-04-15 対応

本家 LaTeX2e が更新されたので、それへの対応です。

3-1. \verb と verbatim 環境の修正

「入力したまま」を表示する \verb と verbatim 環境に対して、本家 LaTeX カーネル側で修正が入りました。修正内容とは「verbatim な範囲では“絶対に”ハイフネーション行分割が起きないようにする」というものです。

あれ？ と思った方、鋭いです。従来も、verbatim な範囲ではハイフネーションが起きないように設計されているはずでした（要するに、たとえページをはみ出してもどこまでも「入力したまま」の内容が横にのびていく）。が、そこには条件があったのです。その条件とは、ざっくり言えば「verbatim に使われるフォントがタイプライタ体のときには」というものでした。

これでは「任意のフォントで verbatim したい」という場合に困ってしまいます（おそらくフォント選択の自由度が高い XeLaTeX や LuaLaTeX では、問題が顕著になると思います）。そこで新しい LaTeX では、verbatim な範囲ではどんなフォントを使っていてもハイフネーションが抑制されるようになっています。

補足：日付表記の変更に関して

なお、platex や uplatex の起動時のバナーを見て気づいた方がいらっしゃるかもしれませんが

LaTeX2e <2017/01/01>

という表示から

LaTeX2e <2017-04-15>

という表示に変わりました。年/月/日 (YYYY/MM/DD) から 年-月-日 (YYYY-MM-DD) に変わったことで、ISO 8601 に準拠したことになります。

従来の YYYY/MM/DD 方式では、地域によって YYYY/DD/MM だったり DD/MM/YYYY だったりとバラバラでした。たとえば 2017/05/04 と書かれていた場合、これが 2017 年 5 月 4 日なのか 2017 年 4 月 5 日なのかわからない…ということが多々ありました。LaTeX2e の日付はこれまで常に YYYY/MM/DD の順になっていましたが、ときどきパッケージ開発者が間違って YYYY/DD/MM と書いてしまうことがあって混乱を起こしていました。

ISO 8601 に規定されたハイフン方式は、地域差なく必ず YYYY-MM-DD を表します。長い歴史のある LaTeX team が日付表記を曖昧さのない方式に切り替えたことは英断だと思います。また、起動時のバナーにそれが現れていますので、アピールの意味合いも大きいと思われます。

pLaTeX の日付はまだ 2017/05/05 のように YYYY/MM/DD のフォーマットを維持していますが*1、近い将来、コミュニティ版 pLaTeX / upLaTeX も、LaTeX team に追随してこれを YYYY-MM-DD に切り替える予定です。

 

4. nidanfloat パッケージのバグ修正

図や表が大きすぎて、二段組の片カラムに入りきれず両カラムにまたがる場合があります。LaTeX は標準では、こうした段抜きフロートをページの top（[t] オプション）か、別ページ ([p] オプション）にしか配置することができません。これを bottom（[b] オプション）対応にするのが、nidanfloat パッケージです*2。

このパッケージには古くからバグがあり、qa:44116 や qa:51706 で指摘されてきました。「右カラムの処理中に段抜きフロートが出現すると、カラムの高さの計算を間違って本文とフロートが重なる」というバグです。

\documentclass[twocolumn]{article}
\usepackage{nidanfloat}
\usepackage{lipsum}
\begin{document}
\lipsum[1-5]
\begin{table*}[b]
\begin{tabular}{cccccccc}
\hline
AAAAAA & BBBBBB & CCCCCC & DDDDDD & EEEEEE & FFFFFF & GGGGGG & HHHHHH \\
\hline
a & 1.00 & 1.00 & 1.00 & 1.00 & 1.00 & 1.00 & 1.00 \\ 
a & 2.00 & 2.00 & 2.00 & 2.00 & 2.00 & 2.00 & 2.00 \\ 
a & 3.00 & 3.00 & 3.00 & 3.00 & 3.00 & 3.00 & 3.00 \\ 
a & 4.00 & 4.00 & 4.00 & 4.00 & 4.00 & 4.00 & 4.00 \\ 
\hline
\end{tabular}
\end{table*}
\lipsum[1-3]
\end{document}

f:id:acetaminophen:20160311140406p:plain

今回のリリースで、ついにこのバグを修正することが出来ました！ 実に 10 年以上の懸案が解消したことになります。

f:id:acetaminophen:20170604115113p:plain

 

5. 目次の中で \ref の直後の半角スペースが消えるバグの修正

ラベル \label の番号や出現したページ番号を取得する「相互参照」機能の \ref や \pageref ですが、pLaTeX / upLaTeX ではたとえばセクション \section のタイトルに使うと、目次に出したときに後ろの空白が喰われて消滅するバグがありました。

\documentclass{article}
\begin{document}
\tableofcontents
\section{Question}\label{q1}
\section{Another Question}\label{q2}
\section{Answer for the question in \ref{q1} and \ref{q2}}
\end{document}

f:id:acetaminophen:20170604120409p:plain

新しいバージョンでは修正し、正常に半角スペースが残るようになりました。

f:id:acetaminophen:20170604120425p:plain

補足：一部には \section のような「動く引数」*3では \protect を前置すべきでは？ という話がありました。しかし、LaTeX2e の source2e.pdf を見ると「\ref や \pageref を robust にした」と書かれています。pLaTeX ではこれが意図せず壊れていたわけですから、LaTeX と合わせるためには robust な実装にしないといけないわけです。

 

6. 出力ルーチンの高さ補正量の誤り修正

これは説明が難しいのですが…大雑把に説明します。従来の pLaTeX で以下の縦組文書を処理した場合、脚注ありのページとなしのページで版面がまるごとずれていました。

\documentclass{article}
\documentclass{tarticle}
\begin{document}
脚注がないpage\clearpage
脚注があるpage\par テスト\footnote{あいうpage}。\clearpage
\noindent\vrule width\textwidth height\textheight
\end{document}

実際にオーバーレイしてみるとこんな感じでした。

f:id:acetaminophen:20170604122742p:plain

これは、pLaTeX / upLaTeX カーネルの出力ルーチン内で、高さ補正量が正しくなかったためでした。新しい pLaTeX では次のように綺麗に重なります。

f:id:acetaminophen:20170604122801p:plain

 

7. \linebreak を行頭禁則文字直前でも有効化

これは、pTeX 系特有の処理の代表である「禁則処理」が絡む話です。

pTeX のデフォルトでは、行頭禁則文字すなわち「。」や「、」や「！」等の直前では絶対に行分割が起きないような設定がされています。問題となるのは、この「pTeX が定義した禁則文字」と「LaTeX が提供する明示的な強制改行命令 \\ または \linebreak」が連続したときの挙動です。

従来の pLaTeX は「pTeX の行頭禁則文字の直前でも \\ という強制改行命令は効く」という対処が施されていました。ところがどういうわけか、\linebreak に対してはそうなっていませんでした。同じ LaTeX レベルの命令なのに、一方は強制改行して一方は改行しない…というのは不自然なので、新しい pLaTeX では「pTeX の行頭禁則文字の直前でも \linebreak という強制改行命令も効く」という仕様にしました。

もっと詳しく：pTeX の禁則処理は、ペナルティという概念を流用することで実現されています。現在の pTeX は「通常の TeX のペナルティ (\penalty) の直後に行頭禁則ペナルティ (\prebreakpenalty) が連続する場合、その場で 2 つのペナルティ値を合算する」という挙動を示します。LaTeX の \\ と \(no)linebreak はともに「通常の TeX のペナルティを発行する命令」なので、直後に行頭禁則ペナルティが続くとそこで合算が起き、結果的に強制改行が無効化されてしまいます。pLaTeX ではこれらの命令を改修し、「通常の TeX のペナルティを発行した後に“見えない壁”を置く」ことで、あたかも連続していないかのように pTeX に見せかけて合算を抑制するようにした、と説明できます。

 

8. その他

ほかにもいくつかありますが、些細なバグ修正なので挙げるだけにとどめます。

  • \textundescore を縦組の数式内テキストで使ったときの位置が変だったのを修正
  • plext パッケージの \Kanji{数字} のあとにも数字が続く場合、その数字まで漢数字に変わってしまうもバグを修正
  • plext パッケージによって拡張された \parbox 命令と \pbox 命令（LaTeX の \makebox みたいなもの）を robust にした。さらに、\pbox が calc パッケージ（簡単な式による寸法指定が可能に）でエラーにならないように修正

 

未完の最重要案件：plext パッケージ

実は、現在 2017/05/05 の pLaTeX に付属している plext パッケージは未完成な部分が残っています。それは、tabular 環境や \parbox 命令の「組方向オプション」拡張機能を使った場合の位置の問題です。これは現在 pLaTeX レポジトリの issue 24 で議論している最中です。

なぜこれが問題かというと、plext パッケージは 2001 年からその構造はほとんど変わっていません。それにもかかわらず、pTeX のほうは何度も修正を経ています。その結果「plext は変わっていないのに、plext を使った pLaTeX 文書の処理結果が年々変化してしまった」という事情があります。これでは困るので、「最新の pTeX の挙動に即して、plext の仕様を確定させよう」というのが目標です。詳細は GitHub の議論を参照してください。

*1:これはごく一部の LaTeX パッケージが「スラッシュで区切られた日付」を想定して書かれているためです。たとえば stfloats.sty というパッケージは、2016/06/28 v3.2 まで YYYY/MM/DD 書式しか想定していませんでした。このままでは LaTeX2e 2017-04-15 が出た途端に stfloats.sty が全く動かなくなる…という懸念を作者に報告し、対処済みの 2017/03/27 v3.3 をリリースしていただいた、という経緯があります。このようなケースが他にもあるかもしれないので、pLaTeX / upLaTeX はもう少し慎重に様子を見ようとしています。

*2:これと同じような機能を提供するものに dblfloatfix パッケージなどというものがありますが、nidanfloat のほうがフロートを元のページに配置しやすい傾向にあり、dblfloatfix のほうが次のページに送りやすい傾向にあります。

*3:ざっくりいうと、外部ファイル .aux や .toc などに一度書き出されて再度読みこまれるという処理を通るもの。

コミュニティ版 pLaTeX / upLaTeX 2017/05/05 版の解説 (1)

TeX

先日、コミュニティ版 pLaTeX と upLaTeX を更新しました。TeX Live 2017 のリリース時に標準でインストールされるバージョンはこの 2017/05/05 版となります。本家 LaTeX も最近アップデートされましたので、platex や uplatex コマンド起動直後のバナーは以下のように表示されます。

  • pLaTeX の場合： 
    pLaTeX2e <2017/05/05> (based on LaTeX2e <2017-04-15>)
  • upLaTeX の場合： 
    pLaTeX2e <2017/05/05u01> (based on LaTeX2e <2017-04-15>)

今回は半年ぶりのアップデートで、かなり多くの修正・改良を加えてあります。本記事では、この修正点について解説します。

 

続きを読む

TeX Live で使えるゆきだるま☃のまとめ

TeX ネタ
これは TeX ＆ LaTeX Advent Calendar 2016 の 23 日目の記事です。昨日は __rinx さんでした。明日は golden_lucky さんです。5 日目と 7 日目に続いて今年 3 回目の参加となります。

2016 年も残すところあとわずかになりました。師走の仕事納め、学生の皆さんは卒論の大詰めを迎えていることでしょう。特に LaTeX で卒論を書いている皆さんは、さぞかしゆきだるま☃が恋しくなっていることと思います。今日はそんな皆さんに朗報です！

f:id:acetaminophen:20161223125907p:plain

学生の方に限らず、LaTeX 文書を書いていると、無性にゆきだるま☃が欲しくなった経験は誰にでもあるでしょう。そんなときに使える「TeX Live で使えるゆきだるま☃」を一挙に紹介します。

 

続きを読む