[空白を表示]をONにすると、一部のフォントでキャレットの位置がズレる
sdottaka ご連絡ありがとうございます。
再現できず、しばらく悩んでいたのですが、HackGen-Regular.ttf だけインストールすると問題なく、HackGen-Bold.ttf もインストールすると問題が再現するようでした。
以下のような仮の対策を入れています。月末リリース予定のバージョンに反映される予定です。
https://github.com/WinMerge/winmerge/commit/49554697817164b30699cc18040b8c4b824ece16
WinMergeでは、日本語ターミナルソフトのように漢字等の全角文字を半角2文字分の幅で表示しています。 全角文字判定は、それぞれの文字のフォントの幅をGetCharWidth32() Win32APIを使用して取得し、半角文字の幅よりも1.5倍以上であれば、全角文字とみなすようにしています。
レンダリングモードがGDIの場合、フォントの幅を計算する際、フォントを太文字かつ斜体に設定しているのですが、HackGenフォントでは、 タブを表す文字(U+00BB)がなぜか全角相当の幅で取得されていました。(フォントを太文字かつ斜体でなければ半角相当の幅となっていました)
カレット位置を計算する際はタブを表す文字は半角幅とみなして計算しますが、実際に表示する際は、タブを表す文字を全角幅で表示するため、このずれが発生していました。
レンダリングモードをDirectWriteに変えると問題なかったのは、フォント幅を計算する際、フォントを太文字かつ斜体に設定しなければならなかったのですが、そうしておらず、タブを表す文字の幅が半角幅で取得できたためでした。
ちゃんと対応するには修正量が多すぎそうなため、強引ですが、タブを表す文字の幅は必ず半角幅とみなされるよう特別扱いするようにしています。
こんにちは、HackGenの作者です。 WinMerge、私もいつも利用させていただいています。メンテナンスご苦労さまです。（いつも使っているのに今まで気づけなかったんかい、というのは自分自身、不思議なのですが…）
太字の場合だけ、というのを見させていただいて、確認してみました。原因が分かりました。 HackGenの » (U+00BB) が、Regularでは半角幅、Boldでは全角幅になっていました。原因は、合成元の源柔ゴシックでの当該記号が、Regular/Boldでこの半角/全角の食い違いが起きているためでした。おそらく、源柔ゴシックでのバグなんだと思います。
RegularとBoldの同じ文字で半角/全角の幅を変えるということは、モノスペースフォントでは一般的には行わないでしょうから、この事象に遭遇することは相当に稀なことではありそうです。
sdottaka (匿名) への返信
太字の場合だけ、というのを見させていただいて、確認してみました。原因が分かりました。 HackGenの » (U+00BB) が、Regularでは半角幅、Boldでは全角幅になっていました。原因は、合成元の源柔ゴシックでの当該記号が、Regular/Boldでこの半角/全角の食い違いが起きているためでした。おそらく、源柔ゴシックでのバグなんだと思います。
ご確認ありがとうございます。源柔ゴシックからそうなっているのですね。 HackGen v2.6.2 で修正していただきましたが、源柔ゴシックや派生フォントも問題が発生するようですので、WinMergeの修正はそのままにしておこうと思います。
sdottaka 
Fork
フォントにHackGenを指定し、メニューの[表示] - [空白を表示]をONにすると、タブ文字を含んだ行のキャレットが誤った位置に表示されます。
イメージはこちらを参照してください。 https://github.com/yuru7/HackGen/issues/36#issue-1206618258
なお、[オプション(エディター > 一般)]でレンダリングモードをGDIからDirectWriteに変えると不具合は発生しませんでした。