Develop and Download Open Source Software

今月のプロジェクト

2008年5月 - BrailleConverter

• プロジェクト名: BrailleConverter
• 登録日: 2008-03-04 18:30
• URL: http://sourceforge.jp/projects/brc/wiki/FrontPage
• プロジェクトホーム: http://sourceforge.jp/projects/brc/
• 動作環境: Console(Text Based)
• ライセンス: GNU General Public License (GPL)
• 言語: English, Japanese
• プログラム言語: Lisp
• プロジェクト管理者: tmatsugaki

プロジェクトの概要

Common Lispで記述された日本語、英語、その他の外国語の点字・墨字テキストの相互変換プログラム。

プロジェクト管理者へのインタビュー

Outline

• このソフトウェアはどんなソフトウェアですか？
• プロジェクトを始めた動機は？ また、どうやって始めましたか？
• このソフトウェアのターゲット・ユーザーは？
• このソフトウェアをどれくらいのユーザーが利用しているとお考えですか？
• プロジェクトがうまく行っていると感じるのはどんなときですか？
• このプロジェクトをやっていて最も驚いた出来事は？
• このプロジェクトで最も苦労している点は？
• 今後のプロジェクトの方向性は？
• どのような要望がユーザーからあがっていますか？
• このソフトウェアあるいはプロジェクトについて誇れるところは？
• このプロジェクトでどこかやり直せるとしたら、どこを変更したいですか？
• あなたの本業は何ですか？
• あなたの開発環境は？
• バージョン・ヒストリー：
• このプロジェクトに貢献するには？
• SourceForge.JPへの要望をお聞かせください。

このソフトウェアはどんなソフトウェアですか？

CUIで点字と墨字（点字ではない普通の文字）の相互変換をするプログラムです。

プロジェクトを始めた動機は？ また、どうやって始めましたか？

バリアフリーな分野で自分が貢献できる何かを探していたところ、点字に興味を持ったので変換プログラムでも作ろうかと思ったのがきっかけです。当時、すでにNFBTransというフリーの墨字→点字のコンバータが存在しており、Cで記述されているため高速でありかつ機能も多彩であるということで、まずこれを試してみることにしました。私はMacを利用しているのですが、第三者によるNFBTransの改造版にMac OS Xでの動作を謳うものがあったこともNFBTransを選んだ理由の一つです。

ところが、その改造版が何故か私の環境では動作しません。オリジナルのNFBTrans自体にも日本語非対応であったり英語の変換結果に少々変なところがあるという問題がありました。何だかいろいろ問題があって厭になったのでNFBTransを改造（バグフィクス・機能拡張）しようかと、ソースコードをざっと斜め読みしたところ、ちょっとメンテナンスが難しそうだと感じて改造は断念。ということで、結局ゼロから作ることにしたわけです。せっかくゼロから作るのですから自分が楽しく開発できることを重要視し、言語にはLispを選んで、のらりくらりと開発することにしました。

Lispを選んだ理由ですが、点字の変換ルールは結構多岐に渡るのですがデータベースの採用を迫られるほどではないので連想リストを持つ言語を採用すれば十分だと判断しました。最近流行っていることと昔挫折した悔しい経緯もあって、今回はLispでやろうと決めました。最近はフリーで立派なCommon Lispの処理系があるので本当に良い時代になったと思います。最初に開発した日本語の点字・墨字の相互変換部分の開発は比較的平易だったのですが、複雑なルールベースの省略があるグレード2英語の相互変換部分の開発では未だに手を焼いています。

このソフトウェアのターゲット・ユーザーは？

• 自分を含めて点字を学んでいる方。
• 自分を含めてLispを学んでいる方。

このソフトウェアをどれくらいのユーザーが利用しているとお考えですか？

ダウンロード数からすると、今のところほとんど0人ではないかと思います。

プロジェクトがうまく行っていると感じるのはどんなときですか？

今のところ一人プロジェクトなのと反響がないため、残念ながらそういう感じはないです。

このプロジェクトをやっていて最も驚いた出来事は？

• Common Lispの生産性が高いこと
• 国の内外を問わず、点字の仕様が迷走していること
• SourceForge.JPのプロジェクト管理環境が至れり尽くせりなこと
• DuxburyのDBT（Duxbury Braille Translator：商用の変換プログラム）に非常に永い歴史があるということ（起源はData GeneralのNovaやEclipse上で実現されたツール）

このプロジェクトで最も苦労している点は？

• グレード2英語の変換結果を検証するのが結構大変です。海外で定番の点字変換プログラムであるDuxburyのDBTは高価なので、オープンソースのNFBTransの変換結果を参考にしてBrailleConverterの変換結果の検証をしているのですが、NFBTransの変換結果（特に点字→墨字）に問題があるのです。
• 国内外での点字の標準化の動向が不鮮明であることも問題です。規格がどう転ぶか分からないので、BrailleConverの開発では将来の変更へ迅速に対応できるよう、シンプルさを維持するように努めています。
• グレード2英語の変換ルールには矛盾というか一意性にかける部分があるように思われます。自分が変換ルールをきちんと理解できていないので間違っているかも知れませんが、上記のNFBTransの変換結果の問題もこれに起因しているように感じています。
• 開発マシンのPowerMac G4 Cubeの処理速度が遅く、最新バージョンのOS Xも使用できないこと。

今後のプロジェクトの方向性は？

• UEBC（Unified English Braille Code：統一英語点字記号）その他の言語フォーマットヘの対応。
• 日本語の分かち書き機能の追加。（別プログラムで実装するつもりです）
• 点字プリンタその他の機器の制御機能の追加。（これも別プログラムで）

どのような要望がユーザーからあがっていますか？

• よそ様からは特にないです。
• 大きな懸案の1つとして「1.8GHzのPentium MでSBCL（※）使っても遅い変換速度はどうにかならんか？」というのがあります。

※　SBCL（Steel Bank Common Lisp）は高速処理で評判の高いオープンソースのCommon Lisp処理系です。

このソフトウェアあるいはプロジェクトについて誇れるところは？

• Common Lispのお陰ですが、リーダーを利用することで対話的に変換できること。
• これもCommon Lispのお陰ですが、プログラムの構造がシンプルであること。実際に難しいことをしているわけではないので当然なのですが、正規表現／オブジェクト／構造体の使用を見送りました。
• 内部の点字標準フォーマットを点字のビットパターンを基調に構成しているので、点字のシンボルに依存した処理などの将来の拡張を容易にしていること。基本的な考え方は画像コンバータのpbmplusなどに習ったもので、内部の標準フォーマットを経由した変換方式を採用しています。この方式は若干スピードを犠牲にしますが、合理的な内部処理が可能であると考えています。
• グレード２英語の変換においては辞書を使った学習機能を持っています。コストのかかる変換を幾度も繰り返さないようにするため導入した仕組みなのですが、今のところ目覚ましい効果は出ていません。

このプロジェクトでどこかやり直せるとしたら、どこを変更したいですか？

特にないです。

あなたの本業は何ですか？

中年プログラマです。

あなたの開発環境は？

• Mac OSX 10.4.11 (PowerMac G4 Cube), GNU CLISP 2.43
• Debian GNU/Linux etch (ThinkPad X32), GNU CLISP 2.41

バージョン・ヒストリー：

まだpre Alphaの段階であり、バグフィクスをタグ付きで管理しているだけというのが実情ですので、すみませんが割愛させていただきます。

このプロジェクトに貢献するには？

設計・開発・テスト・助言でもなんでも助かります。

SourceForge.JPへの要望をお聞かせください。

すばらしいプロジェクト管理環境を無償で提供していただき、大変感謝しております。さらなる進化を期待しています。

(取材日：2008年4月11日)

記事へのご感想をお寄せください。

今月のプロジェクトに戻る