[DE | EN | FR | IT | JA | ES | KO | PT]

GeorgのBrave GNU Worldの新しい号へようこそ。 文書処理は、 まず間違いなくほとんどの利用者のニーズに入っていますので、 次の記事を最初にしてみました。 たぶん、 特に「初心者」の方なら、 新しい視点が得られることでしょう。

preview-latex - はじめに

TeX、 そしてまたLaTeX [5] の歴史は、 疑いなく計算機科学の最高峰のひとりである、 Donald E. Knuthにまでさかのぼります。 LaTeXはその能力や、 属性により、 科学や計算機の分野で人気のある解になりました。

LaTeXの主な長所は、 作者が各語の表示の詳細を気にすることなく、 内容に集中できることにあります。 また植字の世界では、 いかに複雑な数式でもこなせるLaTeXは、 いまだに無敵です。

これはLaTeXが、 テキストを書く、 一種の「文書用プログラミング言語」といえるからです。

特にコンピュータに非常に深くはまったほどではない人たちにとって、 これは、 相当の障碍 (しょうがい) であり、 これはまた、 いわゆる WYSIWYG ("What You See Is What You Get" 「見える物は手に入る物」) 式のプログラムが、 そういう人びとの圧倒的な選択になる理由でもあります。 このパラダイムは、 グラフィックにどっぷり依存した文書に優位性を提供し、 今日ひろく使われているオフィス・パッケージがそれに追従しています。

両方のパラダイムを合わせて、 両方の世界から利点を得るため、 LaTeXを基盤にしつつ、 WYSIWYG入力のできるプログラムが、 若干あります。 例としては、 LyX [6] や、 Brave GNU Worldの第30号 [7] で紹介したTeXmacs [8] があります。

オフィス・パッケージのように、 これらにおいては、 LaTeX文書と利用者の間に、 別な層を入れる必要があり、 このせいで、 LaTeXの全機能へのアクセスが大変、 あるいは不可能になります。 また、 これは往々にして中間形式も必要になり、 そのため長期的な保守が困難になります。

そしてこれは、 WYSIWYGのパラダイムと矛盾するLaTeXの長所を隠しがちです。 プログラミング言語としての設計のため、 文書の保守や、 さらなる開発には信じられないほど便利だが出力には出てこないような命令、 コメント、 メモを LaTeX文書に入れることができるようにしてあります。

preview-latex - プロジェクト

LaTeXの長所を損なうことなく、 初心者や、 本職の利用者にとってLaTeX生活を快適にするため、 David Kastrupは、 preview-latex [9] プロジェクトを始めました。

preview-latexは、 GNU EmacsとXemacsエディター用のパッケージで、 AUC-TeXモードの中で、 埋込みWYSIWYGフィードバックをあたえるものです。

文書作業で最大の部分は、 いまだ、 文書を書くこと自体にありますが、 それは、 強力で、 追加機能の多いツールである、 Emacsでできます。 と同時に、 グラフィックス、 音楽の総譜表、 チェスや碁盤、 非ラテン文字、 数式のようなもっと複雑な要素なども、 エディターの中で直に視覚化されます。

preview-latexは、 LaTeXコードを修正したり、 要求したりはしませんので、 LaTeXのすべての力を使うことができます。 (ドラフト注: 「すべての力」「あらゆる力」どっちがいいかな?) また、 同じ文書に別々の著者がいる場合、 ある場所でのpreview-latexの利用は、 もう一方に影響をあたえません。

プロジェクトは、 David Kastrupが博士論文への取組み中に始まり、 元来「痒い背中を掻く」だけだったのですが、 GNU General Public License (GPL) の下でのFree Softwareとしての公開後、 すぐプロジェクトにたいして並々ならぬ関心がもたれていることに気付きました。

短期のうちに6人の開発者が見つかり、 とりわけAlan Shutko、 Jan-Åke Larsson、 Nick Alcockらは、 特筆しておくべきでしょう。 Alan Shutkoは、 Autoconf対応をサポート、 保守しています。 Jan-Åke Larssonは文書上、 大きく貢献し、 RPMによるパッケージ化をしました。 今は、 表示の高速化のため、 レンダリング・デーモンに取り組んでいます。 Nick Alcockは、 XEmacsへの移植と、 たくさんのデバッグ作業による援助をしました。

驚くまでもなく、 preview-latexはほとんどTeXマクロで、 そして一部PostScriptと、 接合部分のコードの多くはEmacs-LISPで、 書いてあります。 スピードのため、 将来は一部、 Cも採用するでしょう。

David Kastrupの目から見て、 preview-latexの主な長所のひとつは、 これが控え目であることです。 要求があって初めて活性化され、 直感的なユーザー・インターフェースのせいで、 ほとんどの人は、 説明書を全然読まないようです。 また、 すでにたくさんの最適化が施され、 そこそこ大きな文書を二流のハードウェア上で処理しても、 まあまあの応答時間です。

それでも、 GNU EmacsやXemacsでグラフィックを扱うのは、 快適とは思えないため、 そういう部分がより大きいと、 まだ問題が若干あるようです。

したがって、 プロジェクトでは、 Emacsエディター側からの改善の手助けをしてくれるボランティアを、 まださがしています。 特にWindowsとMacintoshでは、 GNU Emacs用の作業が、 まだ若干あります。

技術的に熟達した人たちならば、 夢中になれる方法を、 きっとたくさん見つけられるでしょう。 一部の「ふつう」な利用者の方たちも、 好奇心をもち、 最初の面倒さにめげることなくpreview-latexをご覧いただけるよう、 まさに希望するところです。

もしあなたが、 テキスト処理領域についての、 よりまとまっていて冗長な概観に興味をお持ちであれば、 David Kastrupがpreview-latexの作業の間に書いた文献 [10] をご覧になることをお勧めします。

Lire

ウェブ・サーバー、 メール・サーバー、 ネーム・サーバー、 データベースなどなどのサービスをするシステム内のできごとや活動は、 すべてログファイルに書き込むのが、 Unixシステムでの伝統です。 この活動風習にしたがうことにより、 システム管理者は、 システムを注意深く監視できます。 (ドラフト注: ここでの``protocol''は、通信とは関係ないから、 いわゆる「プロトコル」ではないよね。どうかな。)

しかしログファイルは、 すぐにそこそこ大きくなりえるので、 その扱いは、 つらいものがあります。 とはいえ、 たいていはただのASCII形式ですから、 大きさが数メガバイトのファイルは、 人間が完全に把握することに無理があります。

それをふまえれば、 データは、 ある問題に取り組むときの情報となるだけです。 ところが、 データのほとんどの部分はその問題と無関係なので、 実際、 そういう情報も無関係なデータに埋もれてしまい、 ほぼアクセス不能におちいります。

この問題は、 何年もいろいろなところで起こっていたので、 ログファイルを解析する人たちを助けるためのプログラム開発の引き金となってきました。

そこで2000年4月6日、 オランダの会社の計算機科学者らが数名、 ログファイル解析というこの退屈な課題を論議すべく集まりました。 それぞれの会社が、 単に他の会社では終わったような労力をダブらせて、 独自に解を作っていたことが、 明らかになりました。

この操作作業にけりをつけるため、 LogReportチームが、 GNU General Public License (GPL) の下でのFree Softwareとして、 本職の環境でもこの課題を頼もしくやりとげることになるプログラムの製作を始めました。 その約2年後、 Lire 1.0 [11] が公開されました。

信頼のあきあきする課題から人間を解法してくれる、 ダグラス・アダムズの"Electric Monks"のように、 Lireの目的は、 ログファイルを読むという退屈な課題から人びとを解法することにあります。 したがって、 その名前は、 フランス語で「読む」ことを意味する"lire"からきています。

プログラムは、 PerlとBashで書いてあり、 XMLを大胆に使い、 4段階に分けて機能します。 第1に、 以降の段階の準備として、 "Destilled Log Format" (DLF) への正規化をおこないます。 第2に、 各サービスで共通の汎用ツールでこれを解析します。 その汎用ツールは、 サービスを越えて使われます。 これらツールの出力形式は、 XMLです (訳注: これが第3段階)。 第4段階で、 最終的なログファイル形式に変換されます。

Lireには現在、 29種類の別々なサービスについての入力フィルターがあり、 増えつつあります。 単にDLF形式へのコンバータを書けば、 サービスを追加できます。

Lireの特長には、 MTAのeximやpostfixのように、 同一のサービスにたいして別々の実装を比較できる、 という点があります。

効率、 計測、 システム保守、 問題解決、 マーケティングといった事業に数ギガバイトのログファイルをかかえる会社で、 うまくこなしていることから、 このプロジェクトは、 すでに十分あかしを立てたといえます。 したがって、 十分安定していると思われます。

Brave GNU Worldのアンケートに答えてくれたJosh Koenigによると、 最大の弱点は、 現在APIで、 理解も難しく、 文書化も不十分です。 ユーザーにやさしいGUIをのぞけば、 将来、 これが開発の主な懸案事項です。

新しいサービスへのフィルター同様、 この分野への手伝いは、 大歓迎です。 また、 グループでは、 特に中規模から大規模の会社でLireの評判を上げてくれる手助けを、 さがしています。

世界中のさまざまな国にいる開発者らが貢献をしていますが、 LogReport開発チームの中心には、 Joost van Baal、 Francis Lacoste、 Egon Willighagen、 Josh Koenig、 Wessel Dankersらがいます。 プロジェクトは、 オランダにある慈善団体のLogReport Foundationが、 保守しています。

技術的な有用さをのぞいても、 このプロジェクトは、 Free Softwareにおける最も重要な経済的特長、 つまり、 同じ作業の繰返し防止のよい例にもなっています。

GNU Source Highlight

Lorenzo Bettiniによる、 GNU Source Highlight [12] は、 ソース・コードをとりこみ、 構文を強調し、 HTMLやXHTMLの出力をつくりだします。 これは、 Brave GNU Worldの第21号 [13] で紹介したcpp2htmlや、 java2htmlといったツールから発展し、 GNU Source Highlightへと融合したのです。

入力フィルターには現在、 Java、 C/C++、 Prolog、 Perl、 PHP3、 Python、 Flex、 ChangeLogがありますが、 他の言語用フィルターの追加もできます。

このプロジェクト自体は、 C++で書いてあり、 Lorenzo Bettiniによれば、 安定しているとのことです。 彼は今、 新しい出力形式 (LaTeX) に取り組んでおり、 プログラミング言語の記述のために現在使っているFlexの代わりになる、 専用の言語をつくろうと思っています。

彼がこのプロジェクトで受け付けた支援のほとんどは、 他の開発者の書いた、 さまざまなプログラミング言語用のフィルターでした。 たとえば、 John Millawayは、 FlexとChangeLogのフィルターを書き、 Christian W. Zuckschwedtと、 Josh Hiloniは、 XHTML出力に貢献し、 Martin GebertはPythonフィルターを書きました。 Alain Barbetは、 PHP3とPerlのフィルターを書きました。

現在このプロジェクトの主な弱点は、 ただ辞書的に解析されるため関数の参照から関数定義へまだ移れない、 という点にあります。 したがって、 この改善と、 さらなるフィルターの作成は、 このプロジェクトを支援するよい方法になります。

本質的に、 GNU Source Highlightをコマンド行ツールや、 ウェブの対話的CGIとして使う開発者は、 このプロジェクトの利用者の正統派といえます。 しかし、 グラフィカル・ユーザー・インターフェースの良さの方を評価する利用者もいます。

Ksrc2html

Martin GebertによるKsrc2html [14] は、 GNU Source Highlight用のグラフィカル・ユーザー・インターフェースで、 GNU General Public License (GPL) の下で入手の可能なFree Softwareです。 その名前が暗示するように、 Ksrc2htmlは、 C++、 Qt、 KDE 2を基礎にしており、 KDE 3への更新が計画中です。

Ksrc2htmlは、 パラメータでのよりよい制御のため、 整形プレビューができます。 また、 色とフォント・タイプの設定は、 対話的におこなうことができ、 後での利用のため保存もできます。

フランス語翻訳のめんどうを見ていたXavier Outhierのおかげで、 Ksrc2htmlは現在、 ドイツ語、 フランス語への地域化もできます。

さまざまなプログラミング言語用に自動調整できるような色や、 フォント・タイプのダイアログの拡張を計画中ではありますが、 Martinの考えでは、 プロジェクトは安定しています。

また彼は、 KDE 3への移植は大歓迎だと知ってもらいたいとのこと。

アジアのFree Software

たぶんアジアの読者なら読んでうれしいことですが、 2002年7月10日、 「フリー ソフトウェア イニシアティブ ("Free Software Initiative of Japan")」 (FSIJ) [15] が設立されました (*)。 これは、 日本においてさらなるFree Softwareを求め、 未来のFSF JapanやFSF Asiaの基盤をつくるものです。

---

(*) 訳注: 7月10日は会員募集開始の記者会見日で、 本当の設立はそれより前。

---

長年Free Software Foundation North Americaの "Vice President Japan" として活動を続け、 また昨年のヨーロッパ旅行でFree Software Foundation Europeのメンバーらと徹底的に議論した井田昌之教授が、 FSIJの理事長です。

日本におけるFree Softwareに衝撃をあたえるべく、 さる10月22日、 23日、 東京において、 FSIJは"Free Software Symposium 2002"を開催しました。 アジアにおけるこの種の最初の行事として、 中国、 タイ、 日本、 シンガポール、 ドイツ、 イタリア、 米国から発表者が招かれ、 興味深い会議次第になりました。

Debian、 HURDプロジェクト、 中国のGNU/Linux配布物件であるRedFlag Linuxといった、 やや技術的な発表の他、 Free Softwareについての広い話題、 ヨーロッパやアジアにおける状況も語られました。

10月22日夕方の円卓会議では、 プログラムの国際化でのより良好な国際強力の問題について、 議論されました。 また、 Free Softwareのためのソリューション・オリエンテッド・データベースの可能性についても、 同様に議論されました。 確かにこういった問題は2時間で解決はされないのですが、 そこで見つかった実用的な若干のアイデアは、 今もメールで継続しています。

これはすべて、 アジアにおけるFree Softwareにとっての重要な一歩であり、 またアジア諸国間での対話を強めるものです。 さらにその上、 2003年3月頃、 タイにおいて後続行事が開催されるようです。

このような行事を、 アジアの国から国へと移動する恒常的な学会として確立することも、 可能であるかもしれません。 どちらにしろ、 アジアにおけるFree Softwareがさかんであることを見られるのは、 とてもよいことです。

アジアにいらっしゃるBrave GNU Worldの読者で、 かかわってみたいと思う方は、 FSIJやFSF China [16] に連絡されるとよいでしょう。

それでは、 次回まで

今月のBrave GNU Worldは、 ここまで。 繰り返しをすると、 一部の読者に読み飛ばされるかもしれませんが、 毎月どおり、 ご質問、 お考え、 コメント、 面白いプロジェクトについてのメールをお願いいたします。

メールに埋もれる危険を覚悟でいうと、 皆さんへは具体的な質問をお願いしておきます。 ダグラス・アダムズを引き合いに出すと、 Free Softwareが答えになるような、 最も重要な質問を、 ぜひ聞いてみたいと思います。 他と同様、 質問は、 いつものアドレス [1] までお送りください。