アクセス数

なんだかんだ言って、アクセス数は少しずつ上昇しつつある。およそ一週間サイクルで上昇と下降を繰り返しつつ、もう少し長いサイクルでの変動があり、全体としては増えている。

ここ二ヶ月ほどは、一日平均100PVを維持している。下は50PV/日から上が200PV/日ぐらいだ。

それなのに広告収入は一向に増える気配がない。最近アクセスしてくるようになった人間は、広告をクリックしない類の人たちばかりなのだろうか？

法則

マーフィーの法則というのだったか、物事は常に悪い方へ転ぶ、あるいは、常に裏目に出るという法則がある。

なぜか知らないが、俺が傘を持って外に出ると決して雨は降らず、持ってこなかった日に限って雨が降る。一体何の嫌がらせなのかは知らないが、傘は必要なときには無く、入らないときに限ってあるから困る。

スーパーのレジもそうだ、俺が並んだ列はいつも進捗が悪い。気が付くと俺の後ろにいる奴の方が先に精算を終えている事がある。大概にして、俺の直前にいる奴がやたらと時間のかかる奴であることが多いのだ。一体何の嫌がらせなのかは知らないが。

そもそも、スーパーのレジでなぜにそんなに時間がかかるのだろうか？　一体何をしているのだろうか？　人によっては15分ぐらい粘っている奴がいる。時間を掛けた方が得だとでも思っているのだろうか？

遅いと言えば、ATMのいじっているオバハンも不思議だ。一体何をしているのだろうか？　なせあんなに時間がかかるのだろうか？　いくつもの通帳やカードをとっかえひっかえ、金を出し入れしている。暇なのだろうか？

年寄りは歩くのが遅い。それはまぁ致し方のないことだろう。しかし、だったら人の前に強引に割り込むのはやめてもらえないだろうか。突き飛ばされたいのだろうか？　まぁ、そういう場合俺は押しのけて進むわけだが。自分の歩く速度を考えずに、人の前に割り込んできた奴の方が悪いのだから。

女はなぜ道をよけないのだろうか？　自分の方が優先されるとでも思っているのだろうか？　コンビニなんかで、商品棚の前に俺が立っていて、方一方から女が進行してくると、その女は絶対に止まらない。男の場合は、大概止まるか、進行方向を変えるか、道をよけていくのだが、女の場合はそういうことはほとんど無い。なぜだろうか？　それでもって、俺が道をよけずに頑張っていると、その女はどんどん進んできて、最終的にはぶつかることになる。そうするとその女は、まるで俺が痴漢か何かかのような目つきで睨み付けてくる。一体何を考えているのだろうか？　被害者は俺であり、おまえの方が加害者ではないか。殺すぞ。

電車の中でもそうだ。自分の方から近づいてきておきながら人を痴漢扱いする。

酷い奴になると、自分で押してきておきながら「押すんじゃねぇよ」とか言ってきやがる。このときはさすがの俺もむかついたから「押されてるんだろうが、馬鹿が」と言い返しておいた。だが、今思い返すと言うべき言葉が間違っていたように思う。ここは「オメーが押してるんだろうが、売女」とでも言った方が良かった。

俺のオカンもそうだが、どうも、自分が悲劇のヒロインでありたがる奴というのが結構いるようだ。特に女がそうだが、男の中にもいる。何があっても自分は常にかわいそうな被害者であり、周囲の人間は常に自分に悪意を抱いている。そう本気で考えている奴が世の中にはかなり多数いる。

そういった人間に気を遣うのは、馬鹿馬鹿しいし報われないから、強気に出るに越したことはない。

進捗

一向に作業がはかどらない。土日を費やしても、結局、読み込み時のエンコード変換の処理を実装できただけだった。まだ出力時の変換処理が残っている。道のりは長い。

今現在は、とりあえずエンコード変換に対応使用としているだけだけで、それ以上の機能を付けるつもりはない。つまり、エンコードの自動認識は後にしようと思っている、ということだ。

だが、そうするとちょっと困ったことになる。

ファイルを開くとき、「ファイルを開く」ダイアログからファイル名を指定する場合は、特に問題はない。そこでエンコード名もいっしょに指定させればいい。だが、ドラッグ＆ドロップでファイルを開く場合はどうするべきだろうか。

自動認識機能を実装するのであれば、エンコードを自動認識するという仕様にするのがもっともだと思う。だが、自動認識を実装しないのであれば、是非ともどこかでエンコード名を入力させなければならない。

ドラッグ＆ドロップされたタイミングで、強制的にエンコード名のダイアログボックスを表示させるというのもあるだろう。だが、それでは使い勝手が悪くなるように思う。毎回表示されるのはさすがにうざいだろう。

一旦、カレントのロケールで使用されているエンコードで読み込んでみて、それで失敗するようだったらエンコード名の入力を促すという方法もあるだろう。だがそれにも問題がないわけではない。

どうするのが一番いいだろうか。

コードの再利用

プログラムを作っていると、かつて一度作ったことがあるような処理をもう一度作っていると言うことがある。既視感みたいなものだ。

それが単なる既視感なのであれば、それはそれでどうでもいいのだが、問題は本当に同じ様な処理を作ったことがある場合だ。

何かのプログラムでどこかに書いたであろう処理を、再度作り込むのは馬鹿馬鹿しい。かといっても、その処理が書かれたプログラムが一体どこにあるのか、それを思い出すことができない。

結局、同じ処理をもう一度記述する羽目に陥る。普段からソフトウェア工学なんたらと偉そうなことを行っている割には、俺の実態はこの程度のものだ。

この辺でそろそろ何らかの手を打っておいた方がいいのかも知れない。

そもそも論でいけば、リポジトリ関係のソフトを導入するべきだと思う。最良の解は、自分が作成したクラスや関数をリポジトリに登録し、コンパイル時にはリポジトリ内にあるコードが自動的に使用される、という仕組みだ。

だが、これを実現するのは非常に大変だ。ソフトの購入に金がかかるのは、まぁ仕方がないだろう。もしかしたらフリーソフトがあるかも知れないし。最大の問題は、開発スタイルの変更を余儀なくされることだ。

自分の作業手順が多少増減する程度であれば、特に問題はない。だが、作成するプログラム中に、リポジトリ内のコードを参照する為のコードを記述しなければならなかったり、あるいはヘッダファイルの参照や、リンクするライブラリの参照に変更が生じたりするのは、是非とも避けたいと思う。

結果としての実行バイナリだけが得られればいい、というのであればそれでもいいだろう。だが、ソースコードを配布しようとする場合には困ったことになる。配布するためには、リポジトリからコードを取り出して、必要に応じてMakefileやプログラムを書き換えて、単独でコンパイルできるようにしてやらなければならない。それは非常に面倒だ。だからといってリポジトリごと配布するわけにも行かない。

それ以外にも、ある特定のリポジトリソフトに全面的に依存するのにも嫌悪感を感じる。作成したプログラムの一部ないし大部分がリポジトリ内に格納されて、そのリポジトリソフトがなければコンパイルすることもできないとなると、不安を感じざるを得ない。

どうしたらいいだろうか。何か、俺の需要を満たしてくれるような、いいソフトはないだろうか。あるいはいい感じの物を自作するべきだろうか。

プロセスの分割

エンコード変換の処理を行うプログラムは、以前「祐筆」の為に作成した変換プログラムをそのまま使うことになった。今まで、変換処理の実装には、変換用プログラムから変換処理を行う部分を切り出してきて「主筆」に組み込む必要があるかと思っていた。しかし、どうやらそんなことをせずとも、変換処理を別プロセスで行うような実装にしても問題なさそうだ。

プログラムの明瞭性を高め、維持するためには、ロジックを様々なレベルで極力細かく分割するのがセオリーだ。たとえば、長大な単一の関数より小さな複数の関数の方が解りやすい（一般的には、だが）。同じ要領で、クラス・コンパイル単位・変数のスコープ・変数の寿命・コンポーネント・プロセス・サービスなど、いろいろな種類の「分割」が考えられる。

「主筆」第15版では、クライアント・サーバ・主筆本体の３つのプロセスに分割されている。そして今度それにエンコード変換のプロセスが追加される。

第15版の実装方法は、機能を実現する上での必要性から導き出された結論だ。しかし、上述の議論を考えると、プロセスの分割は必要性のみならずソフトウェア工学的な観点から見ても、もっと積極的に押し進めてもいいのかも知れない。

だが、プロセスで分割するのは何かと大変だ。処理の依頼と結果の受信は、全てIPCの機能を使ってやらなければならない。共有メモリとかパイプとかRPCとか、いろいろな種類のIPCがあるが、どれもこれもプロセス内での関数呼び出しに比較すれば遙かに複雑で困難だ。まぁ、だからこそ厳格に分割することができるのだが。

時間の問題もあるから、第16版では余り大したことはできないだろが、最近肥大化しつつある主筆本体の分割には、いつかは手を着けなければなるまい。

アクセス解析

この間から使い始めたアクセス解析を、徒然なるまま眺めてみた。

で、気が付いた。

まず、アクセスの内の多数が、makecabとjpeglibの使用法のページに集中している。でもって、このページへのアクセスの多数が、googleやyahoo等の検索エンジンから直接飛び込んできたものであり、他のページへ移動することなく俺のサイトから出ていくのだ。

つまり、これらのページは誘い水としては成功してはいるのだが、他のページにアクセスを誘導することができていないのだ。

じゃ、どうすればいいのか。

各ページの情報に関連性を持たせるのがいいのだろうが、そもそも関連のない情報は関連がないのだから、仕方がない。とりあえず、無理矢理にでもサイト内リンクを密にするべきなのだろう。

サイトの基本的な作りとして、左側にインデックスの領域を設けてあるのだが、「その他情報」のページだけは、追加や削除が頻繁にあるだろうという判断から、そのインデックスを付けていない。やはり付けるようにした方がいいのだろうか？

でも面倒なんだよな。ページ数も多いし。楽にやる方法はないものなのだろうか？

忘却

今現在、「主筆」にエンコード変換機能を実装しようとしているところなのだが、ある機能のことを完全に忘れていた。

読み込み／出力時に変換しなければならないのは、文字コードだけではなく改行コードもあったのだ。そのことをすっかり忘れていた。

実際に文字コード変換を行うプログラムはすでにできていて、それは改行コードの変換にも対応している。しかし、「主筆」側で改行コードの種別をユーザに入力させる機能が抜けていた。

要は、ファイル名を選択させるダイアログで、文字コードと共に改行コードの種別も入力させればいいだけのことなのだが、これが面倒くさい。入力項目の増減を伴う変更は、結構大きく変更が波及する。

これは別に主筆に限った話ではないし、それどころかXやMotifに依存する話でもない。Windows上のアプリケーションでも、EXCELマクロでも同様だ。

DOAなんたらの講釈を垂れるつもりはないが、あえて言わせて頂く。入出力項目の増減はデータ項目の増減につながることが多い。でもって、プログラムは処理するデータに依存して記述される。データありきのプログラムというわけだ。だから、データ形式が変更されると、プログラムに変更が及ぶ可能性が高くなるのだ。

そういうことで、改行コードの種別を入力させる機能を実装するのは面倒なのだ。先の原因不明のバグみたいなのが起こることもあるのだし。

第16版公開までは、今しばらく時間がかかるだろう。

デバッグ２

土曜日は接待飲みだった。なぜに金を払って仕事をせねばならんのか、等とここにサラリーマンの愚痴を書いても仕方がない。

この間、XtOpenDisplayの呼び出しでメモリアクセスエラーが検出される、と書いたが、そのエラーは主筆に限らずSun Studio 11の解説で使ったTestPrj3というプログラムでも発生することが判った。

このTestPrj3というのは、解説用に作っただけのきわめて単純な奴で、俺自身はほとんど何もプログラムを記述していない。だから、たぶんXtOpenDisplayの呼び出しで検出されるエラーは、俺のせいではないと言うことができるのではないだろうか。

そういうことで、メモリアクセスのエラーについては、ここではちょっとおいておくことにした。

で、次に何をしたらいいのか。寄る辺を失いする事が無くなったから、とりあえず漫然と起動時のシーケンスを一つずつステップ実行してみた。

そしたら気がついた。

CTaEditShell::OnCreateというメソッドは、シェルウィジットが生成されるときに呼び出される。つまり、シェルウィジットが生成されるときのコールバックとして登録してあるということだ。



で、このコールバックだが、こいつは本当にシェルウィジットが生成された直後に呼ばる。シェルウィジット配下の他のウィジットが生成される前に呼び出されるのだ。

一応、CTaEditDrawなどの「シェルウィジット配下のウィジットを管理するクラス」のインスタンスは、「シェルウィジットを管理するクラス」のコンストラクタで生成されているから、OnCreateが呼び出された段階では、こいつらにアクセスすることができるようになっている。しかし、ウィジット自体はまだ存在しない。

だからシェルウィジットのOnCreateの段階では、あまりウィジットやMotifの初期化処理を行うことができないのだ。

ところが俺は、今まで余りそういうことを考えていなかったようだ。思い返すだけでも身震いがする。

だから、今度はそういう視点で初期化処理について見直してみた。そして、今までOnCreate内にあったいくつかの処理（正確には、タイトルバーの文字列の設定をアイコンの読み込みなのだが）を、もっと後の方で呼び出されるメソッドに移設してみた。

その結果、一応プロセスが殺されることなく起動することができるようになった。

だが未だに起動できなかった本当の理由は判然としていないし、メモリアクセスエラーの問題も何ら解決していない。これでいいのだろうか？

主筆のデバッグ

ここ数日、主筆に文字コード変換機能を追加しようとして、いろいろと手を加えている。

その途中で、ドキュメント管理用のクラス（編集対象のテキストを保持している）に、エンコードの情報を保持するメンバを追加したら、主筆が動かなくなった。

起動する途中、メニューのウィジットを生成する処理でセグメント例外が発生して、プロセスが殺されてしまう。上述のメンバを取り除いてやると動く。

それ以外の状況なども含めて考えると、どうもメモリ関係のバグが発生しているようだ。Sun Studio 11が持っている、メモリアクセスのエラーを検出する機能を使用すると、いくつか引っかかるところがある。どう考えても何かがおかしい。

ところがだ、どこがどうおかしいのかがさっぱり判らない。いつ頃からおかしくなるのかすら判然としない。XtOpenDisplayの呼び出しでいきなりアクセスエラーが検出される。

Sun Studio 11が生成したコードがおかしいのか、MotifやXlibがおかしいのか、デバッガがおかしいのか、本当に俺の書いたコードがおかしいのか。それすらも判らない。まぁ、たぶん俺の書いたコードが間違っているのだろうが。

に、しても、XtOpenDisplayはプログラムの本当に初めの方で呼び出されるのであって、それより前には俺の書いたコードは実行されないはずだ。

一体何がおかしいのだろうか？

メタボール

深い理由はないが、前々からメタボールをやってみようと思っていた。しかしながら、今まで果たせずにいた。どうにも難しくて、なかなか作れなかったのだ。だが、この間ついに成功した。



絵はワイヤフレームで表示されていて、なんだか分かりにくいが、一応3つのボールが融合した形になっている。

ややこしい割には、実際にプログラムにしてみると結構単純で、総行数でも500行程度だ。俺は一体今まで何をこんなに悩んでいたのだろうかと、自分で自分を疑いたくなる。まぁ、短いから簡単と言うわけでもないのだが。

現在の実装だと、接合部分に乱れが生じやすく、それを防ぐためにはポリゴン数を増やす必要がある。しかし、ポリゴン数を増やすと、形状の生成や描画に時間がかかるようになる。

何らかの抜本的な対策をとるのが最前なのだろうが、それはもはや俺のおつむには不可能事に近いため諦めるとする。

今ひとつの方法としては、あらかじめ細かいポリゴンで形状を生成しておいて、後から余分なポリゴンを削るという方法だ。これならまだ何とか俺の手に負えそうだ。

今度時間があったら、久しぶりにスクリーンセーバーでも作ってみることにしよう。

アクセス解析

日曜日、暇だったから全部のページにアクセス解析のコードを仕込んでおいた。

まだ余り結果は出ていないみたいだったが、とりあえず昨日統計を見てみた。

俺は今まで、俺のサイトに飛び込んで来るときに使用された検索エンジンは、ただ何となくgoogleが多いのではないかと思っていたのだが、どうやらそうではないらしい。

一番多いのはyahooだった。大体全体の3割程度がyahooの検索から入ってきている。googleは1割に満たない。

google analyticsは、えげつないことにアクセス元ドメインまでもが表示されるのだが、それを見るとどうも各社SIerからのアクセスが多いようだ。この事はアクセス数の変化、つまり平日が多く休祭日は減少する、という事実から何となく感じてはいたのだが、どうやらその感じは間違ってはいなかったようだ。

せっかくだから、今後のweb制作にアクセス解析の結果を有効活用させてもらおうか。

主筆のビルド

文字コード変換に対応するとか行っておきながら、昨日は本来の作業を怠って、ビルド時にパッケージが自動的に生成されるような仕掛けを作り込んでおいた。

仕掛けといったって、とどのつまりはMakefileでコンパイルによって生成されたファイルの収集とパッケージ生成を行う一連のコマンドを叩くだけなのだが。

この間買ってきてまだ残っている安いブランデーをちびりちびりとやりながら、その上テレビを見ながらの作業だったから、非常に時間がかかった。結局、昨日の進捗はその作業だけだった。

だがまぁ、この作業によって、今後のリリース作業が効率化されるようになったのだから、良しとするか。

検索・置換

検索・置換機能をいじった結果、こういう風になった。


それと、もう一つ機能を追加しておいた。

今まで、「検索・置換」ダイアログは、メインのウインドウの後ろ側に隠れてしまったら、そのウインドウを自力で移動して、「検索・置換」ダイアログをマウスでクリックしなければならなかった。だが、それでは面倒で不便だから、「検索・置換」メニューを選択するか、あるいはCtrl+Fキーを押すかすると、「検索・置換」ダイアログが一番前に表示される様にした。

それと後、検索に使用した文字列を記録しておいて、後からそれを参照できるようにする機能とか、「検索・置換」ダイアログにおけるショートカットキーなんかの機能を実装したいと思うが、それは後にしておくとにした。

とりあえず次は、文字コード変換の機能を実装することにした。そもそも「祐筆」は「主筆」での文字コード変換機能の実装を念頭に置いて作ったものなのだ。今まで後延ばしにしてきてはいたが、そろそろ実装しなければならない。

だが、ファイルで使用されている文字コードを自動認識する機能は、とりあえずおいておくことにしよう。何か、難しそうだから。

検索・置換機能の変更

「主筆」は昨日に引き続き、検索・置換処理を変更している。

実をいうと、今までの実装では、「置換」ボタンは現在選択されている範囲を削除して、置換後に設定する文字列を挿入していただけであった。

一応それでも、「検索」と「置換」を交互に連続して押下する場合には、そのほかの通常のエディタと同じような振る舞いになる。

しかし、そんな安直な実装だと使いにくいので、ちゃんとすることにした。今現在は修正を行っている最中である。


ところで、そろそろ近い将来にTOEICの試験を受けなければならないらしいから、久しぶりに英語のお勉強をやろうと思う。

とりあえず手始めに、英文のBlogを再開することにした。一応これだが、余り読むに値するようなもんではないと思う。

主筆の開発を再開

久しぶりに、「主筆」の開発を再開することにした。

とりあえず、検索・置換の周辺をいじることにした。あの辺は今ひとつ機能が不足していて不便だからだ。

今日実装したのは大文字と小文字を同一視した検索だ。一応正規表現による検索に対応している都合上、気合いと根性があれば大小文字を区別しない検索もできないことはないのだが、しかし、それはさすがに現実的ではない。

そういうことで、正規表現ライブラリに手を入れて、然るべき機能を実装しておいた。

ところで、俺が苦労して作った正規表現ライブラリは、その目的の都合上、検索対象のデータ型、及び、検索用の文字列のデータ型には依存しないように作ってある。

つまり極端なことを言えば、”文字列”は文字の列でなくとも、レコードのような複合的なデータ形式であったとしても、対処できるようになっている。

だがしかし、”大文字”・”小文字”を意識して処理を行うようにするとなると、上記の性質が失われることになる。どうするか。

とりあえず現状では、”文字”型のクラスが==演算子をオーバーロードすれば、いかなる型でも対応できるものとしている。俺の正規表現ライブラリを紹介しているページでも、同じ方法でもってして大小文字を同一視した比較を行っている。

「主筆」でも、理論上は同じ事をやれば然るべき機能を実装することはできるのだが、しかしそれは大変だ。「主筆」の内部のデータ形式を大幅に変更する必要がある。

どうするか。風呂に入りながら考えた。

結局、ごく単純な方法で対処できた。外部から、比較用の関数オブジェクトを指定できるようにすればいいだけだった。良くある方法だ。

まぁ一応、これでめでたしめでたしということなのだが、それに関連して一つ。

ForteC++6.0だとクラスのメンバ関数をテンプレートにすることができなかったのだが、Sun Studio 11だとできるようになっていた。

一応、コンパイラもぼちぼちと進歩しつつあるようだ。

まぁ、それだけなんだが。

メール

久しぶりにメールを見てみると、珍しく何通かメールが来ていた。

まず1通はVectorのダウンロード数の通知。例のごとく情けないほど少ないから、ダウンロード数はもう書かない。

あと、何かの広告が2通。これは無視して捨てておいた。

変わったところでは、Vectorからもう一通来ていた奴、うちの所のblogを使えという広告があった。

なにやら、課金機能だのユーザ管理機能だのがあるだ何だと抜かしていはしたが、しかし、申し訳ないが俺のblogにはそんな機能は全くもって必要ない。前々から書いている通り、このblogはほとんど誰にも読まれることはない。毎日毎日貴重な自由時間の内のかなりの時間を割いて書いているにもかかわらず、その努力は一向に報われること無く現在に至っている。

無償で公開していても誰にも読まれることのないblogなのに、それを有償にしたら一体誰が読むというのだろうか。例え無料であったとしても、登録制にしただけでも読者は絶無になるだろう。

そういうことで、各種の利点の一切を使わないのであれば、強いてわざわざblogを移動する理由は何一つ無くなる。だからこのままここに居座ることにしよう。

そして今一通来ていたメールは、googleのアクセス解析が使えるようになったとか、ならないとかいうメールだった。

googleという所は、ずいぶんな殿様商売をやっている会社で、俺としてはこんな所の商品は、できれば利用したくない。だがしかし貧乏サラリーマンとしては致し方のないことだ。背に腹は代えられぬ。

とりあえず、いろいろな意味でムカムカしながらも、何とかアカウントの設定をしておいた。後は気合いと努力と根性と忍耐と体力で、アク解用のコードを全ページに埋め込むだけだ。

あぁ、面倒くせぇ。

仕事

ぶっちゃけて言って、俺はほとんどまともに仕事をしていない。

一応会社員であって、ちゃんと毎日定時に出社してはいるのだが、することがない。暇で暇で仕方がないのだ。新手のリストラ策なのかと思ってはいたのだが、どうやら本当に仕事がないらしい。

それなのに不思議なことに、最近、人事的な評価のランクが一つ上がって、それにともなって給料が上がったらしい。茄子もちびっと増えたらしい。

企業とは不思議なものだ。朝会社に行って、PCの前に座って、一日寝ているだけで、なぜ給料が増えるのか。

だがまぁいいだろう。給料が下がったわけではないのだから。

とりあえず、増えた茄子を使ってUPSの一つでも買ってみることにしようか。電源が不安だしな。

画面のキャプチャ

おもむろにSolarisでの画面のキャプチャと、インターネットで公開できるようにする方法について書いてみる。

Solarisで画像をキャプチャするのに、俺はCDE付属のイメージビューアを使っている。


背景を右クリックして、スナップショットを選択すると、こんな画面が表示される。


で、このツールを使って画面をキャプチャすると、こんな感じになる。


問題はここから。キャプチャした画面はファイルに保存しなければならないのだが、一体何の形式で保存すればいいのか。

この後、画像に対して縮小などの加工を行いたいから、画質の劣化無く保存したいと思う。でもって俺の場合、画像の加工はWindowsで行いたいから、Windowsで扱うことができる形式で保存したい。

イメージビューアで保存できる形式の内、そういった需要を満たすのはTIFFしかない。TIFF形式で、圧縮を「なし」、カラーを「フルカラー」で保存してあげればいい。


そうしてキャプチャした画像がこれ。


その次に、キャプチャした画像をインターネットで公開できるように加工することを考える。

インターネットで公開するためには、GIFやJPEGに変換する必要がある。それに、Webサイトに使用できる記憶容量の問題とか見る人の利便性とかも考えれば、ファイルサイズは極力小さくする必要がある。でもって、画質はできるだけ落としたくない。

その為に俺は、Visual Studioを買ったときにくっついてきたFront PageにくっついてきたImage Composerというソフトを使っている。なぜこのソフトなのかといえば、それは単に俺のPCにインストールされていたから。


ここで画像をGIFにすることを考える。

まずは、さっきSolarisでキャプチャしたファイルを、何らかの方法でWindowsPCに持ってくる。で、Image Composerでそのファイルを開いて、メニューの中の「ツール(T)」－「色の選択(K)...」を選択する。そうすると、こんな画面が表示される。


ここで「新規作成」ボタンを押す。パレット名は何でもいい。ディザ処理の方法はべた塗りを選択しておくといい感じになるようだ。


OKボタンを押すと、「色の選択」ダイアログがこういう風になる。


「色の作成」ボタンを押すと、下の絵のようなダイアログが表示される。ここで色数を256、作成元は選択範囲を選択して、追加ボタンを押す。


そうすると、「色の選択」ダイアログのパレットに、必要な色が登録される。で、OKをおしてこのダイアログを閉じる。


後はGIF形式で保存すればいい。ただそのとき、画面下部にある「色の形式」のところで、さっき作成したパレットを指定してあげる必要がある。そうしないと画面が汚くなる。


まぁ、大体こんなもんだ。

キャプチャした一枚の絵を公開するまでには、結構手数がかかっている。個人の趣味でやっているとはいえ、我ながらご苦労なことだとつくづく感心せざるを得ない。

その割に報われないのだが。