積極的にユーザに問い合わせるべきだと思う

文字コードの自動認識についていろいろ調べてみると、少なくとも日本語では、完全な自動認識というのは不可能であるらしい。まぁ、当たり前と言えば当たり前だが。当然のことながら、Shift-JISとEUC-JPとASCIIとJISとでは、文字コードとして使用する値が部分的に重複している。もし、入力したテキストファイル中に、たまたま重複した領域の値しか含まれていなかったとしたら、機械には判断のしようがない。

極端なことを言うと、A～Zまでのアルファベットしか含まれていないテキストファイルを読み込んだとき、それをASCIIと判断するべきなのか、Shift-JISとするべきかEUC-JPとするべきか、あるいはJISなのかBIG5なのか、それはユーザにしか判らない問題だと思われる。

無論、そのほかの様々な情報を総合すれば、ある程度の推定を下すことも可能だ。例えば、ShifT-JISとEUC-JPとで重複している文字コードの領域というのは、Shift-JIS側では余り使用されることの無いであろう文字ばかりであるとか、言語や文字コードが違えば値の出現頻度が変わるとか（例えば英語ならスペースやeが多い）、使用しているロケールがjaならばEUC-JPである可能性が高くBIG5は余り使われないだろうとか、いろいろと考えることができる。

だが、そういった情報による判断は万能ではない。ユーザの中には変な文字ばっかり使いたがる奴だっているかも知れない。意味もなく旧字旧仮名を使う気色の悪い連中だって、世の中にはいるのだ。どんな奴がいるか、知れたものではない。

いずれにせよ、完全な認識ができない限りどんなに高い精度で予測しようとも、必ず文字コードをユーザに問い合わせる機能は必要になるということだ。ということであれば、認識精度はそこそこでも構わないから、判断がつかないのならつかないなりに、ちゃんと「判らない」という答えを返す方が重要なのではないかと思う。

つまり、間違った答えを本物と信じて、ユーザに何も問い合わせることなくそのまま処理を続行してしまうのは、よろしくないのではないかと思われる。それならば、積極的にユーザに問い合わせるべきなのではないだろうか。

文字コードの自動認識

「主筆」第19版を公開して以降、少しばかり開発を中断している。前にも書いたが、物の開発に対する意欲にはいくらか波があり、今はその谷間に来ている為である。とはいっても全く手を休めているわけではなく、エンコードの自動認識を行う機能を少しずつ作りつつある。ゆっくりとではあるが。

エンコードの自動認識は、今更自分で作り込まなくとも、既存の物がいくらでもあるような気もするのだが、いろいろと思うところがあって、結局自分で作ることにした。要は、「主筆」は日本語に依存したくないから、エンコードの自動認識機能も様々なエンコードに容易に対応できるようにしておきたかったのだ。

理論上は、世の中で使われているありとあらゆるエンコードに対応できるような自動認識機能を、自力で実装してしまえばいい。だが俺は、スワヒリ語やタガログ語はもとよりドイツ語やフランス語すら理解し得ない都合上、世の中全てのエンコードを使ってテストを行うことができない。つまり、英語と日本語以外のエンコードに対応できる自動認識機能は、俺には実装することができないのである。

ではどうすればいいのか。仕方がないからここは、俺には対応し得ないエンコードに対応する為のモジュールを、容易に追加・削除できるようにしておくしかない。そして後は、将来の俺か、あるいは俺以外の誰かに期待するしかない。

とはいっても、俺以外の誰かが俺にはできないことをやってくれるとは、到底思えないのだが。

出処進退

第19版を公開し、Webページも更新したところで、Fire v250の方のOSを入れ替えることにした。どうにも環境の出来が悪く気に入らないためだ。ついでに、開発環境もSun Studio 11からSun Studio 12に更新することにした。

ところで、Sun Studio 12はSolaris 8には対応していない。ここでもし、開発用のソフトをSun Studio 12にしてしまったとしたら、Solaris 8は切り捨てなければならないことになるのだろうか？

確かに、今までの開発方式を踏襲するのであれば、そういうことになる。だが、残念ながら俺は、まだSolaris 8を見捨てるつもりはない。例えSunが捨てても俺は捨てない。

ではどうするのか？　Sun Studio 12に乗り換えたときにSolaris 8で実行できるバイナリが生成できなくなるのは、Sun Studio 12がSoaris 8上で動作しないためである。つまり、Solaris 8で動作するバイナリを生成するためには、Solaris 8上でコンパイルしなければならないため、使用しているコンパイラがSolaris 8で動作しないとなると、Solaris 8用のバイナリが生成できないと言うことになるのだ。（WindowsではAPIの互換性さえ保っておけば、Windows XP上でコンパイルしたバイナリもWindows NT 4.0上で動作させることができるし、うまくすれば9x系でも動作する。だが、残念ながらSolarisはそういうことはできないようになっているらしい。）

だがここで一つ疑問が生じる。なぜ、Sun Studio 12を使って作られたプログラムは、Sun Studio 12でコンパイルしなければならないのか。C++で書かれているのなら、C++に対応したコンパイラを使えばコンパイルできるはずではないか？

確かにその通りである。少なくとも、CやC++で記述された範囲であれば、何もわざわざSun Studio 12でコンパイルしなくともForte developper 6.0でだってコンパイルすることができる（はずだ）。だが、そうでない部分が一箇所ある。それは、X-Designerで生成されたファイルだ。

GUIのデザインを作成するツールであるX-Designerは、設計されたGUIを独自のファイル形式で保存する。そして、コンパイル時には保存された独自形式のファイルを読み込み、Cのソースコードを出力する。問題はこの独自形式のファイルで、こいつは古いバージョンの奴で作られたファイルを読むことはできるのだが、新しいバージョンのX-Designerで生成されたファイルを、古いバージョンのX-Designerで読み込むことができないのだ。Sun Studio 11と12の互換性についてはまだ調査していないが、少なくともForte Developper 6.0 Update 2とSun Studio 11の間ではそういう関係になっていた。だから、Sun Studio 11と12でも同様であると考えた方が良いだろう。

つまり、一度でもGUIのデザインをSun Studio 12で編集してしまったら、金輪際二度とSun Studio 11には戻れないと言うことだ。だから、Son Studio 12がSolaris 8に対応していないと、Solaris 8用のバイナリが生成できないという理論が導き出されることになる。

だがよく考えてみれば、というかよく考えなくとも、Solaris 8上でできないのはX-Designerの独自形式のファイルからCのソースコードを生成する部分なだけであって、生成されたCのコードがあればForte Developper 6.0やSun Studio 11でコンパイルすることが可能なはずである。現に、一筋縄ではいかなかったとはいえ、似たようなことであれば、やったことはなくはない。

だから、うまい具合にMakefileを書いて、X-Designerで生成したGUIを表示するためのCのソースも一緒に配布してやるようにすれば、Solaris 8上でコンパイルすることも可能になるはずなのである。とはいえ、リンクするライブラリを配布する問題とか、いろいろとパス名が違う問題とかがあり、そう簡単にできることでもないのだが。

いずれにせよ、多少工夫してやればSun Studio 12に乗り換えてもSolaris 8を切り捨てる必要はなさそうである。

だが、ここにいたって別種の問題が持ち上がってきた。それは、Solarisの将来のバージョンではCDEがサポートされなくなることだ。前々からそんな話はなくもなかったが、ここに来て、CDEでログインする際に「将来のバージョンではサポートされなくなるから早くJava Desktop Systemに切り替えろ」という意味のメッセージが表示されるようになった。

見てくれが悪いからなのか共産主義者が多いからなのか何なのかは知らないが、世の中一般ではCDEは嫌われる傾向になるらしい。だが、誰なんと言おうとも俺はCDEが好きだ。GNOME何か死んでも使いたくない。あんな腐った鈍重なデスクトップ環境など、到底使用には耐えない。とはいえ、OpenWindowsと同様にSolarisでCDEが使えなくなるのは、もはや時間の問題である。

こうなると、さすがにそろそろ「主筆」の出処進退について考えなくてはならなくなるようだ。主筆はSolaris上のCDEで快適に動作することを特徴としている。そのCDEが無くなるとなると、「主筆」の居場所も無くなってしまうのだ。

どうやら、俺と「主筆」に与えられた選択肢は三つあるようだ。一つはこのままSolarisのCDEと共に心中する道だ。未だにCP/Mを使い続ける人がいるのと同じように、Solaris/CDEもこの世の中から完全に消えて無くなるまでには、相当の時間がかかるものと思われる。だから、このままCDEに拘泥し続けて残存者利益を享受し、最後はCDEと共にひっそりと消えていくという道が考えられる。

二つ目はネイティブのデスクトップ環境をJava Desktop Systemに替えることだ。なんだかんだと言っても、やはり時代はGNOMEやKDEに傾きつつある。これは致し方のない事実だ。ということで、「主筆」をJDS上で快適に動作するよう作り直すという方法が考えられる。だがこれは、GPL臭いものは嫌いだという俺の宗教観に真っ向から対立する道であり、そう容易には採用できない。そもそも、GNOMEをメインのデスクトップ環境として使うようにするのであれば、そもそもがSolarisである必要はなくLinuxに乗り換えてしまった方がマシである。

三つ目は、未だにCDEで頑張り続けている他の商用UNIXすなわちAIXないしHP-UXに乗り換える道だ。今の俺の心情では、この方向性が一番魅力的である。だが、それにはAIXないしHP-UXが動作するマシンを用意する必要があるため、それなりに経済的負担を負わなければならないという問題がある。

最近仕事で、HP-UXに触れる機会があり、その痺れるようにカッコイイCDEのデザインに心引かれつつある。やはり、売れなくなってきて共産主義者に媚びを売る様になった軟弱者とは格が違う。ログイン画面もへたれならログイン後の画面もいい加減で、俺の心の琴線を刺激してやまない。アレぞまさしく男のロマンだ。俺の目指すべき理想の姿がそこにある。

だがそうは言っても、俺の手元にある実弾は心許ない。もう少し戦線が回復できたら、HP-UXかAIXへの移行について検討することとしよう。とりあえずそれまでは、Solaris依存の部分を共通的な方式に変更する仕事でもやることにしよう。

第19版の公開

とうとう「主筆」の第19版を公開した。

第18版との最大の違いは印刷機能が実装されたことだけなのだが、それでも公開するまでに半年以上の時間を要してしまった。

意外と地道に書き続けているblogを読み返してみれば、実は相当以前から印刷機能の実装に取り組んできていたらしい。一番古い記述は2007年1月22日にまで遡る。この当時はまだ第18版を公開していなかったことを考えれば、印刷機能の実装には随分時間がかかったものだと、言わざるを得ない。

だが、時間がかかったのは手を抜いていたばかりではない。純粋に開発工数が嵩んだためでもある。俺にとっては未知の言語であるPostScriptを勉強しつつ、それを出力するために必要となる多数のパラメタを入力させるインタフェースを作り込み、最終的にプリンタまで送り出すための出力処理など、思えば長い道程だった。

中でも特に苦しんだのが、エンコードの違いによる差異だ。印刷するとき、PostScriptの中でフォントを指定する必要がある。だが、そのフォントはエンコードによってそれぞれ別のフォント名を指定する必要がある。つまり、フォントはエンコードを意識するのだ。その為、そのPostScriptを生成する主筆側でも、ロケールに合わせてフォントを替えてやるようにしてやる必要がある。

だが、ここに一つ大きな罠がある。PostScript チュートリアル&クックブックを見ると、日本語環境において利用可能なフォントは、JIS・SJIS・EUCのそれぞれの環境におけるゴシック体と明朝体であると記載されている。だが、Solarisでは使用されるエンコードがUnicodeになる可能性がある。

もし単純に、PostScript内でのエンコードをカレントのロケールに合わせて、同時にフォント名もロケールに合わせて入力させるようにした場合、Unicodeでは印刷できないということになってしまう。

俺個人としてはUnicodeのロケールで使うつもりは更々無いのだが、とは言ってもロケールへの非依存は主筆の特徴として高らかに謳っていることでもあり、無視するわけにはいかない。

ということで、こういう事にした。まず、少なくとも日本語環境ではフォント名はEUCのものに固定する。当然、PostScript内に出力される文字列もEUCにする。それでもって、日本語以外の環境に対応するために、"PostScript内で使用するエンコード"をリソースで設定できるようにする。

こうすれば、例えロケールがUnicodeのものであったとしても印刷することが可能になる。

だがその為には、印刷前にテキストをEUCに変換してやる処理を入れなければならない。しかも都合の悪いことに、エンコード変換処理は別プロセスに切り出してしまってある。その都合上、エンコード変換はそう容易には行かない。

だが、容易には行かないとは言っても、やるしかないのだから実装した。パイプやテンポラリのファイルを駆使し、入力されたヘッダやフッタの文字列も含め、然るべくエンコードを変換するよう作り込んだ。

お陰で、印刷処理を行っているモジュールが随分肥大してしまった。単純に行数で行けば、このファイルが一番長い。仕方がないとはいえ、見苦しいことこの上ない。

だがまぁいいだろう。いろいろあったが、これで、テキストエディタとして最低限必要な印刷機能が実装されたのだから。