Created attachment 102303 [details] glyph clipping due to too low lineheight; QtCurve I have been noticing cases where the lineheight was too low in Kate-based editors on OS X, and have just traced this to a regression in KTextEditor between 5.24.0 and 5.27.0 . It strikes reproducibly on the last line (when not terminated with a newline); see the screenshots. It happens only with the native CoreText font engine, not when using the FreeType engine (-platform cocoa:fontengine=freetype); the application style in use is of no importance. Reverting to KTextEditor 5.24.0 solves the issue.
Created attachment 102304 [details] glyph clipping in v5.2.7; Macintosh native style
Created attachment 102305 [details] no clipping with v5.24.0
We altered how lines are painted to actually avoid things like that (perhaps between that versions).
Hah, well, that misfired then, at least on OS X. I didn't check if 5.24.0 does worse with the FreeType font engine. This commit? 4c83bac52716a08a549dca50a76be8aa47c11ca3
Created attachment 102307 [details] touching lines with 5.27.0
Created attachment 102308 [details] better line spacing with 5.24.0
(In reply to RJVB from comment #4) > This commit? 4c83bac52716a08a549dca50a76be8aa47c11ca3 Clearly not only that commit. Reverting just that makes line spacing too generous (total text height increases by approx. 16%).
FWIW, this seems to work acceptably for me: ```C++ void KateRenderer::updateFontHeight() { // use height of font + round down, ensure we have at least one pixel // we round down to avoid artifacts: line height too large vs. qt background rendering of text attributes const qreal height = config()->fontMetrics().height(); #ifdef Q_OS_OSX m_fontHeight = qMax(1, qFloor(1.005f * height)); #else m_fontHeight = qMax(1, qFloor(height)); #endif } ```
Hmm, any idea why we need that adjust? Seems strange, given no problem on other operating systems.
What other OSes have you tried? I guess it must have something to do with the font engine, an observation that I think is supported by the fact that the adjustment isn't required when I use the Freetype font engine on OS X. Sadly the Freetype font engine isn't really ready for prime time on OS X; it doesn't appear to use FontConfig for one, and it requires the use of a commandline argument without any way the make it the default as far as I have seen. To what extent do you intervene in the standard Qt text rendering mechanisms, iow to what extent could this be considered a Qt bug?
What about this in ::updateFontHeight? - m_fontHeight = qMax(1, qFloor(height)); + m_fontHeight = qMax(1, qCeil(height)); Is this better?
Yes, that seems to have about the same effect as my tweak. `qCeil(1.005f * height)` is too much though (I tried that too, tuning down the extra space that was obtained in the original code).
I would be fine with changing that to ceil, floor is a bad idea, no clue why we/I did not use ceil :/
Did you compare the spacing with qCeil and qFloor on Linux and/or MS Windows? I find the line spacing just fine on Linux, and would regret it getting significantly more ample *). Maybe it can be tied to the hidpi setting, but when your screen is only 768 pixels high like mine I tend prefer a somewhat more compact layout than I might otherwise prefer. It just got too compact on OS X. *) using ceil instead of floor makes lines approx. 10% higher for me, iow 10 lines instead of 11 lines in the same vertical space with Ubuntu Mono 12pt.
> I would be fine with changing that to ceil, floor > is a bad idea, no clue why we/I did not use ceil :/ Interestingly, I wondered why you changed if from ceil to floor, but I trusted you enough that this was intentional :-) But then it's easy: back to qCeil() and that's it. Btw: The #ifdef is the worst solution of all, so this is a no-go in my opinion.
I'd say that the most important aspect here is that behaviour is as much the same as possible across platforms. In this case that would mean that they all have a sufficient line spacing, and that a same font size will give a number of lines per height unit that's as similar as possible. I was surprised to see the difference qCeil can make vs. qFloor in that latter aspect, so I hope you test this properly before making a decision. #ifdefs don't look very nice, but nice looking code isn't the goal here.
I think the issue with ceil was that you get space between lines that is not painted correctly. Perhaps we should just start to use float's for the height...
So we have not made any decisiton. Rene, any news?
What kind of news are you hoping for? I'm currently using the patch below with 5.29.0 on Mac and that works well enough. I should maybe try the patch on Linux too (not sure why I never did) because I do see glyph clipping for instance in KDevelop's "Find in Files" toolview.
The problem is we end up with ugly spacing between the lines if we ceil or scale, see bug 379727, we have them already in some cases :/ I guess we need to redo that rendering stuff :/// *** This bug has been marked as a duplicate of bug 379727 ***
I still use m_fontHeight = qMax(1, qCeil(height)); on Mac, stock code on Linux, and that's perfectly satisfactory to me. Maybe you should accept that there are subtle platform differences in font rendering that interact with how KTextEditor handles line-spacing and allow platform specific code here. FWIW, one would expect that difference to be due to using FreeType vs. CoreText (i.e. in QPA code) but strangely that does not appear to be the case. I build the XCB QPA plugin on Mac and don't notice any real differences running apps side-by-side in X11 (XQuartz) and Cocoa mode. I also cannot reproduce the transversal line glitch of #379727 under XQuartz, at least not as easily as described.
Could you try if https://phabricator.kde.org/D10145 improves that? It includes the qCeil you wanted + includes the font leading.