https://bugs.documentfoundation.org/show_bug.cgi?id=85426
--- Comment #20 from Volga <[email protected]> --- Here I saw a comment oppugn the method to handle line height on MS Windows. https://github.com/ButTaiwan/genyog-font/issues/13#issuecomment-2251756173 This is his comment and my translation: 思源有收三倍長 em-dash，因為還有收直排版本。所以 ascent + descent 高達 3000。 Source Han Sans have three-em-dash, because it is also includes vertical version, so ascent + descent is up to 3000. 就算是源樣拿掉三倍長版本，但因為留下兩倍長的，理論上仍然還有 2000。 Even if GenYo Gothic removed three-em-dash, but due to two-em-dash is preserved, ideally it's still 2000. 另外如樓上所說，日文有 https://zi-hi.com/sp/uni/3031 這個符號，它的高度也是 2000。 In addition, as above comment, Japanese has the symbol 〱 (U+3031), it's height is also 2000. 當然因為直排字符去影響正常的橫排高度不太合理，所以源樣採用竄改 win descent 跟 FontBBox 的作法。 Certainly because it doesn't make sense to make vertical glyphs affect horizontal line height, so GenYo Gothic uses modifying win descent and FontBBox. 基本上這就是字型的技術債。 It's basically technical debt of the font. ascent / descent 本來應該只是 typography 上的抽象高度，用來描述理想的行高、x-height等相對位置。 Ascent/descent should be only abstract heights among typography that used to describe ideally relative position for line height or x-height. 就像 macOS 內建的 Zapfino 字型，ascent / descent 都侵略性地直接重疊到上下行，但這正式傳統歐文書法的風格。 Such as macOS built-in font Zapfino, both ascent/descent are just aggressively overlap neighboring lines, but this is traditional European caligraphy style. 然而 Windows 舊的渲染引擎卻拿 win descent 值當作渲染時的裁切邊界。完全不容許兩行發生重疊（甚至中間還被強制留一些行間）。 However Windows legacy rendering engine used win descent value as clipping boundry for rendering. Completely oppose two neighboring lines overlap each other (even forced leaves line gaps in the middle). So I think this should be fixed via integrating an independent library that makes LibreOffice jump out of system calls for glyph rendering. -- You are receiving this mail because: You are the assignee for the bug.
