In openSUSE 13.2, in Konsole, downarrow↓displays↓wrong. The file encoding, Konsole terminal's encoding, and vim's encoding are all UTF-8. Five↓↓↓↓↓downarrows↓↓↓↓↓look↓↓↓↓↓like↓↓↓↓↓three. vim counts characters properly but the display is wrong. more, cat, etc., display wrong. I used Suse 11.0 for six years. Konsole had no problem with downarrows. I have been informed that the Unicode consortium invented ambiguous-width characters. So the Unicode consortium needs to be taught that, just as half-width Romaji have different encodings than full-width Romaji, and half-width katakana have different encodings than full-width katakana, and even a full-width plain blank space has a different encoding than half-width plain blank space, it is possible to do the same with downarrows. Anyway, without teaching the Unicode consortium, it is still possible to teach Konsole. Konsole's settings panel, font selection dialog, has a preview textbox. I can paste downarrows into the preview. Five downarrows display properly in the preview. Konsole's main window displays downarrows properly for some fonts but not for others. I think Konsole knows what locale it's running in because Konsole's own menu bars and settings panels are mostly displayed in Japanese. So I think Konsole can be made to use full-width display for characters that traditionally had full-width display. Reproducible: Always Steps to Reproduce: 1. Use vi, more, cat, cp (to /dev/tty), etc., to display a file that contains downarrow characters. Actual Results: Actual results are corrupt. Five downarrows look like three. If using vi, cursor motion keys move the cursor to the next or previous character so it's possible to edit the file even while operating half-blind, but it's not pleasant. Expected Results: Five downarrows should look like five. If using vi, cursor motion keys should move from a character to an adjacent character and the user can see what they're editing. If using cat, the user can see what's in the file. Konsole's menu bar, settings dialogs, etc., are mostly displayed in Japanese. So Konsole knows what locale it's running in. Even though the Unicode consortium needs to be taught a lesson (they handled multiple widths OK for Italian characters, katakana, and plain blank space), it is still possible to remind Konsole of how to render characters in their proper widths like it used to do.
When the language of installation of openSuse 13.2 is Japanese, the default font of Konsole is Monospace, which maps to IPAGothic, and the problem occurs. When the Konsole font setting is changed to DejaVu, downarrows display properly. The display isn't identical to what it used to be in Suse 11, but it's correct. Konsole knows what locale it's running in (e.g. the menu bar and settings dialogs are Japanese) but I have a feeling that it doesn't really matter. The downarrow character in IPAGothic is rendered as a halfwidth character (one ASCII character cell) but it's really a fullwidth character (two ASCII character cells), so a sequence of five of them look like three. vim counts characters correctly but the user gets confused when rows of text appear not to be aligned correctly, as well as the apparent number of characters not being correct. The downarrow character in DejaVu doesn't suffer from this problem. It's rendered as a fullwidth character and everything is working. Despite the need to inform the Unicode consortium that halfwidth and fullwidth characters are separate characters for arrows too, not just for letters such as Roman, Greek, Cyrillic, and katakana, I have a feeling that this Konsole bug is not their fault.
Can you update and let us know if this is still an issue? and perhaps add a screenshor.
Created attachment 104106 [details] Screenshot Screenshot
The problem was consistent in a different installation of OpenSuse 13.2, but the problem is inconsistent in my present installation of the same OS. The screenshot is from my present installation, showing the inconsistency. As shown in the "vi" session, when the cursor is in the middle of a line containing arrow characters, something is greatly confused and the display is completely scrambled. This still makes editing just about impossible. But for unknown reasons, in my present installation, the output of cat displays the arrow characters properly in full-width. In my earlier installation, arrow characters were all displayed as half-width both in vi and the output of cat. This still made editing impossible. In my earlier installation, a Japanese person recommended changing the Konsole setting for fixed-width font. Some fonts displayed arrow characters as full-width and solved the problem consistently. In my present installation, I think I haven't tried such an experiment yet, but I don't know what produced the inconsistency.
Changing status from Needsinfo back to Unconfirmed. If you disagree, please let me know.
Might be relevant: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1665140.
The down arrow U+2193 is indeed of "ambiguous width" both in Unicode 8.0 and 9.0.
"The down arrow U+2193 is indeed of "ambiguous width" both in Unicode 8.0 and 9.0." Then it's not entirely Konsole's fault, but we still need a workaround for the Unicode consortium's bug. The present behaviour sometimes makes Konsole unusable, just like (retired C language lawyer speaks up now) a C compiler that only compiled one single valid C program would be legal but unusable. How did the Unicode consortium figure out that half-width a, full-width ａ, lower-case a, upper-case A, upper-case Ａ, etc., shouldn't all have ambiguous width, ambiguous casing, etc. But just allowing Konsole to be unfriendly doesn't force Konsole to be unfriendly.
Konsole uses QPainter::drawText() for the complete line, which handles the pixel advances the fonts provide. The only way I see to fix this is to call QPainter::drawText() for each cell character individually, so that the characters are always aligned to grid, regardless how wide they are in the fallback fonts.
I'm observing the same with other characters too, in Konsole 19.12.3 (=default on kubuntu 20.04): ✔ (checkmark) and ✖ (X) Here's a (very fancy ;-) reproduction script: ```bash #!/bin/bash echo '✖'; echo '✖A'; echo '✖ A'; echo '↓'; echo '↓A'; echo '↓ A'; ``` The problem only occurs, if the UTF8-character is *immediately* followed by another (`✖A`); it works if it's followed by a line break or space. Here's a screenshot: https://github.com/Codeception/Codeception/issues/6029#issue-735432274
Can you try a recent version such as Qt6? If you can reproduce any oddities, just revert back to confirmed. Thanks.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to Bug Janitor Service from comment #12) > This bug has been in NEEDSINFO status with no change for at least > 15 days. I thought it was closer to 15 years than 15 days, but actually it's only closer to 9 years. The bug caused trouble for me when I edited source files that had been created by others, with downarrows and uparrows in comments. I no longer edit their source files, so I am no longer affected by the bug. This doesn't mean it WORKSFORME, because I don't find out if it works or not. Three years ago Thomas Landauer found similar manifestations of the bug. If he's still active, perhaps you can ask him if it's fixed or not.
I don't know how to get Qt 6. The issue from my above reproduction script seems to be fixed now in Konsole 21.12.3 (Qt 5.15.3). But there's still something wrong, regarding styling (color): * The color is never working for those special characters * The character is only displayed partially, if there's no blank after it ```bash #!/bin/bash GREEN='\033[0;32m' NC='\033[0m' # No Color printf "${GREEN}Green${NC}\n" # Just to prove that `${GREEN}` is working in principle ;-) printf "✔\n" # Full checkmark displayed in grey color printf "${GREEN}✔${NC}\n" # "Half" checkmark displayed in grey color printf "${GREEN}✔ ${NC}\n" # Full checkmark displayed in grey color ```