請問行高的修正是如何進行的

[Binjohn]

行高修正真的解決掉我一個非常頭痛的問題！不過因為微軟正黑體和其他思源黑體的衍生字型也都有行高問題，最近想要自己修正看看，所以想來請教一下。

我用fontforge比較過思源黑體和源樣黑體後，只知道OS/2 Metrics裡的Win/HHead Ascent和Win/HHead Descent有縮減過。請問：

1. 還有其他地方應該注意的嗎？
2. 這個值該如何決定呢？

謝謝大大持續更新！

[ButTaiwan]

影響Word行高最重要的應該是OS/2裡的Win Decent。
不過這個值改到太小，在舊版Word又可能有字符超界被切斷的風險。
之前是改了好幾個值實驗到哪個數值為止在Word還不至於變兩行高。

但這次實驗發現值抓太緊，有時候橫排時行高正常，直排時又變兩行寬了。
實在很麻煩，所以值有在調比之前的版本更小一點。
現在有點擔心舊版Word是否pqy下方會被切斷。

--
Illustrator行高則主要是OpenType CFF表裡的FontBBox值在影響，
不過TrueType格式釋出時應該已經沒有FontBBox了。

目前的版本在Photoshop游標顯示的行高還是很高，Illustrator稍短，
我也還不太確定是哪些值在影響....。

[Binjohn]

原來有這麼多問題……

我有看到大陸人在改FontBBox，不過因為我只有用Word，所以就沒研究了。
請問你納入測試範圍的Word有到多舊啊？我自己是覺得測到2007甚至2010就已經很夠了。

我原本想說，是不是要用函式庫找出整個Unicode範圍裡面，頂到最上和最下界的字元是誰？
不然我很難理解，為什麼設計者沒事要把Ascent和Decent設到那麼大？
台灣微軟不可能不知道他的字型的行高設定根本和Word的格線設計自我矛盾吧？
都過了這麼多年還是不修正，有夠詭異。

[KrasnayaPloshchad]

剛剛發現一篇文章提及思源黑體的這個行高問題，下方的討論認為這個 FontBBox 是通過生成 Type 1 檔的時候由軟體自動計算取得的，而且是 Adobe 有意為之，甚至還有提議把 LineGap 設定為 0 的。
https://zhuanlan.zhihu.com/p/19887102
另外個人覺得在保證「〱、〲」能正常顯示的前提下，兩行漢字之間至少要有 1en 的距離。

[ButTaiwan]

我原本想說，是不是要用函式庫找出整個Unicode範圍裡面，頂到最上和最下界的字元是誰？ 不然我很難理解，為什麼設計者沒事要把Ascent和Decent設到那麼大？

思源有收三倍長 em-dash，因為還有收直排版本。所以 ascent + descent 高達 3000。
就算是源樣拿掉三倍長版本，但因為留下兩倍長的，理論上仍然還有 2000。
另外如樓上所說，日文有 https://zi-hi.com/sp/uni/3031 這個符號，它的高度也是 2000。
當然因為直排字符去影響正常的橫排高度不太合理，所以源樣採用竄改 win descent 跟 FontBBox 的作法。

--
基本上這就是字型的技術債。
ascent / descent 本來應該只是 typography 上的抽象高度，用來描述理想的行高、x-height等相對位置。
就像 macOS 內建的 Zapfino 字型，ascent / descent 都侵略性地直接重疊到上下行，但這正式傳統歐文書法的風格。

然而 Windows 舊的渲染引擎卻拿 win descent 值當作渲染時的裁切邊界。完全不容許兩行發生重疊（甚至中間還被強制留一些行間）。