[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[OSASK 724] Re: フォーマットについて(Re: ssizz1).



やっほぉ、<川合の旦那>
[2000年6月2日(金)]にもろた
【[OSASK 719] フォーマットについて(Re: ssizz1).】への返答っ! 。

川合>  OSASKの普通のアプリケーションは、たった1種類のフォーマットし
川合>かサポートしません。たとえば、あるグラフィックビュワーは、BMPし
川合>かサポートしていないとしましょう。
川合>  このアプリケーションは、シェルに、「私はBMPしかデコードできま
川合>せん」と通達します。そうすると、あら不思議、このアプリケーション
川合>で、JPEGやGIF、TIFFなどが見られるようになってしまうのです。シェ
川合>ルはファイルをアプリケーションに回す際に、フォーマットが不一致な
川合>ら、フォーマットコンバーターを勝手に呼び出し、コンバートしたファ
川合>イルを渡すのです。なお、このコンバーターさえ充実させれば、テキス
川合>トファイルやhtmlファイル、ワード文章も「ビュー」できます(全部、
川合>表示イメージをBMPとしてコンバートする)。さらに、音楽ファイルを
川合>「ビュー」したら、楽譜が出てきたりすると最高ですね。

イメージ的には全然逆方向かもしれないけど、SUSIEのプラグインみたいな
ものがShellとしてサポートされる(する)ってことだよね?

で、この場合コンバーターが変換をかける際に、中間的な部分
(例えばTIFF→BMP→JPGのときのBMPとか)が必要だと思うんだけど
(もちろんファイルコンバーター同士をつなげてもいいだろうけど)
その中間となるフォーマットとかってどうするの?

中間フォーマットを使う場合
利点:ユーザーはコンバーターのコンバーター、というようなものを
   探す手間などが不要。優秀な中間フォーマットであれば
   コンバートによる劣化や手間の省略が可能
   変換経路が短い。
欠点:汎用性が薄れる。中間フォーマットの変更は多大な作業を伴う。

中間フォーマットを使わない場合
利点:異種データ変換は個別対応可能。フォーマットに合わせた変換を
   行えるので変換効率はよい(かもしれない)。
   汎用性は高い。
欠点:変換経路が長くなるおそれがある。コンバーターの為のコンバーターという
   状況が生じる。

おそらく、初期はOSASK用と称して中間フォーマット(もちろん既存でもよい)を
明示して、コンバーターのしくみを示し、後は流れに任せる、って所かな?
ただし、コンバーターのコンバーターという状況は、ユーザーにとって
結構面倒なことになるのでは?
#それこそShellサービスで導入を促すような形にすればいいんだろうけど。

あと、変換経路は自動or手動での切り替えがほしい人も多いだろうね。

川合>  ですから、OSASKにおいては、新しい音楽ファイルフォーマットを標
川合>準にするために、かっこいいプレイヤーを作らなくてもいいんです。コ
川合>ンバーターさえ作ればいいわけです。

コンバーターがサポートするべき(変換するべき)フォーマットを規定するのも
なんだし、おそらく既存のコンバーターを頼りに・・・ってのが続きまくるような
気がするのは気のせいだろうか?

川合>  逆に、プレイヤー作者も、自分がプログラムしやすいフォーマットだ
川合>けサポートすればいいんです。後は、コンバーターに任せましょう。

これは作る側は楽だよね。
#まあ、コンバーターを用意した段階でサンプルと称して付けてくるものも多そうだけど。



でわでわ

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/  氏名:もしかしたら橋 直行                                      _/
_/  E-mail:n-hashi !Atmark! interlink.or.jp,PXW06256 !Atmark! nifty.ne.jp             _/
_/_/_/_/_/_/_/_/_/_/_/_/_/-----平成12年06月03日(土曜日) AM12時50分_/_/