2004シーズンはまるでカモのような存在だった横浜。しかし高木監督のもと強固な守備を手に入れてJ1に上がってきました。というわけでロースコアでじりじり時間が過ぎていく展開になると思いきや、ガンガン点が入りました。お祭り騒ぎですな。 ジュニの先制点(フリーで持ってドリブルで上がりエリア付近に近づきコースを狙ったミドル)がでかかったですね。あれで楽に戦えるようになりました。あと黒津のゴール(2点目。囲まれながら落ち着いて左足を振り抜きファーに)はすごかったな。勇介(交代に不満を示してボトルを蹴り上げて2枚目のイエロー)はどうかと思いましたね。そこまでのプレーも良くなかった。今年も悪癖は修正できないみたいな感じ？ ディフェンスは出足も鋭くシュートもほとんど打たせなかったため川島の見せ場はなし。このチームは村上が攻守に効いてますね。マギヌンの運動量も多く効果的。谷口の不在を埋めた河村もなかなか良かったです。 今日は特に寒くて大変でした。神戸より寒かった。この時期に夜にゲームをやるのはどうかと思いましたね。Ｇゾーンで応援してる人はいいんでしょうけど、座ってる人にとっては辛かったと思います(私は故あって座ってました)。 「エスを狙え」については…特に私がコメントすることはありません。

今日は2007シーズン開幕戦、2階席で見てました。 歌詞カードを見ると、新曲が2曲発表されたようだ。1曲しか聞いてないが、メロディを思い出したり忘れたりしている。今は忘れているところ。今年もコールリーダーは西野君のようです(私の席からは上半身だけ見えていた)。 久しぶりの等々力はほぼ満員に。開門くらいに到着すると7番ゲートの末尾はゲートボール場に達し、ゲートボール場内で幾重にも折り返されていた。常に観客動員を気にするキャプテン伊藤宏樹をして「あのお客さんの入りで2万人ですか（20,295人）。もっと入ってるのかと思いました(jsgoal.jp)」と言わせるほどの客入り。みんな試合を待ち望んでいたんだなぁ。 スタジアムではとりあえず新発売(？)のドーナツを食いつつ、ファンキーズのホットドッグはトッピングが自分でできるように改良されていたのでひとまずカレー味を食し、試合を待つ。ほどなくして座席が次々に埋まり、川島が出てきて試合前の練習を始めた。 試合のほうは昨年鬼のようなキープ力を誇った我那覇がすぐに囲まれ、前線でのキープに苦しんだこともあって、序盤はかなり鹿島ペースで進んだ気がするが守備意識が高くチャンスを作らせない。このへんで昨年との違いを見せてくれる予感を感じさせた。守備陣は試合が終わるまでバランスを崩すことなく集中を続け、昨年はあまり見ることができなかった無失点試合を達成。終盤にはジュニを引っかけた鹿島のDFが2枚目のイエローで退場に。鹿島は川崎戦で退場になることが多いですよね。 鹿島はキャプテンマークは柳沢が巻いていた(川崎は憲剛)。得点シーンは右サイドで粘って得たボールが中央の憲剛を経由して左サイドの村上へ。村上が放りこんだボールは正確にファーサイドのマギヌンの頭にヒットしたもの。 流すのが大好きな吉田主審の流しに対応しきれないシーンが気になったなぁ。終盤に箕輪がセルフジャッジしたシーンなど。この試合は荒れ気味な時間もあったけど、ACLを考えると綺麗にやることに固執するほうが危険なように思う。欲を言えば何度かあったチャンスにジュニが決めてほしかった。本人も決めて気分良く終わりたかったろう。交替は我那覇に代えてテセ、村上に代えて西山。テセは悪くない動き。西山は残念ながらなかなか試合に入りきれず。 次は水曜にインドネシアでアレママラン戦(行けず)、その次の日曜はアウェイ神戸戦です(これは行くつもり)。

ひとつ前の続き。 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"),