TeX

やる気だけはあるのだが

自分用のテックのマクロを同僚が使えるように整備して配布したいなあと、随分前から考えてはいるのだが、これがなかなか出来ない。現状のまま、多少整備されてなくても良いではないかとも思うが、さすがにちょっと気恥ずかしいとか、いろいろあって。

それに、クラスファイルと汎用のマクロが渾然一体となっている部分もあって、これも分離した方が良かろうとか、自分好みのタイプフェースの設定とかは無い方がいいかなとか、いろいろ考えると面倒くさくなって、また今度ねえ〜となってしまうのだった。

今日も少しだけマクロのバージョンアップをしたけど、中途半端。一つだけ勉強したことをメモ。\newenvironment で新しい環境を定義するとき、オプションの引数も使えるようだ。ワタシの持っている判のLaTeX Companionには、\begin{hogehoge}[option] … \end{hogehoge} という書き方が出来るとは書いてなかったので、てっきりダメだと思っていたのだが、吉永徹美さんの 「LaTeX2e プログラミング基礎解説」によると可能なようなことが書いてあった。もっとも、自前で、

\def\hogehoge{\ifnextchar[{\@hogehoge}{\@@hogehoge}}

みたいな調子で処理すれば出来るのは何となく分かるのだが、こういうのが毎回出てくると面倒なんだよなあ。

あと、やっぱりみんなに使ってもらうには、使い方というか仕様書を書かねばならないだろう。実はこれが一番面倒かもしれない。ううむ。

文字コードを判別してTeXにかけるPerlスクリプト

とある事情で、Ubuntu上ではUTF-8およびShift_JISの2種類のTeX文書を処理している。一々 platex -kanji=utf8 とか platex -kanji=sjis とか、したくないので、文字コードを判別してから組版し、ついでにPDFに変換して文書ビューアで表示させる Perl スクリプトを作ってみた。

ユーザーは自分だけなので、思いっきり手抜きだが、まずまず役立っている。

#! /usr/bin/perl -w
#
# [usage] myplatex hoge
#  hoge.tex の文字コードを判別して、platex -kanji=KANJICODE とコンパイル
#  引き続いて dvipdfmx で PDF を作り、文書ビューアー evince を起動する
#  とりあえず,普段使っている UTF-8 と Shift_JIS のみサポート

use strict;

my $basename;   # hoge
my $texfile;    # hoge.tex
my $dvifile;    # hoge.dvi
my $pdffile;    # hoge.pdf
my $kanjicode;  # UTF-8, Shift_JIS

$basename = $ARGV[0];
$texfile = $basename."\.tex";
$dvifile = $basename."\.dvi";
$pdffile = $basename."\.pdf";

open (INFILE, "<$texfile") || die "File Not Found\n";
close INFILE;

$kanjicode = `nkf -g $texfile`;
chomp($kanjicode);

if ($kanjicode eq "UTF-8") {
 system("platex -kanji=utf8 -interaction=nonstopmode $texfile");
} elsif ($kanjicode eq "Shift_JIS") {
 system("platex -kanji=sjis -interaction=nonstopmode $texfile");
} else {
 die "Not supported\n";
}

system("dvipdfmx $dvifile");
system("evince $pdffile");

MePoTeXで悪戦苦闘

図版を作るために、ひさしぶりにMePoTeX (LaTeXからMetapostを呼び出して使うためのマクロ集) を使ったのだが、どうも思う通りに行かず、イライラする。腹立ちまぎれ(?)に状況をメモ。

まず、Mac OS X 上では、何故か pensize が思うように変えられない。\sendMP{…} の中で pickup pencircle scaled 1.2pt などとしても線は細いまま。ええいと、3ptにしたら突然太くなる。いや、3ptは太すぎなんだってば。あれこれやっていると、ペンサイズは変えてないのに、ある場所に \mptDraw{…} と、MePoTeX の描画マクロを加えた瞬間に全体のペンサイズが変更になったり、もう訳が分からんというか、なんじゃ〜これ〜。

原因がマクロ集にあるのか、それともMacのMetapostにあるのか判断できないので、Ubuntu (Linux) 上でやってみようとするのだが、これが上手く動作せずに、これまたイライラ。ちゃんと shell escape のオプションも指定しているのに、何故か sh: mpost not found のエラーメッセージ。おいおい、パスが通ってないのかよ、と思いつつ、シェルから実行してみると、パスは通っている模様。というか、platexと同じ /usr/local/teTeX/bin/ にmpost もあるんですけどね。そういえば、エディターからlatex呼び出すときも、何故か実行ファイルを見つけられなかったことあったよなあ、と思いつつ、mepotex.sty を読んで、mpostを呼び出している部分を /usr/local/teTeX/bin/mpost と、絶対パス指定に変更してみた。いやあ、こんな乱暴、普通あり得んだろう。結果・・・ちゃんと mpost 呼び出されるじゃないすか。うーん、やっぱり、ここかあ。

しかし・・・こんな現象、いくら検索しても出てこない。ってことは、ワタシの設定が間違っている可能性が高い、と思われる。うーむ、パスが通ってるのに何故に絶対パスを記述しないとダメなんでしょうか。理由が分からない。あーイライラするなあ。

EnumItem パッケージ

LaTeXの箇条書き環境をカスタマイズできるパッケージを見つけたのでメモ。

enumitem パッケージというのがそれ。名前から想像できるように、enumerate環境、itemize環境、それからdescription環境という主なリスト環境をカスタマイズする。

LaTeXのリスト環境は、非常にmessyというか、作りが雑というか、特にリストの中にリストを含むような場合に、左マージンの調整やら何やら、いらいらすることが多いのである。であるからして、個人的にはできるだけこれらを使わないようにしている。

今回、人のLaTeX原稿に手を入れることになったため、悪戦苦闘。幸い、このパッケージのおかげで、少しはましになったと思う。マージンの量を直に設定するのは個人的にはダメダメだと思うが、まあ、原稿が固定しているから、今回は不都合はないかな。

やはり日本語ファイル名だと読み込まれない

実験してみたが、ダメだった。メインのファイルをutf-8で編集し、「なんとか.tex」というファイルを読み込もうと \input なんとか.tex としても、
ファイルが見つからないというエラーメッセージ。ううむ。

以前読んだことがあるが、日本語TeX (ASCII pTeX) では、内部的にはJISコードで処理しているとか何とか、とにかく、何らかの処理をしていたような気がする。もしそうであれば、Ubuntu側はutf-8でファイル名を管理しているのだから、無理というものだ。TeXの内部処理に手を付けて、\input など外部ファイルを読み込むルーチンを書き換える必要がある。それはワタシの手に余るなあ。

Mac OS X 10.3.9 までの井上版pTeXでは、そういう処理が施されているのだろうと想像。今のところ UNIXベースの日本語TeXシステムで日本語ファイル名が普通に使えるものを他に知らない。みんなファイル名だけはアルファベットで表記しているのだろうが、不便じゃないのかなあ。

Ubuntu上のTeXで日本語ファイル名は使えるはずだが・・・

日本語ファイル名の文書がインクルードできなくて困っている。うーむ、何故だろう。「なんとか.tex」というファイル名にして、platex なんとか.tex とすれば普通にコンパイルできるのだが、なんとか.tex の中で、更に「かんとか.tex」という別のファイルを読ませようとすると「かんとか.tex」というファイルが見つからないというエラーが出る。

つらつら考えるに、文字コードのせいではないかという予感。「かんとか.tex」というファイル名はUbuntuではUTF-8で管理されていると思う。もちろん「なんとか.tex」のファイル名もUTF-8だろう。ところが、「なんとか.tex」のファイル本体、中身のテキストファイルは (ワタシの個人的理由によって) Ubuntu標準のUTF-8ではなくShift-JISで記述してあるのだ。だから、\input かんとか.tex という命令で「かんとか.tex」を読み込もうとすると、これが OS の入出力に渡される際に Shift-JIS コードのままで渡されているのではなかろうか。以上、単なる推測だが、そうだとすれば、エラーになるのは当然と言える。

確認するには次の実験をすればよい。なんとか.tex を Shift-JIS ではなく UTF-8 で書き、かんとか.tex が読み込まれるか試す。やってみますかね。しかし、Shift-JIS を止めるわけには行かないしなあ。ファイル名に日本語を使わなければエラーは回避できるのだが、kantoka.tex というファイル名は分かりにくいしなあ。どうしたものか・・・。

dvipdfmxのMap設定が反映されない罠

Ubuntu上でのTeXに関する備忘録。何故かFourier-GUTの数式フォントがPDFに埋め込まれない。Mapファイルを設定して texhash、updmap-sys してもダメ。以前の経験から、何かが優先されているため、変更が反映されないのだと推理。HOME直下の隠しディレクトリー .texmf-var 以下を探す。ここには個人の設定ファイルなどがあり、システム共通の設定に優先する。~/.texmf-var/fonts/map/dvipdfm/ に dvipdfm.map なるファイルがあった。いろんなフォントに対応するtype1フォントが書いてある中、fourier-GUTのフォント群だけがない。ああ、やっぱりだ・・・。ということで、このファイルを削除。すると、ちゃんと変更が反映されて、dvipdfmx により PDF が無事に作成された。あーやれやれ。

さよならAcrobat、こんにちはEvince

さよならというわけじゃないが、Ubuntu GNU/LINUX上のEmacsでTeX文書を編集する際のプレビューコマンドをAdobeのAcrobat(Linuxでのコマンド名は acroread)からGNOME標準の文書ビューアーEvinceに変更した。いやあ、激重のアクロバットと違って、あっという間に起動するので、ストレスを感じない。dvipdfmxでdviからpdfに変換してからEvinceで開いているのに、そんなことを少しも感じさせない速さは素晴らしい。

やっぱ、男はEmacsだな(^^;)

いや、まだ全然使いこなせてないんですがね(苦笑)。というか、以前使っていたときも、別にEmacs Lispをバリバリと書いていた訳じゃなし、普通のユーザーにすぎなかったんですから。

ともあれ、Emacs 23 (まだ安定版じゃないけど)にAUCTeXを入れて、自分の環境に合わせたカスタマイズを少々行いました。これでイーマックスもただのエディターに成り下がった :mrgreen: というか、普通に使う分には、難しいことは何もありません。ツールバーにあるライオンさん(TeXbook以来の伝統で、ライオンがTeXのイメージキャラクターなんです)のアイコンをクリックして組版、しかるのちに眼鏡のアイコン(なんで眼鏡なんだろう?)のアイコンをクリック。すると出来たPDFがプレビューできるという具合です。

Emacs編集画面