Acetaminophen’s diary

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

TeX2img で任意の TeX エンジンを指定するために

TeX TeX2img ソフト
【最終更新 2015-08-23 04:10】TeX ソースの処理スキームおよびその活用法の網羅的解説。Windows 版 1.5.6 と Mac 版 1.9.8 に対応済み（一部のスクリーンショットを除く）。

TeX2img の機能拡張！

TeX2img の開発が進み、特に Windows 版 1.4.0 と Mac 版 1.8.8 の大規模アップデートではあらゆる LaTeX エンジンを用いるスキームに対応した。従来は pLaTeX/upLaTeX + dvipdfmx と固定されていたが、この拡張により多くの TeX ソースを処理することが可能となった。同時にユーザインタフェースも刷新されて便利な機能が付加されたため、それらの機能拡張を十分に使いこなすための情報もあわせて説明する。

配布サイトはこちら：

以前公開した GUI/CUI 版の使用法解説記事も、最新版に対応して改訂を完了している。併せて参照してほしい。

f:id:acetaminophen:20150226041219p:plain

 

初回起動時のデフォルト設定は…

初めて TeX2img を起動すると、まず初めにインストールされている TeX システムを推測し、LaTeX, dvipdfmx, Ghostscript プログラムの場所を設定する。デフォルトでは LaTeX プログラムは platex になっているはずだ。なお、以前のバージョンをインストールしていた場合はその設定を継承する。

 

他の LaTeX エンジンを使うには？

TeX2img for Windows 1.3.2 以前、および TeX2img for Mac 1.8.7.1 以前では、pLaTeX/upLaTeX + dvipdfmx によるコンパイルのみをサポートしていた*1。しかし、Windows 版 1.4.0 および Mac 版 1.8.8 への大規模アップデートにより pdfLaTeX や XeLaTeX といった PDF を直接出力するエンジンを指定できるようになった。内部処理は以下のように行っている：

  1. TeX2img は指定された LaTeX プログラムに TeX ソースを引き渡す。このときの TeX2img の役割は、プログラムを起動するランチャにすぎない。
  2. LaTeX プログラムが完了すると、生成したファイルを見て「実行したプログラムが出力したのは PDF なのか、それとも DVI なのか」を判断する。
    • 仮に DVI だった場合は、dvipdfmx に指定されたプログラムで PDF に変換してから画像化スキームへ移行
    • 仮に PDF だった場合は、dvipdfmx をスキップして直接画像化スキームへ移行

この「LaTeX プログラムの実行結果から次の処理を決定する」という実装により、TeX2img が想定していないエンジンにも対応可能となった。なお、この後に続く画像化スキームについてはこちらの記事で紹介しているので、参照してほしい。

 

プログラム実行時のオプション付与

TeX2img の仕様上、意図しないフリーズを避けるため等の理由で、標準でいくつかのオプションを実行プログラムに与えることになっている。この節の内容は TeX2img を使ううえで必要となることはほぼ無いと考えられるので、気にしない場合は読み飛ばしていただきたい。

各プログラムの実行時に標準で与えるオプションは以下のとおりである：

  • LaTeX に対して：-interaction=nonstopmode
  • dvipdfmx に対して：-vv

LaTeX に -interaction=nonstopmode を与えることで、途中で LaTeX がユーザからの入力を求めるようなことがなくなる。TeX2img はプログラム実行中にユーザからの入力を受け付ける仕組みを持たず、このオプションを付与しなければ処理を制御できなる可能性があるため必須としてある。

dvipdfmx に与える -vv とは more verbose を意味し、デバッグ用に dvipdfmx の処理過程を詳細に表示させるものである。このオプションを付与することで、dvipdfmx 処理中に問題が生じた場合のエラー内容を分かりやすくしている。

これ以外に後述の「文字コード」関連のオプションを LaTeX に与えることがあるが、その他のオプションをユーザが任意に与えることもできる。その場合、Mac 版では例えば

  • /Library/TeX/texbin/platex -shell-escape

のように、スペースを空けてオプションを入力すればよい。Windows 版では例えば

  • "C:\w32tex\bin\platex" -shell-escape

のようにプログラムのパスを "..." で囲み、スペースの後にオプションを入力すれば問題ないようである。

 

処理における文字コードの扱い

プログラムの設定画面には、文字コードの指定という項目がある。どうすべきか迷ったら、最近の TeX ディストリビューションをインストールしたのであればとりあえず

  • Windows 版では「指定しない（入力 UTF-8）」あるいは「UTF-8」
  • Mac 版では「指定しない」あるいは「UTF8」

に指定して問題ないようだ。普段は「指定しない」にしておき、文字化けが発生する場合にのみ明示的に指定するという程度でも十分かもしれない。以下で、詳細にこの挙動を知りたい方のために説明しておく。

文字コードの設定状態は、TeX2img の動作に対して次のように影響する。

  1. エディタに書き込まれたソースから一時ファイルを生成するときの文字コード指定
  2. LaTeX エンジンへの -kanji= オプションの付加
  3. TeX ソースファイルをインポートする際の文字コード推定の補助（Win 版のみ）
  4. エクスポートする TeX ソースファイルの文字コード指定

1つめは、単に「ユーザが指定した文字コードに従って一時ソースファイルを生成する」ということである。文字コードを「指定しない」場合は、Mac では自動的に OS の標準的な文字コードである UTF-8 で扱われる。Windows では2通りの指定が可能である*2。

2つめは「呼び出す LaTeX エンジンに、ソースファイルの正しい文字コードを教えてあげる」ことを意味する。日本語用に開発された LaTeX エンジンである pLaTeX/upLaTeX には（相当古い TeX システムでない限り）-kanji= というオプションで utf8/sjis/euc/jis/ という文字コードを指定できる。このオプションを付けることを TeX2img は GUI でサポートしているわけだ。なお、Windows 版の pLaTeX では標準で文字コード推定がはたらくようになっている（これは -guess-input-enc が有効になっているから）ため、これを禁止するために -no-guess-input-enc オプションも併せて付加してある。

3つめは、TeX ソースファイルをエディタにインポートする際に文字コードを TeX2img が推測するのを助けるものである。Windows 版の文字コード推定の詳細は阿部さんのにっき♪で説明されているが、この方法で万が一推定に失敗した場合を考慮し、確認メッセージを出すためにユーザ指定を参照する。Mac 版の文字コード推定については寺田さんの GitHub リポジトリの Issue 5 で説明されている。

4つめについては1つめと同様で「ユーザが指定した文字コードに従ってエクスポートする」という意味である。

 

色入力支援機能について

Windows 版 1.5.1 および Mac 版 1.8.9 で導入された機能。表示メニューから色入力支援を選択すると、\color, \textcolor, \colorbox, \definecolor という 4 種類の色指定関連コマンドを入力支援するダイアログが出現する。カラーパレットで選択した色を rgb に変換してくれるので、直感的な操作が可能である。

f:id:acetaminophen:20150504182207p:plain

f:id:acetaminophen:20150328004508p:plain

挿入はエディタ上でカーソルを置いた位置に行われる。支援は最小限にとどめてあるため、あとはユーザが範囲を { } で囲むなどの操作が必要である。

f:id:acetaminophen:20150328005115p:plain

f:id:acetaminophen:20150328010037p:plain

なお、色指定を行うためには color パッケージが必要である。プリアンブル設定ウィンドウに \usepackage{color} を追加する必要があるが、このとき platex/uplatex の場合は dvipdfmx ドライバオプションを付けなければならないことに注意されたい。すなわち \usepackage[dvipdfmx]{color} とする。Mac 版のテンプレート機能ではデフォルトで graphicx パッケージおよび color パッケージに対し、ドライバオプションを適切に与えるように追加してあるが、手動でこれらのパッケージを追加する場合は注意してほしい。

 

プリアンブルのテンプレート機能

プリアンブル設定ウィンドウでは、従来の「デフォルトに戻す」ボタンを廃止し、代わりにより高機能な「テンプレート」メニューを配置した。

デフォルトは古い TeX 環境を想定して pLaTeX で統一してあるが、pLaTeX には JIS 第一・第二水準 (JIS X 0208) 外の漢字や絵文字、環境依存文字（ゆきだるまや丸数字など）をそのまま扱えないという問題がある。これらの文字を直接エディタで入力して処理するには、内部処理が Unicode の uplatex というエンジンが便利である。もちろんそれ以外の文字も pLaTeX のときと同様に処理できるので、日本語文書を作成する場合には「使う漢字が JIS X 0208 に含まれているか？」などと考えずに済む upLaTeX を利用するのをためらう必要はない*3。

この場合、文字コードを Windows 版では「UTF-8」または「指定しない（入力UTF-8）」に、また Mac 版では「UTF8」または「指定しない」に設定し、プリアンブル設定ウィンドウで jsarticle のオプションに uplatex を追加するとよい。例えば以下のような処理ができる（スクリーンショットは Windows 版）。

f:id:acetaminophen:20150823041003p:plain

f:id:acetaminophen:20150226042117p:plain

 

このように、デフォルトの pLaTeX では処理できない文字を upLaTeX で処理したり、そもそも (u)pLaTeX + dvipdfmx では処理できないパッケージを利用するために pdfLaTeX などの PDF 直接出力エンジンで処理するという場合には、エンジンに応じて適切にプリアンブルを書き換える必要がある。これをサポートするのがテンプレート機能である。デフォルトでは pLaTeX 用のプリアンブルを指定しているが、さまざまな LaTeX エンジンに対応すべく5種類のテンプレートを標準で用意した。

pLaTeX（最も一般的な日本語文書）

\documentclass[fleqn,papersize]{jsarticle}
\usepackage{amsmath,amssymb}
\pagestyle{empty}

upLaTeX（Unicode に対応：日本語文書で推奨！）

\documentclass[fleqn,papersize,uplatex]{jsarticle}
\usepackage{amsmath,amssymb}
\pagestyle{empty}

pdfLaTeX などの一般的な欧文文書

\documentclass[fleqn]{article}
\usepackage{amsmath,amssymb}
\pagestyle{empty}

XeLaTeX（システムにインストールされたフォントを直接利用可能）

\documentclass[fleqn]{bxjsarticle}
\usepackage{zxjatype}
\usepackage{amsmath,amssymb}
\pagestyle{empty}

LuaLaTeX (LuaTeX-ja)（将来の標準と目されている新しいエンジン）

\documentclass[fleqn]{ltjsarticle}
\usepackage{amsmath,amssymb}
\pagestyle{empty}

 

なお、Mac ならヒラギノを使いたいと思われるので、XeLaTeX, LuaLaTeX については標準テンプレートを以下のように作成してある。

XeLaTeX の場合：Mac 用ヒラギノ設定

\documentclass[fleqn]{bxjsarticle}
\usepackage{zxjatype}
\setCJKmainfont[BoldFont=ヒラギノ明朝 ProN W6]{ヒラギノ明朝 ProN W3}
\setCJKsansfont[BoldFont=ヒラギノ角ゴ ProN W6]{ヒラギノ角ゴ ProN W3}
\usepackage{amsmath,amssymb}
\pagestyle{empty}

LuaLaTeX (LuaTeX-ja) の場合：Mac 用ヒラギノ設定

\documentclass[fleqn]{ltjsarticle}
\usepackage[deluxe,hiragino-pron,jis2004]{luatexja-preset}
\usepackage{amsmath,amssymb}
\pagestyle{empty}

 

テンプレートの管理

ユーザがテンプレートを改変したり、新たに追加したりすることもできる。プリアンブル設定ウィンドウ下の「テンプレート」メニューは以下のようになっている。

f:id:acetaminophen:20150226055118p:plain

f:id:acetaminophen:20150226055103p:plain

Windows 版ではテンプレート集は設定ファイルの中に書き込まれているので、実ファイルが存在せずコンパクトである。メニューから「テンプレートの管理」を選択すると、管理画面が現れる。ここでプリアンブルの追加や上書き、削除が可能である。外部ファイルからのプリアンブルインポートにも対応している。

f:id:acetaminophen:20150226055241p:plain

Mac 版では実際の TeX ファイルがフォルダに格納される。メニューから「テンプレートの管理」を選択すると実際のフォルダが現れる。ここでファイルを追加・編集・削除すれば、テンプレートメニューに反映される。サブフォルダによる管理にも対応し、例えば以下のような整理が可能である。

f:id:acetaminophen:20150226055624p:plain

f:id:acetaminophen:20150226055635p:plain

 

出力画像へのソースコード埋め込みについて

Windows 版 1.4.0 および Mac 版 1.8.8 の新機能。従来から Mac 環境では、MacTeX という TeX ディストリビューションに標準でバンドルされている LaTeXiT という類似の画像化ツールが国際的によく使われているようで、LaTeXiT には「PDF にコメントとして TeX ソースを埋め込む」という機能があった。これに対抗すべく、画像ファイル自体のサイズを増やさない「拡張属性」としてソース情報を保持する機能が TeX2img には搭載された。この仕組みについては、GitHub Issue 7 およびあべのりさんのにっき♪で詳しく説明されている。なお、Windows 版 1.4.0 と Mac 版 1.8.8.1 以降では、ソース埋め込みは無効にすることも可能である*4。

この機能でソースを埋め込んだ画像ファイルは、TeX2img でインポート（またはソース入力エリアにドラッグアンドドロップ）することにより、元の TeX ソースコードを復元できる。ソースの再利用性が高まる非常に便利な機能である。なおこの機能は Windows 版では NTFS の拡張属性を、Mac では HFS+ の拡張属性を活用しているため、USB メモリなどでしばしば用いられる FAT 形式では無効であるほか、Windows と Mac で相互にソースをやりとりすることはできない。Windows と Mac の間でソースを持ち出したい場合は別途「インポート/エクスポート機能」を用いるとよい。

 

クリップボードに画像をコピーする機能

Windows 版 1.5.5 および Mac 版 1.9.5 の新機能。複数画像が生成した場合にはすべての画像がクリップボードに転送される。PowerPoint や Keynote に画像をすぐに貼り付ける場合に便利である*5。

 

コンパイル回数推定について

Windows 版 1.3.0 および Mac 版 1.8.6 で導入された機能。数式番号などを相互参照する際に有用な「コンパイル回数推定・指定機能」は .aux などの補助ファイルを監視し、変化しなくなるまでコンパイルを繰り返すことにより実装されている。なお .aux が収束しない場合*6を考慮し、回数推定を働かせる場合にも上限を設定できるようにしてある。

 

結局、何が変わったのか

ユーザインタフェースの見た目としては、テンプレート集を作れるようになったという程度の差であるが、内部構造も大きく変化していることがおわかりいただけただろうか？ 今回のアップデートで最も意識したのは

LaTeX のパス設定が他の挙動に影響を与える部分を全廃する

ということである。従来はパス設定に uplatex を推奨すべく、自動判定を uplatex にしたりプリアンブルを uplatex の場合に変化させたりしていた。しかし、今回の PDF 直接出力エンジンへの対応を完成させるには、あらゆる TeX エンジンを TeX2img が知っていて、それぞれに適切な設定を行う必要性が生じてしまう。開発途上に一度はパス設定をフル活用して自動設定する方向へと進みかけた（＝“毒を食らわば皿まで”）が、ユーザが特殊なスクリプトを作成して指定したい場合や、想定外の TeX エンジンの利用も考慮すると、拡張性が損なわれることになる。そこで、徹底的に“解毒”を行う代わりに「テンプレート集」という形でプリアンブル設定をサポートし、また文字コード設定の挙動についても GUI と実際に LaTeX エンジンに渡されるオプションの整合性を高めた。今回のアップデートにより、ベテランの LaTeX ユーザにとっても理解しやすい仕様になったのではないかと期待している。

 

あとがき

Windows 版 1.4.0 および Mac 版 1.8.8.1 の開発は、またも Twitter を発端にして実に 10 日間に及ぶ大規模な改修となった。Mac 版の GitHub リポジトリ上で 150 件を超えるコメントのやりとりで詳細な仕様を詰め、将来の更新の可能性をも見据えた安定した仕様を追求した。開発の方向性の決定段階が難航したが、無事リリースにたどり着いた。機能性・操作性ともに大幅に向上したのが非常に嬉しい。

*1:実は、この状態でもここ (Windows) やここ (Mac) に書いた方法で、pdfLaTeX や XeLaTeX といった他のエンジンを利用することができた。ただし、もちろんサポート外のバッドノウハウである。

*2:Windows 版の「指定しない（入力 UTF-8）」と「指定しない（入力 Shift_JIS）」は、ともに文字コード判定を pLaTeX に任せる。2つの違いは「ソースを BOM 付として判定を UTF-8 に仕向けるか、OS 標準の Shift_JIS で処理させるか」という点にある。前者は UTF-8 を処理できない古い TeX では使えないため、Windows 版のデフォルトは後者に設定してある。

*3:ただし、upLaTeX は TeX Live 2012 以降および W32TeX [2007/08/24] 以降でなければインストールされないので、これ以前の TeX システムの場合は従来どおり pLaTeX を使う必要がある。

*4:特に Windows 版では、主にセキュエリティ上の観点から拡張属性にアクセスされたくないという場合があるかもしれない。

*5:ただし、Mac 版では Office for Mac 2011 が Finder からの画像コピー＆ペーストに対応していないため、この機能を活用できない場合があることに留意されたい（Keynote や Windows 版 Office などは対応しているので問題ない）。

*6:実例としては、寺田さんによる一例あるいは阿部さんによる一例が考えられる。