Repository navigation
Combining accents not rendered correctly #400
Description
I have reported the issue described below to the mailing list some time ago, but didn't get any feedback. I am still experiencing this in MacVim 8.0 (111) under macOS 10.12.1.
With the Core Text renderer on, combining accents are not rendered correctly (the height of diacritical marks does not adapt to the height of the associated glyph), no matter whether “Draw marked text inline” is checked or not. Try, for example, ė̃ (U+0303 with U+0117). Such combinations are displayed correctly in terminal Vim (both in Terminal.app and iTerm2) using the same fonts (I have tried with Menlo, Consolas, and SF Mono).
Text is rendered correctly when Core Text is turned off.
Activity
andlabs commentedon Jan 21, 2017
How do the following render for you? I'm not a MacVim developer but I'm pretty sure this is something with Core Text and not with MacVim specifically, because I'm seeing similar issues in my own code with
A̪︠
and
💻̀
being rendered differently between Core Text and the Cocoa text system. (In the former, the baseline is not adjusted to give room for the upper accent, so it (and by extension the bounds of the line) collides with any descenders in the previous line; in the latter, the accent is positioned above the glyph in TextEdit.app (though the selection highlight does not fully consume it) but collides with it to the side in Core Text.)
lifepillar commentedon Jan 22, 2017
The same for me. MacVim with the Core Text renderer off renders those glyphs correctly, as in TextEdit. It's only when Core Text renderer is on that I get overlapping diacriticals.
So, I have turned it off now.
andlabs commentedon Feb 3, 2017
Looking at it again, I think the problem is Core Text might not be using combining characters for line height calculations, even if a different font is used just for the combining mark? But from what I can tell Core Text uses every CTRun for line height calculation, not just the ones that start graphemes... Needs more investigation. Not sure if it can be fixed without discarding CTFrameDraw() and doing manual line placement...
andlabs commentedon Feb 3, 2017
Actually wait no there's only one run in that accented A string wtf
andlabs commentedon Feb 3, 2017
[18:00:45] <andlabs> my guess now is that Core Text does not respect the GPOS table while deciding line heights, since it just uses ascent + descent + leading
[18:01:02] <andlabs> but isn't the font bounding box supposed to contain glyphs with their GPOS extents?
[18:01:21] <andlabs> and that doesn't explain why shoving an accent on an emoji produces different results, not just a different vertical position
[18:03:21] <andlabs> http://stackoverflow.com/questions/41857213/is-there-any-way-i-can-get-precise-metrics-line-ascent-line-descent-etc-of if I could get an answer on this I wouldn't need to use Core Text heh
[18:05:59] <andlabs> of course that won't solve #400 so in that case I'd have to aks how to get core text ot look the same as cocoa, if anyone has figured that out
andlabs commentedon Feb 5, 2017
2017-02-05 14:01:29.226 macarialnogpostest[43533:24448181] 100 100 -> 15.9428
2017-02-05 14:01:29.229 macarialnogpostest[43533:24448181] 130 100 -> 15.91
okay somehow with GPOS etched out the bounding rect is actually TALLER, so I have no idea
I do have a feeling AppKit doesn't use GPOS; I'd have to check how the one on the left looks against AppKit... and then that leaves the question of what AppKit does use
andlabs commentedon Feb 5, 2017
Okay no I was wrong; TextEdit.app does use GPOS and renders that properly, and also has the same font height line height issue after all! I guess AppKit renders properly then; either that or TextEdit does its own thing that I have to check...
💻̀ is still rendered differently, though. I wonder what's going on there.
andlabs commentedon May 3, 2018
Will check this again (as well as the PR) at some point in the future. Thanks again!