+ Webチャート

last mod.2022/01/17

Webチャート:1. Webチャートについて
 Webチャート:2. 現状調査
 Webチャート:3. 設計検討
 Webチャート:9. メモ

1. Webチャートについて

Wikiで使える「再編集可能な」ドローツールを実現することを検討する。

(メモ：まだ実現してません。
進捗：FedoraCore1にはGTKのLibRSVGのツール、rsvgコマンドが入っていて

rsvg zzz.svg zzz.png

とやるとSVG→PNG変換してくれるのですが、テキストの位置がずれてしまいます。
現状はここまで。）

(メモ２：2004/1/21
FedoraCore3に付属のrsvgは日本語文字列もちゃんと変換してくれる！
svgはWindowsのsodipodiで作成した。あとは...
アップロードしたら自動で rsvg するようにして、
# IMAGEタグで同名の.pngを表示するようにすればOK)

WikiWikiWebと呼ばれるツールを使ってみると、かなり便利に使えることがわかった。これいいじゃん。
そこで：

初期において、WWWはだれでも電子的に読める論文を書く道具として認知されていた時期がある。
この考えを進めて、今後書く文書を特定アプリケーションでなくHTMLをベースにするものに移行することを検討する。

移行を阻む致命的な原因として「デファクトスタンダードなドローツールがない」ことが考えられる。そこで、
Wikiで使える「再編集可能な」ドローツールを実現することを検討する。

Q: HTMLに図を埋め込む方法なんてすでにあるじゃないか？

それにラスタグラフィクス（＝ペイント系）のほうがベクタグラフィクス（＝ドロー系）より描画処理が短時間ですむ、という話（詳細未検証）もある。

A: 確かにペイント系の図表は問題ない。しかしここで求めるのは「再編集できる」「ドロー系の」図表。賢いコネクタが使えて、テキストをコピーペーストできるドローツールを使いたいということ。

Webベースで簡単に（チャートを含む）文書が書ける
書いた（チャートを含む）文書を後で修正できる
チャートに対し、いわゆるドロー系ツールの操作（要素の拡大や縮小、移動、コネクタ設定、前後関係の変更）ができる

軽快に動作する
誰もが読める。（特に表示において）特別なソフトのインストールを求めない
独自で作りこむのは最小限に。既存ソフトに付加するものを作る

いろんなひとが同じようなことやら似たようなことを考えているが、
決定的なものがないように見える。

Webチャートの現状調査?

以下を検討した。

プラットフォーム
利用モデル
内部/外部データ形式
表示に関して
編集に関して

Webチャートの設計検討?

決定事項：

既存Wikiのプラグイン
外部データ形式として既存のベクタ画像フォーマットを利用可能にする
外部データ形式はユーザごとに設定可能にする

2. 現状調査

いろんなひとが同じようなことやら似たようなことを考えている。

Microsoft,Macromedia他の企業が標準化を提案したベクタフォーマット。XML。
IEにはVMLビューワがすでに組み込まれているし、MS Officeには
VML出力エンジンがすでに組み込まれている。
W3Cに「SVGと統合せよ」と蹴られて標準化されなかった。
特定企業のニオイがするフォーマットはGIFのようにだれにも見向きされなくなるという教訓なのか？
ちょっと痛快な話ではあるが、理想はともかく動くものが普及するのが遅れたかも。

業界標準化が着々と進んでいるベクタフォーマット。XML。良くも悪くも。
アドビやコレルが無料のビューワプラグインを提供している。アドビのものは処理が重くて使いたくなくなる。
アニメーション機能が含まれているし、規格が肥大化する傾向にあるのかも。

スプライトアニメーション用フォーマット。動作が軽快なので普及している。
Mingは.swfを出力できるフリーのライブラリ。
１フレームのみ利用することで、サーバ側で生成できる単なる画像フォーマット
として使える。

.pngはラスタ画像フォーマット。
GDはpngやjpegを動的に描画するためのライブラリ。
ラスタ画像をサーバ側で生成する方式なら、これも候補にできる。

リンクをここにメモしていたが
Link:Web透過なチャート関連
に移動した。

3. 設計検討

サーバはLinux。ロケールはUTF-8
クライアントはWindowsXP + InternetExplorer。ただし…

チャットやホワイトボードのモデル
オフィススイートのモデル

VML
SVG
独自フォーマット

IEに標準で組み込まれているVMLビューワ
Adobe や Corel のSVGビューワ
Javaアプレットによるビューワ（独自作成）
Flash(Ming)によるビューワ（データを動的にロード。独自作成）
Flash(Ming)でチャート１枚ごとにおのおのファイルを出力
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の１要素を「行」としてチャット風クライアントでアップロードし
時系列で並べられるように番号をつけてDBMSに保存
サーバ側スクリプトで、ある時点以降の「行」をならべて出力する
ビューワはSVGビューワ

よくよく考えるとこうした利用法が必要な場面は少ないな…。
これはこれで、あってもいいが。

なにかをクリックして編集開始
ローカルのツールで編集して
１枚のチャート全体をアップロード

てか、これなら添付ファイルで.svgをＯＫにすればいいだけじゃん。
でもそれだと全員がSVGビューワをインストールしないと見れない？
サーバ側でパージングして内部フォーマットに変換、VMLでも出力可にする？
それは作業量が多いからいやだ…

ともあれ今回はこの「オフィススイートモデル」で進める。

内部で保持するフォーマットと、ブラウザが取得（し、その後描画）するフォーマットは、必ずしも同じでなくてもいい。
外部フォーマットとして既存のものを採用すれば、好みのエディタで編集しアップロードする使い方もありうる。
フリーで利用できないものは検討しない。

データ形式	メリット	デメリット
VML	IE5から(?)標準でレンダラが組み込まれており、誰でも読める。	W3Cで「SVGと統一化するように」と標準化を却下された。
SVG	W3Cで標準化され、デファクトスタンダードになりつつある。	AdobeやCorelがフリーのビューワプラグインを提供しているが、動作が重い。プラグインをインストールする必要があり、「誰でも読める」かというと微妙。
その他既存フォーマット
独自フォーマット	内部では独自フォーマットでもち、外部にはユーザごとの希望フォーマットとする方法もある。こうすると外部フォーマットの変更に影響を受けにくくなる。

うひゃ

うひゃ

うひゃ

libRSVGでSVGをPNGに変換する案が有力かな…

9. メモ

テスト画像。

（現在はpngを添付して、画像参照してるだけ。）

PassWikiにプラグインを足して、たとえばhoge.svg添付して

#RSVG(){hoge.svg,hoge.png}

という本文を書いてやると、そのページを要求したときにサーバ側で

rsvg hoge.svg hoge.png

した結果のhoge.pngをページに埋めてくれればいいのかな。

#IMAGE(){sodi-test4.png}

と同じようなhtml出力をすればおｋと。

（最新のPassWikiでは、理論上保存時に作成できてしまうものも、ページ生成時に毎回つくる方針みたい）

でさらに、画像をクリックしたらsvgをダウンロードできるようなimageタグを出力してやればさらによいかな。
チャートの編集は、任意のツール（たとえばsodipodi ...っていうか最近はその派生のInkspaceのほうが発展してる？）でやればよいと。