Namazu-devel-ja(旧)

[Yukio USUDA <m6694ha392t@xxxxxxxxxxxxxxx>]

臼田です

Tadamasa Teranishi wrote:
> RTF の filetype が TEXT だったりします。ですので、filetype だけ
> で、text/plain とすると誤認します。(たぶん)
filetype が 'TEXT'の場合はtext/plainにせずにundefにすることにします。

> # data/ja-mac/textedit.rtf の filetype は空です。ごめんなさい。
> # あまり良いサンプルでなくて。
このサンプルはcreatorも空ですね
これはmacのアプリでないもので作成されたファイルですか？


> ちなみに UNIX extensions and Macintosh Creator/Type mapping database
> が、 http://ext.comitas.no/?page=10&prpage=20  にあります。
> # この内容も随分抜けがあったり、古かったりするのですが...。
たくさん集められていますね。

macbinay.pl内ではファイル名の拡張子でしか判定できないOLE系のファイル
だけ特定しておき、あとは通常処理にまかせて判定させようと思います。
excel,word,powerpoint,一太郎の全バージョンでのfiletypeがわかれば
とりあえず安心ですが、上記の中には全部はなさそうですね。

> もうちょっと実用的なサンプルデータを集めて、実用上問題のない
> ところまで対応するというのが良いのでしょうね。
> 
> 常に filetype と creator のペアで比較するというのも、creator 違いで
> 同じメディアタイプもあるだろうから、面倒といえば面倒ですしねぇ。
creatorではファイルタイプは特定できないからまずいですね。
（wordで出力されたplaintextファイルもあるということですね）

Mac上のアプリケーションがfiletypeを適切につけていることは信頼できる
のではと考えているので、filetypeの一覧を充実させるということですね。


> > > ppthtml の問題なら powerpoint4.ppt を削除するということで
> > > 良いかもしれません。
> > Automakeは失敗することが予定されているテストというのは定義
> > できないのですかね？
> 詳しくないですが、可能だったのではないかと、思います。
> # あんまり自信ないけど。
要勉強ですね。


> > ヘッダだけ出力して止めてしまうというのは正常動作ではないので
> > リターンコードが異なっているかもしれません。
> > 少しソースを見るなりして試してみます。
試しました
xlhtml0.5に付属のppthtmlに
tests/ja-mac/powerpoint4.pptをそのまま
処理させた場合はexit 256とエラーコードが返ってくるのですが、

tests/ja-mac/powerpoint4.pptのヘッダを除いたファイル
を処理させた場合、exit 0 が返ってきました。
前述のとおり本文は出力されませんが、エラーメッセージも出ません。
そのため
tests/ja/powerpoint97.ppt
を処理させた場合の exit 0 という正常時と区別がつきません。

ちなみに、tests/ja/excel98.xls
を処理させた場合はエラーメッセージが出るのですが
exit 0 が返ってきました。

ppthtmlにはオプションも全くありません。
ppthtmlを使っている限りでは
powerpoint.plで旧バージョンのpowerpointファイルを判定して
除外するのは困難だと思われます。


> とか、本文が空だと思える場合ははじくとかですかね。でも。
とりあえず対応してもppthtmlの出力するhtmlのヘッダ部分が今後の
バージョンで変わればうまくいかなくなりそうです。

> > > doccat も対応していないようなら削除しても良いかもしれません。
> 
> 対応してなさそう。
> 
> powerpoint4 って随分と古いので、これをはじくための処理をわざわざ
> するまでもないような気はしてきました。
> powerpoint4 が現存する確率は低いだろうし。
powerpoint4はあきらめようと思います。


> > > これを応用すれば、gzip や compress, bzip2 にも使えるわけですね。
> > 他にもE-mailの添付ファイルやmhtファイルの展開に使えるのではと
> > 思っています。
> 
> 添付ファイルが複数だったりした場合でも対応可能そうなんですね。
> それはすごい。
> なら、lha とか tar とかアーカイブ系にも応用が効きそう。
> って、元々それ用に追加された機能か。
私の発想は
filterモジュールの中でアーカイブを展開してループを回し
mknmz::apply_filter()に分割したcontentを渡して返って来た結果を結合
していけばよいかなというものです。

野首さんの準備しているArchiveモジュールはfilterモジュールに渡す前に
アーカイブを展開して各contentにuriをつけてあげてからインデックスにする
というしっかりとした実装で将来性がありそうに思えます。

> > Archive内のファイルについてはgnome-vfsのschemeのような表記で
> > uriを示す処理を考えているのではと思っていますので、野首さんの
> > ご意見をうかがって続きを考えようと思っております。
> 
> へぇ。よければ、gnome-vfsのschemeってどんなものかわかる uri を
> 教えていただければうれしいです。
私もくわしくありません。
mknmzの中に出てくるキーワードだけでいろいろ探してこれだろうと思っ
ているだけです。

ローカルファイル以外のものも共通に扱うように抽象化しアーカイブ中の
ファイルも同様にアクセスさせる予定なのではと思っています。
gnome-vfsの紹介記事
http://japan.linux.com/desktop/03/05/25/1710208.shtml
gnome-vfsのAPIドキュメントからコンセプト部分
http://developer.gnome.org/doc/API/gnome-vfs/writing-modules.html

こんな表記がサンプルに出ていますが
ftp://username:password@xxxxxxxx/path/to/file.tar.gz#gzip#tar/path/to/hello.c
Nautilus以外のブラウザはこのuri？を処理できないようにも思えるので
具体的にどういうものにする予定なのか野首さんのご意見をお聞きしたい
です。

臼田幸生