Ubuntu

UNIX日本語環境でのロケール設定が分からない

差し当たって、nkf を用いてエンコーディングをシフトJISからユニコード(UTF8)に変更すればバックスラッシュ(\)がきちんと表示される。しかし、何故にShift JISでは、たとえフォントがバックスラッシュのグリフを持っていても円記号(¥)の方が表示されるのか、その理由を知りたい。少し検索したが、断片的な情報しか得られない。とりあえず、現時点で分かったことをメモ。

まず、バックスラッシュに関係するらしきロケール(locale)の話が次のページにある。

ja_JP.UTF-8 ロケールとフォントに関する注意事項 (日本語環境ユーザーズガイド) – Sun Microsystems

ページの一番下に、具体的な設定方法が少しだけある。どうやら、それぞれのロケール設定ファイルにおいて個別のコードブロックに対応するフォントファイルを指定できるようになっているようだ。バックスラッシュは、U+005C であり、アスキー7ビット領域にあるから、この領域に対するフォントグリフの設定を修正すれば良いのかもしれない。これはSun OSのケースなので、UbuntuというかGNU/Linuxの場合はファイルの位置から違うが、これはすぐに分かった。Ubuntu 8.04 (Hardy) の場合は、当該のファイル群は
/usr/share/X11/locale/
以下にある。しかし、具体的にどう修正すれば良いのか、全く分からない。

UTF8に関するロケールは、ja_JP.UTF-8 であり、XLC_LOCALE というファイルに記述がある。ASCII部分は次のようになっている。

# We leave the legacy encodings in for the moment, 
# because we don't
# have that many ISO10646 fonts yet.
#   fs0 class (7 bit ASCII)
fs0 {
  charset {
    name  ISO8859-1:GL
  }
  font  {
    primary   ISO8859-1:GL
    vertical_rotate all
  }
}

一方、Shift JIS のロケール ja.SJIS では次のようになっている。

# 	fs0 class (7 bit ASCII)
fs0	{
	charset	{
		name		ISO8859-1:GL
	}
	font	{
		primary		ISO8859-1:GL
		substitute	JISX0201.1976-0:GL
		vertical_rotate	all
	}
}

違いは、substitute JISX0201.1976-0:GL という一行だけのようだが、これは ISO8859-1のフォントグリフの代わりに JISX0201.1976-0 のフォントグリフを使うという意味だろうか。この行をコメントアウトして無効化すれば、UTFと同じ状態になるだろうか。勝手にファイルをいじって、不都合はないだろうか。うーん、やってみる勇気がいまひとつ出ないなあ。どうしたものか・・・。

nkfを用いて文字コードを変換する

Ubuntuの(というより Gnomeの?)標準テキストエディター gedit でShift_JISでエンコードされた文書を開くと、何故かバックスラッシュ(\)が円マーク(¥)のグリフで表示される。フォントの問題かと思って、Andale Mono などいくつかの欧文等幅フォントで表示させたが、結果は同じ。Emacsで開けば、きちんとバックスラッシュで表示されるのだが。

とある理由で gedit から印刷させたいのだが、バックスラッシュがきちんと表示されないのでは困る。gedit でエンコードを utf-8 にして保存してみたのだが、驚くなかれ、今度は Emacs でも円マーク(¥)で表示されてしまう始末だ 😯 。一体どうなっているの〜。うーむ・・・想像だがUbuntuのロケールがutfの日本語だと、良かれと要らぬサービスをしているのだろう。困ったもんだ。

仕方ないので、nkf を使って文字コードをutf-8に変換した。検索して見つけた次のページを参考にした。

まさおのブログ: ファイルの文字コードを一括変換 (find, nkf, xargs)

nkf単独だと1個ずつ変換することになるので、パイプの機能を利用して、ディレクトリーにあるファイル全部を変換する。


$ find . -type f | xargs -n 20 nkf -w -Lu --overwrite

上の例だと、カレントディレクトリーにおいて、ファイルを見つけて(find)、それをパイプラインで nkf に送り込む。オプションの意味は、-w がutf にする、-Lu が行末コードをUNIXタイプにする、などなど。

ということで、これでファイルの文字コード変換はばっちりだ。utf-8のエンコードだと、gedit もバックスラッシュをきちんと表示してくれて気分が良い。

avimergeで映像ファイルを結合

[ 備忘録 ] 大げさな編集ソフトを使わずとも、avimerge なる命令で幾つかの AVI ファイルを結合させることができる。事前に transcode をインストールしておくこと。

Transcode_Wiki: Avimerge

正規表現までは無理だが * で任意の文字列に対応させるという、単純な処理はできるようだ。例えば、
 $ avimerge -i sample*.avi -o combined.avi
とすれば、sample(任意の文字列).avi がすべて結合されて combined.avi というファイルに書き出される。*の部分には数字を対応させるとよい。
sample01.avi, sample02.avi, sample03.avi, etc. sample99.avi という99個のファイルがあったとすれば、この順序で結合されるので都合が良い。

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

実験してみたが、ダメだった。メインのファイルを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 というファイル名は分かりにくいしなあ。どうしたものか・・・。

Ubuntuでの囲碁再生ソフト Quarry

Chessはあっても囲碁はないだろうと、はなから決めつけていたが、Ubuntu上でも囲碁の棋譜再生ソフトがちゃんとあった。他にもあるかもだが、すぐに見つかったQuarryというので十分な感じ。

quarry_screenshot

白石がちょっと灰色がかっているのが、やや不満と言えば不満。まあ、このあたりは画像の問題だから、あとでなんとかなるだろう。

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で開いているのに、そんなことを少しも感じさせない速さは素晴らしい。

華麗に敗北

Screenshot-Pychess

Ubuntuはチェス関係も充実している。というか、今となっては、WindowsもLinuxもMacも、大きな違いはないが。PyChessというチェスボードがシンプルで気に入ったので、それで遊んでいる。チェス・エンジン(実際の着手を計算するプログラム)も、デフォルトのGNU Chess以外に、定評のあるCraftyやら、最近評判のfruitやら、いろいろと選べる。fruitから派生したToga IIというエンジンと対戦。いや、黒番(後手番)なので最初から厳しいのではあるが、不慣れなオープニングでいや〜な感じだなあと思っていたら、いきなり華麗なコンビネーションをくらってしまった、orz… 最後は、クイーン・サクリファイスして例のsmothered mateではないですか!やれやれ、実戦でこれをくらってしまうとは 😯