Version: 2.3.2 (using KDE 4.3.2) OS: Linux Installed from: Fedora RPMs The further right I am in Konsole, the more out of alignment the cursor is. To reproduce, type in a long list of characters, such a "aaaaaaaaaaaaaaaaaaaaaaaaaa". Note how the cursor moves farther and farther out of alignment. I'm going to try and attach screen shots.
Created attachment 38536 [details] Cursor is far to the right of where it should be This shows how the cursor has moved to the right as I typed in a bunch of 'a's.
Created attachment 38537 [details] When I move to the left, the text on the right is also out of alignment When I move to the left, the text on the right is also out of alignment. Perhaps this is because the cursor is getting fatter the further to the right it is?
Which font are you using? (family, size, style)
I'm using Liberation Mono. This affects multiple font sizes, at least between 9 and 11pts. I tried Lucida Typewriter as well with similar results.
Font styles were plain for the above.
Confirmed on Arch. The cursor if off. Konsole is broken. Please raise the severity of this bug.
No, seriosly, the Konsole is a core system component. Not a plasma kind of stuff. I would recommend to raise it to "Critical".
Being dramatic will not help (in fact it tends to annoy developers). "Critical" is defined as "crashes, loss of data, severe memory leak". You are describing a graphical glitch that IMO doesn't count as even "major", and clearly is not "critical". Nor is Konsole "a core system component" to most people. What happens with a bitmap font? (Also... I suspect the problem here actually lies below Konsole, in Qt's font rendering, which may be a problem in Qt, or perhaps even in something below Qt.) And... it works for me (with Liberation Mono even, as well as Terminus which I normally use).
> Nor is Konsole "a core system component" to most people. A terminal is important to a lot of technical users. I agree that this is not 'critical' though because the number of reports/confirmations is small and it appears to relate to certain setups only (perhaps certain fonts, distributions, versions of libraries etc.). @Jonathan, khotyanovsky@mail.ru As I cannot reproduce this myself, I need you to experiment and see if you can track down what combinations of font/size or something else cause the problem.
Alright, I'll get on it. On Thu, Dec 24, 2009 at 10:58 AM, Robert Knight <robertknight@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=215937 > > > > > > --- Comment #9 from Robert Knight <robertknight gmail com> 2009-12-24 19:58:28 --- >> Nor is Konsole "a core system component" to most people. > > A terminal is important to a lot of technical users. I agree that this is not > 'critical' though because the number of reports/confirmations is small and it > appears to relate to certain setups only (perhaps certain fonts, distributions, > versions of libraries etc.). > > @Jonathan, khotyanovsky@mail.ru > > As I cannot reproduce this myself, I need you to experiment and see if you can > track down what combinations of font/size or something else cause the problem. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
OK, it affects various sizes of the Liberation Mono, sizes 10 through 7 or so. (Why didn't I try this before?) Other fonts are not affected. This is apparently a problem with the font or the font rendering system, and not Konsole. Is there additional information that may be useful, such as how the fonts are configured or what file, exactly, the font is?
It affects Monospace, FreeMono and Liberation Mono on my system. Andale Mono, Courier, Courier New, DejaVu Sans Mono are apparently unaffected. Matthew Woehlke, I agree it is not really that critical. I by no means wanted to annoy developers. I was just really mad trying to issue a long command on a remote server with pipelines, sed expressions, having no idea what character my cursor is positioned at. Sorry, if I was harsh.
I'm getting this bug using Terminus , size 12. Using KDE 4.4 RC2. This seems and important bug to me.
This problem was appearing in KDE 4.3 which came with Mandriva 2010.0 but it is also appearing in KDE 4.4 which is in Mandriva 2010.1a3. there is currently a bug listed on the Mandriva buglist as bug 57564 ( https://qa.mandriva.com/show_bug.cgi?id=57564 ). If you play around with the font sizes, you can make the problem appear and disappear, for example, the default install I had was "Fixed, font=12" but changing the font to 11 appeared to work okay. In the Mandriva bug, someone mentioned fractions of integers as a possible path to a problem or a solution... maybe something to look into????? I've also noticed that the slider bar is capable of choosing non-existing fonts, so this may also be something to look at (limiting the output of the slider bar to show only existing fonts allowed).. I'll attach a picture showing the slider bar with font=12.
Created attachment 42223 [details] konsole cursor bug (also shows slidebar and allowed font sizes) Picture is in grayscale to keep within attachment size limit, but you could see the cursor location as you move back into a line of text, for example if you typed... ls -l /usr/share/bin/ {cursor now 1 char further right than before} and then you begin to move your cursor back.... you see the shift. If you have trouble seeing this on your konsole, try to change font size.
To comment#14: AFAICS this bug doesn't exist in Mandriva 2010.0 at all, the bug surfaced after updating to fonts-ttf-liberation-1.05.2 in cooker, while 2010.0 has fonts-ttf-liberation-1.04 . In Mandriva Fixed is aliased via fontconfig to Liberation Mono, IIUC.
Robert do you have some infos about this bug ? i still experience it under kde 4.4.2 / qt 4.6.2
No, I'm afraid I haven't looked into it any further yet.
Robert, can you take a look here : https://qa.mandriva.com/show_bug.cgi?id=57564#c64 i don't know at all if this is a correct way to fix the bug. What do you think about this ?
Hi Nicolas, > Robert, can you take a look here : > https://qa.mandriva.com/show_bug.cgi?id=57564#c64 > i don't know at all if this is a correct way to fix the bug. As the author of the patch says, it is a proof-of-concept hack, it is not something that can be included upstream yet. One thing I can say regarding the last comment in that thread: > This should affect only konsole, and should be a better fix then > the other possible one that would be to draw character by character... Drawing a character at a time would probably be extremely slow.
I can confirm that font spacing problems are still present in konsole 2.4.3 under KDE 4.4.4, Fedora 13 distribution. They are very apparent using Liberation Mono 11pt. In particular, a string of 10 minus signs takes about the same screen width as 9 'x'-characters. The problems disappear with DejaVu Sans Mono 11pt. The problem does not affect gnome-terminal, which renders Liberation Mono 11pt correctly, as does OpenOffice. So the problem does seem to lie in konsole or in the rendering libraries that it uses.
(In reply to comment #21) > I can confirm that font spacing problems are still present in konsole 2.4.3 under KDE 4.4.4, Fedora 13 distribution. I tried Liberation Mono 11pt in KDE-4.7.0 but did not notice the problem. Maybe you should upgrade your distribution? 4.4.4 is a bit old. Or, maybe this is fontconfig related. I use slight hint.
This problem seems to have been fixed over the last year. I am now running Konsole 2.6.4 using KDE platform 4.6.5 under Fedora 15. I am happy to report that Liberation Mono 11pt now renders correctly and looks great!
Can confirm this is still here in 4.14.2, Debian Jessie.
I usually encounter this problem when my font preference for a bitmap font can not be fulfilled by the system, e.g. I prefer "terminus" and have this selected. If starting konsole on a system that does not have this font, the observed problem also appears for me. It looks konsole (or the X font component) is improperly replacing the missing font with some weird broken selection. Solution: Install the missing font OR select a different one.