Acetaminophen’s diary

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

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

続きです。目次は前回の記事を参照してください。

 

7. dvipdfmx の仕様変更・機能強化       

仕様変更 2 件は,組版結果にも関わる大きな変更です。

7.1 バウンディングボックスのデフォルトが常に /CropBox へ       

昨年の TeX Live 2017 の解説記事で,「3. dvipdfmx の画像取り込みの挙動変更」として

従来の dvipdfmx のバウンディングボックス選択律「/CropBox → /ArtBox → /TrimBox → /BleedBox → /MediaBox の順に明示されている最初のものを選択する」が 2017 年 6 月に LaTeX team によって破棄され,「常に /CropBox を使う」という仕様に統一された

ことを述べました。この時点では「graphicx パッケージの dvipdfmx オプション (dvipdfmx.def)」の挙動が変わったのですが,TeX Live 2017 の時点では「dvipdfmx 本体」はまだ従来の挙動のままでした。どういうことかというと

TeX Live 2017 では「extractbb hoge.pdf で得られる .xbb に抽出されるバウンティングボックス」と,「graphicx パッケージが思うバウンディングボックス」が違う可能性がある

という状態です。TeX Live 2018 では,dvipdfmx 本体の改修も反映されますので,extractbb hoge.pdf でも常に /CropBox が返るようになりました。

7.2 回転された PDF (/Rotate) のサポート       

昨年の記事に【TeX Live 2018 に向けて】として書いていた部分です。

PDF の見た目を回転するために,PDF の内部に /Rotate という回転命令が仕込まれる場合があります。ほとんどの PDF ビューアはこの /Rotate 命令に従い,ページは回転して表示します。ところが,TeX Live 2017 までの dvipdfmx や XeTeX は /Rotate を無視し,ビューアの見た目と違う「回転前の向きのまま」で取り込むという挙動でした。これが TeX Live 2018 ではついに,dvipdfmx や XeTeX でも「/Rotate で回転されたページは回転して取り込む」という挙動に変更されました (r44963, r44964)。

以上 7.1・7.2 の結果を踏まえると,TeX Live 2018 では「PDF のページがビューアの見た目のまま(向き・バウンディングボックス共に)\includegraphics できる」ということになります。一方,過去のドキュメントをコンパイルすると結果が違ってびっくりすることもあるかもしれませんので,注意が必要です。

7.3 OpenType サポート機能の強化・修正       

dvipdfmx の OpenType サポート機能が TeX Live 2017 で追加されたことは,昨年の記事で述べました。ここで【TeX Live 2018 に向けて】として触れた修正内容が反映されますので,「一つのフォントには複数の OpenType Layout タグが付けられない」という制約がなくなります。

7.4 挿入可能な画像数上限の撤廃       

2015 年頃 (r37953) から 2017 年までの一時期,おそらく実装上の都合で「dvipdfmx で扱える挿入画像数の上限は 5000 枚まで」という制約がありましたが,撤廃されました (r45126)。

7.5 XeTeX で見 (U+898B) を処理すると ⾒(U+2F92) に化ける等の修正       

一見 dvipdfmx とは関係ないように見えますが,これは「XeTeX が組版した結果が xdvipdfmx(= dvipdfmx の独自拡張版)を通して PDF 化される過程」で起きている問題なので,dvipdfmx の問題です。

ここでは前者の質問を基に説明します。これは,「見」という見た目の字形が,Unicode文字集合の中に重複して登録されていることが一因でした(画像は Code Chart から。PDF 直リンク → U2F00.pdf, U4E00.pdf)。

  • CJK UNIFIED IDEOGRAPH - U+898B(「見る」を意味する単独の漢字)

    f:id:acetaminophen:20190413175254p:plain

  • KANGXI RADICAL SEE - U+2F92(漢字の一部,康熙部首としての⾒)

    f:id:acetaminophen:20190413175227p:plain     f:id:acetaminophen:20190413175241p:plain

意味は異なるので,Unicode に 2 回登場するのはおかしくありません。ただし,この字形を表示するフォントの方は,多くの場合は「見」という全く同じ見た目の字体を2つも収録せず,Unicode のコードポイント U+898B も U+2F92 も単一の「見」グリフを割り当てる多対一対応でいわば“節約”しています。

この“節約”で問題になるのが,「フォントの収録文字のうち何番目が,Unicode のどのコードポイントに対応するか」の対応づけです。これは ToUnicode CMap というもので,PDF からのコピペなどに必須のテキスト情報を定義するために欠かせません。(x)dvipdfmx は,フォントのxx番目の文字を使うという指示を受け取り,その文字を埋め込むのですが,その「見」が元々どちらの意味だったかという情報はもらえません。そこで,(x)dvipdfmx はフォントから逆算して ToUnicode CMap を作りますが,「多対一」の逆算は「一対多」ですから,必然的にどちらかを選ぶことになります。その選択の結果,たまたま「見」を単独の漢字 (U+898B) ではなく康熙部首 (U+2F92) を選んでしまっていた…というのがこの「部首問題」です。(x)dvipdfmx に限らず,他のソフトウェアや Web ブラウザでも似たような「部首問題」が起きることがあるそうです。

実用的な書類で部首が出てくることはあまりなく,漢字としての利用がほとんどでしょう。そこで,今回の例のような一対多の対応を考慮し,部首よりも単独の漢字の Unicode コードポイントを優先し,ToUnicode CMap に使うような対策がとられました(逆に言えば,部首のつもりで書いたものは漢字になってしまう,という制約があります)。

 

8. macOS 向けサポートファイルの分離・TLContrib 収録       

TeX Live は「利用や改変,商用再配布にライセンスの問題がなく(=フリー),かつフリーでない何かを動作に必要としない」ものだけを採用するという方針をとっています。そこで,様々な事情で TeX Live には入れないが,ライセンスの問題がなく,利用や再配布が自由なパッケージを代わりに収録して,TeX Live を補完しようというディストリビューションが存在します。TLContrib です(参考:forum:2366)。

以下のパッケージ群がこれに該当するので,TeX Live から分離されて TLContrib に収録されました。

  • ptex-fontmaps-macos (kanji-config-updmap):hiragino-elcapitan や hiragino-highsierra などの「macOS 専用のヒラギノフォント」を使うためのファイルを収録。
  • cjk-gs-integrate-macos:「macOS 専用フォント(ヒラギノを含む)」の設定用データベースを収録。
  • japanese-otf-nonfree:「ヒラギノフォントの和文プロポーショナル組」に使う TFM/VF を収録。

従って,TeX Live 2017 では単独で可能だった sudo kanji-config-updmap-sys hiragino-elcapitan が使えなくなります。TLContrib に収録されている ptex-fontmaps-macos をインストールすると,この命令が利用可能になります。方法の詳細は forum:2366 で既に告知してある通りです。

このように手作業で TLContrib をインストールするのが嫌だという場合は,GUI でこれが可能なツールが munepi さんにより公開されています。

 

9. kanji-config-updmap と cjk-gs-integrate の機能強化       

すぐ上に書いたフォントの設定に使われるツールですが,macOS 向けのファイルが分離された一方で,機能強化も入りました。

9.1 kanji-config-updmap で --ja と --sc などの同時設定が可能に       

2017 年に,それまでは jfontmaps という名前でインストールされていた「日本語用マップファイルと設定用スクリプト (kanji-config-updmap) のセット」が ptex-fontmaps に改名されて再出発しました。下記表題にもあるとおり,upLaTeX + dvipdfmx で中国語や韓国語の文書を作る場合の埋込フォントを切り替える仕組みが,このとき確立されました。

この時点ではまだ一度に多言語のファミリ名を指定することができず,例えば

  • まず kanji-config-updmap-sys hiragino-pron を実行して「日本語をヒラギノ」に変えてから
  • 次に kanji-config-updmap-sys --sc fandol を実行して「中国語を Fandol」に変える

というように複数回に分けて実行する必要がありました。新しいバージョン 20180306.0 ではこの制約がなくなり,例えば kanji-config-updmap-sys --ja hiragino-pron --sc fandol --tc adobe --ko unfonts のように,CJK 言語の設定を一度に変えられ,速度的に効率化できます。

9.2 cjk-gs-integrate の --fontdef-add で複数ファイル指定が可能に       

cjk-gs-integrate は「Ghostscript で CJK フォントを使うためのセットアップと,(--link-texmf オプションをつけた場合は)TEXMFLOCAL に dvipdfmx で CJK フォントを使うためのリンク作成を自動で行うスクリプト」です。新機能を使えば,“自分用のデータベース”を用意して cjk-gs-integrate に使わせることができます。

既に触れた cjk-gs-integrate-macos はこの新機能を活用し,「macOS 専用のデータベース」を用意することで実現されています。

 

10. ファイルサーチ機能 (kpathsea) の大文字・小文字の取り扱い       

これもユーザに影響する変更だと思います。

TeX Live は,多くの人が作成した成果物の集合体なので,大量のファイルを分類してディレクトリ構造 (TeX Directory Structure; TDS) に組み込んでいます。LaTeX を使う場合も,例えば \documentclass{article} と書けば article.cls というファイルが探され,\usepackage{scsnowman} と書けば scsnowman.sty というファイルが探されます。このようなサーチ機能の根幹を担っているのが Kpathsea ライブラリです。

さて,ファイル名にはアルファベットの大文字や小文字が使われますが,「大文字と小文字のファイル名を同じとみなすかどうか」は OS によって異なります(大文字と小文字を区別しないことを case-insensitive といい,区別することを case-sensitive といいます)。例えば,Windowscase-insensitive で,Linux などの Unix OS はほとんどが case-sensitive です。また,macOS の場合は case-insensitivecase-sensitive かを選ぶことができます(既定は case-insensitive)。

このような状況では,例えば foo.JPG というファイルが存在するとき

  • ある OS では \includegraphics{foo.jpg} で foo.JPG を見つけられたのに
  • 同じ .tex ソースを別の OS に持って行くと foo.JPG を探し出せなくてエラー

というようなトラブルが頻発していました(ということのようです)。そこで,Kpathsea version 6.3.0 で

  • 最初に呼ばれたファイル名 (foo.jpg) を探す。
  • もし見つからなければ,大文字と小文字が違うだけのファイルを探す。

というフォールバック機能が新設されました。

TeX Live 2018 ではこの機能がデフォルトで ON になっていますので,二段階のファイル検索が行われます。この機能を OFF にしたい場合は texmf.cnf という設定ファイルに定義されている環境変数 texmf_casefold_search の値を 1 から 0 にする必要があります。

この機能の詳細は,texdoc kpathsea で読める PDF ファイルの 5.4 Casefolding Search の節を参照してください。

 

11. dviselect や dviconcat 等のツールの pTeX / upTeX 対応       

日本の pTeX / upTeX は組版結果を DVI というファイルに出力します。TeX Live には沢山の DVI ウェアが収録されているのですが,(u)pTeX の DVI はオリジナルの TeX の DVI と比べて拡張されていて,その DVI を処理できるツールは少々限られています。TeX Live 2017 時点で (u)pTeX の DVI をサポートしていたのは,代表的な dvipdfmx,dvips と dvisvgm くらいでした。

ところが,他にも「時々使える便利ツール」が TeX Live には存在します。dviselect は,時々日本でも話題に上がっています。例えば,dvipdfmx で処理できない「10 万ページある DVI」を一旦 2 つの DVI にぶった切って別々に PDF に変換したい場合,この「ぶった切り」に使えます。

TeX Live 2017 までの dviselect は,pTeX の縦組を使った DVI を受け付けてくれませんでしたが,TeX Live 2018 では問題なく扱えるようになります。他にも dviconcat, dvitodvi, dvibook, dvidvi というツールが,TeX Live 2018 を以って pTeX 対応になります(これらの改修には,1992 年まで籠谷氏によって書かれていた「SeeTeX の日本語対応化パッチ」が大いに寄与しました)。

 

12. pdfTeX の「deterministic な出力」の改良       

以前の記事に【TeX Live 2018 に向けて】と書いていた話です。一般に,あるソースファイル test.tex を複数回コンパイルすると,その都度 DVI に埋め込まれる「処理日付の情報」や PDF の「フォント埋込オブジェクト番号」などが時間的・乱数的に変化します。しかし,「ある .tex ソースを何度処理しても完全にバイナリ一致する PDF を作りたい」という要望(主にテスト目的)があることから,TeX Live 2016 辺りから determinisitic (reproducible) な出力がサポートされるようになりました。

ところが,pdfTeX などで「ソースファイルを置くディレクトリの名前によって出力がバイナリ一致しない」という現象が報告されました。

これでは,最悪のケースでは OS ごと・ユーザごとに不一致な PDF が生成してしまい不便でした。TeX Live 2018 ではこの問題が解消します(必然的に,TeX Live 2017 と TeX Live 2018 では同じ環境変数を設定していても「違うバイナリ」が出てくるわけですが,しょうがないです)。

 

13. LuaTeX の Lua がバージョン 5.3 へ向け準備態勢へ       

LuaTeX には現在,Lua 5.2 が組み込まれています。しかし,TeX Live 2019 を目処に,Lua をバージョン 5.3 へ上げることを計画しているようです。具体的には

  • LuaTeX 1.07 以降は Lua 5.3 ベースでビルドできる
  • TeX Live 2018 では従来の Lua 5.2 ベースの LuaTeX が標準だが,luatex53(LuaTeX として)と texlua53(Lua インタプリタとして)も一緒に配布する
  • TeX Live 2019 では標準が Lua 5.3 ベースになる

ということのようです。

Lua 5.2 と Lua 5.3 では言語仕様が異なる(整数型の導入,math.pow の廃止などとのこと)ため,各種パッケージの改修が必要になると予想されます。移行期間とも言える TeX Live 2018 の間に,luatex53 バイナリを動かして,自分の手元にあるパッケージが確かめておくと慌てずに済むかもしれません。

 

14. その他の修正       

他にも幾つかありますが,細かいので箇条書きにとどめます。

 

駆け足ではありますが,多くの修正が入っていることがわかります。パッケージなどにもいろいろな修正・新機能が追加されているケースがありますので,それらもお時間のある時に texdoc を使って読んでみると面白いでしょう。