やる気がないときは一切やらないのに、いったんハマると抜けられないな。 折り返しやEUC関連の修正と変更は、手作業でばかりやっていたわけではない。 数万の文字についてそれが何語だとか記号だとか、変換先がどこだとか、 人間様が手作業で分類してたら気が遠くなるわけで、 既に他人によって分類されたデータを利用しやすいように編集するという作業は、 それ専用にプログラムを書いてやらせたりとかしているわけだ。 プログラムをプログラムに書かせるみたいな…続きを読む

偽パッドはエディタエンジン自体を自作したわけではなく、 OSについてくるリッチエディットをプレーンテキストモードで使い、 OS任せで描画したあとに、マークなどを加筆する形で動作している。 よって、偽パッドが折り返しでどんな処理をしているかは一切わからない。 メモ帳とかなり近い動作をしているわけだが、違う動作もいろいろあるわけで、 メモ帳ではロシア語のワードラップはしないが、リッチエディットはするらしい。 で、真魚は出来ればメモ帳準拠で行…続きを読む

以前も書いたように、より多くのテキストエディタと同じ仕様にすればスタンダードなのではなく、 よりユーザー数の多いソフトと同じ仕様にすればスタンダードである。 たとえWindowsの仕様が間違っていたり使いにくかったりしても、 Windows風にあわせてやればより多くの人が迷わずに使えるようになるわけで、 テキストエディタにおける動作のお手本は、まぎれもなくメモ帳である。 でも、メモ帳と同じにするわけにはいかない部分もあるよと言う話。 ま…続きを読む

Owned Window型の検索と置換のダイアログを用意し、 ダイアログ表示中も編集ウィンドウと行ったり来たり出来るようにしたのはいいが、 メモ帳と同様に、「次を検索」しても閉じない検索ダイアログが邪魔で仕方ない。 でもこれがメモ帳での正解なんだから、なじめない自分の体質の方が間違いであり、 ダイアログを閉じて検索するようなオプションはつけない事にする。 置換については、メモ帳の場合、確認しながら連続置換するっていう操作はなくて、 手動…続きを読む

検索ボックスを置くっていう事で腹は固まったのだが、 コレって既存のボタン数個分の横幅を取るため、 ツールバーを二本とも同じ段にしたりとかすると、はみ出る環境とか出てくるよな。 二段は邪魔だが一段だと長すぎとかってなると思うんだよ。 で、そういう人のためにツールバーの縦置きも出来るんだけど、 検索ボックスは縦置きに向いていないというか、横以外あり得ない。 一番良いのはツールバーをユーザーがカスタマイズ出来ることなんだけれど、 カスタマイズ…続きを読む

ブラウザにはGoogleツールバーって必須だと思うのね。 あたしがGoogleの検索しか使わないからなんだけど、他で検索する人はそれ用に、 ともかく、ブラウザにはアドレス入力の他に、検索のためのツールバーは必須。 それからタブも、次期IEではついてるらしいし、もうSDIの時代じゃないね。 最初の真魚v1.xxを作り始めたキッカケは、ブラウザで便利なタブをエディタにもって事だが、 SDIだと良いエディタがいっぱいあるのに、タブだと全然ない…続きを読む

メモ帳での画面表示色って、Windows全体の色設定にしたがうようになっている。 黒地に白で書くようなテーマにすると、メモ帳でもそれに従うようになる。 範囲選択された文字の色と背景も同様だ。 真魚の場合は、Windowsの設定がどうであっても、真魚の設定で動くようにしている。 でも、色設定の項目に範囲選択された文字色と背景色の設定がなく、 範囲選択部分はネガポジ反転で対応している。 白地に黒の文字なら範囲選択で黒地に白になるっていう感じ…続きを読む

JIS/EUC変換読み書き部分を作り直し、今まで対応してなかった文字に対応したので、 文字コード自動判定部分も、新たに対応した領域を使いたい。 jconvert.pasは結構古いものなので、 JIS、EUCを検出することは出来ても、UTF-8やUTF-7を自動判定することは出来ず、 真魚では、まずjconvert.pasの判定もして、 しかも自前で書いたUTF-7とUTF-8の判定をもするという形をとっているわけだが、 全部まとめて1p…続きを読む

なんか文字コードに躍起になっているが、もともと萌ディタの開発日記が発端である。 http://www.geocities.co.jp/SiliconValley-Oakland/3617/progress_2004Q2.html EUCはSJISにない文字も扱える仕様に変更済み。 次にJISなんだが、そこに書いてあるようにいろいろあるわけだが、 読み込みについてはどんな実装をするか悩まずに出来た。 EUC変換のために作ったテーブルを使っ…続きを読む

EUCへの対応については、補助漢字領域の拡張を目的に進めてきた。 すなわち、旧来のSJIS変換を行うとEUCにしかない文字が失われてしまうので、 SJISを介さずにEUC＜-＞ユニコード変換を行うように仕様変更だ。 それはもうできあがったからそれで良い。 次にJISへの対応をどうするかという話だ。 JISは多くの拡張がなされているため、全てに対応すれば中韓国語も扱えるはずだ。 だが、中韓国語拡張したJIS文字コードはどこで利用されるのか…続きを読む

自体はどんどん複雑化する。 ユニコードの私用領域であるU+E000辺り以降が、SJISやJISへ変換出来ると言うことを、 ATOKの文字パレットで確認したが、JISの規格では使われていない、 0x7F21から0x927Eまでが割り当てられているようだ。 EUCでは、JISでの0x2121～0x7E7Eに0x8080を加えた、0xA1A1～0xFEFEを使っているので、 規格をはみ出して私用領域を割り当てようとすると桁があふれてしまうのだ…続きを読む

JISX0212の補助漢字領域の資料が正しいかどうかはわからないが、 JISX0208の第一水準、第二水準漢字領域については、 資料には不備が多すぎて使い物にならなかったと言うことで、 CP50220を使って、OSにJISX0208領域を実際に変換させてテーブルを作成させた。 そしたら、CP20932を使ったときと同様、それと同じ文字で問題があった。 これも、SJIS経由での変換とは多少違った物を作ってしまった。 いや、多少かどうかは知…続きを読む

二つの方法がダメになった。 ○SJISを経由すると補助漢字が失われる。 ○CP20932でもうまくいかない。 で、最後の方法として、 ○アプリが変換テーブルをもつ。 コレをやるにあたり、 http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/ にあるテキストファイルを使用した。 矩形選択と正規表現置換で、完璧にDelphiコードに変換できた。 そして実際に正しい変換が出…続きを読む

まとめると、EUCをWindowsで扱う方法は三つ。 ○SJISに変換する。 SJISにはない補助漢字領域の文字は全て破棄する事になる。 ○EUC＜-＞UTF16変換テーブルをアプリ内で持つ。 一番やりたいのはこれだが作業がつらい。 ○CP20932を使ってWindowsにやらせる。 本来のEUCでは補助漢字領域を3バイトで表すが、CP20932は2バイトで表す。 この2バイトと3バイトの相互変換が実に簡単な事がわかった。 CP2093…続きを読む

日本語文字コードって、WindowsではSJIS、UnixではEUCということだが、 インターネットが普及したおかげで、EUCをWindowsで扱う機会も増えてきたということだが、 EUCにはあってSJISにはない文字っていうのもあるってことを、萌ディタの開発日記で知った。 旧来のSJISのテキストエディタでは、SJISにない文字なんだから編集出来なくて当たり前で、 ”EUC対応”って書いていても特定の文字は変換できなくて切り捨ててきた…続きを読む