rabbit -...

修士論文

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

2.1 WYSIWYG型プレゼンテーションツール . . . . . . . . . . . . . . . . . . . . . . . 32.1.1 スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 プレゼンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.4 印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.5 画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 テキスト型プレゼンテーションツール . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 プレゼンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.4 印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 その他のプレゼンテーションツール . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1 Goby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 lessプレゼン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

第 3章採用するべき機能 11

3.1 スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.1 人が可読なマークアップ言語の採用 . . . . . . . . . . . . . . . . . . . . . . . 113.1.2 編集モードの提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.3 多言語サポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.4 インターフェイスの国際化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.5 多くの画像フォーマットのサポート . . . . . . . . . . . . . . . . . . . . . . . 173.1.6 数式のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.7 表のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.8 マルチプラットフォームサポート . . . . . . . . . . . . . . . . . . . . . . . . 19

v

3.2 スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1 自動再読み込み機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 校正支援モードの提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.3 スライド一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 プレゼンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.1 コメント印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

第 4章新しく開発する機能 23

4.1 スライド作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.1 ソース入力インターフェイスの抽象化 . . . . . . . . . . . . . . . . . . . . . 234.1.2 ソースエンコーディングの自動変換機能 . . . . . . . . . . . . . . . . . . . . 244.1.3 コードの自動色付け機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.4 見栄えの分離 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 スライド校正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 自動再読み込み機能の強化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.2 段階的ソース読み込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 プレゼンテーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.1 スライド移動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.2 キーボードカスタマイズ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.3 マウスインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.4 マウスジェスチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.5 覗き穴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3.6 レンダリングされたページのキャッシュ . . . . . . . . . . . . . . . . . . . . . 324.3.7 コメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 印刷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.1 描画機能を抽象化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

第 5章外部インターフェイス 35

5.1 dRubyインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 XML-RPCインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 SOAPインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 インターフェイスの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.5 使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.5.1 専用Webサーバの提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.5.2 サーバモードの提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.5.3 RWikiとの連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

vi

第 6章テーマ 41

6.1 テーマ記述言語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2 テーマ記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.1 宣言的記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2.2 要素選択記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2.3 フック記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3 値の正規化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4 テーマの使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.4.1 自動再読み込みの強化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4.2 タイマー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4.3 スライド数表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4.4 表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.4.5 画像 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.4.6 デバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.4.7 テーマの合成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.5 テーマの動的変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

第 7章実装 55

7.1 段階的ソース読込 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.2 外部インターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3 レンダリングモジュールの抽象化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.3.1 出力種類の関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.3.2 拡張可能性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.3.3 出力種類の抽象化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.4 テーマ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.1 テーマ評価環境の提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.2 レシーバの差し替え . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

第 8章結論 63

8.1 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638.2 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

索引 67

vii

図目次

4.1 マウスジェスチャのユーザインターフェイス . . . . . . . . . . . . . . . . . . . . . . 314.2 覗き穴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 コメント表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 mgpとmgpnetの連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Rabbitと Rabrickの連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Rabbitと RWikiの連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 ワイルドカードの表す範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2 基準座標と残りの幅と残りの高さの関係 . . . . . . . . . . . . . . . . . . . . . . . . 486.3 うさぎとかめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.1 段階的ソース読込 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.2 テーマ適用中もイベントを処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3 外部インターフェイスの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.4 レンダリングモジュールの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.5 暗黙の 2段階レシーバ差し替え . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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のKPresen-ter[35]，AppleのKeynote[2]，Microsoft Officeの PowerPoint[6]のようにアプリケーション上でスライドの作成から表示までを行うタイプのプレゼンテーションツールである．WYSIWYG型のプレゼンテーションツールではマウスを用いて GUIでスライドを作成するものが多い．テキスト型とはMagicPoint[24]，Pyslide[4]，prosper[9]，lessプレゼン [29]のようにスライド用

のソースファイルはアプリケーションとは別の任意のエディタで作成し，そのソースを用いてアプ

リケーションがスライドの表示を行うタイプのプレゼンテーションツールである．

プログラマは自分の手に馴染んだエディタを用いることを好む．そのため，スライド作成には

WYSIWYG型の編集インターフェイスをもったプレゼンテーションツールよりも自分の好きなエディタを用いるテキスト型を好む．また，既存の各種テキスト処理用ユーティリティやバージョン

2 第 1章序論

管理のしやすいテキストファイルを好む．例えば，grepによる文字列検索や diffによるバージョ

ン間の差分表示である．よって，Rabbit はテキスト型を採用する．プログラマはアプリケーションがキーボードによるインターフェイスを提供することを好む．ま

た，アプリケーションが提供するキーバインドを変更できることを好む．よって，Rabbitでは豊富なキーバインド及びキーバインドのカスタマイズ機能を提供する．

プログラマはキーバインドだけではなくアプリケーション自体をカスタマイズできることを好む．

よって，Rabbitを「本物の」プログラミング言語を用いてカスタマイズできるようにする．プログラマはさまざまな技術を応用してシステムを構築することに興味を持つ．よって，Rabbit

は外部のアプリケーションやライブラリと協調し，システムを構築しやすくするためのインターフェ

イスを提供する．

まとめると，本稿では以下の条件を満たすプレゼンテーションツール Rabbitを提案する．

• テキスト型である．

• 豊富なキーバインドを提供する．

• キーバインドは変更可能である．

• プレゼンテーションツールをカスタマイズするために「本物の」プログラミング言語を提供する．

• 外部アプリケーション／ライブラリへのインターフェイスを提供する．

以降の章では，まず，WYSIWYG型とテキスト型それぞれについて考察する．それらに当てはまらない既存のプレゼンテーションツールについてはその後に考察する．続いて，既存のプレゼン

テーションツールの考察結果から，Rabbitが提供するべき機能を考察する．その後，既存のプレゼンテーションツールには存在しない，Rabbitが提供するべき機能，およびその実装について述べる．最後に Rabbitと既存のプレゼンテーションツールとの違いを考察し，今後の展望を述べる．

3

第2章既存のプレゼンテーションツール

本章では既存のプレゼンテーションツールを以下のように分類し，考察する．

• WYSIWYG型

• テキスト型

最後に，どちらにも分類することが難しい既存のプレゼンテーションツールを考察する．

2.1 WYSIWYG型プレゼンテーションツール

現在もっとも一般的なプレゼンテーションツールのタイプはWYSIWYG型である．WYSIWYG型はスライドの作成から表示まですべてアプリケーション自身で行う．

本章では以下の視点からWYSIWYG型を考察する．

• スライドの作成方法

• スライドの校正方法

• プレゼンテーションの方法

• スライドの印刷

2.1.1 スライド作成

WYSIWYG型ではプレゼンテーションツールにスライドを作成するためのインターフェイスがある．

まず，マウスでスライドのテンプレートを選択する．

次に，スライドを作成する．テンプレート中にはテキストを入力するための領域があり，そこを

クリックしテキストを入力する．図はマウスで使用する図を選択し，配置する．ドラッグで図のサ

イズを調整できる．表も同様に挿入できる．また，スライドには表示しない発表者用の注釈も関連

付けることができる．注釈スペースは単なるテキストエリアなので，マウスで選択し注釈を入力で

きる．これらを繰り返しスライドを作成する．

必要な枚数だけ上記のようにスライドを作成する．

4 第 2章既存のプレゼンテーションツール

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.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に表示機能

を任せている．一般に，これらの表示アプリケーションはプレゼンテーション用に最適化されてい

ないためプレゼンテーションに便利な機能を提供していない場合が多い．


一方，独自にプレゼンテーション機能を提供している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 人が可読なマークアップ言語の採用

テキスト型では，ソースにマークアップを行って，スライドの区切りや箇条書きなどを表現する．

マークアップ言語の設計はプレゼンテーションツールによって大きく異なる．

ソースの見た目からスライド表示が容易に想像できるマークアップ言語を採用した場合は以下の

ような利点がある．

• 実際にスライド表示をプレビューしなくてもスライド作成および校正が行える．

• ソースの編集が容易になる．

12 第 3章採用するべき機能

一方，以下のような欠点がある．

• ソースに詳細な指示を記述することが難しい．

これは，ソースに詳細な指示を記述すると，その分，ソースにスライド表示には直接現れない要

素が出てくるためである．これは見た目からスライド表示を想像しづらくする．

MagicPointや lessプレゼンではソースの見た目がスライド表示での見た目と類似している．例えば，MagicPointは箇条書きをタブインデントで表現している．このタイプのマークアップ言語はソースの見た目からスライド表示が容易に想像できるという点

で人が可読なマークアップ言語ということとする．

一方，Pyslideの XMLベースのマークアップや prosperの LaTeXベースのマークアップは，そのソースの見た目からスライド表示が容易に想像できない．これは，以下が原因である．

• ソースの構造がインデントとは独立している．

• ソース全体を見たとき，テキストとマークアップの比率でマークアップの割合が多い．

例えば，Pyslideが採用している XMLベースのマークアップ言語では，スライドタイトルと箇条書きが同じレベルの要素として現れることがある．これでは，ソースを読み，タグの意味を解釈

してからでないとスライド表示を想像することは困難である．

また，prosperが採用している LaTeXベースのマークアップ言語では，スライド定義の開始と終了，箇条書きの開始と終了，箇条書きの各要素など，人が可読なマークアップ言語よりもマーク

アップ量が多い．図??は箇条書きを入れ子にした例である．¶ ³\begin{itemize}

\item トップレベル 1

\begin{itemize}\item サブアイテム 1

\end{itemize}\item トップレベル 2


\item サブアイテム 2

\end{itemize}\item トップレベル 3


\end{itemize}\end{itemize}µ ´

3.1. スライド作成 13

これが，図??のようなスライド表示になることを容易に想像することは困難である．これは，各

箇条書きの間に，マークアップ行が含まれていて，テキストの構造を判断しづらくさせているから

である．¶ ³• トップレベル 1

– サブアイテム 1

• トップレベル 2



• トップレベル 3

– サブアイテム 1µ ´Rabbitでは，インデントと簡単な記号でマークアップをするRD[18](Ruby Document)をベース

とし，人が可読なマークアップ言語を設計する．

このように完全な独自マークアップ言語を採用せずに，RDのようなの既存のマークアップ言語をベースとすることは，開発者にもユーザにも利点がある．

まず，ユーザの利点について述べる．既存のマークアップ言語を知っているユーザは学習コスト

が小さくなる．もし，既存のマークアップ言語を知らない場合でも，学習のために既存のマーク

アップ言語のためのドキュメントが利用することができ，学習が容易になる．

開発者側の利点は既存のマークアップ言語の資産を利用できるということである．マークアップに

関するドキュメントを作成する際，既存のマークアップ言語のためのドキュメントを参考にしたり，

参照するようにしながらドキュメントを作成できるため開発コストを小さくすることができる．ま

た，マークアップ言語を一から設計しなくても良いというのも開発コストが小さくなる．もし，既

存のマークアップ言語用のパーザがある場合は，さらに開発コストを小さくすることができる．

既存のマークアップ言語をベースとした場合の欠点は，既存のマークアップ言語の制限を継承し

てしまうことである．また，既存のマークアップ言語がスライド作成用に設計されていることは少

ないため，スライド作成用にパーザや文法に独自拡張を入れなければいけない．既存のマークアッ

プ言語のパーザや文法が拡張に向いていない場合は，開発コストが高くなってしまうことも考えら

れる．

Rabbitでは，RDの文法を拡張せずに，マークアップの中にサブマークアップを挿入する，あるいは既存のマークアップにスライド作成用の意味を持たせることによりRDを拡張している．これにより，既存の RDパーザを流用できるため開発コストが小さくなっている．また，文法はRDそのものであるため，ユーザの学習コストも小さい．

Rabbitが採用した RDベースのマークアップ言語がどのようになっているかを述べる．RDで


は，見出しを図??のようなマークアップで表現する．¶ ³= 見出し（レベル 1）

== 見出し（レベル 2）

=== 見出し（レベル 3）

==== 見出し（レベル 4）

+ 見出し（レベル 5）

++ 見出し（レベル 6）µ ´=がもっとも大きい見出しレベルで，++がもっともい小さい見出しレベルである．

Rabbitでは，=レベルの見出しをスライドタイトルとして扱い，=レベルの見出しから次の=レベ

ルの見出しまでを 1枚のスライドとする．図??は 2枚のスライドを記述した例である．¶ ³= スライド 1

1枚目のスライドの内容

= スライド 2

2枚目のスライドの内容µ ´=レベルの見出しがスライドタイトルとして扱われる一方，=レベルより小さい見出しは全て無視

され，Rabbitでは意味を持たない．このように，既存の RDとは少し違うスライド作成に特化した意味を持たせることにより RDを拡張している．スライドの内容には RDの文法をそのまま使用する．例えば，1枚目のスライドに箇条書きを入

れたい場合は図??のようになる．¶ ³= スライド 1

* トップレベル 1

* サブアイテム 1

* トップレベル 2



= スライド 2

2枚目のスライドの内容µ ´


このように，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 と呼ばれることが多い．


¶ ³= 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」）なら，日本語に翻訳されたテキスト「ファイル」のこと．


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などの画像フォーマットに変換し直すのを忘れて，スライドに反映されないといった事態が起こらなくなる．

6Portable Object の略で，人が読み書きするためのフォーマットである．翻訳する対象となるテキストがどこに書かれていたか，未翻訳のテキストであるなどといった情報も含まれている．テキストを翻訳するときは POファイルを編集する．

7Machine Object の略で，プログラムが読み込むフォーマットである．バイナリファイルなので人が読み書きすることには向かない．


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，MacOS X，Windowsと複数のプラットフォームをサポートできる．

3.2 スライド校正

本節ではスライド校正時に使うための機能を考察する．Rabbitでは，テキスト型と同じプログラマ好みのエディタを用いたスライド作成方法を採用したため，スライド校正方法もテキスト型ベー

スの方法を採用する．

スライド校正はスライド表示を確認しながら行う．テキスト型では，ソースとスライド表示が異

なるため，どれだけスムーズにソースの変更をスライド表示に反映させるかが問題となる．


3.2.1 自動再読み込み機能

WYSIWYG型では，ソースにテキストや図などのスライド中の各要素がどの位置に配置されるかが記述されている．一方，テキスト型ではそのような指定はせずにツールがソースを読み込んで

自動的に計算し，配置する．このため，WYSIWYG型よりもテキスト型の方がスライドのレンダリング速度が遅くなる8．

スライド表示に時間がかかると，ソースの変更をスライド表示に反映するまでの時間が長くなり，

スライド校正の効率を落とす．

そこで，MagicPointでは再起動せずにソースを読み直すソース再読み込み機能を提供している．これにより，プレゼンテーションツールの起動および終了の時間を排除し，スライド表示に反映す

るまでの時間を短縮している．また，MagicPointには，ソースを再読み込みすることを指示しなくても自動的にソースが変更されたかどうかを判断し再読み込みをするソース自動再読み込み機能

もある．これも，ソースの変更をスライド表示に反映するまでの時間を短縮することに役立つ．

Rabbitでも，スライド校正効率をあげるために，このソース自動再読み込み機能を提供する．

3.2.2 校正支援モードの提供

テキスト型では，エディタの編集モードによって，編集支援機能だけではなく，校正支援機能も

提供する．校正支援機能としては以下のようなものがある．

非表示機能指定したレベル以下の構造を非表示にする機能である．エディタに備わっている機能

をモード用にカスタマイズして実現する場合が多い．

この機能を利用することによりWYSIWYG型のアウトライン画面と同じ使いかたができる．

構造単位での編集機能ページ単位や箇条書き単位などで削除やコピーなどをする機能である．指

定した範囲の箇条書きのレベルを上げたり下げたりする機能もこの機能である．この機能も

エディタに備わっている機能を利用して実現する場合が多い．

この機能はスライドの順序を変更したり，アウトラインを変更したりするために利用できる．

外部コマンド起動機能テキスト型ではスライド編集環境であるエディタとは別にスライド表示用

のコマンドがある．エディタから外部コマンドを起動する機能があると，ターミナルから外

部コマンドを呼び出さなくてもよくなるため，スライド校正効率を上げることができる．

この機能もエディタの機能を利用して実現されることが多い．

Rabbitでも，以上の機能を提供する．ただし，エディタごとにモードが存在するため，提供する機能はさまざまである．現在，xyzzyには Rabbit用の編集モードが存在する．このモードでは上

8WYSIWYG型がテキスト型よりも起動が遅いことが多いのはスライドのレンダリング以外にユーザインターフェイスの初期化などを行う必要があるためである．

3.3. プレゼンテーション 21

述の全ての機能を提供している．しかしながら，Emacs や Vimで用いる既存の RD用編集モードでは外部コマンド起動機能が提供されていないため，この機能は提供していない9．

3.2.3 スライド一覧

テキスト型では提供されることが少ないスライド一覧画面であるが，WYSIWYG型では提供されていることが多い．

この機能は，発表後に表示して，観客からの質問時などに観客とのコミュニケーションを円滑に

進めるためにも使用できる．このため，Rabbitはテキスト型であるがスライド一覧機能を提供する．ただし，スライド一覧機能からスライドの順序を入れ替える機能は提供しない．これは，スライ

ド一覧でプレゼンテーションの流れを確認することが有益ではないからである．スライド一覧でプ

レゼンテーションの流れを確認するよりも，スライドを一枚ずつ表示して確認した方が，実際のプ

レゼンテーションの流れをシミュレートできるため，より高いフィードバックが得られるからであ

る．スライド一覧でスライド順序を変更する場合は，スライドを一枚ずつ表示したときのプレゼン

テーションの流れを壊してしまうことがある．

Rabbitでは，良いプレゼンテーションを行うためのスライド作成を邪魔する機能は導入しない．よって，スライド一覧機能からスライドの順序を入れ替える機能は提供しない．

3.3 プレゼンテーション

既存のプレゼンテーションツールはプレゼンテーション時の機能および機能を呼び出すインター

フェイスが貧弱である．Rabbitでは以下の既存のプレゼンテーションツールにある機能はすべて提供する．




• ホワイトアウト

• ブラックアウト

• 強制再描画

• ソース再読み込み

• スライド検索

9エディタが提供する外部コマンド起動機能を直接使えばエディタからプレゼンテーションツールを起動することはできる．しかしながら，それは使いやすいものではない．


また，キーボードによるインターフェイスだけではなく，マウスによるインターフェイスも提供

する．つまり，マウスクリックによるインターフェイスだけではなく，ポップアップメニューによ

る機能起動のインターフェイスも提供する．

スライド検索では，単なる文字列検索ではなく，より強力な正規表現によるインクリメンタル検

索を行う．また，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項で述べる．

24 第 4章新しく開発する機能

ソースが 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上のリソースを入力ソースとして扱う場合，もし，リソースのエンコーディングが期


待するエンコーディングと異なっていた場合は，一度リソースをダウンロードしてエンコーディン

グを確認してプレゼンテーションツールに指定しなければいけない．これは非常に不便である．

また，プログラマはプログラムでできることは自分で行わずに，プログラムに行わせることを好

む．エンコーディングの自動検出もそのひとつである．

以上の理由より，Rabbitでは入力ソースのエンコーディングを自動検出し，自動で内部エンコーディングに変換する機能を提供する．また，明示的に入力ソースのエンコーディングを指定する機

能も提供するため，エンコーディングの自動検出が失敗する場合でもエンコーディングを明示的に

指定することにより，入力ソースのエンコーディングを変更せずにプレゼンテーションを行うこと

ができる．

4.1.3 コードの自動色付け機能

ここでいうコードとは，プログラミング言語のソースコードのことである．プログラマはコード

をスライドに張り付ける機会が多い．

プログラミング言語には構文があり，その構文要素を強調表示することにより見やすくなる．

Rabbitは，Enscript[25]と連携してスライド中に張り付けたソースコードをパーズし，自動で色付けをする機能を提供する．

Enscriptは PostScriptなど画像ファイルとしてもパーズ結果を出力ができるため，MagicPointや prosperなどでも色付けされたソースコードを使うことができる．しかしながら，それらのプレゼンテーションツール内では画像として扱われるため，色づけされたソースコードを細かく制御す

ることができない．一方，Rabbitは Enscriptがパーズして色付けしたソースコードを Rabbit内部のオブジェクトに変換するため，第 6章で述べるテーマを用いて結果を細かく制御することができる．

4.1.4 見栄えの分離

テキスト型のプレゼンテーションツールは，ソース中に見栄えを定義することも，ソースと見栄

えを別ファイルに分けることもできる．例えば，MagicPointではスライド区切りを表すために図??のようなマークアップを行う．¶ ³%page

1ページ目の内容

...

%page

2ページ目の内容

...µ ´


このようなスライドの構造を表現するマークアップ以外に，図??のようなスライドの見栄えを設

定するマークアップを行う．¶ ³%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 章で詳しく取りあげる．4less プレゼンなど一部 GUI アプリケーションではないものもあるが，多くのプレゼンテーションツールは GUI アプ

リケーションである．


め，スライド描画処理に時間がかかると，キーイベントなどを受け付けない時間ができる．GUIアプリケーションでは，イベントを受け付けない時間はユーザに大きなストレスを与える．

既存のプレゼンテーションツールは，起動時やソース再読み込み時において，完全にツール側の

処理が完了するまでユーザからのイベントを処理しない．例えば，MagicPointではソースの再読み込み時は再表示までの間にイベント処理が行われない時間が生じる．この時間のストレスを軽減

させるためには以下のような方法がある．

進行状況を見せる処理が行われていることを示すプログレスバーやスプレッド画面などを表示す

る方法である．これにより，ユーザはあとどのくらいで処理が終了するのかを判断できるた

め，無反応状態からくるストレスを軽減させることができる．

この方法は，会話に例えて説明することができる．相手に質問をした場合を考える．相手は

質問にはすぐに答えられず考え込んでしまったとする．このとき，何も言わずに黙り込んで

考え込まれると，「聞こえなかったのだろうか」，「無視されたのだろうか」，「いつまで待てば答

えが返ってくるのだろうか」，などと不安を感じる．一方，「少し考えさせて」，「えーっと」，

などと考えているということを伝えてもらえると，「質問はきちんと伝わったんだな」，「考え

中だからもう少し待ってみよう」などと安心することができる．

段階的に処理する処理が行われている間でもユーザからのイベントを処理する方法である．ツー

ル側の処理が行われている間は，その時点で処理した分だけでイベントに対応する．例えば，

描画処理中にユーザからのスライド移動要求がきた場合は，描画処理が途中であっても，ス

ライドを移動し，処理途中のものを描画する．

処理途中のものでも表示するというこの方法でも，プログレスバーなどを用いて進行状況を

見せる場合と同じようにユーザに処理中であることを示すことができる．これにより，ユー

ザのストレスを軽減させることができる．また，この方法では進行状況を明示するだけでは

なく，ユーザからのイベントも処理するため，単に進行状況を見せる場合よりもユーザのス

トレスを減少させることができる．

既存のプレゼンテーションツールでは「進行状況を見せる」方法を用いているものがいくつかあ

るが，「段階的に処理する」方法を用いているものはない．これは，処理途中に割込みが入ったとき

に整合性を保ちつつ，割り込みを処理することが難しいからである．しかしながら，「段階的に処理

する」方法の方が無反応状態を無くし，さらに進行状況を示すことができるため，「進行状況を見せ

る」方法よりユーザのストレスを減らすことができる．よって，Rabbitでは段階的に処理する方法を採用し，待ち時間によるユーザのストレスを減少させる．

4.3 プレゼンテーション

既存のツールは貧弱過ぎる．Rabbitではプレゼンテーション時の機能として，既存のプレゼンテーションツールにある機能はもちろん，既存のプレゼンテーションツールにはない機能を提供す


る．本節では以下に挙げる既存のプレゼンテーションツールにはない特長となる機能について述

べる．

• 豊富なコマンド起動インターフェイスの提供

• プレゼンテーション支援機能

• コメント機能

また，プレゼンテーション中のユーザのストレスを減少させる機能についても述べる．

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.3.2 キーボードカスタマイズ

既存のテキスト型のプレゼンテーションツールは，全てのコマンドをキーボードから起動する．

プログラマにとってキーボードインターフェイスが用意されていることは魅力的である．しかしな

がら，既存のテキスト型のプレゼンテーションツールでは，キーバインディングは固定されていて，

ユーザが変更することはできない．

プログラマはツールを自分好みにカスタマイズしようとする．Rabbitでは，全てのキーバインドが変更可能である．これにより，プログラマは Rabbitを自分好みの手に馴染んだツールとして使うことができるようになる．

4.3.3 マウスインターフェイス

既存のテキスト型のプレゼンテーションツールはポップアップメニューのサポートがない．プロ

グラマにとってキーボードが主体のインターフェイスは魅力的であるが，マウスを用いたグラフィ

カルなインターフェイスの方が便利なこともある．

例えば，スライド書き込みの際のペンの色や太さを変えることを考える．キーボードから色を

RGBA値で指定することもできる．しかしながら，カラーパレットからマウスを用いて色を選択する方がより直感的で容易に色を選択できる．

Rabbitでは，既存のプレゼンテーションツールよりもキーボードインターフェイスを強化するだけではなく，マウスインターフェイスも強化する．まず，WYSWYG型にあるようなポップアップメニューをサポートし，多くの機能をポップアップメニューから起動できるようにする．また，マ

ウスインターフェイスがキーボードインターフェイスよりも有効である，スライド書き込みのため

のカラーパレットも提供する．

4.3.4 マウスジェスチャ

マウスジェスチャとはマウスの動きによって機能を実行するインターフェイスであり，主にWebブラウザでサポートされている．

一般に，マウスによるインターフェイスは直感的であるが，作業が多くなると面倒になることが

多い6．マウスによるインターフェイスで機能の実行は，選択し，クリックという手順となる．例え

ば，ポップアップメニューでは，項目を選択して，クリックで機能を実行する．このような手順で

は，利用可能な機能など選択対象が多くなる程，選択が面倒になる．

マウスジェスチャでは，マウスの動きで選択とクリックをまとめて行うことができる．これによ

り，マウスによるインターフェイス特有の煩わしさを軽減することができる．

6キーボードによるインターフェイスはマウスによるインターフェイスほど直感的なことは少ないが，面倒な作業を短縮することができる．例えば，マウスを 10 回クリックして 10 枚スライドを進めるよりも，n を 10 回押して 10 枚スライドを進める方が楽である．


多くのブラウザがサポートしている一般的なインターフェイスであり，マウスを使用しているの

にストレスの小さいインターフェイスので，Rabbitではマウスジェスチャをサポートする．既存のプレゼンテーションツールでマウスジェスチャをサポートしているものはない．

Webブラウザなど既存のアプリケーションではマウスの軌道を表示するだけのものが多いが，これでは現在の軌道でどのような機能が利用可能なのかがわからない．軌道だけではなく，現在の軌

道に対応する機能を表示することによりわかりやすさを向上させているアプリケーションもある．

しかしながら，この方法では，次にどう動いたらどの機能が利用可能であるのかということがわ

からない．そこで，一部のアプリケーションでは軌道だけではなく，図 4.1のように，次にどう動いたらどの機能が利用可能であるかを示す画像も表示することでわかりやすさを向上させている．

Rabbitでもこのインターフェイスを採用する．

4.3.5 覗き穴

プログラマはプレゼンテーション中にターミナルを開いてデモを行うことがよくある．その際，

既存のプレゼンテーションツールでは，プレゼンテーションツールのフルスクリーンを解除して，

ターミナルを開き，デモが終わるとまたプレゼンテーションツールをフルスクリーンにする7．こ

れは，観客の視線や意識がプレゼンテーションからデスクトップなど関係のないものに向いてしま

うなどプレゼンテーションの流れを壊してしまう．

そこで，Rabbitでは，図 4.2のようにスライドの一部を透過にして，後ろのウィンドウが見える機能を提供する．この機能を用いることにより，スライドのフルスクリーンを解除せずにデモを行

うことができる．デモが終了したら透過部分を元に戻すだけでよい．

この機能は今までにない新しいインターフェイスを提供するため，この機能を用いたプレゼン

テーションをはじめて見た人にとって大きな衝撃を与える．これは，実際に筆者がこの機能を用い

たプレゼンテーションを行って確認した．

図 4.1: マウスジェスチャのユーザインターフェイス

7デモ用のアプリケーションがフルスクリーンをサポートしていればプレゼンテーションツールのフルスクリーンを解除せずに，単にプレゼンテーションツールの上にデモ用のアプリケーションを配置すればよい．MagicPoint は Xアプリケーションをスライド中に埋め込む機能を持つ．この機能はアプリケーションがフォーカスを要求しない xclock や xeyes のような X アプリケーションであれば問題はないが，ターミナルのようにフォーカスを要求する X アプリケーションではフォーカスとウィンドウマネージャの間で問題が発生する場合がある．


4.3.6 レンダリングされたページのキャッシュ

テキスト型のプレゼンテーションツールは，ソースに具体的な配置情報を埋め込まずに，描画時

に動的に計算するため描画処理が重くなる傾向がある．これは待ち時間を増加させるためユーザの

ストレスとなる．

ただし，MagicPointのように毎回最初から描画している場合でも，以下のようにすることによりユーザのストレスを減少させることができる．

• 段階的に描画し，描画途中でもイベント処理を行う．

• 次のページを先読みしキャッシュしておく．

Rabbitでは，描画されたスライドを画像としてキャッシュしておくことにより，一度描画されたスライドを高速に表示することができる．また，全スライドをキャッシュするコマンドを提供する

ことにより，各スライドの表示を高速化することができる．

4.3.7 コメント

プレゼンテーション中に観客からのコメントを受け付ける機能を提供する．コメントは第 5 章で述べる外部インターフェイスを用いて投稿する．投稿されたコメントはすぐにプレゼンテーション

画面に反映される．プレゼンテーション画面にコメントを表示する方法として，以下の 2種類を用意している．

• ポップアップ

• スライド表示を縮小し，左と下にスペースを空け，そこに表示する方法

これらは一度に両方使うこともできるし，片方だけ使うこともできる．図 4.3は両方表示した例である．

コメントを受け付ける機能を提供することで，観客がプレゼンテーションに割り込みやすくなる

ことが期待できる．しかしながら，観客が PCを起動しながらプレゼンテーションを観ていることは少なく，また，フォーマルなプレゼンテーションであればあるほどプレゼンテーションに割り込

むという習慣がないため，コメントをする観客はほとんどいないのが現状である．

図 4.2: 覗き穴

4.4. 印刷 33

4.4 印刷

印刷に関する機能面では既存のプレゼンテーションツールと大きく異なるところはない．しかし

ながら，次に述べる描画機能の抽象化はプログラマに好まれる実装である．

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 章で述べる．

36 第 5章外部インターフェイス

ソケットを用いて通信している 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では，XMLSchemaのデータ型，数十種類をサポートし，さらに，利用者が拡張できるようにもなっている．

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がどのように外部インターフェイスを利用しているかを述べる．2SOAPよりも XML-RPCの方が仕様が小さいため，言語に SOAP用ライブラリがない場合でも，XML-RPC用ライ

ブラリがあることがある．例えば，Gauche[16]がそうである．Gaucheには SOAP用ライブラリは存在しないが，xsm[33]という XML-RPC 用ライブラリが存在する．


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 (Dis-tributed Component Object Model)を用いることにより実現できる．ただし，UNOもDCOMも ImpressやPowerPoint専用の技術ではなく，OpenOffice.org やWindows 全般で利用されるための技術のため，Impress や PowerPoint に接続するために形式的なコードを書かなければいけない．一方，Rabbit の場合は，どのインターフェイスを利用する場合でも接続先の URI を指定するだけで簡単に接続することができる．


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 SpecificLanguage)の 2種類があり，それぞれ以下の通りである．

言語内DSL 既存のプログラミング言語上に問題領域用のための APIを用意し構築された言語のことである．

言語内DSLを構築する側は既存の言語の資産を利用したり，DSLを評価するために既存の言語の評価器を利用することができるため容易に DSLを構築することができる．

また，DSL内では既存の言語の機能がそのまま使えるため，DSL使用者に問題領域に特化した API以外の，既存の言語が提供する機能をそのまま提供することができる．これにより，容易に DSLの記述力を高めることができる．

言語内 DSLを記述する側は，ベースとなっている既存の言語を知っているかどうかで学習コストが大きく異なる．ベース言語を知っている場合は学習コストはほとんどなく，DSL用に用意された APIを理解すればよいだけである．一方，ベース言語を知らない場合は言語外DSLと同じように言語をはじめから学習しなければいけないため学習コストが大きくなる．

ただし，言語内DSLを利用するためにベース言語の機能を完全に理解しなければいけないとは少ない．多くの言語内DSLでは，簡単な設定は代入やいくつかのリテラル表記を覚えるだけで済む場合が多い．もちろん，DSLの機能を使いこなしたい場合はベース言語を学習しなければいけないため，言語外 DSL同様，学習コストが大きくなる．

また，DSL中でベース言語の機能も使えるため，DSLをより簡潔に記述することができる．しかし，ベース言語が型定義を要求するなど言語の制限が多い場合は，逆に記述が複雑にな

り DSLの見通しが悪くなる場合がある．

42 第 6章テーマ

言語外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 宣言的記述

要素にプロパティを設定したり他のテーマを取り込んだりするためには図??のように記述する．

1Rabbit 自体が 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を用いた宣言的記述もプログラマには容易に理解

できる．テーマでは，代入を用いた宣言的記述も行うことができる．図??は横方向の中央揃えを指

定する例である．

2Ruby では代入もメソッド呼び出しである．


¶ ³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が実行される．

例えば，図??はスライドタイトルを選択する例である．

3Ruby はメソッド呼び出しの括弧を省略できる．4Ruby ではブロックと呼ばれる．コールバック関数をメソッドに関連付けるための便利な表現である．

6.2. テーマ記述 45

¶ ³match(Slide, HeadLine) do

...

endµ ´スライドタイトルを表す HeadLine要素がスライドを表す Slide要素の下にあるためこのように

パスを指定する．

このように matchメソッドを用いることにより，どの要素でも選択できる．しかしながら，全て

の強調要素を赤く表示したい，といった場合，このようなフルパスを指定する方法では破綻してし

まう．そこで，パスにはワイルドカードを指定できるようになっている．ワイルドカードには 2種類ある．

• 全ての子要素を表す

• 自分自身と全ての子孫要素を表す

全ての子要素を表すワイルドカードは*で表す．自分自身と全ての子孫要素を表すワイルドカー

ドは**で表す．それぞれのワイルドカードが表す範囲を示したものが図 6.1である．ワイルドカードを用いることにより，図??のように簡単に全ての強調要素を赤く表示させるとい

う定義を書くことができる．¶ ³match("**", Emphasis) do

font :color => "red"

endµ ´要素選択記述も宣言的記述のように，より設定ファイルらしくしたい．なぜなら，要素選択記述

も宣言的記述のように，「なに」を記述するのであって，「どのように」を記述するのではないからで

ある．つまり，要素選択記述はどのように要素を選択したいかではなくて，どの要素を選択したい

かを記述している．

図 6.1: ワイルドカードの表す範囲


宣言的記述の場合のように，より設定ファイルらしく書き換えてみる．例として，図??の全ての

強調要素を赤く表示させる定義を使う．¶ ³match("**", Emphasis) do


endµ ´宣言的記述の場合のように，これからメソッド呼び出しの括弧を省略する．¶ ³match "**", Emphasis do


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. テーマ記述 47

6.2.3 フック記述

描画時の前後に呼び出される手続きを登録することにより，要素の描画をカスタマイズすること

ができる．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に示す．図中では，「タイトル」


が描画する要素である．

フックには基準座標以外に，描画対象である 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は現在時刻を表示するテーマ，プレゼンテーションの残り時間を表示するテーマを提供している．


プレゼンテーションの残り時間を表示する機能は，既存のプレゼンテーションツールではリハー

サルモードなどとして用意されている機能である．これは，プレゼンテーションのペース配分を計る

ために便利な機能である．しかしながら，筆者の経験ではプレゼンテーション中に残り時間とスラ

イドの残り枚数から，進みすぎている，遅れている，などを判断するのは難しい．そこで，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.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: 段階的ソース読込

56 第 7章実装

なお，「溜っているイベントの処理」は 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ページに複数枚のスライドをサムネイルとして印刷するレンダリングモジュールである．multiprintモジュール自体は印刷処理は行わず，サムネイル用に座標変換を行ったり，サムネイルのレイアウトを処理するだけである．実際の印刷処理はバックエンドとして cairoまたは gnomeprintを用いて行っている．

7.3.2 拡張可能性

レンダリングモジュールを抽象化することによってレンダリングモジュールを取り換えることが

可能になる．Rabbitでは，さらにユーザが新たにレンダリングモジュールを作成し，Rabbitに組み込むことを可能にする．

図 7.3: 外部インターフェイスの構成

58 第 7章実装

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


endµ ´fontメソッドはテーマ評価用オブジェクトへのメソッド呼び出しである．しかしながら，事前

にテーマ評価用オブジェクトにフォント設定用メソッドを用意しておくことはできない．なぜなら，

テーマ評価用オブジェクトはどの要素に対してフォントを設定すればよいかわからないからである．

そこで，method missingを用いる．テーマ評価用オブジェクトに定義されていないメソッドは全

てこのメソッドで捕捉することができる．この場合，定義されていない fontメソッド呼び出しが

method missing呼び出しにつながる．

60 第 7章実装

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


endµ ´このように，method missingを用いて動的にレシーバを変更することにより，テーマの記述量

を減らし，より直感的に記述できるようにしている．

62 第 7章実装

図 7.4: レンダリングモジュールの構成

図 7.5: 暗黙の 2段階レシーバ差し替え

63

第8章結論

8.1 まとめ

既存のプレゼンテーションツールの中にはプログラマのために作成されたものが無く，プログラ

マが満足するプログラミングツールが存在しない．本稿では，プログラマを満足させるプログラマ

のプレゼンテーションツールについて考察し，実装した．表 8.1は既存のツールと本稿で提案するプログラマのプレゼンテーションツール Rabbitとをプログラマの視点から見て比較したものである．xがサポート無しまたはサポートが弱い，o がサポート有り，ooが非常によくサポートしていること表している．

このように，Rabbitはプログラマが好む以下の性質をすべて満足する．

キーボードによるインターフェイススライド作成／校正時にはエディタの強力なキーボードイン

ターフェイスを利用でき，プレゼンテーション時にはRabbitが提供する豊富なキーバインドを利用することができる．

高いカスタマイズ性スライド作成／校正時にはエディタのカスタマイズ機能が使え，プレゼンテー

ション時はテーマにより，キーバインドの変更，「本物の」プログラミング言語による描画方

法のカスタマイズが行える．

既存のツールとの連携スライド作成／校正時には，手に馴染んだエディタや，バージョン管理ソ

フトウェア，各種テキスト処理ユーティリティを利用できる．プレゼンテーション時にはソー

スを自動色付けするために Enscriptと連携したりすることができる．また，ウィンドウの一部を透過させることにより，プレゼンテーション中でもRabbitのウィンドウの後ろにある他のウィンドウを利用することができる．

モジュール化された拡張可能なシステム描画用，印刷用のレンダリングモジュールを専用ディレ

クトリに置くだけで，Rabbit本体を変更することなく組み込むことができる．

現在，Rabbitは筆者だけではなく，主にRubyプログラマの間で使われている．これは本稿で考察したプログラマのプレゼンテーションツールが実際のプログラマに受け入れられる要素を含んで

いるということを示している．また，海外で使用しているユーザがいるという事実は，国内のプロ

グラマだけではなく，海外のプログラマにも国内のプログラマと同様の性質があるかもしれないと

いうことを示している．

64 第 8章結論

表 8.1: プレゼンテーションツールの比較

項目 PowerPoint Impress MagicPoint 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

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. Ruby Document. http://pub.cozmixng.org/˜the-rwiki/?cmd=view;name=RD.

[19] Peter Mattis, Spencer Kimball, and Josh MacDonald. GTK+. http://www.gtk.org/.

[20] Bram Moolenaar. Vim. http://www.vim.org/.

66 第 8章結論

[21] Masao Mutoh. Ruby-GetText-Package. http://gettext.rubyforge.org/.

[22] National Institute of Advanced Industrial Science and Technology. m17n library.http://www.m17n.org/m17n-lib/.

[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 –

a2ps, 8API, 24, 41, 56

– B –

BMP, 17, 22

– C –

cairo, 16, 57, 58Cascading Style Sheets, =⇒ CSSCriawips, 1CSS, 42, 43, 46CVS, 11, 24

– D –

DCOM, 39diff, 2, 19, 26Distributed Component Object Model, =⇒

DCOMDomain Specific Language, =⇒ DSL, =⇒

DSLDrawingArea, 57dRuby, 35–39, 56DSL, 6, 41, 42, 58DVI, 8

– E –

Emacs, 1, 6–9, 11, 15, 17, 19, 21, 29, 64Enscript, 25, 63EPS, 17EUC-JP, 24External Domain Specific Language, =⇒ 言

語外 DSL

– F –

fork, 38Front, 56FTP, 23

– G –

Gauche, 37GDK, 57, 58gettext, 16, 17GIF, 22GIMP, 64GNOME, 1, 16gnomeprint, 57GNU, 19Goby, 8, 9grep, 2, 11GTK+, 16, 19, 55GUIツールキット, 16, 55

– H –

HTML, 9, 22, 38HTTP, 23, 35–39

– I –

i18n, 16IDE, 1, 11Impress, 1, 16, 19, 24, 39Internal Domain Specific Language, =⇒ 言

語内 DSLinternationalization, =⇒ i18n, 16ISO-2022-JP, 24

– J –

68 索引

JPEG, 17, 22

– K –

Keynote, 1KPresenter, 1

– L –

LaTeX, 6, 12, 17, 18, 22less, 7lessプレゼン, 1, 7–9, 12, 19, 27libgnomeprint, 16

– M –

m17n, 15m17nlibrary, 15Machine Object, =⇒ MOMagicPoint, 1, 6–8, 12, 15, 18, 20, 25, 27, 28,

31, 32, 38, 41, 43, 51MathML, 18mgp, 6, 38mgp-mode, 6mgpnet, 38Migemo, 22mimeTeX, 18MO, 17msgmerge, 17multilingualization, =⇒ m17n, 15multi print, 57

– O –

OpenGL, 33, 57

– P –

Pango, 16PDF, 5, 7, 8, 22, 26, 33PNG, 17, 22PNM, 17PO, 17po-mode, 17

Portable Object, =⇒ POPostScript, 8, 9, 22, 25, 26, 33PowerPoint, 1, 39prosper, 1, 6–8, 12, 18, 19, 24, 25pTeX, 24Pyslide, 1, 6–8, 12, 41

– R –

Rabrick, 38, 39RD, 13–15, 18, 22, 24RD2TeX, 22RDtool, 19Remote Procedure Call, =⇒ RPCRPC, 36, 37RTtool, 18, 19Ruby, 16, 19, 35–37, 42–44, 46, 58–60, 63Ruby-GetText-Package, 16, 17Ruby/GTK2, 56Ruby Document, =⇒ RDRWiki, 23, 24, 40

– S –

Shift JIS, 24SMTP, 37SOAP, 24, 35–37, 40, 56SSH, 36Subversion, 11, 19, 24, 26SVG, 17

– T –

TCP, 36TCPソケット, 36Tgif, 17, 18

– U –

Universal Network Objects, =⇒ UNOUNO, 39URI, 23, 39UTF-8, 24

索引 69

– V –

Vim, 1, 6, 11, 15, 21, 29Visual Studio, 1

– W –

Wiki RPC, 24WYSIWYG型, 1–9, 11, 18, 20–22, 26, 27WYSWYG型, 30

– X –

xclock, 31xeyes, 31XML, 6, 7, 12, 17, 35–37XML-RPC, 35–37, 56XML Schema, 37xsm, 37X Window System, 27, 39xwintoppm, 38xyzzy, 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

サムネイル, 5, 8, 22シミュレーション描画, 48スライド

一覧, 4, 21移動, 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 -...

Documents