謝謝你的建議. 我原本有想要再看一下Regluar的正黑體, 因為懶惰, 就算了.

如果現在還能找到十幾年前的FontForge執行檔, 只要打開一看就可以證明. 我當年看過, 那時FF會顯示一條右邊的邊界線, "碧"這個字的右邊界線就被畫在4096, 而其他正常的字則被畫在2048. 因為我親眼見過, 而且修改成2048後把字型覆蓋回去, 就沒問題了. 所以我能肯定是字型的問題, 不需要再猜測. 可惜我現在頂多只能在GITHUB上找到2014年的執行檔.

我前面也說了, 這個問題和應用程式是否用rightbearing的數值來計算字寛有關, 微軟的記事本是老程式, 一直沒改, 它在計算regular和BOLD的字寬是否用同一套運算方式, 我不知道. 依我猜想, 如果Regular 正黑體的right bearing和BOLD一樣, 那有可能是記事本在套用REGULAR和BOLD字體時, 計算字寛的方式不同, 在REGULAR字體時就用right bearing的最小值, BOLD字體則用rightbearing的最大值.

總之, 我還是堅持這個問題是字型本身的問題. 只是要證明它需要一些合適的字型編輯工具, 偏偏這是個老問題, 而現在已經找不到當初的工具程式了. 反正我現在沒法證明它, 有人要質疑或提出不同的觀點也是個人自由, 我沒意見.

SourceForge上有2012年, 可能還有更早的, 我找時間試試.

補兩張擷圖, 是用2023年版的FontForge開啟Windows 7 的正黑體 msjh.ttf (版本6.02) 和 msjhbd.ttf (版本6.00), 同一個"碧"字, 邊界線不同. Bold的邊界線被畫3920的位置, Regular的邊界線則被畫在2048.

https://ibb.co/xmR9YrQ
https://ibb.co/zhXrRHK

先聲明, 那條邊界線不是我自己畫的, 是一開啟就有的, 不是我做弊畫出來的.

問題來了, 為何Windows 10的正黑體字型在FF上看不出來邊界線異常, 但記事本在顯示加粗"碧"字時右邊仍有多餘空白? 我也不知道. 重複我前面猜過的原因, 就是字型的問題修正不完全, 而記事本是老程式, 仍用舊的方式計算字距.

所以我前面就講過了，微軟修是修了，但修的不只是字型，
還包含了一些API等的底層軟體，但僅限於新的底層軟體，
而舊的就直接放生，所以還使用舊API的軟體就是會出問題。
這點可以很明確的在新舊版本的Notepad上看出差異。
要是你的Notepad還有這類問題，請上Microsoft Store下載新版。
不過新版Notepad也不一定會更好(更吃資源，而且還有別的問題出現)，
就自己斟酌吧。

咦
所以每一種字型的 bold 效果都是內含另一套 bold 字型副本嗎
我還以為是API可以把字型自動加粗?

你前面的回文裡好像沒說這麼多...

而且, 一樓樓主有提到Total Commander也有同樣的問題, 這點我也能確定, 因為我在Windows 10上用Total Commander一樣有同樣的問題, 這就不是單純新舊NOTEPAD的問題了.

至於微軟到底修正了什麼, NOTEPAD的原始碼又看不到, 只能憑程式設計的理論用猜的. 我光是要提出證據說明微軟正黑體確實有問題, 就花了好大功夫. NOTEPAD的程式碼到底有什麼問題, 有做了哪些修正, 除了微軟自己有能力提出證據, 其他人都只能用猜的, 根本拿不出證據.

我用NOTEPAD跟Notepad++測試

NOTEPAD 微軟正黑粗體 大小8~24 會多空白，大小26~72沒空白。

Notepad++ 偏好設定>其他 開啟"使用DirectWrite" 微軟正黑粗體「碧」「筵」「綰」沒空白。
關閉"使用DirectWrite" 「碧」「筵」「綰」會多空白。
舊版的正黑粗體不管有沒有使用DirectWrite，「碧」「筵」「綰」後面都有多餘的空白。

1. 前面已經說得夠多，您可能專注於問題就在字型上，對我提出的意見沒仔細思考而已。
2. Total Commander的問題代表它用的部份API(目前看來應該是老舊的GDI/GDI+)跟舊版Notepad一樣。
3. 樓上網兄的嘗試某程度已經證明我的推論。