ひとつ前の続き。 xpsに入っているバイナリファイルの内、odttfはほとんどttfでした。jhdでダンプするとすぐに特徴的なttfのテーブルが見えまして、少し書き換えるとttfとして使えます。ただしそのxpsに必要な文字だけしか入っていません(当然ですが)。ヘッダの長さが44バイトに変わっていて44バイトの中身はよくわかりませんが、ttfに変換するスクリプトをgitのリポジトリに入れておきました。

# cg-clone /xps.git/
# cd xps
# python odttf.py xxxx.odttf ...

のようにしてみると、odttfがttfに変換されます。次はこれを利用してttfを作り、XPSの表示に生かすことになるわけですが、それはまたいずれ。

ここの続き。「とりあえずパス」と言いつつ、書いてみたので公開しておくよ。 xps2txt.py

# python xps2txt.py hogehoge.xps
  :

ページに含まれるテキスト情報だけ抜き出して表示する簡単なプログラムです。少なくとも、Vistaのメイリオの情報(microsoft.com)のXPSは正常と思われる程度に処理できました(Windowsを使っていないので本当にこういう内容のファイルなのかは不明)。 「XPSのサンプル(microsoft.com)」と称されるものはLicense Agreementを読む気になれず手元にないので試していません(たぶん大したことは書いてないと思いますけど＞ライセンス)。機能がtext変換という単純なものなので、問題があるにしても多少の変更でどうにかなると思います。「FixedDocSeq.fdseqとFixedDocumentSequence.fdseqの問題」にはやられたけど。ひどいなこれは(笑)。本来のrootは別のファイルらしい。これから探します。 いずれHTMLかOpenDocument(odt)くらいに変換したいなぁ。まあでもtextの次はreStructuredText(planewave.org)とかWiki形式かな。 もしかしたら今後も続くかもしれないので、gitのリポジトリを公開しておきます。

# cg-clone /xps.git/

XPS(XML Paper Specification)(microsoft.com)というのがあるらしい。MS製PDFみたいなものだ。紙を表現するXMLということだが、ビューワもWindows用にしか存在せず(.NETのなんたらを入れる必要があるとかないとか？？)、孤高のファイルフォーマットという感じがする。最初はプリンタ用の言語(PSの代わり？)として作られたらしい。紙をXMLで表現するなど、なかなかよろしい話ではないか。だが仕様のダウンロードにLicense Agreementが必要なので仕様は落としてない。その代わり、サンプルにいくつかファイルをダウンロードしてみた。しょせんXMLだし、当分はこれで充分だろう。 というわけで仕様はともかく、MS配布のXPSファイルの中身を見ると、zipで束ねられた複数のXMLファイルだ。データとしてjpegやpng、内容は良く分からないが「odttf」という拡張子のファイルも入っていた(フォントだろうか？)。こういう構造はODFと同じようなもので、流行りかな。かなり効率は悪いと思うんだけど、何も考えなくても圧縮されるし解析がしやすいからオープンな規格にしようとするとこうなってしまう。XMLを見ているといろいろ冗長で、単純なものを扱うデータがどんどん複雑に表現されていく。入力と出力を共通化するだけのためにここまでやる必要があったのだろうか？ YAMLとかJSONが出現した理由が分かるよね。 印象としては、MSはUTF-16のテキストファイルが好きですね、というのと、いろいろな流儀のXMLファイルが混合しているので生成するのはどうやってるのかが疑問、という感じ。 まず最初のUTF-16というのは、US-ASCIIしか使ってないファイルがUTF-16で書かれていたりする。「<?xml」宣言でエンコーディングを指定しなければUTF-16という感じのルールにも見えるが、全部のXMLファイルがUTF-16であるとは限らないのが気持ち悪い。 あといろいろな流儀のファイルが混合しているというのは、上記のXMLで「<?xml」の宣言がないXMLファイルとあるファイルの違いとか、タグ間にスペース/改行が入っているのと入ってないのとか、MSがXMLの出力方法をどうやっているのかが疑問に思えたりする。普通に内部表現でXML用のツリーを作って一箇所で出力するように書いてないのかなぁ。不思議だ。普通にプログラムを書けば同じ流儀になるはずなんだ。たまに適した流儀に変更するというのはあるが(個々の文字をエスケープしないでCDATAにするとか)。 zipに入っているファイル名も「[Content_Types].xml」(なぜ大括弧が必要なの？)とか「_rels/.rels」(なぜにドットファイル？？)とか、ちょっと気持ち悪かったりしている。 ファイルの解析としては、トップディレクトリにあるFixedDocSeq.fdseqを見てFixedDocumentSequence/DocumentReferenceのSourceに書いてあるファイル名のファイルにページのリストが書いてあり、1ページ1ページが別々のXMLファイルになっていた。紙を表現するだけあって、かなり細かい指定までできる。すばらしい。最後はodttf(フォントファイル)のパースが一番面倒になるかも。バイナリだしな。 というわけであまり積極的に見ていく気にならない気もするのだが、XPS対応のビューワかコンバータをPython/Tkinterか何かで書ければ、MacやLinux等でXPSが使えてけっこう偉いかもしれないなと思ったりもしている。 しかしもう休暇が終わってしまうのでとりあえずパスだな。いつかやろう。MSがXPSを見捨ててからやるか(笑)

今さらですが、ソーシャルブックマークを利用しはじめてみました。 wtnb75(icio.us) まだタグのつけ方がそれほど確定していない。

いま中原区には雪が降ってますね。 それだけ。

Pythonのモジュールをインストールするのにbdist_rpmを使ってrpmから入れている人で、Fedora Coreでこんな感じのエラーになるときは、

Checking for unpackaged file(s): /usr/lib/rpm/check-files /usr/tmp/scanf-1.1-1-buildroot
error: Installed (but unpackaged) file(s) found:
   /usr/lib/python2.4/site-packages/xxxx.pyo
 
 
RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/python2.4/site-packages/xxxx.pyo

こうゆうふうに変更するとよい。/usr/lib/python2.4で以下のパッチを当てる。 root# patch -p1 < patch-file

--- python2.4/distutils/command/bdist_rpm.py.orig	2007-01-19 18:57:07.000000000 +0900
+++ python2.4/distutils/command/bdist_rpm.py	2007-01-19 18:57:43.000000000 +0900
@@ -488,6 +488,7 @@ class bdist_rpm (Command):
             ('build', 'build_script', def_build),
             ('install', 'install_script',
              ("%s install "
+              "--optimize 1 "
               "--root=$RPM_BUILD_ROOT "
               "--record=INSTALLED_FILES") % def_setup_call),
             ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"),

RedHatのbugzilla(redhat.com)より。upstreamの問題として報告してclosedにされてしまっている。rpmを作るときに修正できる(し、その方法も分かっている)のに放置とは、いいかげんなものだ。 rpmに入れる場合のパッチは以下の通り。変更内容は同じです。

--- Python-2.4.4/Lib/distutils/command/bdist_rpm.py.orig	2007-01-20 09:56:37.000000000 +0900
+++ Python-2.4.4/Lib/distutils/command/bdist_rpm.py	2007-01-20 09:57:03.000000000 +0900
@@ -488,6 +488,7 @@ class bdist_rpm (Command):
             ('build', 'build_script', def_build),
             ('install', 'install_script',
              ("%s install "
+              "--optimize 1 "
               "--root=$RPM_BUILD_ROOT "
               "--record=INSTALLED_FILES") % def_setup_call),
             ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"),

正月休みを利用して、青空文庫のファイルをOpenDocument(OpenOffice.org 2.0とかで使われているドキュメントフォーマット)に変換するスクリプトを書いてみました。 まだイマイチなところもありますが置いておきます。odt.py zipの状態でも食わせることができます。

# python odt.py 789_ruby_5639.zip saruno_koshikake.txt
789_ruby_5639.zip -> wagahaiwa_nekodearu.odt
吾輩は猫である 夏目漱石
saruno_koshikake.txt -> saruno_koshikake.odt
さるのこしかけ 宮沢賢治

もともとはOpenDocumentのフォーマットを調べてみるのが目的でした。縦書きにしようと思いましたが普通にやると(OOoのバグだと思いますが、)ルビがずれるので…直す方法はあるらしいですが、横書きのままで。

最近は低レベル系の人が張り切ってますね。一応言っておくと「低レベル」と言っても技術者の言う「低レベル」は一般の人の意味とは違います。レイヤが低いという感じの意味ですね。 というわけで私もBinary Hacks(amazon.co.jp)という本が意外に面白いので買ってみたり。この本は100個の"Hack"と称して低レベルな話が載っていますが、誰しも101個目のHackを持ってるんじゃないでしょうか。私はあまり凄い人ではないので、あの本よりも高いレイヤにはなってしまいますが、役に立ちそうなものを1つ紹介しておきます。 ★Hack #10101 initrdで遊ぶ Linuxのブート時のある時期に、initrdというファイルが読み込まれます。ブート時に指定できるんで、指定しなければ読み込まれないんですけど、grubもliloもsyslinuxもpxelinuxもinitrdを読み込む機能はついていますから、普通は読み込む。そんでこのinitrdの内容が一旦/としてマウントされた状態になるんです。本来の/がマウントされる前にちょっとした処理ができるようになっている。 initrdのフォーマットは昔はext2とかのファイルシステムが圧縮されたものだったんですけど、最近はcpioが圧縮されたものになってます。通常このinitrdファイルを作るのはmkinitrdというコマンドで、中身はスクリプトになってます。特に難しいことはしていません。nashがinitとして動いてモジュールをロードしてデバイスを作り、マウントして/を切替えているだけです。 nashは大したスクリプト言語ではなく、条件判断もできませんが、insmodやmount、echo、sleepなどの内部コマンドの実行に加えて、外部コマンドを呼び出すことができます。mkinitrdが作るinitrdのnashスクリプトは、initrdの中に入っているディスクのドライバモジュールを読み込んでmountするわけです。サンプルを見たいなら、gzip+cpioでシステムのinitrdファイルを展開してスクリプトを見てみるといいです。man nashにも有用な情報が書いてあります。 initrdとnashを応用すればいろんなことができます。1FD LinuxやCDで上げるLinuxではけっこう変なinitrdが使われてるんじゃないかなという気がする。 ●カーネルのリコンパイルなしでNFS Rootを実現する 例えば、NICのドライバを読み込んで自分のIPアドレスを設定し、NFSのドライバを読み込んでNFSを/にマウントすることもできます(nashの内部マンドのmountはNFSに対応していないので外部コマンドとしてinitrdの中に入れる必要があります)。普通はNFSを/にするにはカーネルをリコンパイルする必要がある、とされていましたが、initrdに必要なドライバとスクリプトを入れておけばわざわざリコンパイルする必要はなく、ディストリビューションのカーネルをそのまま使うことができます(少なくともRed Hat Enterprise Linux 4系やFedora Core 3〜5は大丈夫でした)。 とは言え、システムにはNFSで他のマシンと共有できないディレクトリもありますので、Root環境を快適に使うにはもう少しの工夫は必要になります(大したことではないです。/var/runや/var/lock/subsys、/etc/mtabの処理とかそういう)。 NFSと同じ要領で、iSCSIを/にマウントすることもたぶんできます(iSCSIrootは私はやったことがないです)。 ●tmpfs rootでディスクレス環境 また、本来の/自体を全部initrdの中に埋め込んでおき、tmpfsを/にマウントしてファイルを展開してswitchrootしてディスクレス環境に、というのもなかなかおもしろいテクニックです(これが意外に快適なんです！)。 ●まとめ initrdはちょいと遊ぶに値するということを説明しました。面倒なので実例は出してませんが、暇ができたら遊んでみるといいと思いますよ。ブートローダにもよりますが、けっこう無謀なこともできちゃいますので。

私は現地に行けませんでしたが、丸亀にてシーズンは終了してしまいました。 3大大会全てでベスト4というのが川崎の年初の目標でしたが、ナビスコカップベスト4、リーグ2位といい調子でクリアしていったものの、天皇杯はベスト16止まりとクリアには至りませんでした。それでも上出来だとは思います。リーグ終盤に守備のバランスを大きく崩しながら、敢えて修正せずに勝点のみを追求してしまったのが裏目に出たんでしょう。最もプライオリティの高いリーグ戦でそれで表目(？)を出したわけで、特に文句はありませんよ。 注目の入替戦はアウェイゴールルールにより神戸が昇格。劇的でしたね。微妙なシーンもありつつ。 そんなこんなで、思っていたよりも少し長いオフになります。

長居第2に行ってきました。晴れるという予報だったはずだが、試合前に雨が降りはじめ、試合中はなかなかいい雨になった。地面が傾斜の芝生だったのだが泥んこにまではならなかった。芝生席のスタジアムって、ピッチの芝生と同じ芝生にしたらいいんじゃないかと思う。それならギリギリ許せるが、そうではない。青新聞でピンクに対抗。私は寒いし着替え持ってないし、風邪をひくわけにいかない状態なので、日和って上着を着込んで応援してしまいました(これは恥ですね)。逆に汗をかいて気持ち悪い。 この試合の状況としては最終節、セレッソは自動降格を避け入替戦に回るには福岡の成績を上回る必要があった。勝点差は1、得失点差は0。勝てばよいだけ。 川崎は3位以上は確定していて、あとは2位になれるかどうかというところ。すでに天皇杯の枠でACL(アジアチャンピオンズリーグ)出場を決めていた浦和が2重に権利を取った場合、リーグ2位になるとACLに出られるとか出られないとかいう話があるし、賞金も違うので勝つ意義はある。2位のガンバとの勝点差は2、得失点差は充分開いているので、川崎が勝ってガンバが負けるという場合のみを考えればよい。つまり両クラブとも引き分けを考える必要はないのだった。 試合のほうはよく見えなかった。得点経過は左からのクロスにファーから飛び込んだ飛弾がダイレクトで打って0-1、おめでとう。飛弾ががんばるので、飛弾のアッコちゃんをやったりしている内にジュニが0-2、前半ロスタイムに1-2、後半は黒津が再三のチャンスを外しつつ(黒津の動きは良くて、だいぶ効いてたと思うけどフィニッシュを外していた)セレッソもバーに当てたりして決めきれず、最後はカウンターからマルコン、ジュニ(？)が中に送り込んだボールを黒津が押し込み1-3。勝負あり。ほんと細かいところは全く見えなかったのです。 あちこちで携帯をチェックして歓声を上げる人もいつつ、こちらに挨拶に来る選手の様子で、2位になったことを知りました。おれたちと戦おう共に＆威風堂々。あとはですね、天皇杯も勝って某会長に文句を言わせないぞという決意をコールリーダーが示し、最後は恒例のバス囲みコール。なぜか微妙な西部警察をやると、箱乗り状態の選手バスはゆっくりと長居の公園を去っていった。ジュニにメッセージを見せていたけど後ろにいたので内容は分からない。 言っとくけど川崎にとってJ1準優勝というのは快挙だよ。すげーよすげーよ。まだ気持ちがフワフワしてますよ。 あとですね、初優勝の浦和もおめでとう。正直なところ浦和は大嫌いだが優勝してしまったことを覆すことはできない。柏も昇格決定おめでとう。岡山は3年連続で昇格させてるので、そろそろ伝説になってもよいのではないかと。 セレッソは福岡が引き分けたため、得失点差で自動降格。福岡は神戸との対戦になりますが熱くなりそうですね。