Acetaminophen’s diary

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

pTeX のペナルティを LuaTeX-ja で試してみた

これは TeX & LaTeX Advent Calendar 2019 の 15 日目の記事です。昨日は hak7a3 さんでした。明日は keisuke495500 さんです。

今年は残念ながら TeXConf 2019 が中止になってしまいました。私は「pTeX のペナルティ」という題目で一般講演を申し込んでいたのですが,発表スライドを使う予定がなくなったのでここで公開します。

…さて,TeXLaTeX Advent Calendar 2019 の重点テーマは「とにかく Lua(La)TeX しよう」です。pTeX ではありません。というわけで,先のスライドと同じことを LuaTeX (LuaTeX-ja) でやってみるとどうなるか,試してみることにしましょう。

f:id:acetaminophen:20191215120823p:plain

おことわり:本稿はあくまで実験結果で,何らかの結論を導くものではありません。「ただやってみた」という程度に捉えてください。

 

続きを読む

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

前回の続きです。

 

5. pTeX の仕様変更:\inhibitglue の有効範囲の変更            

これは TeX Forum でも告知した件ですが,再掲しておきます。

新仕様では,以下のように \inhibitglue の有効範囲が変わります。

  1. \inhibitglue は,その後にノードが挿入されると無効化する。つまり,\null や \hskip や \kern や \vrule といったノード挿入では必ず無効化される。
  2. \inhibitglue は,ノードを挿入しない処理であれば透過する(無効化しない)。つまり,\relax や \let\A\B や数値代入では無効化されない。
  3. \inhibitglue の効果は他のリストに波及しない。つまり,あるボックスの中で発行された \inhibitglue は,その外側には影響しない。
  4. \inhibitglue を無効化する \disinhibitglue という新プリミティブの追加。これは,上記 2. により \relax などが \inhibitglue を無効化しなくなったので,「効きすぎて困った」という場合の対策として使えることを想定。

詳細は上につけたリンク先 forum:2566 に説明したとおりです。

 

6. e-pTeX\pdfsavepos の改良,\readpapersizespecial の新設            

ページ内の現在位置を保存する \pdfsavepos と,それを取得する \pdflastxpos / \pdflastypos に関する改良です。

この座標の原点位置は「ページの左下隅」ですが,より詳細には \pdfpagewidth / \pdfpageheight に応じて決まります。しかし,DVI を経由する e-pTeX では,これらの寸法はゼロになっており,原点位置を設定することができません。そこで,e-pTeX では

papersize special を読み取って \pdfpagewidth, \pdfpageheight を設定する

という,pdfTeX にはない特殊な決まりがありました。e-pTeX バージョン 180901 以降では,この特殊仕様を無効化できるように,\readpapersizespecial というプリミティブが追加されました

\readpapersizespecial
内部整数値で,値が正であれば papersize special を読み取る。ゼロ以下ならば読み取らない。後方互換のため,既定値は 1(読み取る)。

また,「縦組の場合」や「\mag が使われた場合」に,原点位置が誤って計算されてしまうという問題がありましたが,同時に修正されました。

 

7. upTeX 1.24 で Latin Extended-B と Latin Extended Additional をデフォルトで欧文扱い            

昨年の TeX Live 2018 において,upTeX 1.23 で仕様変更が行われ

  • Latin-1 Supplement のうち Latin-1 Letters (U+AA, U+BA, U+C0..D6, U+D8..F6, U+F8..FF)
  • Latin Extended-A (U+0100..017F)

がデフォルトで欧文扱いになりました。TeX Live 2019 の upTeX 1.24 ではさらに,

  • Latin Extended-B (U+0180..024F)
  • Latin Extended Additional (U+1E00..1EFF)

も欧文扱いになりました。

この変更は,最新の inputenc パッケージ(2018年7月以降)がサポートする Unicode 文字の範囲が広がったことに刺激されたものです。

この v1.24 では,このデフォルト値の変更作業中のミスでバグが混入してしまいました(参考)。v1.25 では修正され,しかも特に critical なバグであることから,TeX Live 2019 の期間中であるにもかかわらず,例外的に多くのプラットフォームでバイナリのリビルドが行われました。

 

8. pdfTeX / e-(u)pTeX / XeTeX の新プリミティブ「\expanded」               

いかにも TeX 言語っぽいプリミティブ名です。今回追加された新しいプリミティブ \expanded は,展開可能なマクロの定義に便利なものです。TeX 言語プログラミングではしょっちゅう,悪名高い(しかし一部の人🍣が大好きな)展開制御の「\expandafter 体操」の必要に迫られますが,\expanded があればそれが少々簡略化できる,というわけです。

LuaTeX には相当昔から存在したプリミティブですが,TeX Live 2019 では pdfTeX,e-pTeX,e-upTeX,XeTeX にも新たに \expanded が追加されました

機能説明は別の誰かに譲ることとして,ここでは \expanded の少々特殊な歴史をば少し:現在,pdfTeX はバージョン 1.40.? と付けられています。今でこそ pdfTeX は機能追加もほとんどなく,バグもほとんど発生しないという「安定」ですが,今から10年ほど前(2008年頃)までは pdfTeX にも新機能追加を目指した開発が行われていました(開発場所)。これは将来バージョン 1.50 としてリリースされるはずだったのですが,次第に開発者が離れてしまって現在に至ります。その 1.50 で追加される予定だったプリミティブの一つが \expanded でした*1

 

9. XeTeX:新しい pdfTeX 互換プリミティブ,\UCharcat の拡張               

今年から,XeTeX でも pdfTeX と同様のプリミティブが沢山使えるようになりました。ただし,従来の XeTeX 流の命名規則に則り pdf〜 の接頭辞を取ってあります。幾つかは TeX で乱数を使うために有用ですね!

\creationdate, \filedump, \filemoddate, \filesize \elapsedtime, \resettimer, \normaldeviate, \uniformdeviate, \randomseed

また,\Ucharcat プリミティブにも機能拡張が入っています。

これらはいずれも,LaTeX3 team がリクエストしたものです。「新しいプログラミング言語 expl3 を強力なものにするため,足りない機能を追加していく」という流れは今後も続くのではないかと思います。

 

10. pdfTeX の新プリミティブ \pdfomitcharset                

「dvipdfmx で作った PDF」が Acrobat のプリフライトを通りやすくなった件を先ほど書きましたが,「pdfTeX で作った PDF」にも改良が入りました。

簡潔には,「/CharSet が不完全で PDF/A として不正になってしまう場合に,\pdfomitcharset プリミティブを発行すれば PDF に /CharSet を書き出さないようにできる」ということのようです。

 

11. MetaPost の制限版 r-mpost コマンドの追加                            

2016年11月28日に,制限付きシェル実行 (restricted shell escape) に関連するセキュリティホールが見つかったことを記憶している方もいるかもしれません。

これ以前は,MetaPost の起動コマンド mpost が shell_escape_commands リストに登録されていました。しかし,上記のセキュリティホールが見つかり,即日 mpost はこのリストから外されてしまいました。結果的に,例えばみなも氏の MePoTeX パッケージなどが(-shell-escape なしには)使えなくなってしまいました。

これは困った… というわけで,MetaPost 本体に改修が入りました。

  1. TeX Live 2017 で,MetaPost に「外部コマンド起動を抑制する -restricted オプション」が追加された。
  2. TeX Live 2019 で,「r-mpost」というコマンドを実行すると「mpost -restricted」と同じ意味を表すことになった。

新設されたコマンド名は以下の通りです (r49614, r49616)。

  • 制限付 mpost →「r-mpost」
  • 制限付 pmpost →「r-pmpost」
  • 制限付 upmpost →「r-upmpost」

このうち「r-mpost」は texmf.cnf の shell_escape_commands にも追加され (r49551),晴れて再び TeX から MetaPost を r-mpost という名前で呼び出せるようになりました。

余談:TeX Live にはいくつか「r」を頭につけて「制限付き」を表すことにしたコマンドが存在します。
  • epstopdf → repstopdf
  • pdfcrop → rpdfcrop
この慣例とは異なり,今回の mpost 系列では「r-」という接頭辞が付いていますので注意してください*2

 

12. dvisvgm が PDF → SVG 変換をサポート                            

DVI を SVG に変換するツール dvisvgm は,割と新しい SVG 画像作成ツールで,名前の通りメインは DVI → SVG 変換ツールです。pTeX で日本語文字が出てくる DVI も変換できるほか,EPS → SVG 変換もサポートしていることが知られています(過去記事も参照)。

TeX Live 2019 には,dvisvgm 2.6.3 が収録されています。この新しいバージョンで, PDF も入力ファイルに指定できるようになりました(v2.4 で新設)。つまり,dvisvgm を新しい PDF → SVG 変換ツールとして使うことができます

通常の DVI 入力の場合はコマンドが dvisvgm hoge.dvi ですが,PDF 入力の場合は dvisvgm --pdf hoge.pdf とします。あるいは,長いオプション --pdf を短縮形 -P で代替することもできます。入力する PDF は複数のページを含んでいても問題ありません(v2.5 でサポート)。残念ながら,「マルチページ PDF をアニメーション SVG に変換」ということはできないようです。この用途には WindowsmacOS 向けアプリケーションである TeX2img を使いましょう

 

13. 新しいツール:dvispc と chkdvifont と ctwill                            

Windows ユーザの方は,dviout という DVI ビューアを知っているかもしれません。大島先生が開発された歴史あるビューアで,高機能のため,WindowsTeX Live に収録されている唯一の DVI ビューアです。実は,この dviout にはビューア本体の他に,いくつかの「単体でも便利なツール」が一緒に含まれています。そのうちの2つが,dvispc と chkfont でした。

  • dvispc:バイナリである DVI とテキストファイルを相互変換する機能,DVI に使われている色指定の \special がページをまたぐ場合に修正する機能などを提供するプログラム。
  • chkfont:DVI でどんなフォント(正確には TFM ファイルの名前)が使われているかを表示するプログラム。他に,TFM ファイルや PK ファイルなど,TeX 特有のフォント形式のファイルを読み取り,基本的な情報を表示することができる。

これまでも,TeX Live の Windows 版にはこっそり含まれていたのですが(c:/texlive/2018/tlpkg/dviout の中の dvispc.exe と chkfont.exe がそれです),もっと Windows 以外の人にも使えるようにということで,TeX Live で正式に全てのプラットフォーム向けにビルドして配ることにしました(それを機に,chkfont は chkdvifont に改名されました)。機能の詳細については,それぞれ dvispc-ja.txtchkdvifont-ja.txt を参照してください。

ctwill というのは,CWEB 関係のなにかのようです。CWEB と聞いてピンと来る人は見てみるといいかもしれません。 → cwebbin

 

14. dviconcat で縦組を含む DVI の ID を必ず 3 に                            

これは,昨年 dviselect などを pTeX に対応させた際の考慮漏れによるバグでした。

通常の TeX が出力する DVI では ID が 2 ですが,pTeX には「DVI の中でどこか一箇所でも組方向変更する場合は,識別のため ID を 3 にする」という仕様が存在します。これに従わないと,dvipdfmx などが DVI を解釈するときにエラーをします。

ところが,昨年 pTeX に対応したつもりだった dviconcat で,最後に結合される DVI が横組だけの場合に誤って ID を 2 にしてしまうバグが見つかったので,今回 TeX Live 2019 では修正されています。

 

15. kanji-config-updmap(-sys) で noto / sourcehan サポート                            

TeX Live 2019 では,Noto Serif CJK / Noto Sans CJK あるいは源ノ明朝・源ノ角ゴシック (Source Han Serif / Source Han Sans) を kanji-config-updmap(-sys) で設定できるようになりました。ただし,サポートは完全ではありません

これらのフォントをデフォルトで埋め込む場合は,下記のコマンドを実行します。

  • (sudo) kanji-config-updmap-sys noto: Noto の OTF 版
  • (sudo) kanji-config-updmap-sys noto-otc: Noto の OTC
  • (sudo) kanji-config-updmap-sys sourcehan: Source Han の OTF 版
  • (sudo) kanji-config-updmap-sys sourcehan-otc: Source Han の OTC

ただし,以下の通り制約があります

  • 使えるのは upLaTeX + dvipdfmx だけです(つまり,pLaTeX では使えませんし,dvips を経由する場合も使えません)。さらに,upLaTeX + dvipdfmx であっても,クオート(ダブルクオート“”やシングルクオート‘’は使えません
  • OTF パッケージが提供する命令については,\UTF は使えますが,\CID は使えません。また,\aj~シリーズの一部や,横組み専用・縦組み専用仮名 (expert) やルビ専用仮名も使えません
  • 上記「使えません」は,現時点では,表示されない或いはエラーになるというわけではなく,フォントが非埋め込みになります。

おおざっぱな書き方のため,他にも多くの機能上の制約が存在すると思います。この点に注意してお使いください。これらの機能上の制約は,pxchfon パッケージを使うことで一部解消しますので,当方としてはこちらをお勧めします。

 

16. その他                      

細かい修正です。

  • makejvf で明らかに間違った使い方を禁止
    • 和文 VF を作るために使う makejvf ですが,その使い方が誤解されるケースが時々ありました。例えば,makejvf jis jis のように,第一引数と第二引数を同じにすることはあり得ません((なぜだか分からない場合は,和文 VF の存在意義を考えてみてください。makejvf のマニュアル texdoc makejvf もヒントになるでしょう。))。TeX Live 2019 の新しい makejvf では,このような「明らかに間違った使い方」を封じて,エラーを出すようにしました。
  • upBibTeX がフリーズする問題の修正

 

駆け足でしたが,私が把握している変更点は以上です。

*1:pdfTeX の後継とされる LuaTeX に \expanded がもともと存在したのも,この日の目を見なかった pdfTeX 1.50 の影響だと考えられます。

*2:ちなみに発案は私です;-) → ここ

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

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

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

目次

 

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

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

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

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

  • pLaTeX 標準の jarticle, jbook, jreport, tarticle, tbook, treport
  • upLaTeX 標準の ujarticle, ujbook, ujreport, utarticle, utbook, utreport
  • jsclasses の jsarticle, jsbook, jsreport
  • jlreq クラス
  • babel パッケージの japanese オプション
  • LuaTeX-ja の ltjsarticle, ltjsbook, ltjsreport, ltjarticle, ltjbook, ltjreport, ltjtarticle, ltjtbook, ltjtreport

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

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

 

*1:マクロツイーターの記事の時点 (2019-04-06) では対応版がリリースされていなかったものについても,その後このように対応が進みました。

続きを読む

私と TeX Live と LuaTeX の近況レポート

これは TeX & LaTeX Advent Calendar 2018 の 9 日目の記事です。昨日は CareleSmith9 さんでした。明日は wtsnjp さんです。

おことわり

重点テーマにあまり関係しない記事です。TeX & LaTeX Advent Calendar 2016 の記事の続きのような感じですが,どうぞお付き合いください。

目次

日頃やっていること                      

TeXConf 2018 の懇親会の席でリクエストを受けたので,この辺の話を書いてみます。

私は 2017 年に TeX Live チームにも入りました。「TeX Live チーム」の定義が明確ではありませんが,ここでは以下のように定義することとし*1,私は一つ目に該当します。

以下のいずれかの条件を満たす開発者を「TeX Live チーム」とみなす。

さて,TeX Live チームの一員になって以降,私は以下のような活動をしています。すべて毎朝一回,お出かけ前に必ずやることです。毎日やっていれば,大体 15 分くらいで終わります(溜め込んでしまうとむしろ訳が分からなくなり,余計に時間がかかってしまいます)。

  1. TeX Live の subversion をチェックする。具体的には,ブラウザから Log of /trunk を訪問し,その日の変更内容を見る。
  2. W32TeX の [ChangeLog] をチェックする(ほぼ常に TeX Live と同期しているので軽く眺める程度)。
  3. 購読している TeX Live 関連のメーリスの配信を読む。具体的に特に重視するのは以下:
  4. GitHub にログインして https://github.com/ を訪れ,All activity を見る。TeX Live チームの一員であると同時に,2015 年から日本語 TeX 開発コミュニティの一員でもあるという立場上,特に注意して見るのは以下:
    • texjporg, TeX-Live 以下の全てのリポジトリ(当然)。
    • latex2e: LaTeX2e の開発元。
      → ここ,ちゃんと見ないと例えば「LaTeX が変わると pLaTeX が動かなくなる」という問題(例えばこんなの)が起こるので,極めて重要です。
    • latex3: LaTeX3 (expl3) の開発元。
      → expl3 という新しい言語は,それを使うだけで pdfLaTeX / XeLaTeX / LuaLaTeX / pLaTeX / upLaTeX の違いを考えずに済む「クロス・エンジンなコード」が保証されることを理念に掲げています。しかし,それをマクロで実現するためには「全てのエンジンに必要な機能が揃っている」ことが必須です。そこで例えば「足りない機能を e-pTeX と XeTeX に追加したい」という提案が出ることがあり*3,その動向からは目が離せません。
    • graphics-def: graphicx パッケージのドライバオプション(\usepackage[dvipdfmx]{graphicx} とか)の開発元。
      2017 年のバウンディングボックスの仕様変更をいち早く事前につかめたのも,ここを watch しているからです。

あとは,暇を見つけて(毎日ではない)TwitterTeX Live 関連,W32TeX 関連のツイートが流れていないか探す。ここは,どういうワードで検索フィルターをかけるかがノウハウになってきます…。

そして,何か気になる変更があったら覚えておいて,帰宅後に $ git pull なり $ svn update なりして取ってきます。特に,TeX Live subversion の Build/ 配下に気になる変更があったら,ビルド*4して試してみます。だいたい,週に1回か2回はビルドを走らせます。その結果,特に問題なさそうならそのままですが,もし何か日本で関心がありそうな変化があれば(この判断も経験がものを言います),TeX Forum あるいは GitHub の関連する場所で周知を図ります。

 

最近の LuaTeX の動向                      

今年の Advent Calendar の重点テーマが「とにかくLua(La)TeXしよう」なので,ここから無理やり LuaTeX っぽい話に移ります。とはいっても,LuaTeX を使う話ではなく,ここまでの流れと続く「LuaTeX を使えるようにする側」の話をします。

さて,TeX Live 2018 がインストールされている環境では

$ luatex hoge.tex
This is LuaTeX, Version 1.07.0 (TeX Live 2018)

と表示されます。現在の TeX Live subversion にある最新版をビルドしてみると

$ luatex hoge.tex
This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev)

と出てきます。そして,LuaTeX の roadmap によると

Version 1.10
This will be the TeXLive 2019 release. (後略)

というわけで,TeX Live 2019 では LuaTeX 1.10.0 になると思われます。数字だけみると大したことはない違いに見えますが,これが結構大きな影響かもしれない,という話をします。

Lua 5.2 → 5.3 に完全移行                      

今年 4 月の記事にも書いていた予定では

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

でしたが,これは着実に遂行されています。LuaTeX のソース (experimental) は今日現在,LuaTeX 1.09.1 になっていて,これは既に Lua 5.2 ライブラリが削除され,Lua 5.3 に一本化されています。私は Lua に詳しくはありませんが,Lua 5.3 のマニュアルにも 8. Incompatibilities with the Previous Version として Lua 5.2 → Lua 5.3 での非互換な変更が列挙されています。TeX Live にあるパッケージは対応が間に合うのだろうか…?

画像取込ライブラリの poppler → pplib への移行                      

LuaTeX の roadmap に以下のような記述があります。

Image handling
(略) Inclusion of PDF has been optimized in 0.50. In 1.10 we expect to have replaced the dependency on Poppler for embedding external PDF images by a dedicated small lightweight PDF access library that will also replace the now somewhat inconsistent epdf interface. This is part of the onguing effort to make LuaTeX as independent if other code as possible (the long term stable TeX narrative).

PDF を画像として取り込む(\includegraphics のような)機能を実現するためには,PDF を読み取る能力が欠かせません。その機能を,TeX Live 2018 までの LuaTeX は poppler という外部ライブラリに任せていました。ところが,LuaTeX 1.08.0 以降は poppler を捨て,pplib という小さなライブラリに移管しています。

この「poppler を捨てる」という流れは,TeX Live 界隈の最近の風潮になりつつあります。あまり詳しくない(けれども複数の有識者から話を聞いた)私の理解では,以下の要因が挙げられます。

  1. poppler が安定しない
    • poppler 自体はかなり強力な機能を持っている。(実際,InkscapeTeXworks などのツールも PDF レンダリングに poppler を採用している。)
    • ところが,その機能の多くは外部公開用 API として「仕様化」されているわけではなく,他のソフトウェアが使うことを意図していない
    • 外部公開用 API としては poppler-glib があるが,これはもちろん仕様として安定しているが,機能が足りないので,結局,内部向け API を使わざるを得ない。
    • すると当然ながら,内部用 API には poppler のバージョンアップごとに破壊的変更が入るので,それを使っていたソフトウェアが壊れる。
    • 勿論,安定な poppler-glib に API を追加してほしいという pull request を出している方もいるわけですが,なかなかマージされなかったり…。
  2. 比較的新しいコンパイラ (C++14) が必要
    • TeX Live 特有の事情として,新旧によらず「幅広いプラットフォームをサポートする」ことを目指している(Master/bin/ を見ると,2018 年現在 17 プラットフォーム)。「古いプラットフォームをいつまでサポートし,いつ排除すべきか」という議論でも,新しい言語により得られるメリットとデメリットが天秤にかけられる。
    • ちなみに TeX Live のコンパイルC++11 が必須となったのは TeX Live 2017 以降(dvisvgm version 2.x を皮切りに,ICU や Poppler などのライブラリが C++11 で書かれている)。
    • そんな中,poppler 0.69.0 からは C++14 が必要である。まだまだ C++14 対応コンパイラが利用可能な環境が多くないらしい状況を鑑みると,あと 2, 3 年は先の話になる?

実際に LuaTeX の場合も,poppler を捨てて pplib に乗り換えたことで C++ コンパイラが不要となり,純粋に C コンパイラだけでビルドできるようになったそうです。なお,TeX Live 2019 では恐らく poppler 依存のプログラムは XeTeX だけになると思います。

そもそも,LuaTeX の開発で LuaLaTeX は考慮されていない                      

この記事を読んでいて,LuaTeX を使ったことがある人のほとんどは,LuaLaTeX で

  • \usepackage{luatexja}
  • \documentclass{ltjsarticle}
  • \documentclass[lualatex]{jlreq}

のいずれかで,直接的あるいは間接的に LuaTeX-ja の成果物を使っていることでしょう。当然ながら,これらは LuaLaTeX で動いています

ところが,LuaTeX の開発目標は LuaLaTeX とは関係ないところにあり,その大きな部分を占めるのは Hans Hagen 氏が開発している ConTeXt です。実際に,forum:2513 の例のように「新しい ConTeXt + 新しい LuaTeX だと問題ないが,古い LuaTeX との組ではエラーが出て動かない(しかもTeX Live 2018 の物も古い部類に入る!)」というほど,LuaTeX と ConTeXt が密接に結びついているのです*5

ConTeXt は LaTeX や plain TeX と双璧をなす(?)マクロの枠組みで,文法が全く異なる(\starttext で始めて \stoptext で終わる等)だけでなく,開発コンセプトも LaTeX とは異なります。What are the differences between ConTeXt and LaTeX? には Hans 氏の考え方が色濃く出ています。また,歴史的背景としても,LaTeX は長年の多くの人による成果物を守るため,よほどのバグは直しつつもなるべく安定志向で維持開発されていますが,ConTeXt はまだその段階に至っていません。

その ConTeXt を動かす LuaTeX の設計思想にも,Hans 氏の考え方が大いに取り入れられていると感じます。例えば,LuaTeX は KnuthTeX を一から再実装していて,LuaTeX と TeX で生じる任意の違いは仕様 (feature) であり,TeX に合わせる気はないと言います。(Hans 氏がそのような発言をしていた気がするのですが,どこで読んだかは忘れました…。)また,先の「新しい ConTeXt + 古い LuaTeX だとエラーが出て動かない」の例は,ConTeXt のために LuaTeX の挙動が変えられたことを示唆します。何が変わったのか詳細はわかりませんが,ConTeXt のために LuaTeX が変わるようだと,いつか LuaLaTeX にも影響が出る可能性がないとはいえません*6

開発目標をどう持つかは自由なのでそれ自体は問題ではありませんが,「LaTeX 界隈での当たり前」が成り立たない LuaTeX (LuaLaTeX) が日本で受け入れられ,安定して使えるようになるのかどうかは,少なくとも私は見通せません。ただ,LuaTeX が「強い」のは確かなので,「安定」と比べてどちらを重視するかは個々人の判断に委ねられるところでしょう。

LuaTeX のフォーク版:LuaHBTeX                      

LuaTeX の公式版は主に Hans Hagen,Luigi Scarso,Taco Hoekwater らによって,ここまで述べてきたような独特の思想で開発されています。それとは別の方向性で,最近*7走っている LuaTeX のフォーク版プロジェクトが存在します。「LuaHBTeX」と名付けられたものがそれです。

これはエジプトの Khaled Hosny 氏が進めている「LuaTeX に HarfBuzz ライブラリを組み込む」という試みです。Khaled Hosny 氏といえば,XeLaTeX / LuaLaTeX で欠かせないといっても過言ではない fontspec パッケージに多大な貢献があり,ちょっと前までは XeTeX のメーリスでちょくちょく名前が出ていましたが,最近はどうやら LuaTeX でアラビア語を組むことに興味をお持ちのようです。

Arabic and color fonts in LuaTeX using HarfBuzz:
f:id:acetaminophen:20181209165000j:plain
Twitter より)

HarfBuzz は text-shaping engine と呼ばれるもので,「OpenType フォントに定義されている情報をもとに,ユーザが入力した Unicode コードポイントに対応するグリフを並べ,適切に配置する」という機能を提供するライブラリです。特に HarfBuzz には,アラビア語のような「隣り合う文字によって配置を変えて組む」という複雑な処理にも対応しているという強みがあり,これが現在の LuaTeX では弱いところとされています。同じく Unicode ベースの XeTeX は HarfBuzz を内蔵していて,そうしたアラビア語組版もこなすことができる*8ことと比べると,LuaTeX でも HarfBuzz を使いたくなるのも理解できます。

面白い試みなのですが,TeX Live チームからすると,この流れもまた難しいところです。LuaHBTeX は LuaTeX 本家のあずかり知らぬところで開発されていますから,方向性はよくわかっていません。

  • 先述のとおり LuaTeX は C++ 依存を外したのですが,HarfBuzz は C++11 を使っているので,結局ビルドに C++11 が必要になります。
  • LuaTeX に今後マージされるのかどうかは不明です*9

そういうわけで,動きは承知していながらも TeX Live チームとしては特に何もせず様子見です*10

追記(2019年4月):残念ながら LuaHBTeX は開発放棄されました。よくわかっていませんが,「バイナリに HarfBuzz を組み込む方式」ではなく,「LuaHarfBuzz なるライブラリを普通の LuaTeX から後で読み込む方式」になるのでしょうか。

 

まとめ                      

とりとめもなくなってしまいました…。でもリクエストは果たしました。

LuaTeX の怪しい動向を取り上げましたが,皆さんが使うのは自由ですし,それを TeX Live チームも最大限サポートしていくということは今後も変わりません。

*1:このように定義すれば,個別の「TeX に関連する何かを作って終了」するのではなく,それを「いかに TeX Live という枠組みに落とし込み,ユーザが使えるようにするか」という,よりマクロな「インフラ整備」とでもいうべき活動を指すことができると考えています。

*2:TeX-Live Organization (on GitHub) に所属している人数は,現在 18 名です(所属していることを非公開にしている人も含む)。しかし,実際には「GitHub アカウントで招待したので参加はしたが,活動実態がないメンバー」もいますので,ここではそれを TeX Live チームのメンバーとはみなしません。

*3:直近では \expanded というプリミティブが提案され,これは TeX Live 2019 の e-pTeX から利用可能となる予定です。

*4:簡単には,Build/source/ 以下にある「Build」というシェルスクリプトを走らせるだけです。

*5:実際に,LuaTeX の開発メーリス (dev-luatex) に修正をお願いするために LuaLaTeX の再現ソースを送ってみると返ってきたのは ConTeXt のソースでした。

*6:以前「LaTeX team の中の人が LuaTeX に要望を送ったけれども,結局通らなかった」という事象が確かあったような気がする…。ConTeXt とは対照的です。

*7:本当にごく最近の話で,おそらく初出は今年の 10 月 16 日のチャット (TeX, LaTeX and Friends - StackExchange) だと思われます。

*8:コマンドで xetex --version としてみると,使われている HarfBuzz のバージョンが表示されます。

*9:個人的には,マージされないのではないかと思っています。というのも,LuaTeX は OpenType フォントの扱いを,組み込みライブラリではなく全て Lua プログラムで書かれた fontloader によって実装しているためです。

*10:この本家 LuaTeX と LuaHBTeX をめぐる混沌が,TeXConf 2018 の懇親会の時に飲みながら Norbert さんと「勘弁してくれー」と言っていた話題です。

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 を使って読んでみると面白いでしょう。