KDEのMLなんかを読んでいると、時々「n7y」なる語を見かける。
が、この意味がさっぱりわからない。

というわけで、grep '^n.......y$' /usr/share/dict/words

naggingly
narratory
naseberry
nassology
naturally
naughtily
navigably
necessary
necessity
necrology
necrotomy
needfully
nemophily
neobotany
neoplasty
nephology
nervosity
nervously
neurataxy
neuriatry
neurility
neurocity
neurology
neuronymy
neurotomy
neutrally
niggardly
nightmary
nimbosity
ninepenny
nippingly
nitrosify
nobiliary
nocuously
noddingly
noisomely
nominally
nomocracy
nonagency
nonbodily
nonbroody
nonchalky
noncounty
nonentity
nonexpiry
nonfamily
nonfelony
nongreasy
noninjury
nonpopery
nonremedy
nonsanity
nonsticky
nontreaty
normality
northerly
nostology
nothingly
notionary
notoriety
noveletty
noxiously
numbingly
numerably
nummulary
nuptially
nursingly
nutritory
nyctalopy

さあ、どれだろ。いや、ここにない可能性ももちろんあるけど。
necessaryとかは近い気もしなくはないけど。

QTextCodec::codecForContent()について

この関数、"Searches all installed QTextCodec objects, returning the one which most recognizes the given content."とあるように、与えられた文字列から、適切なCodecを得るための関数。
つまり、文字コードの自動認識を行なう関数です。

が、"Note that this is often a poor choice,"とあるように、はっきり云って使えない。その理由としては"since character encodings often use most of the available character sequences, and so only by linguistic analysis could a true match be made."とあるが、実際の理由は別のところにあります。
(上記は嘘ではないです。iso-8859-X系を考慮すると正しい理由でしょう。ただ、日本語を考慮すると上記の理由だけでは足りません)

QTextCodec::codecForContent()のアルゴリズムですが、
各codecのheuristicContentMatch()を呼び出し、その帰り値をスコアとして、
スコアがもっとも高かったcodecを適切なcodecとして選ぶというものです。

と、ここまで書いてqtのコードを確認していて、qeucjpcodec.cppやqjiscodec.cppではそれなりにheuristicContentMatch()が実装されてるのに気づく。
今までは、これが不十分だからだと思っていたが、他のcodecとの兼ね合いか。
それとも、いつのまにかそこそこまともに動作するようになっているのだろうか。

要確認かも。

kzkさんの日記の関連で、khtmlの日本語自動認識部の簡単な解説を。
ついでに考えている最中に見つけた問題点も。

なお、バージョンはKDE-3.1.Xのkdelibs/khtml/misc/decoder.cppを用いる。
日本語の自動認識はKDE-3以降なら入っている機能ではあるが、バージョンによる認識アルゴリズムの差はないはずである。
ただし、KDE-3.2では認識ルーチンが動作するための条件が変化する予定である。

実際の認識用ルーチンは KanjiCode::judge() であるが、これはjvimのソースコードから流用した物である。
認識精度、コード量などを考慮して、Unicode関連の認識ルーチンは削除したがアルゴリズム自体は変えてない。
このルーチンでは与えられた文字列に対して、それがASCII, EUC, SJISのどれであるかを判定している。
これに関する詳細は割愛。コードを見てください。

認識用ルーチンを呼び出している部分のコードは以下のようになっている。(改行等は変更)

if (!haveEncoding && KGlobal::locale()->languageList()[0] == "ja") {
        switch ( KanjiCode::judge( data ) ) {
        case KanjiCode::JIS: enc = "jis7"; break;
        case KanjiCode::EUC: enc = "eucjp"; break;
        case KanjiCode::SJIS: enc = "sjis"; break;
        default: enc = NULL; break;
}
if (!enc.isEmpty()) { setEncoding(enc, true); }

一行目のif文の条件から分かるように、利用言語の一番始めが日本語であることが自動認識が動作する条件である。
KDE-3.2では言語の認識系の動作条件が変更になったため、khtmlの自動認識対象を日本語に設定してあれば日本語の自動認識が動作するようになる。

また、htmlやhttpの段階でcharsetが指定されている場合にはhaveEncodingが設定されるため、自動認識は行なわれない。

dataにはkhtmlが読み込んだブロックが生のまま入っている。
dataの長さが幾つかは不定である。その時々の回線などの状況によって変化すると考えていただきたい。
(自動認識部のデバッグが難しいのはこれがあるためである。必要ルーチンを抜き出して、別に検証用プログラムを作成するのがよい)
KanjiCode::judge()でdataを評価し、その結果どれかの漢字コードだと分かれば setEncoding()を用いて漢字コードを設定する。
setEncoding()を呼び出せばhaveEncodingがtrueとなるため、そのページの以後のデータにおいて、漢字コードの確認、変更は行なわれない。
与えられたデータではコードが認識できなかった場合には次に読み込まれたデータで再度KanjiCode::judge()を呼び出す。

このコードの問題点は境界問題への対処を行なっていない点である。
dataの切れ目が漢字コードやJISのエスケープシーケンスの途中になっていた場合、この自動認識は失敗する可能性がある。
(回線が遅い場合に問題は発生しやすい可能性がある)

それへの対処としては、KanjiCode::judge()で、余りが出た場合にそれを返すようにし、次回の呼び出し時にはその余りも渡してやればよい。

また、自動認識の精度を上げるためにはKanjiCode::judge()の内部状態を構造体にでも格納し、ある程度以上の確度を得られるまでは漢字コードの判断をしないように変更するという手もある。
ただし、この場合には最後まで読み込んだ場合の処理を追加してやる必要がある。
(この修正をする場合にはバイナリコンパチビリティに注意)

というわけで、誰か修正と検証をしてみませんか?

KDEで、個人的に一番重要なソフトは実はkscdだったり。
CDの情報をcddbで管理している関係上、これできちんとcddbを
扱えることが私には必須なのだが、CVSではkscdの改造が始まっていて、
cddbまわりは現在まともに動作せず。
なおかつ、更新がムチャクチャ遅い。

変更の方向性も見えてないので無理やりパッチをつくる気にもなれないし。
どうしたものやら。

というわけで、ニューマシンを購入。
P4 2.5GHz(HT)、512MBと、そこそこ程度だけど、今までのマシンに比べるとスピードは段違い。
Linuxの事などほとんど考慮せずにスペックは決めていったが、
若干の設定でほぼ問題なく動作してくれた。

Linuxはどれを入れようか悩んだが、なんとなくでGentoo Linuxを。
時間はかかるし、それほど親切ではないが、なかなか面白い。
ebuildの書き方を調べないとな。
KDE-cvsの環境はこちらに移していくつもり。

メールを旧マシンと共用とかも考えているのだが、
古いメールをIMAPへ移すのがいいのかなぁ。
homeをNFSで共有っていうのは悪くないのだが、
めんどうだし、あまりやりたくない。
昔のNFSが馬鹿みたいに遅いときの虎馬が残ってるだけだとは思うが。

書くのはずいぶんと遅くなってしまったが、ファンを購入してマシン復活。
qt、KDEのコンパイルも問題なし。
安いのを買ってきたからか、うるさくはなったが、まあ、いいか。
が、いい加減遅いのに嫌になったので新マシン購入を決意。

ようやく仕事も落ち着いてきたので、とりあえずKDEのアップデートをしようかと思ったが、
Qtのコンパイルが失敗。Internal compiler errorで不定期に落ちる。
どうもおかしいな、とメモリかディスクを疑ったが、ふとケースを触ったら熱い。
電源のファンもCPU用のファンも止まってやがる。
そりゃ、Qtのビルドも失敗するわけだ。

電源とCPUファン買ってくるか。
しばらく高温で動かしてたことになりそうだからCPU他にダメージが行ってなければいいが。

久々にCVS HEADをコンパイルしようと思ったら、
configureでSTLを上手く認識できず失敗。

バグレポートしたものの、環境の問題ではないかとの返事。

VIneSeedのgcc-3.2.3-0vl2なんだが、本当にgccが悪いのだろうか。
それとも、gccの変化にconfigureがついて行ってないのか。

さて、どう対処しようかな。

Qtを3.1から3.2beta1に変更してみる。
フォント周りが変ったかな。
Webを見ていると、例のフォント間隔が増大する現象がなくなったようだ。
Qtを入れ替えただけで同じページで確認したので間違いではない。

その他の細かいチェックはまだ。
ちなみに、素のQt-3.2beta1には問題がいろいろあるようなので、
使う場合にはqt-copyがお勧め。

Qt-3.2beta1のリリースやKDE Trafficで取り上げられたKDE-3.2のスケジュールの話題、続々とkdelibsに追加されるclass群など、話題としてはそこそこあるんだけど、きっちり読んで書くまでの余裕はなし。

5月の初めから、KDE自体のビルドもやってないんだよなぁ…。