レイアウト座標を半角単位桁数に戻したい

[ghost]

やりたいこと(=実現したいこと)

サクラエディタ内部で扱うドキュメント上の座標単位を半角単位桁と行の組み合わせに戻したい

やりたい理由

1. 現状のピクセル単位は、その値がフォント設定の影響を受けるため、環境依存となってしまう。
2. フォント設定と文字・行の間隔を CLayoutMgr と CTextMetrics 双方で処理しなくてはならない。
   • 適用した間隔や文字幅を取得するメソッドも双方にあり、冗長に見えます。
3. レイアウト作成フローなど、処理の途中でピクセル単位を半角単位桁に換算する必要が発生する。
   • これを忘れることは (sf1034)プロポーショナル版で禁則処理がおかしい問題の修正 #1410 のような不具合の原因となります。
4. レイアウト作成フローが DLLSHAREDATA に依存してしまう。
   • 改行のレイアウト幅を 1px とする仕様により、改行コード拡張機能の設定値が必要です。
5. 位置や座標に関するマクロは、相当する機能を呼び出して処理を行っているため、内部単位の変更がマクロに破壊的な影響を与えている。
   • v.2.2.0.1 までの動作に基づいて作成された位置や座標を扱うマクロは、特定の実装以外は v.2.3.0.0 以降動作しません。
   • これによるバグが マクロ関数の選択開始桁と選択終了桁で取得できる数値が桁数でない #326 として報告されています。

解決手段の提案

• 文字のレイアウト幅を以前と同様に CNativeW::GetKetaOfChar で計算します。
  • CNativeW の静的メンバである GetHabaOfChar 及び GetColmOfChar は不要になります。
    • 文字幅計算の際に DLLSHAREDATA を参照しなくてよくなります。
  • タブ文字やインデントはタイプ別の設定値から適切な桁数を計算してレイアウトに加えます。
• 文字と行の間隔は CTextMetrics だけで処理します。
  • 設定された間隔やピクセル単位の文字幅は CTextMetrics のメソッドで取得できます。
  • ピクセル単位とレイアウト単位の換算機能は CTextMetrics で提供されています。
• 当時動作が変更されたマクロ関数を元に戻し、新たにピクセル単位座標を返す関数を追加します。

事前に検討する必要があるもの

• 内部単位の再定義に伴う取り扱いを検討する

  • 参考案

    データ型	基底	X方向の単位	相当する用語
    CLogicXInt	CStrinctInteger	wchar_t単位（文字単位）	ロジック位置（文字位置）・文字数
    CLogicYInt	CStrinctInteger	wchar_t単位（文字単位）	ロジック位置（行位置）・行数
    CLogicPoint	SLogicPoint	wchar_t単位（文字単位）	ロジック座標
    CLogicRange	CRangeBase	wchar_t単位（文字単位）	ロジック選択範囲（2地点座標）
    CLogicRect	CStrictRect	wchar_t単位（文字単位）	ロジック矩形範囲（4地点座標）
    CLayoutXInt	CStrinctInteger	半角単位	レイアウト位置（桁位置）・桁数
    CLayoutYInt	CStrinctInteger	半角単位	レイアウト位置（行位置）・行数
    CLayoutPoint	SLayoutPoint	半角単位	レイアウト座標
    CLayoutRange	CRangeBase	半角単位	レイアウト選択範囲（2地点座標）
    CLayoutRect	CStrictRect	半角単位	レイアウト矩形範囲（4地点座標）
    CPixelXInt	int	ピクセル単位	X方向の描画位置・描画幅
    CPixelYInt	int	ピクセル単位	Y方向の描画位置・描画高さ

• 矩形選択を等幅フォントに限定するかを検討する

  • 限定しない場合は、 USE_UNFIXED_FONT ビルドオプションといくつかの共通設定項目が不要となります。

• 単位換算機能の提供方法を検討する

  • CLayoutMgr 以外にこの機能を提供するクラスとして CViewCalc があり、 CLayoutMgr とは依存関係にあります。
  • CEditView は CViewCalc を継承していますが、これらに「 is-a 関係」は成立しないように思えます。
    

    sakura/sakura_core/view/CEditView.h

    Lines 117 to 118 in 062cda8

    	class CEditView
    	: public CViewCalc //$$ これが親クラスである必要は無いが、このクラスのメソッド呼び出しが多いので、暫定的に親クラスとする。

• 半角1桁あたりピクセル幅の計算方法を検討する

  • 以前は「 xx 」の幅を全角とし、その半分を半角としていましたが、現在はアルファベットの文字幅から算出された平均値を半角としています（この半角単位をルーラー桁単位と言います）。
    ゆえに半角文字の幅が全角の幅の1/2より広くデザインされた等幅フォントでは、半角2桁と全角文字の幅が一致しません（ OSDNより転載：等幅フォントを使用した時、1バイト文字２文字と２バイト文字１文字の文字幅が一致しない。 #1250 として報告済み）。
    

    sakura/sakura_core/view/CTextMetrics.cpp

    Lines 52 to 57 in 062cda8

    	auto hFontOld = (HFONT)::SelectObject( hdc, hFont );
    	SIZE sz;
    	GetTextExtentPoint32(hdc, L"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", 52, &sz);
    	::SelectObject( hdc, hFontOld );
    	m_nCharWidth = (sz.cx / 26 + 1) / 2;

関連情報

• patchunicode#587 文字幅取得マクロの追加
  • fbd65a6 プロポーショナルフォント対応の準備のため、CKetaXInt・CHabaXIntの各単位を追加
    （ CHabaXInt は 66f5d68 まで使用されていませんでした。）
• patchunicode#713 プロポーショナルフォント
  • 変更点の説明
    「レイアウト座標が桁からピクセルに変更された」ものの、そうした理由は説明されていません。
  • 66f5d68
  • 7247748 桁数表示のオプション化 : patchunicode#1004
  • 7ce12cc 文字の間隔の適用値が今までと異なる : patchunicode#1003
  • 8d65af4
  • 8d6fbe0
  • ec204b6 タブ幅がフォントサイズが大きいと4固定になる : patchunicode#1078
  • 8b307ef
    • patchunicode#1014 文字間隔に 1以上の値を設定すると改行がうまく扱えなくなる
    • replace: patchunicode#1110 空行を削除できない
  • patchunicode 1006 と 1047 の取り込み #738
    • patchunicode#1006 改行文字部分とそれより後ろのキャレット移動に関して
    • patchunicode#1047 プロポーショナル版で変更された単語単位移動を戻す
  • プロポーショナル版で禁則処理を使えるようにする #1543
    • (sf1034)プロポーショナル版で禁則処理がおかしい問題の修正 #1410 プロポーショナル版で禁則処理がおかしい問題の修正
      replace: patchunicode#1034

[berryzplus]

文字幅をpx単位で管理してはアカン理由を考察するのに参考とできる挿絵のあるドキュメントを紹介しときます。
https://docs.microsoft.com/en-us/windows/win32/directwrite/glyphs-and-glyph-runs#glyph-metrics

日本語フォントの余白定義はここまで細かくないですが、フォントグリフってのは本来こういうクソ細かいパラメータを持っていることを理解しておいて損はないと思います。（具体的に「だからどーよ。」というのは要らんです。）

[ghost]

ピクセル単位にもう一つ問題点があることに気が付きました。
#1543 (comment)

余談ですが、MSゴシックでも絵文字の文字幅が全角・半角のどちらでもないということに気が付きました。

MS ゴシックには絵文字は収録されていないはずですので、フォントフォールバックで絵文字の所だけ Segoe UI Symbol あたりが使われていそうですね。
🗻 (U+1F5FB) など全角よりも広くなる文字もあるようです。

フォントフォールバックなどによって文字幅が異なるフォントが混在した場合、1桁あたりピクセル値も複数存在することになるので、桁換算して処理を行っている箇所では結果に影響がありそうです。

[berryzplus]

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
とか
ＷＷＷＷＷＷＷＷＷ
とかの表示をどうすべきか、
本当はちゃんと考えたほうが良いんでしょうね。

[ghost]

| CLogicXInt | CStrinctInteger | wchar_t単位（文字単位） | ロジック位置（文字位置）・文字数 |
| CLogicYInt | CStrinctInteger | wchar_t単位（文字単位） | ロジック位置（行位置）・行数 |
| CLayoutXInt | CStrinctInteger | 半角単位 | レイアウト位置（桁位置）・桁数 |
| CLayoutYInt | CStrinctInteger | 半角単位 | レイアウト位置（行位置）・行数 |
| CPixelXInt | int | ピクセル単位 | X方向の描画位置・描画幅 |
| CPixelYInt | int | ピクセル単位 | Y方向の描画位置・描画高さ |

縦方向と横方向をデータ型で区別した場合、「この数値は文字数なので～XIntで宣言してください」といったレビュー指摘をしないといけないので、レビュワーの負担が増えそうですね。
（ #1655 を見てて思いました。）

[ghost]

issue とはあまり関係ないですが、空白記号描画（ CFigure_HanSpace ）もプロポーショナルフォント対応で問題を抱えてしまったみたいです。

半角空白の記号が下半分に英小文字の「 o 」、上半分に空白を使用した合成文字になっていて、それぞれのピクセル単位文字幅が異なるかもしれません。
（全角空白は「全角空白と記号に使う文字の幅が違う場合は独自に描画する」という方法を取るので問題ないです。）

[berryzplus]

縦方向と横方向をデータ型で区別した場合、「この数値は文字数なので～XIntで宣言してください」といったレビュー指摘をしないといけないので、レビュワーの負担が増えそうですね。

意味があるかどうか微妙なんですけど、POINT_TYPEやRECT_TYPEにテンプレートクラスを使えば型の誤りを「コンパイルエラー」にできます。

template<typename POINT_TYPE>
class 点を表す型 : public POINT_TYPE {
  using X_TYPE = decltype(POINT_TYPE::x);
  using Y_TYPE = decltype(POINT_TYPE::y);
public:
  void SetX(X_TYPE);
  void SetY(Y_TYPE);
};

どちらかというと、行・桁の組み合わせを「点」と表現していることも問題な気がします。
行・桁の組み合わせは一般的に「ロケーション」と表現することが多いっす。

class CLocation {
    uint32_t row = 0; //!< 文章先頭からのオフセット行。値域＝[0, INT_MAX]
    uint32_t column = 0; //!< 行頭からのオフセット位置。WORD単位。値域＝[0, INT_MAX]
};

そういえばx64対応の目標って、4GBを「超える」ファイルを開けるようにする でしたが、なんかそれは違うような気がしてきている、という話をどこにも書いたことがなかったような。

[berryzplus]

半角空白の記号が下半分に英小文字の「 o 」、上半分に空白を使用した合成文字になっていて、それぞれのピクセル単位文字幅が異なるかもしれません。

たぶん文字幅は問題ないと思います。
横方向、文字幅には「半角小文字o」を使うので、大き過ぎたり小さ過ぎたりはしないんでないかと思います。
縦方向、上半分を背景色で塗りつぶす仕様に関して、フォントにより上半分の位置がおかしくなる懸念があります。

Unicodeには、もともとそれっぽい形で定義された文字があるので、それを使うことが対策になるかもしれません。
（この方式だと、選択したフォントにその字形が収録されてるかどうかが課題になるです。）

[ghost]

忘れないようにメモしておきます：

• 対応を行ってCLayoutMgrのタブ幅計算処理を変更した場合、タブ記号描画（CFigure）における描画幅計算処理を見直すこと。

[ghost]

違った。