◀Unicode版開発トップへ
  • 2282 プロポーショナル版の変更点について
    • 2283 Re:プロポーショナル版の変更点について
      • 2284 Re2:プロポーショナル版の変更点について
        • 2285 Re3:プロポーショナル版の変更点について
          • 2286 Re4:プロポーショナル版の変更点について
            • 2287 Re5:プロポーショナル版の変更点について
              • 2288 Re6:プロポーショナル版の変更点について
                • 2289 Re7:プロポーショナル版の変更点について
                  • 2293 Re8:プロポーショナル版の変更点について
    • 2294 Re:プロポーショナル版の変更点について
      • 2295 Re2:プロポーショナル版の変更点について
        • 2296 Re3:プロポーショナル版の変更点について
          • 2297 Re4:プロポーショナル版の変更点について
  • [2282] プロポーショナル版の変更点について もか 2015年09月20日 23:34

    ■ステータスバーの桁数ですべての文字が1桁扱いになります。
    いままではTAB=タブ幅,全角=2桁,半角1桁(=以降旧桁数)扱いでした。
    ■GetSelectColmFrom,GetSelectColmTo
    の各値がpx単位になります。いままでは旧桁数と同じ値でした。
    ■LineColumnToIndex,LineIndexToColumn,MoveCursorLayout,GetStrLayoutLength,SetViewLeft,GetViewColumn
    レイアウト桁がpx数になります。今までは旧桁数でした。
    ■GetDefaultCharLength
    ルーラー1文字分の幅が返ります。この幅はA~Za~zの幅の平均値px数です。
    折り返し桁数やタブ幅はこの幅を基準に計算されます。今までは1でした。
    等幅フォントの場合GetStrLayoutLength/GetDefaultCharLengthで旧桁数とほぼ同等の値を取得することができます。
    ■左右移動の改行以降の移動がpx単位の移動になります。
    いままでは1文字幅単位でした。
    ■単語の左端に移動で改行以降の移動がルーラーの1文字分移動になります。
    いままでは改行位置に移動していました。
    ■単語の右端に移動はルーラー1文字分右移動でいままでと変わりません。
    ■改行コードは内部幅は1px扱いで表示だけ1ルーラー文字分+4pxになっています。
    改行コードを表示しない場合は表示幅は2pxです。
    いままでは内部1文字幅表示2文字幅(旧バージョン・反転選択では表示1文字幅)でした
    ■TAB幅の計算は、最低でもルーラー1文字幅分以上の隙間が確保される状態での次のタブ位置までです。
    最大で1文字幅-1px+タブ幅分確保されるので最大値は以前より約1文字分大きくなります。
    ■等幅フォントの場合であっても以前は幅が固定されていたコードポイントがありましたが、
    コントロールコードを除くすべての文字がフォントを基準に可変長になります。
    また最低幅は1px以上なのでUnicodeの0幅文字でも1px幅の文字として扱われて
    等幅フォントであったとしても文字幅が1px単位でずれることがあります。
    • [2283] Re:プロポーショナル版の変更点について syat 2015年09月20日 23:53

      ▼ もかさん
      > ■ステータスバーの桁数ですべての文字が1桁扱いになります。
      > いままではTAB=タブ幅,全角=2桁,半角1桁(=以降旧桁数)扱いでした。

      これはちょっとリリースはストップですね。ご指摘ありがとうございました。
      プロポーショナル修正をコミットしてしまったので戻した状態で再チャレンジします。

      • [2284] Re2:プロポーショナル版の変更点について もか 2015年09月21日 02:40

        やっぱだめかな?(判断はお任せします)
        桁表示にcol(px数をルーラー幅で整数割りした物)を使うとプロポーショナルフォントでガタガタになるので、
        そうなるのなら計算コストの一番安いCLogicInt+1で表示するようにしようと考えてました。
        これは$xとかタグジャンプの桁表示と同じものです。
        メモ帳はじめほとんどのエディタ・開発環境は1文字で1つづ表示するのが今は主流みたいですし。
        今までの実装はすごく長い行の後ろ側で1文字づつの修正を繰り返すような動作のときに顕著に重いです。
        表示上のタブを中途半端に含めた桁数が知りたいときはルーラーを見ればある程度は分かるかなと。
        なお矩形選択時は、colとpxが表示されます。
        昔のように正確でない表示もどうかと思いますし、かといって無意味に重いのもどうかと思います。
         もしいままでと同じような値にしたい場合は、タブ幅を含め文字幅固定で計算してやる必要があります。
        折り返し単位で表示のときも、今までは低コストで表示するだけでしたが1レイアウト行分計算が必要になります。
        レイアウト行の行頭インデントがある場合は1行目のインデント分を固定文字幅で先に計算しておく必要もありそうです。
        そういえばCNativeW::GetKetaOfCharはサロゲートペアに固定で2を返す等の理由により、厳密には実際の表示幅と同じになりません。
        もうちょっと改造が必要かもしれないです。
        TabToSpace/SpaceToTabに似たような処理がありますが、こちらはサロゲートペアにそもそも未対応のようです。
        色々な人の意見も聞いてみたいですがあんまり人いないんですよね。
        • [2285] Re3:プロポーショナル版の変更点について もか 2015年09月21日 03:22

          色々書いたけどF_GETSTRWIDTHをコピペだけである程度いい気がしてきた
          • [2286] Re4:プロポーショナル版の変更点について syat 2015年09月21日 23:20

            ▼ もかさん
            パッチとして整合性とれてるからいけるかな、と思ったのですが、既存の動きから大きく変わってしまうのは躊躇してしまいます。
            内部の計算はプロポーショナル版のでよいので、マクロ関数と桁数表示のような外部と接する部分に旧Verとの互換性を持たせられるとよいと思いました。
            • [2287] Re5:プロポーショナル版の変更点について もか 2015年09月22日 01:01

              ▼ syatさん
              > パッチとして整合性とれてるからいけるかな、と思ったのですが、既存の動きから大きく変わってしまうのは躊躇してしまいます。
              > 内部の計算はプロポーショナル版のでよいので、マクロ関数と桁数表示のような外部と接する部分に旧Verとの互換性を持たせられるとよいと思いました。
              全角だから2とか決め打ちせずLogicLayout変換関数群をちゃんと使ってあるマクロは互換性があります。
              例えばこれ
              http://sakura.qp.land.to/?Macro%2F%C5%EA%B9%C6%2F222
              あとはSimpleCmdの切り取り・貼り付けコマンドとかです。
              既存マクロ関数を等幅専用にされると既存マクロのプロポーショナル対応(作者が意図的でないのも含む)で書かれたものが等幅フォントを選ばないとちゃんと動かないものになります。
              もっとも互換性があるように書いた人が私以外にいるかどうかはあやしいところです。
              あとマクロのヘルプでSetViewLeft,GetViewColumns等でプロポーショナル対応の記述が既にあります。
              ANSI->Unicodeのときも座標系の相違はすでにあり特に目立った混乱も観測していないので影響は限定的かなという印象です。
              AUのときは罫線マクロとURLエンコードマクロが動かないなどの例はありました(PPAは除く)。
              0.0.1バージョン上げで切り替えるにはちょっと乱暴だとは正直思いました。
              • [2288] Re6:プロポーショナル版の変更点について syat 2015年09月24日 21:38

                プロポーショナル対応の動きを整理しますと、
                ・旧レイアウト桁・・・半角1、全角2の桁
                ・新レイアウト桁・・・ピクセル単位のx座標
                ・新ルーラー桁・・・半角文字の平均幅を1桁とする
                として、

                【論理桁(変化なし)】
                ExpandParameter('$x')

                【旧レイアウト桁→論理桁】
                ステータスバーの桁

                【旧レイアウト(変化なし)】
                GetStrWidth()

                【旧レイアウト桁→新レイアウト桁】
                GetSelectColmFrom()、GetSelectColmTo()、GetStrLayoutLength()、GetViewColumns()

                【旧レイアウト桁→新ルーラー桁】
                ルーラー、右端折り返し、タブ、指定桁縦線

                みたいになっています。レイアウト座標が桁からピクセルに変更されたと考えれば全体的に辻褄があっています。

                一案ですが、ステータスバーの桁とマクロ関数が返す桁は、ピクセル座標をルーラー桁幅で割り算したものを返せば、等幅フォントを使う人には互換性が保たれて良いんじゃないでしょうか?
                レイアウト~ロジックの正確な計算をするにはピクセル座標が必須なので、GetSelectColmFrom2()などでピクセル座標を返せるようにするとか。
                個人的には、マクロ関数はどっちでもよいですが、ステータスバーの桁は変わらないでくれるとありがたいです。
                • [2289] Re7:プロポーショナル版の変更点について もか 2015年09月25日 01:51

                  >【旧レイアウト桁→論理桁】
                  >ステータスバーの桁、GetStrWidth()
                  GetStrWidthは旧レイアウト桁のままです。

                  >一案ですが、ステータスバーの桁とマクロ関数が返す桁は、ピクセル座標をルーラー桁幅で割り算したものを返せば、等幅フォントを使う人には互換性が保たれて良いんじゃないでしょうか?
                  ステータスバーの桁についてプロポーショナルの時もその表示にするんですか?
                  ABCとかは1桁進んでWとかは2桁進んで.とかでは桁は増えないみたいな動きになり実質無意味な値が表示されるようになりますけど。
                  >個人的には、マクロ関数はどっちでもよいですが、ステータスバーの桁は変わらないでくれるとありがたいです。
                  等幅版と変わらない感じに表示するものをweeklyの下のところにアップしておきました(パッチ付き)。
                  M案1は、改行単位のときは旧レイアウト互換計算、折り返し単位のときは新ルーラー桁で表示します。
                  M案2は、改行単位のときも新ルーラー桁(折り返しインデント抜き)で表示します。
                  以前はあった行が長い時のキャッシュはとりあえずなので復活させてません。
                  用途とか好みの都合だから選択できるようにすりゃあいいんじゃないかという気もしますが。
                  マクロのほうは意見保留。
                  • [2293] Re8:プロポーショナル版の変更点について syat 2015年09月30日 01:06

                    ▼ もかさん
                    > GetStrWidthは旧レイアウト桁のままです。
                    そうでしたね。修正しました。


                    > 等幅版と変わらない感じに表示するものをweeklyの下のところにアップしておきました(パッチ付き)。
                    > M案1は、改行単位のときは旧レイアウト互換計算、折り返し単位のときは新ルーラー桁で表示します。
                    > M案2は、改行単位のときも新ルーラー桁(折り返しインデント抜き)で表示します。
                    M案2のほうが私のイメージでした。
                    M案2か物理桁かのオプションがあると良いかもしれません。
                    M案1はあまりいらないかな。プロポーショナルでは全角半角あまり気にしない気がします。


                    > マクロのほうは意見保留。
                    GetSelectColmFrom()、GetSelectColmTo()、GetStrLayoutLength()、GetViewColumns() は、プロポーショナル対応にともない仕様が変わったってことで、このままで良いんじゃないでしょうか。
    • [2294] Re:プロポーショナル版の変更点について もか 2015年09月30日 03:57

      すっかり忘れていた変更点
      文字の間隔が半角1:全角2だったのが、文字毎に1になったので
      等幅フォントで文字の間隔を設定すると全角と半角の混ざった表示が等幅じゃなくなる
      これはすっかり忘れてた暫定仕様だった。
      直すのは結構大変
      • [2295] Re2:プロポーショナル版の変更点について syat 2015年09月30日 21:55

        ▼ もかさん
        > 直すのは結構大変

        等幅の互換性を優先して、全角文字だったら2倍にするのは難しいでしょうか?
        CTextMetirics.cppとCMemoryIterator.hを直せばいけそうな気がするのですが。
        • [2296] Re3:プロポーショナル版の変更点について もか 2015年10月01日 01:24

          ▼ syatさん
          > 等幅の互換性を優先して、全角文字だったら2倍にするのは難しいでしょうか?
          > CTextMetirics.cppとCMemoryIterator.hを直せばいけそうな気がするのですが。
          大変かと思っていたのですがそうでもなかったです。
          その2つとCLayoutMgr::GetLayoutXOfCharを直せばだいたいいけました。
          →patchunicode:1003
          関連バグ2件をパッチに含んでいます。(状況によってパッチから分離して適用してください)
          修正・適用はご自由にどうぞ。

          プロポーショナル的にはCSSのletter-spacingプロパティと同じ挙動のほうが
          見た目が良いような気もしますが私はいつも0にしているのでどういうのが正解かいまいちわかりません。

          それともう1点、ASCII以外の半角文字(半角カナ等)で印刷に使われるフォントが
          全角から半角のものに変更になっています。
          フォントサイズ指定が幅から高さに変更になっているので場合によっては今までと
          微妙に文字の大きさが異なるかもしれません。
          • [2297] Re4:プロポーショナル版の変更点について もか 2015年10月07日 00:23

            中ボタンによるマウススクロールで、左右移動が等幅版と比べて遅いみたいです。
            等幅版3文字分移動、PP版3px移動になってる気がする。
            他にもまだあるかも。うむむ