TeX Live 2019 注目ポイントまとめ (1) (original) (raw)

この広告は、90日以上更新していないブログに表示しています。

【最終更新 2019-05-01 14:50】ついに日本時間の昨日，TeX Live 2019 がリリースされました。

本ブログで毎年恒例の（昨年はこちら），TeX Live 2018 → 2019 の変更点まとめです。特にユーザレベルに影響しそうな項目は，下記目次で太字にしてあります。

目次

いきなり番外編：新元号「令和」への対応

「新元号に変わるので LaTeX が動かなくなります。アップデートしましょう。」

…ということは絶対にありえません。ただ，「LaTeX で令和できるとハッピー???」という方のために，最初に持ってきました。

今日の日付を表示する \today を \和暦 な状態で使った時，2019 年 4 月 30 日までは「平成」，2019 年 5 月 1 日からは「令和」となります*1。

もし，学会などのクラスファイルが対応していない状態で「令和」な日付を使いたくなったら，bxwareki パッケージの \warekitoday という命令が新元号「令和」に対応していますので，利用すると良いでしょう。

また，OTF パッケージの \ajLig{令和} も令和の組文字 (U+32FF) になります。ただし，この U+32FF の組文字が PDF で正しく表示されるためには，埋め込むフォント自体に「令和」の組文字が存在する必要があります。また，この文字を PDF からコピーペーストできるようになるためには，ビューア（Adobe Acrobat Reader など）に内蔵されている CMap ファイルが十分新しいものでなければなりません。

さて，ここから本題です。

1. インストーラが新しくなった

TeX Live のインストーラ install-tl の GUI 部分が刷新されました。

新しい見た目がこちら。

f:id:acetaminophen:20190413184104p:plain

…といっても，まだ TeX Live 2019 リリースが正式にアナウンスされて間もないため，私自身まだこのインストーラを試せていません。機会があれば見てみようと思います。

2. mendex の文字コードを既定で UTF-8 に変更

昨年（2018年）の変更点に書いたとおり，2018 年春に LaTeX のデフォルトが UTF-8 に変わり*2，この変更に触発されて Windows の pTeX のデフォルト入力文字コードも UTF-8（-kanji=utf8 に相当）に変わりました*3。今年は，この「デフォルトで UTF-8 化」の波が索引作成ツール mendex にもやって来ました。

TeX Live 2018 までは以下のようになっていました。太字部分に注目です。

これが TeX Live 2019 では以下のように変わります。

つまり，入出力コード・内部コードがともに UTF-8 になり，オプション無しでも例えば森“?”外や“?”のような「JIS 第1,2水準に含まれない文字」も扱えるようになりました。これに伴い，オプション -U は純粋に入出力コードだけを「明示的に UTF-8 であることを保障する」程度の役割になっています。

3. LuaTeX がバージョン 1.10.0 に（Lua 5.3 へアップデート）

こちらは昨年末の「私と TeX Live と LuaTeX の近況レポート」なる記事で先取りしていた話題ですので，そちらを参照してください。

LuaTeX で日本語を組版する「LuaTeX-ja プロジェクト」のほかにも，TeX 関連ツールの中には，Texdoc，cluttex，llmk など，Lua で書かれたものが幾つもあります。手元で試す限りでは，いずれも Lua 5.3 で正常に動いているようです。

4. dvipdfmx の大規模アップデート

まず，セキュリティ上重要なバグ修正を挙げておきますと，「dvipdfmx でグリフ数よりグリフ名の方が多いフォントを使うと異常終了する問題」が治りました (r50098, r50114)。

このほかにも，dvipdfmx には今年も多くのニッチな改良が入っていますので，順に紹介します。

4-1. ToUnicode CMap 改良で Acrobat のプリフライトを通りやすく，再現性も改善

ものすごく雑に書くと

  1. (x)dvipdfmx が生成する ToUnicode CMap の名前が，不適切な文字（空白など）を含まなくなった。
  2. さらに .notdef 以外のすべてのグリフを CIDSet に正しく登録するようになった。

結果的に，Adobe の Acrobat プリフライト*4を通りやすくなった。同時に，生成する PDF バイナリの再現性も改善した。

ということです。メーリスで関連していた話題を挙げておきます。

以下，どうにか説明を試みますが，PDF の内部構造に絡む話なのでどうしても難解になってしまいます。分からなければ読み飛ばして結構です。

ToUnicode CMap とは，「PDF に表示されている文字が Unicode のどのコードポイントに対応するか」を定義したものです。これは PDF からテキスト情報を取り出す（コピペする）ために欠かせないもので，**(x)dvipdfmx は ToUnicode を生成してPDF に一緒に埋め込むことで，PDF にテキスト情報を持たせます***5。

では，ちょっと実物を見てみましょう。

% xelatex で処理してください \documentclass{article} \usepackage{fontspec} \setmainfont{ipaexm.ttf} \begin{document} ゆきだるま? \end{document}

このソースを xelatex で処理して得られる PDF（例えば test.pdf とします）を，qpdf というツールで読んでみます。

$ qpdf --qdf test.pdf test.qdf

すると test.qdf（p ではなく q です）の中にこんな部分が見つかります（これは TeX Live 2018 の場合の例）。これが ToUnicode CMap の実例です。

begincmap /CMapName /-usr-local-texlive-2018-texmf-dist-fonts-truetype-public-ipaex-ipaexm.ttf,000-UTF16 def /CMapType 2 def /CIDSystemInfo << /Registry (Adobe) /Ordering (UCS) /Supplement 0

def 1 begincodespacerange <0000> endcodespacerange 7 beginbfchar <0014> <0031> <026C> <304D> <027F> <3060> <029D> <307E> <02A5> <3086> <02AA> <308B> <1E03> <2603> endbfchar endcmap

さて，<1E03> <2603> のようなものが対応づけで，左辺が ipaexm.ttf（IPAex 明朝）の中のグリフ番号（GID 7683 = 0x1E03），右辺が Unicode の位置（U+2603 = ?）です。そして

/CMapName /-usr-local-texlive-2018-texmf-dist-fonts-truetype-public-ipaex-ipaexm.ttf,000-UTF16 def

この行が ToUnicode CMap の名前の定義です。ここでは長いですが「/-usr-local-texlive-2018-texmf-dist-fonts-truetype-public-ipaex-ipaexm.ttf,000-UTF16」という名前が付けられています。なんとなく，ファイルパスを基にした文字列が使われていることに気づくのではないでしょうか。実際，TeX Live 2018 まではそのとおりで，

という実装になっていました。フルパスには時々空白文字が入るので，その場合はそのまま不正な CMap の名前になってしまう危険があり，実際にそれが Acrobat プリフライトを通過できない原因になっていた…というのが上掲のメール1件目でした。また，これでは Unix と Windows では当然パスが違い，reproducible なバイナリ生成のネックになってしまう…というのが上掲のメール2件目です。

この両方が一度に解決するのが，「フォントのフルパスではなく，PSName を基に名前をつける」という方策です。実際に，TeX Live 2019 からは「ランダムな6文字*6+PSName」という名前が使われるようになりました (r48418)。例えば

/CMapName /VNYFWO+IPAexMincho-UTF16 def

のような具合です。これで，Acrobat のプリフライトを通りやすくなり，なおかつ reproducible な PDF 生成とも相性が良くなりました。

「.notdef 以外の全てのグリフを CIDSet に含めるようにした」については，私もまだよくわかっていません。r48427 で修正されたらしいことまでは把握しているのですが…。もし「解説は任せて！」という方がいたら教えてください。

4-2. 部首の ToUnicode 問題へのさらなる対策

昨年，「XeTeX で見 (U+898B) を処理すると ??(U+2F92) に化ける」という問題が修正されました。これの続きのようなもので，今回は「長(U+9577) が??(U+2ED1) に化ける」という問題が修正されました。より正確には，このように説明されます。

TeX Live 2018 では「KANGXI RADICALS (U+2F00～2FD5) と字形が一致する漢字」のテキスト情報 (ToUnicode) が漢字を優先するよう対策した。**TeX Live 2019 ではさらに，CJK Radical Supplement (U+2E80～2EFF) と字形が一致する漢字も，同様に優先されるよう対策した**。

この原理については昨年の記事に，KANGXI RADICALS の「見」を例に詳しく説明していますので，そちらを参照してください。

4-3. TikZ の shadows.blur を使った PDF 画像を取り込めない問題の修正

実例で説明しましょう。以下のソースを mwe-graphic.tex として保存し，これを latex + dvipdfmx で処理します。

\documentclass[dvipdfmx]{article} \usepackage{tikz} \usetikzlibrary{shadows.blur} \begin{document} \thispagestyle{empty} \begin{tikzpicture} \drawblur shadowcircle(1); \drawblur shadowrectangle(3,2); \end{tikzpicture} \end{document}

得られた mwe-graphic.pdf を，別のソースファイルから同じく latex + dvipdfmx で取り込もうとすると…

\documentclass[dvipdfmx]{article} \usepackage{graphicx} \begin{document} \begin{center} \includegraphics{mwe-graphic.pdf} \end{center} \end{document}

TeX Live 2018 ではこんなエラーが出て PDF を作れませんでした*7。

dvipdfmx:fatal: Loop in object hierarchy detected. Broken PDF file?

どうやら「オブジェクトの循環参照の処理が正しくなかった」とのことで，TeX Live 2019 では治してくださいました。

この修正には紆余曲折ありました。というのは，この問題への対処が最初に試みられた dvipdfmx version 20180821 から，9/4 に完全に直るまでの間，PDF 画像の取り込みに関して「逆に壊れてしまうケース」があったからです。例えば forum:2609 はまさにこの問題に運悪く当たってしまった例でした。

4-4. dvipdfmx の新しい \special -- pdf:trailerid

PDF ファイルの最後に書き込まれる「trailer 辞書」（例えば「PDF 構文 -ファイル構造(各部)-」などに説明があります）の の ID を自由に指定できるようにする新しいインターフェースとして，\special{pdf:trailerid ?} が新設されました。

使い方については texdoc dvipdfmx で開く公式ドキュメント「The Dvipdfmx User's Manual」を参照してください。

4-5. XeTeX で Noto の直立体と擬似斜体を同時に使うと一方が文字化けする問題の解消

Noto や SourceHan などの Adobe-Identity0 なフォントの謎挙動で，一つのフォントを2回以上，違うシェイプ（例えば直立体とスラント＝擬似斜体）を XeTeX で呼び出した場合に起こっていました。

\nopagenumbers \font\x="[NotoSerifSC-Regular]" at 12pt % 直立体 \font\y="[NotoSerifSC-Regular]:slant=0.2" at 12pt % 同じフォントの擬似斜体 {\x 好} {\y ?好} \bye

のような plain XeTeX ソースを xetex でコンパイルすると文字化けしていたのが直りました。左が TeX Live 2018 の場合，右が TeX Live 2019 の場合です。

f:id:acetaminophen:20190413183536p:plainf:id:acetaminophen:20190413183550p:plain

…これはいつの間にか解消したので，説明は以上です。

まだまだ続きます。