+ Webチャート
created 2004-06-14 modified 2004-06-23
Webチャート:1. Webチャートについて
Webチャート:2. 現状調査
Webチャート:3. 設計検討
Webチャート:9. メモ
1. Webチャートについて
Wikiで使える「再編集可能な」ドローツールを実現することを検討する。
(メモ:まだ実現してません。
進捗:FedoraCore1にはGTKのLibRSVGのツール、rsvgコマンドが入っていて
現状はここまで。)
(メモ2:2004/1/21
FedoraCore3に付属のrsvgは日本語文字列もちゃんと変換してくれる!
svgはWindowsのsodipodiで作成した。あとは...
アップロードしたら自動で rsvg するようにして、
// IMAGEタグで同名の.pngを表示するようにすればOK)
そこで:
移行を阻む致命的な原因として「デファクトスタンダードなドローツールがない」ことが考えられる。そこで、
Wikiで使える「再編集可能な」ドローツールを実現することを検討する。
それにラスタグラフィクス(=ペイント系)のほうがベクタグラフィクス(=ドロー系)より描画処理が短時間ですむ、という話(詳細未検証)もある。
A: 確かにペイント系の図表は問題ない。しかしここで求めるのは「再編集できる」「ドロー系の」図表。賢いコネクタが使えて、テキストをコピーペーストできるドローツールを使いたいということ。
決定的なものがないように見える。
Webチャートの現状調査?
Webチャートの設計検討?
決定事項:
(メモ:まだ実現してません。
進捗:FedoraCore1にはGTKのLibRSVGのツール、rsvgコマンドが入っていて
rsvg zzz.svg zzz.pngとやるとSVG→PNG変換してくれるのですが、テキストの位置がずれてしまいます。
現状はここまで。)
(メモ2:2004/1/21
FedoraCore3に付属のrsvgは日本語文字列もちゃんと変換してくれる!
svgはWindowsのsodipodiで作成した。あとは...
アップロードしたら自動で rsvg するようにして、
// IMAGEタグで同名の.pngを表示するようにすればOK)
それはなにか
WikiWikiWebと呼ばれるツールを使ってみると、かなり便利に使えることがわかった。これいいじゃん。そこで:
- 初期において、WWWはだれでも電子的に読める論文を書く道具として認知されていた時期がある。
- この考えを進めて、今後書く文書を特定アプリケーションでなくHTMLをベースにするものに移行することを検討する。
移行を阻む致命的な原因として「デファクトスタンダードなドローツールがない」ことが考えられる。そこで、
Wikiで使える「再編集可能な」ドローツールを実現することを検討する。
自己ツッコミ
Q: HTMLに図を埋め込む方法なんてすでにあるじゃないか?それにラスタグラフィクス(=ペイント系)のほうがベクタグラフィクス(=ドロー系)より描画処理が短時間ですむ、という話(詳細未検証)もある。
A: 確かにペイント系の図表は問題ない。しかしここで求めるのは「再編集できる」「ドロー系の」図表。賢いコネクタが使えて、テキストをコピーペーストできるドローツールを使いたいということ。
求める機能
必須事項
- Webベースで簡単に(チャートを含む)文書が書ける
- 書いた(チャートを含む)文書を後で修正できる
- チャートに対し、いわゆるドロー系ツールの操作(要素の拡大や縮小、移動、コネクタ設定、前後関係の変更)ができる
重視すること
- 軽快に動作する
- 誰もが読める。(特に表示において)特別なソフトのインストールを求めない
- 独自で作りこむのは最小限に。既存ソフトに付加するものを作る
現状
いろんなひとが同じようなことやら似たようなことを考えているが、決定的なものがないように見える。
Webチャートの現状調査?
設計検討
以下を検討した。- プラットフォーム
- 利用モデル
- 内部/外部データ形式
- 表示に関して
- 編集に関して
Webチャートの設計検討?
決定事項:
- 既存Wikiのプラグイン
- 外部データ形式として既存のベクタ画像フォーマットを利用可能にする
- 外部データ形式はユーザごとに設定可能にする
設計
ベースとするWikiクローンの選択
ベースとするドローフォーマットの選択
2. 現状調査
いろんなひとが同じようなことやら似たようなことを考えている。
IEにはVMLビューワがすでに組み込まれているし、MS Officeには
VML出力エンジンがすでに組み込まれている。
W3Cに「SVGと統合せよ」と蹴られて標準化されなかった。
特定企業のニオイがするフォーマットはGIFのようにだれにも見向きされなくなるという教訓なのか?
ちょっと痛快な話ではあるが、理想はともかく動くものが普及するのが遅れたかも。
アドビやコレルが無料のビューワプラグインを提供している。アドビのものは処理が重くて使いたくなくなる。
アニメーション機能が含まれているし、規格が肥大化する傾向にあるのかも。
Mingは.swfを出力できるフリーのライブラリ。
1フレームのみ利用することで、サーバ側で生成できる単なる画像フォーマット
として使える。
GDはpngやjpegを動的に描画するためのライブラリ。
ラスタ画像をサーバ側で生成する方式なら、これも候補にできる。
Link:Web透過なチャート関連
に移動した。
基礎
VML
Microsoft,Macromedia他の企業が標準化を提案したベクタフォーマット。XML。IEにはVMLビューワがすでに組み込まれているし、MS Officeには
VML出力エンジンがすでに組み込まれている。
W3Cに「SVGと統合せよ」と蹴られて標準化されなかった。
特定企業のニオイがするフォーマットはGIFのようにだれにも見向きされなくなるという教訓なのか?
ちょっと痛快な話ではあるが、理想はともかく動くものが普及するのが遅れたかも。
SVG
業界標準化が着々と進んでいるベクタフォーマット。XML。良くも悪くも。アドビやコレルが無料のビューワプラグインを提供している。アドビのものは処理が重くて使いたくなくなる。
アニメーション機能が含まれているし、規格が肥大化する傾向にあるのかも。
Flash(SWF), Ming
スプライトアニメーション用フォーマット。動作が軽快なので普及している。Mingは.swfを出力できるフリーのライブラリ。
1フレームのみ利用することで、サーバ側で生成できる単なる画像フォーマット
として使える。
PNG, GD
.pngはラスタ画像フォーマット。GDはpngやjpegを動的に描画するためのライブラリ。
ラスタ画像をサーバ側で生成する方式なら、これも候補にできる。
参考資料
リンクをここにメモしていたがLink:Web透過なチャート関連
に移動した。
3. 設計検討
案を列挙
プラットフォーム
- サーバはLinux。ロケールはUTF-8
- クライアントはWindowsXP + InternetExplorer。ただし…
利用モデル
- チャットやホワイトボードのモデル
- オフィススイートのモデル
内部/外部データ形式(ファイルフォーマット)
- VML
- SVG
- 独自フォーマット
表示に関して
- IEに標準で組み込まれているVMLビューワ
- Adobe や Corel のSVGビューワ
- Javaアプレットによるビューワ(独自作成)
- Flash(Ming)によるビューワ(データを動的にロード。独自作成)
- Flash(Ming)でチャート1枚ごとにおのおのファイルを出力
- ActiveXによるビューワ(独自作成)
- GDでPNGを動的(or静的)に出力。ビューワ側はペイント系データとして表示。
編集に関して
- 既存ツールを利用し、VMLやSVGのファイルを作成してからアップロードする
- Javaで独自作成
- OpenOfficeのドローツールを利用できないか?
- Flashで独自作成
プラットフォーム
まずは以下で実現し、- サーバはLinux。ロケールはUTF-8
- クライアントはWindowsXP + InternetExplorer
その後、クライアントとしてLinux + Mozillaも利用可能にする余地を残しておく。
想定シナリオをいくつか
- MS Officeからの移行。つまりMS Officeのドローツールがインストールされている環境
- MS Officeなんて利用しない環境
現実問題としてMS Officeから移行するひとに「だめだこりゃ」といわれないレベルは必要。
しかし、利用にはMS Office不要であるとうれしい、と。そういうこと。
利用モデル
チャットのモデル
要素ごとに送信すると他のユーザのビューにも反映する。ホワイトボードともいえる。もともとのアイデアはこのモデルで、やりたいことも「遠隔勤務で打ち合わせ」だった。
- SVGの1要素を「行」としてチャット風クライアントでアップロードし
- 時系列で並べられるように番号をつけてDBMSに保存
- サーバ側スクリプトで、ある時点以降の「行」をならべて出力する
- ビューワはSVGビューワ
よくよく考えるとこうした利用法が必要な場面は少ないな…。
これはこれで、あってもいいが。
オフィススイートのモデル
- なにかをクリックして編集開始
- ローカルのツールで編集して
- 1枚のチャート全体をアップロード
でもそれだと全員がSVGビューワをインストールしないと見れない?
サーバ側でパージングして内部フォーマットに変換、VMLでも出力可にする?
それは作業量が多いからいやだ…
ともあれ今回はこの「オフィススイートモデル」で進める。
内部/外部データ形式(ファイルフォーマット)
- 内部で保持するフォーマットと、ブラウザが取得(し、その後描画)するフォーマットは、必ずしも同じでなくてもいい。
- 外部フォーマットとして既存のものを採用すれば、好みのエディタで編集しアップロードする使い方もありうる。
- フリーで利用できないものは検討しない。
データ形式 | メリット | デメリット |
---|---|---|
VML | IE5から(?)標準でレンダラが組み込まれており、誰でも読める。 | W3Cで「SVGと統一化するように」と標準化を却下された。 |
SVG | W3Cで標準化され、デファクトスタンダードになりつつある。 | AdobeやCorelがフリーのビューワプラグインを提供しているが、動作が重い。プラグインをインストールする必要があり、「誰でも読める」かというと微妙。 |
その他既存フォーマット | ||
独自フォーマット | 内部では独自フォーマットでもち、外部にはユーザごとの希望フォーマットとする方法もある。こうすると外部フォーマットの変更に影響を受けにくくなる。 |
表示に関して
うひゃ編集に関して
うひゃまとめ
うひゃlibRSVGでSVGをPNGに変換する案が有力かな…
9. メモ
テスト画像。
(現在はpngを添付して、画像参照してるだけ。)
PassWikiにプラグインを足して、たとえばhoge.svg添付して
(最新のPassWikiでは、理論上保存時に作成できてしまうものも、ページ生成時に毎回つくる方針みたい)
でさらに、画像をクリックしたらsvgをダウンロードできるようなimageタグを出力してやればさらによいかな。
チャートの編集は、任意のツール(たとえばsodipodi ...っていうか最近はその派生のInkspaceのほうが発展してる?)でやればよいと。
(現在はpngを添付して、画像参照してるだけ。)
PassWikiにプラグインを足して、たとえばhoge.svg添付して
#RSVG(){hoge.svg,hoge.png}という本文を書いてやると、そのページを要求したときにサーバ側で
rsvg hoge.svg hoge.pngした結果のhoge.pngをページに埋めてくれればいいのかな。
#IMAGE(){sodi-test4.png}と同じようなhtml出力をすればおkと。
(最新のPassWikiでは、理論上保存時に作成できてしまうものも、ページ生成時に毎回つくる方針みたい)
でさらに、画像をクリックしたらsvgをダウンロードできるようなimageタグを出力してやればさらによいかな。
チャートの編集は、任意のツール(たとえばsodipodi ...っていうか最近はその派生のInkspaceのほうが発展してる?)でやればよいと。