修士論文
Rabbit
プログラマのプレゼンテーションツール
岩手大学大学院 工学研究科 博士前期課程 情報システム
工学専攻
氏名 23604019 須藤功平
指導教官 西谷泰昭 教授
2006 年 2 月
概要
プログラマはマウスを多用したスライド作成,バージョン管理のしづらいファイルフォーマット
は好まない.また,プログラマはソフトウェアに高いカスタマイズ性を求める.しかし,既存のプ
レゼンテーションツールはこれらの性質を満たしておらず,プログラマにとって使いやすいもので
はない.
一般的なユーザを想定して作成したソフトウェアよりも,特定のユーザを想定し,そのユーザに
特化して作成されたソフトウェアの方が,そのユーザにとって使いやすい.本稿では特定のユーザ
としてプログラマを想定した,プログラマの求める性質を満足するプログラマのプレゼンテーショ
ンツール Rabbit を提案する.
i
謝辞
本研究を進めるにあたり,ご指導を頂いた計算機システム学講座西谷泰昭教授に心から感謝いた
します.
博士後期課程 3 年の東大野先輩には新機能や新テーマに関するアイディアをたくさんいただきま
した.その中には極めて斬新で直感的なインターフェイスの提案もあり,Rabbit の普及に大きく貢
献しています.その類稀な発想に心から感謝いたします.
研究室の OG である澤口さんにはマスコットキャラクタ Lavie や Rabbit のバナーなどたくさん
のかわいい画像を描いていただきました.初期の Rabbit のスライドは画像を用いておらず,とて
も殺風景なものでした.彼女の描いてくれた画像を用いることで,スライドが華やかになり,とて
も見栄えのするものになりました.その画力を Rabbit のために使っていただき,心から感謝いた
します.
博士前期課程 1 年の袖林君にも Rabbit のための画像を描いていただきました.彼の描いてくれ
たうさぎとかめの画像を用いることにより,東大野さんからいただいたアイディアを実現できまし
た.このアイディアは今では Rabbit の最も特長となる機能のひとつとなっています.この機能の
おかげで Rabbit が注目されたことが多くありました.面倒臭いと言いながらも素晴らしいうさぎ
とかめを描いてくれたことに感謝いたします.
荒木徹助手には一般的なプレゼンテーションに必要な機能など,実際にプレゼンテーションを行っ
て感じていることについて,貴重な意見をいただきました.荒木助手からの意見がなければ,既存
のプレゼンテーションツールにあるよいところを取り込んでおらず,ユーザビリティの低いソフト
ウェアになっていたことでしょう.いつも冷静に客観的な意見をいただき,心から感謝いたします.
今まで使っていたプレゼンテーションツールから Rabbit に乗り換える日も近いとのことです.
博士前期課程 1 年の滝沢君は Rabbit を開発するきっかけを与えてくれました.Rabbit を開発し
て本当によかったと思っています.きっかけを作ってくれたことに感謝いたします.
研究室ではデファクトスタンダードのプレゼンテーションツールとして Rabbit を使用していた
だきました.このためにバグを発見することができたこと,またユーザビリティに関する意見,新
機能のアイディアなどもいただいたことに感謝いたします.
Rabbit を用いてプレゼンテーションを行っていただいているかずひこさんや角谷さんなど Rabbit
ユーザの方々に感謝いたします.かずひこさんの宣伝により Rabbit の知名度があがりました.角
谷さんには新機能などへの貴重なリクエストだけではなく,Rabbit を用いた衝撃的なプレゼンテー
ションを行っていただいています.両人には Rabbit 普及のきっかけを作っていただき,心から感
謝いたします.
iii
鈴木助教授にはソフトウェア開発,ネットワークに関して,議論していただきました.周囲の人
達とはなかなかこのような話をできないため,非常に有意義でした.また,COZMIXNG の立ち上
げを支援してくれただけではなく,講義でも COZMIXNG のサービスを利用していただいていま
す.心から感謝いたします.
日頃よりお世話になりました,平山貴司講師,吉田功技官,そして研究室の方々に深く感謝しま
す.みなさまの一言一言がよい刺激であり,また,みなさまの存在が心の支えであったため,研究
を進める原動力となりました.
2006 年 2 月 23604019 須藤功平
iv
目次
概要
i
謝辞
iii
第 1 章 序論
1
第 2 章 既存のプレゼンテーションツール
3
3
2.1
2.2
2.3
WYSIWYG 型プレゼンテーションツール . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
2.1.2
スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3
2.1.4
2.1.5
プレゼンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
テキスト型プレゼンテーションツール . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
2.2.2
スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3
2.2.4
プレゼンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
その他のプレゼンテーションツール . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1
2.3.2
Goby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
less プレゼン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
第 3 章 採用するべき機能
3.1
3
4
4
4
5
6
6
7
7
8
8
8
9
11
スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1
3.1.2
人が可読なマークアップ言語の採用 . . . . . . . . . . . . . . . . . . . . . . . 11
編集モードの提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3
3.1.4
多言語サポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.5
3.1.6
3.1.7
多くの画像フォーマットのサポート . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.8
マルチプラットフォームサポート . . . . . . . . . . . . . . . . . . . . . . . . 19
インターフェイスの国際化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
数式のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
表のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
v
3.2
スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1
3.2.2
3.2.3
3.3
3.4
自動再読み込み機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
校正支援モードの提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
スライド一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
プレゼンテーション
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1
コメント印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
第 4 章 新しく開発する機能
4.1
23
スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ソース入力インターフェイスの抽象化
4.1.1
4.1.2
. . . . . . . . . . . . . . . . . . . . . 23
ソースエンコーディングの自動変換機能 . . . . . . . . . . . . . . . . . . . . 24
4.1.3
4.1.4
コードの自動色付け機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
見栄えの分離 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2
スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 自動再読み込み機能の強化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 段階的ソース読み込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3
プレゼンテーション
4.3.1
4.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
スライド移動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2
4.3.3
4.3.4
キーボードカスタマイズ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.5
4.3.6
覗き穴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
マウスインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
マウスジェスチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
レンダリングされたページのキャッシュ . . . . . . . . . . . . . . . . . . . . . 32
4.3.7 コメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1 描画機能を抽象化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
第 5 章 外部インターフェイス
5.1
35
dRuby インターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2
5.3
XML-RPC インターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
SOAP インターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4
5.5
インターフェイスの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5.1
専用 Web サーバの提供
5.5.2
5.5.3
サーバモードの提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
RWiki との連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
vi
第 6 章 テーマ
6.1
6.2
テーマ記述
6.2.1
6.2.2
6.2.3
6.3
6.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
宣言的記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
要素選択記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
フック記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
値の正規化
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
テーマの使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.4.1 自動再読み込みの強化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.4.2
6.4.3
6.4.4
6.4.5
6.4.6
6.5
41
テーマ記述言語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
タイマー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
スライド数表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
画像 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
デバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.4.7 テーマの合成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
テーマの動的変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
第 7 章 実装
7.1
7.2
7.3
7.4
55
段階的ソース読込 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
外部インターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
レンダリングモジュールの抽象化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3.1
出力種類の関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.2
7.3.3
拡張可能性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
出力種類の抽象化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
テーマ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.4.1
7.4.2
テーマ評価環境の提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
レシーバの差し替え . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
第 8 章 結論
8.1
63
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.2
今後の課題
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
索引
67
vii
図目次
4.1
4.2
マウスジェスチャのユーザインターフェイス . . . . . . . . . . . . . . . . . . . . . . 31
4.3
コメント表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1
mgp と mgpnet の連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2
5.3
Rabbit と Rabrick の連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Rabbit と RWiki の連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1
6.2
ワイルドカードの表す範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3
うさぎとかめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1
段階的ソース読込 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2
7.3
7.4
テーマ適用中もイベントを処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.5
暗黙の 2 段階レシーバ差し替え . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
覗き穴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
基準座標と残りの幅と残りの高さの関係 . . . . . . . . . . . . . . . . . . . . . . . . 48
外部インターフェイスの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
レンダリングモジュールの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
ix
表目次
8.1
プレゼンテーションツールの比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
xi
1
第1章
序論
使いやすいアプリケーションを開発するには,使用ユーザを限定し,そのユーザの利便性を意識
するとよい.誰もが使いやすいように開発されたアプリケーションよりも,特定のユーザのために
開発されたアプリケーションの方が特定のユーザにとって使いやすい.
現在,プログラマのために開発されたプレゼンテーションツールは存在しない.また,プログラ
マに好まれそうな既存のプレゼンテーションツールではプログラマは満足しない.本稿では,プロ
グラマのプレゼンテーションツール Rabbit を提案する.
ここで,プログラマとは以下のような人物であり,その代表的なモデルは筆者自身である.
• Visual Studio[7] などの IDE よりも高度にカスタマイズが可能な Emacs[30] や Vim[20] など
のエディタを好む.
• マウス操作よりもキーボード操作を好む.
• 高いカスタマイズ性を好む.
• 新しい技術,その応用システムに興味を持つ.
プレゼンテーションツールは大きく以下のふたつの種類にわけることができる.
• WYSIWYG 型
• テキスト型
WYSIWYG 型とは OpenOffice.org の Impress[13],GNOME の Criawips[12],KDE の KPresenter[35],Apple の Keynote[2],Microsoft Office の PowerPoint[6] のようにアプリケーション上でス
ライドの作成から表示までを行うタイプのプレゼンテーションツールである.WYSIWYG 型のプ
レゼンテーションツールではマウスを用いて GUI でスライドを作成するものが多い.
テキスト型とは MagicPoint[24],Pyslide[4],prosper[9],less プレゼン [29] のようにスライド用
のソースファイルはアプリケーションとは別の任意のエディタで作成し,そのソースを用いてアプ
リケーションがスライドの表示を行うタイプのプレゼンテーションツールである.
プログラマは自分の手に馴染んだエディタを用いることを好む.そのため,スライド作成には
WYSIWYG 型の編集インターフェイスをもったプレゼンテーションツールよりも自分の好きなエ
ディタを用いるテキスト型を好む.また,既存の各種テキスト処理用ユーティリティやバージョン
第 1 章 序論
2
管理のしやすいテキストファイルを好む.例えば,grep による文字列検索や diff によるバージョ
ン間の差分表示である.よって,Rabbit はテキスト型を採用する.
プログラマはアプリケーションがキーボードによるインターフェイスを提供することを好む.ま
た,アプリケーションが提供するキーバインドを変更できることを好む.よって,Rabbit では豊富
なキーバインド及びキーバインドのカスタマイズ機能を提供する.
プログラマはキーバインドだけではなくアプリケーション自体をカスタマイズできることを好む.
よって,Rabbit を「本物の」プログラミング言語を用いてカスタマイズできるようにする.
プログラマはさまざまな技術を応用してシステムを構築することに興味を持つ.よって,Rabbit
は外部のアプリケーションやライブラリと協調し,システムを構築しやすくするためのインターフェ
イスを提供する.
まとめると,本稿では以下の条件を満たすプレゼンテーションツール Rabbit を提案する.
• テキスト型である.
• 豊富なキーバインドを提供する.
• キーバインドは変更可能である.
• プレゼンテーションツールをカスタマイズするために「本物の」プログラミング言語を提供
する.
• 外部アプリケーション/ライブラリへのインターフェイスを提供する.
以降の章では,まず,WYSIWYG 型とテキスト型それぞれについて考察する.それらに当ては
まらない既存のプレゼンテーションツールについてはその後に考察する.続いて,既存のプレゼン
テーションツールの考察結果から,Rabbit が提供するべき機能を考察する.その後,既存のプレゼ
ンテーションツールには存在しない,Rabbit が提供するべき機能,およびその実装について述べ
る.最後に Rabbit と既存のプレゼンテーションツールとの違いを考察し,今後の展望を述べる.
3
第2章
既存のプレゼンテーションツール
本章では既存のプレゼンテーションツールを以下のように分類し,考察する.
• WYSIWYG 型
• テキスト型
最後に,どちらにも分類することが難しい既存のプレゼンテーションツールを考察する.
2.1
WYSIWYG 型プレゼンテーションツール
現在もっとも一般的なプレゼンテーションツールのタイプは WYSIWYG 型である.WYSIWYG
型はスライドの作成から表示まですべてアプリケーション自身で行う.
本章では以下の視点から WYSIWYG 型を考察する.
• スライドの作成方法
• スライドの校正方法
• プレゼンテーションの方法
• スライドの印刷
2.1.1
スライド作成
WYSIWYG 型ではプレゼンテーションツールにスライドを作成するためのインターフェイスが
ある.
まず,マウスでスライドのテンプレートを選択する.
次に,スライドを作成する.テンプレート中にはテキストを入力するための領域があり,そこを
クリックしテキストを入力する.図はマウスで使用する図を選択し,配置する.ドラッグで図のサ
イズを調整できる.表も同様に挿入できる.また,スライドには表示しない発表者用の注釈も関連
付けることができる.注釈スペースは単なるテキストエリアなので,マウスで選択し注釈を入力で
きる.これらを繰り返しスライドを作成する.
必要な枚数だけ上記のようにスライドを作成する.
第 2 章 既存のプレゼンテーションツール
4
2.1.2
スライド校正
スライドを作成したら,よりよいスライドにするために全体を見直し,調整を行う.
スライドの順序はスライド一覧画面などでマウスドラッグにより変更できる.また,スライドの
スタイルを変更して全体の見栄えを変更したり,スライド移動の際の効果を設定することができる.
全体の流れを見直すためにスライドからテキストとその構造のみを抜き出したアウトライン表示
ができる.ここでは,マウス操作で箇条書きのインデントレベルを変えたり,テキストの移動がで
きる.
2.1.3
プレゼンテーション
マウスによるメニュー選択,またはショートカットキーにより作成したスライドを全画面表示で
表示する.
プレゼンテーション中に使用できる機能を以下に示す.
• スライド移動
• プレゼンテーション終了
プレゼンテーションツールによっては以下の機能もサポートしている.
• スライド書き込み
• 一時的にスライドを白くするホワイトアウト
• 一時的にスライドを黒くするブラックアウト
スライド表示モードではマウスクリックまたはキーボードの矢印キーでスライドを移動する.
キーボードからはスライド移動,プレゼンテーションの終了など基本的なコマンドのみが実行可
能である.プレゼンテーションツールがホワイトアウト,ブラックアウトをサポートしている場合
はそれらも実行可能である.
マウスでは,クリックによるスライド移動,ポップアップメニューを使用してのコマンド起動が可
能である.スライド書き込み機能をサポートしているプレゼンテーションツールではマウスドラッ
グでスライドに書き込みを入れることができる.
2.1.4
印刷
観客用にスライド一覧を配布したり,発表者自身のメモのためなどにスライドを印刷する機能が
ある.WYSIWYG 型では以下のような印刷種類がサポートされている.
2.1. WYSIWYG 型プレゼンテーションツール
5
配布用 1 ページに 1 枚のスライドを配置する印刷方法である.発表者がメモ書き用や練習用に用い
ることもあるが,PDF 形式としてファイルに保存し,プレゼンテーションの後に資料を配布
する場合に用いることもある.
資料用 1 ページに複数枚のスライドを配置する印刷方法である.スライドを複数枚配置するため,
印刷されるスライドはサムネイルとなる.
この印刷方法で印刷した資料は,会場が大きい場合や,スライド中の文字が小さい場合など,
発表者の画面ではなく手元の資料を参照してもらうために当日会場に来ている観客に配布する.
あるいは,プレゼンテーション内容をメモしなくてもすむための資料として配布することも
ある.こうすることによって観客をプレゼンテーションに集中させることが期待できる.一
方,観客が発表者の画面ではなく配布資料ばかりを見て発表者の動きなどに注目させること
が難しくなる場合もある.
発表者用 1 ページにスライドのサムネイルとそのスライドへの注釈を配置する印刷方法である.発
表者の原稿として用いる.
2.1.5
画面
WYSIWYG 型は以下のように複数の表示画面を持っている.以下にそれぞれの画面の説明と,そ
の画面がこれまでに述べたどの項目に関連するかを示す.
編集画面 スライドを 1 枚ずつ表示し,ツールバーやツールボックスなどを用いてスライドを作成
する画面である.スライド作成時はこの画面を用いる.
アウトライン画面 スライドのテキストとテキストの構造のみを取り出し,デザインなどを排除し
た画面である.この画面ではスライド全体の構成を確認できるため,スライド校正の際にこ
の画面を用いる.
注釈画面 注釈を表示/編集する画面である.プレゼンテーションツールによっては編集画面と注
釈画面を一度に表示するものもある.
配布資料画面 観客に配布するための資料のレイアウトを編集する画面である.1 ページに何枚のス
ライドを配置するかなどを変更できる.この画面がなく,印刷プレビューがこの画面に相当
するプレゼンテーションツールもある.
スライド一覧画面 全てのスライドをサムネイル表示する画面である.スライド全体の校正を見直
すために使うことができる.また,プレゼンテーションが終了した後に表示し,観客からの
質問に迅速に対応するためにも用いることができる.
スライドショー スライドを 1 枚ずつフルスクリーンで表示し,プレゼンテーションを行うための
画面である.
第 2 章 既存のプレゼンテーションツール
6
2.2
テキスト型プレゼンテーションツール
Windows や Mac OS 環境などでは一般的ではないが,UNIX 環境では一般的なプレゼンテーショ
ンツールのタイプはテキスト型である.テキスト型はスライドの作成はサポートせず,スライドの
表示や印刷などスライドのレンダリング処理をサポートするプレゼンテーションツールである.
本章でも WYSIWYG 型と同じように以下の視点からテキスト型を考察する.
• スライドの作成方法
• スライドの校正方法
• プレゼンテーションの方法
• スライドの印刷
2.2.1
スライド作成
テキスト型ではプレゼンテーションツールを用いず,任意のテキストエディタでスライドを作成
する.
スライドのソースはツールごとに異なるマークアップを用いる.例えば,MagicPoint ではインデ
ント/行ベースの独自マークアップを用いており,Pyslide は XML ベースの独自マークアップを用
いている.また prosper は LaTeX のクラスファイルとして実装されており,LaTeX に独自のマー
クアップを追加したものを用いる.
プレゼンテーションツール側が特定のエディタ向けにソース作成支援ツールを提供していること
もある.
例えば,MagicPoint は MagicPoint を用いたスライドの作成を支援する Emacs のモードとして
mgp-mode を提供している.このモードではソースの色付けやコマンド挿入機能などのソース編集
機能以外に,MagicPoint の実行コマンドである mgp を起動するスライド作成支援機能も備えてい
る.このような支援ツールを用いることによりエディタとプレゼンテーションツールを連携させる
ことができ,テキスト型のプレゼンテーションツールを WYSIWYG 型のようにスライド作成機能
からスライド表示機能までを備えているプレゼンテーションツールのように使うことができる.
Pyslide や prosper のように完全な独自マークアップではなく既存のマークアップ言語の上に DSL
(Domain Specific Language) としてマークアップ言語を定義した場合は既存のマークアップ言語用
の支援ツールを流用できる.
例えば,Pyslide の場合は Emacs や Vim 用の XML 編集支援ツールがあるためそれらを利用する
ことができる.また prosper の場合も同様に,各エディタの LaTeX 編集支援ツールを利用できる.
LaTeX のようにもともとコンパイルして使用することを目的としたマークアップ言語の DSL と
してマークアップ言語を定義した場合は,mgp-mode のようなスライド作成支援機能を独自に実装
しなくても,既存の編集支援ツールにコンパイルコマンドやプレビューコマンドを起動する機能が
2.2. テキスト型プレゼンテーションツール
7
備わっている場合が多いため,既存のツールを利用するだけでエディタとプレゼンテーションツー
ルを連携させることができる.
しかし,XML のようにコンパイルして使用することを目的としないマークアップ言語の場合,
既存の編集支援ツールには編集のための機能しかない場合が多い.このため,エディタとプレゼン
テーションツールを連携させるためには独自のツールを開発しなければいけない.ただし,編集機
能は既存のツールを利用できるため,エディタとプレゼンテーションツールを連携させる部分だけ
を開発すればよい.
2.2.2
スライド校正
スライド校正にはエディタの強力な編集機能がそのまま使える.
編集支援ツールがスライド単位での編集をサポートする場合がある.例えば,スライド単位での
移動,コピー,削除や,タイトルのみ抽出してアウトラインを表示する機能がある.
WYSIWYG 型とインターフェイスは大きく異なるが,提供するスライド校正機能はほとんど同
じである.編集支援ツールのできやエディタ自体が高機能な場合はむしろ WYSIWYG 型よりも強
力なスライド校正機能を提供する.例えば,Emacs には正規表現を用いた置換機能があるため,ス
ライド全体の語句を置換するために正規表現を使うことができる.
スライド校正時は実際にどのようにスライドに表示されるかを確認しながら行う.このとき,以
下の作業を繰り返すことになる.
• テキストを編集
• 表示を確認
表示を確認するときにプレゼンテーションツールを再起動しなければいけないとすると作業効率
が低下する.そのため,プレゼンテーションツールはソースの自動再読み込み機能を備えている場
合が多い.あるいは,起動時間がストレスにならないくらい速い場合もある.
2.2.3
プレゼンテーション
プレゼンテーション時に提供する機能は以下の基本機能しかない場合が多い.
• スライド移動
• プレゼンテーション終了
これは,MagicPoint や Pyslide のように独自にプレゼンテーション表示機能を提供しているツー
ルが少ないからである.
prosper を用いた場合は既存の PDF ビューアに,less プレゼンを用いた場合は less に表示機能
を任せている.一般に,これらの表示アプリケーションはプレゼンテーション用に最適化されてい
ないためプレゼンテーションに便利な機能を提供していない場合が多い.
第 2 章 既存のプレゼンテーションツール
8
一方,独自にプレゼンテーション機能を提供している MagicPoint は以下の機能もサポートして
いる.
• スライド書き込み
• 強制再描画
• ソース再読み込み
prosper や less プレゼンなど,既存のアプリケーションに表示を任せている場合は,キーボード
からスライド移動やプレゼンテーション終了など基本機能を実行するインターフェイスしかない場
合が多い.
MagicPoint や Pyslide など独自に表示機能を提供している場合は,キーボードから基本機能を実
行するインターフェイスに加え,マウスによるインターフェイスがサポートされている.ただ,マ
ウスによるインターフェイスはスライド移動,スライド書き込みだけのサポートなど,WYSIWYG
型よりも貧弱である.例えば,WYSIWYG 型にみられるポップアップなどメニューからのコマン
ド実行がサポートされていない.
2.2.4
印刷
PostScript または PDF を出力できる機能を備えていることが多い.
例えば,prosper は DVI ファイルを PDF に変換して使用するため,発表用ファイル自体が印刷
用ファイルとなる.MagicPoint は独自に PostScript 出力をサポートしている.less プレゼンの場
合は a2ps などを使用して印刷用 PostScript ファイルを作成できる.
印刷時のページレイアウトは,1 ページにスライド 1 枚を配置する配布用レイアウトと 1 ページ
にスライドを複数枚配置する資料用レイアウトが使える.
WYSIWYG 型にある 1 ページにスライドのサムネイルとスライドの注釈を配置する発表者用レ
イアウトはサポートされていない.これは,通常,スライドの注釈はソースファイル中にコメント
として埋め込まれているため,プレゼンテーションツールが注釈を無視するからである.
2.3
その他のプレゼンテーションツール
本節では WYSIWYG 型にもテキスト型にも分類することが難しいプレゼンテーションツールに
ついて考察する.
2.3.1
Goby
Goby[39] は Emacs 上に実装されたプレゼンテーションツールであり,WYSIWYG 型でありな
がらテキスト型に似た特徴を備えている.
2.3. その他のプレゼンテーションツール
9
ソースはテキスト型のようにマークアップされたテキストである.Goby は Emacs の機能を用い,
テキストが入力されたら即座にマークアップを解釈し表示する.このように,ソースはテキストで
あり,キーボードで編集するというインターフェイスであるが,WYSIWYG 型のようにスライド
表示を確認しながらスライドを作成できる.
スライド作成 テキスト型と同じくエディタを用いて行う.テキスト型と違う点は使用できるエディ
タが Emacs のみであるという点と,マークアップを覚えなくてもよいという点である.
マークアップを覚えなくてもよいというのは,Goby では各種マークアップを適用するための
キーバインドを提供しており,通常,ユーザはそのインターフェイスを通してスライドを作
成するからである.もちろん,ソース自体は単なるテキストなので,Goby を用いずにソース
を編集すればテキスト型とまったく同じようにスライドを作成できる.
スライド校正 テキスト型と同じで,エディタの編集機能や各種テキスト処理ツールを用いて行う.
ただ,テキスト型と違って,編集,表示の確認という作業を繰り返さなくてもよい.
プレゼンテーション テキスト型とだいたい同じで,キーボードからはスライド移動やプレゼンテー
ション終了など基本的機能が使える程度である.キーバインドは多くない.特徴的なのは,
Emacs の機能を利用したマウスクリックによりブラウザで URL を表示する機能と,単語検
索機能である.
印刷 テキスト型と同じで,PostScript 出力機能と,画像と画像を配置する HTML 出力機能がある.
2.3.2
less プレゼン
本稿ではテキスト型に分類した less プレゼンであるが,ソースをそのまま整形せずに表示する
less プレゼンは WYSIWYG 型であるとも言える.ただ,その特徴はテキスト型 と同じであるため,
ここで再び less プレゼンについて考察しない.
11
第3章
採用するべき機能
これまで,既存のプレゼンテーションツールを WYSIWYG 型とテキスト型に分け,それぞれの
特徴を考察した.本章ではそれぞれのタイプから Rabbit が採用するべき機能について考察する.
3.1
スライド作成
本節では,スライド作成時に使うための機能を考察する.プログラマは,日常の作業において,
作業ごとに異なるテキスト作成ツールを使用することを好まない.むしろ,既存のツール群を応用
し,それぞれのテキスト作成を快適に行える環境を構築することを好む.なぜなら,既存のツール
群を使い回した方が覚えることが少なくてすみ,さらに新しいツールに慣れるための時間も節約す
ることができるからである.
例えば,異なるプログラミング言語を用いてプログラムを開発する場合を考える.プログラマは
言語ごとに異なる IDE を切替えて使う開発スタイルよりも,Emacs や Vim などで編集モードを対
象となるプログラミング言語用のものに切替え,対象となるプログラミング言語用の編集環境を構
築し,エディタの編集機能に加え,grep や CVS,Subversion[23] などの既存の開発用ユーティリ
ティを用いた開発スタイルを好む.
この場合は,Emacs や Vim の検索,置換などの基本的な編集機能はどのプログラミング言語で
も同じインターフェイスで使うことができ,結果としてプログラマの開発コストを下げている.
以上のことから Rabbit ではテキスト型をベースとしたスライド作成方法を採用する.以降の項
では,Rabbit が採用するべき機能を挙げていく.
3.1.1
人が可読なマークアップ言語の採用
テキスト型では,ソースにマークアップを行って,スライドの区切りや箇条書きなどを表現する.
マークアップ言語の設計はプレゼンテーションツールによって大きく異なる.
ソースの見た目からスライド表示が容易に想像できるマークアップ言語を採用した場合は以下の
ような利点がある.
• 実際にスライド表示をプレビューしなくてもスライド作成および校正が行える.
• ソースの編集が容易になる.
第 3 章 採用するべき機能
12
一方,以下のような欠点がある.
• ソースに詳細な指示を記述することが難しい.
これは,ソースに詳細な指示を記述すると,その分,ソースにスライド表示には直接現れない要
素が出てくるためである.これは見た目からスライド表示を想像しづらくする.
MagicPoint や less プレゼンではソースの見た目がスライド表示での見た目と類似している.例
えば,MagicPoint は箇条書きをタブインデントで表現している.
このタイプのマークアップ言語はソースの見た目からスライド表示が容易に想像できるという点
で人が可読なマークアップ言語ということとする.
一方,Pyslide の XML ベースのマークアップや prosper の LaTeX ベースのマークアップは,そ
のソースの見た目からスライド表示が容易に想像できない.これは,以下が原因である.
• ソースの構造がインデントとは独立している.
• ソース全体を見たとき,テキストとマークアップの比率でマークアップの割合が多い.
例えば,Pyslide が採用している XML ベースのマークアップ言語では,スライドタイトルと箇
条書きが同じレベルの要素として現れることがある.これでは,ソースを読み,タグの意味を解釈
してからでないとスライド表示を想像することは困難である.
また,prosper が採用している LaTeX ベースのマークアップ言語では,スライド定義の開始と
終了,箇条書きの開始と終了,箇条書きの各要素など,人が可読なマークアップ言語よりもマーク
アップ量が多い.図??は箇条書きを入れ子にした例である.
¶
³
\begin{itemize}
\item トップレベル 1
\begin{itemize}
\item サブアイテム 1
\end{itemize}
\item トップレベル 2
\begin{itemize}
\item サブアイテム 1
\item サブアイテム 2
\end{itemize}
\item トップレベル 3
\begin{itemize}
\item サブアイテム 1
\end{itemize}
\end{itemize}
µ
´
3.1. スライド作成
13
これが,図??のようなスライド表示になることを容易に想像することは困難である.これは,各
箇条書きの間に,マークアップ行が含まれていて,テキストの構造を判断しづらくさせているから
である.
¶
³
• トップレベル 1
– サブアイテム 1
• トップレベル 2
– サブアイテム 1
– サブアイテム 2
• トップレベル 3
– サブアイテム 1
µ
´
Rabbit では,インデントと簡単な記号でマークアップをする RD[18](Ruby Document) をベース
とし,人が可読なマークアップ言語を設計する.
このように完全な独自マークアップ言語を採用せずに,RD のようなの既存のマークアップ言語を
ベースとすることは,開発者にもユーザにも利点がある.
まず,ユーザの利点について述べる.既存のマークアップ言語を知っているユーザは学習コスト
が小さくなる.もし,既存の マークアップ言語を知らない場合でも,学習のために既存のマーク
アップ言語のためのドキュメントが利用することができ,学習が容易になる.
開発者側の利点は既存のマークアップ言語の資産を利用できるということである.マークアップに
関するドキュメントを作成する際,既存のマークアップ言語のためのドキュメントを参考にしたり,
参照するようにしながらドキュメントを作成できるため開発コストを小さくすることができる.ま
た,マークアップ言語を一から設計しなくても良いというのも開発コストが小さくなる.もし,既
存のマークアップ言語用のパーザがある場合は,さらに開発コストを小さくすることができる.
既存のマークアップ言語をベースとした場合の欠点は,既存のマークアップ言語の制限を継承し
てしまうことである.また,既存のマークアップ言語がスライド作成用に設計されていることは少
ないため,スライド作成用にパーザや文法に独自拡張を入れなければいけない.既存の マークアッ
プ言語のパーザ や文法が拡張に向いていない場合は,開発コストが高くなってしまうことも考えら
れる.
Rabbit では,RD の文法を拡張せずに,マークアップの中にサブマークアップを挿入する,ある
いは既存のマークアップにスライド作成用の意味を持たせることにより RD を拡張している.これ
により,既存の RD パーザを流用できるため開発コストが小さくなっている.また,文法は RD そ
のものであるため,ユーザの学習コストも小さい.
Rabbit が採用した RD ベースのマークアップ言語がどのようになっているかを述べる.RD で
第 3 章 採用するべき機能
14
は,見出しを図??のようなマークアップで表現する.
¶
³
= 見出し(レベル 1)
== 見出し(レベル 2)
=== 見出し(レベル 3)
==== 見出し(レベル 4)
+ 見出し(レベル 5)
++ 見出し(レベル 6)
µ
=がもっとも大きい見出しレベルで,++がもっともい小さい見出しレベルである.
´
Rabbit では,=レベルの見出しをスライドタイトルとして扱い,=レベルの見出しから次の=レベ
ルの見出しまでを 1 枚のスライドとする.図??は 2 枚のスライドを記述した例である.
¶
³
= スライド 1
1 枚目のスライドの内容
= スライド 2
2 枚目のスライドの内容
µ
´
=レベルの見出しがスライドタイトルとして扱われる一方,=レベルより小さい見出しは全て無視
され,Rabbit では意味を持たない.このように,既存の RD とは少し違うスライド作成に特化し
た意味を持たせることにより RD を拡張している.
スライドの内容には RD の文法をそのまま使用する.例えば,1 枚目のスライドに箇条書きを入
れたい場合は図??のようになる.
¶
³
= スライド 1
* トップレベル 1
* サブアイテム 1
* トップレベル 2
* サブアイテム 1
* サブアイテム 2
= スライド 2
2 枚目のスライドの内容
µ
´
3.1. スライド作成
15
このように,Rabbit では既存の RD の文法を維持しながら,RD をスライド作成用の人が可読な
マークアップ言語と拡張している.
3.1.2
編集モードの提供
テキスト型では,ユーザは好みのエディタを用いてスライドを作成する.プログラマが好んで使
用する Emacs や Vim のような高度にカスタマイズ可能なエディタではモードと呼ばれるそれぞれ
のファイル形式に特化した編集モードを提供する.ソースの編集効率は編集モードの有無に大きく
影響する.テキスト型 のプレゼンテーションツールはツールが採用しているソース形式に特化した
編集モードを提供するべきである.
編集モードを提供するためには以下の 2 つの方法がある.
• 独自に編集モードを作成する.
• 既存のマークアップ言語をベースとしたマークアッ プ言語を採用し,既存のマークアップ言
語用編集モードを利用する.
独自に作成する場合は,作成するためのコストがかかるが,そのプレゼンテーションツールに固
有の機能などを組み込むことができるため,モードのできによっては既存のモードを利用した場合
よりも便利になる.
一方,既存のモードを利用する場合は,開発コストがかからない.しかしながら,そのプレゼン
テーションツールに固有の機能などがないため,モードに不満が残ることがある.ただ,独自にモー
ドを作成する場合に,既存のモードを基にモードを作成することができるため,開発コストが小さ
くなる.
Rabbit では,既存のマークアップ言語である RD をベースとしたため,Emacs,Vim 用に用意
されている既存の RD 用編集モードを利用できる.また,xyzzy[15] エディタのために独自に作成
された編集モードも提供する.
3.1.3
多言語サポート
既存のプレゼンテーションツールでは多言語をサポートしているものがいくつかある.例えば,
MagicPoint は m17nlibrary[22] を用いて多言語を実現してる.
多言語1 をサポートしているとは同時に複数の言語を扱うことができるということである.プレ
ゼンテーションツールが多言語をサポートして場合は,同じスライド中に複数の言語を表示させる
ことができる.例えば,図??のようなスライドがあったとする.
1 英語では multilingualization のことである.multilingualization は長いので,2 文字目から 18 文字目までの 17 文
字を略して m17n と呼ばれることが多い.
第 3 章 採用するべき機能
16
¶
³
= Hello World
* Hello
* こんにちは
* (アラビア語でこんにちは)
µ
´
日本語に対応している普通のプレゼンテーションツールでも「Hello」と「こんにちは」は正常に
表示することができるだろう.しかし,
「(アラビア語でこんにちは)2 」の部分は「右から左へ」表
示されないだろう.多言語をサポートしている場合はアラビア語のように「右から左へ」書く言語
では,
「右から左へ」表示し,日本語や英語のように「左から右へ」書く言語では,
「左から右へ」表
示しなければいけない.
Rabbit ではテキストレンダリングエンジンである Pango[34] を用いて多言語をサポートする.
Pango は,Rabbit が採用している GUI ツールキットである GTK+[19] やデスクトップ環境 GNOME
の印刷エンジンである libgnomeprint でも採用されているテキストレンダリングエンジンである.
また,Rabbit がサポートしているグラフィックレンダリングエンジンのひとつである cairo[38] も
Pango をサポートしている.
3.1.4
インターフェイスの国際化
既存のプレゼンテーションツールではメッセージやメニューなどインターフェイスが国際化され
ているものがいくつかある.OpenOffice.org の Impress もそのひとつである.
国際化3 とは,アプリケーションが複数の言語や地域4 をサポートしているということである.ただ
し,アプリケーションを改変したり構築しなおしたりせずに,言語や地域を変更できる必要がある.
例えば,言語が日本語で地域が日本という環境でアプリケーションを実行したら,メニューが
「ファイル」などというように日本語で表示され,日付が「2006 年 2 月 9 日.
.
.
」というように表示
されるが,言語が英語で地域がアメリカという環境でアプリケーションを実行したら,メニューが
「File」などというように英語で表示され,日付が「Thu Feb 9 ...」などというように表示される.
つまり,アプリケーションと言語資源5 や地域情報が分離されていて,アプリケーション実行時
に動的にアプリケーションをその言語および地域用に設定することを国際化をサポートしていると
いう.
Rabbit では Ruby[17] 版の gettext[8] である Ruby-GetText-Package[21] を用いてインターフェイ
スの国際化をサポートする.gettext は GTK+や GNOME など,多くのオープンソースソフトウェ
アで利用されており実績がある.
2 本当はアラビア語で「こんにちは」と書けば良いのであるが,著者はもちろん,読者もわからないと思ったためこう表
記してある.
3 英語では internationalization のことである.internationalization は長いので,2 文字目から 19 文字目までの 18 文
字を略して i18n と呼ばれることが多い.
4 日付表記などが地域ごとに異なる.
5 例えば,元が英語のテキスト(例えば「File」
)なら,日本語に翻訳されたテキスト「ファイル」のこと.
3.1. スライド作成
17
Ruby-GetText-Package は PO6 と,PO をコンパイルした MO7 という,gettext と互換性のある
フォーマットを採用している.このため,gettext が提供する Emacs 用の PO 編集モードである
po-mode や PO を更新する msgmerge などが利用でき,効率良くテキスト翻訳を行うことができる.
3.1.5
多くの画像フォーマットのサポート
観客にわかってもらえる「良い」プレゼンテーションを行うために画像を使うことは効果的であ
る.プレゼンテーションツールが挿入したい画像フォーマットをサポートしていれば,画像フォー
マットを変換せずにスライドに挿入することができる.これにより,作業効率を下げずにスライド
作成ができる.既存のプレゼンテーションツールの多くは,複数の画像フォーマットをサポートし
ている.
画像フォーマットのサポート状況はプレゼンテーションツールによって様々である.プレゼンテー
ションツールによっては JPEG などのラスタ画像フォーマットしかサポートしていないこともある.
プレゼンテーションツールは画像の拡大縮小をサポートしていることが多く,画像の拡大を行う
場合はラスタ画像フォーマットよりも EPS などのベクタ画像フォーマットの方が向いている.こ
れは以下のためである.
ラスタ画像フォーマットはどの画素にどの色を置くかという情報で画像を表現しているため,拡
大した場合は元の画像情報にはない画素の情報を周囲の画素などから推測しなければいけない.こ
のため,ラスタ画像フォーマットを拡大すると,画像が荒くなったりぼやけたりする.一方,ベク
タ画像フォーマットは描画操作の集まりで画像を表現しているため,描画方法のパラメータを調節
することにより拡大縮小を行える.このため,ベクタ画像フォーマットを拡大しても,画像が荒く
なったりぼやけたりせずに,元の画像と同じ画質を保つことができる.
Rabbit では PNG や JPEG,PNM,BMP などのラスタ画像フォーマットだけではなく,LaTeX
で一般的に用いられている EPS や XML ベースの SVG などのベクタ画像フォーマットもサポート
する.
拡大縮小に強いベクタ画像フォーマットだけではなく,多くのラスタ画像フォーマットをサポー
トするのはスライド作成効率を下げないためである.もし,慣れ親しんだ画像処理ツールがラスタ
画像フォーマットを扱うためのペイント系の画像処理ツールだった場合でも,そのツールを使って
スライド用の画像を作成し,画像フォーマットを変換せずにそのまま使用できる.
Rabbit は PNG や EPS などの標準的な画像フォーマットだけではなく,UNIX 環境で広く使わ
れている Tgif[5] など,特定の画像処理アプリケーション用の画像フォーマットもサポートする.こ
れにより,元の画像を変更したのに EPS などの画像フォーマットに変換し直すのを忘れて,スライ
ドに反映されないといった事態が起こらなくなる.
6 Portable Object の略で,人が読み書きするためのフォーマットである.翻訳する対象となるテキストがどこに書かれ
ていたか,未翻訳のテキストであるなどといった情報も含まれている.テキストを翻訳するときは PO ファイルを編集する.
7 Machine Object の略で,プログラムが読み込むフォーマットである.バイナリファイルなので人が読み書きすること
には向かない.
第 3 章 採用するべき機能
18
3.1.6
数式のサポート
WYSIWYG 型では数式エディタなど専用編集ツールを用いてスライド中に数式を入力すること
ができる.テキスト型 では LaTeX など外部コマンドと連携して数式をサポートすることができる.
テキスト型でも prosper は特別である.prosper は LaTeX ベースのプレゼンテーションツールなの
でネイティブに数式に対応している.
プログラマがスライド中に数式を用いることは少ない.そこで,Rabbit は簡単な数式であれば
Rabbit 自身で処理する.LaTeX など数式処理が得意なツールに比べれば見栄えは悪いが,Rabbit
内部で表示などを細かく制御ができるという利点がある.
しかし,複雑なものは mimeTeX[14] や Tgif,LaTeX を用いて数式を整形し,整形された数式を
画像としてスライド中に挿入する.見栄えは Rabbit 独自処理の数式より綺麗であるが,Rabbit か
らは数式を画像として扱うので,整形済みの数式を微調整することはできず,拡大縮小するなど簡
単な操作しかできない.
Rabbit が独自の数式サポートをもっと強化するということも考えられる.しかしながら,プログ
ラマはスライド中に数式を用いることが少ないということを考えると,簡単な数式は Rabbit 自身
で処理し,複雑なものは専用のツールと連携するというのは開発コストとニーズからみて,妥当な
トレードオフであるといえる.
また,数式サポートを強化するためには文法の拡張を考えなければいけない.文法を拡張するこ
とは開発コストが上げるだけではなく,ユーザの学習コストも上げてしまう.文法を拡張せずに,
既存の数式記述文法をサポートすると,既存の数式記述文法用のサポートツールを利用することが
できる.また,もし,ユーザが既存の数式記述文法を知っていれば学習コストを小さくすることが
できる.もし知らなくても,普及している数式記述文法をサポートするならば,学習するためのド
キュメントが揃っているために,独自に文法を拡張した場合よりも用意に学習できる.このことか
ら RD の文法を拡張して数式サポートを強化するよりも,LaTeX や MathML[10] などの既存の数
式記述文法をサポートした方が開発コストもユーザの学習コストも下げることができるといえる.
このため,Rabbit は簡単な数式のみ Rabbit 自身でサポートし,複雑な数式は他のツールと連携
するという方法をとっている.
3.1.7
表のサポート
WYSIWYG 型では表がサポートされていることが多い.一方,テキスト型ではツール自身が表
をサポートしていることは少ない.prosper は LaTeX ベースのプレゼンテーションツールなのでネ
イティブに表をサポートしているが,MagicPoint は数式サポートと同じように LaTeX など外部コ
マンドを用いてサポートしている.
数式ほどではないが,プログラマはスライド中で表を利用しない.しかし,Rabbit ではネイティ
ブに表をサポートする.これは以下のような理由からである.
• RD に表の書式を導入する RTtool[26] という RD の拡張がすでに存在するため,開発コスト,
学習コストともに小さくすることができる
3.2. スライド校正
19
• 見栄えを細かく制御できる
• 表には数式ほど多くのことが要求されないため,小さい開発コストでユーザの要求を満足さ
せることができる
数式サポートでは,開発コストとユーザの要求,および,文法拡張とユーザの学習コストを考慮
した結果,ネイティブサポートを見送った.しかしながら,表では上記の理由からネイティブサポー
トする.
これは,表をネイティブサポートしても開発コスト,学習コストともに低いからである.開発コ
ストは既存の RDtool のパーザを使うことによって低くなる.表のレンダリングは第 6 章で述べる
テーマを用いて解決できる.このように,既存の拡張機能を用いることができるため開発コストが
低い.文法拡張に対するユーザの学習コストも低い.これは,RTtool の文法がよく知られている
ということと,RTtool の文法を解説した文書が存在するためである.
3.1.8
マルチプラットフォームサポート
既存のプレゼンテーションツールの中には OpenOffice.org の Impress や prosper,less プレゼンな
どいくつかマルチプラットフォームで動作するツールがある.
本稿で想定しているプログラマは主に UNIX 上で作業しているということを想定している.しか
しながら,プロジェクタを使用するために UNIX 以外の Mac OS X や Windows といったプラット
フォームを使用しなければいけない,あるいはプログラマの環境が UNIX 以外のプラットフォーム
という場合がある.
現在,Emacs や diff などの GNU[31] プロジェクトのツールや,Subversion などの多くのソフ
トウェアが UNIX 上だけではなくマルチプラットフォームで動作する.このため,UNIX 上で作業
できないプログラマも UNIX 上と同じツールを使い,UNIX 上と同じような使い心地で作業ができ
るようになってきている.
UNIX 以外のプラットフォームで作業しているプログラマが,UNIX 上で作業しているようにプ
レゼンテーションを作成できるように Rabbit もマルチプラットフォームをサポートする.このた
め,マルチプラットフォームで動作する Ruby と GTK+[19] を用いる.これにより,UNIX,Mac
OS X,Windows と複数のプラットフォームをサポートできる.
3.2
スライド校正
本節ではスライド校正時に使うための機能を考察する.Rabbit では,テキスト型と同じプログラ
マ好みのエディタを用いたスライド作成方法を採用したため,スライド校正方法もテキスト型ベー
スの方法を採用する.
スライド校正はスライド表示を確認しながら行う.テキスト型では,ソースとスライド表示が異
なるため,どれだけスムーズにソースの変更をスライド表示に反映させるかが問題となる.
第 3 章 採用するべき機能
20
3.2.1
自動再読み込み機能
WYSIWYG 型では,ソースにテキストや図などのスライド中の各要素がどの位置に配置される
かが記述されている.一方,テキスト型ではそのような指定はせずにツールがソースを読み込んで
自動的に計算し,配置する.このため,WYSIWYG 型よりもテキスト型の方がスライドのレンダ
リング速度が遅くなる8 .
スライド表示に時間がかかると,ソースの変更をスライド表示に反映するまでの時間が長くなり,
スライド校正の効率を落とす.
そこで,MagicPoint では再起動せずにソースを読み直すソース再読み込み機能を提供している.
これにより,プレゼンテーションツールの起動および終了の時間を排除し,スライド表示に反映す
るまでの時間を短縮している.また,MagicPoint には,ソースを再読み込みすることを指示しな
くても自動的にソースが変更されたかどうかを判断し再読み込みをするソース自動再読み込み機能
もある.これも,ソースの変更をスライド表示に反映するまでの時間を短縮することに役立つ.
Rabbit でも,スライド校正効率をあげるために,このソース自動再読み込み機能を提供する.
3.2.2
校正支援モードの提供
テキスト型では,エディタの編集モードによって,編集支援機能だけではなく,校正支援機能も
提供する.校正支援機能としては以下のようなものがある.
非表示機能 指定したレベル以下の構造を非表示にする機能である.エディタに備わっている機能
をモード用にカスタマイズして実現する場合が多い.
この機能を利用することにより WYSIWYG 型のアウトライン画面と同じ使いかたができる.
構造単位での編集機能 ページ単位や箇条書き単位などで削除やコピーなどをする機能である.指
定した範囲の箇条書きのレベルを上げたり下げたりする機能もこの機能である.この機能も
エディタに備わっている機能を利用して実現する場合が多い.
この機能はスライドの順序を変更したり,アウトラインを変更したりするために利用できる.
外部コマンド起動機能 テキスト型ではスライド編集環境であるエディタとは別にスライド表示用
のコマンドがある.エディタから外部コマンドを起動する機能があると,ターミナルから外
部コマンドを呼び出さなくてもよくなるため,スライド校正効率を上げることができる.
この機能もエディタの機能を利用して実現されることが多い.
Rabbit でも,以上の機能を提供する.ただし,エディタごとにモードが存在するため,提供する
機能はさまざまである.現在,xyzzy には Rabbit 用の編集モードが存在する.このモードでは上
8 WYSIWYG 型がテキスト型よりも起動が遅いことが多いのはスライドのレンダリング以外にユーザインターフェイス
の初期化などを行う必要があるためである.
3.3. プレゼンテーション
21
述の全ての機能を提供している.しかしながら,Emacs や Vim で用いる既存の RD 用編集モード
では外部コマンド起動機能が提供されていないため,この機能は提供していない9 .
スライド一覧
3.2.3
テキスト型では提供されることが少ないスライド一覧画面であるが,WYSIWYG 型では提供さ
れていることが多い.
この機能は,発表後に表示して,観客からの質問時などに観客とのコミュニケーションを円滑に
進めるためにも使用できる.このため,Rabbit はテキスト型であるがスライド一覧機能を提供する.
ただし,スライド一覧機能からスライドの順序を入れ替える機能は提供しない.これは,スライ
ド一覧でプレゼンテーションの流れを確認することが有益ではないからである.スライド一覧でプ
レゼンテーションの流れを確認するよりも,スライドを一枚ずつ表示して確認した方が,実際のプ
レゼンテーションの流れをシミュレートできるため,より高いフィードバックが得られるからであ
る.スライド一覧でスライド順序を変更する場合は,スライドを一枚ずつ表示したときのプレゼン
テーションの流れを壊してしまうことがある.
Rabbit では,良いプレゼンテーションを行うためのスライド作成を邪魔する機能は導入しない.
よって,スライド一覧機能からスライドの順序を入れ替える機能は提供しない.
3.3
プレゼンテーション
既存のプレゼンテーションツールはプレゼンテーション時の機能および機能を呼び出すインター
フェイスが貧弱である.Rabbit では以下の既存のプレゼンテーションツールにある機能はすべて提
供する.
• スライド移動
• プレゼンテーション終了
• スライド書き込み
• ホワイトアウト
• ブラックアウト
• 強制再描画
• ソース再読み込み
• スライド検索
9 エディタが提供する外部コマンド起動機能を直接使えばエディタからプレゼンテーションツールを起動することはでき
る.しかしながら,それは使いやすいものではない.
第 3 章 採用するべき機能
22
また,キーボードによるインターフェイスだけではなく,マウスによるインターフェイスも提供
する.つまり,マウスクリックによるインターフェイスだけではなく,ポップアップメニューによ
る機能起動のインターフェイスも提供する.
スライド検索では,単なる文字列検索ではなく,より強力な正規表現によるインクリメンタル検
索を行う.また,Migemo[40] をサポートしているため,ローマ字による日本語の検索も行うこと
ができる.
Rabbit では,これらの既存のプレゼンテーションツールにある機能に加えて新たに独自の機能を
追加する.さらに,機能を起動するためのインターフェイスも充実させる.これについては第 4.3
節で詳しく述べる.
3.4
印刷
Rabbit では,以下に挙げる既存の印刷方法をすべて提供する.ただし,WYSIWYG 型にある 1
ページにスライドのサムネイルとそのスライドへの注釈を配置する発表者用印刷は提供しない.
• 1 ページに 1 枚のスライドを配置する配布用印刷方法
• 1 ページに複数枚のスライドを配置する資料印刷方法
• スライド画像とその画像を表示する HTML を生成する方法
Rabbit では PostScript および PDF のどちらの形式での印刷もサポートする.また,PNG や
JPEG だけではなく,GIF や BMP での出力もサポートする.
3.4.1
コメント印刷
第 3.1.1 項で述べた通り,Rabbit はもっとも大きいレベルの見出しのみを使用し,それより小さ
いレベルの見出しを全て無視する.
これを利用して,ソース中の 2 レベル以下の見出しの下に,スライドには載せない詳細な記述を
書いておくことができる.この記述を RD 変換プログラムを用いて抽出し,他の書式に変換するこ
とができる.例えば,RD2TeX[32] を用いてこの記述を LaTeX に変換し,PostScript ファイルなど
を作成することができる.このように WYSIWYG 型にみられ,テキスト型に見られないコメント
印刷機能を実現できる.ただし,WYSIWYG 型のようにスライドのサムネイルとコメント記述を
関連付けた印刷ではない.
23
第4章
新しく開発する機能
本章では既存のプレゼンテーションツールにはない,プログラマ向けプレゼンテーションツール
に必要な機能を述べる.つまり,この章で述べる機能が Rabbit の特長となる機能である.
4.1
スライド作成
スライド作成時における Rabbit の特長となる機能を挙げる.
4.1.1
ソース入力インターフェイスの抽象化
プログラマはさまざまなレイヤを抽象化することを好む.Rabbit は入力ソースを抽象化し,以
下のような入力ソースをサポートする.
• 標準入力
• ファイル
• URI
• メモリ
• RWiki[28] のページ
URI,メモリ,RWiki 上のソースを入力をサポートすることにより,以下のような Rabbit の利
用が可能になる.
ソースが URI の場合,HTTP/FTP 経由で Web 上のリソースを取得し,入力ソースとして扱う
ことができる.これにより,スライドを公開する側は,ソースファイルをそのまま Web で公開する
ことができる.公開されているスライドを閲覧する側はスライドのソースをローカルディスクにダ
ウンロードせずに手元で動かしてみることができる.ただし,このような使い方の場合,スライド
を閲覧する側が Rabbit をインストールしている必要がある.
ソースがメモリ上にある場合,Rabbit は外部プロセスがメモリ上のソースを変更することを許可
する.これにより,外部プロセスからスライドの内容を変更することができるようになる.これを
用いることにより,レンダリングエンジンとして Rabbit を利用できる.これはシステムに Rabbit
を組み込むことを可能にする.詳細は第 5.5.2 項で述べる.
第4章
24
新しく開発する機能
ソースが RWiki のページの場合,Rabbit は SOAP[11] 経由で RWiki のページを取得し,その
ページの内容を入力ソースとして扱う.RWiki は Subversion または CVS を用いてページの内容を
バージョン管理することができる.このため,ソースを RWiki のページとして管理すれば,どこか
らでも編集でき,しかも特別な操作なしにバージョン管理をすることができるようになる.
特に,Wiki とプレゼンテーションツールの連携は Rabbit が初めての実例である.SOAP ではな
く Wiki RPC [1] を用いて,RWiki だけではなく任意の Wiki に接続するようにすることもできる.
しかしながら,以下の理由からこれは現実的ではない.
• Wiki 毎に文法が異なっていることに加え,RD をサポートしている Wiki がほとんどないた
め,Wiki のソースを入力ソースとして使えない.
• Wiki RPC には文法を取得する API が用意されていないため,たとえ Rabbit が複数の文法
をサポートしたとしても入力ソースのパーズ方法を切替えることができない.
つまり,たとえ Wiki とのインターフェイスを一本化したとしても,入力ソースの文法がばらば
らであるため対応できない.
4.1.2
ソースエンコーディングの自動変換機能
既存のプレゼンテーションツールでは,入力ソースは ISO-2022-JP にすること,あるいは EUC-JP
にすることなど入力ソースのエンコーディングが限定されているものが多い.特定のプラットフォー
ム上でのみ動作するアプリケーションであればこれは問題にならない.なぜなら,入力ソースのエン
コーディングはそのプラットフォーム上でのデフォルトエンコーディングと仮定できるからである.
しかしながら,マルチプラットフォームで動作するアプリケーションで入力ソースのエンコーディ
ングが限定されていると非常に使いづらくなる.例えば,UNIX 上で EUC-JP で作成した入力ソー
スを Windows 上では Shift JIS に変換してからではないと使用できない.また,Rabbit のように
Web 上のリソースを入力ソースとして使える場合は,プレゼンテーションツールを実行しているプ
ラットフォームと入力ソースを作成したプラットフォームが異なるということが十分に有り得る.
ただ,異なるプラットフォームで入力ソースを共有するという場合が少ないこと,Rabbit のよう
に Web 上のリソースを入力ソースとして扱えるプレゼンテーションツールが存在しないことを考
えると,既存のプレゼンテーションツールが採用している以下のような解決法で十分なことが多い.
• prosper のように pTeX[3] でコンパイルする時にエンコーディングを指定できるようにして,
指定されない場合にはデフォルト値としてそのプラットフォームのデフォルトエンコーディ
ングを使用する.
• Impress のように入力ソースを UTF-8 に限定する.
しかしながら,Rabbit は Web 上のリソースを入力ソースとして扱うため,これでは不便である.
例えば,Web 上のリソースを入力ソースとして扱う場合,もし,リソースのエンコーディングが期
4.1. スライド作成
25
待するエンコーディングと異なっていた場合は,一度リソースをダウンロードしてエンコーディン
グを確認してプレゼンテーションツールに指定しなければいけない.これは非常に不便である.
また,プログラマはプログラムでできることは自分で行わずに,プログラムに行わせることを好
む.エンコーディングの自動検出もそのひとつである.
以上の理由より,Rabbit では入力ソースのエンコーディングを自動検出し,自動で内部エンコー
ディングに変換する機能を提供する.また,明示的に入力ソースのエンコーディングを指定する機
能も提供するため,エンコーディングの自動検出が失敗する場合でもエンコーディングを明示的に
指定することにより,入力ソースのエンコーディングを変更せずにプレゼンテーションを行うこと
ができる.
4.1.3
コードの自動色付け機能
ここでいうコードとは,プログラミング言語のソースコードのことである.プログラマはコード
をスライドに張り付ける機会が多い.
プログラミング言語には構文があり,その構文要素を強調表示することにより見やすくなる.
Rabbit は,Enscript[25] と連携してスライド中に張り付けたソースコードをパーズし,自動で色付
けをする機能を提供する.
Enscript は PostScript など画像ファイルとしてもパーズ結果を出力ができるため,MagicPoint
や prosper などでも色付けされたソースコードを使うことができる.しかしながら,それらのプレ
ゼンテーションツール内では画像として扱われるため,色づけされたソースコードを細かく制御す
ることができない.一方,Rabbit は Enscript がパーズして色付けしたソースコードを Rabbit 内
部のオブジェクトに変換するため,第 6 章で述べるテーマを用いて結果を細かく制御することがで
きる.
4.1.4
見栄えの分離
テキスト型のプレゼンテーションツールは,ソース中に見栄えを定義することも,ソースと見栄
えを別ファイルに分けることもできる.例えば,MagicPoint ではスライド区切りを表すために図
??のようなマークアップを行う.
¶
³
%page
1 ページ目の内容
...
%page
2 ページ目の内容
...
µ
´
第4章
26
新しく開発する機能
このようなスライドの構造を表現するマークアップ以外に,図??のようなスライドの見栄えを設
定するマークアップを行う.
¶
³
%size 7, fore "red"
サイズを大きくして文字を赤くする
µ
´
ソース中に見栄えを定義することにより,ソース単独のみで動作させることができる.しかしな
がら,見栄えを既にある他の見栄えに変更したいときは,既存の見栄え定義部分を他の見栄え定義
に置き換えるようにソースを変更しなければいけない.ソースの内容は変更していないのにソース
を変更すると,diff や Subversion などの既存の開発用ユーティリティ使用時にノイズ1 が混じって
しまう.
ソースと見栄え定義を分離すれば,ソースの変更履歴にノイズが混じることはない2 .また,見
栄え定義を再利用することもできる.
ソースと見栄え定義を分離した場合の欠点はポータビリティが下がることである.ソースを持ち
運ぶときに,プレゼンテーションツールが標準で提供していない見栄え定義を用いていると,ソー
ス以外に見栄え定義も一緒に持ち運ばなければいけない.ただし,このソース単独で持ち運びがで
きないという問題は,スライド中で画像を使用する場合も起こる.よりわかりやすく,観客に訴え
るスライドを作成するためには画像は必須である.つまり,ソースに見栄え定義を埋め込んだ場合
も,ソースと見栄え定義を分離した場合もポータビリティに関して同様の問題を抱えている.
このポータビリティが下がる問題は,最終スライドを配布する段階であれば PostScript や PDF
として画像を埋め込んで解決することができるが,編集中のスライドの場合はソースや画像ファイ
ルをまとめて持ち運ばなければいけないためポータビリティの問題が残る.つまり,ソースに見栄
え定義を埋め込んだ場合のポータビリティに関する長所は,ほとんどの場合当てはまらず,ソース
と見栄え定義を分離した方が長所が多い.
以上の議論と,プログラマがモジュール化を好むということにより,Rabbit ではソース中への見
栄え定義の埋め込みをサポートしない.見栄え定義はテーマとしてソースとは別に管理することに
する.テーマに関しては第 6 章で詳しく述べる.
このように,Rabbit では単に既存のプレゼンテーションツールの機能を継承するだけではなく,
よりプログラマらしいスライド開発や,よりよいプレゼンテーションを促進するように機能制限を
加えている.
4.2
スライド校正
プレゼンテーションの作業のうち,もっとも時間を費すのがスライド校正である.本節では,スラ
イド校正時にテキスト型が WYSIWYG 型より劣っている点,つまり,ソースの変更がスライドに
1 ソースの内容がどのように変更されてきたかを追いかけているときに,diff や svn log が見栄え定義の変更にも反応
してしまう.
2 ソースと見栄えを分離する場合は,ソースファイル中に使用する見栄え定義の情報をメタデータとして埋め込む.これ
がソースの変更履歴に混じってしまうが,この記述はせいぜい数行程度であり,ノイズになるほど大きなものではない.
4.2. スライド校正
27
どのように影響するのかを確認するフィードバックの早さを改善する方法を考察する.また,テキス
ト型が WYSIWYG 型より勝っている点,つまり,スライドの表示結果からソース変更へのフィー
ドバックの早さ,を犠牲にしないという点も考慮する.
4.2.1
自動再読み込み機能の強化
プレゼンテーションツールを再起動せずにソースを再読み込みすることによってソースの変更を
スライドに反映する時間を短縮することは,ソースの変更がどのようにスライドに影響するかを確
認する際のストレスを減らすために有効である.そして,テキスト型では MagicPoint がこの機能
を実現していることはすでに述べた.
MagicPoint では X Window System がウィンドウに再描画を要求するためのシグナルが来たタ
イミングでソースが変更されているかどうかを確認する.再描画を要求するシグナルは,ウィンド
ウにフォーカスが移った場合や,ウィンドウが前面に表示された場合に発行される.つまり,ソー
スの変更をスライドに反映させるためには,エディタから MagicPoint のウィンドウにフォーカス
を移したりしなければいけない.
これは,ソースの変更をスライド表示に反映させるためのアクションを必要とする点で校正効率
を落としてしまうが,長所もある.それは必要最小限しか再読み込みをしないということである.
ソースを変更しても即座に再読み込みしないため,スライド表示を要求しないときにスライド表示
を行い計算資源を利用することはない.また,一定間隔毎にソース変更を確認するわけでもないた
め,一定間隔で計算資源を消費するということもない.
ただ,現在の計算機環境は向上しており,多少の計算資源の利用は許される.Rabbit でも,Mag-
icPoint と同じように再描画シグナル時に自動再読み込み機能を実行するが,一定間隔毎に再描画シ
グナルを発行することも可能である3 .このため,プレゼンテーションツールのウィンドウにフォー
カスを移すなどというアクションなしでソースの変更をスライドへ反映させることができる.また,
スライドへの反映はバックグラウンドで行われるため,反映中も通常の編集作業は続けることがで
き,一定間隔毎にソース変更を反映することが編集効率を下げることはない.
このように,一定間隔毎にソース変更をスライドに反映させることによって,通常のソース編集
効率を落とすことなく,ソース変更がどのようにスライドに反映されるかを確認し,フィードバッ
クを受けることができるようになる.
4.2.2
段階的ソース読み込み
プレゼンテーションツールのような GUI アプリケーション4 では,イベント処理のループを行う.
各イベント処理の間は他のイベントは処理されないシングルスレッドでループが行われる.このた
3 この機能は
Rabbit のテーマを用いた独自機能として,第 6 章で詳しく取りあげる.
プレゼンなど一部 GUI アプリケーションではないものもあるが,多くのプレゼンテーションツールは GUI アプ
リケーションである.
4 less
第4章
28
新しく開発する機能
め,スライド描画処理に時間がかかると,キーイベントなどを受け付けない時間ができる.GUI ア
プリケーションでは,イベントを受け付けない時間はユーザに大きなストレスを与える.
既存のプレゼンテーションツールは,起動時やソース再読み込み時において,完全にツール側の
処理が完了するまでユーザからのイベントを処理しない.例えば,MagicPoint ではソースの再読
み込み時は再表示までの間にイベント処理が行われない時間が生じる.この時間のストレスを軽減
させるためには以下のような方法がある.
進行状況を見せる 処理が行われていることを示すプログレスバーやスプレッド画面などを表示す
る方法である.これにより,ユーザはあとどのくらいで処理が終了するのかを判断できるた
め,無反応状態からくるストレスを軽減させることができる.
この方法は,会話に例えて説明することができる.相手に質問をした場合を考える.相手は
質問にはすぐに答えられず考え込んでしまったとする.このとき,何も言わずに黙り込んで
考え込まれると,
「聞こえなかったのだろうか」,
「無視されたのだろうか」,
「いつまで待てば答
えが返ってくるのだろうか」,などと不安を感じる.一方,
「少し考えさせて」,
「えーっと」,
などと考えているということを伝えてもらえると,
「質問はきちんと伝わったんだな」,
「考え
中だからもう少し待ってみよう」などと安心することができる.
段階的に処理する 処理が行われている間でもユーザからのイベントを処理する方法である.ツー
ル側の処理が行われている間は,その時点で処理した分だけでイベントに対応する.例えば,
描画処理中にユーザからのスライド移動要求がきた場合は,描画処理が途中であっても,ス
ライドを移動し,処理途中のものを描画する.
処理途中のものでも表示するというこの方法でも,プログレスバーなどを用いて進行状況を
見せる場合と同じようにユーザに処理中であることを示すことができる.これにより,ユー
ザのストレスを軽減させることができる.また,この方法では進行状況を明示するだけでは
なく,ユーザからのイベントも処理するため,単に進行状況を見せる場合よりもユーザのス
トレスを減少させることができる.
既存のプレゼンテーションツールでは「進行状況を見せる」方法を用いているものがいくつかあ
るが,
「段階的に処理する」方法を用いているものはない.これは,処理途中に割込みが入ったとき
に整合性を保ちつつ,割り込みを処理することが難しいからである.しかしながら,
「段階的に処理
する」方法の方が無反応状態を無くし,さらに進行状況を示すことができるため,
「進行状況を見せ
る」方法よりユーザのストレスを減らすことができる.よって,Rabbit では段階的に処理する方法
を採用し,待ち時間によるユーザのストレスを減少させる.
4.3
プレゼンテーション
既存のツールは貧弱過ぎる.Rabbit ではプレゼンテーション時の機能として,既存のプレゼン
テーションツールにある機能はもちろん,既存のプレゼンテーションツールにはない機能を提供す
4.3. プレゼンテーション
29
る.本節では以下に挙げる既存のプレゼンテーションツールにはない特長となる機能について述
べる.
• 豊富なコマンド起動インターフェイスの提供
• プレゼンテーション支援機能
• コメント機能
また,プレゼンテーション中のユーザのストレスを減少させる機能についても述べる.
4.3.1
スライド移動
既存のプレゼンテーションツールはキーボードによるインターフェイスとして以下のものを提供
している.
• スペース/バックスペースキーによる前後のスライドへの移動
• 矢印キーによる前後のスライドへの移動
• 数字キーによる指定したスライドへの移動
他にも以下のようなインターフェイスが提供されることがある.
• ページアップ/ページダウンキーによる前後のスライドへの移動
• ホーム/エンドキーによる最初/最後のスライドへの移動
これらは,一般的なエディタやテキスト入力インターフェイスで提供されているキーを用いたわ
かりやすいインターフェイスである.
しかしながら,プログラマが好んで使うエディタでは,カーソル移動は編集作業によく用いるた
め,エディタ独自のキーバインドを提供していることが多い.例えば,Vim では h, j, k, l による
カーソル移動をサポートしているし,Emacs では C-b, C-n, C-p, C-f によるカーソル移動をサポー
トしている.プログラマにとって,これらのキーバインドでスライド移動ができた方が自然である.
そこで,Rabbit では,既存のプレゼンテーションツールが提供する矢印キーなどを用いたイン
ターフェイスだけではなく,Emacs 風キーバインド,Vi 風キーバインドも提供する.
また,数字キーを用いたスライド移動では 0 枚目から 9 枚目まで5 しか移動できない.そこで,
Rabbit では,Control キーや Alt キーを組み合わせて利用することで 0 枚目から 39 枚目まで移動
できるインターフェイスを備えている.
n ストロークキーバインドをサポートしてこの制限を取り除くこともできるが,40 枚目以降のス
ライドに移動する機会がそれほどないことを考えると Rabbit のインターフェイスは現実的なイン
ターフェイスである.
5 あるいは
1 枚目から 10 枚目まで
第4章
30
4.3.2
新しく開発する機能
キーボードカスタマイズ
既存のテキスト型のプレゼンテーションツールは,全てのコマンドをキーボードから起動する.
プログラマにとってキーボードインターフェイスが用意されていることは魅力的である.しかしな
がら,既存のテキスト型のプレゼンテーションツールでは,キーバインディングは固定されていて,
ユーザが変更することはできない.
プログラマはツールを自分好みにカスタマイズしようとする.Rabbit では,全てのキーバイン
ドが変更可能である.これにより,プログラマは Rabbit を自分好みの手に馴染んだツールとして
使うことができるようになる.
4.3.3
マウスインターフェイス
既存のテキスト型のプレゼンテーションツールはポップアップメニューのサポートがない.プロ
グラマにとってキーボードが主体のインターフェイスは魅力的であるが,マウスを用いたグラフィ
カルなインターフェイスの方が便利なこともある.
例えば,スライド書き込みの際のペンの色や太さを変えることを考える.キーボードから色を
RGBA 値で指定することもできる.しかしながら,カラーパレットからマウスを用いて色を選択す
る方がより直感的で容易に色を選択できる.
Rabbit では,既存のプレゼンテーションツールよりもキーボードインターフェイスを強化するだ
けではなく,マウスインターフェイスも強化する.まず,WYSWYG 型にあるようなポップアップ
メニューをサポートし,多くの機能をポップアップメニューから起動できるようにする.また,マ
ウスインターフェイスがキーボードインターフェイスよりも有効である,スライド書き込みのため
のカラーパレットも提供する.
4.3.4
マウスジェスチャ
マウスジェスチャとはマウスの動きによって機能を実行するインターフェイスであり,主に Web
ブラウザでサポートされている.
一般に,マウスによるインターフェイスは直感的であるが,作業が多くなると面倒になることが
多い6 .マウスによるインターフェイスで機能の実行は,選択し,クリックという手順となる.例え
ば,ポップアップメニューでは,項目を選択して,クリックで機能を実行する.このような手順で
は,利用可能な機能など選択対象が多くなる程,選択が面倒になる.
マウスジェスチャでは,マウスの動きで選択とクリックをまとめて行うことができる.これによ
り,マウスによるインターフェイス特有の煩わしさを軽減することができる.
6 キーボードによるインターフェイスはマウスによるインターフェイスほど直感的なことは少ないが,面倒な作業を短縮
することができる.例えば,マウスを 10 回クリックして 10 枚スライドを進めるよりも,n を 10 回押して 10 枚スライド
を進める方が楽である.
4.3. プレゼンテーション
31
多くのブラウザがサポートしている一般的なインターフェイスであり,マウスを使用しているの
にストレスの小さいインターフェイスので,Rabbit ではマウスジェスチャをサポートする.既存の
プレゼンテーションツールでマウスジェスチャをサポートしているものはない.
Web ブラウザなど既存のアプリケーションではマウスの軌道を表示するだけのものが多いが,こ
れでは現在の軌道でどのような機能が利用可能なのかがわからない.軌道だけではなく,現在の軌
道に対応する機能を表示することによりわかりやすさを向上させているアプリケーションもある.
しかしながら,この方法では,次にどう動いたらどの機能が利用可能であるのかということがわ
からない.そこで,一部のアプリケーションでは軌道だけではなく,図 4.1 のように,次にどう動
いたらどの機能が利用可能であるかを示す画像も表示することでわかりやすさを向上させている.
Rabbit でもこのインターフェイスを採用する.
4.3.5
覗き穴
プログラマはプレゼンテーション中にターミナルを開いてデモを行うことがよくある.その際,
既存のプレゼンテーションツールでは,プレゼンテーションツールのフルスクリーンを解除して,
ターミナルを開き,デモが終わるとまたプレゼンテーションツールをフルスクリーンにする7 .こ
れは,観客の視線や意識がプレゼンテーションからデスクトップなど関係のないものに向いてしま
うなどプレゼンテーションの流れを壊してしまう.
そこで,Rabbit では,図 4.2 のようにスライドの一部を透過にして,後ろのウィンドウが見える
機能を提供する.この機能を用いることにより,スライドのフルスクリーンを解除せずにデモを行
うことができる.デモが終了したら透過部分を元に戻すだけでよい.
この機能は今までにない新しいインターフェイスを提供するため,この機能を用いたプレゼン
テーションをはじめて見た人にとって大きな衝撃を与える.これは,実際に筆者がこの機能を用い
たプレゼンテーションを行って確認した.
図 4.1: マウスジェスチャのユーザインターフェイス
7 デモ用のアプリケーションがフルスクリーンをサポートしていればプレゼンテーションツールのフルスクリーンを解除
せずに,単にプレゼンテーションツールの上にデモ用のアプリケーションを配置すればよい.MagicPoint は X アプリケー
ションをスライド中に埋め込む機能を持つ.この機能はアプリケーションがフォーカスを要求しない xclock や xeyes の
ような X アプリケーションであれば問題はないが,ターミナルのようにフォーカスを要求する X アプリケーションでは
フォーカスとウィンドウマネージャの間で問題が発生する場合がある.
第4章
32
4.3.6
新しく開発する機能
レンダリングされたページのキャッシュ
テキスト型のプレゼンテーションツールは,ソースに具体的な配置情報を埋め込まずに,描画時
に動的に計算するため描画処理が重くなる傾向がある.これは待ち時間を増加させるためユーザの
ストレスとなる.
ただし,MagicPoint のように毎回最初から描画している場合でも,以下のようにすることによ
りユーザのストレスを減少させることができる.
• 段階的に描画し,描画途中でもイベント処理を行う.
• 次のページを先読みしキャッシュしておく.
Rabbit では,描画されたスライドを画像としてキャッシュしておくことにより,一度描画された
スライドを高速に表示することができる.また,全スライドをキャッシュするコマンドを提供する
ことにより,各スライドの表示を高速化することができる.
4.3.7
コメント
プレゼンテーション中に観客からのコメントを受け付ける機能を提供する.コメントは第 5 章で
述べる外部インターフェイスを用いて投稿する.投稿されたコメントはすぐにプレゼンテーション
画面に反映される.プレゼンテーション画面にコメントを表示する方法として,以下の 2 種類を用
意している.
• ポップアップ
• スライド表示を縮小し,左と下にスペースを空け,そこに表示する方法
これらは一度に両方使うこともできるし,片方だけ使うこともできる.図 4.3 は両方表示した例
である.
コメントを受け付ける機能を提供することで,観客がプレゼンテーションに割り込みやすくなる
ことが期待できる.しかしながら,観客が PC を起動しながらプレゼンテーションを観ていること
は少なく,また,フォーマルなプレゼンテーションであればあるほどプレゼンテーションに割り込
むという習慣がないため,コメントをする観客はほとんどいないのが現状である.
図 4.2: 覗き穴
4.4. 印刷
4.4
33
印刷
印刷に関する機能面では既存のプレゼンテーションツールと大きく異なるところはない.しかし
ながら,次に述べる描画機能の抽象化はプログラマに好まれる実装である.
4.4.1
描画機能を抽象化
プログラマは抽象化を好む.Rabbit では,描画機能をモジュール化し取り換え可能にしている.
このため,新しく描画モジュールを作成し,簡単に Rabbit に組み込むことができる.
現在は,以下のモジュールを提供している.
• オフスクリーンでスライドを描画できる画像生成用モジュール
• スライド描画以外にイベント処理なども行うディスプレイ用モジュール
• OpenGL[36] を用いた 3D オブジェクト描画用モジュール
• PostScript や PDF を生成する印刷用モジュール
詳しい実装は第 7 章で述べる.
図 4.3: コメント表示
35
第5章
外部インターフェイス
Rabbit を外部プロセスから操作するために,以下のインターフェイスを提供している.
• dRuby[27]
• XML-RPC[37]
• SOAP[11]
全てのインターフェイスで同じ機能を提供している1 ため,Rabbit に外部プロセスから接続する
ためにユーザが好きなインターフェイスを選択することができる.
本章では外部インターフェイスの詳細と,外部インターフェイスを利用した機能について述べる.
5.1
dRuby インターフェイス
dRuby はリモートにある Ruby オブジェクトのメソッドを呼び出すための Ruby のライブラリ
である.dRuby を用いることにより,リモートにある Ruby オブジェクトをローカルの Ruby オブ
ジェクトのように扱うことができ,簡単に分散システムを構築することができる.
dRuby を用いた外部インターフェイスの特長は以下の通りである.
• Ruby との親和性が非常に高い
• XML-RPC / SOAP を用いた外部インターフェイスより高速
Ruby との親和性が非常に高いのは,dRuby が Ruby のメソッド呼び出しをネットワークに拡張
するために作成されていることからもわかる.dRuby では,リモートオブジェクトがローカルオブ
ジェクトとほとんど同じように扱える.リモートオブジェクトのメソッドにブロックを渡すことが
できる.また,リモートオブジェクトのメソッド呼び出し中に発生した例外が,ローカルの呼び出
し側に返ってくる.
dRuby を用いた外部インターフェイスの方が XML-RPC / SOAP を用いた外部インターフェイ
スより高速なのは,通信方法が異なるからである.XML-RPC,SOAP を用いた外部インターフェ
イスでは XML と HTTP を用いて Rabbit と通信しているが,Ruby のマーシャル機能と直接 TCP
1 これは外部インターフェイス層を抽象化しているからであり,詳細は第
7 章で述べる.
第 5 章 外部インターフェイス
36
ソケットを用いて通信している dRuby を用いた外部インターフェイスの方がオーバヘッドが少な
いからである.メソッド引数や,返値にもよるが,およそ数 10 倍から 100 倍程度高速である.
一方,dRuby を用いた外部インターフェイスの欠点は以下の通りである.
• Ruby 以外の言語から接続できない
• 異なるネットワーク上にある Rabbit と接続することが難しい
Ruby からしか接続できないのは,dRuby がメソッド,Ruby オブジェクトの転送のために Ruby
のマーシャル機能を利用しているためである.これは,dRuby を Ruby 用に最適化し,Ruby にとっ
て非常に使いやすいライブラリであるために支払った代償である.
異なるネットワーク上にある Rabbit と接続することが難しいのは,異なるネットワーク間には
ファイアウォールが設置されていることが多いからである.XML-RPC / SOAP は通信プロトコ
ルとして HTTP を利用するため,容易にファイアウォール を通過できることが多いが,dRuby が
用いているプロトコルは dRuby のための専用プロトコルで,使用する TCP ポート番号も標準的な
番号がないため,ファイアウォールを通過して異なるネットワーク上の Rabbit と通信することは
難しい.
しかしながら,不可能というわけではない.この問題を解決するために,ファイアウォールの設
定を変更したり,SSH のポート転送を用いる方法がある.
5.2
XML-RPC インターフェイス
XML-RPC は XML と HTTP を用いた RPC(Remote Procedure Call) の仕様である.仕様書が
A4 で 3 ページ程というくらい仕様が小さく,シンプルなのが特長である.また,通信プロトコルと
して HTTP を用いているため,ファイアウォールを容易に通過することができ,RPC のマーシャ
ルフォーマットとして XML を用いているため様々な言語用のライブラリが存在するという特長が
ある.
Rabbit は dRuby を用いた外部インターフェイスでは実現できない以下の機能を実現するために
XML-RPC を用いた外部インターフェイスを提供する.
• Ruby 以外の言語との連携
• 容易なファイアウォール越え
ただし,dRuby を用いた外部インターフェイスを用いた場合の以下の特長は失われる.
• Ruby との高い親和性
• 高速な RPC
5.3. SOAP インターフェイス
37
Ruby との高い親和性が失われる例として,RPC 中に発生した例外の転送がある.dRuby では例
外オブジェクトをそのまま呼び出し側に転送するのに対し,XML-RPC を用いた場合は例外のメッ
セージのみが転送される.
RPC 速度に関しては第 5.1 節で述べた通り,およそ数 10 倍から 100 倍程度 XML-RPC インター
フェイスを用いた方が遅くなる.
5.3
SOAP インターフェイス
SOAP は XML-RPC 同様,XML を用いた RPC の仕様である.SOAP は,通信プロトコルとし
て主に HTTP を用いて RPC を行うが,SOAP 自体は通信プロトコルに依存していない.その例と
して,仕様書には HTTP だけではなく,SMTP と共に SOAP を用いて RPC を行うという記述が
ある.SOAP は XML-RPC と異なり,その仕様は膨大であり,XML-RPC よりも高機能である.例
えば,XML-RPC では,基本的な 8 種類の型しかサポートしていないのに対し,SOAP では,XML
Schema のデータ型,数十種類をサポートし,さらに,利用者が拡張できるようにもなっている.
dRuby を用いた外部インターフェイスと比較した際の利点は XML-RPC を用いた外部インター
フェイスと同様である.欠点もほぼ同様であるが,XML-RPC では失われた Ruby との高い親和性
は SOAP を用いた外部インターフェイスの方がいくらか改善されている.例えば,XML-RPC を用
いた場合にはできなかった例外オブジェクトの転送がサポートされている.しかしながら,ブロッ
クの転送などはサポートされていない.
5.4
インターフェイスの選択
以上のように Rabbit には機能が同じ外部インターフェイスが 3 種類存在する.本節では,どの
ような場合にどの外部インターフェイスを用いればよいかを述べる.
Ruby から接続する場合は dRuby を用いた外部インターフェイスを用いるのが,機能/速度のど
ちらの面からみても最良の選択である.しかしながら,異なるネットワークから接続したい場合や,
異なる言語を用いて接続したい場合は XML-RPC または SOAP を用いた外部インターフェイスを
用いる必要がある.
機能面は SOAP の方がよいが,速度面は XML-RPC の方が良い.しかしながら,大きな差はな
いため,SOAP か XML-RPC かの選択は言語にライブラリがあるかどうかでするとよい2 .もし,
どちらのライブラリもある場合は,使い勝手で選ぶと良い.
5.5
使用例
本節では Rabbit がどのように外部インターフェイスを利用しているかを述べる.
2 SOAP
よりも XML-RPC の方が仕様が小さいため,言語に SOAP 用ライブラリがない場合でも,XML-RPC 用ライ
ブラリがあることがある.例えば,Gauche[16] がそうである.Gauche には SOAP 用ライブラリは存在しないが,xsm[33]
という XML-RPC 用ライブラリが存在する.
第 5 章 外部インターフェイス
38
5.5.1
専用 Web サーバの提供
Rabbit は dRuby インターフェイスを用いて,現在表示中のスライドを画像として HTTP 経由
で配信する Rabbit 専用の Web サーバ Rabrick を提供する.これにより,プレゼンテーション中の
計算機に HTTP で接続し,表示中のスライドを手元の Web ブラウザで見ることができる.会場が
大きい場合や,機材トラブルでプロジェクタにスライドを表示できない場合に利用できる3 .
また,HTTP 経由でコメントを投稿する機能も提供する.これを用いることにより,Web ブラ
ウザでプレゼンテーションを観て,さらにスライドにコメントを付けることもできる.
既存のプレゼンテーションツールでは,MagicPoint がスライドを HTTP 経由で配信する機能を
提供している.しかしながら,MagicPoint の提供する Web サーバ mgpnet は MagicPoint の実行
コマンドである mgp と直接通信して連携しているわけではない.図 5.1 にその連携方法を示す.
まず,mgpnet が起動すると,内部で fork して mgp を起動する.その際,mgp には状態が変わっ
たら指定したタイムスタンプファイルを更新するように指示する.mgpnet は指定したタイムスタ
ンプファイルを監視し,mgp の状態が変わったかどうかを検出する.状態が変わっていた場合は
xwintoppm コマンドを用いて mgp が表示しているウィンドウを画像として保存する.mgpnet が
HTTP リクエストを受け取ると保存した画像を用いて HTML を作成し,レスポンスを返す.
つまり,タイムスタンプファイルの更新で mgp と mgpnet が同期し,スライド画像は mgp の画像
生成機能ではなく,表示されているスライド画面のダンプで生成している.
この方法では,mgp と mgpnet は直接通信する必要がなく,mgp 側にはタイムスタンプファイル
を更新する機能を付けるだけで良い.しかしながら,スライド画面のダンプ時に問題が発生するこ
とがある.タイムスタンプファイルの更新とタイムスタンプファイルが更新されたことを検出する
間にタイムラグがあるため,スライド画面のダンプ画像に他のウィンドウが入ってしまうことがあ
る.これは,ダンプ画像生成時に mgp のウィンドウに他のウィンドウが重なっている場合に起こる.
ただ,通常のプレゼンテーション時にはフルスクリーンでプレゼンテーションを行うため,この問
題が発生することはない.
図 5.1: mgp と mgpnet の連携
3 著者はノート PC とプロジェクタの接続用コネクタを忘れたため,この機能を使い,借りたノート PC の Web ブラウ
ザでプレゼンテーションを行ったことがある.
5.5. 使用例
39
Rabrick でもこの方法を採用することができる.しかしながら,この方法は X Window System
上でしか使うことができない.
Rabrick は,図 5.2 のように Rabbit 本体とは別プロセスで起動し,Rabbit 本体とは dRuby を用
いて接続する.画像生成は Rabbit 本体が行い,Rabrick は HTTP リクエストの処理のみを行う.こ
のように,画像生成処理を Rabrick ではなく,Rabbit 本体が行うようにすることにより,Rabrick
が Rabbit 本体の状態が変わったかどうかを監視する必要が無くなる.また,画像生成を Rabbit 本
体が自身の内部バッファを用いて行うため,ウィンドウが重なることによりゴミが入ることもなく,
Rabrick もマルチプラットフォームで動作することができる.
5.5.2
サーバモードの提供
Rabbit は,自身をライブラリとして使用できるだけではなく,外部プロセスからレンダリングエ
ンジンとして利用することもできる4 .
Rabbit を外部プロセスからレンダリングエンジンとして利用するために,Rabbit と外部プロセ
スをつなぐ手段として外部インターフェイスを利用する.外部インターフェイスを通じて Rabbit
を利用する際,大きく分けて以下の 2 つの場合がある.
• Rabbit からの出力を参照するだけで Rabbit の状態を変えるような入力を行わない.
• Rabbit からの出力を参照するだけではなく,Rabbit に値を送ったりして Rabbit の状態を変
更する.
第 5.5.1 節で述べた Web サーバを用いて HTTP 経由でスライド画像を配信する場合は,前者の
Rabbit の状態を変えない利用例である.Rabbit をレンダリングエンジンとして利用したい場合は,
外部から入力ソースを与えたり,スライドを進めたりする必要がある.これが後者の Rabbit の状
態を変える利用法である.
図 5.2: Rabbit と Rabrick の連携
4 同じようなことは,Impress では UNO (Universal Network Objects) を用いて,PowerPoint では DCOM (Distributed Component Object Model) を用いることにより実現できる.ただし,UNO も DCOM も Impress や PowerPoint
専用の技術ではなく,OpenOffice.org や Windows 全般で利用されるための技術のため,Impress や PowerPoint に接続
するために形式的なコードを書かなければいけない.一方,Rabbit の場合は,どのインターフェイスを利用する場合でも
接続先の URI を指定するだけで簡単に接続することができる.
第 5 章 外部インターフェイス
40
Rabbit は,自身をレンダリングエンジンとして利用するために,サーバモードを提供する.通常
はスライド移動すら受け付けないが,サーバモードでは,スライド移動はもちろん,ソース変更や
サイズ変更も受け付ける.
5.5.3
RWiki との連携
サーバモードの利用例として RWiki との連携がある.RWiki との連携は,第 4.1.1 項で RWiki
のページを入力ソースとし使用できることを述べた.これは,Rabbit が RWiki にリクエスト行い,
RWiki がそれに応えるという関係である.ここで述べるのは,図 5.3 のように SOAP インターフェ
イスを用いて Rabbit と RWiki が双方向に連携する場合である.
Rabbit をサーバモードとして利用することにより,外部から Rabbit に入力ソースを送り込み,
スライド表示結果を画像として取り出すことができる.本項での連携では,RWiki が Web ブラウザ
からのリクエストを受け付け,RWiki のページの内容を RWiki 自ら Rabbit に送る.そして,RWiki
が Rabbit が生成したスライド画像を Web ブラウザに送る.
このように,サーバモードとして Rabbit を用いることにより Rabbit をレンダリングエンジン
として利用することができる.
図 5.3: Rabbit と RWiki の連携
41
第6章
テーマ
テーマは見栄えを定義するための機能であり,Rabbit の最も特長となる機能である.本章では
テーマの詳細について述べる.
6.1
テーマ記述言語
見栄えの定義のために,MagicPoint のように独自の記述言語を設計したり,Pyslide が CSS を採
用したように既存の記述言語を用いる場合がある.
Rabbit ではテーマ記述言語を DSL (Domain Specific Language) として独自に設計した.DSL
には言語内 DSL (Internal Domain Specific Language) と言語外 DSL(External Domain Specific
Language) の 2 種類があり,それぞれ以下の通りである.
言語内 DSL 既存のプログラミング言語上に問題領域用のための API を用意し構築された言語の
ことである.
言語内 DSL を構築する側は既存の言語の資産を利用したり,DSL を評価するために既存の言
語の評価器を利用することができるため容易に DSL を構築することができる.
また,DSL 内では既存の言語の機能がそのまま使えるため,DSL 使用者に問題領域に特化し
た API 以外の,既存の言語が提供する機能をそのまま提供することができる.これにより,
容易に DSL の記述力を高めることができる.
言語内 DSL を記述する側は,ベースとなっている既存の言語を知っているかどうかで学習
コストが大きく異なる.ベース言語を知っている場合は学習コストはほとんどなく,DSL 用
に用意された API を理解すればよいだけである.一方,ベース言語を知らない場合は言語外
DSL と同じように言語をはじめから学習しなければいけないため学習コストが大きくなる.
ただし,言語内 DSL を利用するためにベース言語の機能を完全に理解しなければいけないと
は少ない.多くの言語内 DSL では,簡単な設定は代入やいくつかのリテラル表記を覚えるだ
けで済む場合が多い.もちろん,DSL の機能を使いこなしたい場合はベース言語を学習しな
ければいけないため,言語外 DSL 同様,学習コストが大きくなる.
また,DSL 中でベース言語の機能も使えるため,DSL をより簡潔に記述することができる.
しかし,ベース言語が型定義を要求するなど言語の制限が多い場合は,逆に記述が複雑にな
り DSL の見通しが悪くなる場合がある.
第6章
42
テーマ
言語外 DSL 問題領域用のために構築した新しい言語のことである.
言語外 DSL を構築する側はパーサや評価器などを独自に実装しなければいけないため,言語
内 DSL と比べて開発コストが高い.しかし,独自に構文を定義できるため,記述性が高いな
ど使いやすい DSL を構築することもできる.
DSL の機能を減らしたり,構文上の制限を多くすることにより DSL の構築コストを下げるこ
とができる.しかし,それは記述時のコストが高くする.DSL がどの程度の記述力を提供す
るようにするかが言語外 DSL を構築する際のトレードオフになる.
言語外 DSL を記述する側は,はじめから DSL を学習しなければいけないため学習コストが高
い.DSL がシンプルな場合は学習コストが低くなるが,高いカスタマイズ性を好むプログラ
マには物足りなくなるだろう.一方,強力な DSL の場合は高いカスタマイズ性を好むプログ
ラマの性質を満足させるだろう.しかしながら,プログラマは使い回しのきかない独自 DSL
を学習したいと思わないだろう.
Rabbit では高いカスタマイズ性を提供しながら開発コスト,学習コストを低くおさえられる言語
内 DSL を採用する.ベース言語は,動的で,変数に型がなく,見た目が既存の設定ファイル風な
DSL を構築することも簡単なため,Ruby を採用する1 .よって,Rabbit ではテーマ記述言語とし
て Ruby 上に言語内 DSL を構築する.
6.2
テーマ記述
テーマの記述は大きく以下の 3 種類に分類できる.
• 宣言的記述
• 要素選択記述
• フック記述
テーマ記述のおおまかな流れは要素を選択し,その要素に対してプロパティを設定するという
CSS (Cascading Style Sheets) と同じような流れになる.CSS と異なり,テーマは「本物の」プロ
グラミング言語で記述するため,プロパティを設定しただけでは行えないような複雑な処理をプロ
グラムすることができる.この部分がフック記述であり,既存のプレゼンテーションツールでの見
栄え定義とは大きく異なる部分である.
6.2.1
宣言的記述
要素にプロパティを設定したり他のテーマを取り込んだりするためには図??のように記述する.
1 Rabbit
自体が Ruby で記述されているという理由もある.
6.2. テーマ記述
43
¶
³
prop_set("foreground", "red")
include_theme("rabbit")
µ
´
このように,どのように処理を行うのかという処理方法ではなく,どんな処理を行うのかという
処理内容を単純に示す記述を宣言的記述と呼ぶことにする.宣言的記述は,既存のソフトウェアの
設定ファイルの多くで見られる,設定を容易に変更できるようにする記述方法である.また,宣言
的記述は設定ファイルだけではなく,既存のテキスト型のプレゼンテーションツールの見栄え定義
にも採用されている.例えば,MagicPoint では文字の色を変更するために図??のような宣言的記
述をする.
¶
%fore "red"
µ
また,見栄え定義言語として有名な CSS で行う図??のような記述も宣言的記述である.
¶
³
´
³
... {
color: "red";
}
µ
´
宣言的記述は多くの設定ファイルにも見られる通り,Ruby を知らないのプログラマでも容易に
理解ができる.そこで,テーマでの宣言的記述は Ruby らしさよりも,より設定ファイルのような
記述ができることを目指している.例えば,テーマが提供する宣言的記述方法の中には,図??のよ
うに Ruby の Hash リテラルを用いることができるものがある.
¶
³
font({:color => "red",
:family => "Sans"})
µ
´
ただ,Ruby ではメソッド引数中では Hash リテラルの括弧を省略できるため,図??のようにも
書くことができる.
¶
³
font(:color => "red",
:family => "Sans")
µ
´
このように,Hash リテラルを用いることにより,Ruby のソースを記述しているというよりも,
設定ファイルを記述しているような見た目になる.
また,プログラミング言語では一般的な代入2 を用いた宣言的記述もプログラマには容易に理解
できる.テーマでは,代入を用いた宣言的記述も行うことができる.図??は横方向の中央揃えを指
定する例である.
2 Ruby
では代入もメソッド呼び出しである.
第6章
44
テーマ
¶
³
element.horizontal_centering = true
µ
´
しかしながら,代入を用いた宣言的記述は設定ファイルよりもプログラミング言語を連想しやす
い.テーマでは,より直感的に記述できるように,宣言的記述にはより設定ファイルらしさを提供
する.確かに,プログラマにとって代入を用いた宣言的記述は直感的である.しかしながら,後で
述べるフック記述ではよりプログラムらしさを求めるため,宣言的記述とフック記述で記述時の考
え方が異なる.これらの記述間で違いを明確にし,頭の切替えを行いやすくしたい.そのために,
宣言的記述からはできるだけプログラムらしさを減らし,設定ファイルらしさを提供する.
よって,テーマでは,宣言的記述には代入を用いるものよりも,メソッドを用いた宣言的記述を
推奨する.
また,メソッド呼び出しの括弧を省略3 することにより,より設定ファイルらしく記述できるよう
になる.例として,上述の include theme の例を考える.
¶
³
include_theme("rabbit")
µ
´
これから括弧を取り除く.
¶
³
include_theme "rabbit"
µ
´
これを見ると,include theme メソッドを呼び出しているのではなく,include theme という文
法があるように見える.
このように,メソッドの API を工夫したり,Ruby の省略可能な文法を利用することにより宣言
的記述をより設定ファイルらしく見せている.
6.2.2
要素選択記述
テーマでは,要素毎に表示方法を定義する.そのためには,対象となる要素を選択しなければい
けない.要素を選択するための記述を要素選択記述と呼ぶことにする.要素選択記述は図??のよう
に match メソッドを用いる.
¶
³
match(...) do
...
end
µ
´
match メソッドには引数として,対象となる要素のパスを指定する.パスにマッチした要素に対
して do から end4 が実行される.
例えば,図??はスライドタイトルを選択する例である.
3 Ruby
4 Ruby
はメソッド呼び出しの括弧を省略できる.
ではブロックと呼ばれる.コールバック関数をメソッドに関連付けるための便利な表現である.
6.2. テーマ記述
45
¶
³
match(Slide, HeadLine) do
...
end
µ
´
スライドタイトルを表す HeadLine 要素がスライドを表す Slide 要素の下にあるためこのように
パスを指定する.
このように match メソッドを用いることにより,どの要素でも選択できる.しかしながら,全て
の強調要素を赤く表示したい,といった場合,このようなフルパスを指定する方法では破綻してし
まう.そこで,パスにはワイルドカードを指定できるようになっている.ワイルドカードには 2 種
類ある.
• 全ての子要素を表す
• 自分自身と全ての子孫要素を表す
全ての子要素を表すワイルドカードは*で表す.自分自身と全ての子孫要素を表すワイルドカー
ドは**で表す.それぞれのワイルドカードが表す範囲を示したものが図 6.1 である.
ワイルドカードを用いることにより,図??のように簡単に全ての強調要素を赤く表示させるとい
う定義を書くことができる.
¶
³
match("**", Emphasis) do
font :color => "red"
end
µ
´
要素選択記述も宣言的記述のように,より設定ファイルらしくしたい.なぜなら,要素選択記述
も宣言的記述のように,
「なに」を記述するのであって,
「どのように」を記述するのではないからで
ある.つまり,要素選択記述はどのように要素を選択したいかではなくて,どの要素を選択したい
かを記述している.
図 6.1: ワイルドカードの表す範囲
第6章
46
テーマ
宣言的記述の場合のように,より設定ファイルらしく書き換えてみる.例として,図??の全ての
強調要素を赤く表示させる定義を使う.
¶
³
match("**", Emphasis) do
font :color => "red"
end
µ
宣言的記述の場合のように,これからメソッド呼び出しの括弧を省略する.
¶
´
³
match "**", Emphasis do
font :color => "red"
end
µ
´
宣言的記述を用いている CSS の場合と比較してみる.
¶
³
em {
color: "red";
}
µ
´
まず,マッチ条件があり,次にブロックがあり,ブロック内でプロパティを設定するという同じ
ような構文になっているのがわかる.さらに見た目を CSS に近づけることもできる.Ruby では,
ブロックの構文として do と end の組合せだけではなく {} の組合せもサポートしている.これを用
いて書き換える.
¶
match "**", Emphasis {
font :color => "red"
}
µ
{} を用いた方がより CSS のような見た目になっている.
³
´
ただし,ここで CSS のような見た目を目指しているのは,より宣言的に記述するためである.最
終的な目標が CSS と同じような見た目を実現することではない.メソッド呼び出しの括弧を省略
することにより宣言的な記述になるが,do と end の代わりに {} を用いた方が必ずしも宣言的な記
述になるわけではない.CSS に親しんでいる場合は {} の方が宣言的に見えるかもしれないし,そ
うでない場合は do と end の方が宣言的に見えるかもしれない.しかしながら,テーマでは do と
end という記述も {} という記述も使えるため,どちらの場合でも直感的にテーマを記述すること
ができる.
6.2. テーマ記述
6.2.3
47
フック記述
描画時の前後に呼び出される手続きを登録することにより,要素の描画をカスタマイズすること
ができる.Rabbit では,これをフックと呼んでいる.フックを用いることにより,箇条書きのマー
クの描画や,スライドの背景画像の描画などができる.他のプレゼンテーションツールにはない
Rabbit の最も特長となるパワフルな機能である.
フック記述は宣言的記述,要素選択記述と異なり,宣言的な記述を求めない.多くの場合,フッ
ク記述中には座標計算や描画方法などを記述する.つまり,フック記述にはプログラムを記述する.
プログラムを記述する部分で宣言的な記述を求めるとプログラムが書きづらくなる.プログラムを
記述する部分では,いつものようにプログラムが書けた方がよい.Rabbit がテーマ記述のために
「本物の」プログラミング言語を提供する理由はこのためである.
フックは要素が描画する前後に呼び出される.それぞれ,図??のように登録する.
¶
³
add_pre_draw_proc do |...|
...
end
add_post_draw_proc do |...|
...
end
µ
´
これからフックがどのように呼ばれ,どのように描画を行っているのかを述べるが,これはフッ
クだけではなく要素についても成り立つ.つまり,フックは疑似的に要素を追加しているとみなす
ことができる.
要素は描画するときに基準座標を渡される.基準座標というのは要素が描画を始める位置を示す
座標である.要素は,描画が終わったら,自分が描画した内容から次の要素がどこから描画を始め
ればよいかを計算し,その座標を返す.返された座標が次に描画する要素の基準座標になる.
フックにも基準座標が渡され,フックが返した基準座標が次の描画の基準座標になる.要素が描
画する前のフックが返す基準座標は要素の基準座標になり,要素が描画した後のフックが返す基準
座標は次の要素の基準座標になる.
例えば,10 ピクセルインデントしたい場合は図??のような描画前フックを登録する.
¶
³
add_pre_draw_proc do |..., x, y, w, h, ...|
[x + 10, y, w - 10, h]
end
µ
´
フックには基準座標以外にも,要素が描画できる残りの幅と残りの高さが渡る.上記の例では,
x 座標を 10 ピクセルインデントしたため,幅を 10 ピクセル短くしている.基準座標を (x,y),描
画できる残りの幅を w,残りの高さを h としたときの関係を図 6.2 に示す.図中では,
「タイトル」
第6章
48
テーマ
が描画する要素である.
フックには基準座標以外に,描画対象である Canvas オブジェクトが渡される.描画はこのオブ
ジェクトに対して行う.図??は箇条書きのためにマークとして 10 ピクセルの赤い円を描画し,マー
クの分だけインデントする例である.
¶
³
add_pre_draw_proc do |canvas, x, y, w, h, ...|
canvas.draw_circle(true, x, y, 10, 10, "red")
[x + 10, y, w - 10, h]
end
µ
´
実際に描画を行うまでにフックは 2 度呼ばれる.1 度目はシミュレーション描画と呼ばれる,実
際には描画を行わない呼び出しである.この呼び出しの際に,配置場所を決定したり,必要な画像
を読み込んだりする.いわば,コンパイルである.
2 度目の呼び出しは実際に描画を行う呼び出しである.2 度目の呼び出しでは,1 度目の呼び出し
によって計算された基準座標が使われる.図??は箇条書きのマークとして画像を用いる例である.
¶
³
pixbuf = nil
add_pre_draw_proc do |canvas, x, y, w, h, simulation|
if simulation
loader = ImageLoader.new(find_file("XXX.png"))
pixbuf = loader.pixbuf
else
canvas.draw_pixbuf(pixbuf, x, y)
end
[x + pixbuf.width, y, w - pixbuf.width, h]
end
µ
´
シミュレーション描画の際に画像を読込,2 度目の呼び出しの際にだけ描画する.このシミュレー
ション描画かどうかは simulation が true か false かでわかる.ImageLoader は画像読み込みの
図 6.2: 基準座標と残りの幅と残りの高さの関係
6.3. 値の正規化
49
ためのクラスである.find file は画像の検索パスの中から指定した名前の関数を探すメソッドで
ある.画像は Gdk::Pixbuf オブジェクトとして扱っている.
このように,フック記述では基準座標の更新のために数値計算を行ったり,画像を読み込んだり,
実際に描画を行うためにさまざまなオブジェクトを利用する.これはまさにプログラムである.テー
マ中では宣言的な記述を支援するように設計されているだけではなく,
「本物の」プログラムを記述
することを支援するようにも設計されている.
6.3
値の正規化
テーマ中では正規化された値を用いる.これは,スライドの大きさが変わっても,テーマを変更
せずに相対的に同じ位置や同じ大きさに描画できるようにするためである.テーマ中で正規化され
た値をスライドの大きさに応じた値に変換するために以下のメソッドを提供している.
screen x 正規化された x 座標の値をスライドの幅に応じた値に変換する.
screen y 正規化された y 座標の値をスライドの高さに応じた値に変換する.
6.4
テーマの使用例
Rabbit にはテーマを使用して既存のプレゼンツールにある機能はだけではなく,Rabbit 特有の
機能も実現している.
6.4.1
自動再読み込みの強化
第 6.2.3 項で述べた通り,テーマにはプログラムを記述する能力がある.タイムアウト時間を指
定して,一定間隔毎に処理を実行することもできる.
これを利用して,一定間隔毎に再描画シグナルを発行することができる.再描画要求によって,
Rabbit のソース再読み込み機能が動く.つまり,一定間隔毎にソースが変更されたかをチェックす
るようになる.これにより,ソースの変更が一定間隔毎に自動でスライドに反映されることになる.
よって,手動で再描画シグナルを発行してソースの変更をスライドに反映されるまでの待ち時間を
減らすことができ,スライド校正の効率を上げることができる.
6.4.2
タイマー
一定時間毎に再描画シグナルを発行すると,一定時間毎に異なる内容を描画することもできる.
これを利用して,タイマーを表示することができる.Rabbit は現在時刻を表示するテーマ,プレゼ
ンテーションの残り時間を表示するテーマを提供している.
第6章
50
テーマ
プレゼンテーションの残り時間を表示する機能は,既存のプレゼンテーションツールではリハー
サルモードなどとして用意されている機能である.これは,プレゼンテーションのペース配分を計る
ために便利な機能である.しかしながら,筆者の経験ではプレゼンテーション中に残り時間とスラ
イドの残り枚数から,進みすぎている,遅れている,などを判断するのは難しい.そこで,Rabbit
では従来の文字ベースで残り時間を表示するテーマだけではなく,プログレスバーのように,あと
どのくらいかを具体的な値ではなく視覚的に表現するテーマも提供する.
6.4.3
スライド数表示
フック記述中では,描画時の状態から動的に描画内容を変更することもできる.これを利用して,
現在のスライドが何枚目のスライドかを表示するテーマを 2 つ提供している.
1 つはテキストで「現在のスライド番号/全部の枚数」と表示するものである.例えば,全部で 10
枚のスライドがあって,現在 2 枚目を表示している場合は「2/10」と表示する.これは既存のプレ
ゼンテーションツールにも見られる,
もう 1 つは,前述のプレゼンテーションの残り時間でも用いた手法で,プログレスバーのように,
全スライド枚数からどのくらいかを視覚的に表示するものである.このテーマと,前述のプレゼン
テーションの残り時間をプログレスバーのように表示するテーマを組み合わせることによって,ス
ライドの進み具合と残り時間の関係が一目でわかるようになるという今までになかったインター
フェイスができる.
この使用法は,
「うさぎ5 とかめ」の物語を模して説明することができる.実際,テーマでは,ス
ライドの進み具合を示すためにうさぎの画像を,残り時間を示すためにかめの画像を用いている.
使用例を図 6.3 に示す.
「うさぎとかめ」はうさぎとかめが競走する物語である.うさぎは最初かめを引きはなすが,途
中で怠けてしまうことによってかめに追い越されてしまう.この使用法では,うさぎの立場になっ
て,かめに追い越されずにゴールすることを目標にする.
うさぎは,スライドの進み具合を示し,かめは残り時間を示すとする.うさぎは,発表者がスラ
イドを進めない限り前には進まない.一方,何もしなくても時間は経つので,かめは黙っていても
図 6.3: うさぎとかめ
5 この「うさぎ」は英語では
hare であって,rabbit ではない.
6.4. テーマの使用例
51
進む.一般に,前半のスライドは立ち入った話をせずに,理解しやすい話から入って,プレゼンテー
ションの導入部分を説明する.ここでは,1 枚のスライドにそれほど時間をかけずに進むことがで
きる.一方,中盤から後半にかけての,プレゼンテーションのメインの話をするところでは,説明
のために 1 枚のスライドに前半よりも時間がかかってしまうことがある.
つまり,前半ではうさぎは順調に進み,後半はうさぎの進み具合が遅くなることが多い.しかし
ながら,かめは一定間隔で進んでいく.プレゼンテーションでは,かめに追い付かれずにうさぎが
ゴールするようにすればよい.もっと言えば,うさぎとかめが仲良くゴールするのが理想である.
ペースが速いか遅いかはうさぎとかめのどちらがどのくらい進んでいるかを見れば良い.テキスト
で残り時間を示されている場合と違って,うさぎとかめの位置を見るだけでよいので,一瞬でペー
スを確認することができる.また,ユーモアがあり,プログラマの遊び心も満足させる優れたイン
ターフェイスである.
6.4.4
表
第 3.1.7 項で述べた通り,他の要素と同様,表の描画もテーマで行っている.MagicPoint のよう
に表の描画を外部ツールに頼っていないため,柔軟に見栄えを変更できる.また,他の要素と同じ
インターフェイスで変更できるため,学習コストを下げている.
6.4.5
画像
画像の拡大縮小は画像要素が行っているが,画像の配置,枠や表題の表示などはテーマが行って
いる.画像の拡大縮小は画像要素が行っているとはいえ,テーマ側でも行うことができる.
画像の配置とは,センタリングするかどうかということである.センタリングは,他の要素と同
様,水平方向にも垂直方向にも行うことができる.
デフォルトでは画像の周りに枠を表示しないようになっているが,オプションで枠付きにするこ
とができる.また,枠に影を付けることもできる.
もし,画像に表題が指定されていた場合は,表題用のスペースを用意して,表題を描画する.
6.4.6
デバッグ
テーマを作成している際は,要素がどのくらいの幅/高さを持っているかがわかると都合が良い.
そこで,全ての要素の境界線を表示するテーマを提供している.このテーマはとてもシンプルで,
図??のように実現している.
¶
³
match "**" do
draw_frame :frame_color => "blue"
end
µ
´
第6章
52
6.4.7
テーマ
テーマの合成
テーマは include theme メソッドを用いることにより他のテーマを読み込むことができる.Rabbit
では,見栄えを定義する対象の小さなグループ毎にテーマを分割することを推奨している.例えば,
箇条書きの見栄え定義,タイトルスライドの見栄え定義,などというようにテーマを分割する.こ
のように,グループ毎にテーマを分割することにより,テーマの再利用性を高めることができる.
例えば,デフォルトのテーマを少しだけ変えて使いたいとする.もし,強調要素の色を赤から青
に変えたいだけなのであれば,図??のようにすればよい.
¶
³
include_theme "default"
match "**", Emphasis do
font :color => "blue"
end
µ
´
箇条書きは「Rabbit」テーマを使って,他はデフォルトのテーマでよいという場合を考える.も
し,
「Rabbit」テーマがグループ毎にテーマを分割しているなら図??のように書くだけでよい.
¶
³
include_theme "default"
include_theme "rabbit-item-mark"
µ
´
しかし,
「Rabbit」テーマの見栄え定義がすべて同じファイルに記述されている場合は上記のよう
に簡単にはいかない.なぜなら「Rabbit」テーマの箇条書きの見栄え定義の部分だけ取り出すこと
ができないからである.
また,グループ毎にテーマを分割することによってテーマファイルの見栄えがよくなるという利
点もある.図??はデフォルトのテーマの内容である.
6.5. テーマの動的変更
53
¶
³
add_image_path "ruby-images"
include_theme "image"
include_theme "table"
include_theme "slide-number"
include_theme "default-icon"
include_theme "default-text"
include_theme "default-title-slide"
include_theme "default-slide"
include_theme "default-item-mark"
include_theme "default-method-list"
include_theme "default-preformatted"
include_theme "default-foottext"
include_theme "default-description"
include_theme "windows-adjust"
µ
´
このように,デフォルトのテーマではどのグループが見栄えが定義されているかがすぐにわかる.
なお,add image path メソッドは画像の検索パスを追加するためのメソッドである.
6.5
テーマの動的変更
テーマの合成はテーマ記述中だけではなく,プレゼンテーション時にも行うことができる.また,
現在適用中のテーマにテーマを合成するだけではなく,現在適用中のテーマを変更することもで
きる.
テーマを変更した場合,前のテーマの設定は全てクリアされ,最初から変更されたテーマを指定
していたかのようになる.もし,ソースと見栄えを完全に分離していない場合は,ソース中に前の
テーマ用の設定が残っていて変更されたテーマの見栄えがおかしくなってしまうかもしれない.し
かしながら,Rabbit はソースと見栄えを完全に分離しているためそのような心配は無い.
55
第7章
実装
本章では Rabbit の機能をどのように実装しているかについて述べる.
7.1
段階的ソース読込
ソースの読み込みからスライドの表示まで,Rabbit は以下のような処理を行う.
• 読み込んだソースをパーズし Rabbit の内部構造に変換
• Rabbit の内部構造にテーマを適用
• スライドを描画
この処理の間には,画像の読み込みや内部構造のトラバースなどの処理がいくつも入るため,ユー
ザがストレスを感じないくらいの短い時間で処理を終えることができない.そこで,Rabbit はテー
マ適用中でも,適用中の内部構造を用いてスライド描画処理を実行することによりユーザのストレ
スを軽減している.つまり,上記の処理の流れは図 7.1 のようになる.
これは Rabbit が採用している GUI ツールキットである GTK+が提供している,現在溜ってい
るイベントを処理する API を用いることにより実現できる.この API を利用して,テーマ適用処
理の途中に溜っているイベント(例えば,描画リクエストなど)を処理する.図 7.2 はテーマ適用
処理の合間に溜っているイベントを処理する例である.
これにより,テーマ適用処理の途中であっても,ユーザによるリクエストを処理することができ
る.このため,Rabbit の無反応時間が短くなり,ユーザのストレスを軽減することができる.
図 7.1: 段階的ソース読込
第 7 章 実装
56
なお,
「溜っているイベントの処理」は Rabbit で使用している Ruby/GTK2 では図??のように
書く.
¶
³
while Gtk.events_pending?
Gtk.main_iteration
end
µ
7.2
´
外部インターフェイス
Rabbit では,dRuby,XML-RPC,SOAP を用いた 3 種類の外部インターフェイスを提供して
いる.どのインターフェイスを用いた場合でも同じ機能を利用できる.これは,図 7.3 のような構
成になっているからである.
クライアントと Rabbit が通信するためには必ず Front オブジェクトを経由する必要があることが
重要である.つまり,全ての外部インターフェイスが Front オブジェクトを利用する.また,dRuby
の場合は Front オブジェクトを直接公開していて,XML-RPC と SOAP の場合は単に Front オブ
ジェクトをラップして公開しているだけである.つまり,Front オブジェクトの API が外部に公開
する API となる.
このように,外部インターフェイスからのアクセスを抽象化し,必ず Front オブジェクトを経由
させるようにすることによって,全ての外部インターフェイスに同じ機能を提供している.このよ
うな抽象化を用いた機能拡張はプログラマが好む実装である.
7.3
レンダリングモジュールの抽象化
Rabbit には画像,画面,印刷という 3 種類の出力種類があり,図 7.4 のような構成になっている.
図 7.2: テーマ適用中もイベントを処理
7.3. レンダリングモジュールの抽象化
57
画面出力は DrawingArea モジュールのみが利用可能であるが,画像出力,印刷出力はそれぞれ
数種類のレンダリングモジュールが利用できるようになっている.つまり,それぞれの出力種類ご
とにレンダリングモジュールが抽象化されている.これにより,Rabbit が動作する環境を増やす
ことができる.
画像を出力するときを考える.画像出力には GDK または cairo を利用できる.cairo はアンチア
イリアスやアルファチャンネルをサポートしていて,GDK よりも品質が良い出力を期待できるた
め,Rabbit は GDK よりも cairo を優先的に使おうとする.しかし,もし,Rabbit が動いている環
境で cairo が利用できなくても,画像出力機能は利用できる.この場合は,品質は落ちるが GDK
を用いて画像を出力することができる.
7.3.1
出力種類の関係
Rabbit のレンダリングモジュールは出力種類毎に独立しているわけではない.画面出力の DrawingArea
モジュールはバックエンドとして画像出力のレンダリングモジュールを利用している.つまり,
DrawingArea モジュールのバックエンドとして,GDK も cairo も OpenGL も利用できる.
同様の仕組を印刷出力でも,OpenGL でも利用している.印刷出力の multi print モジュールは,
1 ページに複数枚のスライドをサムネイルとして印刷するレンダリングモジュールである. multi
print モジュール自体は印刷処理は行わず,サムネイル用に座標変換を行ったり,サムネイルのレイ
アウトを処理するだけである.実際の印刷処理はバックエンドとして cairo または gnomeprint を
用いて行っている.
7.3.2
拡張可能性
レンダリングモジュールを抽象化することによってレンダリングモジュールを取り換えることが
可能になる.Rabbit では,さらにユーザが新たにレンダリングモジュールを作成し,Rabbit に組
み込むことを可能にする.
図 7.3: 外部インターフェイスの構成
第 7 章 実装
58
Rabbit は,Ruby の検索パスを調べていき,レンダリングモジュール用ディレクトリにあるファ
イルを自動的に読み込む.利用するレンダリングモジュールを決定するために,そのレンダリング
モジュールに設定された優先度を使う.例えば,画像出力では GDK よりも cairo を優先的に使う
ようになっているのは cairo の方が GDK よりも優先度を高く設定しているからである.
もし,ユーザが作成したレンダリングモジュールを使いたい場合は,検索パスが通っているレン
ダリングモジュール用ディレクトリにファイルを配置し,レンダリングモジュールの優先度を高く
すれば良い.Rabbit 本体を変更する必要はない.そのため,システムにインストールされている同
じ Rabbit を複数のユーザがそれぞれ別々にカスタマイズして使うことができる.スライドの見栄
えだけではなく,レンダリングモジュールまでもカスタマイズして使うことができるため,Rabbit
は高い拡張性を持っているといえる.
7.3.3
出力種類の抽象化
また,Rabbit のレンダリングモジュールは出力種類毎に抽象化されているだけではなく,図 7.4
ではレンダリングインターフェイスと示されているように,出力種類のレベルでも抽象化されてい
るため,テーマや Rabbit の内部要素が描画を行うときは出力種類を意識する必要はない.
このため,これから出力種類が増えた場合でも,既存のテーマなどを変更する必要なく新しい出
力種類を使うことができる.
7.4
テーマ
テーマはベース言語として Ruby を用い,言語内 DSL として設計した.Ruby には Kernel#eval
という Ruby の評価器を用いるメソッドが用意されている.テーマは Ruby を用いた言語内 DSL な
ので,テーマは DSL であると同時に Ruby のソースコードでもある.そのため,テーマの評価に
Kernel#eval を用いることができる.これにより開発コストが大きく下がる.
7.4.1
テーマ評価環境の提供
開発コストが下がる代償に使いづらいものになってはいけない.Ruby のソースコードには文脈
があり,その文脈で自明なものは省略可能である.例えば,以下は obj オブジェクトの meth メソッ
ドを呼び出す例である.
¶
³
obj.meth
µ
´
1
もし,レシーバ が自明な場合は省略できる.以下は Klass クラスに meth1 メソッドと meth2 を
定義する例である.
1 メッセージを受け取るオブジェクト
7.4. テーマ
59
¶
³
class Klass
def meth1
print "Hello"
end
def meth2
meth1
print " World!\n"
end
end
µ
´
このように,meth2 の中では,meth1 がレシーバ無しで呼び出せる.これは,メソッド定義の文
脈ではメッセージを受け取った Klass クラスのオブジェクトがデフォルトのレシーバとなるためで
ある.
テーマ中でも文脈を考慮することにより,記述量を大きく減らすことができ,書きやすくするこ
とができる.そのために,テーマを評価するためのオブジェクトを用意する.テーマの評価は全て
このオブジェクトの文脈で行われるようにする.これにより,テーマ評価用オブジェクトのメソッ
ドは全てレシーバ無しで呼び出すことができる.
このように,レシーバを省略できるようにテーマを評価するための環境を用意することによって,
よりテーマを書きやすくしている.
7.4.2
レシーバの差し替え
Ruby はオブジェクトにメソッドが定義されていない場合に,そのオブジェクトの method missing
メソッドを呼ぶ.これを利用してメソッドを別のオブジェクトに委譲することができる.
例えば,全ての強調要素を赤くする場合は以下のように記述する.
¶
³
match "**", Emphasis do
font :color => "red"
end
µ
´
font メソッドはテーマ評価用オブジェクトへのメソッド呼び出しである.しかしながら,事前
にテーマ評価用オブジェクトにフォント設定用メソッドを用意しておくことはできない.なぜなら,
テーマ評価用オブジェクトはどの要素に対してフォントを設定すればよいかわからないからである.
そこで,method missing を用いる.テーマ評価用オブジェクトに定義されていないメソッドは全
てこのメソッドで捕捉することができる.この場合,定義されていない font メソッド呼び出しが
method missing 呼び出しにつながる.
第 7 章 実装
60
match メソッドではマッチした要素を暗黙のうちに内部変数に保持している.method missing
ではその内部変数に,テーマ評価用オブジェクトには定義していない font メソッドの呼び出しを
委譲する.こうすることにより,図??のような明示的なフォント設定メソッド呼び出しをしなくて
もよくなる.
¶
³
match "**", Emphasis do |emphs|
emphs.font :color => "red"
end
µ
´
このように,method missing を用いてデフォルトのレシーバを差し替えることにより,より記
述しやすい API を提供している.
もうひとつ method missing を用いて利便性を上げている箇所がある.それは,上述の例の
emphs.font の部分である.
要素が複数個マッチする場合は多く,match がマッチした要素を配列として表現することは自然
である.しかしながら,配列にして,font メソッドが配列の要素全てにフォント設定を適用するよ
うにするには,Ruby の標準クラスである Array クラスを書き換える必要がある.これは,影響範
囲が大きく,見付けづらいバグの原因になったり,Rabbit をライブラリとして使用した場合に問題
が起こることが予想される.そこで,配列のように振るまい,font メソッドなどのように定義され
ていないメソッドは子要素全てに適用するコンテナオブジェクトを導入する.
method missing を用いているのは,このコンテナオブジェクトである.コンテナオブジェクト
は自身に定義されていないメソッドが呼ばれて,その結果として method missing が呼ばれると,
自身の子要素全てに呼び出されたメソッドを委譲する.それは以下のようなコードになっている.
¶
³
def method_missing(meth, *args, &block)
each do |elem|
if block
proxy_block = Proc.new do |*block_args|
block.call(elem, *block_args)
end
else
proxy_block = nil
end
elem.__send__(meth, *args, &proxy_block)
end
end
µ
´
proxy block を導入している理由は,ブロックに子要素を渡すためである.こうしないと,ブロッ
ク内で各要素を参照することができない.ブロック内で各要素を参照したいのは,以下のようにそ
れぞれの要素に同じブロックを使いまわしたいからである.
7.4. テーマ
61
¶
³
elements.add_pre_draw_proc do |element, x, y, w, h, simulation|
...
end
µ
´
ブロック内で各要素が参照できない場合は,以下のように書くことになり,結局単なる配列でも
よいことになる.
¶
³
elements.each do |element|
element.add_pre_draw_proc do |x, y, w, h, simulation|
...
end
end
µ
´
つまり,最初の例でだした以下の例は図 7.5 のように暗黙のうちに 2 段階でレシーバを差し替え
ている.
¶
³
match "**", Emphasis do
font :color => "red"
end
µ
このように,method missing を用いて動的にレシーバを変更することにより,テーマの記述量
を減らし,より直感的に記述できるようにしている.
´
第 7 章 実装
62
図 7.4: レンダリングモジュールの構成
図 7.5: 暗黙の 2 段階レシーバ差し替え
63
第8章
8.1
結論
まとめ
既存のプレゼンテーションツールの中にはプログラマのために作成されたものが無く,プログラ
マが満足するプログラミングツールが存在しない.本稿では,プログラマを満足させるプログラマ
のプレゼンテーションツールについて考察し,実装した.表 8.1 は既存のツールと本稿で提案する
プログラマのプレゼンテーションツール Rabbit とをプログラマの視点から見て比較したものであ
る.x がサポート無しまたはサポートが弱い,o がサポート有り,oo が非常によくサポートしてい
ること表している.
このように,Rabbit はプログラマが好む以下の性質をすべて満足する.
キーボードによるインターフェイス スライド作成/校正時にはエディタの強力なキーボードイン
ターフェイスを利用でき,プレゼンテーション時には Rabbit が提供する豊富なキーバインド
を利用することができる.
高いカスタマイズ性 スライド作成/校正時にはエディタのカスタマイズ機能が使え,プレゼンテー
ション時はテーマにより,キーバインドの変更,
「本物の」プログラミング言語による描画方
法のカスタマイズが行える.
既存のツールとの連携 スライド作成/校正時には,手に馴染んだエディタや,バージョン管理ソ
フトウェア,各種テキスト処理ユーティリティを利用できる.プレゼンテーション時にはソー
スを自動色付けするために Enscript と連携したりすることができる.また,ウィンドウの一
部を透過させることにより,プレゼンテーション中でも Rabbit のウィンドウの後ろにある他
のウィンドウを利用することができる.
モジュール化された拡張可能なシステム 描画用,印刷用のレンダリングモジュールを専用ディレ
クトリに置くだけで,Rabbit 本体を変更することなく組み込むことができる.
現在,Rabbit は筆者だけではなく,主に Ruby プログラマの間で使われている.これは本稿で考
察したプログラマのプレゼンテーションツールが実際のプログラマに受け入れられる要素を含んで
いるということを示している.また,海外で使用しているユーザがいるという事実は,国内のプロ
グラマだけではなく,海外のプログラマにも国内のプログラマと同様の性質があるかもしれないと
いうことを示している.
第 8 章 結論
64
表 8.1: プレゼンテーションツールの比較
項目
PowerPoint
Impress
propser
Rabbit
WYSIWYG
WYSIWYG
テキスト
テキスト
テキスト
x
x
oo
o
oo
バージョン管理
o(自前)
o(自前)
oo
oo
oo
キーバインドの変更
x
o
oo
oo
oo
外部ツールとの連携
x
x
oo
oo
oo
キーバインド
o
x
o
x
oo
キーバインドの変更
x
x
x
x
oo
ポップアップ
o
o
x
x
oo
マウスジェスチャ
x
x
x
x
oo
描画モジュールの追加
x
x
x
x
oo
描画時の自由度
x
x
o
x
oo
外部ツールとの連携
oo
o
o
x
oo
外部からの接続
o
o
x
x
oo
o
o
x
x
oo
種類
MagicPoint
スライド作成
編集のしやすさ
スライド校正
プレゼンテーション
印刷
印刷モジュールの追加
8.2
今後の課題
プレゼンテーションツールとしての基本機能は完成している.今後は拡張機能に注力していく.
例えば,以下の事項について検討している.
• マルチメディアのサポート
• 印刷品質の向上
• Emacs 専用編集モードの提供
• GIMP など既存のツールと連携することによる機能拡張
• ドキュメントの整備
Rabbit は http://www.cozmixng.org/˜rwiki/?cmd=view;name=Rabbit で入手できる.
65
参考文献
[1] Wiki RPC Interface. http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface2.
[2] Inc. Apple Computer. Keynote. http://www.apple.com/iwork/keynote/.
[3] ASCII. Publishing TeX. http://www.ascii.co.jp/pb/ptex/.
[4] Ayose Cazorla. Pyslide.
[5] William Chia-Wei Cheng. Tgif. http://bourbon.usc.edu:8001/tgif/.
[6] Microsoft Corporation. PowerPoint. http://office.microsoft.com/powerpoint/.
[7] Microsoft Corporation. Visual Studio. http://msdn.microsoft.com/vstudio/.
[8] Ulrich Drepper. GNU gettext. http://www.gnu.org/software/gettext/.
[9] Frederic Goualard. prosper. http://prosper.sourceforge.net/.
[10] W3C Math Working Group. MathML. http://www.w3.org/Math/.
[11] XML Protocol Working Group. SOAP. http://www.w3.org/TR/soap/.
[12] Sven Herzberg. Criawips. http://www.criawips.org/.
[13] Sun Microsystems Inc. Impress. http://www.openoffice.org/product/impress.html.
[14] Inc. John Forkosh Associates. mimeTeX. http://www.forkosh.com/mimetex.html.
[15] Tetsuya Kamei. xyzzy. http://www.jsdlab.co.jp/˜kamei/.
[16] Shiro Kawai. Gauche. http://practical-scheme.net/gauche/.
[17] Yukihiro Matsumoto. Ruby. http://ruby-lang.org/.
[18] Yukihiro Matsumoto.
rwiki/?cmd=view;name=RD.
Ruby
Document.
http://pub.cozmixng.org/˜the-
[19] Peter Mattis, Spencer Kimball, and Josh MacDonald. GTK+. http://www.gtk.org/.
[20] Bram Moolenaar. Vim. http://www.vim.org/.
第 8 章 結論
66
[21] Masao Mutoh. Ruby-GetText-Package. http://gettext.rubyforge.org/.
[22] National Institute of Advanced Industrial Science and Technology.
http://www.m17n.org/m17n-lib/.
m17n library.
[23] The Subversion Project. Subversion. http://subversion.tigris.org/.
[24] WIDE Project. MagicPoint. http://member.wide.ad.jp/wg/mgp/.
[25] Markku Rossi. GNU Enscript. http://www.codento.com/people/mtr/genscript/.
[26] rubikitch. RTtool. http://www.rubyist.net/˜rubikitch/computer/rttool/.
[27] Masatoshi SEKI. dRuby. http://www.druby.org/ilikeruby/druby.html.
[28] Masatoshi SEKI. RWiki. http://pub.cozmixng.org/˜the-rwiki/.
[29] Takuya SHIOZAKI. less プレゼン. http://www.imou.to/˜AoiMoe/column/less/.
[30] Richard Stallman. GNU Emacs. http://www.gnu.org/software/emacs/.
[31] Richard M. Stallman. GNU’s Not UNIX. http://www.gnu.org/.
[32] Kouhei Sutou. RD2TeX. http://www.cozmixng.org/˜rwiki/?cmd=view;name=RD2TeX.
[33] Kouhei Sutou. xsm. http://www.cozmixng.org/˜rwiki/?cmd=view;name=xsm.
[34] Owen Taylor. Pango. http://www.pango.org/.
[35] the KPresenter Team. KPresenter. http://www.koffice.org/kpresenter/.
[36] the OpenGL Architecture Review Board. OpenGL. http://www.opengl.org/.
[37] Dave Winer. XML-RPC. http://www.xmlrpc.com/.
[38] Carl Worth. cairo. http://cairographics.org/.
[39] Kazu Yamamoto. Goby. http://www.mew.org/˜kazu/proj/goby/.
[40] 高林哲, 小松弘幸, 増井俊之. Migemo: 日本語のインクリメンタル検索. 情報処理学会論文誌,
pp. 3698–3705, December 2002.
67
索引
– A –
– F –
a2ps, 8
API, 24, 41, 56
fork, 38
Front, 56
FTP, 23
– B –
BMP, 17, 22
– C –
cairo, 16, 57, 58
Cascading Style Sheets, =⇒ CSS
Criawips, 1
CSS, 42, 43, 46
CVS, 11, 24
– D –
DCOM, 39
diff, 2, 19, 26
Distributed Component Object Model, =⇒
DCOM
Domain Specific Language, =⇒ DSL, =⇒
DSL
DrawingArea, 57
dRuby, 35–39, 56
– G –
Gauche, 37
GDK, 57, 58
gettext, 16, 17
GIF, 22
GIMP, 64
GNOME, 1, 16
gnomeprint, 57
GNU, 19
Goby, 8, 9
grep, 2, 11
GTK+, 16, 19, 55
GUI ツールキット, 16, 55
– H –
HTML, 9, 22, 38
HTTP, 23, 35–39
DSL, 6, 41, 42, 58
DVI, 8
– I –
i18n, 16
IDE, 1, 11
– E –
Emacs, 1, 6–9, 11, 15, 17, 19, 21, 29, 64
Enscript, 25, 63
Impress, 1, 16, 19, 24, 39
Internal Domain Specific Language, =⇒ 言
EPS, 17
EUC-JP, 24
internationalization, =⇒ i18n, 16
ISO-2022-JP, 24
External Domain Specific Language, =⇒ 言
語外 DSL
–
語内 DSL
J
–
索引
68
JPEG, 17, 22
Portable Object, =⇒ PO
– K –
Keynote, 1
PostScript, 8, 9, 22, 25, 26, 33
PowerPoint, 1, 39
prosper, 1, 6–8, 12, 18, 19, 24, 25
KPresenter, 1
–
L
–
LaTeX, 6, 12, 17, 18, 22
less, 7
less プレゼン, 1, 7–9, 12, 19, 27
libgnomeprint, 16
– M –
m17n, 15
m17nlibrary, 15
Machine Object, =⇒ MO
MagicPoint, 1, 6–8, 12, 15, 18, 20, 25, 27, 28,
31, 32, 38, 41, 43, 51
MathML, 18
mgp, 6, 38
pTeX, 24
Pyslide, 1, 6–8, 12, 41
– R –
Rabrick, 38, 39
RD, 13–15, 18, 22, 24
RD2TeX, 22
RDtool, 19
Remote Procedure Call, =⇒ RPC
RPC, 36, 37
RTtool, 18, 19
Ruby, 16, 19, 35–37, 42–44, 46, 58–60, 63
Ruby-GetText-Package, 16, 17
Ruby/GTK2, 56
Ruby Document, =⇒ RD
mgp-mode, 6
mgpnet, 38
RWiki, 23, 24, 40
Migemo, 22
mimeTeX, 18
MO, 17
Shift JIS, 24
SMTP, 37
SOAP, 24, 35–37, 40, 56
msgmerge, 17
multilingualization, =⇒ m17n, 15
SSH, 36
Subversion, 11, 19, 24, 26
multi print, 57
SVG, 17
– O –
– T –
OpenGL, 33, 57
TCP, 36
TCP ソケット, 36
– P –
Pango, 16
PDF, 5, 7, 8, 22, 26, 33
PNG, 17, 22
–
S
–
Tgif, 17, 18
– U –
PNM, 17
PO, 17
Universal Network Objects, =⇒ UNO
UNO, 39
URI, 23, 39
po-mode, 17
UTF-8, 24
索引
69
– V –
サムネイル, 5, 8, 22
Vim, 1, 6, 11, 15, 21, 29
Visual Studio, 1
シミュレーション描画, 48
スライド
一覧, 4, 21
– W –
Wiki RPC, 24
WYSIWYG 型, 1–9, 11, 18, 20–22, 26, 27
WYSWYG 型, 30
– X –
xclock, 31
xeyes, 31
XML, 6, 7, 12, 17, 35–37
XML-RPC, 35–37, 56
XML Schema, 37
xsm, 37
X Window System, 27, 39
xwintoppm, 38
xyzzy, 15, 20
– あ –
アウトライン, 4, 7, 20
委譲, 59, 60
エンコーディング, 24, 25
オープンソースソフトウェア, 16
– か –
開発コスト, 11, 13, 15, 18, 19, 58
学習コスト, 13, 18, 19, 41, 42, 51
カスタマイズ, 1, 2, 20
可能, 15
機能, 2
性, 1, 42
言語外 DSL, 41, 42
言語内 DSL, 41, 42, 58
国際化, 16
– さ –
サブマークアップ, 13
移動, 4, 8, 21, 29
書き込み, 4, 8, 21, 30
検索, 21, 22
作成, 13–15, 17
ソース
再読み込み, 8, 20, 21
自動再読み込み, 20
– た –
多言語, 15, 16
テーマ, 26
テキスト型, 1–3, 6, 8, 9, 11, 15, 18–22, 25–27,
30, 32
デスクトップ環境, 16
デフォルトエンコーディング, 24
– は –
パーザ, 13, 19
パーズ, 24, 25, 55
人が可読なマークアップ言語, 12, 13, 15
ファイアウォール, 36
ブラックアウト, 4, 21
文法, 13–15
ポート転送, 36
ホワイトアウト, 4, 21
– ま –
マークアッ プ
言語, 15
マークアップ, 6, 9, 11–14, 25, 26
言語, 6, 7, 11–13, 15
量, 12
マーシャル, 35, 36
メタデータ, 26
70
– ら –
レンダリング処理, 6
– わ –
ワイルドカード, 45
索引
ダウンロード

rabbit-ppt