Created attachment 63182 [details] Konsole with the Clean font Version: unspecified (using Devel) OS: FreeBSD I'm using Konsole from git and qt from the 4.8 branch. I _think_ this started when I switched from qt 4.7 to 4.8. Depending on the font I use (especially non-TTF ones), they get chopped off (as if each character was supposed to fit in a small square but didn't). I have attached screenshots of a few fonts (such as Montecarlo, Clean, Fixed and Profont). If that matters, I have anti-aliasing disabled in Konsole. Reproducible: Always Steps to Reproduce: - (Possibly) Use qt 4.8. - Select a non-ttf font in Konsole. - Type 'p' or 'j' and notice how the characters are not displayed correctly. Expected Results: - The characters are shown correctly.
Created attachment 63183 [details] Konsole with the Fixed (Sony) font
Created attachment 63184 [details] Konsole with the Montecarlo font
Created attachment 63185 [details] Konsole with ProggySquareTTSZ This is actually a TTF font.
Does Konsole use QFontMetrics::height() or QFontMetrics::lineSpacing()?
I have noticed that at least on my system, changing font hinting from "slight" to "full" in System Settings work-arounds the issue (at the expense of reduced font quality if properly TTF hinted fonts are installed).
To answer Cristoph: by digging a bit into the source, I found use of at least QFontMetrics:height() (TerminalDisplay.cpp, line 213). I didn't have time to look more in detail.
(In reply to comment #5) > I have noticed that at least on my system, changing font hinting from "slight" > to "full" in System Settings work-arounds the issue (at the expense of reduced > font quality if properly TTF hinted fonts are installed). Hmm, I tried changing the "hintstyle" option in my ~/.fonts.conf to "hintfull", but it didn't have any effect.
One recent commit by Christoph should have fixed this problem(at least for me). See https://git.reviewboard.kde.org/r/102899/ for more info.
Does changing the bi-di rendering in konsole's setting helps, like I described in bug 284848 ?
My commit should only affect horizontal metrics, but this bug is about vertical clipping.
I'm however unable to see the problem again since a few couple of days (updated both Qt and KDE).
*** Bug 284881 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Does changing the bi-di rendering in konsole's setting helps, like I described > in bug 284848 ? I do not use the "Misc Console" font, but enabling BiDi does eliminate the problem with the "Fixed Sony" font in comment #1 and "Terminus" font in bug #284881(including the floating cursor problem) for me.
On a second look, the commit also affects the vertical metrics handling. If the actual metrics is "15.7 pixels", then QFontMetrics::height() will round that down to "15 pixels" causing the cropped appearance because the rendered pixmap will be 16 pixels tall. Fixed in master with http://commits.kde.org/konsole/de5ef9484a253795002d0e6accc86cc3cb1b5c71
Ok, but it certainly doesn't fix bug 284848, so that has another cause in that case.
Well, after observing how "Terminus" and "Fixed (Sony)" are rendered before and after that commit by Christoph, it seems that commit actually does not influence this problem or fix it. The results are the same: chopped when Bi-Di is disabled, while OK when Bi-Di is enabled. I haven't repeated that observation on other mentioned fonts which I do not have. Can someone confirm my observation? If that is the case, then this report is actually the same as bug 284848.
The patch in comment 14 does not fix the problem with the Terminus font: it still chops off the bottoms of letters like q and g.
I can confirm that enabling Bi-Di in the profile fixes the issue with all the issues I have reported (comment #14 indeed does not have any effect).
[quoted from bug 284848] Using Misc Console as Konsole's font, the fonts seems to be shifted down and the last line is not rendered. This happens with Qt 4.8, but not with 4.7 and only when Bi-di rendering is disabled in the konsole profile. See https://bugreports.qt.nokia.com/browse/QTBUG-22270 . I tried to reproduce with a simple const QChar LTR_OVERRIDE_CHAR( 0x202D ); p.drawText( r, 0, LTR_OVERRIDE_CHAR + text); in a QWidget's paint event, but could not, probably Konsole does something else as well.
*** Bug 284848 has been marked as a duplicate of this bug. ***
Of course I also tried to reproduce with a Qt test app, but couldn't :( Even printed out all QFontMetrics data with Qt 4.8/4.7 using that font and got the same output. And I can't find any other code in Konsole that is affected by the bidi rendering, just the addition of that control character.
Enabling Bi-Di doesn't help with Terminus font - especially cursor highlight problem is still there. KDE 4.7.3.
(In reply to comment #22) > Enabling Bi-Di doesn't help with Terminus font - especially cursor highlight > problem is still there. KDE 4.7.3. I don't understand what you mean by cursor highlight problem. Terminus + Bi-Di looks OK here with master and Qt 4.8.
I can confirm that "Enabling Bi-Directional text rendering" fixes the issue for the Terminus font, but doesn't for the Monaco TTF font. Arch Linux. Qt 4.8.0 here.
(In reply to comment #24) > I can confirm that "Enabling Bi-Directional text rendering" fixes the issue for > the Terminus font, but doesn't for the Monaco TTF font. > > Arch Linux. Qt 4.8.0 here. Forgot it. Seems to work in kopete 4.7.90
Worked like a charm enabling bi-di rendering in Arch Linux. How about set it standard ? It was a bit of a hassle to find this bug report actually as one can hardly describe the issue ...
Enabling bi-di is just a workaround, and thus enabling it by default not a real solution. Besides, at least on my system, enabling bi-di causes a noticeable rendering performance hit.
Non-integer metrics were introduced in Qt 4.7, not 4.8, so this is probably not the problem, especially since setting ForceIntegerMetrics does not help.
Created attachment 67173 [details] konsole-text-ypos.patch I'm attaching a patch that fixes this (it's against 4.7.4). It's trivial; it just sets the Qt::AlignBottom flag when calling drawText().
and should that same flag be set in the _bidiEnabled case too? If not, why not?
(In reply to comment #30) > and should that same flag be set in the _bidiEnabled case too? If not, why > not? I can be applied. It just doesn't seem to change the result. As to why, I don't know; didn't look to deep. Could be a bug in Qt, since I don't see why drawing the 0x202D character (LTR_OVERRIDE_CHAR) should affect text alignment.
(In reply to comment #29) > Created an attachment (id=67173) [details] > konsole-text-ypos.patch > > I'm attaching a patch that fixes this (it's against 4.7.4). It's trivial; it > just sets the Qt::AlignBottom flag when calling drawText(). Thanks, works for me!
(In reply to comment #29) > Created an attachment (id=67173) [details] > konsole-text-ypos.patch This patch doesn't appear to be in 4.8rc2. Is there someone who can commit it?
I can confirm the patch from comment #29 works as advertised (with several confirmations from others as well).
interesting side-effect, testing with terminus, that I see some characters get chopped at the top, ones like ~ and ^
Followup, seems to only happen using terminus @ 11pt
The other workaround is to set _lineSpacing to 1, which I prefer, because it exactly restores the line height on my system. The freetype shipped with Qt 4.8 seems to sometimes makes fonts smaller, see also bug 279490.
It doesn't look like I'm going to get a system w/ Qt4.8 + the above fonts installed by the tagging day. Jekyll, have you happened to look at this issue?
So, Christoph, pardon my ignorance, but it is unclear to me how your suggestion to set _lineSpacing to 1 translates into something I can test. Will that require patching the code too, or is it some configuration option?
This is what I use: diff --git a/src/TerminalDisplay.cpp b/src/TerminalDisplay.cpp index da2fb38..351afc4 100644 --- a/src/TerminalDisplay.cpp +++ b/src/TerminalDisplay.cpp @@ -304,7 +304,7 @@ TerminalDisplay::TerminalDisplay(QWidget* parent) , _resizeTimer(0) , _flowControlWarningEnabled(false) , _outputSuspendedLabel(0) - , _lineSpacing(0) + , _lineSpacing(1) , _colorsInverted(false) , _blendColor(qRgba(0, 0, 0, 0xff)) , _filterChain(new TerminalImageFilterChain())
Thanks! OK, I can confirm that a combination of setting Qt::AlignBottom fixes the descender problem and setting _lineSpacing(1) fixes the ascender case.
Git commit 47f504785f1855e0dbe81197ed1b5496ca641a0f by Kurt Hindenburg. Committed on 04/02/2012 at 22:21. Pushed by hindenburg into branch 'master'. A quick fix to get fonts to look OK w/ Qt4.8 and bidi off Hopefully a temp fix for this issue. It would be better to find out what happened with Qt4.8 font rendering. Thanks to people on bug report for research and info. M +9 -1 src/TerminalDisplay.cpp M +8 -0 src/TerminalDisplay.h http://commits.kde.org/konsole/47f504785f1855e0dbe81197ed1b5496ca641a0f
Git commit bf3e57e94b54c1c4337d7960e0fda0ef98156451 by Kurt Hindenburg. Committed on 31/03/2012 at 02:55. Pushed by hindenburg into branch 'KDE/4.8'. A quick fix to get fonts to look OK w/ Qt4.8 and bidi off Hopefully a temp fix for this issue. It would be better to find out what happened with Qt4.8 font rendering. Thanks to people on bug report for research and info. M +11 -3 src/TerminalDisplay.cpp M +11 -1 src/TerminalDisplay.h http://commits.kde.org/konsole/bf3e57e94b54c1c4337d7960e0fda0ef98156451
FYI, Nokia closed the upstream bug report https://bugreports.qt-project.org/browse/QTBUG-22270 because of lack of feedback(I didn't have time to make a Qt only test case).
> --- Comment #43 from Kurt V. Hindenburg <kurt.hindenburg@gmail.com> --- > Git commit bf3e57e94b54c1c4337d7960e0fda0ef98156451 by Kurt Hindenburg. > Committed on 31/03/2012 at 02:55. Applying the patch on konsole-4.7.4 (debian unstable) i can report it makes the konsole usable again with pcf fonts, but still the rendering has a wrong idea about the font metric. Visually guessing, two extra pixels are added to the ascent. In undecorated fullscreen mode, i get $ stty size 66 239 while on the linux console with the same resolution i have # stty size 75 240 Note that this is (basically) the same font (console8x16.pcf.gz and the linux console font) having an 8/16 geometry, meaning 9 lines and one columns are lost. # fbset mode "1920x1200" geometry 1920 1200 1920 1200 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode Thus 1200/16=75 and 1920/8 = 240. The konsole underestimates the size of the screen due to an older glitch in the size calculation perhaps not taking the frame into account, so it would "normally" (i.e. without the current problem) show $ stty size 74 239 Thus (1200-1)/(16+2) gives 66.61.. confirming my visual guess. Please let me know if i can help along further. -lars > --- Comment #43 from Kurt V. Hindenburg <kurt.hindenburg@gmail.com> --- > Git commit bf3e57e94b54c1c4337d7960e0fda0ef98156451 by Kurt Hindenburg. > Committed on 31/03/2012 at 02:55. > Pushed by hindenburg into branch 'KDE/4.8'. > > A quick fix to get fonts to look OK w/ Qt4.8 and bidi off
Created attachment 80835 [details] Screenshot from KDE 4.10.90 When I updated KDE from 4.10.4 to 4.10.80 (and now 4.10.90), I get some characters that are chopped again. Attaching screenshot. Doesn't happen all the time and not on all text lines. Should I open a new bug about this, or can this be considered the same issue as this bug?
The Qt4 version of Konsole is no longer maintained. This issue could be fixed in the master branch, see bug 371687. Please followup there.