連日、何をやっているのかわかりにくいと思うから、今やってることをまとめておく。 FontForgeでフォント編集すると、いったん独自データにコンバートされるせいで、 読み込んだフォントをそのまま書き出すことは不可能であり、 ほんの一箇所の数字だけ変えたいだけでも、他に余計なところまで勝手に変更されるという事で、 現在、そのピンポイント変更用のソフトを作ってる。 で、今のところ、OS/2テーブルを読み込むところまで来たのだが、書き込みはま…続きを読む

とにかく既存のフォントエディタでは自由にならないことを自由にしたいだけなのだが、 既存のフォントエディタで加工した後に、気にくわないところだけちょこっといじりたいということで、 まずはフォントファイルの仕様みたいな物を探して読んでたら、目は疲れるし腰は痛いし、 健康上の理由でそういうツールは作れないという結末が見えてきた。 正直なところ最近は、フォントの仕様が英語で書かれた物を読むより、 フォントを扱うDelphi製ソフトのソースがあっ…続きを読む

JISにもESC$(Dで補助漢字領域が使えるようなので、読み込み部分で対応した。 これで、EUCもJISも旧来の変換では切り捨てていた多くの文字に対応した事になる。 もちろんJISの書き出しはメーラー互換を前提にするので、補助漢字の書き出しはしない。 JISで使えないはずの規格外4文字が半角カタカナ周辺にあり、これも書き出さないことにした。 JISの変換はやはりSJISを経由にし、新たにテーブルを設けることはしなかった。 さてここで、ま…続きを読む

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

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

ようやく満足のいくEUC対応ができあがったようだ。 が、乗りかかった船なのでもうちょっと調べている。 http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html これのEUC-JPとShift_JISのところに、ちょっと納得いくことが書いてあった。 ＞いずれを使うかは、使う人の自由にまかされます。 なるほどな。 DelphiアプリでのEUC変換は、jconvert.…続きを読む

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…続きを読む

今、真魚でプロポーショナルフォント対応のために内部の深いところをいじっているわけで、 ここを変更したら連鎖的にアッチもコッチも変更しなきゃいけなかったりするような場所だから、 当然あちこちでバグが出るわけで、その動作確認をするにはやはり文章を書いてみるしかない。 で、何を書くかなって事になると、ソースコード自体はDelphiのIDEで書いているわけで、 DelphiのプログラミングをDelphi以外のエディタでやろうとは思ったこともない…続きを読む

そもそもWindowsの世界の進化がそれほど速くないのに、 開発ツールだけバージョンアップしすぎなんだよな。 特に、.NETについては昔のVBと一緒で、開発者には楽でもユーザーには不快なもので、 遊び程度の小物を作るには便利だが、徹底的にやろうとするとまだまだだ。 そんな.NETにあまりお金はかけたくない。 Delphiについては、C++部分にいまさら魅力は感じないから今回はパス。 Delphi2006のDM来た VSについては、価格発…続きを読む

あまーい！ブラジルのお菓子よりも甘いよー！ と、言われるほどブラジルは甘いものが甘すぎるのだが、そんなブラジルの甘いものの話。 去年ブラジルに行ったとき、どこに行っても湯水のようにコーヒーを飲めたわけで、 そのテーブルには必ず二種類の砂糖が置いてあった。 うちのヨメはコーヒーに砂糖なんか入れないので、全然気にもしてないが、 あたしは両方試してみて、その一方がやたらと旨い事に気がついた。 シュラスコなんて肉ばっかりで、いくら肉好きでも飽き…続きを読む

今回はC++Builderの統合が目玉になるようだ。 C++Builderは以前使ったことがあり、あまり良いイメージを持っていない。 Delphiのビジュアル開発をC++でもやろうというコンセプトの商品らしいが、 部品はPascal、プロジェクトはC++で書くと言うことで、 もし部品の作成を行わないなら、C++しか書きたくない人には良い製品になるだろう。 だが、例えば真魚は既存の部品を並べるだけで作ることに限界を感じ、 エディタコンポー…続きを読む

真魚は正規表現検索を既存コンポのちょい改造したものに頼っていて、 正規表現以外の検索はもっとも単純な順番に照合していく方法を用いている。 その単純な検索をあえて別ユニットにしてあるわけだが、 これは将来的に検索の王道といわれるBM法に置き換えることを想定しての物。 あたしがやらなくても、ソースを利用したい人がそこだけBM法に置き換えてもいい。 誰かがBM法を書いて、怠けているあたしに貢献してくれることも期待した。 それをそろそろ実装しよ…続きを読む