Bug 297390 - When wide characters appear on a line, Konsole cuts off half a letter
Summary: When wide characters appear on a line, Konsole cuts off half a letter
Status: RESOLVED DUPLICATE of bug 361547
Alias: None
Product: konsole
Classification: Applications
Component: font (show other bugs)
Version: 2.7.4
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
: 351380 (view as bug list)
Depends on:
Reported: 2012-04-03 13:52 UTC by Dotan Cohen
Modified: 2017-03-23 13:51 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Screenshot depicting issue. (6.17 KB, image/png)
2012-04-03 13:52 UTC, Dotan Cohen
A gif showing a large width character bug in Konsole (52.54 KB, image/gif)
2013-11-12 23:01 UTC, calvinh34
konsole russian issue (36.25 KB, image/png)
2014-08-25 16:35 UTC, Eugene
Screenshot showing where the letters are cut off (34.35 KB, image/png)
2015-08-17 09:51 UTC, Alexander Kowalski

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2012-04-03 13:52:53 UTC
Created attachment 70114 [details]
Screenshot depicting issue.

When a character wider than the monospace font is used in Konsole, the cursor appears to cover half of the last letter of the line. See attached screenshot. The top line of the screenshot is from root, which has the stock Bash prompt. The lower line is from my user, which has a wide non-ASCII character leading the prompt.

Note that this issue is not limited to only non-ASCII dingbats like that used in the screenshot. My own native language is not represented in ASCII either, and may be displayed using a font that is wider than the ASCII font used for ASCII.
Comment 1 Jekyll Wu 2012-04-03 14:06:48 UTC
Could you provide the Unicode code point for that leading symbol in the screenshot? like  U+4E2D for "中", U+305F for "た" ?  

Your screenshot might be another example of the problem tracked in bug 41744(a very old bug, I know)
Comment 2 Dotan Cohen 2012-04-03 15:29:11 UTC
Thank you, it is U+2708

It looks plausible that this is a case of bug 41744, but I am not knowledgeable enough to say for certain either way. However, certainly some of the last comments on that bug are conflated with this issue.
Comment 3 Jekyll Wu 2012-04-09 14:03:21 UTC
Thanks for the infomation. 

It truns out my previous guessing may be wrong. That symbol is defined as narrow(actually neutral)according to Unicode data[1][2]. However the screenshot shows that it is displayed as Wide, taking the width of two cells. I can reproduce the problem when using some fonts, while not when using other fonts. At the moment I'm not sure whether this is a problem of fonts or a problem of Konsole.

which font is used in your screenshot? 

[1] http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt
[2] http://unicode.org/reports/tr11/
Comment 4 Dotan Cohen 2012-04-09 20:02:41 UTC
The font in the screenshot was Ubuntu Mono. I won't be at my computer for a few weeks to check, but I can confirm that the phenomenon is in fact font-dependant. All the fonts that I like suffer this problem, but some very ugly fonts do not.

Here is the original bug that I filed on the Ubuntu Mono font:
Comment 5 Ranasingha Aaraccigee Sisikossal Chatranga Ranasingha 2012-06-02 01:46:53 UTC
I suffer from the same problem with certain unicode characters and can confirm this. However I'd like to add that just like Cohen said, it's dependent on the font that's used. I've recently tried to set Monaco (which is wider than the standard font used) as my Konsole font, but found that konsole eats up a little of the prompt when I set the font to that. I'm thinking it's got something to do with the character width.

Here's a screenshot:

Comment 6 calvinh34 2013-11-12 23:01:06 UTC
Created attachment 83533 [details]
A gif showing a large width character bug in Konsole
Comment 7 calvinh34 2013-11-12 23:09:15 UTC
Hi !
Sorry, I did'nt get that the comment box in the web interface would be the message   with my attachements.

Anyway, I found that bug too, using monofur font.

I also confirm it's font dependant, I have no problem with any other font like Deja Vu or Monospace.
Although I patched it with powerline () witch gives the arrow-like character in prompt, the problem actually come from the 'inverted A' and 'weird E'.

As you can see, the bug doesn't occur when the problematic glyph is the first character after prompt (the inverted A), which is just cropped to a normal width wharacter.

Comment 8 petteyg359 2013-11-12 23:22:42 UTC
(In reply to comment #7)
> I also confirm it's font dependant, I have no problem with any other font
> like Deja Vu or Monospace.

In my experience, this occurs with all fonts. Changing the font (either face or size) will solve the problem temporarily; after exiting and restarting Konsole, the problem appears again regardless of the current font.
Comment 9 Iven Hsu 2014-06-20 19:06:47 UTC
I confirm this issue.

In my case, the only working fonts are Dejavu and Monospace. All of the other fonts have this issue, like Droid Sans Mono, Ubuntu Mono, Adobe Source Code Pro, Fantasque Sans Mono.

While this doesn't occur in xterm.
Comment 10 canlotes 2014-07-15 00:40:03 UTC
On my case is confirmed also with "Unispace" under openSUSE 13.1 x86-64 with fglrx64. It seems that the final character is under the cursor, no matter his shape or font size.
Comment 11 Eugene 2014-08-25 16:35:18 UTC
Created attachment 88421 [details]
konsole russian issue
Comment 12 Eugene 2014-08-25 16:36:02 UTC
Comment on attachment 88421 [details]
konsole russian issue

Issue: the cursor moves right from proper position when typing russian
Encoding: UTF8
Entered string: "при наборе русского текста курсор уходит вправо"
Font Oxygen Mono 8
Version 2.13.2
Comment 13 canlotes 2014-08-28 08:41:54 UTC
I am starting to think that this is something related with the video driver (¿...? IMHO). I have an old computer, with a nvidia card, same initial installation but instead ati driver, it has the nvidia one. The same font type and it works perfectly.
Comment 14 Eevee 2015-02-14 22:02:35 UTC
I'm /reasonably/ sure this has nothing to do with Unicode character width, and everything to do with fonts.  (Note that the character in the original screenshot doesn't take up two cells; it takes about one and a half.)

I think the problem is that Konsole is rendering each row as a regular line of text.

The original reporter's terminal font apparently doesn't have an airplane glyph.  So the font engine searches for a font that does, and finds one, whatever it may be.  But this new font probably isn't monospace, so the glyph isn't the same width as the rest of the characters in the terminal.  Konsole blindly prints it anyway and places the next character immediately following it, even though this is now completely misaligned from the grid.

The cursor is apparently rendered separately (makes sense, since it's not a character), so it gets drawn in the appropriate grid cell.

What Konsole /should/ be doing is either shrinking the substituted character to fit in a cell, or forcibly rendering every single character at its correct position (even if this makes some overlap).

This has been a bug for as long as I've used KDE.  It makes using non-ASCII characters for any reason basically impossible — my prompt, irssi, vim, roguelikes, anything that uses interesting characters causes the cursor and columns to become misaligned.  I've had to switch to a libvte-based terminal, which correctly handles this by overlapping characters when necessary.
Comment 15 Eugene 2015-02-26 10:36:45 UTC
(In reply to Eevee from comment #14)
> I'm /reasonably/ sure this has nothing to do with Unicode character width,
> and everything to do with fonts.  (Note that the character in the original
> screenshot doesn't take up two cells; it takes about one and a half.)

You are right. My problems ended when I set Droid font.
I think Konsole should warn user about non-monospace characters in selected font or try to calculate right cursor position. Something should be done to eliminate users confusion.
Comment 16 Matthew Paul Thomas 2015-03-05 14:40:12 UTC
Hi, I'm QA for the Ubuntu font featured in the screenshot. I don't use KDE, so take anything I say with a grain of salt, ;-) but:

> What Konsole /should/ be doing is either shrinking the substituted character to fit in a cell,

It would be inefficient and unreliable if the developers of every terminal app, and every other app that uses a monospace font for alignment reasons, had to include their own code to detect and shrink over-wide characters. It wouldn't even occur to most of them that it was something they needed to do! So in <http://launchpad.net/bugs/932958> I suggested that this be done lower down in the stack -- perhaps in fontconfig, perhaps in Pango (or whatever KDE's equivalent of Pango is).

> or forcibly rendering every single character at its correct position (even if this makes some overlap).

This is what Gnome Terminal does right now, and people really don't like the overlap. Examples:
Comment 17 Alexander Kowalski 2015-08-17 09:51:29 UTC
Created attachment 94081 [details]
Screenshot showing where the letters are cut off

Someone posted a new bug (bug 351380) yesterday which is a duplicate of this one, but it made it (in my opinion) more clear where the cutting off of the characters happens.

It was already mentioned that following a wide character, from the cursor on the rest is drawn correctly again, but this also happens on any other color change (and I could imagine maybe bold/underlined too, but I didn't check).
To show this, I expanded the test case from that bug and made a screenshot of it.
As you can see, the last misaligned character is always cut off when the color changes.
If you print only the text in red, it is cut off at the end of the line; if you don't change the color, you don't see any cut off, but if you just add one "red" space after the text, it will cut off the last character again.
This also happens when you select part of the line (presumably the fg/bg colors are just inverted for that part) or put the cursor in the line (but that isn't shown in the screenshot).
You can also see this happening in the input lines due to my syntax highlighting.

Tested with konsole 15.08.0
Comment 18 Kurt Hindenburg 2015-09-04 20:55:32 UTC
*** Bug 351380 has been marked as a duplicate of this bug. ***
Comment 19 Brendon Higgins 2015-09-20 17:50:09 UTC
Perhaps not surprising, but it seems vertical extent/placement is also affected by this. I was running a script (in Konsole 15.08.0) which prints names of files it's processing, and noticed some lines that happened to contain a Я (Cyrillic capital Ya) character in the filename were misplaced downwards by a couple of pixels when using the Oxygen Mono font (9pt).
Comment 20 Serhiy Zahoriya 2015-10-30 04:40:33 UTC
Filed a report against Oxygen Mono: https://bugs.kde.org/show_bug.cgi?id=354588
Comment 21 Christoph Feck 2016-12-07 19:22:17 UTC
Brendon, for the vertical issue, please see bug 371687.
Comment 22 Phil Armstrong 2016-12-11 16:43:08 UTC
The original bug as reported is fixed for me in Konsole 4:16.08.2-2 on the current Debian testing release as of today.

This is probably because Unicode 9 included fixes to mark many of these characters as EAST ASIAN WIDE, & a conforming fixed width terminal will render these as taking up the space of two ordinary characters.
Comment 23 Christoph Feck 2017-02-17 13:04:09 UTC

*** This bug has been marked as a duplicate of bug 361547 ***
Comment 24 Guillaume BINET 2017-02-17 14:00:36 UTC
Reported:	2012-04-03, it feels like the other one is the duplicate ! :)
Comment 25 Vadim A. Misbakh-Soloviov (mva) 2017-03-23 13:51:53 UTC
1) dear Cristoph Feck, would you be so kind to explain how can the bug reported in 2012 with long discussion history be a duplicate of bug reported in 2016 with a single "me too" comment? Wouldn't you mean the opposite assignment (that bug as duplicate of this)?

2) Despite airplane icon (at least with my font) don't mess the things in modern Konsole (16.12.3) as for reporter, it is a very big bunch of characters (say, emojis, for example, or some other "icons") that mess up the things and makes inline navigation impossible.