Acetaminophen’s diary

化学に関すること，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 の方々🍣は

をどうぞ。

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

 

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

1. pLaTeX / upLaTeX が新しくなった                    

このブログではもはやお馴染み（？）の話題です。今年もコミュニティ版 pLaTeX / upLaTeX には多くの改善が入りました。

アグレッシブな変更はほぼありませんが、顕著なのは 2017/07/29 の「tabular 環境の表のセル要素周囲に入ることがあった JFM グルーを抑制」でしょうか。詳細は上記のリンクそれぞれに書かれているので参照してください。

 

2. pTeX / upTeX の改良とバグ修正                    

2-1. 縦組の数式でのベースライン補正の修正                    

実は TeX Live 2016 の pTeX/upTeX には、致命的なバグがありました。TeX Live 2015 以前の環境と比べると、縦組で数式を書いたときのベースラインの位置がずれてしまっていたのです。これは、TeX Live 2016 で導入された修正に起因するものです。

復習すると

文中数式モードでは自動的に全体にベースライン補正がかかり，その結果 $\hbox{漢字ABC}$ では「漢字」に一重，「ABC」に二重にベースライン補正が適用される

という挙動を直すために、「ベースラインの戻し量」を定義する 3 つの \〜baselineshiftfactor プリミティブが導入されたのでした。これは横組の数式ではうまく動いていましたが、「縦組で数式を使うと欧文のベースラインがずれる」という困った現象が起きてしまいました。これは縦組での数式は、pTeX において「横組」「縦組」とは異なり「縦数式ディレクション」という別のモードで処理されますが、これを考慮していなかったため、「ベースラインを戻す必要がないボックスを戻してしまい、かえって変になってしまった」のです。

TeX Live 2017 では再び、従来の縦数式ディレクションの挙動に戻りました（ついでに \ifmbox というプリミティブも追加されました）。したがって、「TeX Live 2016 だけ、縦組で数式が予期せぬ出力になるかもしれない」という可能性は気に止める必要があるかもしれません。

2-2. \catcode`〈文字〉=〈数値〉で 2 バイト以上の文字の禁止                    

\catcode とは何かには触れませんが、pTeX / upTeX ではこれらは 1 バイト文字のみに対して「期待どおり」の挙動を示します。2 バイト文字に対して \catcode を設定・読出した場合の挙動は、これまでちゃんと定まっていませんでした。このため、TeX Live のバージョンによっては古くは Segmentation fault したり、それを回避するために JIS ブロックの上位バイト（つまり「区」ごと）にしたり…と変遷がありました。

TeX Live 2017 からは、このような「期待どおりにならない」ケースを避けるため、2 バイト以上の文字への \catcode 設定・読出を完全に禁止してエラーを出すようにしてあります。

上記 2-1. と 2-2. については、昨年 2016 年の北川さんの TeX ユーザの集いでの発表資料 (p.19) でもわかりやすく説明されています。

2-3. \endlinechar=-1 での挙動の修正                    

\endlinechar とは何かには触れませんが、「ソース中での改行の解釈を変えたい場合に使う」とだけ言っておきましょう。pTeX と upTeX が「改行に出会った時にどこまでを文字とみなすか」に絡む処理に問題があったのが直りました。

特に pTeX に至っては、1992 年にすでに一度報告されていたバグ*2で、実に四半世紀ぶりに修正が入ったことになります。

 

3. dvipdfmx の画像取り込みの挙動変更                    

これはフォーラムでも話題になりましたが、TeX Live 2017 リリース時点での変更というよりは「2017 年 6 月の graphics-def の更新に伴う変化」ですが大事なことかもしれないので挙げておきます。

簡潔には「Adobe Illustrator を使って図版を作って PDF 形式で取り込んでいる人は注意しましょう」です。それ以外のユーザにとっては、ほとんど関係のないことです。

従来の dvipdfmx のバウンディングボックス選択律

PDF には 5 つの「バウンディングボックス」（通称 ﾅﾝﾄｶBox）と呼ばれるものがあります。dvipdfmx が PDF を \includegraphics するとき、この 5 つのうちどれが使われるのかは独特の選択律に基づくものでした。

/CropBox → /ArtBox → /TrimBox → /BleedBox → /MediaBox の順に
明示されている最初のものを選択する

このことは、dvipdfmx あるいはその元となっている dvipdfm のドキュメントのどこにも書かれていませんが、特に日本では知名度の高い挙動で、さまざま「研究報告」らしきものが出ていました。

これに対し、pdfTeX や LuaTeX や XeTeX といった他の PDF 画像取り込み機能を持つプログラムは全て「常に /CropBox を使う」（つまり /CropBox → /MediaBox の順に明示されている最初のものになる）という挙動です。これはほとんどの PDF ビューアの見た目と一致して直感的にわかりやすいものでした。

じゃあこれと比べて dvipdfmx はどうなのか？ という議論は時々巻き起こりました。しかし、それは「互換性を重視する」という観点からずっと変わらずに来ていました。

新しい dvipdfmx のバウンディングボックス選択律

しかし、これが 2017 年 6 月に LaTeX team によって破棄され、dvipdfmx でも「常に /CropBox を使う」という仕様に統一されたのです。

とはいえ、この影響はかなり限定的であると思います。というのも、実際問題として

/CropBox と /MediaBox 以外の 3 つのボックスを生成するアプリケーションは
Adobe のソフトウェア（特に Illustrator）くらいしかない

からです（もし他にご存知だったら是非教えてください）。そして、Illustrator 自体にも Creative Suite 6 と Creative Cloud 2015 の間に非互換な変化がありました。

このことから、実用上は「Illustrator で作成した PDF 図版を安全に \includegraphics するには、必ず pagebox=artbox しよう！」というベストプラクティスさえ覚えておけば安全らしいことがわかります。この点に関しては今も変わっていませんので、今後もこの方法を使っていきましょう。

【もっと詳しく】ではなぜ、ここに来て互換性が破棄されたのか？

従来は dvipdfmx.def とか pdftex.def とか*3の「ドライバ専用定義ファイル」は、dvipdfmx や pdfTeX などそれぞれの作者やその継承者によってバラバラにメンテナンスされていました。そして、それらの仕様・挙動がドキュメント化されることは全くありませんでした。

この状況は芳しくないと考えたのが、graphicx パッケージ本体をメンテナンスしている LaTeX team でした。「自分たちがメンテナンスしている graphicx パッケージが実際にどういう動作をするのか予測がつかない」という状態は、気持ちのいいものではなかったのでしょう。結局、すべての「ドライバ専用定義ファイル」が LaTeX team によって引き取られ、すべての機能が精査されてドキュメント化されました（コマンド texdoc graphicx で表示される、grfguide.pdf を参照）。このとき正式にドキュメント化されたものの一つが他でもない pagebox オプションですから、公式のお墨付きを得たと言っても過言ではないでしょう。一方「pdfTeX や LuaTeX と比べて dvipdfmx だけが違うのは変だ」という発想に至るのも、納得せざるをえないと思います。

これで得た教訓があります。

ドキュメント化されていない挙動は「仕様」ではない。

挙動が変わって欲しくなければ、それを「仕様」としてドキュメント化しよう。

ドキュメント化してあれば、もしかしたら LaTeX team も変更に対して慎重だったかもしれません。いくら日本語で LaTeX の入門書や解説記事、研究報告が書かれていても、それが TeX Live のような「誰でもアクセスできる場所」に「誰でも明らかに読める形で」書かれていなければ、そのときどきのメンテナによって変更されてしまう可能性があるのです。ドキュメント化の努力すらせずして、あらゆる変更に対して「互換性が〜！」と言う資格はないのだな、と思い知った瞬間でありました。

【TeX Live 2018 に向けて】ところで、「dvipdfmx / XeTeX」と「pdfTeX / LuaTeX」の間の違いがもう一つありました：「PDF のページを回転したのに*4、それを \includegraphics すると元に戻る」というものです（あるいは、元々予め回転された状態で渡された PDF 画像だった場合には「PDF を \includegraphics すると勝手に回る」という認識かもしれません）。

PDF の内部に /Rotate という回転命令があった場合、ほとんどの PDF ビューアは「/Rotate 命令で回転されているのだから、そのページは回転して表示しよう」とするわけですが、dvipdfmx や XeTeX は /Rotate を無視し、ビューアの見た目と違う「回転前の向きのまま」で取り込むという挙動でした。実際、dvipdfmx が走るときには警告も出ていたので、気づいた人も多かったかもしれません。

これが TeX Live 2018 ではついに、dvipdfmx や XeTeX でも「/Rotate で回転されたページは回転して取り込む」という仕様に変更されました (r44963, r44964)。したがって、TeX Live 2017 でのバウンディングボックスの変更と合わせると

TeX Live 2018 では PDF のページがビューアの見た目のまま
（向き・バウンディングボックス共に）\includegraphics できる

と胸を張って言うことができるようになりました。幸せですね。

 

4. dvipdfmx / dvips の用紙サイズ設定の挙動変更                    

TeX には「用紙サイズ」という概念がない、とはよく知られた話だと思います。実際、DVI ファイルのネイティブな機能としては、用紙サイズに対応する概念がありません。しかし、PS や PDF を表示・印刷するときにはほとんどの場合、用紙サイズが必要になります。そこで dvips と dvipdfmx の場合は

  • TeX ソース中に\AtBeginDvi{\special{papersize=100pt,200pt}} のように書く（あるいは、それと同等の機能を持つ LaTeX パッケージを使う*5
  • コマンドで dvips の -T オプションあるいは dvipdfmx の -p オプションを使う

ことで、出力される PS / PDF の用紙サイズを規定できるという仕様でした。ところが、ここで問題がありました。

\special 命令が複数書かれていた場合、あるいはそれらと
コマンドオプションが併用された場合の用紙サイズは？

これについても、研究報告のようなものが出ています。

TeX Live 2017 では dvips の優先順位と dvipdfmx の優先順位に変更が生じました。

まず、dvips の場合です。複数の papersize special が見つかった場合、従来はそのうち「最初のもの」が有効でした。新しい dvips では、複数の papersize special のうち「最後のもの」が有効になり、さらにコマンドの -T オプションが勝つようになりました (r42420, r42461, r43362) 。

次に、dvipdfmx の場合です。従来は、papersize special が最強で、それがない場合だけコマンドの -p 等のオプションが効くという挙動でした。新しい dvipdfmx では、papersize special よりもコマンドの -p オプションの方が強い効力を持つようになっています (r43367) 。

要するに、従来は「先にやったもん勝ち、逃げ切り！」だったのが、新しく「後からも用紙サイズを変えられる」という柔軟性が生まれたことになります。互換性がないといってしまえばそれまでですが、用紙サイズ指定機能を提供するパッケージが激増してきた最近の流れに合っているのではないかと思います。

 

5. fmtutil と updmap の user モードと sys モードの分離                    

fmtutil や updmap と聞いて、何のことだかわかるでしょうか。（仮にどこかでコマンド名を見たことがあったとしても、）実際に何をしているのか理解している方はそれほど多くないようです*6。そんなとき、ググった情報をもとに -sys なしの fmtutil や updmap を実行してしまうと…？ これが困ったことに、「いくら TeX Live をアップデートしても、肝心な一部分だけ更新が反映されない」という問題が起きていました。この肝心な部分とは「フォーマット」や「マップファイル」と呼ばれるもので、pLaTeX とか upLaTeX とか LaTeX とか LuaLaTeX …とかの本体や、フォントの割り当ての定義（日本語フォントにヒラギノを割り当てる、とかもその一種です）です。

…というのが、TeX Live 2016 までの現象でした。あまりにもこのような質問が掲示板に溢れたため、今回重大な決断がなされました。それは

TeX Live 2017 では「fmtutil」「updmap」というコマンドが封じられ、
今後は「fmtutil-sys」「updmap-sys」を使うことになった。

ということです。このことが、TeXConf 2017 のノルベルトさんの講演の一つの趣旨でしたね。

では、そんな危険な fmtutil や updmap というコマンドがググると出てくるのはなぜか？ ここには歴史的事情が絡んでいますので、もう少し詳しく見てみましょう。

【もっと詳しく】ユーザ用とシステム用の違い

話は fmtutil と updmap が TeX Live に登場した頃に遡ります。これらのコマンドは TeX の動作に欠かせない作業を担うため、ユーザが使いたい場合もあれば、TeX 一式のシステム導入・更新でももちろん使われます。コマンドが登場した当時は、ユーザもシステムも、同じ TEXMF ツリーにある同じフォーマットファイル・マップ設定ファイルを変更していた平和な時代でした。

時は流れ、「ユーザ用」「システム用」の TEXMF ツリー (TEXMFVAR / TEXMFSYSVAR) が分離されました。システムの設定はシステムに任せ、ユーザのカスタマイズはそれに打ち勝つように、という思想は、ある程度理解できると思います。

ところが、混乱は各 TEXMF ツリーを更新するためのコマンドとして準備された fmtutil と updmap の「ユーザモード (user mode)」「システムモード (sys mode)」に端を発します。TEXMF ツリーが分離されたので、コマンドも分離されるのはまあ自然な発想でしょう。ところがどういうわけか、従来のコマンド名「fmtutil」「updmap」はユーザ向けとされ、システム向けには新設された「fmtutil-sys」「updmap-sys」が使われ始めたのです。一見、ユーザが実行する名前は今までと同じなので受け入れやすい…かと思いきや…！ これには

一度でもユーザモードで fmtutil を実行してしまうと、それ以降は TeX Live システムを更新するたびに、前回のユーザモード実行で作られたフォーマットを手動で全削除するか、あるいは更新の都度ユーザがコマンドを実行し直すかしない限り、古い状態の「ユーザ向けフォーマット」が居座り続ける

という罠がありました。要するに、例えば

pLaTeX に不具合があって tlmgr update で更新したのに、以前一度だけ fmtutil が走ってしまったがために、更新後の pLaTeX が反映されず、バグがなくならない

ということです。（意図せずに fmtutil が走ってしまって pLaTeX が更新されなかったという事例は、昨年も forum に出ていました。）

昔は単純に fmtutil や updmap でよかったため、その頃の解説サイトがいまだにはびこっています。いつまで経ってもこの手のトラブルが絶えないという状況を一掃するため、TeX Live 2017 では「ユーザモードなのかシステムモードなのか意識せざるを得ない状況を作った」といえるでしょう。

 

6. dvipdfmx のドキュメント登場、OpenType フォント対応増強                    

これは非常に嬉しい機能増強です。dvipdfmx には今まで公式ドキュメントがありませんでしたが、TeX Live 2017 に合わせて、dvipdfmx 原作者の一人である平田俊作氏によるマニュアルが作成されました。

TeX Live 2017 以降では、コマンドで texdoc dvipdfmx とするとこのマニュアル (The dvipdfmx User's Manual) を読むことができます。dvipdfmx がサポートしている \special 命令や、挿入をサポートしている画像形式など、簡潔ではありつつも例を交えつつわかりやすく書かれています（もちろん英語）。

そして、このマニュアルにも書かれているとおり、TeX Live 2017 では OpenType 形式のフォントの様々な機能を dvipdfmx で活用できるようになっています。

pLaTeX/upLaTeX ユーザが簡単に使えるインタフェースとしては、PXchfon パッケージがこの機能を早速活用しています。最近話題の源ノ角ゴシック (Source Han Sans)／Noto Sans CJK や源ノ明朝 (Source Han Serif)／Noto Serif CJK のような「Adobe-Identity0 な OpenType/CFF フォント」が使える、という特徴を活かした機能ですね。

【TeX Live 2018 に向けて】現状の TeX Live 2017 の dvipdfmx では、「ある一つのフォントに対して、付けられる OpenType Layout は一つまで（複数つけた場合は最後の一つだけが有効）」など、いくつかの制約（バグ？）がありました。

この制約は 2017 年 9 月の修正 (version 20170918) までに（報告された範囲では）すべて取り除かれた (r44689, r45330) ため、TeX Live 2018 では複数の OpenType Layout を与えることができます。

また、現時点の ptex-fontmaps（旧称 jfontmaps）では、kanji-config-updmap(-sys,-user) で sourcehan / noto を既定にすることはできません。将来的にはこれもできるようにしたいところですが、上記の dvipdfmx の問題点が TeX Live 2018 が出るまでまだ直らないこと、また TeX Live 本体に含まれる updmap というスクリプトの機能を拡張しないといけないことなどの事情から、もう少し時間がかかりそうです。

 

7. Ghostscript の日本語など対応の改善                    

日本語の PDF を作る方法は、今でも pLaTeX / upLaTeX + dvipdfmx が大多数のようです。一方で、pLaTeX / upLaTeX + dvips + ps2pdf (gs) という手段も、一部では好まれているようです。Ghostscript (gs) はしばしば TeX と組み合わせて使われますし、TeX Live win32 版には「TeX Live 用にカスタマイズされた Ghostscript (tlgs.win32)」が標準で付いてきたり、MacTeX にも同梱されていたりします。

Unix 環境を考えれば、「Ghostscript で日本語を使うためのセットアップ」は、cjk-gs-integrate というスクリプト（元々は Norbert Preining さんによる、現在は日本語 TeX 開発コミュニティが管理）の登場によって格段に向上しました。TeX Live 2017 では、この cjk-gs-integrate が Windows でも使えるようになりました！

コマンドプロンプトを管理者権限で起動し、以下のコマンドを実行してみてください。Mac など Unix ユーザの方はターミナルから（必要に応じて sudo 付で）実行した経験があるかもしれないアレです。

> cjk-gs-integrate --link-texmf --force

これだけで、Ghostscript の日本語・中国語・韓国語フォント設定が完了します。

注意 1：このコマンドでサポートしているのは「ptex-fontmaps（旧名 jfontmaps）に含まれる kanji-config-updmap(-sys,user) のマップで埋め込まれる可能性のあるフォント + α」です。もし他のフォントも Ghostscript で使いたい、という要望があれば、私または cjk-gs-integrate resository (GitHub) までリクエストしてください。
注意 2：一度 cjk-gs-integrate --link-texmf --force を実行したあと、設定をやり直したくなった場合は、一度 cjk-gs-integrate --link-texmf --remove --force を実行してから、再度（管理者権限で）cjk-gs-integrate --link-texmf --force を実行すれば成功すると思います。

【もっと詳しく】Ghostscript (tlgs.win32) の新しいバージョンについて

従来の TeX Live 2016 の tlgs.win32 にも、日中韓フォントサポートは一部含まれていました。それは「あらかじめ Windows 標準の TrueType フォント (.ttf/.ttc) や TeX Live のフリーな IPA/IPAex フォントを、Ghostscript が見つけられるようにマップで設定する」というものでした。しかし、この方法は日中韓フォントサポートとしては不十分でした。というのも、ユーザが後からフォントを追加する手段が限定的だったからです。

  1. TeX Live 2016 の途中で追加されたフリーで TrueType な中国語フォント arphic-ttf や韓国語フォント baekmuk はマップに含まれていない。
  2. TeX Live に数年前から含まれていたフリーで OpenType な簡体中国語フォント fandol を追加できない。

前者は少しの手作業でマップを追加すれば対処可能ですが、後者は深刻でした。従来の tlgs.win32 では、OpenType な日中韓フォントを Ghostscript で使う手段が完全に封じられていたのです。要するに、ヒラギノフォントやモリサワパスポートを購入しても、それを dvips + ps2pdf (gs) で PDF に埋め込むことができないのです。

この制約の原因は、Ghostscript のビルド方法にあります。Ghostscript を Windows 用にソースからビルドすると、既定では Resource というディレクトリがバイナリに built-in されることになっています*7。Resource 以下には CMap や CIDFont、Font や Init などのフォント設定ファイルが含まれており、これがバイナリに含まれるということは「バイナリを自分でリビルドしないと、新しいフォント設定を追加できない」ということになるのです。この問題を避けるため、角藤さんが W32TeX のサイトで配布していらっしゃる Ghostscript win32 バイナリは、Resource をビルドせず保持し、後から自由にユーザが変更できるようにしてあります。

そこで、TeX Live 2017 pretest の期間中に Reinhard にお願いして、角藤さんがビルドした Ghostscript のバイナリを tlgs.win32 に取り込んでいただきました*8。

これで、ユーザが自由に OpenType フォントを使う設定をできる下地が整ったのです。これを活用したのが、先述の cjk-gs-integrate の win32 サポート版です。

 

8. LuaTeX がバージョン 1.0 になった                    

改めて説明するまでもないと思います。ただし、TeX Live 2015 → TeX Live 2016 では莫大な非互換な変更が入れられたのに比べ、TeX Live 2017 でついにバージョン 1.0 となったことから、安定性が高まったと期待できます。これから急速に、LuaTeX の先進的な機能を利用する周辺パッケージの整備が進むことでしょう。

 

9. e-(u)pTeX の新しいプリミティブ（乱数・秒単位の時刻）                    

「乱数を生成するためのプリミティブ」と、そのついで*9に「現在時刻の秒単位まで取得するプリミティブ」が e-pTeX に追加されました。これはもともと「LaTeX3 (expl3) で乱数生成できたらいいね」というトピックがきっかけで実装されたものです。そういえば、LaTeX3 については TeXConf 2017 で素晴らしい講演がありましたね！

e-pTeX に導入された新しいプリミティブについては、texdoc eptexdoc で読めるドキュメントにこの説明があるほか、もともと pdfTeX で実装されたものを借りてきたものですから、pdfTeX のドキュメントも参考になるでしょう。

【TeX Live 2018 に向けて】実は乱数生成プリミティブはどうやら真の「乱数」にはなっていないようです。実際、「種」になる数字によっては常に偶数を生成する現象が知られています。

これに対する解決はまだ示されていません。今後に期待です。

 

10. deterministic な出力の環境変数名の変更                    

TeX Live 2016 から注目してきた最近の潮流です。復習すると、例えば

  • SOURCE_DATE_EPOCH=1486439625 のように環境変数を設定すると、TeX で処理した時刻*10が固定されて毎回同じ出力が得られる。
  • 上記に加えて SOURCE_DATE_EPOCH_TEX_PRIMITIVES=1 を設定すると、\year, \month, \day という「年月日を表すプリミティブ」（これは LaTeX の \today で使われます）まで固定できる。

という仕様でした。このうち後者、すなわちプリミティブを固定する環境変数の名称が変更され、FORCE_SOURCE_DATE=1 のように書くことになりました。

【TeX Live 2018 に向けて】これで終わりかと思いきや、TeX Live 2017 リリース後に、pdfTeX などで「ソースファイルを置くディレクトリの名前によって出力がバイナリ一致しない」という現象が報告されました。

これは、PDF の内部構造の ID 値の決定にファイルのフルパスが使われていたためで、これでは、せっかく全く同じ環境変数を設定していたとしても

  • Windows の人と Linux の人ではパス名が違うのでバイナリ一致しない
  • ユーザ名が違うとバイナリ一致しない

といった制約があることになります。そこで、フルパスではなくファイル名だけから ID 値を決定するように変更がなされました (r45808) 。

 

11. pdfTeX で /MediaBox がダブルで書かれる問題の解消                    

10 個で終わるはずでしたが、そういえばと思い出したのでもう一つ。

昨日は pdfTeX でアノテーションをつける話題でしたが、pdfTeX にはたくさんの便利なプリミティブがあって、その中に「PDF の ﾅﾝﾄｶBox を自由に書き換える」というものがありました。この機能を使えば、例えば「/CropBox と /ArtBox と /MediaBox を持つ PDF」などを好きなように作ることができたのでした。

  • 実例：ZR さんによる「PDF の ﾅﾝﾄｶBox」のテストケース

ところが、pdfTeX にはこれとは独立に「常に各ページに対して自分で /MediaBox を書き込む」という挙動があります。そこにユーザがプリミティブを使って新たな /MediaBox を書き込んだとしても、「pdfTeX が自分で書き込んだ /MediaBox」と「ユーザが作った /MediaBox」が共存してしまう、という問題がありました。

これは不便だ、ということで、2017 年 2 月の議論を経て「pdfTeX はユーザが与えた /MediaBox が有効な場合は、そのページに /MediaBox を書き込まない」という挙動になりました。

 

以上、駆け足ではありますが、TeX Live 2017 での変更点・注意点の見どころでした。TeX Live 2018 でもすでにいくつかの変更が予定されていますので、これについてはまたの機会に。Happy LaTeXing!

*1:これは pLaTeX の問題というよりは pTeX の問題でしたが、単に issue が pLaTeX のところに立っているだけです。

*2:非常に歴史のある大島先生の FTP サーバに残っている tex17p1.tar.gz の中に、bugtest.tex というファイルが入っています。

*3:\usepackage[ホゲホゲ]{graphicx} とかする「ホゲホゲ」の部分はこのような ホゲホゲ.def を読み込むためのオプションです。

*4:例えば pdftk や Adobe Acrobat などの PDF の「ページを回転」するツールがあります。

*5:有名なものとしては、(1) jsclasses の papersize オプション (2) bxpapersize パッケージ (3) bounddvi パッケージ（platex-tools バンドル） (4) geometry パッケージ (5) graphicx パッケージの 2016 年以降のもの があります。一昔前までは「用紙サイズを設定するだけのパッケージ」はありませんでしたが、bxpapersize パッケージを皮切りに、これだけの選択肢ができました。

*6:念のため、fmtutil は「フォーマット」つまり LaTeX とか pLaTeX とか upLaTeX とか LuaLaTeX とかの基本的な命令群を .fmt という単一のバイナリファイルにダンプして効率化するためのコマンドで、updmap は TeX が使ったメトリック (TFM) から実際のフォントへの割り当てを定義したマップファイルを追加・更新するコマンドです。

*7:Unix で Ghostscript (gs) を apt-get や port などのパッケージ管理でインストールした場合は、Resource がバイナリにビルドされることはなく保持されるようです。

*8:従来の tlgs.win32 は、実はなんと Reinhard さんが Unix 環境で Win32 用にビルドしたバイナリ」でした。そういうわけで、Resource 云々の問題はそれまで認知されていなかったようです。

*9:一般に、コンピュータでの乱数生成には現在時刻を使うためだと思います。

*10:よく PDF のプロパティに入っている「 TeX Output 2017.08.08:0808」みたいなものや、PDF のオブジェクト番号などがこれをもとに決定されています。