[3428] Unicode版の行方　
▽ 2003/10/21 (火) 00:47:45 もか
INCM1.23a
技術評価レベルでまだ実用段階でなない状態ですが、Unicode版を先日からHPで公開しています。
興味のある方は、お試しください。
上書きインストールはできないので注意してください。

　そのUnicode版ですが、結局どうしようか困っています。
サクラエディタプロジェクトとしては、どのような方針で進めたいのか皆様のご意見をお願いします。
* 1. ANSI版/Unicode版の関係について
1A. ソースコードのみ統合できるようにして、ANSI版Unicode版の両方を公開してしく
1B. ソース自体は統合せず、Unicode版は別系統で開発・公開をする
1C. プロジェクトとしては当面Unicode化しない=Unicode版は出さない

* 2. Unicode化の目的と実装水準
1Cならここで話し合う必要はまったく無いのですが、試作品では単純に
2A. SJISに含まれる文字は今までと同じように編集できる
2B. SJISに含まれないUnicode固有文字は保持できる
という水準です。
それ以上の水準で実装するのかどうかというのが焦点です。

* 3. 正規表現
これも結構問題です。
・ライセンスの問題が解決できる
・バイナリデータが使える
・行先頭の問題が解決できる
・場合によってはSJIS(コードページ)/Unicode両対応
・できれば複数行の問題も解決できる
・できればWin64でも動く
#そんなのあるのか？
[3431] Re: Unicode版の行方　
▽ 2003/10/21 (火) 02:10:39 げんた
INCM1.23c
>　そのUnicode版ですが、結局どうしようか困っています。
_UNICODEを定義していればAPIのWIDE版を呼びだすことになると思いますが，そうするとWin98系のサポートがなんか危うくなるような気がするのですが．うまく両方に対応できれば良いのでしょうけど．

>* 1. ANSI版/Unicode版の関係について
>1A. ソースコードのみ統合できるようにして、ANSI版Unicode版の両方を公開してしく
>1B. ソース自体は統合せず、Unicode版は別系統で開発・公開をする
>1C. プロジェクトとしては当面Unicode化しない=Unicode版は出さない
1Bは煩雑になるので避けたいです．

>* 2. Unicode化の目的と実装水準
>2B. SJISに含まれないUnicode固有文字は保持できる
ということは編集はできない？
いまいちよくわからないのですけど．

>* 3. 正規表現
おにぐるま？
boost?
[3436] Re2: Unicode版の行方　
▽ 2003/10/21 (火) 21:16:28 みく
INCM1.23a

>そうするとWin98系のサポートがなんか危うくなるような気がするのですが．

Win98系のために、ANSI版を残すという捕らえ方もできるかと...


>>* 1. ANSI版/Unicode版の関係について
>>1A. ソースコードのみ統合できるようにして、ANSI版Unicode版の両方を公開してしく
>>1B. ソース自体は統合せず、Unicode版は別系統で開発・公開をする
>>1C. プロジェクトとしては当面Unicode化しない=Unicode版は出さない
>1Bは煩雑になるので避けたいです．

やっぱり1Aでしょうか。
とりあえず、「ANSI版でのコンパイルが正常」な状態を保ちつつTCHAR化(WIDE化)を進めていく
というのが現実的かな。


>>* 3. 正規表現
>おにぐるま？
>boost?

結論：ANSI版=SJISとWIDE版=UTF16の両方をサポートしているライブラリがないので、
同じ正規表現ライブラリは使えません。
と、私は認識していますので、CBregexp周りを大幅に書き直す必要があるかと思います。
（POSIXはバイナリを扱えないので問題外）

oniguruma: ASCII,SJIS,EUC,UTF8
boost: ASCII,UTF16
pcre: ASCII,UTF8
JRE32: SJIS
BREGEXP: SJIS

＃onigurumaあたりをUTF16対応させるか...
[3438] Re2: Unicode版の行方　
▽ 2003/10/21 (火) 23:16:02 もか
INCM1.23a

* 1. ANSI版/Unicode版の関係について
>1Bは煩雑になるので避けたいです．
>とりあえず、「ANSI版でのコンパイルが正常」な状態を保ちつつTCHAR化(WIDE化)を進めていく
>というのが現実的かな。
統合できる状態にもっていけるのかが、勝負です。
ちなみに、ANSI版と書いたのはAPIではなく行データ(CDocLineのCMemoryとか)のことでして、
ANSI版の利点は、少メモリ、少スペース、SJISファイルやバイナリの親和性、他にも色々。
最悪の場合、ANSI版、Unicode版(WinNT系用)、API-ANSI/内部データ-Unicode版(Win9x用)の3種類できますね。
(あ、64bit版もあった)
将来的に、ANSI版を廃止するのかどうかも気になるところです。2010年頃か..

* 3. 正規表現
>結論：ANSI版=SJISとWIDE版=UTF16の両方をサポートしているライブラリがないので、
>同じ正規表現ライブラリは使えません。
>＃onigurumaあたりをUTF16対応させるか...
BREGEXPのlinux用ソースをUTF-16対応させて、DLLを作ろうかとも思いましたが、
それなら機能面やbregexpは無限ループするとか考えると、
みくさんの言うようにonigurumaをUTF-16化したほうが良いですよね。

* 4. UnicodeとWin9x
>>そうするとWin98系のサポートがなんか危うくなるような気がするのですが．
>Win98系のために、ANSI版を残すという捕らえ方もできるかと...
4つ目の問題としておきます。
MSLUやExtTextOutWでサポートできるものの、機能制限はやっぱりあります。
実際にやってみないと分からないので、MSLUを使った試作品を作ってみます。
ダイアログなどの標準ウィンドウクラスがUnicode未サポートだったような。

#ついでに書いておきますが、Unicode化とUIの多言語化は別問題ですので、英語版とかの話は別でお願いします。
[3491] Re3: Unicode版の行方　
▽ 2003/11/14 (金) 21:02:04 みく
INCM1.23a

>* 1. ANSI版/Unicode版の関係について
>とりあえず、「ANSI版でのコンパイルが正常」な状態を保ちつつTCHAR化(WIDE化)を進めていく
>というのが現実的かな。

分岐させるにしても、共通の修正としてやっておくべきことがあるということです。


>* 3. 正規表現
>みくさんの言うようにonigurumaをUTF-16化したほうが良いですよね。

ちょっと見てみましたが、無理っぽいですね。
ちゃんと文字コード別に1文字分処理しているところもあれば、そうでないところもある。
1バイト文字ならどの文字コードも同じという前提で動作しているっぽい。

巷の内部UNICODE版エディタって、どうしてるんでしょうかねぇ。
[3439] Re2: Unicode版の行方　
▽ 2003/10/21 (火) 23:16:20 もか
INCM1.23a
サイズオーバのため分割。
>>2B. SJISに含まれないUnicode固有文字は保持できる
>ということは編集はできない？
>いまいちよくわからないのですけど．
すみません、ちょいと説明します。
とりあえず、日本語を使っている分にはほとんど支障がありません。
アラビア系は入力できても文字が本来の並びとは逆向きに並ぶので使い物にはなりません。
あと、合成文字とかも表示が分かれてしまうので、本来とは違う表示になってしまいます。
Unicodeには、前の文字と一つになって表示する「合成可能」な文字があります。
日本語(JIS X 0123に含まれる文字をUnicodeで使うときに必要)だと半濁点、濁点が該当します。
例えば、U+304B U+3099は「が」と表示されるべきものが、「か゛」となるわけです。
「が」ならすでに合成済みの「が(U+304c)」というものがあるのでましですけど、
かの鼻濁音の「か゜（U+304b U+309a）」だと駄目です。
しかも本来は、この「合成済み文字」と「合成して表現する文字」は等価であるため、
検索でどちらも同じようにヒットするべきです。
ついでに、文字幅が0という文字もありますが、試作品では現状1文字分占領するはずです。
この種の文字を使う人は、サクラエディタではスペースが入って読みにくいのではないかと。
さらに、IMEが入っている日本ではそれほど問題ではありませんが、Unicode文字をコードポイントで入力する機能がないと大変です。(RichText3.0にはその機能があり、Alt+テンキー入力で可能だったと思う)

まとめると、データは保持できるが、編集が困難な文字があり、表示が変な文字もあるという状態です。
そういう文字をまともに扱えるような機能をサポートすると1A(ソース統合)しにくくなり、泥沼に...
この辺は全部サポートしないけど勘弁してほしいというのが私の個人的な意見。
[3557] Sakura-Editor Unicode版 Ver1.4.3.1 V/W への要望 2つ　
▽ 2003/12/16 (火) 21:04:30 ASSA
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
こんばんわ。 始めまして。
私は 定年退職した 62歳の男性です。

▼もかさんの [3428]Unicode版の行方 で
Sakura-Editor Unicode版(Ver1.4.3.1 V/W)を知りました。
さっそくTestしてみました。
Testの結果 とりあえずご要望を2つ書きこませていただきます。

サクラエディタ Unicode版 2003/10/15 Moca
を拝見したところ Fontについては
次のようのに書かれていました。
>■Unicodeとフォントの制限
>Unicodeの機能（文字・制御文字）のサポート状況です。
>・プロポーショナルフォント
>未サポートです。
>強制的に指定すると表示することはできるかもしれません。
>ただし、その場合も、等角で表示されます。
>・文字の表示幅
>各文字の表示幅の決定は、コードポイントから直接決定しています。
>現在は、フォントや言語の設定（ローケル）にかかわらず固定です。
>・合成文字
>すべて未サポートです。それぞれ別の字として扱われるはずです。

[要望 1]
プロポーショナルフォントのうちで 少なくとも
Tahoma
TimesNewRoman を
設定できる/画面表示できるように ぜひ 改良してください。

とくに Tahomaは Win2k/XPでは 特別な扱いで
Tahomaには含まれていない
漢字/かな/カナ/IPA発音記号/CombiningDiacriticalMarks
などなど が 表示できるような しくみが くみこまれています。

[要望 2]
Unicodeの合成文字が 正しく表示できるように改良してください。

『Tilde付の小文字q』のUnicode流の書き方
q(U+0071)+(その右隣に)CombiningTilde(U+0303)などは
Ver1.4.3.1 V/W では 適切なFontを選べないので
画面表示できません。
現実には 適切なFontが選べないので
Testもできない状況です。
(Ziro Editor Ver 0.119βでは 上の2点は 実現しています。)

上の2点の改良を ぜひ お願いいたします。

例: Unicode Ver4.0(Draft)にも含まれていない
『Tilde付の小文字q』を Unicode流の書き方
先にq(U+0071)を入力する
ついで(その右隣に)CombiningTilde(U+0303)を
入力することになります。

これは[3439]
>Re2: Unicode版の行方
の中にある
>前の文字と一つになって表示する「合成可能」な文字
の1例です。

今まで 使った実績やTestした範囲では

上の2点をClearしていて かつ
TahomaとTimesNewRomanで
「合成可能」な文字が 正しく画面表示されるのは

Ziro Editor Ver 0.119β(2001/05/25)
  開発者のHomePageがなくなってしまっていて
  開発はとまっています。
EmEditor Pro J Ver 4.00β16
Word 2002

画面表示が乱れるのは

OpenOffice1.1.0ja　Write
CombiningDiacriticalMarkを入力すると
次の(その右隣の)文字との間が2文字分くらい広がる
（TimesNewRoman Ver 3.00/Win2k SP4)

秀丸Editor Ver 4.0.3
CombiningDiacriticalMarkを入力すると
前の(その左隣の)文字の右側が
CombiningDiacriticalMarkの幅だけ見えなくなる
その状態でCombiningDiacriticalMarkだけは
画面に表示される(Tahoma Ver 3.05/Win2k SP4)

POWER Mac G4も使っています(Mac OS X Ver 10.2.8)ので
Unicodeのほうが ぐあいがいいのです。

正直なところ Win95/98/98SE/Meには
もう まったく関心ありませんし
使う気持もありません。
[3563] Re: Unicode版 1.4.3.1 V/W への要望 2つ　
▽ 2003/12/18 (木) 00:54:26 もか
INCM1.23a
始めに、テストありがとうございます。
▼ASSAさん
>[要望 1]
>プロポーショナルフォントのうちで 少なくとも
>Tahoma
>TimesNewRoman を
>設定できる/画面表示できるように ぜひ 改良してください。
sakura.iniに直接指定すれば使えなくも無いですが、大変なので、選択できるようにします。
表示のほうは、正確な文字幅での表示は実装の都合上、かなり難しいです。
で、現状では、@とかMなどの右端が欠けます。
タイプ別設定 - 文字の間隔 を広げれば回避できますが、かなり読みにくくなります。
しかも、合成文字の表示は不可能です。
>[要望 2]
>Unicodeの合成文字が 正しく表示できるように改良してください。
色々な都合上、実現できていません。
現段階ではアルファベット + 合成文字1つ 程度なら、何とかなるかもしれません。
INCM/CMT
Cyclamen v3.81